企业级 AI 数据助理落地:一份 Step by Step 的实操指南

企业级 AI 数据助理落地：一份 Step by Step 的实操指南

智能问数，也就是所谓的企业级 AI 数据助理，自大模型出现以来技术路线一直在快速演进。

从早期的 RAG 驱动 Text to SQL，到 Agentic 自主探索数据取数，中间穿插了一段模型微调的热度，再到最近半年学术界和工业界都在向“多 agent 流水线 + 指标语义层”这条路收敛。

但不管技术怎么变，有一点是不变的：

智能问数不是 AI 项目，是数据治理项目。AI 只是挂在上面的一个入口。

这篇文章在以下情况下能帮你解决问题，至少有所启发：

你真心想用智能问数给组织赋能，让业务方能自助取数、让数据团队从无穷无尽的提数需求里解放出来
你手上有一定的决策权或影响力，能推动数据治理、指标口径、权限体系这些脏活累活的落地
你愿意接受这是一个长期工程，能容忍前期投入大、见效慢的节奏。

在以下情况下，这篇文章帮不了你，或者说没必要看：

领导拍脑袋让你硬上，你没决策权也调动不了多方资源
项目本身就是个面子工程，能演示就行，落地后没人用也无所谓
不想投入，指望靠一个大模型加几张表就端到端解决问题

虽然后者更多，但我还是希望这篇文章对前者能有所帮助。

如果有兴趣，可以加入我的知识星球星球一起探讨学习。以下是20张优惠券码，先到先得。

Step 1：先想清楚这玩意是给谁用的

很多客户做 AI 数据助理，愿景是让全公司任何一个人都能用一句话问到数据。

听上去就太大而全了。

仔细想想，每类人的需求其实完全不一样。

老板和领导层并不直接看明细数据，他们看的是看板和报告，每天从摘要好的数据中获得决策灵感。这个场景很容易把项目带偏，演示 Demo 时领导突然说能不能直接输出一整个 Dashboard，这个功能其实和 AI 没什么关系，但很容易让整个项目走向失控。

一线业务员工绝大部分的问数据，本质上是想要月报、周报这种固定动作，或者临时查一个指标。他们 80% 的 query 集中在那 20% 的库表和指标上，非常符合二八原则。

真正每天有大量、随机、新需求的，是一线数据分析师。

所以那些成功落地数据助理的客户，一开始就把产品定位成分析师辅助工具。

听上去这个立意比全员 AI 数据转型差很多，但定位准了之后，下面所有决策都顺：

分析师懂 SQL，所以可以把生成的 SQL 暴露出来让他们自己判断
分析师能接受不那么自然的输入方式，比如手动选指标、选维度
分析师能容忍偶尔出错，因为他们自己也会写错 SQL
分析师对产品逻辑的理解速度，比非技术背景的人快得多。

本质上就是：懂相关逻辑的人，对产品的容忍度比不懂的人高得多。

参考一下 Coding Agent，程序员的上手程度和容忍度，明显比非技术人员高。虽然现在有不少产品经理、业务人员用 Coding Agent 工作的案例，但这里有严重的幸存者偏差，沉默的大多数只是用了一次觉得不好用，就再也不打开了，他们不发声而已。

回到我们这个话题，如果定位是“让全员都能问数据”，某个同事第一次问得不对，被错误结果坑了一次，他就再也不会打开第二次。

整体使用率会断崖式下降，更别说提出有价值的反馈，大家的反馈大概率只剩这东西太不好用了花那么多钱就做了个废物。

这个信任问题一旦出现，几乎不可能修补。

所以这一步必须想清楚三件事：明确的用户画像、明确的使用场景、明确的失败可接受度。

最好的方式不是上来就画一个大而全的愿景，而是从一个小场景切入，做精做透，再逐步扩展。这一步没想清楚就直接进 Step 2，后面全是返工。

Step 2：先把主路径定下来，Text to Metrics 还是 Text to SQL？

在讲数据治理、Schema Linking、Agent 架构这些技术细节之前，必须先把一件事挑明，否则后面所有讨论都会糊在一起。

