你的RAG应用为什么总“胡说八道”？这份21项优化自查清单，帮你根治AI幻觉

推荐语

还在为RAG应用的"幻觉"问题头疼？这份21项优化清单帮你从根源解决AI胡说八道的难题。

核心内容：
1. 作者亲身经历的两次典型RAG应用失败案例
2. 用"开卷考试"比喻揭示RAG系统工作原理
3. 21项优化检查点构成的完整解决方案清单

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

关注我，让我的实验，成为你的经验。

大家好，我是dify实验室的超人阿亚。

你是否也经历过这样的“社死”瞬间：信心满满地向老板或客户演示你搭建的智能知识库问答机器人，结果它面对一个简单的问题，却给出了一段看似专业、实则完全捏造的答案。场面一度十分尴尬，你开始怀疑人生：“我明明把所有资料都喂给它了啊！”

别灰心，你不是一个人在战斗。RAG应用中的“幻觉”问题，是每个AI应用开发者都会遇到的拦路虎。今天，我想跟你分享我从无数次失败和调试中总结出的经验，帮你彻底搞懂AI“胡说八道”背后的根源。

核心1：我的两次“踩坑”实录

一开始，为了搭建一个内部的Dify技术文档问答助手，我和大多数人一样，也走了不少弯路。

弯路一：“大力出奇迹”法

我的第一个想法简单粗暴：把我们积攒的数百份Markdown和PDF文档，一股脑儿全扔进了Dify的知识库。我想象中，数据量越大，AI知道的就越多，效果肯定越好。

结果呢？ AI的表现非常精神分裂。有时候能精准回答，但更多时候，它会从A文档里抓一段，再从B文档里拼一段，合成一个看似合理、实则牛头不对马嘴的答案。海量的数据成了“噪音”的海洋，AI彻底迷失了。

弯路二：“提示词炼丹”法

既然数据多了不行，那我优化Prompt总行了吧？于是我开始了漫长的“炼丹”之路。我写出了长达上千字的系统提示词，用尽了各种限定词： “你必须”、“你不能”、“你只能依据我提供的上下文”、“如果找不到就回答不知道”……

结果呢？ 效果略有提升，但治标不治本。就像一个学生，虽然你反复告诉他“不许抄”，但他连考纲（检索的上下文）都是错的，再怎么强调考试纪律也无济于事。

核心2：从“考试”中顿悟RAG的真相

在经历了无数次失败后，我终于悟了。我找到了一个绝佳的比喻来解释RAG的原理：

RAG的本质，就是让大模型进行一场“开卷考试”。

用户的提问是“考题”，知识库是“教科书”，而我们的RAG应用，就是那个帮模型“翻书”的助教。

模型本身再聪明，如果助教（检索系统）递给它的参考资料是错误的、混乱的、不完整的，那么它也只能基于这些“垃圾”资料进行“创作”，这不就是幻觉的来源吗？

所以，检索（Retrieval）的质量，决定了生成（Generation）的上限！ 我们的核心任务，不是去训练一个无所不知的AI，而是设计一个最高效、最精准的“图书管理员”，确保递给AI的每一页资料都是正确答案。

核心3：根治幻觉的21项优化自查清单

基于“开卷考试”这个核心思想，我为你整理了一份包含21个检查点的清单。它覆盖了从“备考资料”处理到“考试技巧”的全流程，跟着它逐项排查，一定能大幅提升你的RAG应用效果。

第一部分：知识库构建（“教科书”的质量）

1. 数据源质量：
    原始文档本身是否存在错误、过时或矛盾的信息？（垃圾进，垃圾出）
2. 文档解析：
    PDF、Markdown、HTML中的表格、代码块、图片注释是否被正确解析？有没有乱码？
3. 切片策略 ：
    是否还在用固定长度切片？尝试按句子、段落或Markdown标题进行“语义切片”，保证上下文完整。
