Text2SQL选型推荐矩阵：五层方案、四维决策与12场景落地指南

如果有人问我，Text2SQL落地最痛苦的一步是什么，我大概率会回答：不是模型选不好，而是方案选不定。过去大半年我帮好几支团队做Text2SQL的技术评审和落地，他们递过来的Demo一个比一个好看——随便问一句就能出SQL，准确率惊人。可真到上生产，问题全冒出来了：几百张表怎么喂给模型？外部用户并发上来怎么办？业务口径打架谁来管？这时候大家才意识到，“能做”和“能上线”之间，隔着一整套工程决策。

这篇文章把我按真实需求梳理出来的Text2SQL选型推荐矩阵摊开聊。我先拆一下当前主流方案的五个层级，再讲选型时真正要盯死的四个维度，然后给出12个细分场景的精准推荐组合，最后分享几个选型误区和我自己踩过的坑。正文按可复制的工程视角来写，适合三类人：准备做自然语言查数的产品经理、负责技术选型的数据架构师、以及真正要写代码落地的后端和算法工程师。

1. 先看全景：Text2SQL方案的五个主流层级

做选型之前，脑子里必须有一张地图。现在市面上的Text2SQL方案五花八门，但拆到底层，无非五个层级：模板/规则、LLM直接生成、RAG增强LLM、微调开源模型、Agent多轮分析。我按从轻到重的顺序逐个说清楚它们各自的边界。

1.1 模板/规则方案：固定意图场景仍是最优选

模板/规则方案是最老派的做法，本质上是把用户问题抽象成若干个固定句式，再通过槽位填充去生成SQL。比如“查一下[城市]今天的天气”“[订单号]到哪了”，系统先做实体识别，把城市、订单号抽出来，再套预先写好的SQL模板。

这套方案在2023年之前几乎是行业标配，现在也远没被淘汰。我自己在帮一个物流公司做售后查询时，发现用户真实提问高度集中在十几个意图上，模板方案准确率能做到接近100%，延迟可以稳定压在100毫秒内，而且完全不可能产生幻觉——因为SQL是写死的，变量只有一个槽位值。

它的短板也很明显：新意图一多，模板指数级膨胀，维护成本很快变成灾难。所以现在更合理的做法是拿模板做“第一梯队拦截”，同时把没命中的问题丢给LLM兜底。模板负责高频、成本敏感、准确性要求拉满的流量，LLM负责低频、长尾、灵活提问。

1.2 LLM直接生成：从Demo到生产还有很大距离

LLM直接生成是目前传播度最高又最容易误导人的方案——给模型一个schema，它就能零样本输出SQL。用ChatGPT或主流开源模型随便试几个经典问题，效果惊艳，尤其是单表查询和简单join场景。

但只要你把真实的库结构丢进去，问题就开始了。真实的业务库动不动就几百张表，每张表几十个字段，Prompt里根本塞不下。强行塞进去，模型在超长上下文里开始“抓瞎”，看着哪张表都像，最后生成一个能跑但结果完全不正确的SQL——这是Text2SQL最危险的一种失败模式，因为程序不报错，业务却拿错了数据。

所以我的判断是：纯LLM直接生成适合三类场景——Demo、外部API模型的快速原型验证、以及表结构非常简单的个人工具。直接上生产，风险不可控。

1.3 RAG增强LLM：工程上收敛最快的落地路径

RAG增强LLM是目前企业级落地里最主流的方案。它的核心思路很简单：不把整个schema硬塞给模型，而是先做检索，把与用户问题最相关的表结构、字段注释、外键关系、指标口径、甚至几条历史问答示例一起取出来，再让模型基于这些局部上下文生成SQL。

这套方案有一个标准的工程管道：先做表路由，筛出最可能相关的2-3张表；再做元数据检索，把这几张表的列名、类型、注释、外键关系喂给模型；最后叠加一个程序化校验层，检查生成的SQL语法、列是否存在、join路径是否合理。整条链路下来，在常规业务库范围内，准确率能做到85%-95%，而且对schema变化的容忍度远高于微调方案。

为什么说这是工程上收敛最快的路径？因为它不依赖大量标注数据，也不需要企业GPU资源，只要把元数据治理做干净，效果就出来了。我见过不少团队在这个方案下两周内就打通了内部BI问答的闭环。

1.4 微调开源模型：学的是企业“口音”

微调方案主要解决的是“企业方言”问题。每个企业都有自己的命名习惯：有的把客户叫CLIENT，有的叫CUSTOMER，再有的叫客户主数据视图；指标口径更是五花八门，同一个“销售额”，业务一部和二部的统计逻辑可能完全不同。通用模型再聪明，也没学过你们公司内部这些黑话。

