很多团队搭完第一版 RAG 系统后，都会遇到同一个阶段：Demo 演示很惊艳，真实用户一问就露馅——答非所问、张冠李戴、明明库里有答案却说「没有找到相关信息」。这时候第一反应往往是「换个更强的模型」，但根据我们踩过的坑，RAG 答不准的原因里，模型本身通常排不进前五。RAG 是一条流水线：文档解析 → 切分 → 向量化 → 检索 → 重排 → 拼装上下文 → 生成。任何一环掉链子，最后呈现出来的都是「模型答错了」。
这篇文章把最常见的 10 个工程原因按流水线顺序排开，每个原因都给出判断方法和修法。建议对照自己的系统逐条排查，多数团队能在前 5 条里找到主因。
RAG 是一条流水线，答不准的问题往往出在检索侧而不是生成侧。
先做一件事：把「答错」拆成三种情况
排查之前先分类，不同类型对应不同环节：
| 现象 | 大概率出问题的环节 |
|---|---|
| 答案存在但说「找不到」 | 检索：召回失败 |
| 答了但引用错文档、混淆对象 | 检索或切分：召回了错的内容 |
| 引用对了但结论歪了 | 生成：上下文拼装或提示词问题 |
拿 20 个真实的坏例子做这个分类，比盲目调参有效得多。下面进入 10 个原因。
入库阶段：问题从文档解析就开始了
1. 文档解析丢了结构
PDF、Word、网页转成纯文本时，表格被拍平、标题层级丢失、页眉页脚混进正文，是最隐蔽的问题。一份价格表被解析成一串连续数字，无论后面怎么检索都救不回来。
修法：抽查解析结果，尤其是表格和多栏排版页。表格建议转成 Markdown 表格或「字段：值」句式再入库；对扫描件先走 OCR。解析质量差的文档宁可单独处理，也不要混进库里污染检索。
2. 切分把语义切碎了
固定 500 字硬切，会把「问题描述」和「解决方案」切进两个 chunk，检索命中前半段时答案正好在后半段。这是「引用对了但答不全」的头号原因。
修法：优先按标题、段落等结构边界切分，配合 10%–20% 的重叠；给每个 chunk 附上「文档名 + 章节路径」的元数据。具体的切分尺寸对比可以看《RAG 文档切分怎么做？Chunk Size 实战对比》。
3. 索引里缺元数据，过滤全靠语义
「2025 年的报销制度」和「2023 年的报销制度」在向量空间里几乎是同一个点。只靠 Embedding 区分时间、部门、版本，必然混淆。
修法：入库时提取时间、来源、部门、文档版本等字段存入向量数据库的元数据，检索时先做结构化过滤再做语义匹配。大多数向量库（Milvus、Qdrant、pgvector 等）都支持 metadata filter，这个能力经常被闲置。
检索阶段：召回不准，生成再强也没用
4. 只用向量检索，丢了关键词匹配
向量检索擅长「意思相近」，但对型号、编号、人名、专有名词经常失手。用户搜「ERR-4032 报错」，向量检索可能召回一堆「常见报错处理」却漏掉那篇标题就叫 ERR-4032 的文档。
修法：上 Hybrid Search，BM25 关键词检索和向量检索并跑，用 RRF 融合结果。三种检索方式怎么选，我们在《向量检索、BM25、Hybrid Search 应该怎么选》里做了详细对比。
5. 用户的问题本身不适合直接拿去检索
用户问「那这个和上个月说的政策冲突吗」，这句话里没有任何可检索的实体。直接拿去查，召回结果基本是噪声。
修法：加一步查询改写（Query Rewriting）：让模型结合对话历史把问题改写成独立完整的查询，必要时拆成多个子查询分别检索。这一步用小模型就够，延迟增加有限，收益通常立竿见影。
6. Top-K 和相似度阈值拍脑袋定
K 取 3 容易漏，K 取 20 又把噪声塞满上下文；不设阈值时，哪怕库里根本没有相关内容，也会硬凑 K 条「最不不相关」的结果让模型强答——这是幻觉的重灾区。
修法：召回条数放宽（如 Top 20–50），交给重排序收窄到 3–5 条；设置相似度下限，低于阈值就明确回答「知识库中未找到」，并把这类问题记录下来作为补充语料的依据。
7. 没有重排序（Rerank）
向量相似度高不等于「能回答这个问题」。粗排召回的 20 条里，真正相关的可能排在第 8、第 15 位，而模型对上下文开头的内容更敏感。
修法：加一层 Cross-Encoder 重排（bge-reranker、Cohere Rerank 等都可以），对候选逐条打「是否能回答该问题」的分。为什么这一步性价比高，见《Rerank 是什么？为什么 RAG 经常需要重排》。
排查 RAG 问题时，先看检索日志里召回了什么，再看模型说了什么。
生成阶段：最后一公里也会翻车
8. 上下文拼装粗暴，模型看不出边界
把 5 个 chunk 直接首尾相连塞进提示词，没有来源标注、没有分隔符，模型很容易把 A 文档的条件接到 B 文档的结论上。
修法：每个片段带上编号和来源（如 [1] 《差旅制度 v3》第 2 章），要求模型回答时引用编号；提示词里明确「仅根据以下资料回答，资料不足时直说」。同时控制拼装总量，上下文并非越长越好，参考《长上下文模型真的更强吗？失效场景实测》。
9. 知识库本身过期或互相矛盾
新旧两版制度同时在库，检索各召回一条，模型只能随机站队。这类问题看起来是「模型不稳定」，实际是数据治理缺位。
修法：建立文档生命周期：新版本入库时旧版本标记 deprecated 或直接下线；同一主题保留唯一权威版本；定期跑「同问多答」检测，发现矛盾来源就人工裁决。
10. 没有评估集，一直在凭感觉调
改了切分、换了模型，到底变好还是变坏？没有评估集就只能靠老板试用两句下结论，这也是很多 RAG 项目反复横跳的根源。
修法：从真实用户问题里挑 50–100 条建评估集，标注期望命中的文档和要点答案，每次改动跑一遍，至少看两个数：检索命中率（正确文档是否进入 Top-K）和答案要点覆盖率。可以用 Ragas 之类的框架，也可以先用一个简单脚本起步——有比没有重要得多。
没有评估集的 RAG 调优等于蒙眼开车，50 条真实问题就能起步。
适用人群与替代方案
这篇清单适合已经有 RAG 系统、正在被答准率困扰的开发和产品团队。如果你还没搭系统，可以直接把这 10 条当成设计检查表。也要提醒一句：不是所有场景都需要 RAG——文档总量很小（几万字以内）可以直接全文塞进上下文；知识几乎不更新的固定问答，用微调或写死 FAQ 可能更省事；需要多跳推理、跨文档关联的复杂场景，可以评估 GraphRAG 或知识图谱方案。
常见问题
Q：换 GPT-5、Claude 这类更强的模型能解决多少？ A：只能改善第 8 类问题（上下文利用），对召回失败（1–7 类）完全无效。检索没找对，再强的模型也只能编。
Q：10 条全做要多久？ A：不必全做。按「先分类坏例子 → 定位主要环节 → 修 1–2 条 → 跑评估集」循环推进，多数团队第一轮修掉切分和 Hybrid Search 后，命中率就有明显提升。
Q：这些结论适用于 Dify、FastGPT 这类平台吗？ A：适用。平台把流水线封装了，但切分参数、检索模式、重排开关、阈值都暴露在配置里，排查思路完全一样。
小结
RAG 答不准，先查检索，再查数据，最后才怀疑模型。把坏例子分类、建一个小评估集、按流水线逐环排查，比任何「玄学调参」都快。这 10 条修完，大部分系统的可用性会上一个台阶；剩下的长尾问题，就交给持续的数据治理和评估迭代。