不要再为所有问题押一个分块大小

先说结论

“固定分块已经过时”并不等于分块不重要。Yuval Belfer 的实验指出，真正的问题是团队常常在索引时为整个语料库选一个固定窗口，却不知道未来的问题需要多少上下文。一个很具体的事实适合小块，一个跨段落的关系需要大块；没有任何单一大小能在所有查询上占优。更稳的办法是用多个尺度索引同一份材料，让每个尺度返回整篇文档，再用 Reciprocal Rank Fusion 合并排序。中文深度整理，非逐字翻译。

原始来源：Stop Chunking Like It's 2022。节目：AI Engineer。嘉宾：Yuval Belfer。原始日期：2026-09-16。时长：约 18 分钟。内容类型：技术演讲 / RAG 检索。

这期内容在讨论什么

RAG 的注意力经常落在查询时：调 top-K、换混合检索、加重排器、让 Agent 用 grep 或 find。分块则发生在系统建立之初，往往被设成 512 或 1000 个 token，再加一点重叠，然后很少重新审视。Belfer 认为这相当于一种有损压缩：索引阶段决定哪些信息会被放在一起、以什么粒度获得向量表示，之后的查询只能在这个决定上工作。

核心观点

第一，小块和大块各有不可替代的优势。小块可以把一个局部事实表示得很清楚，但可能把关系所需的上下文切断；大块能保留叙事和背景，却会让某个细节被大量无关文本稀释。问题不同，最佳窗口也不同。

第二，查询依赖的尺度差异可以被实验直接观察。团队在 QMSum 会议文本、NarrativeQA 小说问答和 Seinfeld 语料上建立多个不同分块版本。一个只问具体名称的问题，较小窗口更容易把答案排到前面；另一个询问人物关系的问题，则需要更大的上下文。平均到数据集的一个“最佳大小”，会掩盖查询之间的差异。

第三，不能使用知道答案的 oracle，但可以用多尺度搜索逼近它。实验中的 oracle 会事后为每个问题选择最佳分块大小，用来测量理论上限；真实系统当然不能这样做。替代方案是同时查询多个尺度，把不同尺度找到的片段映射回相同的源文档，再对文档排序进行融合。这样，短块负责精准定位，大块负责保留语境，后续生成可以读取更完整的文档。

推理链与关键例子

如果六个索引直接返回六套不同的片段，结果无法简单合并，因为每个列表的候选对象不同。Belfer 的关键转换是把“片段命中”改成“源文档命中”：无论哪个尺度找到了一段文字，排序对象都回到它所属的完整文档。然后用 RRF 这样的简单融合方法，把多个尺度对同一文档的排名合在一起。

这种设计把检索和阅读分开。检索时可以用很窄的窗口找到一个关键词或事实；交给模型时则提供更大范围的文档上下文。演讲报告在多个数据集上，融合方法相较固定大小取得约 20% 到 40% 的召回改善。这个数字描述的是检索召回，不是答案生成准确率；但它足以说明，单一分块大小本身可能造成可测量的损失。

代价也很明确：索引副本增加，存储和写入成本随尺度数量上升。查询可以并行执行，因此额外尺度未必线性增加端到端等待，但每个问题仍然需要更多检索工作。团队还没有给出所有语料都适用的尺度选择规则，50、100、200 等窗口只是实验中的候选，需要根据语料和查询分布继续调优。

边界、保留意见与争议

多尺度检索不等于盲目建立很多份数据库。语料规模、更新频率、上下文窗口和并发预算都会决定副本数量。一个小型知识库可能直接保留完整文档就足够；一个实时更新的大型系统则必须认真计算索引同步和存储成本。

此外，召回提升不自动意味着最终回答更好。文档太长会增加生成成本，也可能把更多相互矛盾的材料交给模型。系统仍然需要文档级去重、权限过滤、时间有效性判断和下游引用验证。多尺度解决的是“用什么粒度找到材料”，不是“材料之间哪一个结论应当被采纳”。

整理后的观察

这期内容对“Agent 已经杀死 RAG”的反驳很有价值。Agent 可以改变检索控制流，却没有消除索引、分块和召回的工程问题。相反，当数据量变大、问题类型变多时，固定的早期索引决策会变成更明显的瓶颈。

工程上可以先做一个低风险试验：选一批真实查询，用两个或三个尺度建立副本，把片段命中统一映射为文档命中，再比较融合前后的召回和生成结果。这个实验不需要先引入复杂的新模型，却能让团队看见自己的语料是否真的受困于单一窗口。它把“分块大小该是多少”的静态争论，转成了可测量的查询级策略问题。