把LLM接上知识库，为什么它还是会一本正经地胡说？

大模型能在几秒内给出看起来很漂亮的答案。但有时候，它会非常自信地告诉你一个错误的信息，或者一个根本找不到可靠来源支撑的说法。这就是AI幻觉。

在搭建一个基于RAG（检索增强生成）的文档问答项目时，我专门研究了怎么减少幻觉，也发现了一个问题：仅仅把大模型接上一个知识源，并不够。

先看大模型为什么会幻觉。LLM生成回答的方式，是学习语言中的模式，然后预测下一段文字应该是什么。它不会自动把每一句话拿去和事实核对一遍。

幻觉可能来自这几种情况：

• 知识缺失：模型没有回答问题所需的信息。
• 问题含糊：一个问题可以有多种理解方式。
• 上下文缺失：模型缺少相关文档或证据。
• 信息误导：拿到的上下文本身是错的或不完整的。
• 过度自信的生成：模型给出一个看似合理的答案，而不是承认自己不确定。

说白了，一个流畅的答案，不一定是事实正确的答案。

RAG的思路是把信息检索和答案生成结合起来。它不只依赖模型已经知道的东西，而是先从外部知识源里检索相关信息，再把这段信息作为上下文交给模型。

比如你问“这份报告里的三条主要建议是什么”，RAG会先从报告里检索出相关段落，在模型生成答案之前把这些段落提供给它。

整个流程是：文档 → 切块 → 向量化 → 向量数据库 → 检索 → 上下文 → LLM → 答案。

这相当于给模型提供了可用的证据，而不是让它只凭记忆作答。但RAG只是降低幻觉风险，并不能消除幻觉。RAG有两个失败点：检索到了错误的段落，或者模型在正确的段落之外添加了没有依据的说法。

RAG同时依赖检索和生成，任何一个环节出问题，都可能产生不可靠的答案。

• 切块不当：重要信息被切走，和它需要的上下文分离了。
• 检索错误：系统检索到不相关的段落，或者漏掉了正确的那一段。
• 文档不完整：源文件本身就没有答案。
• 理解偏差：LLM误解或忽略了检索到的信息。

设想一个问题，答案在某个PDF的第42页。如果检索器返回的是第12、18、63页的不相关段落，模型手里就没有它需要的证据，但它仍然可能生成一个看似合理的答案。就算检索正确，模型也可能误解检索到的文本。

所以要先判断失败发生在检索环节还是生成环节，再决定怎么修。RAG的价值，取决于它检索到的证据，以及模型使用这些证据的能力。

减少幻觉没有一招通吃的办法，几种技术要配合使用。

更好的检索：选用合适的嵌入模型、元数据过滤、混合搜索或重排序，找到真正相关的证据。

更好的提示词：明确要求模型只根据提供的上下文作答，并承认信息缺失。比如在提示里写清楚：只用下面的上下文回答问题；如果上下文信息不足，明确说明信息不足；不要编造没有依据的细节。

这样的提示会促使模型把答案建立在检索到的段落上，而不是用听起来合理的内容去填空。证据不够时，模型被要求承认这一限制。

更好的上下文：调整切块大小和重叠度，去掉不相关的段落，避免用无关文本把模型淹没。

置信度和相关性检查：用相似度阈值或其他验证方法识别弱检索结果。这里有个细节值得注意：相似度分数不等于置信度百分比，它的含义取决于检索方法和分数配置。即使一段文本相似度很高，也可能并不包含足够的证据来回答问题。

输出验证：尽可能把生成的答案和源证据对照。举个例子，文档写的是“保修期为两年”，AI却回答“保修期为两年并包含免费维修”，后一个说法就没有依据。验证步骤可以标记出源文件不支持的声明，可以用规则、另一个模型充当评估者，或者人工核验。每种方法都有局限，验证不应被当作正确性的保证。

人工复核：高影响或不确定的答案，要求人来核实。

评估和监控：用已知答案的问题、需要多段信息的问题、以及文档里根本没有答案的问题来测试系统。持续跟踪检索质量、答案正确性、无依据声明和失败情况，而不是靠几个碰巧看起来不错的答案下判断。

不是每个应用都需要全部技术，合适的组合取决于文档、风险和期望的准确度。

在我的文档智能平台项目里，我用LangChain、ChromaDB、BGE嵌入和Gemini搭了一条文档问答流水线，做了几件事让答案更有依据。

第一，先检索再生成。用BAAI/bge-small-en-v1.5把文本转成向量，ChromaDB存储并搜索这些向量，找出和用户问题相关的段落。这样系统是从上传的文档里检索信息，而不是只靠LLM已有的知识。

第二，检索最相关的3个块。检索器设置k=3，一个问题最多返回三个相关块，让上下文保持聚焦，而不是把整份文档都塞给模型。不过检索三个块，并不保证所有必要证据都被包含进来。

第三，要求Gemini待在提供的上下文里。提示词明确告诉模型：只用提供的上下文回答；上下文信息不足时要说出来；不要编造信息。这促使模型在证据缺失时承认，而不是猜测。

第四，保留来源和页码元数据。用PyMuPDFLoader加载PDF并保留来源、页码信息，方便识别检索到的信息来自哪里，也让答案更容易核验。来源追踪支持可追溯性，但它本身不能证明答案正确。

整条流水线是：PDF → PyMuPDFLoader → 文本切分器 → BGE嵌入 → ChromaDB → 检索前3个块 → 有依据的提示词 → Gemini → 答案。这些措施提升了答案的依据性，但不能保证每个答案都正确。

接下来可以改进的方向包括：增加检索相关性阈值，在生成答案前先判断检索结果是否足够相关；测试无法回答的问题，看系统是否会承认上传文档里没有所需信息；把答案和证据对照验证，检查每一条声明是否被检索到的块支持；在必要时改进检索，试验切块策略、混合搜索或重排序并比较结果。关键是要用一组已知答案的问题来测试这些改动，衡量它们是否真的让系统变好了。

能不能彻底消除幻觉？不能，至少不能在所有情况下可靠地做到。即使有RAG，模型也可能误解证据、检索到不完整的信息，或者生成没有依据的说法。实际目标是减少幻觉、识别不可靠的结果，并让系统能够说出“我没有足够的信息回答这个问题”。一个承认不确定性的系统，往往比一个永远给出答案的系统更有用。

那RAG检索到的信息就能直接信吗？也不能。检索到的文档可能过时、不准确、敏感，甚至包含恶意指令。比如文档里可能藏着一段文字，目的是操纵模型忽略它原本的指令，这是间接提示注入的一种形式。我当前的项目通过安全输入处理API密钥，而不是把密钥硬编码在notebook里，但仅凭这一点并不能让整个应用变安全。生产系统可能还需要身份认证、文档级访问控制、输入输出验证、提示注入防护、安全的密钥管理和适当的日志记录。

搭建RAG系统的过程让我明白，减少幻觉远不止是告诉LLM“要准确”。它需要相关的证据、细致的检索、有依据的提示词、验证，以及一套处理信息缺失的清晰方式。RAG不是关掉幻觉的开关，它是构建更可靠AI系统的重要一环。作为AI工程师，目标不该是让模型听起来自信，而是让它的答案尽可能可信、可追溯、有证据支撑。