大模型+数据分析：不是Prompt调得好就行，Text2SQL核心在Schema治理与后处理

一、为什么你的Text2SQL只能当玩具？

过去一年，几乎所有数据团队都试过“自然语言查数据库”：接个大模型API，写几句Prompt，就能让用户输入“上个月华东区销售额TOP10产品”自动生成SQL。Demo很惊艳，一上生产就崩盘：

• 字段名猜错：把order_amount写成sales_amt，SQL直接报错；
• 关联关系乱连：多表JOIN时张冠李戴，查出完全错误的数据；
• 业务术语不理解：“活跃用户”在库里没有对应字段，模型瞎编WHERE条件；
• 无权限控制：普通员工一句话查出全量薪资数据，安全审计直接亮红灯。

问题不在大模型不够聪明，而在我们把Text2SQL当成了纯LLM任务，而非数据工程任务。真正能落地的自然语言查询系统，LLM只占30%的工作量，剩下70%是Schema治理、知识增强、结果校验与权限管控。

这篇文章不讲理论，直接拆解一套在生产环境稳定运行6个月的Text2SQL架构，包含完整流程图、关键代码片段与踩坑记录，帮你跳过所有弯路。

二、企业级Text2SQL核心架构：四层防御体系

先看整体架构，这不是简单的“Prompt→SQL→执行”线性流程，而是带反馈闭环的工程化系统：

这套架构的核心思想是：不信任LLM的单次输出，用工程手段兜底。下面逐层拆解关键实现。

三、第一层：Schema治理——Text2SQL的地基

90%的SQL错误源于Schema信息缺失或混乱。别直接把SHOW CREATE TABLE的结果塞给LLM，必须做三层治理：

1. 元数据标准化

为每张表、每个字段补充三类信息：

• 业务中文名：cust_id→ “客户唯一标识（非自增ID）”；
• 枚举值映射：status=1→ “已支付”，status=2→ “已退款”；
• 关联关系显式声明：orders.cust_id = customers.id，而非靠LLM猜测。

存储格式推荐YAML，便于版本管理与人工维护：

table:ordersdescription:"订单主表，记录交易全流程"columns:-name:order_amountcn_name:"实付金额（含优惠，单位：元）"type:DECIMAL(12,2)note:"不含运费，退款订单为负数"-name:statuscn_name:"订单状态"enum:{1:"待支付",2:"已支付",3:"已取消",4:"已退款"}relations:-target:customerscondition:"orders.cust_id = customers.id"type:"many-to-one"

2. 动态Schema检索

不要把所有表结构塞进Prompt！当表超过20张时，Token爆炸且干扰严重。采用向量检索+关键词匹配混合召回：

• 将表/字段的中文名、描述、示例值向量化存入Milvus/Weaviate；
• 用户提问先提取实体词，召回Top-K相关Schema片段；
• 仅将召回结果注入Prompt，大幅降低噪声。

实测：50张表的场景下，动态检索比全量注入准确率提升28%，Token消耗减少70%。

3. 业务术语词典

建立“自然语言→数据库表达”的映射表，解决领域黑话问题：

• “新客” →first_order_date >= DATE_SUB(CURDATE(), INTERVAL 30 DAY)
• “高价值用户” →lifetime_value > 5000 AND order_count >= 5

该词典由数据分析师维护，作为RAG知识源参与SQL生成，避免LLM自行臆造逻辑。

四、第二层：SQL生成与校验——不让错误SQL流出

LLM生成策略优化

• Few-shot样本精选：不按相似度选示例，按“表组合+查询类型”分层采样，覆盖JOIN、聚合、子查询等高频模式；
• 强制输出约束：要求LLM同时输出SQL+推理过程+置信度，低置信度结果自动触发二次生成；
• 模板优先原则：对于高频查询（如日报、周报），预置参数化SQL模板，LLM仅填充参数，杜绝结构错误。

三重校验机制

这是准确率从60%提升到95%的关键：

特别注意：语义校验不能只靠规则。我们引入了轻量级SQL解释器，模拟执行计划检查是否会产生笛卡尔积、全表扫描等危险操作，提前阻断性能炸弹。

五、第三层：执行与结果验证——数据可信的最后防线

即使SQL正确，也可能因数据质量问题返回错误结果。必须增加结果侧验证：

• 空结果诊断：返回0行时，自动分析WHERE条件过严还是数据缺失，给出修改建议；
• 异常值检测：数值型结果超出历史3σ范围时标记预警，附带数据分布截图；
• 溯源标注：每条结果标注来源表、过滤条件、计算逻辑，支持用户点击验证。

这一步让系统从“生成SQL”升级为“交付可信答案”，用户信任度显著提升。

六、落地避坑清单：这些钱别白花

1. 别追求100%自动化：复杂分析需求（如同环比归因）仍需分析师介入，Text2SQL定位是“80%常规查询自助化”；
2. 别忽视冷启动成本：Schema治理和术语词典需要2-4周集中建设，前期投入决定后期上限；
3. 别用生产库直连：所有查询走只读副本+资源隔离沙箱，防止慢查询拖垮核心业务；
4. 别跳过用户反馈闭环：记录每次查询的“采纳/修正/拒绝”行为，用于持续优化Few-shot样本与校验规则；
5. 别迷信开源方案：DuckDB-NL、Vanna等工具适合原型验证，生产级需定制权限、审计、监控等企业特性。

七、写在最后：Text2SQL不是终点，而是数据民主化的起点

自然语言查询的真正价值，不是替代SQL，而是降低数据消费的门槛，让业务人员敢问、能问、问得准。当销售主管自己能查到区域转化漏斗，当运营同学不用等排期就能验证活动效果，数据才真正从“资产”变成“生产力”。

技术会迭代，但“让人更接近数据”的方向不会变。如果你正在落地Text2SQL，不妨先从一个小业务域试点，把Schema治理做扎实，再逐步扩展。记住：准确的笨办法，永远比花哨的错答案更有价值。

欢迎在评论区分享你的Text2SQL踩坑经历，下一篇我们聊聊如何用Agent编排实现多轮对话式数据分析，敬请期待。