在数据领域，智能问数是最火的话题之一。

同行交流的时候，我看到有两种实现路径，一种是直接上text-to-SQL，chat BI这些，认为大模型能力越来越强，可以让大模型自己去理解数据，处理数据，并给出答案。还有一种是踏踏实实的做数据标准，数据汇聚建模，数据治理，搭建语义层，然后上问数。

我认为这2种方式都有失偏颇。第一种方式，可用性很低，因为大模型总是会回答问题，即使它根本不知道这个问题的答案。业务部门很快就对你的问数准确性产生疑虑，对数据信心不足，就像我们不愿意相信百度搜索的结果一样，这是过一把瘾就死。第二种方式，建设周期太长，投资规模不小，没有决策者会愿意给你超过二年三年时间去做这个事，投入一个不能短期看到成果的技术能力。

那可平衡的方案是什么呢？以我的经验来看，即使数据治理的完成度不高，选择合适的工程路径还是可以做好智能问数的，然后短期见成效，运营起来之后成了活水，局面就简单多了。关键点在于：在存量脏表与模型之间插入隔离层，用上下文供给替代数据清洗，用可回归的评测替代准确率承诺。

这三句话不是口号，下面我一条一条拆开说。

一、先垫一层隔离层，别让大模型直接碰脏表

很多人把问数不准归结为模型还不够强。这个归因基本是错的。

我们这几年的存量表，压根就不是给人看的。一张订单明细表要关联七八张码表才读得懂：产品类型是数字 1042，渠道编码是 SH_PD_09，后面还得跟一句 sts_cd = 'A' AND is_test != 1——而这条”剔除测试号卡”的规则，可能只存在于几个干了好几年的老员工脑子里。

让大模型在用户提问后的几秒钟里推理出这套多表 Join 逻辑加隐式过滤条件，这不是模型能力问题，是任务设计问题。

有个很朴素的算术可以说明这件事。假设模型每一步推理的可靠率是 95%——这已经相当乐观了。一次查询要走 20 个推理步骤（选表、选字段、判断关联键、翻译码值、补全过滤条件……），最后整链可靠的概率是 0.95 的 20 次方，**约 36%**。就算单步做到 99%，20 步之后也只剩 82%。

你没法把单步从 95% 拉到 99.9%，但你可以把 20 步砍到 5 步。后者是你自己能决定的。

所以我们定了条架构原则：进到模型视野里的表，跨表关联数一律按 0 设计。

这不是拍脑袋。国外的一家数据领域的核心厂商（dbt Labs） 在 26 年 4 月发布了一个测试报告，里面有个数字：他们只让 AI 额外写了 3 个模型，让规范化的表连成能用的语义模型——人没写一行代码——模型裸写 SQL 的准确率从 64.5% 跳到了 84%~90%。作者的结论就一句：better modeling helps both approaches。而且，他还发现在这种模式下，主流大模型之间的最终差距极小，你大可以选择便宜的模型。

具体怎么做？不需要动底层跑了十年的 ETL 一根手指头，在现有的 MPP 引擎（我们用 StarRocks，Doris 同理）里单独开一个 ai_mart 库就行：

  1. 先只做 5~8 张宽表，别贪多。 挑一个天天排队提工单的场景切入——家宽与 5G 融合业务发展日报、政企专线月度经营跟踪，随便哪个。用异步物化视图把底下五六张明细表、维表预先关联好。
  2. 字段名说人话，码值直接展开成中文。 别让模型去猜 prod_type = 3 是什么，直接在宽表里落成 'FTTR全光组网'；区域编码落成 '浦东新区'。
  3. 潜规则焊死在视图的 WHERE 里。 剔除测试号、剔除内部免单账户、只取已归档状态——这些默认规则一旦写进视图，模型就再没机会犯错。

做完这一步，原本需要”跨表关联 + 隐性逻辑推理”的任务，被降维成了模型最擅长的单表聚合查询。

有几个坑要提前说清楚。

第一，ai_mart 不是数仓分层。 它不是 ADS 层，是纯粹的”AI 适配层”，随时可以推倒重来。不要把它纳入你的数仓规范去评审，否则光走流程就要两个月。

