没有度量就没有改进：腾讯云 ADP 把 RAG 评测拆成检索、生成和端到端

没有度量就没有改进：腾讯云 ADP 把 RAG 评测拆成检索、生成和端到端

腾讯云 ADP（Agent Development Platform，腾讯云面向企业的智能体开发平台）在 2026 年 9 月 30 日发了 RAG 系列第三篇。前两篇分别写标准流水线和七个工程短板，这一篇把生产环境里还没解决的问题收成五块：切片和上下文互相打架、跨文档推理太贵、评测经常缺席、知识库没人治理、检索结果和最终回答之间缺少可审计的信任环节。对评测读者，后三块才是质量体系，前两块决定评测到底在测什么。

先分开定位和阅读，再谈召回对不对

原文把第一篇里的结构性矛盾重说一遍：召回想要短而干净的片段，生成想要长而连贯的上下文。深水区的做法不是在一个长度上折中，而是把 Search 和 Retrieve 拆开。Search 负责定位，用语义干净的小片段找到线索点；Retrieve 负责阅读，再按线索点拼出更大的上下文交给模型。

文中点名三条路线，并各自带限制：

• TreeRAG：离线用大模型把文档收成「章、节、段」的树状摘要；线上先用小片段召回，再向父节点和兄弟节点扩展，拼成逻辑完整的大片段。
• PageIndex：直接用文档自己的目录。结构清楚时快，但原文写明它依赖源文档质量。
• 父子分块和语义分块：工程上更轻，被写成折中，不是精度上限。

评测如果只报一个「召回率」，这三种做法会混在同一个数字里。定位错了和扩展错了，修法不一样。

GraphRAG 能连上跨文档，也把噪声和成本带进评测

GraphRAG 用来处理答案散落在多份不相邻文档里的情况。喜欢它的理由很具体：向量相似度找不到的间接关系，可以靠图遍历（文中举了 Personalized PageRank）顺着关系链走出来。讨厌它的理由也写了三处，而且都是评测时必须单独记账的限制：

1. 成本高。实体抽取、去重、社区摘要的 token 可以是原文的数倍到数十倍。原文没有给出某一套语料的精确倍数，只给了这个量级。
2. 质量噪声。自动抽出的实体和关系有噪声、冗余和错误，达不到人工知识图谱的质量。
3. 回答易碎。图给模型的是离散知识点和社区摘要，要把碎片收成连贯答案，对模型整合能力要求很高。

文中的务实趋势是混合，而不是二选一：TreeRAG 补局部语义被切断的问题，GraphRAG 补跨文档关联，两者合在一起被叫做「长上下文 RAG」。上一篇里的剪枝、降级和融合检索，是在这组爱恨之间找工程平衡，不是证明图检索已经稳定胜过向量检索。

长上下文没有取消检索，它改变了评测对象

「长上下文会取代 RAG」在原文里被写成已经被实践否定的命题。把大量文本直接塞进窗口，会出现注意力分散、Lost in the Middle、回答变差，成本还随窗口非线性上涨。更有用的用法是：窗口用来装检索已经挑出来的、更完整的结果块，或者装多步检索的中间结果。检索负责找对，长上下文负责装得下。

由此带出 Context Engineering（上下文工程）：工作从单点优化检索算法，转到「检索、上下文组装、模型推理」整条链路。评测若仍只看最终一句话对不对，会把组装阶段的丢失算到模型头上。

知识库要先变成 Agent 的数据底座

随着 Agent 出现，企业级 RAG 被写成不再只是问答知识库，而是给各类 Agent 提供统一、带权限的非结构化数据访问。这需要一条可扩展、可配置的注入管道。原文用结构化数据的 ETL/ELT 作类比，把非结构化侧叫做 PTI（Parse-Transform-Index，解析、变换、索引）。Agent 要的不只是能答一次，而是解析、清洗、结构化、索引、权限过滤和按需召回都稳定。管道质量被直接写成上层所有 Agent 的天花板。这篇没有给出这条管道的时延或失败率数字。

评测：两段误差、多轮一致、能溯源

原文把评测称为深水区里最常被忽略、也最致命的一环，并写出 RAG 比一般 NLP 任务更难的三个原因：

• 两段式误差。检索错和生成错必须分开归因。没检索到，和检索到了却没用对，修法完全不同。
• 多轮一致性。真实对话是多轮的，单轮准确率不能代表体验。
• 可信与可审计。金融、医疗、法律必须能溯源、能审核证据。

分环节指标也写死了，没有再发明综合分：

• 检索侧：Recall@K（前 K 条里有没有召回应有证据）和检索延迟。
• 生成侧：忠实度（回答是否基于证据）和答案相关性。
• 端到端：任务完成率、用户满意度。

