RAG 系统有哪些常见陷阱?

这道题其实问的是[[RAG]]落地时怎么平衡检索质量、上下文利用和生成效果，避免出现检索一堆但生成瞎编的尴尬。我重点讲几个实战中容易踩坑的地方。

先说检索。[[分块]]策略是个基础但容易翻车的点。固定切分简单，但遇到表格、代码或长段落，边界切在语义中间，检索召回率直接崩。我会优先按语义切，实在不行用Chunk重叠加LLM辅助判断边界。块大小一般256到512 tokens，太大模型上下文窗口塞不下，太小丢信息。前提是你的文档结构清晰，如果文档质量差，语义切分反而更乱，那不如固定切分加overlap兜底。

检索召回阶段，很多人只做向量检索，但通用[[Embedding]]在垂直领域效果很差。我会做 [[混合检索]]，向量加[[BM25]]关键词两条腿走路。向量负责语义，BM25负责精确匹配，比如订单号、错误码这种。然后一定要加 [[重排]]，用[[Cross-Encoder]]把Top-K结果精排一遍，这是性价比最高的优化，能显著提升最终生成质量。不过重排有延迟，如果要求实时响应，得权衡一下。

再来看上下文处理。检索回来的chunk往往有重复或者不相关的内容，直接塞给模型会稀释注意力。我会做两步：先去重，用语义相似度或MMR算法，避免同一信息反复出现；再过滤，设一个相关性阈值，分太低的直接扔掉，宁可少一点也不能让噪声干扰生成。但这里有个坑：阈值设太高可能漏掉关键信息，尤其当问题复杂时。所以我会 动态调整检索数量，简单问题3-5条，复杂问题10条以上，同时根据置信度动态裁剪。

生成阶段，prompt设计很关键。我会明确告诉模型："仅基于以下材料回答，不知道就说不知道"，并且在prompt里要求它生成引用标记，比如[来源1]，这样事后能校验答案和原文是否一致。这也是抑制[[幻觉]]的重要手段。另外，我会让模型输出置信度评分，低分答案走人工复核。实际业务中，比如客服退款场景，文档里政策可能有冲突，比如满减和优惠券能不能叠加，模型需要主动说明分歧，不能自己编一个规则。这里有个常见的失败场景：检索内容很多但模型根本不看，自说自话。所以上线后我会监控 上下文利用率，看看模型是不是真的在引用检索结果。

另外，评估体系不能只看Top-1命中率，要关注召回率和MRR。离线评估时，我会把检索和生成分开测，检索用Recall@K，生成用F1或人工评分。但更关键的是在线效果，比如用户满意度或任务完成率。如果发现生成质量差，可能是检索没召回关键信息，也可能是prompt没约束好。这时候我会先分析失败case，定位是检索还是生成的问题，再针对性优化。

所以整体上，我会把RAG看成 ，不是简单搭个管道就完事。每一步都要有评估和兜底，尤其是幻觉抑制和上下文利用，这两个是RAG落地的核心痛点。