第二，宽表会把口径焊死。 业务规则一旦写进视图就不好改了。所以每张视图必须写清 owner、生效日期、变更记录，总数控制在十位数以内。否则你会从一个”几千张烂表”的坑，跳进”几百张没人敢删的视图”的坑。

二、不上重平台，也能做软治理

一提语义层，很多团队第一反应是”得买个几百万的指标平台”。起步阶段真不用。

存量表没注释、不知道里面躺着什么脏数据，怎么办？让 AI 自己去探。

一个不到 200 行的 Python 脚本就够，干三件事：

  • 拉目标宽表的 CREATE TABLE DDL；
  • 对每个文本型和枚举型字段自动跑一句 SELECT DISTINCT col LIMIT 20，把数据的真实长相采样出来。你会惊讶于”套餐名称”到底能有多少种写法；
  • 从老报表后台里扒出十几条查过这张表的历史 SQL，连同采样结果一起丢给大模型，让它逆向推断每个字段的业务中文名、常见枚举值、计算注意事项。

原本需要数据治理岗跟业务部门扯皮半个月的数据字典，模型十分钟能出一份八九不离十的初稿。这里推荐直接输出成 M-Schema（半结构化增强 Schema 表示，出自阿里的 XiYan-SQL 那套框架），比裸 DDL 信息密度高得多，也更适合塞进 Prompt。人工只需要花半天，像改卷子一样把错的地方划掉重填。

至于最头疼的业务黑话——融合率、移网出账、宽带净增、高价值离网，表里根本没有同名字段——维护一份结构化的 JSON 或 Markdown 词典就行，存进 Milvus，再配 Elasticsearch 做混合检索：

【词条】净增用户数
适用域：家庭宽带、5G 移动业务
标准公式：SUM(当期新增出账用户) - SUM(当期正式销户用户)
排雷提示：不要用 new_usr_cnt 字段，必须扣减当月拆机数；默认按自然月统计。

用户提问时先检索，把相关黑话的标准公式当”小抄”塞进 Prompt，同时在问数的时候也回显给用户，让他知道逻辑。今天发现一个口径偏了，改一行配置，下一秒生效——比指标平台发布周期快。

Datafold 的 CEO Gleb Mezhanskiy 有句判断我很认同：**”AI doesn’t care about data quality — it cares about context.”**（AI 不在乎你的数据质量，它在乎的是上下文。）

但这里有个坑：AI 生成的字典，很容易变成第二堆没人信的文档。我们的做法是强制保留来源——每条注释后面挂上”由 3 条历史 SQL 推断”或者”采样值 20 条中 17 条匹配”。业务评审的时候能对着原始证据改，而不是对着一段 AI 的自信陈述。

三、Golden SQL 只是开始，评测集才是关键

AI Agent 业内有个共识捷径：与其费尽心思想让模型理解范式，不如直接给它看标准答案。放在数据工程领域，这就是 Golden SQL。

去翻数据团队过去半年的取数工单、周报月报背后的固定脚本。你会发现业务 80% 的日常提问，其实绕着那 50~100 个核心问题打转，无非换个时间段、换个片区、换个套餐档位。

把这 50~100 条经过长期检验、口径绝对正确的 SQL 挑出来，配上对应问法（"查询各分公司上月千兆宽带渗透率排名" → 标准 SQL），灌进向量库。用户提问时先召回最相似的 3 条作为 Few-Shot 样本喂给模型，哪怕底层字段名再奇葩，它照猫画虎改一下 WHERE 里的日期和分公司，就能写出近乎完美的查询。

底座选型上，有研发能力的团队我推荐腾讯开源的 SuperSonic（ChatBI 和 Headless BI 结合得最透的一套），轻量起步可以用 Vanna 这类 RAG 框架自研。套路都一样，差别在你想投入多少人力。

但绝大多数团队漏掉了下一环：评测集。测试在软件工程领域是个很正常的事，但是在数据工程领域就很少见了。

