alannero

摘要： 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 阅读全文

摘要： 分清四类角色：配置文件 + 业务实体 + ORM模型 + mappers 配置文件: 配置文件是“外部输入”，告诉程序：这次要处理什么。 它主要负责： 要同步哪些表 每张表有哪些字段 字段的角色、描述、别名是什么 哪些字段后续还要同步真实取值 哪些指标要进入知识库 所以配置文件更像一份“任务说明书” 阅读全文

摘要： 当前项目选择的不是“在业务代码里直接加载 Embedding 模型权重”，而是： 服务端组件：Text Embeddings Inference，简称 TEI 嵌入模型：BAAI/bge-large-zh-v1.5 Text Embeddings Inference，通常简称 TEI。它本质上就是一 阅读全文