为什么通用 AI 做不了真正的企业应用？从"幻觉"问题说起

行业洞察 · AI 落地实战

有一段时间，我们公司的销售团队在给政企客户演示智能问数产品时，经常会遇到同一类问题：

"我们其实自己也试过 ChatGPT，把报表截图发给它，让它帮我们分析数据。但它给的答案感觉……不太对，有时候数字会对不上，有时候分析的维度根本不是我们想要的。你们的产品和这个有什么本质区别？"

这个问题问得很好。答案不是"我们的模型更强"，而是我们解决的根本就不是同一个问题。

要说清楚这件事，得先聊一个大多数人对大模型有误解的地方——幻觉。

通用大模型，天生不适合"查数"这件事

很多人第一次用大模型处理数据时，都会有一个体验：它说的话听起来很有道理，格式规范，分析头头是道，但你拿着原始数据去对一对，经常发现数字对不上，或者结论和实际情况有出入。

这不是偶发的 bug，这是通用大模型在设计上的一个根本性局限，有个专门的术语叫"幻觉"（Hallucination）。

幻觉的本质是什么？大模型的工作方式，说到底是基于海量文本训练出来的"语言预测引擎"——它极其擅长生成听起来合理、逻辑自洽、格式正确的内容，但它并不天然具备"先确认这个事实是否为真，再开口"的能力。

当你问它一个它没有确切答案的问题，它不会说"我不知道"，它会生成一个看起来最合理的答案。

这对于写文案、做头脑风暴、辅助思考，问题不大。你能感知到那是"参考意见"，有偏差就调整。

但用它来查企业数据，就完全不一样了。

你让它告诉你"上个月华东区的销售完成率"，它没有你的数据库，但它知道这类问题"应该长什么样子"。它可能会给你一个听起来完全正常的数字，附带一句"较上月提升约 X 个百分点，整体趋势向好"——这段话是它编的，不是从你的数据里读出来的。

格式对，语气专业，但和你的真实业务数据毫无关系。

在 B 端，这种"编答案"的能力是灾难性的

在 C 端，大模型幻觉的代价相对有限。你用它写了一段朋友圈文案，它引了一句查不到出处的"名人名言"，顶多显得有点山寨，删了重写就好了。

但在企业场景里，AI 的输出从来不是拿来"看看"的，是拿来"用的"。

业务人员问数，是为了做决策；合规人员查文件，是为了出结论；管理层看报告，是为了调整策略。如果 AI 给出的是一个"听起来对但实际上是编的"答案，而下游的人没有去核实原始数据的习惯——这个错误就会安安静静地进入业务流程，在某个节点上造成真实损失。

更麻烦的是，AI 生成的内容通常格式规整、措辞专业，看起来比人写的还"靠谱"。这反而会让人在心理上降低核实的警觉性。

政企客户有一个近乎执念的需求，叫做"确定性"——同样的问题，必须得到同样的答案；系统说出来的数字，必须和数据库里的完全一致；出了问题，必须能追溯。

通用大模型的"概率性"和政企客户的"确定性"需求，是结构性的冲突。这不是哪个模型更好的问题，是设计逻辑根本不匹配的问题。

那智能问数产品，是怎么解决这个问题的？

核心逻辑是一个根本性的设计取舍：把大模型从"答案生成者"变成"问题翻译者"。

通用 AI 的工作方式是：你问一个问题，它从训练数据里"推断"出一个答案。

我们做的智能问数（NL2SQL 路线），工作方式完全不同：

你用自然语言提问，大模型的任务不是"回答"你，而是把你的问题翻译成一条 SQL 查询语句；这条 SQL 去客户自己的数据库里执行，把真实数据取回来；你看到的答案，是数据库返回的原始数据，而不是模型"推算"出来的结论。

这意味着什么？

数据库里有什么，产品就能回答什么。数据库里没有的，产品不会编一个答案出来，它会告诉你"没有找到相关数据"。

幻觉问题的根源，是模型在"没有信息时选择猜测"。RAG（检索增强生成）架构 + NL2SQL 的设计，从根本上切断了这条路径——模型回答问题的依据，永远是真实的数据源，而不是自己的"推断"。

还有一点值得单独说：这套东西是私有化部署的。

政企客户的数据高度敏感，财务数据、业务指标、客户信息——这些东西绝对不能传到外部的云端大模型上去。我们的产品部署在客户自己的局域网内，数据从来不出网，模型在本地跑，客户对数据的掌控权是完整的。

这解决的是另一层问题：不只是"回答准不准"，还有"数据安不安全"。

通用 AI 和垂直 AI，解决的根本不是同一个问题

用一句话总结我的理解：

通用大模型是一个极其博学但有时候爱"脑补"的顾问，垂直 AI 产品是一个只说数据库里有的、说完可以溯源的专业助理。

前者适合帮你发散思维、整理思路、生成内容。后者适合帮你查数据、跑流程、出有依据的结论。

这两件事都有价值，但在政企的核心业务场景里，你需要的是后者。

这也是我在做这个方向上的原因——不是因为通用 AI 不够强，而是"够强"本身从来不是政企采购决策的核心标准。他们要的是准、稳、安全，能出现在月度汇报上的数字。

而这件事，不是换一个更好的模型就能解决的。是要从产品设计的底层逻辑开始重新想。