去年 RAG 风头正盛。在一众开源框架的助力下，RAG 得以快速进入企业落地应用，成为AI实践的第一选择。
慢慢地，大家不再满足于搭建"概率输出"的知识库了 —— 想用大模型完成更多工作。问题就出现了。
最近陆续有几个客户和朋友来咨询 RAG 的问题。其中一个跟我们一样，也做长文档报告生成。下面是他为了让报告满足甲方的准确性要求做的事：
升级过一次模型版本，重做了 OCR，调了十几版 prompt，chunk size 从 500 改到 2000 又改回 800，RAG 知识库重建过一遍。最后一版报告交付，客户自测数字一致性不足 50%。
他问我们：到底是哪个环节出了问题？
我们的回答是：**哪个环节都没出问题。是架构出问题了。**
## 一个被严重低估的误判

绝大多数团队遇到"数字对不上"时，第一反应都一样：
- 换更大的模型
- 换更新的 OCR
- 调更长的上下文窗口
- 重切 RAG chunk、调 chunk size、换 embedding
- 加更多 few-shot 例子

**我们都走过。瓶颈不在那。**
这是目前长文档智能报告领域被严重低估的一个误判 —— 大家默认"模型越强越准、RAG 越调越精"，但有一类错误跟模型能力无关，也跟 RAG 调参无关。
它跟**召回架构本身**有关。
## RAG 到底是什么

要把 RAG 的边界讲清楚，得先回到它的本质。
RAG 的根在**信息检索（IR）**这一脉。从向量空间模型、TF-IDF、BM25，到今天的 embedding 召回，本质都是同一件事：**用某种相似度度量，从一堆非结构化文本里找出"相关"的片段**。大模型只是把"找出片段之后怎么办"这一步换成了生成，前面那套相似度召回的骨架没变。
这套范式在搜索引擎、推荐系统、问答系统里跑了二十多年，是成熟的工程范式。它擅长的是：**原文没有唯一答案、召回相关段落让模型总结**。问"这家公司主营业务是什么"、"行业里有什么风险"，效果好。
但企业数据里还有另一套范式 —— **结构化查询**。SQL、SPARQL、图数据库的路径查询、规则引擎的条件匹配，本质上都是**靠结构定位**而非靠相似度排序。给定一个表名、一个主键、一个路径表达式，结果是确定的，不是概率的。
这两套范式在不同问题上各有所长，本来应该互补。但 RAG 这一轮落地里，**所有问题都被塞进了相似度召回这一套** —— 不管是叙述性的问题，还是精确数值的问题，统统走 chunk-embedding-recall。
### 那为什么所有团队都选了 RAG？

不是说大家不懂结构化查询。问题在于：企业文档大部分是非结构化的 PDF、扫描件、Word。上来直接做结构化提取，成本高、周期长、每种文档都要定制解析逻辑。RAG 是这条路线上成本最低的可用方案 —— 今天搭一个 Dify，明天就能跑通 demo。
所以在项目初期，所有团队都理性地选了 RAG。**误判不在这个选择本身，而在于把临时方案当成了终局方案** —— RAG 跑通 demo 之后，数字一致性的天花板就锁死了，后面怎么调参都突破不了那个上限。因为上限不在模型层，在架构层。
这是当前企业级 LLM 落地里最大的范式误用：用一套擅长"找相关"的系统去干"取准确"的活，然后期望它越调越准。
## RAG 在数字上会翻车的几类场景

具体说，RAG 在这几类问题上会系统性翻车：
- **金额、日期、比例、阈值**这类精确数值
- **表格里的跨行跨列数字**（chunk 切分天然破坏表格结构）
- **跨页表格**（一表被切成两半，数字落在边界外）
- **条款编号对应的精确内容**（"第 3.2.1 条规定的违约金比例是多少"）
- **多文档间的数字一致性**（同一指标在两份文档里要对得上）
- **条件触发型数字**（"若 X 则 Y%，否则 Z%"，RAG 召回的是片段，理解不了条件分支）

最后这一类尤其值得展开。举个真实的例子：一份保险条款里写着"若被保险人年龄大于 60 岁，赔付比例为 80%；否则赔付比例为 95%"。RAG 会把这句话作为一个 chunk 召回，然后大模型可能提取出 80%，也可能提取出 95%，**取决于上下文窗口里其他片段的影响和生成的随机性**。这不是 prompt 能修的 —— 模型看到的是一段文本，不是一个可执行的条件分支。
这不是调 chunk size、换 embedding、加 reranker 能解的。**这是当前 RAG 架构的根本性局限。**
## 这不只是 RAG 的问题

