我之前用过oobabooga，感觉很不错，但现在我想使用RAG（检索增强生成），我觉得它不支持。有人有使用Ollama、LMstudio、AnythingLM或者openwebUI进行RAG的经验吗？希望知道你们获得最佳结果的配置。

讨论总结

原帖作者想使用RAG，询问Ollama、LMstudio、AnythingLM或openwebUI相关经验与最佳配置。评论者们从不同角度进行了回应，有的分享自己使用多种工具进行RAG的体验，有的推荐了不同功能对应的工具，有的给出特定工具的操作建议或网址资源，整体氛围比较积极正面，大家都在围绕RAG相关工具及操作分享自己的见解。

主要观点

👍 Open WebUI在使用重排序时效果最好。
- 支持理由：Eugr分享了使用不同工具进行RAG的结果体验，其中Open WebUI在使用重排序时的效果最佳。
- 反对声音：无。
🔥 推荐Ollama用于LLM推理、Infinity用于嵌入和重新排名模型、Chroma用于向量数据库、open - webui用于界面，在Docker中本地运行效果良好。
- 正方观点：mikewasg详细列出不同功能对应的工具，并表示在Docker中本地运行这些工具对自己效果良好。
- 反方观点：无。
💡 每个LLM支持RAG，通过向其提供上下文就能实现。
- 支持理由：koalfied - coder表示每个LLM都能从RAG实现中接收上下文，RAG相关操作是将向量数据库中的内容作为上下文传递给LLM。
- 反对声音：部分评论者的观点可能暗示某些工具对RAG的支持性不佳，与这个观点相悖，但未直接反驳。
💡 Kotaemon结果呈现好但文件管理初级且笨拙。
- 支持理由：Eugr在分享不同工具体验时提到。
- 反对声音：无。
💡 AnythingLLM使RAG工作轻松，但Open WebUI有很多自定义功能利于定制RAG体验。
- 支持理由：评论者在分享工具使用经历时提及。
- 反对声音：无。

金句与有趣评论

“😂 Eugr: I get the best results with Open WebUI (if using reranking), but I also like Msty.”
- 亮点：直接给出Open WebUI在特定条件下的最佳效果，并提到对Msty的喜爱，简单明了地分享了工具使用体验。
“🤔 [mikewasg]：Ollama for LLM inference”
- 亮点：明确推荐Ollama用于LLM推理，并且附上了相关网址，具有参考价值。
“👀 koalfied - coder：Pretty sure every LLM supports RAG. You are just feeding context.”
- 亮点：提出每个LLM都支持RAG的观点，并且认为只是提供上下文的问题，这种观点比较独特。
“😎 foldl - li：I did it from the first principle: https://github.com/foldl/chatllm.cpp/blob/master/docs/rag.md”
- 亮点：从基本原理出发进行操作并给出相关网址资源，为其他想要尝试的人提供了思路。
“🤓 Eugr: 128k context is not going to happen by default.”
- 亮点：分享了关于128k上下文的实际情况，是关于工具使用中一个比较重要的信息。

情感分析

总体情感倾向是积极正面的。主要分歧点在于对于不同工具在RAG方面的评价，例如有的工具在某些功能上被评价较好，而在其他功能上则被指出存在不足。可能的原因是不同评论者有不同的使用需求和使用场景，所以对工具的评价会有所差异。

趋势与预测

新兴话题：关于“command - r”LLM在RAG方面的表现以及如何更好地掌握其UI和最佳配置可能会引发后续讨论。
潜在影响：对相关工具的开发者而言，可以根据这些用户反馈来改进工具；对于想要使用RAG的用户来说，能从这些经验分享中更好地选择适合自己的工具。

详细内容：

标题：探索 RAG 应用的多样选择与最佳配置

在 Reddit 上，有一篇题为“Best for RAG… Olama, LM Studio, AnythingLLM, Openwebui”的帖子引起了广泛关注，获得了众多点赞和大量评论。原帖作者之前使用过 oobabooga，觉得不错，但现在想使用 RAG 且认为它不支持。作者想了解大家使用 RAG 搭配 Ollama、LMstudio、AnythingLLM 或 openwebUI 的经验，并希望得知最佳配置。

讨论的焦点主要集中在以下几个方面：有人指出从第一原则做 RAG 可参考[https://github.com/foldl/chatllm.cpp/blob/master/docs/rag.md]，并被称赞为优秀资源。有人表示使用 Open WebUI 能获得最佳结果（如果使用重新排序），但也喜欢 Msty。同时提到 Kotaemon 很有前景，但文件管理在文件多的时候比较初级和笨拙，它的结果呈现是最好的。AnythingLLM 还行，但文件管理也需要改进。RAGFlow 的文件管理在基于网络的工具中可能是最好的。有人询问是否有人看到 RAGFlow/Kotaemon/其他工具与媒体文件的使用情况。有人提到 Kotaemon（可能还有 RAGFlow）可以从 PDF 和 word 文件的图像中提取文本，但使用的是 OCR 工具，而非类似 vision LLM 的东西。Msty 允许添加 YouTube 视频到知识栈，但不能添加本地视频。有人表示自己一直讨厌 UI/UX 编程，不想构建 UI。有人指出 128k 上下文默认不会出现，这是模型支持的最大窗口，需要在使用的应用设置中进行设置。并且大多数模型即使支持更大的窗口，在上下文超过 32K 时表现也不佳。同时，分块方式取决于查询类型。有人分享了自己使用的相关工具和设置，如Ollama 用于 LLM 推理，Infinity 用于嵌入和重新排序模型，Chroma 用于向量数据库，open-webui 用于界面，并表示在 Docker 中本地运行一切，效果良好。有人因为熟悉其基础设施和喜欢创作者而仍使用 AnythingLLM 处理特定用例，后来因资源问题转向 Ollama，最终又回到 Open WebUI，因为它有很多自定义功能和工具。有人使用 msty，觉得它好用。有人使用 Cursor 在 Python 中编写 RAG 设置，认为这改变了游戏规则，让 Python 编程变得更简单，有助于开发更强大的代理。有人建议使用 command-r LLM，认为它在 RAG 方面表现出色。有人认为 Langflow 是个很好的选择，将其比喻为编程、AI 和思维导图的结合产物，组件可定制且开源。

讨论中的共识在于认识到不同工具在 RAG 应用中的特点和优劣，并且都在努力寻找最适合自己需求的配置。

特别有见地的观点如将 Langflow 比作多种元素的结合产物，形象地说明了其优势，丰富了讨论内容。

总之，这次关于 RAG 应用的讨论为大家提供了丰富的经验和见解，有助于更好地理解和应用相关技术。

讨论总结#

主要观点#

金句与有趣评论#

情感分析#

趋势与预测#

详细内容：#