企业级ChatBI项目为何频频卡在试点阶段？本文从分析师、数仓工程师、管理者三重视角，拆解问数项目的真实困境与破局路径。

本文从多视角深度解析企业级别智能问数 ChatBI 项目的执行路径，分三条线：

1. 分析师看第四部分 — “AI能不能替代我？我的价值在哪？”
2. 数仓工程师看第二部分 — “三种技术方案怎么选？实施难点在哪？”
3. 企业管理者可以从头看起，也可以看第三部分 — “ROI如何？风险可控吗？”

全文也可以从头读，但如果时间有限，各取所需。

问问大家：你的问数项目还推得动吗？

有没有觉得很割裂：市场上热火朝天，这个大厂又出工具了，那个大厂又出技能了，但是你们公司的问数还是用不起来？今天我们唠唠这个事儿，看看到底是什么原因，怎么解决。

现在市场上通用的问数项目情况卡在这里：

推了半年，卡在试点阶段

某行业头部企业，有数仓、有BI、没有指标平台。高管对AI很热情，想在数据应用上搞个大动作。

他们选了问数。逻辑很简单：ChatGPT让自然语言交互火了，那数据查询也可以用自然语言。让业务人员自己问系统，不用等分析师拉数，听起来很美。

半年后，项目卡住了。两个死结：

第一，无法评估效果。

NL2SQL生成的查询结果，准确率是70%还是95%？没有一个客观的标尺。业务部门问：“你的系统查出来的数，我能信吗？” 数据团队给不出答案。

第二，数据撑不住。

按理说，有数仓、有BI，数据基础不算差。但NL2SQL对数据质量的要求远高于看板，看板展示的是预制好的指标，SQL是手写校验过的；NL2SQL要靠AI自己理解字段关系、处理空值、应对口径不一致。一个字段的命名歧义，就能让整个查询结果跑偏。

项目最终停在”试点阶段”，成了PPT里的一页。

或者 部分聪明的企业是这么做的：

B：只做了财务现金库问数，上线3个月稳定运行

同样是问数，另一家企业做的财务现金库问数，3个月上线，现在稳定运行。

场景： 财务部门的紧急查数需求：“昨天华东区的现金流入是多少？”“上周应收账款回款率是多少？”

方案： NL to API（不是NL2SQL）

效果：

• 覆盖15个核心财务指标
• 意图识别准确率95%+
• 平均响应时间 < 3秒
• 财务紧急查数从平均1小时降到实时

他们区别在哪？

不是技术能力的区别，是有没有想清楚为什么做、给谁做、怎么做。

项目A想做”通用问数”——什么都能问，什么都能答。结果是什么都做不好。

项目B找到了”明确场景”——财务现金库，紧急+边缘+实时，有需求、有边界、能验收。

问数不是做不做的问题，是怎么做的问题。什么都想要，就会什么都得不到 。

那么具体要怎么做？

第一：找到明确场景（有需求、有边界、能验收）

什么是”明确场景”？

四个特征：

1. 有真实需求 ： 不是”感觉可能有用”，是”每天都在发生的痛点”
2. 有清晰边界 ： 不是”什么都能问”，是”这15个指标能问”
3. 能客观验收 ： 不是”感觉还行”，是”准确率95%、响应时间<3秒”
4. 高频且固定 ： 不是”偶尔问一次”，是”每天问10次、问法相对固定”

第一步选择什么场景：取决于企业的现状

比如 B 企业为什么选择财务现金库问数？

团队分析了企业内部的查数场景，最后选了财务现金库。原因有三：

原因1：数字化基础不够，做不了大宽表

这家企业的财务数字化经历了多次迭代和重构，烟囱情况严重。不同系统、不同口径、不同时间粒度的数据散落在各处。

要做大宽表，首先要把这些数据统一口径、统一清洗、统一入仓。这个工作量，比做问数本身还大。

原因2：追求实时性，数仓做不了

财务现金库的查询，追求实时性——”昨天的现金流入”要能马上查到，不能等T+1。

但企业没有实时数仓，只有离线数仓。数仓每天凌晨跑批，白天查的是昨天的数据。

我们的方案是直接对接财务系统的API，绕过数仓，实时查询。

原因3：准确性要求极高，NL2SQL风险大

财务数据的准确性要求极高，错一个小数点，可能影响决策。