智能问数其实有两条技术路线：Text to Metrics 和 Text to SQL。

业界经常把这两件事混着谈，但它们的可靠性逻辑完全不同。

Text to Metrics 的本质是：把可信的查询提前固化下来，AI 只做意图理解和参数填充。可靠性来自离线已经做过的工作，指标定义、口径确认、SQL 验证。AI 在这一层犯错的空间被压到很小，因为它不需要理解 schema，只需要从一个有限的、治理好的指标空间里选。

Text to SQL 的本质是：让 AI 现场从 schema 推理出查询。可靠性完全依赖在线推理，schema linking 准不准、字段语义猜得对不对、JOIN 逻辑通不通。每一步都有出错概率，错误还会累积。

这两件事在可靠性上根本不是一个量级。能用 Metrics 解决的问题去用 SQL 解决，等于把一个已经验证过的确定性问题重新降级成概率问题，这是反向的。

所以正确的架构不是二选一，而是分层兜底：

高频、高确定性的 80% 查询走 Text to Metrics，可靠性接近 100%，业务方能放心用
长尾、低频、临时的 20% 查询走 Text to SQL，可靠性 80% 也能接受，因为这一层的用户主要是分析师，他们看得懂 SQL、能容忍出错

这样可靠性预算就分配清楚了。Step 1 里说的二八原则在这里又出现了一次：80% 的查询集中在 20% 的库表指标上，这 20% 应该全部被治理成 Metrics，剩下真正长尾的需求才让 AI 裸写 SQL。

整个智能问数项目的核心工作，本质上就是不断扩大 Text to Metrics 能覆盖的范围，压缩 Text to SQL 需要兜底的长尾。

下面所有 Step 都是围绕这个主从关系展开的：Step 3 讲怎么把 Metrics 层建起来（数据治理 + 语义层），Step 4 讲长尾兜底的 Text to SQL 怎么做 Schema Linking，Step 5 讲什么时候该用 Agent，Step 6 讲 AI 输出层怎么收口到 Metrics，Step 7 讲兜底和安全。

把这条主线想清楚，下面的内容才有意义。

Step 3：数据治理 + 语义层（占 70% 工作量）

无论是前沿论文还是工业界落地，所谓 AI 数据助理的挑战，绝大多数其实是数据本身的问题：

表之间关系复杂、缺乏维护。
字段命名晦涩、取值有歧义。
同一概念跨系统编码不一致。
业务术语在不同部门含义不同。
大表里夹杂脏数据。
领域特殊 schema，外人看不懂。

这些没有一个是模型能解决的。再贵的模型、再牛的 agent 框架，碰到 status_code = 3 也猜不出来这是已发货还是已退款。

这一步既是给人看的文档，也是给 AI 检索的知识库，人和 AI 顺带都受益。要做的事情可以归成四类，老生常谈但还是要梳理一遍。

一、元数据与字段语义

很恶心的字段，比如叫 a1、f_amt_1、status_code 的，必须重新标注业务别名，写清楚字段含义、单位、取值范围、枚举值的业务解释。

最常见的例子：status = 3 到底是已发货还是已退款？业务方清楚，但数据库 schema 里没写，AI 肯定搞不懂。

这一点不要说做 AI，只要是做最基础的数据治理，这一步都逃不过。

二、表关系与跨系统编码对齐

表与表之间的关联关系必须显式画出来：主键、外键、JOIN 条件、关联粒度。很多老库的 ER 图早就没人维护了，得花时间重新梳理。

跨系统编码对齐是这里最容易踩坑的地方。客户在 CRM 里是 cust_id，订单系统里是 customer_no，会员系统里是 member_id，这三套编码必须有一张明确的映射表。否则 AI 生成的 JOIN 跑出来的数字看着对，其实全是错的，这种错最可怕，因为没人会怀疑。

三、业务术语与同义词词典

这是最依赖业务方的一类，也是最容易吵起来的一类。包含三件事：

业务术语对照。 业务方嘴里的GMV净客单动销率复购，对应到哪几张表、哪几个字段，必须一条条对清楚。AI 不可能凭空知道你们公司的复购是按 30 天算还是按自然月算。

