如何检索召回数据库的表和字段？

核心回答

电商问数把召回拆成字段、指标和字段取值三路：字段找列，指标找计算口径，取值找筛选条件里的真实值。字段和指标使用 Embedding 与 Qdrant，取值使用 Elasticsearch；三路并行完成后，由程序按字段 ID 去重，补齐指标依赖、取值所属字段和候选表主外键，再输出按表组织的 table_infos 与指标列表 metric_infos。

例如“统计华北地区的销售总额”，需要同时拿到订单金额字段、销售总额对应的指标定义、地区字段中的“华北”，以及订单表和地区表的连接字段。只召回“销售额”和“华北”两个相似文本，还不足以生成正确查询。

三路分别怎样实现

字段和指标的名称、描述、别名在构建期写入各自的向量集合；配置为需要同步的字段取值写入全文索引。查询时，关键词抽取节点先产生通用关键词，各召回节点再结合原问题生成适合本路的扩展词。

• 字段路：把通用词与字段扩展词合并，逐词生成向量，查询字段集合，再按 ColumnInfo.id 去重。它返回字段所属表、类型、角色和说明等信息。
• 指标路：检索指标集合，按 MetricInfo.id 去重，保留描述、别名和 relevant_columns。例如配置中的 GMV 依赖 fact_order.order_amount，不能只留下指标名称。
• 取值路：用扩展后的词查询 Elasticsearch，得到包含 column_id 和 value 的候选。用户说“华北地区”，命中的真实值可能是 dim_region.region_name 中的“华北”；全文命中仍是候选，不代表任意别名都已准确归一。

三路各写一个状态字段，避免并行更新互相覆盖；随后统一合并。固定版本图编排把这组并行分支与合并节点明确连接起来。

指标依赖和主外键为什么要补

合并节点先用 column_id 建字典。命中的指标若依赖尚未召回的字段，就按 ID 从元数据库查询补入；命中的取值也先找到所属字段，再合并进该字段的 examples。这样，口径、物理字段和条件值才能对上。

随后按 table_id 分组，为每张候选表查询配置为主键或外键的字段，去重后加入上下文，最后补上表说明。以销售总额为例，即使字段路漏掉 order_amount，指标依赖也能把它补回；当订单表与地区表都进入候选后，再补 fact_order.region_id 和 dim_region.region_id，为连接提供信息。合并节点源码展示了这段处理。

这里补的是候选表上的键字段，并没有沿全库关系图自动寻找所有桥接表。若必要的中间表从未进入候选，还要增加关系路径补表设计；补齐字段也不等于已经确认连接方向和聚合粒度。

筛选与取舍

合并后，表字段与指标还会分别经模型精筛。表过滤节点让模型返回保留的表名、字段名，程序再裁剪原结构。这能控制上下文长度，但当前实现没有强制保留全部指标依赖和连接字段；进一步完善时，可以在精筛后做依赖复核，缺失时补回或终止本次生成。

验证时应分别看字段、指标和取值是否命中，合并与过滤后必要依赖是否仍在，以及最终查询结果是否正确。例如金额字段漏召回可以靠指标依赖补齐；地区真实值缺失却不能靠多补几个主键解决。增加召回数量会带来更多噪声，应与完整相关结构、不同候选范围在同一组问题上比较。

对应教程

• 电商问数：关键词抽取与多路召回：回看字段、指标和真实取值的职责，以及各路检索与去重。
• 电商问数：召回信息合并与上下文构建：回看指标依赖、取值归属、主外键补齐，以及两个输出对象。

参考资料

• 国内：飞致云：SQLBot 最佳实践：借鉴表字段说明、关联关系和术语配置，解释只靠字段相似度为什么不足以组织查询上下文。
• 国内：阿里云 Quick BI：数据准备：采用字段描述与真实维值准备的做法，说明语义找列与取值匹配解决不同问题。
• 国内：阿里云 Quick BI：问数知识管理：参考业务定义、同义词、数据范围和选表约束的分工，解释召回前需要限定范围，指标定义也不能由相似度代替。
• 国内：NineData：Text2SQL / Chat2SQL：借鉴字段注释、枚举与表关系的准备和核对方式，说明召回上下文需同时支持筛选、关联与计算。
• 国外：AWS 与 Cisco：Enterprise-grade natural language to SQL generation using LLMs：参考按业务域缩小结构范围、补充描述和业务规则的方案，解释完整结构与按需检索的取舍。
• 国外：Wang 等：RAT-SQL：采用问题与表字段的名称、取值及关系需要共同对齐的分析，解释为何字段命中后仍要补连接信息。

