面向 Agent 与 RAG 的分块:为什么一套方案会同时拖累两者
大多数团队选择一个分块大小,针对检索质量进行调优,然后就此止步。接着,他们在同一个索引上构建一个 Agent,并纳闷为什么 Agent 会以奇怪的方式失败——它只执行了一半的工作流,忽略了条件逻辑,或者根据不完整的指令自信地采取行动。使你的 NDCG 分数最高的分块大小,恰恰是让你的 Agent 变得不可靠的原因。
RAG 检索和 Agent 执行并不是同一个问题。它们有不同的目标、不同的失败模式,以及对什么是“好的分块”有着根本不同的定义。当你针对其中之一优化分块时,你就在系统性地削弱另一个。大多数团队直到已经在错误的架构基础上构建完产品后才意识到这一点。
RAG 检索究竟需要什么
对于检索增强生成(RAG),检索质量取决于嵌入向量相似度——分块必须被嵌入到一个能忠实捕捉其主题的向量 中,并且该向量必须在嵌入空间中靠近查询向量。这驱动了你应如何为 RAG 进行分块的一切。
行业默认的 400–512 token 且带有 10–20% 的重叠是有原因的。NVIDIA 在 7 种策略和 5 个数据集上的基准测试发现,页面级分块以 0.648 的准确率位居榜首,而递归字符拆分(recursive character splitting)在混合工作负载中处于最佳平衡点。但分块大小取决于查询类型:事实类查询(姓名、日期、具体事实)在 256–512 token 时达到峰值,而需要更广泛背景的分析类查询则需要 1024+ token。2026 年 1 月的一项分析发现,语义分块(semantic chunking,即在有意义的语言边界处拆分)产生的片段平均仅为 43 token,虽然实现了清晰的语义连贯性,但对于生成而言上下文不足,端到端准确率为 54%,而递归拆分为 69%。
RAG 分块的设计目标是语义完整性:这个分块是否描述了一个连贯的主题?对正确查询的相似度搜索会落到这里吗?增加分块间的重叠有助于跨边界保留上下文。添加元数据(章节标题、文档标题)有助于嵌入向量捕捉分块在文档层级中的位置。
RAG 检索所不优化的点是:Agent 是否可以在不需要任何其他信息的情况下执行该分块内的内容。
Agent 究竟需要什么
当一个 Agent 检索一个分块来执行操作时,它需要一种本质上不同的东西:程序完整性(procedural completeness)。分块必须是一个自包含的工作单元——一个完整的工作流步骤,一个包含条件和异常的完整指令集,一个包含触发因素和结果的完整策略。
考虑一 个数据库迁移运行手册(runbook)。一个经过 RAG 优化的分块可能清晰地捕捉到“关于锁定行为的章节”——语义连贯,主题统一,检索召回率极高。但 Agent 需要的更多:它需要应用锁的前提条件、后置条件检查,以及这些检查失败时的回滚程序。如果将这些按语义边界拆分,Agent 就会收到一半的指令。它不知道自己不知道什么,所以它会根据现有的内容进行执行。
这种失败很隐蔽,因为检索到的文本在孤立状态下看起来是合理的。Agent 并没有察觉到检索错误——它看到了看似合理的内容并继续执行。问题只在程序失败时才会浮现,而且通常是在生产环境中。
针对 Agent 优化的分块通常更大,大小可变,并且由工作流转换点而非语言或主题转换点来界定。运行手册中的一个步骤在下一个操作开始时结束,而不是在句子实现语义闭合时结束。
当你只选择一种策略时的三种失败模式
失败模式 1:RAG 分块对 Agent 来说太小。 当你针对事实类检索调优分块大小时(256–512 token 通常是最佳的),Agent 会收到片段。一个横跨 1,200 token 的多步工作流被拆分为三个分块。Agent 检索到看起来最相关的一个(通常是第一步),并像收到完整指令一样继续执行。第二步和第三步根本不会发生。这不属于检索失败;相似度得分很高。这是分块不匹配。
失败模式 2:Agent 分块对检索来说噪点过多。 反向问题:如果你为了程序完整性 而设定分块大小,分块会变得很大——整个工作流通常需要 800–1,500 token。检索质量会下降,因为较大的分块引入了多个主题。类似 SQuAD 的分析显示,随着分块大小增加,对于 512+ token 的事实类查询,召回率下降了 10–15%。当用户只是询问一个简单的事实问题时,你的向量索引开始返回整个工作流,从而在提示词中产生不相关的背景幻觉。
失败模式 3:重叠产生的冗余浪费了 Agent 的上下文。 重叠(RAG 用来桥接分块边界所必需的)意味着相邻分块共享 50–100 token 的相同内容。对于检索来说,这基本上是无害的(重复内容会被过滤)。但对于处理多个检索分块的 Agent 来说,重复内容消耗了可观的上下文窗口,挤占了其他工具调用或推理步骤的空间,并可能导致 Agent 重复执行重叠的指令。
一项临床决策支持研究量化了这一利害关系。自适应分块(对齐主题边界并具有可变窗口大小)实现了 87% 的准确率,而固定大小分块仅为 13%(p = 0.001, F1: 0.64 vs. 0.24)。差距并不细微。分块选择对结果的影响比大多数团队预期的要大得多。
双索引架构
更纯净的解决方案:对相同的文档维护两个独立的索引。
索引 A:检索优化型。 固定递归切分,大小在 400–512 个 token 之间,重叠率为 15%。进行元数据增强(章节标题、文档类型、来源)。该索引服务于相似度搜索。需要事实、解释或上下文的查询将路由至此。
- https://developer.nvidia.com/blog/finding-the-best-chunking-strategy-for-accurate-ai-responses/
- https://pmc.ncbi.nlm.nih.gov/articles/PMC12649634/
- https://arxiv.org/html/2501.09136v4
- https://arxiv.org/html/2409.04701v3
- https://arxiv.org/html/2505.21700v2
- https://weaviate.io/blog/chunking-strategies-for-rag
- https://www.ai21.com/blog/query-dependent-chunking/
- https://stackoverflow.blog/2024/12/27/breaking-up-is-hard-to-do-chunking-in-rag-applications/
- https://lancedb.com/blog/chunking-techniques-with-langchain-and-llamaindex/
- https://community.databricks.com/t5/technical-blog/the-ultimate-guide-to-chunking-strategies-for-rag-applications/ba-p/113089
