RAG 工程化：从切分到重排的调优实录
RAG 的 demo 十分钟能搭出来：Embedding + 向量库 + Prompt 拼接。但一上生产就露馅：答非所问、漏召回、幻觉。这篇文章用招聘平台知识库（FAQ + 规则文档）做案例，记录把答案准确率从 55% 提到 85% 的全过程。
一、基线：先搭一个能跑的
基线参数：
- 切分：固定 500 token，重叠 50
- Embedding：通用 embedding 模型
- 检索：向量 top10
- 效果：准确率 55%——能答，但经常漏关键信息、答非所问
二、第一刀：切分不是"均匀切块"
固定 500 token 切分的痛：一个完整规则被切到两段里，上下文断裂。
按语义结构切
招聘规则文档是天然结构化的（标题 + 段落 + 列表）。用 markdown 结构切分：
效果：召回完整率从 55% → 68%。切分的第一原则：尊重文档结构，而不是平均切。
三、第二刀：混合检索，别只靠向量
向量检索对"语义相近但用词不同"好，对"精确关键词/编号/规则号"差。
招聘规则里全是"旷工 3 次"“竞业协议 12 个月"这种精确数字——BM25 一搜一个准。混合后准确率 68% → 76%。
四、第三刀：重排（Rerank）决定上限
Top20 的候选里真正有用的可能就 3 条。重排模型（bge-reranker）把候选按与问题的相关度重新排序，只取前 5 进 Prompt。
重排是性价比最高的一刀：不用改检索逻辑，准确率 +6%。
五、第四刀：上下文压缩（告别 Prompt 爆炸）
Top5 每段 500 token = 2500 token 塞进 Prompt，其中一半是噪音。上下文压缩：
输出控制在 800 token 内的精华。好处：准确率 82% → 85%（噪音少了，LLM 更聚焦）；token 成本降 60%。
六、完整的调优链路
| 环节 | 方案 | 准确率 |
|---|---|---|
| 基线 | 固定切分 + 纯向量 | 55% |
| +语义切分 | 按文档结构 | 68% |
| +混合检索 | 向量 ∪ BM25 | 76% |
| +重排 | bge-reranker top5 | 82% |
| +上下文压缩 | 提取精华 | 85% |
七、评测：没有评测就没有调优
调优的前提是能量化。建一个 200 条 QA 评测集（真实用户问题 + 标准答案 + 文档来源），每条跑完让 LLM 打分（相关/部分/不相关），跑批算准确率。每次改动跑一遍评测集，不凭感觉调参。
八、踩坑记录
坑 1：Embedding 没更新
文档更新后向量库里的旧向量还在，检索到过期内容。文档更新要联动向量删除/覆盖，或用带版本号的 chunk ID。
坑 2：重排模型要进服务端
Rerank 别在客户端做（模型文件几百 MB），服务端封装 /rerank 接口，配一个 GPU 实例专门跑。
坑 3：Prompt 里的"参考答案"要标明来源
让 LLM 引用来源（[来源: 考勤制度.md 第3节]），幻觉率大降——LLM 知道答案要可溯源，就不敢编了。
坑 4：多轮对话的上下文污染
“它”、“这个规则"指代上文的检索片段，第二轮就丢了。多轮场景把对话历史也做检索（HyDE），或把上一轮引用片段保留在上下文里。
总结
RAG 工程化的主线：
- 切分尊重结构：语义块 > 固定块
- 检索混合：向量 + 关键词互补
- 重排定上限：TopK 质量比数量重要
- 压缩减噪音：精华进 Prompt，省 token 又提准
RAG 没有银弹，每一刀 +5~8%，叠起来就是 85%。而且永远带着评测集调优——数据说话，不靠感觉。