同义词与缩写映射。 销售部叫客户，市场部叫用户，运营部叫会员，CRM 里叫联系人，这四个词在你们公司可能指同一拨人，也可能指完全不同的四拨人。这种事只有业务方说了算。

实体消歧。 上海分公司是注册地在上海的法人实体，还是华东大区的上海片区？我们的产品是 SKU 粒度还是 SPU 粒度？高频实体都得有明确定义。

四、指标平台与公式化知识库（这是 Text to Metrics 的核心载体）

这是解决业务术语漂移的关键，也是后面 Text to Metrics 能不能跑起来的根基。每个核心指标必须在指标平台里有唯一定义，类似这样：

指标名：活跃用户
口径 v1（市场部）：过去 30 天打开过 App
口径 v2（运营部）：过去 7 天有下单或加购
口径 v3（财务部）：过去 90 天有过付费行为
默认口径：v1

AI 接到上个月活跃用户多少这种问题，先去指标平台查这个词的定义，明确口径之后再生成查询。检测到多个口径时要么按默认走，要么反问用户。

除了指标定义，公式库还得覆盖几类内容：

计算公式： 毛利率是 (营收−成本)/营收，还是要扣除某些一次性费用？同比是跟去年同月比，还是跟去年同期按周对齐比？每条公式都得有业务方签字确认。
业务规则常识： 拿工作日举例，金融机构后台部门按国家法定节假日筛除，但交易部门可能只算交易日。这些 AI 需要根据情况推导，没有显性知识告诉它，它就只能乱算。
时间口径： 最近一周是滚动 7 天还是自然周？本月是自然月还是财月？截至昨天包不包括今天凌晨的数据？
业务范围定义： 核心客户= 年消费额 ≥ 100 万且下单频次 ≥ 12 次且合作年限 ≥ 2 年。必须是规则化、可计算的，而不是一句那些重要的客户。

这也是为什么 Cube 这类语义指标平台越来越火，BI 工具里定义指标的功能越来越细致，它们本来就是干这个的。

怎么让 AI 用上这些知识

知识库建好之后，技术实现其实就是 RAG 那一套，对应学术界的 Additional Information Acquisition 和 Formulaic Knowledge：

双索引混合召回。 术语、公式、规则做两套索引：向量库负责语义相似度（用户说赚多少钱能匹配到毛利率公式），关键词倒排索引负责精确匹配（BRIC 国家必须命中 BRIC 这个缩写）。两套混合召回，效果比单用一套好得多。

检索结果作为 evidence 拼进 prompt。 用户提问进来后，先用一个小模型或 NER 抽出关键实体和指标名词，去两个索引里检索相关解释、公式、规则，作为 evidence 拼到 prompt 里。命中已治理指标的，直接走 Metrics 路径。

知识可信度分层。 业务方签字确认的标 A 级，从历史 SQL 里挖出来的标 B 级，AI 自己推断的标 C 级。检索时优先返 A 级，C 级只在没有更高级别命中时兜底，并且要在最终回答里明确提示此口径未经业务确认。

为什么这一步真的难

技术实现真的不难，难的是知识本身从哪来。

业务术语词典要业务负责人逐条确认，他没空。指标口径要财务、销售、运营三方对齐，他们对不齐，因为对齐了就意味着以后谁也不能私下改口径，每个部门 KPI 的解释权都会被收走。公式库要数据团队和业务团队一起维护，但数据团队人手永远不够，业务团队觉得这不是自己的活。

所以你会看到一个普遍现象：项目立项时大家都说配合，真到梳理指标时，会议一拖再拖，材料一改再改，掰扯不清。最后变成数据团队几个人闭门造车，造完业务方一句这不是我要的你们这个指标跟我们定义的不一样。

这一步本质上不是 AI 项目，是数据治理项目，更是组织协同项目。能不能把业务一号位拉进来站台，能不能让财务总监同意公开毛利口径，能不能让各事业部交出他们的私有定义，决定了这个项目的天花板。

