RAG 分块策略：通过拆分文档实现更佳检索
大多数 RAG 失败的原因在于你拆分文档的方式。
如果检索效果不佳，不要首先尝试修改提示词（prompt）或更换 LLM。先检查你的分块（chunks）。如果正确的信息已存在于数据库中，但系统却无法找到它，那么问题很可能出在你的分块策略上。
糟糕的分块会导致三个主要问题：
• 边界截断：包含答案的句子被拆分成两部分。这两部分都无法提供足够的信息来匹配查询。 • 上下文稀释：一个巨大的分块中只有一句相关内容，其余十句都是无用的。多余的文本会削弱语义信号。 • 缺失元数据：分块缺乏关于来源或日期等信息，导致无法进行过滤搜索。
使用以下四种策略来优化你的流水线：
1. 固定大小分块 (Fixed-size chunking)
最适用于报告或文章等长篇连续散文。 • 使用 256 到 512 个 token。 • 设置 10% 到 15% 的重叠度（overlap），以防止句子被切断。
2. 语义分块 (Semantic chunking)
最适用于 FAQ 或支持文档等高密度文本。 • 它根据主题转换而非 token 数量来拆分文本。 • 这能将完整的观点保留在一起。
3. 结构化分块 (Structural chunking)
最适用于技术文档、Markdown 或 HTML。 • 它根据标题（H1, H2, H3）来拆分文本。 • 这会增加元数据，以便你可以按章节进行检索过滤。
4. 层级（父子）分块 (Hierarchical (Parent-Child) chunking)
最适用于既需要精度又需要上下文的生产系统。 • 创建小的子块（64-128 tokens）用于精确的向量搜索。 • 将其链接到大的父块（512-1024 tokens）供 LLM 阅读。 • 这让你兼顾两者的优势。
如何选择大小：
• 128–256 tokens：适用于事实查询和技术文档。 • 256–512 tokens：通用场景下的稳妥起点。 • 512–1024 tokens：适用于长篇分析类问题。
金科玉律：在上线之前，务必测试你的策略。
构建一组包含 30 到 50 个真实查询的测试集。标注正确答案。测量你的 recall@3。在 recall 达到 80% 以上之前，不要更换你的嵌入模型（embedding model）。
Optional learning community: https://t.me/GyaanSetuAi