智能问数从朴素到科学二:文档 RAG 问数的天花板

文档 RAG 问数的天花板

—一个没学过数学的“语文老师”，被拉去算财报

”

摘要：

• 文档 RAG 是大模型时代最“顺手”的能力之一：把文档切块、向量化、召回，再让模型总结回答。

• 它非常适合“读懂文档、解释条款、找资料”，却不适合“按口径算清楚一个复杂问题”。

• 在智能问数场景里，RAG 天然缺少三样东西：结构化计算、跨实体链路、可验证口径。

• 即便你把向量库做得再大、召回调得再精，RAG 的上限，依然停留在“聪明的资料管理员”，而不是“靠谱的财务顾问”。

本文是朴素路线三部曲的第一篇，我们只讨论：为什么 RAG 不是那个“算数的人”。

开篇：当“搜索+总结”被当成“算账”用

想象这样一个场景：

”

你把公司过去三年的财报、预算说明、管理层分析、审计报告，全部塞给了一个超级聪明的“语文老师”。

然后对他说：

“请你帮我算算，去年双十一到现在，新客首单来自直播渠道、且在 3 个月内完成二次购买的客户，他们对全年 GMV 的贡献是多少？”

这位老师会做什么？

他会在脑海（或向量库）里飞速搜索：

• 各种报表截图、
• 财务说明文字、
• 运营复盘文档、
• 甚至会议纪要里的段落。

然后认真地给你写一段总结：

”

“根据 XX 报告和 XX 会议纪要，直播渠道在去年双十一期间带来了显著的新客增长，对全年 GMV 贡献较大，尤其是在……（以下省略 800 字）。”

听上去有理有据，唯独缺了一样东西：

”

一个你可以拿去开会拍板的、可复核的具体数字。

这，就是很多企业在“问数 RAG 化”之后的真实体验。

一、RAG 到底在解决什么问题？

先肯定一点：

”

RAG 绝对不是“错的技术”，它在很多场景里非常好用。

它真正擅长的是三件事：

帮你找到那一页：

• 公司制度太多，记不住在哪一版 PPT 里写过；
• RAG 能迅速锁定那几页“最相关”的内容。

帮你读懂这一页：

• 条款又长又绕，
• RAG 能用大白话给你翻译成几条易读的要点。

帮你综合很多页：

• 多份报告、多个部门观点，
• RAG 能帮你做一个“初步的归纳与梳理”。

如果你的目标是：

• 找文档、看说明、读政策、学产品、查流程、理解设计，

那么 RAG 是一个非常称职的“知识库管家”。

问题出在——我们试图让它干一份它天生不擅长的工作：算数。

二、为什么 RAG 天然不擅长“可计算问数”？

在智能问数场景里，一个看似简单的问题，往往隐含着三层要求：

1. 算得出来：

• 有明确的计算链路，
• 能处理各种筛选、聚合、口径变化；

2. 说得清楚：

• 能解释用的是哪套口径、哪个时点、哪块数据、走了哪条路径；

3. 经得起追问：

• 换一个维度、换一个时间、换一套分群，
• 不需要推倒重来。

而典型的文档 RAG，在这三点上都存在结构性短板。

1. 缺少“结构化计算”的骨架

RAG 的信息来源，绝大多数是写给人看的自然语言：

• “去年大促期间，直播渠道贡献了约 35% 的新增 GMV”；
• “我们通常把最近 90 天有购买行为的客户视作活跃用户”；
• “财年维度上，我们采用的是自然年口径”。

这些信息非常重要，但它们只是描述，不是计算。

当问题变成：

”

“那 35% 具体对应到哪些客户？这些客户在最近三个月的留存情况怎么样？”

RAG 能做的，仍然是：

• 再去帮你找几段“看起来相关”的描述；
• 再帮你写一段“合情合理”的分析文字。

它做不到的是：

• 真的把这些规则落到具体数据上去执行一遍，
• 给出一张你可以导出、复核、再加工的明细表。

2. 缺少“跨实体、多跳链路”的地图

真正的经营问题，几乎都不是在“单表单维度”上能解决的：

• 客户 → 订单 → 明细 → 品类 → 渠道 → 活动 → 触达 → 反馈 → 再次购买……

这中间每跨一步，都是一次“关系跳跃”和“语义转换”。

而在文档世界里，

• 客户画像可能在一份 PPT，
• 渠道策略在另一份方案，
• 活动配置在一个后台文档，
• 留存分析在一份年终复盘。

RAG 从中召回的，依然是彼此独立的段落，而不是一条你可以跑一遍、验证一遍的链路。

”

它帮你找来了“很多点”，却很难帮你真正画出“那条线”。

3. 缺少“唯一口径”的裁判

当不同文档里，对同一个概念给出了略有差异的描述时：