微调的核心价值是让模型学到特定schema下的映射习惯。实际操作中，你需要积累几千条高质量的人工修正数据——用户问题、模型错误SQL、人工修正SQL，最好是带执行结果验证的。这比2万条自动跑出来的数据有用得多，因为LLM训练这件事，数据质量的重要性远大于数据量。

但微调不是银弹。它最大的坑在于模型可能会在微调过程中丢失一部分通用推理能力，碰上没见过的问法反而变笨；另外每次schema变更，都意味着可能要重新准备数据和再训练。所以我的建议是：微调只适合表结构相对稳定、查询模式相对集中的大型企业内部数仓，而且最好配合RAG一起用。

1.5 Agent多轮分析：把Text2SQL变成数据对话

Agent方案是最近两年热度上升最快的方向，特别是代码类模型（比如Codex系列）出现之后，模型不仅能写SQL，还能写Python代码，把Text2SQL从“生成一句查询”扩展成“完成一段分析任务”。

典型流程是：模型生成SQL，执行报错后自动读错误信息并修正，再执行直到跑通，最后拿到结果后还能做二次加工，比如生成图表、计算同环比、归纳结论。这种“写SQL-执行-反馈-修正-再执行”的循环，让模型像一个真正在干活的数据分析师，而不是一个SQL生成器。

代价也很明显：延迟高、成本高、不可控环节多。一轮查询可能触发十几轮模型调用，单次查询成本可能是RAG方案的十倍以上。Agent方案目前最适合内部运营分析、用户量小但交互深度大的场景，放在面向C端的高并发入口里用，很容易被打爆。

2. 选型矩阵的核心维度：选什么方案，先看这四个值

方案层级知道了，怎么选？我习惯把选型决策拆成四个核心维度，每个团队在定方案之前，先诚实地给这四个维度打分，很多分歧会自然消失。

2.1 数据复杂度：判断你要不要上“重型装备”

数据复杂度决定了你的工程投入下限。我一般看四个指标：总表数、单次查询涉及的join深度、字段命名规范程度、业务口径数量。

总表数在20张以内、join深度不超过3层、字段命名清晰，这是低复杂度，模板加RAG就够了，上微调和Agent纯属浪费。总表数上百甚至上千、存在大量同名字段、join路径超过4层，这就是高复杂度，必须上表路由加程序化校验，微调才有性价比。口径数量是个容易被忽略的指标——如果业务方对同一个指标有超过5套口径，你首先要做的不是选模型，而是建一个指标字典，否则再强的模型也不知道该按哪个口径生成。

2.2 准确性敏感度：数据错了，代价有多大

准确性敏感度要分三层看。决策级准确性：金融风控、管理层经营决策、合规报表，这种场景数据出错会直接导致经济损失或合规风险，准确性优先级高于一切，宁可多花成本做人审。运营级准确性：日常运营分析、零售经营下钻，数据错了会影响策略但可控，这类场景可以接受95%左右的可执行准确率，配合用户反馈闭环持续修正。体验级准确性：面向C端的智能问答、客服查询，这种场景用户对“答错”的容忍度很低，但“不会答”反而可接受，所以要建立“查不到就明确告知”的兜底机制，而非硬给一个可能错的SQL。

曾经有个团队跟我反复纠结一个模型准确率是92%还是95%，但对业务方来说，真实代价差异根本不在那三个点，而在“错了之后能不能及时被发现”。所以准确性敏感度维度的真正问题不是“多准”，而是“错了的后果多大、能不能兜住”。

2.3 性能与并发：多少用户同时问，容忍等几秒

性能维度有三个硬指标：P99延迟、并发QPS、单次查询执行预算。

直接生成类的方案，单次生成普遍需要2-5秒，内部工具还能忍，面向外部用户就完全不行。解决思路有两类：第一类是模板兜底，高频提问直接从缓存或预编译SQL里拿结果，彻底绕开模型；第二类是语义缓存，把用户问题做归一化后查缓存，相似问题直接返回历史生成结果，命中率能做到30%以上。

数据库端的执行预算也必须在选型时一并约束。用户问题本身没法预测SQL复杂度，你必须在程序化校验层给SQL加上超时和扫描量上限——比如强制不允许全表扫描、单次查询最多跑5秒。不设这个上限，一个精细问法可能把生产库拖垮。

2.4 成本与团队资源：预算不够，再好的方案也白搭

