原贴链接

计划在我的SaaS应用中构建RAG功能，正在寻找成本效益高且简单的解决方案。要是能知道你们的RAG技术栈就太好了。组件有哪些？加载器呢？你们正在使用的集成？成本是多少？任何见解都会非常有帮助，谢谢。

讨论总结

原帖寻求在SaaS应用中构建RAG功能的成本效益高且简单的解决方案，包括技术栈、组件、加载器、集成和成本等方面的见解。评论者们从各个角度进行了回应，分享了自己构建RAG功能时的技术栈，如采用的数据库、模型、工具等，还提到了构建的成本，有的表示可以零成本构建，也有针对小组织构建RAG的讨论，以及对各种组件、工具、模型的评价和推荐，还有一些关于特定类型RAG（如视觉RAG）的经验分享，整体讨论氛围积极，大家互相分享经验和见解。

主要观点

  1. 👍 使用Llamaindex作为Python库构建自定义数据索引器，采用PostgresSQL加VectorDB扩展构建向量数据库。
    • 支持理由：为原帖寻求成本效益高且简单的RAG技术栈提供了具体的参考实例。
    • 反对声音：无
  2. 🔥 kotaemon粗糙不适合生产，小组织可考虑dify ai用于生产且功能全面。
    • 正方观点：dannyboy2042指出kotaemon的粗糙性，Creative_Yoghurt25推荐dify ai且阐述其优势。
    • 反方观点：无
  3. 💡 构建RAG时应注意依赖项大小，过大可能导致应用加载失败。
    • 解释：Abishek_1999以Azure函数应用为例说明了依赖项太大的问题。
  4. 💡 推荐Ollama、langflow和chromadb作为RAG技术栈的组件。
    • 解释：No - Leopard7644推荐这几个组件可用于构建RAG技术栈。
  5. 💡 特定使用案例会极大改变RAG构建。
    • 解释：MissinqLink根据自己手工构建RAG多年的经验得出该结论。

金句与有趣评论

  1. “😂 Kotaemon is pretty rough, definitely would not run this in production.”
    • 亮点：直接指出kotaemon的缺点，简单明了。
  2. “🤔 I’m wondering if it’s still worth for a little organization to develop RAG by itself now that kotaemon exists?”
    • 亮点：提出了小组织在已有kotaemon情况下是否还需自行开发RAG的思考。
  3. “👀 Cost? Definitely $ 0.00 but my 4090 was $2,000 so… 🤷🏼but I believe you can do everything listed here with a free Google collab.”
    • 亮点：强调了构建RAG功能可以零成本，同时还幽默地提到自己昂贵的显卡。
  4. “😂 If you know what you want to do, you can just rewrite a smaller library that minimally implements something and have it included.”
    • 亮点：针对llamaindex依赖项过多的问题提出了一种解决思路。
  5. “🤔 Have a look at Langroid’s DocChatAgent, it has a clear, extensible RAG implementation that you can customize or enhance to your needs.”
    • 亮点：对Langroid的DocChatAgent进行推荐并阐述其优势。

情感分析

总体情感倾向为积极正面，大家都在积极分享自己的经验、见解和推荐。主要分歧点较少，可能存在的一点是对于某些工具或组件的评价不同，如对kotaemon的看法，有的认为粗糙不适合生产，有的则在思考小组织是否还需要自行开发RAG而不使用它。原因在于大家基于自己不同的使用体验和需求来进行评价。

趋势与预测

  • 新兴话题：关于视觉RAG相关的技术实现以及在不同场景下的应用可能会引发后续讨论。
  • 潜在影响：这些不同的构建经验和推荐如果被广泛采纳，可能会影响到SaaS应用中RAG功能的构建效率、成本以及最终的性能表现，对RAG技术在相关领域的发展和应用起到推动作用。

详细内容：

标题：RAG 技术栈大讨论，你选哪一款？

近日，在 Reddit 上有一个关于 RAG 技术栈的热门讨论帖引起了广泛关注。原帖作者表示计划在自己的 SaaS 应用中构建 RAG 功能，寻求经济高效且简单的解决方案，希望了解大家使用的 RAG 技术栈、组件、加载器、集成方式以及成本。此帖获得了众多关注，评论数众多，引发了一场热烈的讨论。

讨论的焦点主要集中在各种 RAG 技术方案的选择和优劣上。有人提到使用 LlamaIndex 作为 Python 库，并基于其可扩展的 API 构建了自定义数据索引器；也有人表示对讨论的内容完全摸不着头脑，但觉得听起来很厉害。还有人认为原帖作者像是无意间构建了多个初创公司。

有用户分享了自己的个人经历，比如有用户表示已经手动构建 RAG 多年，具体的使用案例会极大地改变技术选择。

在观点分析方面，各方各抒己见。有的用户推荐了 PostgreSQL + VectorDB 扩展作为向量数据库；有的认为 Kotaemon 还不够成熟，不适合用于生产环境；也有人推荐了 Diffy AI 用于生产，认为其效果不错。对于“视觉 RAG”的概念，有人给出了详细的解释，包括从 PDF 中进行信息检索的复杂步骤等。

不同观点的争议点在于各种技术方案的适用性、成本以及在实际生产环境中的表现。比如，有的认为某些方案依赖过多，在特定环境下可能会出现问题；有的则强调不同模型和数据库的特点和优势。

这场讨论中，大家的共识在于构建 RAG 功能需要根据具体需求和情况选择合适的技术栈。

总之，这次关于 RAG 技术栈的讨论为有相关需求的人提供了丰富的参考和思考方向。