• 有的说“新客”是 30 天内首购，
• 有的说是自然月内首购，
• 有的在活动方案里偷偷改成了“活动周期内首购”。

RAG 会怎么做？

• 它会把这些不同的描述一起召回，
• 然后让大模型努力“圆”出一段看上去合理的解释。

但在一个需要“算清楚”的场景里，我们真正需要的是：

”

一位能拍板的裁判，而不是一位会说话的主持人。

三、把向量库做大、召回调精，有用吗？

很多团队在遇到 RAG 的局限时，第一反应往往是：

• “是不是我们的向量模型不够好？”
• “是不是我们的 chunk 切得不够细？”
• “是不是要再加一层重排模型？”

这些工程上的改进确实能带来体验上的提升：

• 召回更准了，
• 跑题更少了，
• 回答更顺滑了。

但有三个事实，很难被这些优化改变：

1. 它依然是“找段落+写回答”的范式，
2. 它依然没有结构化的“算账骨架”，
3. 它依然缺少“唯一可复核口径”的机制。

换句话说：

”

你可以把“语文老师”训练得更博学、口才更好，但他终究还是一位语文老师。

让他帮你“算一次账、出一份审核能过的财报”，不现实。

四、用九大要求给 RAG 做一次“体检”

如果按照上一篇提出的九大要求，我们可以给 RAG 做一份简要“体检报告”：

语义化：

• ✅ 能部分承接自然语言里的业务含义，
• ❌ 但缺少统一、可计算的企业语义层。

图谱化：

• ❌ 段落之间缺少显式的实体与关系建模，
• 多跳推理更多靠“语言猜测”，而不是可验证的路径计算。

多模态：

• ✅ 能同时处理多种文本来源，
• ❌ 与结构化表、时序、向量的“对象级统一”，依然薄弱。

准确度：

• ❌ 最终产出的是“相关内容的综合描述”，而非“唯一可复核的数值与明细”。

自由度：

• ✅ 问什么都能聊两句，
• ❌ 但在复杂链路问题上，常常聊着聊着就偏题。

专业度：

• ✅ 可通过提示词注入部分行业背景，
• ❌ 对企业私域知识和口径的对齐，多依赖人工喂养与反复试错。

开放性：

• ✅ 接口简单易接入，
• ❌ 但输出多是文本，难以沉淀为可复用的“算数能力接口”。

成长性：

• ❌ 知识增长主要依赖“再喂更多文档”，
• 很难形成“规则级、口径级”的自我演化。

完整性：

• ❌ 缺少从“问题→计算→解释→验证→回流”的闭环，
• 更多停留在“问题→检索→总结”这一截。

这份体检报告并不是要否定 RAG，而是帮我们认清：

”

RAG 在智能问数体系里，更像是“知识前台”，而不是“结算中心”。

五、那么，RAG 应该被用在什么位置？

从“科学方法”的角度看，更合理的定位是：

做“语境铺垫”：

• 在真正开始算账之前，
• 帮业务和数据团队快速对齐背景、概念、既往结论。

做“解释助手”：

• 在一条可复核的计算链路跑完之后，
• 帮忙把复杂的计算逻辑翻译成业务听得懂的语言，
• 甚至生成初版的分析报告、复盘材料。

做“知识入口”：

• 在用户刚开始探索一个新领域时，
• 提供“先看文档、再看数据”的路径引导。

换句话说：

”

RAG 是一位非常好的“讲解员”，但不要指望它兼职“会计师”。

六、结语与下篇预告

如果你正在做一个 RAG 项目，可以用下面几句话做一个小小的自检：

• 我们期待的，是“有人帮我快速翻文档”，还是“有人替我算清楚账”？
• 我们现在的答案，是“看上去有理有据的总结”，还是“可以被第三方复核的数值和明细”？
• 当口径发生变化时，我们是“改几份文档就行”，还是“要推翻整个系统重来”？

在下一篇《智能问数从朴素到科学三：Text-to-SQL 的准确性困境》中，我们会把视角从“语文老师”转向“翻译官”：

”

当我们试图用一条 SQL 把自然语言问题“翻译”成数据库世界的精确查询时，

为什么看似最直接的路，往往成了“最坑的一条”？

我们会专门聊聊：

• 语法正确为什么仍然可能业务错误；
• 多表多库、多时点多口径下，Text-to-SQL 天然的脆弱点；
• 为什么再聪明的大模型，也很难单枪匹马扛起这份工作。
“大数据”到“大数知”，AI时代的“能源”革命（一）

知识黑洞——AI大模型时代的致命陷阱与ONN破局之道

本体智能·技术探源（一）本体简史——从哲学到AI的千年演进（上篇）

本体智能（三）为什么说本体智能是企业AI的”操作系统”

本体智能（一）为什么你的AI项目，总是”差点意思”？

#本体智能 #本体论 #智能问数 #AI大模型 #数字化 #智能化