1. 为什么选型这么难Text2SQL 项目的第一道分水岭Text2SQL 这几年热度一直没降但真正落地的团队其实没有想象中那么多。我见过不少团队在选型阶段反复横跳今天拿开源模型微调明天换 API 试用折腾两三个月后还在原地打转。问题往往不在模型本身而在选型流程缺乏章法——需求没有拆清楚标准没有量化后面所有评估都是在凭感觉打分。这篇是 Text2SQL 系列的第 7 篇启动一个更贴近实际决策的话题4 步选型法。整套方法分成四步——场景定义、标准设定、候选评测、决策验证。按照系列的计划这篇先讲上半部分也就是前两步怎么把业务场景说清楚怎么把选型标准落成可衡量的指标。适合读这篇文章的人有三类正准备在企业内部落地 Text2SQL 的工程师或架构师、需要给团队做技术选型汇报的负责人、以及做 Text2SQL 产品规划的产品经理。如果你个人正处在Demo 看起来啥都能做一上真实数据就不行的阶段这篇尤其值得读完。先说我自己的判断Text2SQL 选型本质上是一个约束优化问题而不是一个模型比拼问题。同一个模型在内部报表场景和对外查询服务场景里的表现可能是天壤之别。你提前把场景和标准这两个变量钉死后面的评测才有意义钉不死评测做一百轮也选不出合适的结果。2. 先看全貌4 步选型法的整体逻辑2.1 四步到底在做什么4 步选型法是我在多个实际项目里反复调整后沉淀下来的框架每一步解决一个具体问题步骤核心问题主要产出场景定义这个系统到底给谁用、解决什么任务场景说明书、查询样例集、数据字典标准设定什么样的结果才算好用指标定义、权重表、基线阈值候选评测每个候选方案在标准下表现如何评测报告、对比矩阵、风险清单决策验证选出的方案在小范围试点里是否成立试点结论、回退预案、上线计划这篇只覆盖前两步。但我想先说清楚一件事为什么场景和标准必须先于评测。因为评测本身需要测试集测试集必须来自场景评测结果要用指标衡量指标必须来自标准。顺序反过来的话你很可能拿一个公开 benchmark 的测试集去测自己的业务数据测完发现模型分数很高但业务方根本不认。原因很简单——测试题不是他们日常会问的问题。2.2 顺序不能乱的原因我自己最早做选型时也犯过这个错。当时先拉了五六个候选模型然后急着跑 Spider 和 WikiSQL 这些公开数据集。结果最好的模型准确率有 85%团队很开心直接拿去接业务方的需求。结果业务方随手问了几个上个月华东区退货率超过 5% 的产品种类有哪些这种带约束条件的问题模型直接卡壳。回头看问题不是模型不行而是我跳过了场景定义。公开 benchmark 里的 schema 是干净的单表结构业务方的 schema 有几十张关联表、各种奇怪的字段命名、还有复杂的业务口径。两者根本不在一个世界里。场景定义先行的意义就是强迫你在拿模型之前先回答我的世界里到底有什么。2.3 场景和标准的关系场景和标准不是割裂的两个文档而是互相咬合的。场景描述决定了标准里哪些指标重要如果是内部报表场景可能准确率权重占 60%延迟权重占 20%如果是对外查询服务延迟和安全可能反过来占大头。标准也会反向约束场景描述——如果你发现某个查询类型在现有数据条件下根本没法写 SQL那这个场景要么砍掉要么降级为期望场景不能混在一起评级。我习惯用一个简单的数学关系来表达标准 场景的量化映射。场景里说的每一条需求最终都要能被至少一个指标覆盖。覆盖不到的地方要么场景描述不够具体要么标准设计有缺口。3. 第一步场景定义——把想用 Text2SQL翻译成具体需求3.1 四种典型场景画像场景定义的第一步是判断你的项目属于哪一类。我通常把 Text2SQL 的场景粗暴地分成四种内部报表辅助给业务分析师、运营人员用辅助他们从数据仓库里取数。特点是用户量大、问题模式相对稳定、对 schema 理解要求高。嵌入式自助查询集成在 SaaS 产品里让终端用户直接问自己的数据。特点是权限模型复杂、并发要求高、对错误结果的容忍度极低。数据分析工作台面向数据分析师支持探索式分析。特点是一次会话里可能连续问多个问题前后问题有依赖。决策支持问答面向管理层通常是预设问题模板加上少量自由问答。特点是问题数量少但价值高宁可不答也不能答错。每个场景对应的核心矛盾不同。内部报表辅助的核心矛盾是降低取数门槛嵌入式查询的核心矛盾是安全和准确的双重压力数据分析工作台的核心矛盾是上下文连续性决策支持问答的核心矛盾是错误代价。我建议你在场景定义阶段先把项目定性为这四类中的一类最多两类。如果四类都沾一点说明需求还没有收敛需要回到业务方去重新对齐边界。3.2 用户画像与查询模式盘点定性之后要做两件具体的事用户画像和查询模式盘点。用户画像不需要很复杂的模型只要能回答三个问题用户懂 SQL 吗懂到什么程度用户对数据口径熟悉吗他知道销售额在表里叫revenue还是total_amount吗用户期望的交互方式是什么是聊天框、是快捷键弹窗、还是报表页面上的搜索框这三个问题直接决定了你的 Text2SQL 系统要不要做同义词映射、要不要做字段推荐、要不要在生成 SQL 之外再加一层解释。查询模式盘点则需要收集真实的问题。我常用的方法是去业务方那里蹲点三天把他们在 IM、邮件、工单里问数据的问题全部抄下来。累计收集 100 条以上才能看到模式。比如你会发现 30% 的问题是XX 指标最近 N 天趋势20% 的问题是XX 和 YY 的对比这些模式会成为你测试集的主要构成。这里有一个实操心得收集问题时不要只记自然语言问句还要把提问背后的意图也标注清楚。同样的这个月卖得怎么样有人想要月环比有人想看品类排名有人想知道同比。意图不标注后面做评测时会发现测试集里标签打架模型怎么调都不对。3.3 数据与 Schema 复杂度盘点场景定义里最容易被忽视的是数据侧。很多团队把精力全花在问题收集上却忘了盘点数据本身。但 Text2SQL 是生成 SQLSQL 是跑在 schema 上的schema 复杂度直接决定任务难度。我建议做一张 schema 盘点表至少包含这些信息表数量是 10 张以内的简单 schema还是 200 张以上的企业级 schema。表间关联深度最常见的查询需要关联几张表。单表查询、两表 join、五表 join 的难度完全是三个等级。字段命名规范程度字段是 user_id 这种规范命名还是 f_1092_ab 这种带编码的命名。后者对模型非常不友好必须在场景定义阶段就标记出来。指标口径特殊性销售额是含税还是不含税、退款是否剔除、历史数据是否回溯修正。这些业务口径不会写在字段名里但必须出现在场景说明里。数据库方言是 MySQL、PostgreSQL、SQL Server 还是 ClickHouse。不同方言的语法差异会影响模型生成效果特别是分页、日期处理、窗口函数这些细节。做完盘点后你会得到一个非常清晰的结论schema 复杂度在你的项目里是低、中还是高。这个结论会直接影响后面标准的权重设计。如果 schema 复杂度很高但业务方要求的准确率又不能打折那你在选型时基本可以把纯 prompt 调用大模型这条路线先划掉因为它很难稳定处理复杂 schema 下的 join 和口径问题。3.4 场景定义的标准产出物场景阶段结束时应该有四样东西一份场景说明书描述给谁用、解决什么问题、预期使用频率、核心痛点和成功场景。一份查询样例集至少 50 条真实问题及其对应的标准 SQL按查询模式分组。一份 schema 盘点表表、字段、关联关系、口径、方言的完整清单。一份边界清单明确哪些问题不在本项目范围内比如不做多轮对话不做图表生成不做数据写入。边界清单特别重要。Text2SQL 项目最容易失控的地方就是需求边界无限扩张本来只做取数辅助做着做着变成要生成数据洞察报告。边界清单不是限制想象力而是保护项目在第一个迭代周期内能真正交付。4. 第二步选型标准设定——把好用翻译成可度量的指标4.1 准确率三种口径不能混用场景定义完成后就要开始设定标准。标准里第一个绕不开的指标是准确率但绝大多数团队在定义准确率时是含糊的。我见过不少评估报告直接写模型准确率 92%但细问之下92% 这个数字可能是执行结果一致率可能是字符串匹配率也可能只是人工抽样的主观判断。我建议把准确率拆成三个口径SQL 执行一致率生成的 SQL 能在目标数据库上无错执行且执行结果与标准 SQL 的结果集合一致。这是最严格的口径。SQL 语义等价率生成的 SQL 与标准 SQL 返回相同结果但 SQL 文本可能不同。这一般是执行一致率的上位替代因为执行一致率已经隐含语义等价。答案正确率最终呈现给用户的结果是正确的但 SQL 是否最优、是否浪费性能不纳入考量。三个口径对应不同的项目阶段。早期评测用答案正确率比较现实因为评估成本低但到了上线前的验收阶段必须至少达到 SQL 执行一致率 90% 以上否则业务方不会信任。这里需要补充一个容易被忽略的细节准确率必须按查询模式分层统计不能只看整体平均值。单表查询的准确率如果已经 95%而多表 join 的准确率只有 50%整体平均算下来可能还有 80%但这个 80% 毫无意义因为业务方高频使用恰恰是多表查询。我习惯在标准文档里直接写死分层口径单表查询准确率不低于 92%双表 join 不低于 85%三张及以上表 join 不低于 70%。4.2 覆盖率与鲁棒性准确率之外覆盖率和鲁棒性是两个经常被忽略但很重要的指标。覆盖率衡量的是系统能回答多少比例的用户问题。这里的定义容易让人迷惑——什么叫能回答我建议拆成两个层面问题覆盖率指的是系统不报错、不中断、给出结果的比例正确覆盖率指的是给出正确结果的比例。前一个反映系统的兜底能力后一个反映真正可用程度。通常来讲你至少要追求 95% 以上的问题覆盖率如果做不到大量用户会卡在对不起我没理解你的问题这类交互上。鲁棒性则更进阶一些。它衡量的是遇到没见过的问法、拼写错误、别名、口语化表达时系统还能不能正常工作。我常用的测法是把场景收集里的问题做变异把上个月改成上一月把GMV改成成交总金额把华东和江苏浙江上海混着用。变异后准确率的衰减幅度就是鲁棒性得分。衰减控制在 5 个百分点以内算合格超过 15 个百分点说明模型对表达多样性极度敏感需要重点调优。4.3 延迟、并发与成本Text2SQL 选型里最影响体验的是延迟。一个查询从用户说出问题到拿到结果我建议把目标定在 5 秒以内其中模型生成 SQL 的时间最好控制在 2 秒以内剩下的时间留给数据库执行和网络传输。超过 5 秒用户就会开始不耐烦尤其是内部工具很多业务分析师用了几次之后就会放弃回到找数据团队提工单的老路上。并发这里要区分两个环境POC 环境和生产环境。POC 环境并发很低单机跑模型测试没问题生产环境可能同时有 50 个用户发起查询这时候你就要算清楚推理引擎的吞吐量。如果候选方案是自建模型要提前压测如果是调用外部 API要确认限流策略和超时时间。成本不光是钱还有隐性成本。API 调用费是显性的但模型调优的时间、因为延迟过高导致的用户流失、因为错误查询导致的数据计算资源浪费这些都是隐性成本。我碰过一个团队把成本全部压在 API 调用次数上省了钱但准确率一直上不去业务方意见很大。后来换成自建模型加微调虽然显性成本上去了但准确率提升 15 个百分点业务方反而满意了。4.4 安全与权限不能事后补救Text2SQL 有一个独有的安全问题生成 SQL 的动态性。传统报表是提前写好的 SQL权限可以内置在报表逻辑里Text2SQL 是模型即时生成 SQL权限如果没有在生成阶段被约束用户完全可以用一句查一下所有用户的手机号把敏感数据拉出来。所以标准里必须包含权限约束检查生成的 SQL 只能访问当前用户权限范围内的表和字段。这个标准不能用人工抽检的方式验证要在评测阶段做自动化检查对每个测试用例的 SQL 做权限分析超出权限的就算失败。除了权限还要考虑查询安全性比如防止生成拖垮数据库的 SQL——没有 WHERE 条件的大表全表扫描、在超大表上做笛卡尔 join、递归 CTE 无限循环。这些在需求上不一定敏感但在运维上是要命的。选型标准里应该给这类危险 SQL单独设一个一票否决项。4.5 工程集成与定制能力最后是工程层面的标准虽然不是用户直接感知的指标但决定了后续的维护成本。工程集成的几个检查点候选方案是否支持现有的数据源类型比如 MySQL 和 ClickHouse 同时存在时能不能一套系统搞定。是否提供 API接入现有产品需要多少开发量。是否支持自定义 schema 的映射关系比如字段别名、同义词表、业务口径配置。是否支持热更新schema 变化后需要多长时间生效。是否支持反馈闭环用户对生成结果的点赞、点踩能不能收集并回流到调优流程。我处理过的最典型的一个案例是团队选了一个效果很不错的闭源 API 方案结果发现它不支持自定义 schema 映射只能把表结构描述塞到 prompt 里。业务方改了一个字段名整个系统就乱了。标准里如果没有提前验证定制能力这种坑迟早会踩到。关于标准设定还有一条我自己的经验要特别说明标准里每一项指标都最好有数值下限和权重而不是只有描述性的语句。准确率尽量高不是标准单表准确率不低于 92%才是标准。因为标准最终要被用来做对比评分没有数值下限就无法执行。5. 实操示例制造业客户分析场景的标准模型5.1 场景描述与用户画像为了把前两步串起来我举一个自己做过的真实案例。某制造业企业要做客户分析自助查询用户是销售运营团队大概有 80 人日常会用 Excel 处理从 CRM 和 ERP 导出的数据但不会写 SQL。他们高频想知道的问题有三类客户下单情况、区域销售对比、产品退货率。schema 盘点结果是 42 张表核心涉及 6 张表最常见的查询需要关联 3 到 4 张表。字段命名有一定规范但存在部分历史遗留字段用编码命名的情况。数据库是 SQL Server有比较特殊的日期处理和字符串函数语法。5.2 查询样例与测试集我们从业务方那边蹲点了两周收集了 130 条真实问题。清洗掉重复和模糊的问题后保留 86 条作为场景样例集。把这 86 条按查询模式分组结果是这样的查询模式数量涉及表数占比客户下单明细汇总382-3 表44%区域销售对比243 表28%产品退货率分析154 表17%其他临时取数91-2 表10%这组数据帮我们确定了一件事3 表 join 是测试集的核心难度基准4 表 join 是加分项。同时其他临时取数只有 10%说明业务方的主要需求是模式相对固定的三类问题我们可以把调优资源优先放在这三类上。5.3 标准权重设计与数值下限结合场景定义我们把标准设成了这样的权重表指标权重数值下限说明2-3 表查询准确率30%90%占比最高的查询模式4 表查询准确率15%75%难但必须可用问题覆盖率15%95%不能大面积报错首查询延迟P9510%5 秒内用户侧体验底线权限合规率15%100%一票否决不过关直接淘汰危险 SQL 拦截率10%100%防止拖垮数据库成本上限5%按预算折算单次查询成本不超 0.3 元权重设计有一个小心机准确率相关的权重一共 45%延迟 10%安全相关 25%工程成本 5%剩下 15% 的覆盖率。这个分配的核心逻辑是这个场景里准确率和安全是主要矛盾延迟和成本其次。如果换成对外查询服务场景延迟的权重要提到 25% 以上安全更可能要加到 35%。数值下限则是我们和业务方来回对了三轮才定下来的。一开始业务方说要 95% 准确率我们拿真实 schema 做了一次快速测试发现 4 表查询在当前技术条件下很难稳定达到 95%最后协商成2-3 表 90%、4 表 75%。这个妥协很重要因为标准不现实的话后面执行阶段要么疯狂调优导致周期失控要么标准被推翻重来。5.4 这个标准怎么用标准定完之后后面的评测就有了抓手。等候选方案进入第三步时我们会直接把这个场景样例集和权重表拿过来跑分。最终评分是加权得分加权得分最高的方案进入试点。同时标准里的权限合规率 100%会作为一票否决项任何方案在这个指标上不过关即使总分第一也会被直接淘汰。我把这套做法分享出来不是建议你照抄这些数字而是强调它的结构每个指标都有明确的度量方式、数值下限和权重并且这些数字都是从场景定义推导而来。你换一个业务场景数字可以变但推导链条不能断。6. 场景与标准定义阶段的五个典型问题6.1 测试集只有正向问题没有边界问题很多人收集查询样例时只收集业务方正常的问题比如上个月各区域的销售额是多少。但真正能拉开方案差距的往往是边界问题含退款吗灰色产品线和灰色颜色是不是同一个字段去年和今年同月份对比要排除春节影响吗。这些边界问题的收集很难靠蹲点拿到因为业务方自己也不会天天问。我的做法是把样例集分成两部分主集和边界集。主集来自真实收集边界集来自与业务方访谈时追问出来的极端需求以及我们基于 schema 盘点自己构造的问题。边界集不需要很多15 到 20 条就够了但每条都要标注清楚考察的是哪种能力。6.2 指标定义差不多导致评测结果不可复用准确率口径是重灾区。同一个准确率评测 A 用的是 SQL 执行一致率评测 B 用的是答案正确率两边调优出来的模型都没法对比。我建议在标准文档第一页就用加粗字把指标定义写死并且每个指标附一个判例说明。比如SQL 执行一致率生成的 SQL 在测试库执行后结果集与标准 SQL 执行结果集完全一致字段顺序、行序不要求完全一致但数据内容必须一致。这样不管谁来评测标准都是一个。6.3 忽略数据库方言对准确率的影响如果业务库用的是 ClickHouse你拿 MySQL 语法测试出来的准确率再高也没有意义。方言的影响在复杂的日期处理和时间函数上特别明显。我在一个项目里遇到过模型生成的 SQL 在 PostgreSQL 上跑得好好的换到 SQL Server 就报语法错误原因只是分页写法不同和limit关键字不兼容。选型标准里要加入目标方言适配度这一项至少在评测时所有测试用例都要在目标方言的数据库上执行。6.4 权限设计只在 PPT 上没有落实到评测很多企业的数据权限模型本身就复杂比如按组织层级、按客户归属、按产品线做数据隔离。Text2SQL 系统如果不在生成阶段约束权限至少要能在执行阶段做权限过滤。但我在不少评测报告里根本没看到权限相关的测试项。权限合规率必须被写进标准并且要用自动化手段检查人工抽检大概率会漏。做一个简单的权限检查器并不难解析 SQL 的 FROM 和 WHERE 条件再对照当前用户的数据权限矩阵就能跑出合规率。6.5 标准数值脱离真实场景定完就被推翻这是流程层面的问题。标准的数值下限如果定得过高或过低都会在执行阶段出问题。定得过高的典型表现是评测做了几轮没有任何方案能达到最后只能偷偷降标准整个流程的严肃性就没了。定得过低的典型表现是标准全过但上线后业务方不认可只能推翻重来。我建议在定标准之前先用一个最朴素的方案比如直接调 API 加上简单 prompt跑一轮预测试。预测试的目的不是选型而是探底当前技术能力在目标场景下的天花板在哪里。预测试结果出来后再和业务方一起定一个跳一跳够得着的目标值。这样既不会太乐观也不会太保守。7. 实战中的额外心得标准不是定完就不动了按 4 步选型法的设计场景和标准主要在上篇评测和决策在下篇。但我必须提醒你场景和标准在评测阶段往往是会迭代的。评测过程中你会发现有些测试用例本身有问题比如标准 SQL 写错了、问题语义有歧义、某个边界问题根本不重要。这些都需要回到标准和场景文档里去修正。我自己的经验是场景说明书和标准文档保持初版 1.0和评测用 2.0两个状态。评测过程中发现的测试集问题记录在变更日志里但不直接改 2.0 文档等第一轮评测跑完统一修订成 3.0。这样做的好处是每次评测的结论都可以追溯到当时的标准版本不会出现评测报告和标准文档对不上号的情况。另外场景定义阶段做的 schema 盘点在评测阶段的价值会再次体现。候选模型里如果有基于 schema 理解做优化的盘点的质量直接决定它能发挥几成功力。字段注释不全、同义词没有整理、口径说明遗漏这些都会变成准确率的隐形杀手。所以你在场景阶段多花两天把 schema 盘点做扎实后面评测会省下数周的时间。最后再补一句我对选型本质的理解选型不是找最好的模型而是找在给定场景和标准下最合适的方案。场景定义是把问题空间圈定下来标准设定是把评判尺度固定下来圈定和固定这两件事做扎实了选型就成功了一半。接下来第三篇的候选评测和第四篇的决策验证才有真正可执行的输入。如果你还在为选型头疼不妨先停下来把场景说明书写清楚、把标准数值定出来你会发现后面的路比想象中顺畅得多。
1. 为什么选型这么难Text2SQL 项目的第一道分水岭Text2SQL 这几年热度一直没降但真正落地的团队其实没有想象中那么多。我见过不少团队在选型阶段反复横跳今天拿开源模型微调明天换 API 试用折腾两三个月后还在原地打转。问题往往不在模型本身而在选型流程缺乏章法——需求没有拆清楚标准没有量化后面所有评估都是在凭感觉打分。这篇是 Text2SQL 系列的第 7 篇启动一个更贴近实际决策的话题4 步选型法。整套方法分成四步——场景定义、标准设定、候选评测、决策验证。按照系列的计划这篇先讲上半部分也就是前两步怎么把业务场景说清楚怎么把选型标准落成可衡量的指标。适合读这篇文章的人有三类正准备在企业内部落地 Text2SQL 的工程师或架构师、需要给团队做技术选型汇报的负责人、以及做 Text2SQL 产品规划的产品经理。如果你个人正处在Demo 看起来啥都能做一上真实数据就不行的阶段这篇尤其值得读完。先说我自己的判断Text2SQL 选型本质上是一个约束优化问题而不是一个模型比拼问题。同一个模型在内部报表场景和对外查询服务场景里的表现可能是天壤之别。你提前把场景和标准这两个变量钉死后面的评测才有意义钉不死评测做一百轮也选不出合适的结果。2. 先看全貌4 步选型法的整体逻辑2.1 四步到底在做什么4 步选型法是我在多个实际项目里反复调整后沉淀下来的框架每一步解决一个具体问题步骤核心问题主要产出场景定义这个系统到底给谁用、解决什么任务场景说明书、查询样例集、数据字典标准设定什么样的结果才算好用指标定义、权重表、基线阈值候选评测每个候选方案在标准下表现如何评测报告、对比矩阵、风险清单决策验证选出的方案在小范围试点里是否成立试点结论、回退预案、上线计划这篇只覆盖前两步。但我想先说清楚一件事为什么场景和标准必须先于评测。因为评测本身需要测试集测试集必须来自场景评测结果要用指标衡量指标必须来自标准。顺序反过来的话你很可能拿一个公开 benchmark 的测试集去测自己的业务数据测完发现模型分数很高但业务方根本不认。原因很简单——测试题不是他们日常会问的问题。2.2 顺序不能乱的原因我自己最早做选型时也犯过这个错。当时先拉了五六个候选模型然后急着跑 Spider 和 WikiSQL 这些公开数据集。结果最好的模型准确率有 85%团队很开心直接拿去接业务方的需求。结果业务方随手问了几个上个月华东区退货率超过 5% 的产品种类有哪些这种带约束条件的问题模型直接卡壳。回头看问题不是模型不行而是我跳过了场景定义。公开 benchmark 里的 schema 是干净的单表结构业务方的 schema 有几十张关联表、各种奇怪的字段命名、还有复杂的业务口径。两者根本不在一个世界里。场景定义先行的意义就是强迫你在拿模型之前先回答我的世界里到底有什么。2.3 场景和标准的关系场景和标准不是割裂的两个文档而是互相咬合的。场景描述决定了标准里哪些指标重要如果是内部报表场景可能准确率权重占 60%延迟权重占 20%如果是对外查询服务延迟和安全可能反过来占大头。标准也会反向约束场景描述——如果你发现某个查询类型在现有数据条件下根本没法写 SQL那这个场景要么砍掉要么降级为期望场景不能混在一起评级。我习惯用一个简单的数学关系来表达标准 场景的量化映射。场景里说的每一条需求最终都要能被至少一个指标覆盖。覆盖不到的地方要么场景描述不够具体要么标准设计有缺口。3. 第一步场景定义——把想用 Text2SQL翻译成具体需求3.1 四种典型场景画像场景定义的第一步是判断你的项目属于哪一类。我通常把 Text2SQL 的场景粗暴地分成四种内部报表辅助给业务分析师、运营人员用辅助他们从数据仓库里取数。特点是用户量大、问题模式相对稳定、对 schema 理解要求高。嵌入式自助查询集成在 SaaS 产品里让终端用户直接问自己的数据。特点是权限模型复杂、并发要求高、对错误结果的容忍度极低。数据分析工作台面向数据分析师支持探索式分析。特点是一次会话里可能连续问多个问题前后问题有依赖。决策支持问答面向管理层通常是预设问题模板加上少量自由问答。特点是问题数量少但价值高宁可不答也不能答错。每个场景对应的核心矛盾不同。内部报表辅助的核心矛盾是降低取数门槛嵌入式查询的核心矛盾是安全和准确的双重压力数据分析工作台的核心矛盾是上下文连续性决策支持问答的核心矛盾是错误代价。我建议你在场景定义阶段先把项目定性为这四类中的一类最多两类。如果四类都沾一点说明需求还没有收敛需要回到业务方去重新对齐边界。3.2 用户画像与查询模式盘点定性之后要做两件具体的事用户画像和查询模式盘点。用户画像不需要很复杂的模型只要能回答三个问题用户懂 SQL 吗懂到什么程度用户对数据口径熟悉吗他知道销售额在表里叫revenue还是total_amount吗用户期望的交互方式是什么是聊天框、是快捷键弹窗、还是报表页面上的搜索框这三个问题直接决定了你的 Text2SQL 系统要不要做同义词映射、要不要做字段推荐、要不要在生成 SQL 之外再加一层解释。查询模式盘点则需要收集真实的问题。我常用的方法是去业务方那里蹲点三天把他们在 IM、邮件、工单里问数据的问题全部抄下来。累计收集 100 条以上才能看到模式。比如你会发现 30% 的问题是XX 指标最近 N 天趋势20% 的问题是XX 和 YY 的对比这些模式会成为你测试集的主要构成。这里有一个实操心得收集问题时不要只记自然语言问句还要把提问背后的意图也标注清楚。同样的这个月卖得怎么样有人想要月环比有人想看品类排名有人想知道同比。意图不标注后面做评测时会发现测试集里标签打架模型怎么调都不对。3.3 数据与 Schema 复杂度盘点场景定义里最容易被忽视的是数据侧。很多团队把精力全花在问题收集上却忘了盘点数据本身。但 Text2SQL 是生成 SQLSQL 是跑在 schema 上的schema 复杂度直接决定任务难度。我建议做一张 schema 盘点表至少包含这些信息表数量是 10 张以内的简单 schema还是 200 张以上的企业级 schema。表间关联深度最常见的查询需要关联几张表。单表查询、两表 join、五表 join 的难度完全是三个等级。字段命名规范程度字段是 user_id 这种规范命名还是 f_1092_ab 这种带编码的命名。后者对模型非常不友好必须在场景定义阶段就标记出来。指标口径特殊性销售额是含税还是不含税、退款是否剔除、历史数据是否回溯修正。这些业务口径不会写在字段名里但必须出现在场景说明里。数据库方言是 MySQL、PostgreSQL、SQL Server 还是 ClickHouse。不同方言的语法差异会影响模型生成效果特别是分页、日期处理、窗口函数这些细节。做完盘点后你会得到一个非常清晰的结论schema 复杂度在你的项目里是低、中还是高。这个结论会直接影响后面标准的权重设计。如果 schema 复杂度很高但业务方要求的准确率又不能打折那你在选型时基本可以把纯 prompt 调用大模型这条路线先划掉因为它很难稳定处理复杂 schema 下的 join 和口径问题。3.4 场景定义的标准产出物场景阶段结束时应该有四样东西一份场景说明书描述给谁用、解决什么问题、预期使用频率、核心痛点和成功场景。一份查询样例集至少 50 条真实问题及其对应的标准 SQL按查询模式分组。一份 schema 盘点表表、字段、关联关系、口径、方言的完整清单。一份边界清单明确哪些问题不在本项目范围内比如不做多轮对话不做图表生成不做数据写入。边界清单特别重要。Text2SQL 项目最容易失控的地方就是需求边界无限扩张本来只做取数辅助做着做着变成要生成数据洞察报告。边界清单不是限制想象力而是保护项目在第一个迭代周期内能真正交付。4. 第二步选型标准设定——把好用翻译成可度量的指标4.1 准确率三种口径不能混用场景定义完成后就要开始设定标准。标准里第一个绕不开的指标是准确率但绝大多数团队在定义准确率时是含糊的。我见过不少评估报告直接写模型准确率 92%但细问之下92% 这个数字可能是执行结果一致率可能是字符串匹配率也可能只是人工抽样的主观判断。我建议把准确率拆成三个口径SQL 执行一致率生成的 SQL 能在目标数据库上无错执行且执行结果与标准 SQL 的结果集合一致。这是最严格的口径。SQL 语义等价率生成的 SQL 与标准 SQL 返回相同结果但 SQL 文本可能不同。这一般是执行一致率的上位替代因为执行一致率已经隐含语义等价。答案正确率最终呈现给用户的结果是正确的但 SQL 是否最优、是否浪费性能不纳入考量。三个口径对应不同的项目阶段。早期评测用答案正确率比较现实因为评估成本低但到了上线前的验收阶段必须至少达到 SQL 执行一致率 90% 以上否则业务方不会信任。这里需要补充一个容易被忽略的细节准确率必须按查询模式分层统计不能只看整体平均值。单表查询的准确率如果已经 95%而多表 join 的准确率只有 50%整体平均算下来可能还有 80%但这个 80% 毫无意义因为业务方高频使用恰恰是多表查询。我习惯在标准文档里直接写死分层口径单表查询准确率不低于 92%双表 join 不低于 85%三张及以上表 join 不低于 70%。4.2 覆盖率与鲁棒性准确率之外覆盖率和鲁棒性是两个经常被忽略但很重要的指标。覆盖率衡量的是系统能回答多少比例的用户问题。这里的定义容易让人迷惑——什么叫能回答我建议拆成两个层面问题覆盖率指的是系统不报错、不中断、给出结果的比例正确覆盖率指的是给出正确结果的比例。前一个反映系统的兜底能力后一个反映真正可用程度。通常来讲你至少要追求 95% 以上的问题覆盖率如果做不到大量用户会卡在对不起我没理解你的问题这类交互上。鲁棒性则更进阶一些。它衡量的是遇到没见过的问法、拼写错误、别名、口语化表达时系统还能不能正常工作。我常用的测法是把场景收集里的问题做变异把上个月改成上一月把GMV改成成交总金额把华东和江苏浙江上海混着用。变异后准确率的衰减幅度就是鲁棒性得分。衰减控制在 5 个百分点以内算合格超过 15 个百分点说明模型对表达多样性极度敏感需要重点调优。4.3 延迟、并发与成本Text2SQL 选型里最影响体验的是延迟。一个查询从用户说出问题到拿到结果我建议把目标定在 5 秒以内其中模型生成 SQL 的时间最好控制在 2 秒以内剩下的时间留给数据库执行和网络传输。超过 5 秒用户就会开始不耐烦尤其是内部工具很多业务分析师用了几次之后就会放弃回到找数据团队提工单的老路上。并发这里要区分两个环境POC 环境和生产环境。POC 环境并发很低单机跑模型测试没问题生产环境可能同时有 50 个用户发起查询这时候你就要算清楚推理引擎的吞吐量。如果候选方案是自建模型要提前压测如果是调用外部 API要确认限流策略和超时时间。成本不光是钱还有隐性成本。API 调用费是显性的但模型调优的时间、因为延迟过高导致的用户流失、因为错误查询导致的数据计算资源浪费这些都是隐性成本。我碰过一个团队把成本全部压在 API 调用次数上省了钱但准确率一直上不去业务方意见很大。后来换成自建模型加微调虽然显性成本上去了但准确率提升 15 个百分点业务方反而满意了。4.4 安全与权限不能事后补救Text2SQL 有一个独有的安全问题生成 SQL 的动态性。传统报表是提前写好的 SQL权限可以内置在报表逻辑里Text2SQL 是模型即时生成 SQL权限如果没有在生成阶段被约束用户完全可以用一句查一下所有用户的手机号把敏感数据拉出来。所以标准里必须包含权限约束检查生成的 SQL 只能访问当前用户权限范围内的表和字段。这个标准不能用人工抽检的方式验证要在评测阶段做自动化检查对每个测试用例的 SQL 做权限分析超出权限的就算失败。除了权限还要考虑查询安全性比如防止生成拖垮数据库的 SQL——没有 WHERE 条件的大表全表扫描、在超大表上做笛卡尔 join、递归 CTE 无限循环。这些在需求上不一定敏感但在运维上是要命的。选型标准里应该给这类危险 SQL单独设一个一票否决项。4.5 工程集成与定制能力最后是工程层面的标准虽然不是用户直接感知的指标但决定了后续的维护成本。工程集成的几个检查点候选方案是否支持现有的数据源类型比如 MySQL 和 ClickHouse 同时存在时能不能一套系统搞定。是否提供 API接入现有产品需要多少开发量。是否支持自定义 schema 的映射关系比如字段别名、同义词表、业务口径配置。是否支持热更新schema 变化后需要多长时间生效。是否支持反馈闭环用户对生成结果的点赞、点踩能不能收集并回流到调优流程。我处理过的最典型的一个案例是团队选了一个效果很不错的闭源 API 方案结果发现它不支持自定义 schema 映射只能把表结构描述塞到 prompt 里。业务方改了一个字段名整个系统就乱了。标准里如果没有提前验证定制能力这种坑迟早会踩到。关于标准设定还有一条我自己的经验要特别说明标准里每一项指标都最好有数值下限和权重而不是只有描述性的语句。准确率尽量高不是标准单表准确率不低于 92%才是标准。因为标准最终要被用来做对比评分没有数值下限就无法执行。5. 实操示例制造业客户分析场景的标准模型5.1 场景描述与用户画像为了把前两步串起来我举一个自己做过的真实案例。某制造业企业要做客户分析自助查询用户是销售运营团队大概有 80 人日常会用 Excel 处理从 CRM 和 ERP 导出的数据但不会写 SQL。他们高频想知道的问题有三类客户下单情况、区域销售对比、产品退货率。schema 盘点结果是 42 张表核心涉及 6 张表最常见的查询需要关联 3 到 4 张表。字段命名有一定规范但存在部分历史遗留字段用编码命名的情况。数据库是 SQL Server有比较特殊的日期处理和字符串函数语法。5.2 查询样例与测试集我们从业务方那边蹲点了两周收集了 130 条真实问题。清洗掉重复和模糊的问题后保留 86 条作为场景样例集。把这 86 条按查询模式分组结果是这样的查询模式数量涉及表数占比客户下单明细汇总382-3 表44%区域销售对比243 表28%产品退货率分析154 表17%其他临时取数91-2 表10%这组数据帮我们确定了一件事3 表 join 是测试集的核心难度基准4 表 join 是加分项。同时其他临时取数只有 10%说明业务方的主要需求是模式相对固定的三类问题我们可以把调优资源优先放在这三类上。5.3 标准权重设计与数值下限结合场景定义我们把标准设成了这样的权重表指标权重数值下限说明2-3 表查询准确率30%90%占比最高的查询模式4 表查询准确率15%75%难但必须可用问题覆盖率15%95%不能大面积报错首查询延迟P9510%5 秒内用户侧体验底线权限合规率15%100%一票否决不过关直接淘汰危险 SQL 拦截率10%100%防止拖垮数据库成本上限5%按预算折算单次查询成本不超 0.3 元权重设计有一个小心机准确率相关的权重一共 45%延迟 10%安全相关 25%工程成本 5%剩下 15% 的覆盖率。这个分配的核心逻辑是这个场景里准确率和安全是主要矛盾延迟和成本其次。如果换成对外查询服务场景延迟的权重要提到 25% 以上安全更可能要加到 35%。数值下限则是我们和业务方来回对了三轮才定下来的。一开始业务方说要 95% 准确率我们拿真实 schema 做了一次快速测试发现 4 表查询在当前技术条件下很难稳定达到 95%最后协商成2-3 表 90%、4 表 75%。这个妥协很重要因为标准不现实的话后面执行阶段要么疯狂调优导致周期失控要么标准被推翻重来。5.4 这个标准怎么用标准定完之后后面的评测就有了抓手。等候选方案进入第三步时我们会直接把这个场景样例集和权重表拿过来跑分。最终评分是加权得分加权得分最高的方案进入试点。同时标准里的权限合规率 100%会作为一票否决项任何方案在这个指标上不过关即使总分第一也会被直接淘汰。我把这套做法分享出来不是建议你照抄这些数字而是强调它的结构每个指标都有明确的度量方式、数值下限和权重并且这些数字都是从场景定义推导而来。你换一个业务场景数字可以变但推导链条不能断。6. 场景与标准定义阶段的五个典型问题6.1 测试集只有正向问题没有边界问题很多人收集查询样例时只收集业务方正常的问题比如上个月各区域的销售额是多少。但真正能拉开方案差距的往往是边界问题含退款吗灰色产品线和灰色颜色是不是同一个字段去年和今年同月份对比要排除春节影响吗。这些边界问题的收集很难靠蹲点拿到因为业务方自己也不会天天问。我的做法是把样例集分成两部分主集和边界集。主集来自真实收集边界集来自与业务方访谈时追问出来的极端需求以及我们基于 schema 盘点自己构造的问题。边界集不需要很多15 到 20 条就够了但每条都要标注清楚考察的是哪种能力。6.2 指标定义差不多导致评测结果不可复用准确率口径是重灾区。同一个准确率评测 A 用的是 SQL 执行一致率评测 B 用的是答案正确率两边调优出来的模型都没法对比。我建议在标准文档第一页就用加粗字把指标定义写死并且每个指标附一个判例说明。比如SQL 执行一致率生成的 SQL 在测试库执行后结果集与标准 SQL 执行结果集完全一致字段顺序、行序不要求完全一致但数据内容必须一致。这样不管谁来评测标准都是一个。6.3 忽略数据库方言对准确率的影响如果业务库用的是 ClickHouse你拿 MySQL 语法测试出来的准确率再高也没有意义。方言的影响在复杂的日期处理和时间函数上特别明显。我在一个项目里遇到过模型生成的 SQL 在 PostgreSQL 上跑得好好的换到 SQL Server 就报语法错误原因只是分页写法不同和limit关键字不兼容。选型标准里要加入目标方言适配度这一项至少在评测时所有测试用例都要在目标方言的数据库上执行。6.4 权限设计只在 PPT 上没有落实到评测很多企业的数据权限模型本身就复杂比如按组织层级、按客户归属、按产品线做数据隔离。Text2SQL 系统如果不在生成阶段约束权限至少要能在执行阶段做权限过滤。但我在不少评测报告里根本没看到权限相关的测试项。权限合规率必须被写进标准并且要用自动化手段检查人工抽检大概率会漏。做一个简单的权限检查器并不难解析 SQL 的 FROM 和 WHERE 条件再对照当前用户的数据权限矩阵就能跑出合规率。6.5 标准数值脱离真实场景定完就被推翻这是流程层面的问题。标准的数值下限如果定得过高或过低都会在执行阶段出问题。定得过高的典型表现是评测做了几轮没有任何方案能达到最后只能偷偷降标准整个流程的严肃性就没了。定得过低的典型表现是标准全过但上线后业务方不认可只能推翻重来。我建议在定标准之前先用一个最朴素的方案比如直接调 API 加上简单 prompt跑一轮预测试。预测试的目的不是选型而是探底当前技术能力在目标场景下的天花板在哪里。预测试结果出来后再和业务方一起定一个跳一跳够得着的目标值。这样既不会太乐观也不会太保守。7. 实战中的额外心得标准不是定完就不动了按 4 步选型法的设计场景和标准主要在上篇评测和决策在下篇。但我必须提醒你场景和标准在评测阶段往往是会迭代的。评测过程中你会发现有些测试用例本身有问题比如标准 SQL 写错了、问题语义有歧义、某个边界问题根本不重要。这些都需要回到标准和场景文档里去修正。我自己的经验是场景说明书和标准文档保持初版 1.0和评测用 2.0两个状态。评测过程中发现的测试集问题记录在变更日志里但不直接改 2.0 文档等第一轮评测跑完统一修订成 3.0。这样做的好处是每次评测的结论都可以追溯到当时的标准版本不会出现评测报告和标准文档对不上号的情况。另外场景定义阶段做的 schema 盘点在评测阶段的价值会再次体现。候选模型里如果有基于 schema 理解做优化的盘点的质量直接决定它能发挥几成功力。字段注释不全、同义词没有整理、口径说明遗漏这些都会变成准确率的隐形杀手。所以你在场景阶段多花两天把 schema 盘点做扎实后面评测会省下数周的时间。最后再补一句我对选型本质的理解选型不是找最好的模型而是找在给定场景和标准下最合适的方案。场景定义是把问题空间圈定下来标准设定是把评判尺度固定下来圈定和固定这两件事做扎实了选型就成功了一半。接下来第三篇的候选评测和第四篇的决策验证才有真正可执行的输入。如果你还在为选型头疼不妨先停下来把场景说明书写清楚、把标准数值定出来你会发现后面的路比想象中顺畅得多。
