介绍项目中检索召回的完整流程。

核心回答

以下以电商智能问数项目为例，介绍检索链路与模块分工。

项目检索的对象是表字段、指标定义和字段取值，目的是为自然语言生成SQL提供准确的数据库上下文。技术上，Qdrant 负责字段与指标的语义检索，Elasticsearch 负责字段取值检索，MySQL 保存可按标识查询的结构化元数据，LangGraph 编排处理流程。

离线先同步元数据，建立字段、指标和取值索引。在线收到问题后，先抽取关键词，再并行召回三类候选；随后去重、补齐指标依赖字段，把取值归到对应字段，并补充相关表的主外键。候选经过表和指标过滤、补充必要上下文后，才进入SQL生成。

我负责召回结果合并模块。比如问“华北地区销售总额”，不仅要找到金额口径与地区值，还要把订单表和地区表关联所需的字段带全。验证时分别检查每路候选、合并结果和模型最终输入，再核对生成SQL，区分漏召回、合并丢失和生成错误。

先准备哪些可检索资料

字段与指标描述向量化后建立索引；真实取值进入全文检索索引。记录原始描述和稳定标识，才能把候选反查成结构化元数据。元数据变更时，应同步对应索引，避免新表结构与旧描述并存。

沿着“华北地区销售总额”走一遍

1. 理解与抽词：保留原问题，抽取“销售总额”“华北地区”等关键词，必要时扩展别名；时间或金额口径不明时先确认，不能由扩词改变任务。
2. 字段召回：用关键词匹配字段描述，得到金额字段、地区字段等候选，并保留所属表和字段标识。
3. 指标召回：匹配“销售总额”的已登记定义，获取计算表达与依赖字段。不能直接假定它在每个项目中都等于同一口径的GMV。
4. 取值召回：检索“华北”的候选记录，保留值与字段的对应关系。全文匹配产生的是候选；结果是否符合用户对象仍需核对。
5. 合并补齐：按字段标识去重，反查缺失的指标依赖字段，将取值加入对应字段的示例，再按表分组并补齐主外键。
6. 筛选与构建上下文：过滤无关表和指标，补充必要信息，形成SQL生成需要的表结构与指标上下文，保留来源和当前有效版本。

图中重点是三路候选如何汇合，SQL生成位于检索与上下文构建之后：

flowchart TD
 Q[用户问题与关键词] --> C[字段候选：Qdrant]
 Q --> M[指标候选：Qdrant]
 Q --> V[取值候选：Elasticsearch]
 C --> U[按标识合并并补齐依赖]
 M --> U
 V --> U
 DB[MySQL结构化元数据] --> U
 U --> F[表和指标过滤、补充上下文]
 F --> G[SQL生成与后续校验执行]

这不是把三份文本直接拼接。模型需要知道“华北属于哪个字段”“金额口径依赖哪些列”“两张表如何连接”，合并模块负责补出这些关系。

怎样验证检索与合并

准备能覆盖别名、相似字段、多个地区值、多表指标和元数据更新的固定样本。每条保存原问题、各路候选、合并输出以及实际发送给模型的上下文。

若最终SQL漏了地区条件，先看取值是否被召回、是否归到正确字段、过滤后是否仍进入模型输入；不能直接归咎于模型。如果候选已正确、进入上下文后仍生成错误，才继续检查提示词和SQL生成。

还要检查候选数量、关键字段覆盖、最终查询正确性及各环节延迟。增加候选或重排可作为改进方向，但需要用同一组样本比较；原链路中的合并与表/指标过滤，不等于已经配置了独立的重排模型。

常见追问

为什么不用一套向量检索解决全部问题？

字段描述和指标别名适合语义匹配，真实取值还需要稳定映射到具体字段。分路后可分别优化候选质量，再用结构化元数据补关系。这是本项目的数据组织选择，不是所有数据库问答都必须使用三套存储。

检索命中就能保证SQL正确吗？

不能。命中候选不代表口径正确或关联完整，合并、过滤和生成都可能引入错误。语法校验也不能证明业务含义正确，需要与问题条件、指标定义和对照结果一起检查。权限限制还应在可信数据访问与执行层落实。

对应教程

参考资料