text2sql 怎么做的？怎么提高准确率

1️⃣ 考察意图

面试官想考察你对 text2sql 整条链路的工程化理解，而非仅仅背诵模型名称。核心考察点：你是否清楚从“自然语言问题”到“可执行 SQL”的完整 pipeline，以及如何在真实业务中平衡准确率、延迟和成本。刁钻点在于：多数候选人只提“用 LLM 生成”，但面试官想听 schema linking 的细节、执行验证（execution-guided decoding）的 trade-off，以及如何处理“模型生成正确但执行报错”的工程坑。答好了能展示你从模型选型到后处理策略的系统设计能力，以及处理长尾问题的工程直觉。

2️⃣ 标准答

Text2SQL 的经典 pipeline 分为四步：问题解析 → Schema Linking → SQL 生成 → 执行验证。下面逐一拆解，并给出提高准确率的工程手段。

1. 问题解析与语义增强

核心：将自然语言问题转化为结构化查询意图。使用 NER（命名实体识别） 提取问题中的数值、日期、实体名（如“北京”、“2024年”），并用 依存句法分析 识别条件关系（如“大于”、“属于”）。
工程取舍：直接让 LLM 做端到端生成（如 GPT-4）虽然简单，但缺乏对数据库 schema 的显式对齐，容易产生幻觉。因此，必须在 prompt 中注入 schema 信息，并做结构化拆解。

2. Schema Linking（核心难点）

问题：数据库可能有上百张表、数千列，LLM 无法全部塞入 context window，且容易混淆相似列名（如 order_date vs ship_date）。
解法：采用 两阶段检索：
粗筛：用 BM25 或 embedding 检索（如 text-embedding-3-small）从所有表和列中召回 top-20 候选。BM25 默认参数 k1=1.5, b=0.75 对短文本（列名）效果较好。
精排：用 ColBERT 或 cross-encoder（如 BAAI/bge-reranker-v2-m3）对候选做细粒度相关性打分，保留 top-5 表和 top-10 列。
实际落地的坑：列名缩写（如 cust_id vs customer_identifier）导致检索失败。解法：维护一个 列名同义词表（如 id → identifier），并在 embedding 前做标准化。

3. SQL 生成与模型选型

主流方案：
微调小模型（如 CodeLlama-7B、SQLCoder-7B）：在 Spider 或 Bird 数据集上微调，推理成本低（单条 0.1 秒），但泛化到新数据库时准确率下降 10-15%。
大模型 in-context learning（如 GPT-4、Claude-3）：无需微调，但 prompt 设计关键。必须包含：数据库 DDL（CREATE TABLE 语句）、示例 SQL（few-shot）、以及 schema linking 结果（即上一步筛选出的表和列）。
工程取舍：微调模型适合固定 schema 的业务（如电商订单查询），大模型适合多变的 SaaS 场景。不要把全部 schema 塞进 prompt，否则 token 成本飙升且模型注意力分散。

4. 执行验证（Execution-Guided Decoding）

核心：生成 SQL 后，在数据库上执行，捕获语法错误或空结果，并反馈给模型修正。
具体做法：
语法校验：用 sqlparse 或 sqlglot 做静态检查，拦截明显错误（如缺少 GROUP BY 的聚合列）。
执行反馈：若执行报错（如 column not found），将错误信息拼接回 prompt，让模型重新生成。通常迭代 2-3 次，准确率可提升 5-8%。
自一致性采样：对同一问题生成 5 个候选 SQL，执行后选结果出现频率最高的（如 3/5 返回相同结果）。这比直接选概率最高的 SQL 更鲁棒。
实际落地的坑：执行验证依赖数据库连接，高并发场景下可能压垮 OLTP 库。解法：只读副本 + 限制单次执行超时（如 5 秒），或用 SQLite 内存数据库 做沙箱执行。

5. 提高准确率的进阶手段

检索增强（RAG）：构建“相似问题-SQL 对”库，用 embedding 检索最相似的 3-5 个历史问题，作为 few-shot 示例注入 prompt。在 Spider 数据集上，这能将执行准确率从 72% 提升到 78%。
领域微调：在目标数据库的查询日志上做 LoRA 微调（rank=8, alpha=16），仅需 1000 条标注数据即可适配特定业务（如医疗、金融）。
后处理规则：针对常见错误写硬编码规则，例如：问题含“平均”时强制加 AVG()，含“每个”时强制加 GROUP BY。

