RAG 长文本切片策略：父子索引、窗口扩展与模型匹配性分析
在 RAG 应用中，直接采用 512 tokens 的固定长度切片会导致两种极端情况：要么检索结果缺乏逻辑链条（如只保留结论而丢失前提），要么过长的片段引入过多无关信息，使模型难以聚焦核心内容。这三种切片方案的选择，实际上取决于文档结构、模型对上下文依赖的敏感度，以及是否允许在检索阶段引入额外计算开销。
方案 A：固定长度切片（512 tokens） + 50 tokens 重叠
这种方法的优势在于实现简单，检索速度最快，但前提是文档内部逻辑依赖较弱（如新闻文章或独立段落）。然而，当文档需要跨段落推理时——例如技术规范中“步骤 X 导致结果 Y”的解释——固定切片会将因果关系拆解到不同片段中。此时，如果模型仅根据单一片段生成答案，很可能产生“根据文档，XX 是 YY”这样的表述，而忽略“XX 之所以是 YY 的原因在于 ZZ”这一关键逻辑。这种断裂尤以 DeepSeek-V3 为明显，因为其在中文长文本场景下对隐式上下文的依赖较强。
方案 B：语义切片（基于 Cosine Similarity） + 递归字符切分
与固定长度切片不同，语义切片会在句子间语义跳跃处进行分割，确保每个片段内部相对自洽。这种方法的核心在于 RecursiveCharacterTextSplitter 的配置，但其缺点在于预处理成本较高，且在结构化文档（如合同条款或 API 文档）中可能将关键限定词（如“仅限”、“除非”）切割到不同片段中，导致模型误解条件逻辑。例如，一个“如果 A 且 B 则 C”的条件句可能被拆分为“如果 A”和“且 B 则 C”两部分，进而影响 Claude 3.5 Sonnet 的精确推理能力。
方案 C：父子索引（Parent-Child） + 窗口扩展
这一策略的核心在于两级索引：首先用小尺寸子块（如 400 tokens）进行向量匹配，再根据匹配结果自动提取对应的父级文档（如 2000 tokens）。这种设计的关键在于 LangChain 的 ParentDocumentRetriever 实现，其中 child_splitter 和 parent_splitter 的尺寸配比决定了上下文覆盖范围。在处理 10k 字以上 的技术文档时，父子索引能确保模型接收到完整的逻辑单元，而非碎片化的词组。例如，一段描述“算法 X 的时间复杂度为 O(n log n)，前提是输入数据满足条件 Y”时，父子索引能确保“前提条件 Y”和“复杂度 O(n log n)”在同一上下文中呈现，避免模型遗漏隐含条件。
对于不希望修改检索架构的场景，窗口扩展 是一种折中的优化手段：在检索到 Top-K 片段后，根据其在原文中的位置，额外提取前后 200 tokens 的内容。这一扩展量足以覆盖大多数中文句子的上下文依赖（平均句长约 15-20 tokens），同时避免了父子索引带来的存储和计算开销。不过，这种方法在文档逻辑跨度超过 400 tokens 时效果会下降，因为扩展窗口可能仍无法包含完整的因果链或定义范围。
模型匹配性与场景选择
不同模型对切片策略的适应性存在差异：
- Claude 3.5 Sonnet 在处理碎片信息时，能够通过上下文窗口扩展（如方案 C 或窗口扩展）补偿部分语义断裂，但其对长文本的整合能力仍依赖于父子索引提供的完整逻辑单元。
- DeepSeek-V3 在中文长文本场景下表现更稳定，因为其对隐式上下文的依赖较弱，但前提是切片方案能够保留关键词的完整性（如方案 B 的语义切片在配合递归分割时，需确保关键限定词不被拆分）。
- GPT-4o 虽然在对话式 RAG 中表现出较强的上下文缝合能力，但在严格的文档检索任务中，其对碎片化输入的容忍度不及 Claude 3.5。
选择依据总结：
- 精度需求最高（如法律、医疗文档）→ 父子索引 + 语义切片，确保逻辑完整性。
- 性能成本敏感（如实时问答）→ 递归切分 + 窗口扩展（200 tokens），平衡速度与准确性。
- 中文长文本关联性强（如技术白皮书）→ 父子索引，利用 DeepSeek-V3 对隐式上下文的鲁棒性。