Golden SQL 是给模型看的，评测集是给你自己看的。没有评测集，你换模型、改宽表、动词典的时候，根本不知道自己有没有改坏。这是弱治理环境下做问数最常见的死法——系统越用越差，但没人说得清是从哪天开始差的。

做法不复杂：

  • 攒 100200 条测试题（自然语言问题 + 期望 SQL 的关键结构 + 期望结果的量级，比如”行数应在 3040 之间，总额应在千万级”）；
  • 每次换模型、改宽表、动词典，跑一遍全量回归；
  • 看三个数：执行成功率（SQL 跑不跑得通）、结果一致率（和人工 SQL 的结果对不对得上）、Top-50 命中率（业务最高频的 50 个问题里，有多少能稳定答对）。

尤其别再拿”支持多少张表”当 KPI。 那个数字除了在汇报 PPT 上好看，只会把项目拖进”全覆盖”的泥潭。真正该盯的是 Top-50 命中率——它涨一个点，业务的体感就实打实好一分。

还有个便宜又好用的动作：让 Agent 把 SQL 真的跑一遍，再回头看结果。

Datafold 对”什么才算 agentic”下过一个很实用的定义——让 LLM 写 SQL、你复制去执行，这不叫 agentic；真正的分水岭是 agent 自己执行、自己看结果、自己迭代。落到问数场景，就是让它写完先跑一次，看返回的行数、空值率、量级是不是离谱，明显不对就自己改一版再跑。

代码量很小，但它把”生成”变成了”验证过的生成”。我的体感是，这比再堆十条 Few-Shot 样本都管用。

四、不要做黑盒，失败模式很重要

正如我开头说的，大模型总是会回答问题，即使它根本不知道答案。

这句话放在数据工程领域上有更精确的表达。

Text-to-SQL 失败时，给你一个看起来很合理、实际是错的数。
语义层失败时，告诉你”这题我不会”，然后什么都不返回。

在脏数据底子上，你唯一能确定的事就是它一定会错。所以真正该设计的不是准确率，而是失败模式。

准确率你控制不了，但”错了能不能被当场看见”你完全控制得了。

具体做两件事。

第一，置信度路由，分三档给结果。

  • 高置信：直接出图表；

  • 中置信：出图表，但强制附上”口径说明书”，用大白话把刚才执行的逻辑翻译出来——

    本次查询的是【2026年9月】【浦东分公司】的【政企专线新签合同额】，取自《政企经营月度宽表》，口径为已归档合同金额（含税），已自动剔除内部测试订单。

  • 低置信：不猜，直接反问，或者转人工工单。

白盒兜底的好处是：哪怕模型真把”实收金额”当成了”合同金额”，业务扫一眼这段话就能发现不对，顺手点个”口径重选”就纠正了，错误数据根本走不出对话框。

第二，命中模糊口径，严禁瞎猜，主动反问。

“上个月宽带用户有多少？”——背后可能是计费出账用户、期末在网用户、近 30 天活跃用户、终端在线用户，四个数差出十几万。这时候 Agent 绝不能自作主张挑一个算，而是弹一张轻量卡片：

您关注的”宽带用户”是指哪种口径？
[1. 计费出账用户（财务口径）] [2. 期末在网用户（业务口径）] [3. 近 30 天有流量活跃用户]

把”开盲盒”变成”做选择题”。这不只是体验问题——它是把一个不可控的信任崩塌，变成一次可控的多轮对话。

数据从业者最担心的不是AI 不会写 SQL，而是错误或幻觉的输出直接触达了业务方。行业卡点早就从能不能算出来转到敢不敢信了。

五、以用促治，活水不腐

前面讲的都是技术。但技术能不能活下去，取决于组织。

先说一个可能比前面四节加起来都管用的建议：别把项目叫”智能问数平台”，叫”取数工单削减专项”。

名字一改，KPI 跟着就清楚了——不看”准确率有没有到 95%”，看三个数：月均取数工单量、平均取数耗时、自助查询占比。 这三个数是业务和你一起扛的，不是你单方面承诺的。

落地节奏上，我们是这么跑的：

1）找 20 个种子用户，但别都找最配合的，找一些最爱吐槽的。 愿意骂你的业务，才会给你最真实的 Bad Case。