预算和工期的 70% 花在这里，一点都不夸张。这一步做得好，后面的 Schema Linking、SQL 生成、结果校验都是顺水推舟。这一步糊弄过去，那就躺平交差、分锅甩锅得了。

Step 4：长尾兜底，Schema 怎么处理？

讲完 Metrics 主路径，下面进入 Text to SQL 长尾兜底层。

很多人以为大模型上下文窗口大了，可以把整个数据库的 schema 都塞进去让 AI 自己生成 SQL。我试过，效果稀烂。

原因和 Agent 为什么要做上下文工程一模一样：

第一，企业里随便一个数据库都是几百张表、上千个字段，全塞进去 token 成本爆炸不说，模型在那么大的上下文里找重点本来就费劲。

第二，无关的 schema 对模型是噪声。它看见 user_log 和 user_profile 两张表，可能会随便挑一张去 JOIN，结果完全错的。

所以 Schema Linking 必须做。 有三种思路：字符串匹配、神经网络分类、大模型抽取关键词再多阶段筛选。前两种精度不够，现在的主流路线是第三种。这里介绍两个有代表性的工作，分别代表两种范式。

范式 A：CHESS 的多阶段 Pipeline

CHESS 把 schema linking 拆成两个大阶段、若干小步骤，每一步都是独立的 LLM call。

第一阶段：实体与上下文检索。 先用大模型从用户问题里抽取关键词，然后兵分两路：一路去匹配数据库里的实体值（Entity Retrieval），找出可能涉及的具体取值。另一路去检索字段描述、注释、业务文档（Context Retrieval），找出语义相关的解释。这一阶段产出候选证据池。

第二阶段：三段式 Schema 筛选。 拿到候选证据后，做三步串联筛选，Column Filtering（粗筛字段）→ Table Selection（选表）→ Column Selection（精挑列）。每一步用不同 prompt 引导 LLM 做决策，从全库 schema 一路收敛到最终的 Selected Schema。

CHESS 的优点是流程清晰、每步职责单一、出问题好定位。缺点是 LLM 调用次数多，延迟和成本都不低。

范式 B：MAC-SQL 的 Selector Agent

MAC-SQL 走多智能体路线，schema linking 由专门的 Selector Agent 负责。它有两个值得借鉴的设计：

第一，按需触发。 Selector 不是每次都跑，只有当 schema prompt 长度超过阈值才启动。小 schema 直接整个塞进去反而比筛选更省 token，这是个非常务实的工程选择，避免为筛而筛。

第二，结构化输出协议。 Selector 的 prompt 写得非常严格：丢弃无关表。每张相关表里字段按相关度降序，只保留前 6 个。最终至少保留 3 张表。输出必须是 JSON。

输出长这样：

{
  account: keep_all,
  client: keep_all,
  loan: drop_all,
  district: [district_id, A11, A2]
}

keep_all 整张表保留，drop_all 整张丢掉，列出列名表示只保留这些列。这种结构化协议让结果可以被下游 agent 直接消费，不需要二次解析。

MAC-SQL 在 BIRD benchmark 上有一组消融实验数据特别值得看：去掉 Selector 后，简单查询的准确率完全没掉（65.73 → 65.73），但困难查询从 40.28 掉到 35.14。

这条数据印证了一个关键判断：Schema Linking 对简单查询基本没用，但对复杂查询（伴随大 schema、多表 JOIN）贡献显著。 所以 Selector 本身就该按需触发，而不是无脑全开。

具体落地时，把 Schema Linking 做成一个独立模块，输入是用户 Query 加全量 schema，外加 Step 3 里建好的字段语义、术语词典作为 evidence，输出是相关的表和字段子集加置信度。这个子集再拼到生成 SQL 的 prompt 里，不仅准，而且省 token。

最后强调一下边界：Schema Linking 再准，也只解决找哪些表哪些字段的问题，解决不了业务口径问题。 活跃用户该用哪张表，Selector 能选对，但活跃是 7 天还是 30 天，得靠 Step 3 的指标平台回答。两件事缺一不可。

Step 5：一定要用 Agent 吗？按复杂度分流

