alannero

摘要： API文件可以先把它们分成五层： 层次文件主要职责 入口层 main.py 创建 FastAPI 应用，注册生命周期和路由 HTTP 层 query_router.py 定义 /api/query，接收请求，返回流式响应 业务层 query_service.py 创建 State / Context 阅读全文

摘要： 先搭建一个最小的FaastAPI接口 from fastapi import FastAPI # 创建 FastAPI 应用实例 app = FastAPI() # 声明一个 GET 接口 @app.get("/health") async def health_check(): # 返回普通 di 阅读全文

摘要： SQL生成前有那些信息 query # 用户原始问题 table_infos # 可使用的表、字段、字段类型、字段描述、示例值 metric_infos # 可参考的业务指标、指标口径、依赖字段 date_info # 当前日期、星期、季度 db_info # 当前数据库方言和版本 如果缺少这些上下 阅读全文

摘要： 之前将三路召回的信息整理成两份核心上下文： table_infos # 按表组织好的表结构上下文 metric_infos # 整理后的指标上下文 但这里的“整理好”，还不等于“足够精确”。 本章要实现的三个节点，就是在 SQL 生成前做最后一轮准备： filter_table # 过滤表和字段 把 阅读全文

摘要： 本章结束后，state 里会多出两个后续节点最常用的字段： table_infos # 按表组织好的表结构上下文 metric_infos # 整理后的指标上下文 后面的过滤表、过滤指标、生成 SQL，都会围绕这两份上下文继续工作。 为什么不能把召回信息直接给大模型 字段召回得到的是一个字段列表，列 阅读全文

摘要： 在实际应用中，我们经常会遇到这样的需求：同一个Graph，在不同的调用场景下，需要使用不同的配置参数 。 有时候我们希望Graph使用Claude模型，有时候希望使用GPT模型;有时候我们希望给模型设置不同的System Prompt，以适应不同的任务场景;这时候，Runtime Configura 阅读全文

摘要： 落地的是最前面的四个节点： extract_keywords # 从用户问题里抽取关键词 recall_column # 根据关键词召回可能相关的字段信息 recall_metric # 根据关键词召回可能相关的指标信息 recall_value # 根据关键词召回可能相关的字段真实取值 比如问题： 阅读全文

摘要： 这里有三处设计需要先看懂。 第一，关键词抽取之后，字段信息、指标信息、字段取值可以并行召回。它们都依赖用户问题和关键词，但彼此之间没有强制先后顺序。 第二，召回结果不能直接交给大模型生成 SQL。召回阶段通常宁可多召回一些，避免漏掉关键信息；但生成 SQL 阶段需要尽量干净、准确的上下文。因此中间还 阅读全文

摘要： 字段向量索引要解决的问题是：怎么让字段信息具备语义检索能力。 字段向量索引的建立： async def _save_column_info_to_qdrant(self, column_infos: list[ColumnInfo]): """把字段元数据继续推进成可语义检索的 Qdrant 向量点 阅读全文

摘要： 这一章先抓住一条落库链路：配置文件描述表字段，系统去数仓补齐真实结构，再转换成内部实体，最后写入 Meta MySQ ORM、Repository、事务这些细节都服务于这条链路 正式进入第一条真正落地的业务链路：把配置文件里描述的表和字段，转换成系统内部统一的数据对象，并写入 Meta MySQL 阅读全文