面向 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%。进行元数据增强（章节标题、文档类型、来源）。该索引服务于相似度搜索。需要事实、解释或上下文的查询将路由至此。

索引 B：智能体（Agent）优化型。 流程边界切分——块（chunk）由动作边界、工作流步骤转换或政策章节分隔符界定。无重叠（每个块必须是自包含的）。该索引服务于智能体执行。触发工具调用、多步操作或政策执行的查询将路由至此。

相同的文档，相同的嵌入模型，但不同的切分策略、不同的块大小和不同的元数据模式。这种分离是有意为之的：检索质量和执行完整性是完全不同的目标，试图用单个索引同时满足两者会迫使系统做出妥协，从而削弱两者的效果。

LlamaIndex 的 HierarchicalNodeParser 与这种模式非常接近——它同时创建多个块大小（粗粒度章节、中粒度段落、细粒度句子），并允许检索在查询时选择合适的粒度。多尺度索引（并行索引 50、100、200、500 和 1000 个 token）通过捕获粒度多样性，比固定大小的方法提升了 1–37%。但这种层次结构仍然是为检索优化的——它没有建模智能体所需的流程边界概念。

双索引模式使这种概念上的拆分变得明确且具有可操作性。

任务分类路由

只有当系统将查询路由到正确的索引时，双索引架构才有效。这就是任务分类发挥作用的地方。

路由逻辑不需要很复杂。大多数复合 AI 系统（compound AI systems）可以使用轻量级分类器或简短的 LLM 提示词将传入的查询分为两类：

• 检索模式：你或调用代码需要信息——事实、解释、对比。路由到检索优化型索引。返回前 k 个块作为上下文。
• 执行模式：派遣智能体执行任务——运行程序、执行政策、执行工作流。路由到智能体优化型索引。返回与动作匹配的程序块。

在实践中，分类信号通常在下游可用。编排层通常知道它是在填充生成上下文（检索），还是在向专用智能体提供指令（执行）。在这些情况下，路由可以是确定性的，而不是学习性的。

当信号模糊时，轻量级的路由提示词会起作用：询问 LLM 该查询需要信息综合还是程序执行，然后相应地进行路由。现代 Agentic RAG 框架已经实现了评估节点（evaluator nodes），用于评估文档相关性并在信心不足时触发重新路由——同样的机制可以扩展到索引选择。

路由开销很小。额外的 LLM 调用会增加延迟，但它可以与索引获取并行运行。成本是可预测的。相比之下，当错误的索引处理查询时导致的无声降级，其后果是不可预测且难以调试的。

实践迁移路径

如果你正在运行单索引系统并希望转向这种架构，迁移是增量式的：

首先审计实际检索到的内容。记录导致智能体失败的查询，并检查检索到的块。如果你看到流程不完整的块（没有上下文的步骤、没有条件的指令），你就确认了切分不匹配的问题。这就是你需要优先修复的证据。

接下来，按内容类型对你的文档库进行分类。操作手册（Runbook）、标准作业程序（SOP）、政策文件和 API 规范是智能体优化型索引的有力候选者。参考文档、常见问题解答（FAQ）和解释性内容则属于检索优化型索引。许多语料库会自然地分开。

在不拆除第一个索引的情况下构建第二个索引。让两者并行运行，最初按内容类型路由（这是确定性的，不需要分类器）。对比智能体优化型索引与原始索引的智能体失败率。这将为你提供经验信号，以证明投入全任务分类路由的合理性。

底层原理

切分（Chunking）不是预处理细节——它是一个系统设计决策，决定了哪些信息在运行时是可寻址的。块边界是检索的原子单位。该级别之上的一切都是推理；该级别之下的一切都是不可见的。

当 RAG 和智能体共享一个索引时，它们共享的是一个只为其中之一设计的原子单位。结果是显而易见的：其中一个运行在错误的粒度上。由于它经常发生无声失败——高检索分数、看起来合理但输出有误——这使其成为复合 AI 系统设计中代价最高昂的错误之一。

该修复方案在你清晰地看到问题后非常直接：两个问题，两个优化的索引，一个用于路由的分类器。不需要奇特的架构。