自助取数 text-to-SQL

1客户嘴上要的

「业务每天找数据团队要数，排队要 3 天。做个 text-to-SQL，业务用中文提问，系统自动查数据库。」

这是症状或现成方案，不一定是真问题。下面看两种做法。

2照字面做，会怎么烂

3好 FDE 的实际走法

共 6 周，分 5 个阶段。带三角标记的是这一步最容易踩的坑。

1. 1

   第 1 周找真问题（看取数需求单）

   • 跟数据团队负责人、2 个数据分析师，以及销售运营、财务的 2 个经常取数的人坐，导出近 3 个月 450 个取数需求。发现：70% 的需求集中在 30 个指标上；而「销售额」有 5 种口径——含税或不含税、按下单还是按发货、是否扣退货、是否含渠道返利。
   • 分析师说，写 SQL 只要 10 分钟，花时间的是和业务确认口径。
   • 真问题是「指标口径不统一」，不是「不会写 SQL」。成功标准改成：「在 30 个核心指标上，系统结果和数据团队手工结果一致率 100%；每个结果附口径说明；这类需求从排队 3 天变成自助 5 分钟。」
   • 踩坑别让模型直接面对几百张原始表。表越多，生成错误 SQL 的概率越高，而且错得看不出来。
2. 2

   第 2 周先建指标层

   • 和数据团队、财务一起，把 30 个核心指标逐个定义：计算公式、口径、可用维度（时间、区域、产品线、渠道）、数据来源表。口径冲突的由财务和销售运营的负责人裁决。
   • 把定义写进 BI 工具的语义层或指标平台，生成 SQL 只基于这一层，不直接访问原始表。
   • 权限：按员工的数据权限过滤，例如区域经理只能看本区域。
   • 踩坑口径裁决不能由数据团队独自决定。数据团队定了，业务不认，还是会吵。
3. 3–4

   第 3–4 周原型 + evals

   • 做查询入口：业务用中文提问，系统先识别指标、维度、时间范围，回显成一句话（「按发货口径、不含税、2026 年 10 月、华东区的销售额」），用户确认后再查。问到未定义的指标时，说明「暂不支持」并转数据团队。
   • evals：从 450 个历史需求中选 150 个，由分析师给出标准结果。要求结果完全一致；对「问法模糊」的问题，系统必须追问而不是猜。
   • 踩坑时间表达很容易错，例如「上个月」「本财年」「近 30 天」。财年起始月份要做成配置。
4. 5

   第 5 周Demo + 并肩改

   • 让销售运营本人提问。反馈：「回显口径很有用，我原来都不知道有两种销售额」。另一条反馈：想要同比和环比——加进维度计算。
5. 6

   第 6 周交接交接

   • 交给数据团队的一位数据产品经理：新增指标先定义、再上线，每月跑一次 evals；把「暂不支持」的问题汇总，作为新增指标的候选。
   • 没有这个人管指标层，业务会要求开放原始表，系统又回到第一周的问题。

4这个案例教给你的可复用判断