LLM Wiki / RAG
Chunking 工程指南：文档怎么切，RAG 上限就在哪
系统拆解 PDF、网页、表格、代码和长文档的分块策略，以及 Parent-Child、层级索引、上下文化 Chunk 的工程取舍。
Chunking 是 RAG 里最容易被低估的环节。很多团队一开始按固定长度切块，系统能跑，但一到真实文档就出现上下文断裂、表格失真、引用错位和召回噪声。
核心判断
Chunk 不是一段文本，而是一个可检索、可引用、可授权、可回溯的知识单元。分块策略决定了后面检索和生成的上限。
分块前先看文档类型
| 文档类型 | 分块重点 | 常见风险 |
|---|---|---|
| Wiki / Markdown | 标题层级、锚点、段落边界 | 切掉标题后 chunk 失去上下文。 |
| 页码、版面、页眉页脚、表格 | OCR 断行、表格错列、重复页眉污染。 | |
| 表格 | 表头、行列关系、单位 | 直接转 Markdown 后丢语义。 |
| 代码 | 函数、类、注释、示例 | 按长度切会截断函数体。 |
| 长报告 | 摘要、章节、引用、附录 | Top-K 容量不足，跨章节问题答不好。 |
常见策略
| 策略 | 优点 | 代价 |
|---|---|---|
| 固定长度 | 简单、稳定、实现快 | 容易切断语义。 |
| 语义分块 | 保留自然段落和主题 | 边界不稳定，解析成本高。 |
| 层级分块 | 适合手册、报告、Wiki | 需要维护标题树。 |
| Parent-Child | 小块召回，大块补上下文 | 上下文组装更复杂。 |
| Contextual Chunk | 给 chunk 补充标题和摘要 | 生成上下文有成本，可能引入噪声。 |
推荐 Chunk Schema
生产系统里，chunk 至少应该包含这些字段：
{
"chunk_id": "doc_2026_policy_003",
"document_id": "doc_2026_policy",
"title_path": ["HR Policy", "Remote Work", "PTO"],
"text": "...",
"parent_id": "section_remote_work",
"source_url": "https://...",
"page": 12,
"updated_at": "2026-07-06",
"acl_groups": ["hr", "employee"],
"doc_type": "policy"
}Parent-Child 的典型链路
小 chunk 负责精确命中，parent chunk 负责补全上下文。这个策略通常比单纯增大 chunk size 更稳。
如何评估分块策略
| 指标 | 说明 |
|---|---|
| Recall@K | 正确证据能否被召回。 |
| Context Precision | 上下文里噪声是否太多。 |
| Citation Accuracy | 引用是否能精确指向原文。 |
| Token Cost | 最终上下文是否过长。 |
| Update Cost | 文档更新后需要重建多少索引。 |
Chunking 没有通用最优。最好的策略来自文档类型、问题类型和评测结果，而不是来自某个固定 chunk size。
讨论
继续讨论这篇笔记
有问题、补充案例或不同观点，可以通过 GitHub Discussions 继续交流。