工程上要求按周、按月、按季度做持续评测，而不是上线前测一次。文末的行动建议更具体：把答错、依据缺失、引用过期收成评测集，按应用评测做批量验证；每次改知识或检索策略，用同一组问题再跑。原文没有公开这套评测集的题量、标注规范和基线分数，所以不能从这篇读出 ADP 的 RAG 准确率。

知识治理：过期、冲突和重复比模型更常卡住效果

原文判断，多数 RAG 的瓶颈不在检索算法和模型，而在知识库：过期、表述冲突、版本杂乱、重复冗余。从「文档入库」改成「知识治理」时，两条主线被单独列出：

• 图谱冲突治理：用知识图谱做实体归一和关系对齐，找出跨文档矛盾、新旧版本冲突和互斥结论。碎片文本自己检不出这些问题。
• 结构化知识沉淀：按 LLM Wiki 一类动态知识库的思路，把散文档收成统一、无冲突的结构化条目，并保留版本和纠错记录。

医疗医药方案被当作例子，不是当作已公布的评测结果：一线要查学术物料、产品信息和政策法规，多源同步和过期清理直接影响资料能不能用。涉及具体临床判断时，仍要专业人员审核。这是使用限制，不是效果承诺。

证据决策层：把「信不信」从生成里拿出来

传统 RAG 让生成模型同时做证据核验、事实纠错和回答，结果是噪声判错、幻觉偏高、token 浪费。新结构是在检索和生成之间加一层证据决策：检索找候选，决策审证据，模型只生成。

它和普通 Rerank 的差别被写清楚了。Rerank 只按相关性排序；决策层要逐条看有效性、时效性和事实冲突，把无效、过期、矛盾的片段挡在上下文之外。收益写了三条：幻觉更少、忠实度更高；上下文更短、推理更便宜；评测归因有了可审计依据。深层意义是把「该不该信这条证据」从概率生成里抽出来，变成可规则、可审计的确定性环节。金融和医疗被点名为需要这种形态的场景。

企业法务里的来源引用、原文锚点和人工复核，以及复杂政策问答里的依据约束、风险校验和专项评测，被写成相近实践，供证据核验参考。它们不是这篇里的对照实验。

效果、速度、成本不能同时拉满

生产侧被写成不可能三角：效果、速度、成本不能同时最优，客户却常常三者都要。工程核心被定义成动态取舍，而不是把重链路用在每一次请求上：

• 简单问答走轻量检索，保低时延和低成本。
• 复杂推理和跨文档问答才开 TreeRAG、GraphRAG 和长上下文组装。
• 重算力放到离线预计算，在线链路保持轻。
• 用缓存、token 上限熔断和边际收益止损，守住业务 SLA。

原文让试点预算按实际调用量和部署方式去看 ADP 定价，没有给出一份标准成本表，也没有给出熔断阈值。

安全合规是准入条件，不是检索之后的插件

面向金融、医疗、政务，原文列出五类治理，并说明这是工业实践里的典型方向，不是某一客户的审计结论：

1. 敏感数据过滤、向量脱敏，以及仍在探索的隐私计算。
2. 检索过程和生成结果留痕，证据可审计、可存证。
3. 规则引擎挡住违反行业红线的内容。例子是医疗场景不得给出未获批的诊疗方案。
4. 防范语料投毒、提示词注入和越权检索。
5. 权限下沉到召回：不同用户、不同智能体只能召回被授权的切片，做到「检索即可见」。

原文的判断很硬：在深水区，这套合规体系常常比检索精度更能决定项目能不能落地。它没有给出攻防测试的拦截率。

这篇没有给出的数字

系列结论是：2025 年关于长上下文的争论没有终结 RAG。现代企业级 RAG 被概括成源头治理提质量、分层校验控精度、动态调度控成本，让检索和上下文协同。模型会换，要做的事仍是让对的信息在对的时间、以对的方式到达对的模型。

读的时候要守住边界。全文没有 Recall@K、忠实度、任务完成率或满意度的实测值，没有评测集规模，没有 TreeRAG 相对朴素分块的提升百分点，GraphRAG 的 token 只写到「数倍到数十倍」。周、月、季度复测和固定评测集是方法要求。临床判断、法务复核和红线过滤都明确留给规则和人工，不能把这篇读成「模型已经可以独立做医疗或法律结论」。

出处：腾讯云 ADP，腾讯云 ADP 团队，RAG 进入深水区：评测、知识治理与证据决策层，2026-09-30，https://adp.tencent.com/zh/blog/rag-deep-water-evaluation-governance