如果你做过企业数据治理、BI 建设、知识图谱，看到上面这些翻车场景会有强烈的即视感 —— 因为这些场景在 RAG 出现之前就存在，从来都是数据治理领域的心病。
- **BI 语义层**：为什么需要 semantic layer？因为同一个"营收"指标在不同系统、不同口径下数字会打架。指标必须有显式定义，不能靠"看着像"。
- **主数据管理（MDM）**：为什么折腾 MDM？因为"客户"这个实体在不同系统里是不同的 ID，必须建立显式映射，不能靠相似度猜。
- **知识图谱 / 本体论**：为什么搞 ontology？因为实体之间的关系必须显式化，"某条款对应的违约金比例"是一条边，不是一段相似度高的文本。
- **规则引擎**：为什么条件触发型业务逻辑不写进 SQL 而要单拎出来？因为"若 X 则 Y" 是结构化规则，不能靠语义近似匹配。

还是上面保险条款那个例子，在规则引擎里它是这样表达的：
```
IF 被保险人年龄 > 60 THEN 赔付比例 = 80%
ELSE 赔付比例 = 95%
```
输入确定，输出确定。没有"概率提取"这个环节，也没有"chunk 可能切在条件中间"这个问题。但 RAG 路径把它变成了一段文本 → embedding → 召回 → 生成，中间每一步都引入不确定性。
这些领域过去二三十年沉淀下来的核心洞察其实就一句话：**企业里的关键数值，靠"看起来像"是取不准的，必须靠结构定位**。
RAG 这套范式跳过了所有这些结构化基础设施，直接拿相似度去捞数字 —— 等于把数据治理领域过去踩过的所有坑重新踩了一遍。做过企业数字化的团队看到 RAG 在数字上翻车会立刻明白：**这不是 AI 的新问题，是数据治理的老问题披了张 AI 的皮**。
这也是为什么我们对这个问题的判断比较有底气 —— 它不是 LLM 范畴里的新问题，是一个有二三十年沉淀的老问题换了个载体。老问题有成熟的范式可借鉴，借鉴过来用在 LLM 流水线上，数字一致性的天花板就能大幅抬升。
## 问题不在模型，在哪

我们见过太多项目处于这种状态：
- OCR 已经够好了，输出结构清晰
- 模型已经够大了，旗舰级
- RAG chunk size 调了又调，embedding 换了又换
- **但数字一致性就是上不去，长期在 50% 以下徘徊**

真正的瓶颈在一个被忽视的中间层 —— **从原文到 LLM 上下文之间的那段路径**。这一段如果走错了架构，后面模型再强也是垃圾进、垃圾出。
我们的判断是：**不是所有数字都该走同一条路径**。长文档里有一部分关键数字，靠 RAG 召回天然不准 —— 不是调参能解的，是架构问题。这类数字该走另一条路径直取原文，不走召回。
这条路径具体长什么样？拿前面提到的资产负债表"总资产"为例：
**RAG 路径**：把报表切成 chunk → embedding → 检索"总资产"相关 chunk → 模型从召回文本里提取数字。问题在于：chunk 可能正好切在表格中间，"总资产"行和"期末余额"列不在同一个 chunk 里，召回的是半截信息。
**结构化路径**：解析文档结构 → 定位资产负债表区域 → 定位"总资产"行 → 定位"期末余额"列 → 取行列交叉点的单元格值。不经过 embedding，不经过相似度排序，结果是确定的。
后者就是我们说的"另一条路径"。核心思路是：**对关键数值字段，不走语义召回，走结构定位**。文档解析时保留表格的结构信息（行列对应关系），提取时按结构坐标直取，而非按语义相似度排序后碰运气。
这说起来就一句话，但落到工程上 —— 怎么判断哪些字段属于"关键数值"、怎么处理不同文档模板的结构差异、怎么在结构解析失败时降级回退 —— 每一层都有自己的坑。可以借鉴数据治理领域的成熟范式，但落到具体业务文档类型上的工程化，每家都要踩自己的坑。**如果有读者感兴趣，欢迎留言，我们以后找个机会和大家专门聊聊这一层。**
讲一句结论性的话：**长文档里的关键数字，靠语义相似度召回天然不准**。这是架构问题，不是模型问题。
## 我们做过什么

