RAG 中的幻觉是什么？原因分析与防范措施

前言

在学习 RAG 的时候，经常会听到一个词：幻觉。

简单说，幻觉就是：

AI 一本正经地说错话。

它可能回答得很流畅、很自信，甚至格式也很专业，但内容其实并不来自你的知识库，或者和真实资料不一致。

在 RAG 系统里，幻觉是一个非常核心的问题。

一、什么是 RAG？

RAG 全称是：

Retrieval-Augmented Generation
检索增强生成

它的基本流程是：

用户提问 ↓ 将问题向量化 ↓ 从知识库中检索相关文档 ↓ 把检索结果作为上下文交给大模型 ↓ 大模型基于上下文生成答案

RAG 的目标是让大模型不要只靠“记忆”回答，而是参考自己的知识库回答。

二、什么是 RAG 中的幻觉？

RAG 中的幻觉主要指：

大模型生成了看似合理，但实际上没有知识库依据、与检索内容不一致，或者事实错误的回答。

举个例子。

用户问：

项目的文件上传支持哪些文件格式？

知识库里只写了：

支持 TXT、Markdown。

但模型回答：

项目支持 PDF、Word、TXT、Markdown、Excel、PPT、图片 OCR、音频转写等格式。

这个回答看起来很完整，但后面几个格式并没有出现在知识库里。

这就是幻觉。

三、RAG 幻觉常见类型

1. 无依据编造

知识库中没有相关内容，但模型自己补充了答案。

例如：

问：项目是否支持飞书知识库同步？ 答：支持，项目可以自动同步飞书文档。

如果项目实际没有这个功能，这就是幻觉。

2. 检索错了，回答也错了

RAG 的答案依赖检索结果。

如果检索阶段拿到了错误文档，大模型就可能基于错误上下文生成错误答案。

例如用户问：

如何配置 RabbitMQ？

结果检索到了 Kafka 配置文档，模型可能就会答非所问。

3. 上下文不足，模型强行回答

有时候检索出来的内容太少，不足以回答问题。

但是模型为了“完成任务”，可能会强行生成一个答案。

例如：

根据已有资料，项目的最大并发量是多少？

如果知识库没有压测数据，正确回答应该是：

当前知识库中没有相关数据。

但模型可能编造：

项目支持 5000 QPS 的并发访问。

这也是幻觉。

4. 过度总结或错误推理

知识库中有部分信息，但模型推理过头了。

例如知识库中写：

项目使用 Redis 做缓存。

模型回答：

项目使用 Redis Cluster 保证高可用，并通过哨兵机制自动故障转移。

如果项目文档没有说明 Redis Cluster 和 Sentinel，这就是模型过度推理。

四、为什么 RAG 还会产生幻觉？

很多人以为用了 RAG 就不会幻觉，这是误解。

RAG 只能降低幻觉，不能完全消除幻觉。

原因主要有几个。

1. 检索结果不准确

RAG 的第一步是检索。

如果检索结果本身不对，后面生成自然也容易错。

常见原因：

• 文档分块不合理
• Embedding 模型效果不好
• topK 设置不合理
• 只用向量检索，忽略关键词
• 权限过滤错误
• 文档内容质量差

2. 文档分块质量差

如果 Chunk 切得不好，会影响检索效果。

例如把一句完整的话切断：

项目支持 PDF、Word、TXT、

另一个 Chunk 是：

Markdown 等格式的解析。

用户问支持哪些格式时，可能只检索到其中一半，导致模型回答不完整。

3. Prompt 约束不够

如果 Prompt 只是简单写：

请根据以下资料回答用户问题。

模型仍然可能发挥自己的知识。

更好的 Prompt 应该明确要求：

你只能基于给定上下文回答。 如果上下文中没有答案，请回答“知识库中没有相关信息”。 不要编造。

4. 大模型本身有生成倾向

大模型的本质是预测下一个 token。

它擅长生成自然语言，但不天然保证事实准确。

所以即使上下文不足，它也可能给出一个“看起来合理”的答案。

五、如何预防 RAG 幻觉？

1. 提升检索质量

这是最重要的一步。

RAG 的核心不是“生成”，而是“检索”。

如果检索不到正确资料，模型再强也没用。

可以这样做：

1）使用混合检索

不要只依赖向量检索。

推荐：

关键词检索 + 向量检索

可以通过 Elasticsearch 做混合检索：

BM25 关键词搜索 + Embedding 语义搜索

好处是：

• 关键词检索适合精确匹配，如“MinIO”“Kafka”“JWT”
• 向量检索适合理解语义，如“怎么上传文件”“文件如何入库”
• 两者结合，召回效果更好

