排除 RAG (检索增强生成) 问题

检索增强生成 (RAG) 使语言模型能够通过检索相关信息并将其输入模型，从而对外部内容（文档、知识库等）进行推理。但是，当情况不如预期时（例如，模型出现“幻觉”或遗漏相关信息），通常不是模型的错——而是上下文的问题。

让我们分解常见的原因和解决方案，以便您可以大幅提升 RAG 的准确性！🚀

常见的 RAG 问题及修复方法 🛠️

这是最常见的问题——通常是由内容摄取过程中的问题引起的。模型产生幻觉不是因为它错了，而是因为它根本就没有得到正确的内容。

✅ 解决方案：检查您的内容提取设置

tip

尝试上传一份文档并预览提取的内容。如果它是空白的或缺少关键部分，您需要调整提取器设置或使用不同的引擎。

Open WebUI 默认设计用于处理上下文窗口有限的模型。例如，许多本地模型（如 Ollama 的默认模型）限制为 2048 个 token。因此，Open WebUI 会激进地裁剪检索到的内容，以适应预期的可用空间。

✅ 解决方案：

前往 管理员设置 > 文档
选择以下操作之一：
- 💡 启用“绕过嵌入和检索 (Bypass Embedding and Retrieval)” —— 这将直接发送全部内容，而不应用严格的检索过滤器。
- 🔍 开启“全上下文模式 (Full Context Mode)” —— 这将向模型提示词中注入更全面的内容。

warning

📌 警告：请注意上下文限制——如果您的模型无法处理更多 token，内容仍将被截断。

即使检索工作正常，您的模型可能仍无法处理接收到的所有内容——因为它根本做不到。

默认情况下，许多模型（特别是 Ollama 托管的 LLM）被限制在 2048 token 的上下文窗口内。这意味着您检索到的数据中只有一小部分会实际被使用。

为什么网页搜索特别需要更大的上下文窗口： 网页对于小上下文窗口来说尤其具有挑战性，因为它们包含的内容远多于典型文档。单个网页通常包括：

即使在内容提取和清洗之后，网页也很容易消耗 4,000-8,000+ 个上下文 token。如果限制在 2048 token，您得到的内容还不到一半，通常会错过出现在页面后半部分的关联性最强的信息。即使是 4096 token，对于全面的网页内容分析也经常是不够的。

✅ 解决方案：

🛠️ 针对 Ollama 模型：扩展模型的上下文长度：
- 导航至：管理员面板 > 模型 > 设置（针对您想要编辑的模型）
- 前往 高级参数 (Advanced Parameters)
- 修改上下文长度（例如，增加到 8192+，或者如果您的模型支持，理想情况下增加到 16000 token 以上）
🌐 针对 OpenAI 和其他集成模型：这些模型通常有自己的上下文限制，无法通过 Open WebUI 设置进行修改。请确保您使用的是具有足够上下文长度的模型。

ℹ️ 注意：2048 token 的默认限制是网页搜索的一大障碍。为了获得更好的网页内容 RAG 结果，我们强烈建议使用至少 8192 token，对于复杂的网页，16384+ token 是最理想的。

✅ 替代方案：使用具有更大上下文容量的外部 LLM

tip

对于网页搜索和复杂的文档分析，在生产用例中请坚持使用支持 8192+ token 上下文的模型。

糟糕的嵌入 = 糟糕的检索。如果内容的向量表示很差，无论您的 LLM 有多强大，检索器都无法提取到正确的内容。

✅ 解决方案：