Agent 适合"需要多步骤、多工具、不确定后续路径"的任务，但企业内部问数里，符合这个画像的 query 不到两成。

回到 Step 1 的判断：大部分业务人员的 query 只和 20% 的库表与指标相关，长尾很少。但长尾不满足又会严重伤害信任。所以这一层的设计目标是用最低的开销覆盖最广的查询，把 Agent 的开销留给真正配得上的场景。

5.1 先做查询复杂度分流

判断查询复杂度可以用一个轻量分类器，或者直接让大模型判断一下。

先做一次完整的 Schema Linking（Step 4 那一步），看用户提出的query可能涉及多少张表、多少个列、有没有需要 JOIN 的关系。

涉及 1 张表、1-2 个列 → Easy
涉及 2-3 张表、需要 JOIN → Medium
涉及 4+ 张表、或需要中间结果 → Hard

这个判断最准，但代价是 Schema Linking 本身就要调一次 LLM。

学术界比较成熟的分类法是 DIN-SQL 提出的三档划分，我把它做了点本地化改造：

Easy 档（单表、单条件、聚合简单）："上个月销售额多少"、"哪个产品卖得最好"。

这一档应该优先走两条快路，

第一条是命中 Metrics 缓存或者历史 SQL 缓存，直接返回结果，连模型都不调。

第二条是 In-Context Learning + few-shot，给三五个例子让模型一次性生成 SQL。

Non-Nested Complex 档（多条件、多表 JOIN、聚合 + GROUP BY）：用 Decomposition + CoT。先让模型把问题拆成几个子问题，每个子问题对应一段 SQL 片段，最后拼起来。

MAC-SQL 里专门有一个 Decomposer Agent 干这个事，它会把"列出 SAT 优秀率超过平均水平的特许学校名"拆成两步：先算特许学校的平均 SAT 优秀率，再用这个值反查学校名。每一步都是更简单的 SQL，模型出错率显著下降。

Nested Complex 档（嵌套子查询、复杂业务逻辑、需要中间结果验证）：才考虑 Plan-and-Execute，先做完整计划，再顺序执行。这一档是真正应该上 Agent 的场景。

MAC-SQL 在 BIRD 上有一组消融数据印证了这个分流思路：去掉 Decomposer 后，简单查询准确率几乎不变，但困难查询掉了 5 个百分点以上。复杂度分流不是为了炫技，是因为简单查询根本不需要 Agent，复杂查询又必须有 Agent。

5.2 中间表示（IR）：让生成更稳定的小技巧

这是被很多落地团队忽略的一个杀手锏。直接让大模型生成 SQL，它要同时考虑 JOIN ON 子句、表别名、字段限定、GROUP BY 对齐等一堆东西，错一个地方整条 SQL 就废了。

学术界有一类工作专门解决这个问题：让模型先生成一个简化版的中间表示，再用一个确定性规则把 IR 翻译成可执行 SQL。代表性的有几种：

NatSQL：把 JOIN ON、FROM 子句这些 SQL 里"机械但容易出错"的部分省掉，让模型只关注业务语义。NL2SQL360 的实验数据显示，用 NatSQL 作为 IR，在带 JOIN 的查询上 EX 准确率从 69.1% 提到 76.7%。
QPL：把复杂 SQL 拆成 Scan、Filter、Aggregate、Join 这种关系代数算子序列，模型生成算子组合而不是裸 SQL。
SC-Prompt：先让模型生成 SQL 骨架（带占位符的结构），再填具体的列名和值，把"结构生成"和"内容生成"解耦。

如果你的 LLM 总是在 JOIN 和嵌套查询上栽跟头，引入一个轻量 IR 比换更大的模型见效更快。最简单的版本就是 Step 6 要讲的 Metrics 查询协议，本质上也是一种 IR。

5.3 什么时候真的需要多 Agent

只有当查询同时满足以下两个条件时，才值得上完整的 Agent 流水线：第一，需要跨多个数据源或多个工具。第二，路径无法预先规划，需要根据中间结果决定下一步。

一个典型场景是："上个月华东区销量异常下滑，帮我分析下原因。"这种问题需要 AI 先拉数据看趋势、再分维度下钻、再做归因，每一步都要看上一步的结果决定怎么走，这才是 Agent 真正发挥价值的地方。