核心回答

SQLBot 的这条召回链以表级结构为单位：先在当前数据源已选用的表字段范围内，用表结构向量和关键词规则给表排序，保留用户明确点名的表，再补入已配置关系中与候选表直接相连的表，最后把表名、字段类型、说明和连接关系交给模型生成 SQL。

它的 Python 后端负责结构读取与上下文组装，Embedding 模型提供语义相似度，关键词规则补充精确名称和业务描述。字段参与表的匹配，并随入选表进入结构上下文；这条实现并没有为每个字段建立独立向量召回分支。选中了业务表，还要确认连接路径及需要的字段是否完整。

先准备结构，再做表匹配

构建表向量时，程序把表名、字段名、字段类型及自定义说明组织为结构文本，计算并保存向量。查询阶段先读取已勾选的表和字段，对字段应用列权限过滤；若调用方提供 table_list，还会进一步限制候选表。

随后组装各表的 schema_table：表说明优先采用自定义说明，否则使用原表注释；字段结构包含字段名、类型及已配置的自定义说明。关键词评分还能使用字段原注释。由此，向量所依据的结构、关键词信号和最终送给模型的字段列表需要分别核对，修改说明后也要关注表向量是否同步更新。

普通内置数据源路径会先抽取问题关键词，再用术语同义词扩展，供表匹配使用。向量分数衡量关键词与表结构的语义接近程度；关键词规则则匹配表名、表说明、字段名和字段说明，并结合匹配质量与覆盖率评分。启用融合时，分数为 α × 向量分数 + (1−α) × 关键词分数，默认 α=0.4。它是规则分数与向量分数的线性融合，未使用 RRF 或独立重排模型。见关键词与向量融合实现。

明确点名的表怎样保留，失败时怎样回退

仅按融合分取前几名，可能漏掉问题中明确要求使用的表。_select_tables() 因此会用原始问题匹配完整表名或完整表说明，把这些表保留在前面，再按已有排名填充剩余名额。匹配处理标识符边界、引号包裹名称和重叠名称，减少把短表名误当成长表名中一部分的情况。

TABLE_EMBEDDING_COUNT 默认是 10，但显式命中的表全部保留，数量可能超过这个值。这一规则只作用于调用方已经筛选过的候选，不会把范围外的表重新引入。见显式表保留规则。

当前表匹配按排名和数量选择，没有额外的最低相似度阈值。因此，低相关问题也可能得到若干候选表。关键词为空、关键词功能关闭或融合计算异常时，会改用原问题做纯向量排序；纯向量计算也异常时，则保留全部已过滤候选并把显式命中项置前。这种回退减少了计算失败造成的漏表，但会增加结构上下文，不能把“有候选”当作已经找到正确表。

一跳关联补表能补什么

表匹配后，程序读取数据源维护的 table_relation，找出至少一个端点属于当前候选表的关系边，补入这些边另一端缺失的表结构，再追加相应字段等式。关系来自配置，虽然输出栏目名是 Foreign keys，并不表示已经从数据库自动发现并验证全部外键约束。补表也只从此前允许的候选范围中取结构。

这个过程只扩展一跳。例如已选 A，关系为 A→B→C，能补入与 A 直接相连的 B，但不会再以新补的 B 为起点递归查找 C。它可以补回某些未直接命中的桥表，却没有实现任意多跳路径搜索；长链查询仍可能缺表或缺边。具体流程见结构拼接与一跳关系补全。

最终结构上下文包括数据库标识、入选和补入的表结构，以及相关字段连接式；可选的样本数据另行读取。业务术语、示例 SQL 和额外提示分别注入生成消息，不由表向量替代。若要进一步支持复杂桥接，应在允许范围内增加路径选择与连接粒度校验，而不是无差别扩展整张关系图。

验证时，可以对照纯向量、融合、显式保留和一跳补表，分别检查目标表是否出现、关键字段是否保留、连接路径是否完整，以及最终结果是否符合口径。这样才能区分是选表漏了、关系配置缺了，还是结构已经齐全但生成的连接或聚合有误。

参考资料

• 国内：飞致云：SQLBot 最佳实践：采用表字段说明、手工关系配置、术语与示例分别提供上下文的做法，解释表匹配之后为何仍需连接和业务知识。
• 国外：Wang 等：RAT-SQL：依据问题名称、字段及关系共同对齐的分析，解释显式名称信号与表结构关系各自解决的歧义；项目机制以固定版本源码为准。