RAG实战踩坑实录：为什么你的检索比生成还难搞？🧠

兄弟们，最近团队在搞一个企业级知识库问答系统，我负责落地RAG（检索增强生成）。听起来高大上，实际干起来全是坑。来，直接上干货。

先说说检索这一块。很多人以为扔个Embedding模型，把文档向量化就完事了。天真！**检索质量直接决定了生成效果的上限**。我踩的第一个坑：用通用的Embedding模型（比如text-embedding-ada-002）去匹配垂直领域的技术文档，结果Top-5召回率低到30%。解决方案？要么微调Embedding，要么改用BM25+向量检索的混合策略。别偷懒，先跑个AB测试。

然后是分段策略。文档切得太碎，上下文丢失；切得太粗，检索噪声爆炸。我的经验是：按段落+语义边界切，每个块保留标题层级信息。比如“3.2 部署配置”这种，检索时把父标题拼进去，召回准确率能提15%。

最后是生成环节。大模型拿到检索结果后，别直接怼。**系统提示词里一定要写“如果检索内容无关，请明确说不知道”**，否则模型会一本正经地瞎编。我见过最离谱的：检索到一篇安卓开发文档，结果模型硬说iOS也能用。

部署时注意性能瓶颈。检索端用FAISS+量化，生成端用vLLM或TGI，延迟控制在2秒内才算合格。预算不够？先上开源模型，比如Llama 3.1 8B，性价比王炸。

**抛个问题**：你们在RAG里处理过“检索结果多但矛盾”的情况吗？怎么应对？比如两份文档对同一个API的配置说法不一致。