4. 切片大小：
    切片是否过大（包含太多噪音）或过小（丢失关键上下文）？这个尺寸需要根据你的文档特性和使用的Embedding模型进行调试。
5. 切片重叠：
    切片之间是否有足够的重叠部分，以确保一个完整的语义单元不会被硬生生切断？
6. 元数据 ：
    是否为每个切片都附上了来源、章节、日期等元数据？这对于后续的精准过滤至关重要。
7. 清洗与预处理：
    是否移除了无意义的页眉、页脚、版权声明、广告语等噪音文本。

第二部分：检索策略优化（“翻书”的技巧）

8. Embedding模型选型：
    你选择的Embedding模型是否适合你的业务领域和语言？（例如，代码知识库和法律文书库用的模型可能不同）
9. Top-K参数：
    召回的文档片段数量（K值）是多还是少？太多会引入噪音，太少可能错过正确答案。一般建议从3-5开始测试。
10. 重排模型 ：
     在召回Top-K个结果后，是否引入了Re-ranker模型进行二次排序，把最相关的结果排在最前面。
11. 混合搜索：
     是否只依赖了语义搜索？对于专有名词、代码函数等，结合传统的关键词搜索（如BM25）往往效果更佳。
12. 查询扩展：
     当用户问题很短或很模糊时，是否尝试用LLM对原始问题进行改写、扩展和丰富，以提高召回率。
13. 元数据过滤：
     在进行语义搜索前，能否利用元数据（如日期、文档类别）先筛选掉大量不相关的文档。
14. 多路召回：
     对于复杂问题，能否将其拆解为多个子问题，分别进行检索，然后合并结果？

第三部分：生成与提示工程（“答题”的规范）

15. 生成模型选型：
     用于最终生成答案的LLM，其推理和遵循指令的能力是否足够强？有时候问题不出在检索，而出在生成模型太弱。
16. “根据上下文”指令：
     系统提示词中是否明确、强硬地要求模型“必须且只能”根据提供的上下文来回答问题？
17. “不知道”指令：
     是否明确告诉模型，如果在上下文中找不到答案，应该直接回答“根据已有信息，我无法回答这个问题”，而不是自己创造答案。
18. 上下文格式：
     喂给模型的上下文格式是否清晰？用Markdown引用、XML标签等方式把多个文档片段清晰地分隔开，能有效提升模型理解力。
19. Temperature参数：
     将大模型的Temperature参数设置为0或一个极低的值（如0.1），可以有效降低其“创造性”，让回答更稳定、更忠于原文。
20. 引用与溯源：
     是否要求模型在回答时，必须注明信息来源于哪个文档片段？这不仅能提升可信度，也方便用户快速溯源核对。
21. 建立评估与反馈闭环：
     是否提供了一个简单的机制（比如点赞/点踩），让用户可以反馈回答的好坏？这是持续优化的数据金矿。

升华：从Demo到生产级的思考

完成了上述清单，你的RAG应用应该已经从“胡说八道”进化到了“有理有据”。但要投入生产环境，我们还需要考虑更多：

• 知识的动态更新：
   现实世界的文档是会变化的。如何设计一套高效的增量、更新、删除知识库的流程？
• 权限与隔离：
   如何确保不同用户只能检索到他们有权限访问的知识？
• 持续评估：
   如何建立一套自动化的评估体系（如使用RAGAS框架），来持续监控线上应用的效果，防止效果衰退。

这些问题，我们dify实验室后续会推出更深入的实战文章来探讨。

附赠：我的工具箱推荐

• Embedding模型：
   BGE-M3，目前市面上最强大的开源多语言Embedding模型之一，推荐在Dify中配置使用。

你是否在搭建RAG应用时也遇到过其他“奇葩”的幻觉问题？或者，你有什么独到的优化技巧？

从Demo到生产还有很长的路，但每一步都算数。

我是阿亚，我们下次再聊！

请点个「赞」或「在看」，让需要的人也能看到它。