2）合理设置 topK

topK 表示检索返回多少条相关内容。

如果 topK 太小：

可能漏掉关键信息

如果 topK 太大：

上下文太杂，模型容易被干扰

常见设置：

topK = 3 ~ 10

可以根据问题复杂度动态调整。

3）增加 rerank 重排序

检索出来的 topK 不一定顺序最优。

可以增加 Rerank 模型，对候选文档重新排序。

流程变成：

用户问题 ↓ 召回 top50 ↓ Rerank 重排序 ↓ 取 top5 ↓ 交给大模型生成

这样可以显著提升上下文准确率。

2. 优化文档分块 Chunk

文档分块对 RAG 效果影响很大。

分块原则：

1. 不要太短
2. 不要太长
3. 尽量保持语义完整
4. 保留标题、章节信息
5. 可以设置重叠窗口 overlap

比如：

chunkSize = 500 ~ 1000 字 overlap = 100 ~ 200 字

对于技术文档，可以按标题分块：

一级标题 二级标题 段落内容

而不是机械地每 500 字切一次。

3. 给 Prompt 加强约束

Prompt 是防幻觉的重要手段。

一个比较安全的 RAG Prompt 可以这样写：

你是一个企业知识库问答助手。 请严格根据【上下文】回答用户问题。 要求： 1. 如果上下文中没有答案，请回答：“知识库中没有相关信息。” 2. 不要使用上下文之外的知识。 3. 不要编造功能、数据、时间、人物、链接。 4. 回答时尽量引用上下文中的原文信息。 5. 如果上下文信息不足，请明确说明不足。 【上下文】 {context} 【用户问题】 {question}

这样可以降低模型自由发挥的概率。

4. 设置相似度阈值

不是所有检索结果都应该交给大模型。

如果检索分数太低，说明知识库里可能没有相关内容。

可以设置阈值：

if maxScore < threshold: return "知识库中没有相关信息"

例如：

if(searchResults.isEmpty()||searchResults.get(0).getScore()<0.65){return"知识库中没有相关信息。";}

这样可以避免“无资料硬回答”。

5. 要求模型引用来源

让模型回答时附带来源，可以提升可控性。

例如：

根据文档《项目总结文档》第2节，项目支持 Word、PDF、TXT、Markdown 等格式。

或者在前端展示：

参考来源： 1. 项目总结文档 - 知识库管理 2. 上传模块设计文档 - 文件解析流程

这样用户可以检查答案依据。

如果模型无法给出来源，就说明答案可信度要降低。

6. 对答案做后处理校验

可以在生成后增加一层校验。

例如：

模型回答 ↓ 检查回答是否被上下文支持 ↓ 如果不支持，拒答或重新生成

可以再调用一次模型，让它判断：

请判断下面的回答是否完全由上下文支持。 如果不支持，请指出哪些内容没有依据。

这叫做：

答案一致性校验

7. 控制模型温度参数

temperature 越高，模型越有创造性。

RAG 场景不需要太强创造性，更需要准确。

建议：

temperature = 0 ~ 0.3

不要设置太高。

比如：

temperature = 0.2

会比：

temperature = 0.9

更稳定、更不容易胡编。

8. 权限过滤要准确

如果用户只能访问某个组织的知识库，就必须在检索阶段过滤

否则可能出现：

• 检索到别人的文档
• 回答了用户无权知道的信息
• 造成数据泄露

这类问题虽然不是传统意义上的幻觉，但属于 RAG 结果不可信。

六、防幻觉 RAG 流程

可以设计成这样：

用户提问 ↓ 问题改写/规范化 ↓ Embedding 向量化 ↓ Elasticsearch 混合检索 ↓ 权限过滤 ↓ 相似度阈值判断 ↓ Rerank 重排序 ↓ 构建严格 Prompt ↓ 调用大模型，低 temperature ↓ 答案一致性校验 ↓ 返回答案 + 引用来源

七、总结

RAG 中的幻觉，就是：

模型生成了没有知识库依据，或者与知识库不一致的内容。

常见原因：

1. 检索不准
2. 文档分块差
3. 上下文不足
4. Prompt 约束弱
5. 模型自由发挥
6. 没有相似度阈值和来源校验

预防方法：

1. 使用混合检索
2. 优化 Chunk 分块
3. 加 Rerank
4. 设置相似度阈值
5. 写严格 Prompt
6. 降低 temperature
7. 要求引用来源
8. 做答案一致性校验
9. 做好权限过滤

一句话记住：

RAG 防幻觉的关键，不是让模型更会说，而是让模型只根据可靠资料说。