成本维度不只是API调用费，我建议把四笔账一起算：模型成本、标注成本、硬件成本、人力成本。

模型成本是大头但不是唯一的坑。假设一个内部系统每天有3000次查询，每次查询消耗约5000个token，一个月光token费用就是数千元。微调方案的话，一次微调的人力加硬件成本，足够你用API方案跑一年以上。所以除非查询量极大或者数据必须私有化部署，否则优先用API加RAG，这是大多数情况下的经济解。

团队资源也要掂量。团队里有没有能读懂SQL、能维护校验规则的人？如果没有，模板方案的比重就得加大，因为LLM方案的工程兜底需要有人持续维护。选型选出来的不是一个模型，而是你们团队未来一年要维护的一整套系统。

3. 12个场景的精准推荐组合

下面这张表是我把常见需求归纳成12个场景后给出的选型结论。表格先给总览，后面逐个展开讲理由和注意事项。

3.1 固定意图、高并发场景：模板优先，LLM做配角

场景1：固定工单/售后查询。这是模板方案的主战场。以物流售后为例，“我的包裹到哪了”“为什么延迟派送”“修改收货地址”这类问题，用户提问句式高度稳定，底层只需要查询订单表、运单表、操作日志表三张表。我用规则模板加一个轻量实体抽取模型做槽位填充，整体准确率逼近100%，单次查询响应时间控制在100毫秒左右，服务端几乎不需要常驻GPU。

关键细节是模板表的设计：不只是“意图-模板”的静态映射，要加上对实体值的边界处理，比如用户可能说“昨天发的货”，实体抽取要做相对日期解析。这类场景最容易犯的错是在模板没覆盖到的时候硬套近似模板，宁可直接转人工或转LLM兜底，也不要返回一个错误的运单状态。

场景2：C端站内搜索问答。面向C端用户的问题五花八门，但整体流量分布符合长尾定律——头部20%的问题占了80%的流量。这种场景的核心矛盾是：用户查不到会流失，但系统查错了更伤体验。所以推荐方案是“模板拦截大部分高频请求+LLM重写剩余长尾问题+结果校验后返回”。

工程上要把LLM放在旁路而不是主路径上。主路径先做query归一化，匹配语义缓存和历史模板，命中直接返回；没命中才走LLM生成，并且强制加上SQL超时、限制最大join张数、限定操作库表白名单。面向用户的产品，答不上来的话术远好于生硬报错，更远好于给一个跑得通但结果错的数据。

场景3：实时大屏/运营监控。大屏场景不追求交互灵活性，追求丝滑。这种场景最合适的做法是干脆不跑模型：运营想看什么指标，提前列清单，由开发人员离线把SQL写好，大屏端只做参数传递。LLM在这里的角色是“模板制造机”——当运营新增指标需求时，用LLM离线生成候选SQL，人工评审后合入模板库，线上运行时完全不需要模型推理。

我见过有人非要把LLM嵌到大屏链路里，结果一次模型升级导致SQL风格变化，线上大屏数据展示出问题，事故等级还很高。实时场景里稳定压倒一切，让模型离线生成、人工控制上线，是成本最低又安全的方式。

场景4：初创MVP快速验证。创业团队做自然语言查数功能，最忌讳一上来就摆重型RAG架构和微调管线。MVP阶段的核心命题是验证“用户愿不愿意用自然语言问数据”，而不是“准确率能不能到95%”。直接用成熟API模型，把核心表结构在提示词里描述清楚，加上每个字段的简短业务说明，就足够支撑早期验证。

要注意的是，MVP代码里必须留一个“方案切换点”——把LLM调用封装成独立接口，未来要接RAG或换微调模型时，只改内部实现不动外部调用。我见过很多团队MVP代码里LLM调用写得到处都是，后面想改造只能重写，白白多花几周时间。

3.2 分析探索类场景：RAG、微调与Agent的组合拳

场景5：内部BI驾驶舱/管理者问答。管理层问数据的特点是：提问句式灵活，但落点高度集中在几十个核心指标上。“这个月华东区的销售怎么样”“为什么华北区退货率突然高了”，本质上都是在问少数几个既定指标在不同维度下的表现。

推荐方案是RAG加指标字典，把每个指标的口径、计算公式、涉及表名、常见筛选维度固化成结构化条目，查询时先做指标识别再检索表结构。这部分一定要把语义缓存做好，因为管理层的高频问题高度重复，大模型服务不是瓶颈，但token成本和延迟能省则省。另一个容易踩坑的地方是“指标口径冲突”，同一个销售额在不同部门可能定义不同，这必须在指标字典层解决，不能指望模型自己判断。

