RAG文档分块的三种常见策略及选型指南
TL;DR · AI 摘要
RAG文档分块策略需按数据类型选择：技术文档优先语义分块，聊天记录用固定长度加大重叠，API文档按章节切分，避免单一方法导致检索失效。
核心要点
- 固定长度分块（512/1024 token）易截断完整答案，如600 token的Nginx配置被512切分导致信息缺失。
- 滑动窗口分块（50-100 token重叠）防止语句截断，但重复内容会挤占Top-K结果中的其他相关信息。
- 语义分块依赖清晰格式（段落/标题），对内部Wiki、聊天记录等非结构化数据无效，需降级为固定长度策略。
结构提纲
按章节快速跳转。
512或1024 token的固定长度分块虽易于设置，但容易切断完整答案，导致检索结果不完整。
50-100 token重叠的滑动窗口分块可防止语句中间截断，但产生的重复内容会挤占头部结果中的其他相关信息。
语义分块通过结构切分保持语义完整，但对缺乏清晰格式的聊天记录或内部Wiki等非结构化数据无效。
技术文档适用语义分块，聊天记录需固定长度加大重叠，API参考文档应严格按章节切分。
思维导图
用一张图看清主题之间的关系。
查看大纲文本（无障碍 / 无 JS 友好）
- RAG Chunking Strategies
- Fixed-length
- 512/1024 tokens
- Risk: Answer truncation
- Sliding-window
- 50-100 token overlap
- Risk: Result duplication
- Semantic
- Split by structure
- Requires clean formatting
金句 / Highlights
值得收藏与分享的关键句。
512 token的分块会直接切断600 token的答案中间，导致检索只能返回其中一半信息。
同一段落出现在三个重叠分块中且得分都很高，这会填满顶部结果，挤占其他相关内容的空间。
内部Wiki、聊天记录和工单系统通常没有清晰的格式，因此语义分块无法找到切分依据。
先按类型对文档进行分类，正确的分块方法自然随之确定。
标题：Milvus 在 X 上发文：“RAG 文档分块主要有三种常见方法。具体选择哪种，取决于你的文档结构。
固定长度分块（每块 512 或 1024 https://t.co/eXKK3vLC8q” / X
URL 来源：https://x.com/milvusio/status/2062196358673830128
Markdown 内容：
RAG 文档分块主要有三种常见方法。具体选择哪种，取决于你的文档结构。固定长度分块（每块 512 或 1024 个 token）配置最简单，但可能会将完整的答案一分为二。例如，配置 Nginx 超时的步骤需要 600 个 token，而 512 个 token 的分块会直接从中间截断，导致检索时可能只返回其中一部分。即使源文档包含完整信息，用户得到的也是不完整的回答。滑动窗口分块（50–100 个 token 的重叠）可以避免答案在句子中间被截断，但会产生重复内容。同一段落可能出现在三个重叠的分块中，且这三个分块的相似度得分都很高，从而占据了检索结果的顶部位置，挤占了其他相关内容的展示空间。语义分块（按段落、标题或章节拆分）能够保持语义的完整性，但前提是文档格式规范。内部 Wiki、聊天记录和工单系统通常缺乏清晰的结构，因此语义分块无法找到合适的切分点。我们的实践经验如下：• 技术文档：优先使用语义分块，滑动窗口分块作为备选 • 聊天记录和工单：使用固定长度分块，并设置较大的重叠度 • API 文档和配置参考：按章节拆分 首先对文档进行分类，然后据此选择合适的分块方法。