但这类查询在企业内部占比可能不到 5%。为了这 5% 的需求把整套系统都做成 Agent，剩下 95% 的查询都被迫付出多次 LLM 调用的代价，这是最常见的过度工程。

Step 6：AI 的输出边界划在哪？——Text to Metrics 的具体设计

这一步是 Step 2 主从关系的具体落地。

6.1 让 AI 输出结构化的指标查询请求

不要让 AI 输出原始 SQL，而是输出一个结构化的指标查询请求，类似这样：

{
"metric": "活跃用户数",
"dimensions": ["地区", "产品线"],
"filters": {
"时间": {"op": "between", "value": ["2025-10-01", "2025-10-31"]},
"用户类型": {"op": "in", "value": ["付费用户", "试用用户"]}
  },
"time_grain": "day",
"order_by": [{"field": "活跃用户数", "direction": "desc"}],
"limit": 100
}

这个请求发到指标平台，由指标平台翻译成最终 SQL。这样做有三个核心好处：

第一，AI 犯错的空间被极大压缩。它不需要知道表名、字段名、JOIN 条件，只需要从一组已经定义好的指标和维度里选。即使它选错了维度，影响也是局部的，整条查询不会因为一个表别名写错就完全跑不通。

第二，业务口径被锁死。指标平台里"活跃用户"对应的 SQL 是 Step 3 已经验证过的版本，AI 不会自己写一个跟业务口径不一致的版本。换句话说，这一层把"AI 可能出错的部分"限制在了"理解用户意图"上，不包括"理解数据"。

第三，底层数据源可以解耦。指标平台后面接 MySQL、ClickHouse、Hive、PostgreSQL 都不重要，AI 永远只跟指标平台对话。这对多数据源的中大型企业非常关键。

6.2 协议怎么设计

这套结构化协议至少要覆盖五类要素：

指标（metric）：必填，从已注册的指标列表里选。这里要支持多指标查询（比如同时看 GMV 和订单数），但要限制数量上限，避免一次拉一百个指标把库压垮。

维度（dimensions）：可选，决定 GROUP BY 的字段。每个维度都要在指标平台里登记过它的取值范围、层级关系（比如"省 → 市 → 区"是一个层级树）。

过滤条件（filters）：可选，支持等值、范围、IN、LIKE 等几类常见操作符。值的部分如果是枚举类（比如"用户类型"），要校验是否在白名单里，避免 AI 编造一个不存在的值。

时间粒度（time_grain）：单独拎出来，因为时间是数据分析里最高频的维度，需要专门处理。day/week/month/quarter/year，每一个对应的逻辑都不一样（自然月 vs 财月、自然周 vs ISO 周）。

排序、聚合方式、Limit：避免一句"查所有"把库拉爆。

6.3 命中不了怎么办——优雅降级

不是所有问题都能映射到已有指标上。比如分析师问："给我看一下昨天那个新上的活动页面的 UV 来源分布"，如果"活动页面 UV 来源"还没被治理成指标，怎么办？

这时候不能直接报错"无法处理"，要走降级链：

第一层：在 Metrics 命中。直接返回，可靠性接近 100%。
第二层：在历史 SQL 缓存里找相似 query。从过去成功执行过的 SQL 里检索语义相近的，作为 few-shot 例子拼到 prompt 里，再让 AI 改写。
第三层：Text to SQL 兜底。走 Step 4 的 Schema Linking + LLM 生成 SQL 的路径，并且明确标注"这条 SQL 未经业务验证，请人工核对"。
第四层：明确告诉用户"这个问题超出系统能力范围，建议联系数据团队"，并把这条 query 记录到运营后台，提示治理团队"这是一个新的待治理指标候选"。

第四层这个反馈闭环非常重要。一个好的 Text to Metrics 系统应该具备自我进化能力，它知道自己不会什么，并且能把"不会的东西"反馈给治理团队去补齐。长期看，治理覆盖率会随着用户使用越用越高。

