RAG开发者常见问题排查：6步检查清单与3种修复方法

遇到RAG应用回答不准或检索失败时，可以从以下6个环节逐一排查：检查文档切块是否过大（建议512-1024字符）、确认Embedding模型与查询的领域匹配、验证向量数据库索引类型（如IVF或HNSW）、测试检索结果是否按相关性排序、查看大模型上下文窗口是否被截断、核对检索与生成之间的Prompt衔接是否正确。RAG（检索增强生成）让大模型先检索外部知识再生成回答，能有效减少幻觉，但每个环节都可能成为瓶颈。

步骤1：检查文档解析与切块

• 确认原始文档（PDF、Word、Markdown）是否完整解析，避免乱码或丢失内容。
• 切块策略（如固定长度切片或语义分割）会影响检索质量。块太小会丢失上下文，太大则引入噪音。用调试工具输出切块片段，查看是否保留了核心信息。

步骤2：验证Embedding模型选择

• 不同Embedding模型擅长的语种和领域不同。如果查询的是金融术语但用了通用模型，语义向量可能无法准确匹配。换用领域微调模型或对比多个模型的向量距离，可以快速定位问题。
• 检查向量数据库中是否插入了非文本字段（如HTML标签），这些噪音会干扰相似度计算。

步骤3：测试混合检索策略

• 纯向量检索可能漏掉关键词精准匹配的场景。引入BM25关键词检索与向量检索结合，再用RRF（倒数排序融合）合并结果。源3提供的示例显示，混合检索能兼顾语义理解与关键词命中，对技术文档类问答提升明显。

步骤4：审查检索排序与重排

• 向量数据库返回的Top-K结果不一定相关。检查排序依据（欧氏距离或余弦相似度），或添加重排序模型（cross-encoder）对候选结果二次筛选。源4提到“召回/精排”是RAG流程中的关键环节，直接跳过精排可能导致低质片段落入生成。

步骤5：确认大模型上下文窗口

• 检索出的文档片段若超出模型的最大Token限制（如4K或8K），超出的部分会被静默截断。用代码统计输入总Token数，并设置动态截断策略，确保最相关的片段始终位于窗口前端。

步骤6：核对Prompt模板设计

• 检索结果送入大模型之前，Prompt指令必须清晰指定「基于以下内容回答」。如果指令写成了「根据你自己的知识回答」，模型可能忽略检索结果。源1强调RAG的核心是“先搜再答”，Prompt需明确区分检索上下文与模型自身知识。

3种常见场景的修复方法

场景A：检索结果为空或太少。增大检索数量（Top-K从5调至20），或调整相似度阈值（如从0.8降至0.6）。切块粒度也可调到更小，增加候选段落数量。

场景B：答案与检索内容矛盾。检查是模型幻觉还是检索回传了错误片段。在Prompt中加上“如果检索内容与已知信息冲突，请以检索内容为准”，同时排查向量数据库是否混入了过期数据。

场景C：系统响应速度太慢。如果混合检索+重排导致延迟过高，可以改用紧凑型嵌入模型（如all-MiniLM-L6-v2），或对向量索引做量化压缩。源3提供的“向量+BM25+RRF”方案在本地即可跑通，适合前期调试性能瓶颈。

排查RAG问题像逐层拆解管道，每个环节都有对应检查项。把6步清单写进CI测试脚本，发现指标下降时自动告警，能避免上线后排查的被动局面。