RAG 语料库架构：决定检索质量的索引决策
当 RAG 系统返回错误答案时，事后分析几乎总是聚焦于同一批嫌疑人：检索查询、相似度阈值、重排序器、提示词。团队会花好几天调整这些组件，而真正的原因却静静地躺在索引流水线里无人触碰。失败早在几周前就已发生——那时有人拍板决定了分块大小。
大多数 RAG 质量问题是架构性的，而非运营性的。它们源于索引时做出的决策，这些决策会悄然塑造 LLM 最终能看到的内容。等到用户投诉时，检索系统正在做它被设计好的事——只是那个设计本身就是错的。
本文是一份关于最重要的索引时决策指南，涵盖 2024–2026 年基准测试的实际结论，以及在生产中持续区分高质量与低质量 RAG 系统的设计模式。
索引陷阱：症状如何向下游迁移
对 RAG 的朴素认知将检索视为查询时的问题。你有一个向量存储，发送查询，拿回分块。如果分块不对，就调整查询。如果模型产生幻觉，就检查提示词。
真实的故障模型并非如此。索引架构设定了一个上限，无论怎么调整查询都无法突破。如果你的分块在句子边界处切断了关键段落，每一半的嵌入在语义上都会减弱。如果你从未将章节标题注入为元数据，重排序器就没有任何线索可循。如果你对叙述性散文和财务表格使用同一分块大小，两者的表示都会变差。
这些失败会静静地叠加。PDF 提取出错会产生噪声分块。噪声分块产生误导性嵌入。误导性嵌入返回无关上下文。无关上下文导致幻觉。所有责任都落在"模型"身上——但模型只是在根据你提供的内容进行推理。
实践含义：像对待查询流水线一样积极地监测索引流水线。记录分块质量分布。从第一天起就在真实查询上测试。你的评估基准应该建立在真实用户查询上，而不是基于你已经清晰索引的文档所构造的合成查询。
分块大小是一个查询类型决策
索引时最常见的错误是把分块大小当作全局调整的单一参数。不存在普遍最优的分块大小。正确的大小取决于你的系统所面对的查询分布。
事实查询、查找型查询在小分块（128–256 token）下表现最好。更小的单元能产生更聚焦、更具体的嵌入，与精确措辞的问题高度匹配。当用户问"持有不足一年的资产资本利得税率是多少"时，你想要的是一个恰好包含这句话的分块，而不是一个还涵盖遗产规划、赠与税和成本 基础递增的分块。
分析型查询——综合、比较、多跳推理——需要更多上下文。一个覆盖文档完整章节的 512–1024 token 分块为模型提供了跨相关概念进行推理的连接纽带。把它切成 128 token 的碎片，会产生对概念关系表示更弱的嵌入。
NVIDIA 2024 年的基准测试显示，页级分块以 64.8% 的准确率和最低方差取得最高精度。但这一发现范围有限：它适用于结构良好的分页文档，其中一页确实代表一个连贯的语义单元。应用于长篇叙述性文本或 FAQ 文档时，页级分块是随意的，而非原则性的。
实践基线：从 400–512 token 的递归字符切分开始。Chroma Research 2025 年的研究发现，此方法在无需语义分块计算开销的情况下实现了 85–90% 的召回率。在有真实流量可测量之后，再根据你的实际查询分布进行调整。
重叠悖论
十年来的 RAG 教程都建议在分块之间添加重叠。理由直觉上说得通：如果关键段落横跨分块边界，重叠能确保两半都不会孤立存在。
2026 年 1 月一项使用 SPLADE 检索在 Natural Questions 数据集上的系统性分析发现，重叠没有带来任何可测量的收益，反而增加了索引成本。直觉失效的具体原因在于：重叠的分块互为近似副本，当两者都被检索到时，它们消耗的是上下文窗口而不是提供额外证据。你得到的是冗余，而不是覆盖。
这不意味着重叠永远是错的。对于 OCR 处理的文本、抓取的网页以及其他空白符和结构不可靠的来源，10–15% 的重叠可以弥补朴素切分会破坏的边界。对于干净、结构良好的文档，它往往只是增加噪声。
实践规则：默认不设重叠，在跨边界查询上测量检索质量，仅当能观察到改善时再添加重叠。大多数场景的适当上限是 10%。
父子层级与小转大模式
生产 RAG 系统中最持久的模式之一是父子检索层级。文档被切分成用于检索的小子分块（100–300 token）和用于生成的大父分块（500–2000 token）。检索系统获取子分块，因为其紧凑的嵌入编码了更精确的语义。生成步骤接收父分块，因为更广的上下文能产生更好的答案。
理解其有效性的原理很重要。当你嵌入一个横跨多个子主题的 1500 token 分块时，得到的向量是所有这些主题的加权平均，嵌入是模糊的。当你嵌入一个 200 token 的句子窗口分块时，向量捕捉到了更聚焦的语义单元——检索相似度分数相应提高。
在生成时，窄分块通常不够用。模型需要周围上下文来解析代词、遵循逻辑链并理解主张之间的关系。父分块提供了这种上下文。
这一模式对技术文档、研究论文以及任何具有清晰层级结构（章节内的小节、小节内的子章节）的语料库特别有效。索引中的层级与源材料中的层级相对应，检索从这种对齐中获益。
元数据增强：团队持续跳过的决策
索引时最被低估的决策是在每个分块进入向量存储之前附加什 么元数据。
仅内容的向量存储支持一维检索：语义相似度。元数据丰富的存储支持多维过滤搜索。你可以同时按语义相似度、源文档、发布日期、章节类型和文档分类进行检索。你添加的每个过滤维度都将"找相似的"变成了"找相关的"。
Snowflake 2024 年金融 RAG 基准测试显示，元数据增强检索实现了 82.5% 的精度和 0.813 的 NDCG 分数，大幅超越仅内容的基线。推动差距的元数据包括公司名称、申报日期、表单类型和章节标题——所有这些字段若不作为结构化字段注入，模型都需要从内容中推断。