NL2SQL的问题在于：即使温度设为0，多层链路也会导致结果不稳定。意图理解层可能理解偏、SQL生成层可能写错、执行层可能超时重试。

我们用NL to API的方案：自然语言→意图识别→调用预定义API。API里的查询逻辑是人工写好并验证过的，不会出错。

对比：营销场景适合用大宽表+NL2SQL

不是所有场景都适合这个方案。比如营销场景就不同：

不同场景用不同方案，这需要判断力还需要有决策力，很多公司都卡在这里。

第二：分析场景特征，制定技术方案

那么怎么样找到适合的方案呢？ 我们要先知道有什么方案吧：

问数的三种技术路线

如果一定要做问数，有三种技术路线。我按”理想→现实→入门”的顺序讲。

方案一：Agent + RAG 五层架构（理想形态）

用户问题（自然语言）

↓

[层1] 意图理解层：拆解用户问题为子任务

↓

[层2] 知识检索层（RAG）：检索数据字典、表结构、业务规则

↓

[层3] SQL生成层：基于检索到的上下文生成SQL

↓

[层4] 执行层：执行SQL，错误时自动重试或修正

↓

[层5] 结果解释层：把查询结果用自然语言解释给用户

优势： 灵活性最高，理论上什么都能查

致命劣势：

• 准确性最难保证：五层链路，每一层都可能出错，温度问题被层层放大
• 成本最高：每次查询要调用多次LLM
• 结果不稳定：同一个问题两次查询可能得到不同的答案

我们的实战结论： 除非有极其特殊的场景和充足的资源，否则不推荐。

推荐度：⭐⭐（低）

方案二：指标平台 + NL2API

用户问题（自然语言）

↓

意图识别（匹配预定义的指标）

↓

调用对应的API

↓

API执行预定义的查询逻辑

↓

返回结果

核心思路： 不生成SQL，只做意图识别→API映射。前提是有成熟的API接口（或者指标平台）。

优势：

• 准确率最高：API里的查询逻辑是人工预定义和验证过的，不会出错
• 可控性强：指标口径统一，不会产生歧义
• 温度问题被规避：只需要做意图识别，不需要生成SQL

劣势：

• 灵活性较差：只能查已定义的指标，无法做探索性分析
• 前期建设成本：需要先有API接口或指标平台

我们为什么选这个方案？

财务现金库的15个核心指标，财务系统本身就有API接口。我们不需要重新建指标平台，只需要：

1. 梳理这15个指标的查询参数（时间、地区、币种等）
2. 训练意图识别模型（识别用户问的是哪个指标、参数是什么）
3. 调用对应的API

实施经验：

• 意图识别模型用的是DeepSeek（本地部署），成本可控
• 15个指标的意图训练数据，我们人工标注了300条，准确率就达到95%+
• 整体开发周期3个月（包括需求对齐、开发、测试、上线）

推荐度：⭐⭐⭐⭐⭐（高，前提是有成熟的API接口）

方案三：预置宽表 + NL2SQL（入门选择，有坑）

用户问题（自然语言）

↓

意图识别（提取时间、地区、产品等维度）

↓

SQL生成（针对预置宽表，单表查询）

↓

执行查询

↓

返回结果

看起来最简单，实际上最容易被脏数据搞死。

优势：

• 查询速度快（宽表预计算）
• SQL生成逻辑相对简单（单表，不用JOIN）
• 技术实现门槛最低

劣势：

• 宽表维护成本被严重低估：每次加维度要重建表，字段变更需要同步
• 灵活性差：只能查预定义的维度组合
• 仍然有SQL生成错误的可能——单表查询一样会有温度问题

适合场景： 营销、运营等对准确性要求不极端、维度变化频繁的场景。

推荐度：⭐⭐⭐（中等——可以起步，但别以为它是终点）

怎么选工具：嘻嘻推荐的方案选择决策树

开始

↓

有成熟的API接口或指标平台？

├─ 是 → 用方案二（NL2API）【推荐】

└─ 否 → 继续

↓

数据基础好、能建大宽表？

├─ 是 → 用方案三（大宽表+NL2SQL）【可以试】

└─ 否 → 别做问数，先把数据基建补上

第三：确认节奏和验收边界（ROI怎么算）

问数最致命的死穴：效果评估

