高进阶

RAG分块与召回策略#

一句话答案#

RAG 分块策略影响召回质量：按语义分块优于固定长度，混合检索（向量+关键词）配合重排序提升准确率。

核心要点

四种分块策略对比：

策略	原理	优点	缺点
固定长度	按字符/token 数切分	简单一致	切断语义，丢失上下文
递归字符切分	按分隔符（`\n\n` → `\n` → `.`）递归	保持段落完整性	需调 overlap
语义分块	按 embedding 相似度变化点切分	语义完整性最佳	计算成本高
文档结构切分	按标题/章节/HTML 标签	利用文档自然结构	块大小不均匀

分块参数经验值：

chunk_size：512-1024 token（太小丢上下文，太大引入噪声）
overlap：chunk_size 的 10-20%（保证边界不丢信息）

混合检索 Pipeline：

Query
  ├── BM25 关键词检索 → top-50（精确匹配专有名词/编号）
  ├── 向量语义检索 → top-50（捕获语义相似性）
  └── RRF 融合排序 → top-20 → Cross-Encoder 重排 → top-5

plaintext

RRF（Reciprocal Rank Fusion）公式：

RRF_score(d) = Σ 1/(k + rank_i(d))，k 通常取 60

plaintext

合并多路排序结果，不依赖分数归一化，简单鲁棒。

为什么需要混合检索：

向量检索擅长语义匹配（“怎么退款” ≈ “退货流程”），但漏掉精确关键词
BM25 擅长精确匹配（订单号、专有名词），但缺乏语义理解
二者互补，混合后 Recall 通常提升 10-20%

Parent Document Retrieval：

用小块（200 token）做检索匹配 → 命中后扩展到父块（1000 token）作为上下文
兼顾检索精度和上下文完整性

面试回答（2分钟版）

RAG系统的召回质量很大程度取决于分块策略和检索方式。分块策略方面，固定长度切分简单但容易切断语义完整的段落，语义分块按embedding相似度变化点切分质量更高但实现复杂，实践中常用递归字符切分并设置chunk_size十分之一到五分之一的overlap来平衡边界信息丢失。还有Parent-Document策略，用小块（约400字）做检索精确匹配，命中后扩展到父块（约1500字）作为上下文，兼顾检索精度和上下文完整性。检索策略方面，单用向量检索能捕获语义相似性但可能漏掉关键词精确匹配，单用BM25关键词检索又缺乏语义理解，所以混合检索是主流做法——先分别用向量和BM25关键词检索各召回top-50候选，再用RRF做排名融合（不依赖分数归一化，比线性加权更鲁棒，k取60），最后用Cross-Encoder做Rerank精排到top-5。混合检索相比单路通常能把Recall提升10-20%。配套用离线评测集验证召回率，驱动参数和pipeline优化。

追问与易错

追问方向：

chunk size 怎么选？你们项目用的多大？ → 512-1024 token 是甜区。DocMind 用 sub-chunk ~400 字做检索匹配，parent chunk ~1500 字做上下文扩展，兼顾精度和完整性
BM25 和向量检索的权重怎么调？为什么用 RRF 而不是线性加权？ → RRF 不需要分数归一化（不同检索器分数尺度不同），用排名融合更鲁棒。k=60 是经验值，DocMind 评测验证有效
Rerank 模型怎么选？Cross-Encoder 会不会太慢？ → Cross-Encoder 比 Bi-Encoder 准但慢 100 倍，所以先粗排 top-50 再精排 top-5。延迟约 200-300ms，在可接受范围内
什么情况下 Parent Document Retrieval 比直接检索效果好？ → 当文档有层次结构（标题→段落）且单个 chunk 缺乏上下文时。小 chunk 精确匹配，扩展到 parent 保留上下文完整性

易错点：

❌ “chunk 越小越好” → 太小丢上下文，LLM 无法理解碎片化的信息
❌ “只用向量检索就够了” → 专有名词、编号等需要 BM25 精确匹配
❌ “Rerank 可以弥补召回不足” → Rerank 只能重排已召回的文档，召回阶段漏掉的补不回来