AIGC标识 用了最好的模型、最新 OCR，为什么 AI 生成的报告数字还是错的？

去年 RAG 风头正盛。RAGFlow、Dify、Bisheng 这些开源框架的助力下，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工具、技术架构等实践干货。

开源产品：

  • Molio — 兼容 Obsidian Vault 的本地知识库 × Claude Code 图形界面 × 微信 AI 助手 × Web Clipper，数据全在自己电脑上
  • OpenSpec — 企业级智能长文档生成与审查平台（本文讲的"原文到 LLM 中间路径重构"正是它解决的核心问题之一）

联系合作：

posted @ 2026-07-15 21:22  AI闲人  阅读(15)  评论(0)    收藏  举报