用了最好的模型、最新 OCR为什么 AI 生成的报告数字还是错的去年 RAG 风头正盛。RAGFlow、Dify、Bisheng 这些开源框架的助力下RAG 得以快速进入企业落地应用成为AI实践的第一选择。慢慢地大家不再满足于搭建概率输出的知识库了 —— 想用大模型完成更多工作。问题就出现了。最近陆续有几个客户和朋友来咨询 RAG 的问题。其中一个跟我们一样也做长文档报告生成。下面是他为了让报告满足甲方的准确性要求做的事升级过一次模型版本重做了 OCR调了十几版 promptchunk size 从 500 改到 2000 又改回 800RAG 知识库重建过一遍。最后一版报告交付客户自测数字一致性不足 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 在数字上翻车翻得花样百出来看看谁家翻得最离谱条款编号被识别成金额—— “第 3.2 条” 变成 “3.2 万元”跨页表格一分为二—— 资产负债表底下那一半直接消失数字对不上条件触发被忽略—— 原文若 A 则 5%否则 8%报告直接取了 5%串列串到隔壁表—— 利润表的金额跑到现金流量表去了客户自测一致性不足 30%研发当场自闭其他更离谱的—— 评论区说说让我们知道我们并不孤单点赞、在看、转发给同样被 RAG 折磨的同事是对我们最大的鼓励。关于我们我们是一支聚焦AI Agent落地工程的团队在企业数据治理、行业 Harness 构建、专业文档生成、智能审查、知识管理这些方向上有多年沉淀也运营着技术公众号持续输出AI工具、技术架构等实践干货。开源产品[Molio]— 兼容 Obsidian Vault 的本地知识库 × Claude Code 图形界面 × 微信 AI 助手 × Web Clipper数据全在自己电脑上[OpenSpec]— 企业级智能长文档生成与审查平台本文讲的原文到 LLM 中间路径重构正是它解决的核心问题之一GitHubzhuzhaoyun
用了最好的模型、最新 OCR为什么 AI 生成的报告数字还是错的去年 RAG 风头正盛。RAGFlow、Dify、Bisheng 这些开源框架的助力下RAG 得以快速进入企业落地应用成为AI实践的第一选择。慢慢地大家不再满足于搭建概率输出的知识库了 —— 想用大模型完成更多工作。问题就出现了。最近陆续有几个客户和朋友来咨询 RAG 的问题。其中一个跟我们一样也做长文档报告生成。下面是他为了让报告满足甲方的准确性要求做的事升级过一次模型版本重做了 OCR调了十几版 promptchunk size 从 500 改到 2000 又改回 800RAG 知识库重建过一遍。最后一版报告交付客户自测数字一致性不足 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 在数字上翻车翻得花样百出来看看谁家翻得最离谱条款编号被识别成金额—— “第 3.2 条” 变成 “3.2 万元”跨页表格一分为二—— 资产负债表底下那一半直接消失数字对不上条件触发被忽略—— 原文若 A 则 5%否则 8%报告直接取了 5%串列串到隔壁表—— 利润表的金额跑到现金流量表去了客户自测一致性不足 30%研发当场自闭其他更离谱的—— 评论区说说让我们知道我们并不孤单点赞、在看、转发给同样被 RAG 折磨的同事是对我们最大的鼓励。关于我们我们是一支聚焦AI Agent落地工程的团队在企业数据治理、行业 Harness 构建、专业文档生成、智能审查、知识管理这些方向上有多年沉淀也运营着技术公众号持续输出AI工具、技术架构等实践干货。开源产品[Molio]— 兼容 Obsidian Vault 的本地知识库 × Claude Code 图形界面 × 微信 AI 助手 × Web Clipper数据全在自己电脑上[OpenSpec]— 企业级智能长文档生成与审查平台本文讲的原文到 LLM 中间路径重构正是它解决的核心问题之一GitHubzhuzhaoyun