场景6：企业数仓即席分析。这是最考验工程深度的场景。数仓动辄几千张表，用户提问又是跨主题、多表join的复杂分析，比如“对比今年和去年各季度的高价值客户复购率”。纯RAG方案在这里不够用，因为检索器很难一次把相关表全部找全。

推荐组合是微调垂直模型加程序化校验，前置一个强表路由模块。表路由可以先基于向量检索粗筛候选表，再用一个分类模型精排，最后把经过筛选的3-5张表结构交给微调模型生成SQL。程序化校验这里不能少，尤其是join路径检查——模型经常会把客户表和订单表用错误的字段关联，生成一个能跑但数据翻车的SQL。此场景务必建规则：join超过4张表的SQL直接拒绝，要求用户拆解成多个问题。

场景7：电商/零售经营分析。零售分析的灵魂是“下钻”：先看整体销售，然后下钻到品类，再下钻到城市，再对比上月同期。这套交互天然需要多轮上下文管理，所以Agent方案在这里最合适。每一轮生成SQL后，要把上一轮对话的关键约束（时间范围、维度选择、筛选条件）透传给下一轮模型，形成连续的分析会话。

实践中的难点是“改条件”的自然表达。用户说“把华东换西南，其他不变”，模型要能识别这是对上一轮筛选条件的替换而不是新增条件。建议把所有历史条件结构化成JSON快照，每次用户提问先做条件更新再生成SQL，而不是连续拼接对话文本让模型自己理解——后者在第三轮之后基本上必出错。

场景8：研发日志/异常排查。日志查询和普通业务查询差异很大：表结构不直观，时间序列特性强，用户还经常要配合正则和聚合统计。我会推荐Agent加代码解释器风格架构：模型先用伪代码写清楚过滤逻辑——查询哪些服务、匹配什么关键字、按什么时间粒度聚合——再由执行器翻译成最终的查询语句，跑完如果报错，Agent自动读错误并修正。

这个场景最重要的参数是扫描成本控制。日志表动辄上亿行，每次查询必须限制时间范围，超大时间窗只跑抽样统计或者提前物化好的中间表。我在实际项目中踩过坑：Agent自作聪明地把时间范围从用户说的“今天”扩充到了“近30天”，结果一个聚合查询把日志库CPU跑满了。硬性规则一定写死在代码里，不让模型自由发挥。

3.3 安全敏感与特殊场景：宁可慢，不可乱

场景9：金融风控/合规报表。金融场景的底线是审计追溯，SQL必须可解释、可复核、可回滚。我推荐的方案是微调加快校验再加人工评审：系统可以自动生成SQL，也可以自动执行，但所有进入正式报表的SQL都必须有人在审核流里点确认，任何一步都留日志。

这个场景里，程序化校验的要求也更高：必须做列级权限校验、行级权限注入、白名单表校验。曾经有团队在提示词里写“不要访问salary表”来防止模型查薪水，这完全是自欺欺人——模型只要没被硬性约束，就可能通过join绕过表面限制。真正的做法是，SQL生成之后在参数层面强制改写，在权限上下文里动态拼接过滤条件，让模型根本没机会生成越权的SQL。

场景10：医疗科研数据查询。医疗数据比金融数据还敏感，尤其涉及患者维度时，通常要求数据不出域。所以这类场景必须走本地化部署，直接用开源模型微调，外部API调用这条路直接堵死。模型体量不必追求大，但要对查询模式做足专项微调，宁可牺牲一些通用能力，也要把“跑得稳”放在第一位。

比较实际的做法是做一个“受控探索”机制：允许科研人员用自然语言查询聚合统计，但所有结果先经过脱敏层，凡是可能反推出个体的查询不返回原始明细。日志同样要脱敏，用户输入的查询语句也要过滤敏感实体。安全不是某个校验模块的事，它是从输入到输出全程的默认约束。

场景11：教育/知识混合查询。教育场景里数据源很杂：课程表是结构化的，教学大纲是PDF文档，历年的考试分析是表格。用户问题经常跨源，“去年挂科率最高的课程对应的任课老师是谁”，既要查成绩表，也要去文档里找任课安排。

推荐方案是混合检索，向量检索和结构化查询并行：向量检索负责从文档里召回候选实体，结构化查询负责从成绩表里算出挂科率，再由LLM融合两边结果生成最终回答。这类场景的关键不再是SQL准确性，而是“查询路由”——先判断问题主要落在结构化数据还是文档数据上，判断错了一切白搭。路由模型需要专门收集一批混合提问样本，一般几十条到上百条就能见效。

