从去年开始给几个项目搭 RAG 系统，踩了一些坑，写下来备忘。
文档切分不是越小越好
一开始以为 chunk 越小越精准，结果切到 256 token 之后，检索命中率反而下降。原因是上下文被切断了 — 一个问题对应的答案散落在三个 chunk 里，召回只能命中其中一个。
后来改成了 512 token + 64 token overlap，命中率从 60% 出头提到了 85% 以上。具体数字看业务场景，但原则是：chunk 要包含完整的语义单元，而不是按固定长度硬切。
向量数据库选型
试了 Chroma、Qdrant 和 Milvus（轻量版）。结论：
- Chroma — 适合原型阶段，部署零成本，但数据量大之后查询性能掉得很快
- Qdrant — 单机部署，Rust 写的，性能不错，API 设计合理
- Milvus — 功能最全，但运维成本也最高，小团队慎重
目前生产环境用的 Qdrant，单节点扛百万级向量没问题。
多路召回 + 重排是关键
只用向量检索很多时候不够准。现在标准做法是：
- 向量检索粗筛（top 20）
- BM25 关键词检索（top 10）
- 合并去重后交给 reranker 精排（取 top 5）
- 这 5 条送给 LLM 生成答案
reranker 我用的是 bge-reranker-v2-m3，CPU 就能跑，120ms 内能处理 20 条。比直接用 LLM 做重排便宜一个数量级。
幻觉控制
评测体系比模型本身更重要。现在的做法：
- 答案溯源：每个 claim 必须关联到原文片段
- 置信度打标：不确定的答案要在 UI 上让用户知道
- 人工抽检 + 自动化回归：每周抽 50 条，跑一遍自动化评测脚本
RAG 本身不能消除幻觉，但把幻觉率从 15% 压到 3% 以内是能做到的。关键在于检索质量 + 溯源机制，而不是换更强的模型。