6.4 Cube、dbt Semantic Layer 这类工具的角色

Cube、dbt Semantic Layer、MetricFlow、Lookml 这些工具，本质都是在做指标平台这一层的工程化。它们提供的核心能力是：

用 YAML/DSL 定义指标、维度、连接关系
自动处理多数据源、缓存、聚合预计算
暴露 GraphQL/REST API，让上层应用（包括 AI）按结构化协议查询

如果你的公司还没有指标平台，强烈建议在做 AI 数据助理之前先把这一层搭起来。 不一定要用现成产品，但至少要有一套自研的"指标注册 + 查询编译 + 缓存"机制。否则 AI 这一层永远是空中楼阁。

Step 7：失败兜底和安全底线

到这一步技术上其实已经差不多了，剩下的是兜底。

投票机制。 两个模型（一个便宜的、一个贵的）各跑一遍，结果一致才执行，不一致让用户来选。听起来土，但能把幻觉率从 8% 压到 0.5%。原理就是用多次采样降低单次幻觉影响，代价是 token 多一倍，但企业内部场景这个钱花得起。

安全护栏。 最低限度要做这几件事：

只读账号。 AI 用的数据库账号必须只读，DDL 和 DML 权限全部砍掉。这是最便宜也最有效的一道防线，不要让 AI 跑出 DELETE 还执行。
SQL 白名单过滤。 生成的 SQL 过一遍 AST 解析，发现 DROP、DELETE、UPDATE、TRUNCATE 直接拒绝。
行数上限。 所有查询自动加 LIMIT，避免一句查所有用户把数据库拉爆。
敏感字段管控。 手机号、身份证、薪资这种字段，要么脱敏要么直接禁止查询。
审计日志。 每次查询记录谁、什么时间、问了什么、生成了什么 SQL、执行结果，方便事后追溯。

这层做完，最坏情况也就是查询错误，不会出数据事故。

上线前必须说的：评估

很多团队 PoC 时准备 50 条测试用例，跑出 90% 准确率就敢上线。

不行。

50 条覆盖不了真实场景。我现在做评估至少分三层：

第一层，benchmark 测试。 用 Spider、BIRD 这种公开数据集测基础能力，知道模型本身天花板在哪。这个准确率参考意义不大，但能排除明显不能用的方案。

第二层，业务样本测试。 跟每个业务部门要 50–100 条真实想问的问题，覆盖所有口径、部门、典型场景。这一关过了才能进 PoC。

第三层，灰度上线。 选一个你最熟最好说话的部门先上，看实际使用一周的准确率。这一步通常会比第二层掉 10–20 个百分点，因为真实用户的提问方式永远比你预想的奇怪。

NL2SQL360 这个工具其实挺好用，它把评估拆成了多个维度：SQL 复杂度、JOIN 数量、嵌套层数、域适应性、查询变体（同一个意思的不同问法）。如果项目有点规模，建议参考这个框架做自己的评估体系。

特别提一下查询变体，同一个问题用不同方式问，AI 能不能给出一致答案。这个在企业场景特别重要，因为不同部门对同一件事的表达差异巨大。PoC 阶段如果只测一种问法，上线立马露馅。

最后

写到这里大概能看出来：这 7 步里真正AI的部分其实只有 Step 4 和 Step 5，剩下 5 步全是产品定位、数据工程、运维安全。

这就是为什么我说智能问数不是 AI 项目。

到底有没有通用智能问数这种东西？写完这篇我大概有答案了，框架可以通用，内容必须定制。

Schema Linking、生成策略、投票机制、安全护栏，这些是框架层面的东西，可以做成通用产品。但语义层、指标定义、字段映射、业务口径，这些是每家公司独有的，没法搬。

所以那些号称开箱即用的企业 AI 数据助理，要么是定位特别窄（只做某个垂直行业的标准化场景），要么就是 PPT 产品，落不了地。

回到最开头那条主线：用治理把高频查询尽可能搬到 Text to Metrics 层，让 Text to SQL 只兜长尾。 这条路线想清楚了，剩下的都是工程问题。想不清楚，技术再花哨也救不回来。

我的知识星球：