场景12：个人效率工具。最后一个场景最轻：本地的SQLite、个人记账表、书单数据这种，表只有几张，字段也不复杂。推荐方案是本地轻量模型或直接调用API，把schema在提示词里写清楚，加少量few-shot示例，体验已经很好。

个人工具要注意的是别过度设计。你不需要表路由、不需要语义缓存、不需要Agent，架构越简单越容易坚持用下去。我给自己搭过一个报价管理的小工具，就是模板加LLM兜底，总共几百行代码，用了一年多也没翻车。选型不是越重越好，是越匹配越好。

4. 常见选型误区与排查经验

4.1 三个最典型的选型陷阱

第一个陷阱：把Demo表现当生产稳定性。Demo里三句测试都对，就以为方案没问题，结果上线后发现用户问法一变化，准确率直线下降。解决方式是用分层评估集——第一层看可执行率，SQL能不能跑通；第二层看结果正确率，抽样做数据对拍；第三层看口径符合率，业务专家逐条审核。三层全过才允许放量。

第二个陷阱：让大模型包办一切。很多团队把所有问题一股脑丢给大模型，结果简单的固定查询也被送到模型里转一圈，成本高、延迟高、风险高。正确做法是先做意图分类路由，高频固定问题走模板或缓存，只有长尾复杂问题才交给LLM。

第三个陷阱：忽略数据库方言差异。模型在训练数据里学到的八成是PostgreSQL和MySQL语法，你的库可能是SQL Server或达梦，窗口函数、分页语法、函数名千差万别。解决办法是把数据库方言版本写进提示词，同时在程序化校验层做语法特性和函数白名单检查，模型生成一个不支持的函数直接拦截。

4.2 一次失败复盘：All-in微调的教训

这里说一个真实案例。去年有支团队找我咨询，他们花了三个月微调一个开源模型，目标是用自然语言查询取代公司内部的固定报表体系。微调做完了，线上准确率不到70%，业务部门完全拒绝使用。为什么？

我们把查询日志拉出来分析，发现80%的问题集中在20个模板句式上，场景高度重复，但团队却选择了最重型的微调方案。微调周期长、标注数据量不够、模型更新跟不上业务口径变化，每一步都在拖后腿。后来调整成“模板主拦截+LLM兜底+指标字典RAG”的混合方案，两周内业务反馈明显改善，可感知的准确率到了90%以上，token成本反而降了70%。

这个复盘给我最大的启发是：企业内部的需求表面上是自由提问，底层却是高度重复的问法。选型前先统计查询日志，看看高频问题到底有多少，这比讨论哪个模型参数能力强有用得多。

4.3 选型落地清单：从方案到上线要做的事

如果方案选好了，落地阶段我建议按下面的清单推进，顺序可以微调但最好不要跳步。

第一步，先搭查询日志和意图分类体系。任何优化都要建立在知道用户在问什么的基础上，连用户问什么都不知道就开始优化，容易优化到错误的方向上。第二步，把最小闭环跑通：用户提问-路由-元数据检索-LLM生成-程序化校验-执行-结果展示-用户反馈记录，这条链路要尽量早打通，后续优化才有的放矢。第三步，建设三级评估集和数据回放机制，错误样本要能自动回流到示例库或训练集，形成闭环。第四步，设置线上监控指标：生成耗时、执行耗时、成功率、缓存命中率、拒答率、用户修正率，这些指标每天看一遍。第五步，留出灰度切换开关，新模型或新方案先在内部团队试运行，确认没问题再逐步放量到全公司。

这套清单不一定漂亮，但我确认过很多次，它确实能兜住绝大多数生产环境会出的意外。Text2SQL项目失败，大部分不是模型失败，而是工程支撑失败。

做了这么多Text2SQL场景之后，我最深的感受是：选型这件事，比的不是谁的方案听着高级，而是谁对真实场景的约束理解得更透彻。模板、RAG、微调、Agent，没有哪个层级是绝对先进或绝对过时的——固定查询场景里模板依然是最优解，复杂数仓里微调才有价值，C端高并发必须把模型放旁路，安全敏感场景无论如何先满足可审计。

如果只让我给一句建议：别急着上重型架构，先把查询日志翻一遍，把数据库的元数据和指标口径理干净，这两件事做好了，哪怕用最普通的模型组合，都能撑起一个让业务愿意用下去的系统。底子没打好，再强的模型也只是偶尔说对而已。