2）每天下班前半小时，雷打不动看后台的点踩清单，分三类归因：

  • 黑话没识别 → 5 分钟补进词典，明天就对；
  • 新维度组合写错 → 10 分钟改 SQL，一键加进 Golden 库；
  • 底层压根没这个字段，或者两个部门口径在打架 → 记下来，这是宝贝。

3）第三类清单，是治理项目唯一好用的弹药。 把”高管和业务高频提问失败清单”摆到跨部门例会上：*”不是 AI 不行，是 A 系统和 B 系统的客户标签没打通，所以张总问的政企融合转化率算不出来。”*

这一句话的杀伤力，超过数据部门过去三年所有的治理宣讲。因为现在不是你在求业务配合治理，是业务在催你打通数据。

这就是”以用促治”真正的地基：需求终于由真正的部门提出来了。

等某个指标被高频问过上百次、口径在反复碰撞里彻底对齐了，再顺理成章固化进 SuperSonic 这类统一语义层和企业级指标平台。先有高频使用，才有资格谈标准化——顺序反了，标准就是纸。

最后一句架构建议：把它做成 MCP Server，而不是做成一个”我们的 AI 助手”。

2026 年一个已经很清晰的模式叫 BYOA。正确姿势就是把能力通过 API/MCP 暴露出去，让业务手里的 Agent、企微机器人来调你，而不是逼业务再开一个新窗口。

你攒的字典、Golden SQL、口径说明，锁在对话框里只是资产，暴露成 MCP 才是能力。

六、三个最容易翻车的坑

说了这么多好话，也得说说什么时候会崩。

坑一：权限。这是唯一能让你一夜下线的。

传统 BI 是”人–>报表”授权，问数是”人–>任意 SQL”，原来的权限模型被整个绕过去了。

先看个前车之鉴。2025 年 7 月，Replit 的 AI coding agent 在代码冻结期间删掉了公司的生产数据库，还伪造了 4000 条假用户记录。事后复盘有两句话被反复引用：

It had all the capabilities it needed to be helpful. It lacked the context and the guardrails to be safe.

还有一句更扎心的：**”The code freeze was a verbal instruction, not a technical control.”**（代码冻结只是一句口头要求，不是一个技术控制。）

落到操作上，必须做到：只读账号、行级权限下推到引擎（StarRocks/Doris 的 row policy，或者直接在 ai_mart 视图里带租户字段）、敏感字段脱敏、超时与限流、全量 SQL 审计留痕。

再强调一句：你的安全边界必须是技术控制，不能是”我跟业务说过别乱查”。 这件事没有”二期再说”。

坑二：宽表把口径焊死了。（这条第一节提过，不重复。）

坑三：覆盖率幻觉。

业务尝到甜头后，第一反应一定是”把所有表都接进来”。这时候必须顶住，实行准入制：新表进 ai_mart，四件套齐全才收——owner、字段字典、至少 5 条 Golden SQL、至少 10 条评测题。缺一件，不接。

太多项目死在这上面：覆盖率从 8 张表冲到 80 张，准确率从 80% 掉到 50%，业务骂了一周，从此再不用。

最后

如果你的业务域满足两个条件——取数需求集中在可枚举的高频问题上，且存在能预关联的核心宽表——那么两三个人、两到四周，就足够在一个垂直域里把 MVP 跑通。模型直接复用内部已经部署的接口，硬件和软件投入几乎可以忽略。

执行顺序我建议固定死：选定一个业务域 → 产出 5~8 张宽表 → 逆向生成字典和黑话词典 → 抽 50 条 Golden SQL → 构造 100 条评测题 → 接上置信度路由再放量。

最后一条：评测题没准备好之前，不要扩大接入范围。

我知道很多团队心里想的是”先做大全、再做准”。在我趟过的项目里，这个顺序从来没成功过。反过来，先用最低成本让一小部分高价值数据”能问、敢用、真的好用”，再借着业务用数的惯性把治理的硬骨头一块一块啃下来——这才是存量企业里真正走得通的那条路。