回到开篇那个企业的案例A。项目推了半年卡住，数据质量还可以 慢慢治理，有钱有人就行了，但效果评估才是真正的死穴。

NL2SQL的准确率怎么算？跑100条测试SQL，70条结果正确，准确率就是70%。但真实用户不是跑测试集。他问了一个问题，得到结果，然后产生了两个新的问题：

1. “这个结果对吗？”
2. “不对的话，我为什么要用你？”

问数不像异常检测、预测分析，它没有一个客观的“对错”，它取决于使用数据的人在他面对的问题场景中，想怎么看数据。

评估不了→业务不验收→ROI算不出来→项目停在PPT里。

正常的验收方法

研发团队和财务部门提前确定了明确的验收指标，比如以下三个：

关键：提前定好标准，用数据说话。

ROI怎么算

ROI = 收益 / 成本 = 150人天 / (3个月×2人) ≈ 25倍

实施节奏：一步步来，别一步到位

我们的实施节奏：

第1个月： 验证可行性（选3个最高频指标，做POC）

第2个月： 扩展到10个指标，小范围试用

第3个月： 扩展到15个指标，正式上线

不要一开始就做“通用问数”，先找最明确的场景验证。

第四：问数只是工具，分析师的价值在于脑子

AI出工具，我们出脑子

很多人担心：问数做好了，分析师是不是就没用了？

恰恰相反。

问数解决的是”脏活”：重复性的查数工作。这部分工作本来就不是分析师的核心价值。

分析师真正值钱的，是脑子。

分析师的核心价值链

• 异常洞察
• ↓
• AI辅助诊断
• ↓
• 主动分析报告
• ↓
• AI给出建议
• ↓
• 解决方案建议
• ↓
• 智能归因
• 举个例子：

场景： 华东区上周销售额异常下降15%

如果只有问数：

• 业务问：“华东区上周销售额是多少？”
• 系统答：“下降了15%”
• 然后呢？业务不知道为什么，也不知道怎么办

如果有分析师+AI工具：

1. 异常洞察 ： 分析师发现异常（或者AI异常检测系统发现）
2. AI辅助诊断 ：AI帮忙拉取相关数据（各产品线、各渠道、各时间段）
3. 分析师判断： 发现是某个重点产品线的问题，结合业务经验判断可能是竞品促销
4. AI给出建议 ：基于历史数据，AI建议调整定价策略
5. 分析师决策： 结合当前库存、利润率、市场策略，给出最终方案
6. 智能归因： 事后验证，沉淀为经验

AI能做什么？ 快速拉数、模式识别、给出初步建议

AI不能做什么？ 理解复杂的业务上下文、做最终决策、承担责任

AI vs 高级分析师的能力对比

结论：目前的AI，不能替换高级的策略型分析师。

能被替换的，只是那些”纯查数”的初级工作。而我们要做的，恰好确实借助工具提升能力，而不是让工具帮你干完活儿，而我还是之前的我。

给分析师的建议

如果你是分析师，不要怕AI：

1. 用AI解放自己 — 把重复性查数工作交给工具，把时间花在更有价值的分析上
2. 提升业务理解 — AI理解不了的业务上下文，是你的护城河
3. 培养分析直觉 — 多次解决问题积累的直觉，是AI学不会的
4. 学会用AI工具 — 不是被AI替代，是用AI增强自己

问数是工具，你的脑子才是核心竞争力。

总结：问数的正确打开方式

回到文章开头的问题：问数到底能不能做？

答案是：能做，但不是随便做。

问数成功的四个前提

1. 找到明确场景 — 有需求、有边界、能验收，不要追求”通用问数”
2. 选对技术方案 — 根据场景特征选方案，不要迷信某一种技术
3. 定好验收标准 — 提前确定准确率、响应时间、满意度等指标
4. 一步步来 — 从 2-3个指标做起，验证可行性，再扩展

嘻嘻的个人想法

对于分析师来说：

不要怕AI，用AI解放自己。把时间花在业务理解和分析直觉上，那是AI学不会的。

对于数仓工程师来说：

技术方案没有绝对的对错。有API就用NL2API，能建宽表就用NL2SQL，别追求完美。

对于企业管理者来说：

别被”通用问数”的PPT忽悠。先找一个明确场景验证，ROI算得出来再扩展。