RAG 系统落地的8个常见问题和解决方案

关于什么是 RAG，我有零基础级别科普过，你可以点击这里查看。

这篇聚焦落地过程的具体问题及解决方案。

一共 8 个常见问题：

1. 1. 不按「知识库」的答案回答，自作主张
2. 2. 相同的问题不能保证每次回答准确，甚至很多时候是错的
3. 3. 回答不完善，而「知识库」中明明有完整答案
4. 4. 正确答案和错误答案并存
5. 5. 范范回答，没有细节 / 面面俱到，事无巨细
6. 6. 回答不显示配图
7. 7. 响应非常慢，甚至直接崩坏
8. 8. 回答问题片面，不能正确“选用”合适的支持资料

在最开始

搭建 RAG 产品/系统，90%的功夫应该花在知识库资料处理上。

“巧妇难为无米之炊”。

在 RAG 系统里，AI 大模型只在最后一步发挥价值。这个“巧妇”不可能把“烂树叶”做成一顿能果腹的晚饭。

前面这 7 个常见问题，只有 1 和 5 是由“巧妇”负责的，其他 5 个都因为我们给她投喂了烂树叶。

1自作主张回答问题

出现这个问题的根本原因是没搞懂 RAG 的本质。

在 RAG 系统里，大模型只负责两件事：

1. 1. 判断这个问题能不能回答
2. 2. 答案编辑

之所以出现“自作主张”，大部分时候是没有明确大模型的职责

既然选择了 RAG，就意味着我们已经不相信大模型生成的答案里

不相信，就坚持到底：不要一边不信任，一边委以重任。

RAG 系统里，关于角色和任务的标准描述结构：

角色描述：一个没有主观能动性的角色，比如助理
任务情景：接收问题和支持资料，编辑输出文本

任何试图使用如下“祈祷式”提示词约束大模型的行为，都是外行的表现：

1. 1. 不要胡编乱造
2. 2. 不要生成不存在的答案
3. 3. 确保你的回答准确（尊重事实）
4. 4. ……

2回答不稳定

核心原因有两个：

1. 1. 问题本身有问题，无法稳定的检索到正确的答案
2. 2. 资料和排序有问题，无法稳定的召回正确的答案

是的，“用户的问题”有问题不是用户的问题，是你的问题。

我们不能要求用户都是专业的用户，因为专业的用户大概率不会使用我们的产品……

大部分用户在提问时，不会像我们一样从「知识资料」出发，使用完整、全面的描述。

大部分时候，他们的问题会类似下面这样：

1. 1. 有没有产品说明资料？
2. 2. 登录按钮点击没反应
3. 3. 苹果可以么？

LightRAG 以查询优化狂揽 17K Star 不是没道理的，强烈建议去看一看它们的工程优化。

假设你已经明确了大模型的职责（编辑），那么影响它回答的关键因素就是我们给了它什么参考资料。

选择什么支持资料给大模型，依赖两个因素：

1. 1. 能回答用户问题的资料能不能被检索到
2. 2. 资料有没有排在前面被找回

因为资料的形态千奇百怪，当前还没有方案能保证资料被 100% 检索到。

但可以使用如下三个方案来优化：

1. 1. 对资料进行有效的预处理，确保分段合理（起码完整的答案没有被切碎）
2. 2. 对资料进行二次加工，比如抽取关键词 + 提取可能的问题
3. 3. 选一个高纬度的嵌入模型，增强语义识别能力

关于答案排序问题（因素二），一味的花钱买贵的 Rerank 也不是唯一解。

多花些精力调整混合权重、Score 阈值，仔细看看召回答案的特征获取更有效。

3回答不完善

出现这种问题的原因基本只有一个：文档分段不合理，完整的答案被切开了。

而只有一段被召回。

解法只有一个，去看召回的段落，重新分段。

不要偷懒使用自定义分段，或者简单粗暴的选择按字符数分段。

另外需要注意一个细节：知识库分段里的“按标识符”分段和“分段最大长度”是同时生效的。

更值得注意的是，那些残缺的答案是大模型幻觉的主要来源！

4包含错误回答

两个原因：

1. 1. 召回段落中包含不相关答案，导致了大模型的幻觉
2. 2. 让大模型生成答案的提示不够

召回策略里的 Top K 不是越大越好，在没有相似度阈值约束的情况下，召回的段落越多，不相关的答案就越多。

如果你在这个环节没有妥善的解决方案，就只能在最后的“兜底”提示词里下功夫：告诉大模型如何判断哪些答案是有效的，如何剔除不相关段落。

一般情况下，我会在生成最终答案的提示词里加这么一句话：

审视支持资料与用户问题的相关性，有些资料可能被错误的放进来，但它们并不能用户回答用户的问题，你可以选择不取用。

5没有细节/全是细节

这是一个响应格式问题，它与“没法让 RAG 系统按指定格式生成答案”一样。

本质上是，你在最后的兜底提示词没讲清楚，或者失效了。

这个问题只有两个解法：

1. 1. 给出回答示例，而不是描述要求
2. 2. 把约束放在提示词最后，user prompt 值得再放一遍

6没有配图

所有知识资料都应该被转成 Markdown 后再去分段。

Word、PDF 这类格式是给人看的。

你看到的，跟大模型最终接收到的，会是完全两个面貌。

尤其是图片相关内容

先确保你深刻理解了 RAG 的基本原理，再来思考为什么不显示图片，否则下面的解决方案并不能真正解决问题。

告诉大模型，正确显示 Markdown 或者<img>标记的图片，最好给图片增加注释以方便模型选用。

7响应慢

大模型的首 Token 响应速度，除了受模型本身质量影响外，上下文长度是另一个非常重要的因素。

即便你心疼 Token 费用，也务必从响应速度的角度考虑，对支持资料进行分段处理。

2000 个 Token 可以作为分段长度的上限，再大首 Token 的响应时间就要超出 1 秒了，如果没办法使用流式输出，那么整体的响应时间可能会超过 10 秒。

顺便嘱咐一下团队里成熟的工程师，给 API 响应的 timeout 多留一些时间……

8不系统

分段带来的最大问题就是知识的碎片化。

“碎片化知识”对 RAG 系统的影响主要在于召回答案的全面性上，不能直接回答问题、但是作为背景信息或具备关联关系的资料几乎不会被检索到。

目前流行的解决方案有以下两个：

1. 1. 知识图谱增强
2. 2. Agentic 增强

个人此刻更看好只是图片增强的策略，Agentic 会涉及到更多工程侧的优化和提示词规训（主要此刻国内模型 Agentic 不了）。

推荐学习微软的 GraphRAG 项目