260 張表中只取 6 張：文字轉 SQL 的表選擇陷阱

文本转 SQL 系统在日常使用中往往给人「直接把自然语言变成查询」的直观印象，但真正落地时，模型在生成任何 SQL 之前，必须先解决一个没人愿意明说的问题：它能看哪些表。一个真实数据库可能有 260 张表，而提示词窗口根本装不下全部 schema，更不用说塞进去之后还会稀释模型的注意力、抬高延迟与成本。因此系统必须在生成前主动做筛选，只把一小部分候选表喂给模型。这一步通常被当作一个检索问题来处理：把每张表的 schema 结构编码成向量嵌入，用用户问题去查询，按相似度排序，然后取前六张。这套流程在演示环境中表现不错，因为演示用的往往是 40 张命名规范、彼此干净的 tidy schema，问题与表名高度对应，检索的自然命中率很高，于是大家默认这一步已经解决。作者正是察觉到这种「演示级可信」与「生产级脆弱」之间的落差，才专门构造了一个用来击破该机制的 schema，并拿自己的库上去实测，结果那个召回数字让他并不想公开，却也恰恰是最有价值的发现。

从技术原理上看，这个陷阱的核心在于「检索相关性」并不等于「查询正确性」。RAG 式表选择依赖的是问题文本与表 schema 之间的语义相似度，但 SQL 查询真正需要的，是表与查询意图之间的逻辑可达性。一张表可能在命名或字段上和问题毫无相似之处，却是回答所必需的——比如一个被命名为 `audit_log` 的表，要回答「本月有多少用户修改过密码」，真正需要的可能是 `user_actions` 表里某条被硬编码为 action_type=7 的记录，而「密码」「修改」这类词在表名和字段里根本不会出现。此时基于文本相似度的检索会毫不犹豫地把它排除。反过来，一张名字里恰好撞上了问题关键词的表，可能只是干扰项。更麻烦的是外键关系：正确的答案往往需要多表 join，而 Top-K 检索是逐表独立打分、互不知情的，它无法判断「选 A 表就必须连带选 B 表」这种结构性依赖，于是即便单表召回都达标，拼出来的查询依然会缺胳膊少腿。换句话说，把表选择简化成向量检索，等于假设「最像问题的表就是最该用的表」，这个假设在复杂 schema 上几乎必然崩塌。

对行业和相关方而言，这个发现的杀伤力在于它动摇了当前一大批文本转 SQL 产品的隐性前提。对做 BI 和数据分析工具的公司来说，表选择是决定最终准确率的上游闸门，上游错了，下游再强的 SQL 生成与纠错也无济于事，用户看到的只是「这系统连我明明问的都答不对」，却不知道为什么。对中小企业和内部工具团队，他们数据库的 schema 往往命名混乱、历史包袱重、语义高度隐含，恰恰是这种「击破型 schema」最擅长的场景，于是演示效果与真实体验的落差会格外刺眼。对开发者社区而言，这篇分析的价值在于把注意力从「模型够不够大」「提示词怎么写」这种热门话题，拉回到那个更基础、却更少人研究的工程环节——schema 的检索与组织策略本身。它提醒业界，表选择不是模型能力的附属品，而是一个独立的、值得专门建模和评测的研究方向。

往后值得关注的信号有几个方向。其一，如何把表之间的 join 关系、约束、以及字段值的分布信息纳入检索，而不是只靠文本相似度，这可能是突破当前天花板的关键。其二，是否会出现针对表选择的专业评测基准，用刻意构造的「陷阱 schema」来量化召回的真实下限，而不是只报演示环境里的漂亮数字。其三，混合检索与重排机制能否真正缓解结构性依赖问题，比如先粗筛再结合图结构做关系扩展。对正在构建或选型文本转 SQL 系统的团队来说，最务实的做法是：别拿演示 schema 的指标当结论，而是用贴近自己真实数据库复杂度的数据去跑一遍表召回，看看在「需要的表没被选上」的情况下，端到端准确率会掉到什么程度。那个数字，往往比任何模型评测都更能说明问题。