真正有用的检索增强
多数 RAG 流水线效果差的原因与实修手段：分块、混合检索、重排序、引用纪律。
出问题的大多是检索，不是生成
RAG 答错时，团队往往先怪模型。应该先度量：正确答案所在的段落到底有没有被检索进来。
- 段落被检索到了吗？ 没有 → 检索的问题。
- 检索到了但被忽略？ → 上下文/提示词的问题。
- 检索到了仍然答错？ → 这时候才看模型。
被诊断成「幻觉」的病例，多数属于第一种。
分块方式会实质改变结果
分块大小是杠杆最大的旋钮，且没有通用值。合适的大小取决于「回答一个问题所需的最小证据单元」。
- 事实型问答：小块（200–400 token），每块一个要点。
- 操作手册：整段流程保持完整——把步骤拆散就毁了答案。
- 法务/政策：按条款切，绝不在句子中间断开；把所属章节标题写进每个块的正文。
最后一条可以推广：给每个块加上结构上下文（标题、章节路径）。一句「截止期为 30 天」，不知道出自哪份政策就毫无用处。
| 文档类型 | 切分边界 | 理由 |
|---|---|---|
| FAQ | 一问一答 | 天然自包含 |
| API 文档 | 单个接口 | 否则参数与描述被拆开 |
| 叙述性文章 | 段落，10–15% 重叠 | 保留行文连贯 |
| 代码 | 函数或类 | 语法单元，含 import |
混合检索胜于任一单独方法
- 向量检索捕捉语义与同义改写，但抓不住精确標識符——错误码、商品 SKU、专有名。
- 关键词/BM25 精确命中，但对同义词和概念性提问失效。
两个都跑然后合并。即便只是朴素的并集，实践中也强过任何单一方法；用 RRF 做分数融合更好，实现也简单。
如果用户的查询形如 ERR_2049 或 Model-3B，关键词检索就不是可选项。
生成之前先重排
召回 top-k=20 很便宜，把这 20 条重排成精确的 top-5，答案质量会明显改善。模式是：
- 召回 20–50 条候选（快速、偏召回）
- 用交叉编码器或 LLM 对相关性重排打分
- 只把 top 3–5 喂给生成环节
多花一次调用，就能修掉相当大比例的「检索到错误段落」故障。
强制引用，然后验证它
要求答案的每个论断都引用块 ID。两个好处：用户可核实，且你能用程序检查被引用的块是否真的包含该论断。
问完之后再用打分器抽查：块 X 是否支撑了句子 Y？稳定引用已检索块的答案，比凭记忆改写的答案可信得多。
该度量什么
| 指标 | 说明什么 |
|---|---|
| Recall@k | 正确块是否进入了候选集 |
| 引用准确率 | 被引用的块是否真的支撑论断 |
| 无有效上下文率 | 检索多久返回一次无用结果 |
| 块利用率 | 检索来的块是否真被引用到 |
高召回但低利用率，说明你在往上下文里塞垃圾——这时应该减小 k，而不是加更多。