3️⃣ 答题模板（30 秒电梯版）

“这个问题我从三个层面回答：第一，经典 pipeline 包括问题解析、schema linking、SQL 生成和执行验证，其中 schema linking 是最大瓶颈，我用两阶段检索（BM25 + cross-encoder）解决；第二，提高准确率的核心手段是执行验证和自一致性采样，能提升 5-8%；第三，工程上要注意 schema 注入的 token 成本、执行验证的并发控制。总结一句：text2SQL 不是纯模型问题，而是检索、生成、验证的工程完整流程。”

4️⃣ 高频追问 & 应对

追问 1：如果数据库有 1000 张表，schema linking 怎么保证不遗漏关键表？

采用 分层检索：先根据问题中的实体名（如“用户”、“订单”）用 BM25 召回 top-50 表，再用 cross-encoder 精排到 top-10。如果问题涉及多表 JOIN（如“查询北京用户上个月的订单”），需要显式识别表间外键关系（如 user.id = order.user_id），并在 prompt 中注入关联路径。极端情况下，可以允许模型生成“未知表”占位符，然后通过执行报错回退到全量检索。

追问 2：执行验证时，如果模型生成的 SQL 语法正确但逻辑错误（如多了一个 WHERE 条件），怎么处理？

用 结果对比：对同一问题生成多个候选 SQL，执行后比较结果集。如果某个候选的结果是另一个候选的子集（如行数少 50%），大概率是误加了过滤条件。更鲁棒的做法是 语义等价性检查：用 sqlglot 将 SQL 转为抽象语法树（AST），计算两棵树的编辑距离，低于阈值则视为等价。实际工程中，我倾向于用自一致性采样 + 投票，因为简单且有效。

追问 3：微调 CodeLlama 时，训练数据怎么构造？直接拿 Spider 的 SQL 对行吗？

不行。Spider 的 SQL 是标准格式，但真实业务中列名、表名差异大。正确做法：数据增强——对每个问题，随机替换表名和列名为同义词（如 user → customer），并加入 10% 的噪声（如拼写错误）。训练时，输入格式为 [问题] [DDL] [schema linking 结果]，输出为 SQL。LoRA 微调时，学习率设为 2e-4，batch size 8，训练 3 个 epoch 即可收敛。

5️⃣ 避坑 · 常见错误答法

❌ 说“直接用 GPT-4 生成 SQL，准确率很高” → ✅ 正确切入：强调 GPT-4 在复杂 schema 下容易产生幻觉，必须结合 schema linking 和执行验证，且 token 成本高，不适合高并发场景。
❌ 说“用 RAG 检索相似 SQL 就能解决一切” → ✅ 正确切入：RAG 只能处理高频问题，对长尾问题（如嵌套子查询）效果差，需要结合模型生成能力。
❌ 说“执行验证就是跑一下 SQL，看报不报错” → ✅ 正确切入：执行验证的核心是逻辑正确性检查，包括结果集对比、自一致性采样，以及超时和并发控制。

6️⃣ 简历呼应

如果你有 RAG 项目：从“检索增强生成”角度切入，强调 schema linking 本质是 RAG 在 text2sql 的特化应用，并分享你如何用 embedding + reranker 解决多表检索问题。
如果你只做过传统 NLP：用“序列标注 + 模板填充”类比，说明早期 text2sql 用 Seq2Seq 模型（如 T5），现在转向 LLM + 执行验证，并突出你对 NER 和依存句法的理解。
如果你是校招无项目：聚焦 Spider 数据集上的实验，展示你复现了 CodeLlama 微调 + 执行验证，并对比了不同模型（如 SQLCoder vs GPT-4）的准确率和延迟。
《Spider: A Large-Scale Human-Labeled Dataset for Complex Text-to-SQL》
《SQLCoder: A State-of-the-Art LLM for Text-to-SQL》
《Execution-Guided Decoding for Text-to-SQL》
《ColBERT: Efficient and Effective Passage Search via Contextualized Late Interaction》
《LoRA: Low-Rank Adaptation of Large Language Models》

—— 本场面试完 ——