在一个类似场景的项目里（已脱敏），客户原本用某个主流低代码 agent 编排平台 + 行业头部 OCR + 旗舰大模型，参数顶配，但数字一致性就是上不去，客户自测长期不足 50%。
我们用约两周时间重构了"原文到 LLM"中间路径。测试方式是：以原文人工标注值为基准，对每份文档的关键数值字段做逐字段精确匹配比对（不做语义近似匹配，差一个字就算错）。测试覆盖招投标文件、合同条款、结算单三类文档，每类各取 20 份共 60 份，每份提取 15~30 个关键数值字段。
**重构后关键数字一致性提升到实测稳定 95% 以上。** 剩余约 5% 误差主要来自上游 OCR 字符识别本身（如 0 与 O、1 与 l、8 与 6 混淆），不在我们这一层。
这套方法我们在多个长文档场景跑通（招投标、保险理赔、工程结算、合同分析等结构同构场景），不绑定特定平台或模型供应商，方法论可迁移。
## 写在最后

如果你正在做长文档智能报告项目，并且卡在"数字对不上原文"这个问题上 —— **这不是模型问题，不要继续在模型层投入**。问题在另一个地方。
继续换更大的模型、调更细的 chunk、加更多的 few-shot，都是在一个错误的方向上加码。
## 你家 RAG 翻过最离谱的车是什么？

写到这，其实更想听听你们的实战故事。我们都知道 RAG 在数字上翻车翻得花样百出，来看看谁家翻得最离谱：
1. **条款编号被识别成金额** —— "第 3.2 条" 变成 "3.2 万元"
2. **跨页表格一分为二** —— 资产负债表底下那一半直接消失，数字对不上
3. **条件触发被忽略** —— 原文"若 A 则 5%，否则 8%"，报告直接取了 5%
4. **串列串到隔壁表** —— 利润表的金额跑到现金流量表去了
5. **客户自测一致性不足 30%，研发当场自闭**
6. **其他更离谱的** —— 评论区说说，让我们知道我们并不孤单

**点赞、在看、转发给同样被 RAG 折磨的同事，是对我们最大的鼓励。**


----
## 关于我们

我们是一支聚焦 **AI Agent**落地工程的团队，在企业数据治理、行业 Harness 构建、专业文档生成、智能审查、知识管理这些方向上有多年沉淀，也运营着技术公众号，持续输出AI工具、技术架构等实践干货。



去年 RAG 风头正盛。在一众开源框架的助力下，RAG 得以快速进入企业落地应用，成为AI实践的第一选择。慢慢地，大家不再满足于搭建"概率输出"的知识库了 —— 想用大模型完成更多工作。问题就出现了。最近陆续有几个客户和朋友来咨询 RAG 的问题。其中一个跟我们一样，也做长文档报告生成。下面是他为了让报告满足甲方的准确性要求做的事：升级过一次模型版本，重做了 OCR，调了十几版 prompt，chunk size 从 500 改到 2000 又改回 800，RAG 知识库重建过一遍。最后一版报告交付，客户自测数字一致性不足 50%。他问我们：到底是哪个环节出了问题？我们的回答是：哪个环节都没出问题。是架构出问题了。

用了最好的模型，为什么 AI 生成的报告数字还是错的？

团队调了十几版prompt、换了旗舰模型和最新OCR，数字一致性还是不到50%——问题不在模型，在架构。RAG的相似度召回天然取不准精确数值，这不是调参能解的。本文从数据治理视角拆解根因，给出另一条路径。

人工智能

RAG架构在长文档处理中存在数字准确性瓶颈，关键数值需结构化定位而非语义召回。企业级AI应用中，表格数据、条件触发型数字等场景需借鉴数据治理经验，采用文档结构解析替代传统RAG路径，实测可将关键数字一致性从50%提升至95%以上。这是架构设计问题，非模型调优能解决。

知识图谱

数据治理

数据管理

代码解释

数据库

腾讯云BI特惠9.9元起！


2026上云采购 | AI焕新·智启新局

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

用了最好的模型，为什么 AI 生成的报告数字还是错的？-腾讯云开发者社区-腾讯云

用了最好的模型，为什么 AI 生成的报告数字还是错的？

用了最好的模型，为什么 AI 生成的报告数字还是错的？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