构建或优化 RAG 系统时如何选择与验证文档分块策略

为 RAG、向量数据库或大文档处理选择分块大小、重叠比例与边界检测方法，并验证语义连贯性与检索指标。

适用场景

解决思路

1. 按文档类型和用例选择分块策略：1) 固定大小分块（Level 1）用于无清晰结构的简单文档，从 512 tokens 和 10-20% 重叠开始，事实型查询用 256，分析型用 1024；2) 递归字符分块（Level 2）用于有结构边界的文档，按段落→句子→词的层级分隔符切分，并针对 HTML、Markdown、JSON 等类型定制；3) 结构感知分块（Level 3）用于 Markdown、代码、表格、PDF 等结构化内容，保留函数、章节、表格块等语义单元，切分后验证结构是否保留；4) 语义分块（Level 4）用于有主题切换的复杂文档，用基于嵌入的边界检测，相似度阈值 0.8，缓冲区 3-5 句；5) 高级方法（Level 5）包括 Late Chunking（用于长上下文模型）和 Contextual Retrieval（用于高精度需求），并监控计算成本与检索收益的权衡。
2. 实现分块流水线：1) 预处理文档，分析结构、内容类型和信息密度，识别表格、图像、代码等多模态内容；2) 选择参数，chunk size 取嵌入模型上下文窗口的 1/4，overlap 多数场景取 10-20%，并设置策略专属参数；3) 处理并验证，应用分块策略后运行 `evaluate_chunks.py --coherence` 验证连贯性，并用代表性文档测试；4) 评估并迭代，测量 precision 和 recall，若 precision < 0.7 则将 chunk_size 减少 25% 后重新评估，若 recall < 0.6 则将 overlap 增加 10% 后重新评估，同时监控延迟和内存占用。
3. 运行验证命令评估分块质量：用 sentence-transformers 计算语义连贯性（`model = SentenceTransformer('all-MiniLM-L6-v2')`，对 chunks 编码后计算 `(embeddings @ embeddings.T).mean()`，目标 0.3-0.7）；计算检索 precision（`relevant / len(retrieved)`，目标 >= 0.7）；用 numpy 检查分块大小分布（均值、标准差、最小值和最大值）。
4. 固定大小分块示例：使用 `RecursiveCharacterTextSplitter(chunk_size=256, chunk_overlap=25, length_function=len)` 并调用 `split_documents(documents)`。
5. 结构感知代码分块示例：用 `ast.parse(code)` 解析 Python 代码，遍历 AST，对 `ast.FunctionDef` 和 `ast.ClassDef` 节点用 `ast.get_source_segment(code, node)` 提取源码作为 chunk。
6. 语义分块示例：将文本切分为句子并生成嵌入，逐句计算相邻句子的 `cosine_similarity`，若相似度低于阈值 0.8 则结束当前 chunk 并开启新 chunk，否则追加到当前 chunk，最后合并输出。
7. 遵循核心原则：在上下文保留与检索精度之间取得平衡，保持 chunk 内语义连贯，并针对嵌入模型上下文窗口约束进行优化。
8. 实施时从固定大小（512 tokens、15% 重叠）开始，根据文档特征迭代，并在部署前用领域特定文档测试。
9. 避免常见陷阱：过度分块导致上下文贫乏的小 chunk、分块不足导致超大 chunk 丢失信息、忽略语义边界和文档结构、对多样内容采用一刀切方案。
10. 注意资源约束：语义方法需要大量计算资源，Late Chunking 需要长上下文嵌入模型，复杂策略会增加处理延迟，大批量文档需监控内存。
11. 满足质量要求：处理后验证语义连贯性，部署前用代表性文档测试，确保每个 chunk 能独立表意，并对格式错误的内容实现错误处理。

适用边界 · 注意事项

• 简单文档或对检索质量要求不高的场景，无需使用语义分块等复杂策略
• 计算资源或延迟预算有限时，避免使用语义方法、Late Chunking 等重计算策略
• 内容类型高度多样时，不要对所有文档套用同一套分块参数