问题是什么？
摘要：
在使用 Ollama 版本 0.2.1 之后的本地模型中，检索增强生成(RAG)功能在 Open WebUI 中出现故障。虽然外部模型(例如 GroqCloud 的 LLama 3 8B)与 RAG 功能正常工作，但本地模型无法利用所选文档，返回不相关或捏造的信息。此问题出现在 SentenceTransformers 和 Ollama 两个 RAG 嵌入模型中。
受影响的版本：
- Ollama:0.2.2、0.2.3、0.2.4、0.2.5(最新)
- Open WebUI:最新
dev和main分支
不受影响的版本： - Ollama:版本 0.2.1 之前
- Open WebUI:?
重现问题的步骤： - 干净的状态：
- 将 Ollama 降级到版本 0.2.0(
ollama --version)。 - 在 Open WebUI 中，清除
Workspace>Documents标签下的所有文档。 - 导航到
Admin Panel>Settings>Documents并单击Reset Upload Directory和Reset Vector Storage。 - 成功的 RAG 测试(Ollama 0.2.0 & 0.2.1):
- 在 Open WebUI
Documents工作区中添加一个.txt文档。 - 开始一个新的聊天并使用
#键选择文档。 - 输入与文档内容相关的查询。
- 验证本地和外部 LLMs 是否准确响应，并包含所选文档的信息。
- 在升级(
ollama --version)后重复步骤 1 & 2 对于 Ollama 版本 0.2.2。 - 失败的 RAG 测试(Ollama 0.2.2 及以后版本):
- 将 Ollama 升级到版本 0.2.2(
ollama --version)。 - 开始一个新的聊天，使用步骤 2 从第 2 步中选择相同的文档，并输入相同的查询。
- 注意本地 LLMs 不能利用文档内容，提供不相关或捏造的响应。
- 验证外部 LLMs 仍然可以正确地与 RAG 一起使用。
- 对于 Ollama 版本 0.2.3、0.2.4、0.2.5,重复步骤 3,观察相同的行为。
预期的行为：
本地 LLMs 应该成功地利用所选文档进行 RAG,根据其内容提供准确且相关的响应，无论使用的 Ollama 版本如何。
实际行为：
本地 LLMs 在使用 Ollama 版本 0.2.2 及以后时无法准确执行 RAG,而外部模型不受影响。尽管成功加载和嵌入生成了文档(通过测试与 SentenceTransformers 和 Ollama 嵌入模型进行了确认),但问题仍然存在。
其他注意事项：
- 该问题在多次尝试、重新生成和消息编辑中持续存在。
- 该问题不特定于某个文档或查询，因为它始终与不同的输入一致发生。
- 通过重置 Open WebUI 上传目录和向量存储以及重新上传文档，无法解决该问题。
- 该问题与 OpenWebUI中的 RAG + Ollama v0.2.2(对于本地模型而言似乎每次都以失败率为百分之百)无关，这一点已通过测试得到证实。
- 将 Ollama 降级到版本 0.2.0 可以完全解决 OpenWebUI中 RAG的故障。
7条答案
按热度按时间hsvhsicv1#
这是一段文本，其中包含了一些硬件配置信息。根据这段文本，您提到了Nvidia (4090)和AMD Ryzen 7950 X这两款硬件产品。
ljsrvy3e2#
为了帮助解决变量问题，我还在Arch Linux上遇到了一个非Docker安装的问题。
AMD RX 6900 XT
CPU AMD Ryzen 5950X
4sup72z83#
对于我来说，同样存在这个问题！
我使用的是GPU NVIDIA A100和Intel CPU,操作系统为Windows Server 2022。
5rgfhyps4#
我将进行更多的测试，因为我在2.1版本中也遇到了与docx和xls文件相关的bug。但我不确定。
68bkxrlz5#
更新/升级:
经过彻底测试，已确定将Open WebUI的
Documents设置中的Top K值设置为1可以解决使用Ollama版本0.2.1及更高版本时与RAG的兼容性问题。此外，将RAG模型的上下文长度配置为更高的数字，例如
8192,已被发现可以与这些特定版本的Ollama保持功能。这些观察是基于Open WebUI维护者和我根据严格测试收集的经验数据得出的。提供的屏幕截图作为支持这些发现的视觉证据：
设置调整(将此值更改为
1):Open WebUI维护者的发现：
RAG在上下文长度设置为
8192时工作(在Open WebUI的最新开发提交上测试了Ollama v0.2.5):RAG在Open WebUI的
Documents设置中将Top K设置为1时工作(在Open WebUI的最新开发提交上测试了Ollama v0.2.5):我们认为提供的信息对于解决手头的错误报告至关重要，并确保将来安装和更新Ollama时与Open WebUI的RAG功能保持最佳兼容性。
2wnc66cl6#
在我这边，我有一个非常简单的提示，文档的总token数量约为2k个token,略高于默认的2048个。然而，即使模型设置为4096,或者在“当前聊天设置”中将其设置为4096,问题仍然存在。使用8112可以解决问题。但4096应该对我的查询来说远远足够了。
@silentoplayz 看起来，使用侧边栏上的“当前聊天设置”的上下文长度没有任何效果。我可以将其设置为1、5、654654654165,模型只会根据我在模型设置(工作区>模型>编辑模型>高级设置)中设置的设置回答问题。
cetgtptt7#
在我这边，我有一个非常简单的提示，文档的总令牌数约为2k个令牌，略高于默认的2048。然而，即使模型设置为4096,或者在“当前聊天设置”中将其设置为4096,问题仍然存在。使用8112可以解决问题。但是4096应该对我的查询来说远远足够了。
@silentoplayz 似乎使用侧边栏上的“当前聊天设置”的上下文长度没有任何效果。我可以将其设置为1、5、654654654165,模型只会根据我在模型设置(工作区>模型>编辑模型>高级设置)中设置的设置回答RAG查询。
奇怪的是，调整右侧边栏聊天控件中的
Context Length值对你来说没有任何效果。我注意到在Open WebUI中，通过将上下文长度提高到4096来“修复”RAG对我来说是有用的，甚至在某些情况下只需要这样做。我还报告说，我在这里报告的相同一组问题似乎出现在最近发布的Ollama版本中：v0.2.6和v0.2.7。