原贴链接

我一直在个人项目中使用本地8b网络+RAG。对于我所关心的数据，在回忆/信息方面，它的表现确实比最新的ChatGPT要好得多。为什么没有一家AI服务提供这种方案呢？这似乎不是性能问题，在消费级硬件上把一本书分割成RAG数据库的时间转瞬即逝，而且我都懒得去测量相似性搜索，因为与推理相比它太快了。它非常有用。你可以把手册、百科全书、代码等几乎任何非虚构类书籍放入RAG数据库并得到有出处的答案。与ChatGPT相比，使用ChatGPT时我得a)希望它在中断之前就知道相关内容b)希望它的训练包含足够多相关内容，这样它才不会说谎。我得说，对于小说来说它就没那么好了，因为RAG似乎无法捕捉你可能问到的关于一本书的抽象概念。

讨论总结

原帖询问为何大AI公司不支持RAG解决方案，在评论区引发了广泛讨论。许多评论者指出实际上不少大公司已经有类似RAG的支持，如GPT、谷歌、Claude、亚马逊等。还有评论者分享了自己使用RAG的经验、探讨RAG在不同场景下的应用、构建RAG的工具和方法、大公司不支持的潜在原因等，整体氛围是大家各抒己见，进行理性的技术探讨。

主要观点

  1. 👍 很多大的AI公司已经有类似RAG的支持
    • 支持理由：如GPT允许上传文件可被索引为RAG，谷歌有NotebookLM，Claude允许添加文件，亚马逊有AWS Search解决方案等众多例子。
    • 反对声音：无。
  2. 🔥 构建标准RAG管道价值有限，构建100%准确的RAG较难
    • 正方观点：构建一个标准的RAG管道比较容易，而构建100%准确的RAG很难，且数据清理、规范化、优化等才是公司提供服务或解决方案的方面。
    • 反方观点：部分人认为RAG很有用，如在个人项目中比ChatGPT在信息检索方面表现好很多。
  3. 💡 不应依赖大企业构建所需工具
    • 支持理由：大企业构建的工具往往不完善、限制过多，并且通常仅适用于自身模型。
    • 反对声音：未提及。
  4. 🌟 大AI公司不支持RAG可能是因为利润空间问题
    • 支持理由：除企业级别的服务外，所需的支持和个性化定制在其他方面利润微薄，如Vertex AI虽有RAG管道，但设置和支持成本高昂。
    • 反对声音：未提及。
  5. 🤔 RAG在企业对企业（B2B）以及特定用户情境下非常有用
    • 支持理由：在多租户共享模型且模型为特定领域时，RAG有其独特优势。
    • 反对声音：未提及。

金句与有趣评论

  1. “😂 Building a RAG is easy so there’s not a ton of value in building a standard pipeline. Building a RAG that is 100 % accurate is hard.”
    • 亮点：简洁地阐述了构建RAG管道的价值判断，是关于RAG构建难度的代表性观点。
  2. “🤔 Only matters is accuracy and speed.”
    • 亮点：指出在RAG相关应用中准确性和速度是关键因素。
  3. “👀 Oddly enough Google seem to be leading the big companies on this front. And no other front. NotepadLM is worth a try.”
    • 亮点：强调了谷歌在RAG解决方案方面处于大公司中的领先地位，并推荐了相关产品。
  4. “💥 We can’t and shouldn’t rely on big corporations to build the tools we actually need, because they will usually be half - baked, over - restricted, and usually only applicable to their own models.”
    • 亮点：表达对大企业构建工具的不信任，倡导构建开源工具系统以满足需求。
  5. “😉 RAG just means to augment the system message or user message with additional information.”
    • 亮点：对RAG的含义进行了一种简洁的解释。

情感分析

总体情感倾向较为理性中立。主要分歧点在于大AI公司是否支持RAG解决方案以及RAG本身的价值。原帖作者认为大AI公司不支持RAG解决方案，但很多评论者指出其实不少大公司已经有类似支持，这一分歧可能源于对RAG定义理解的差异以及对各公司相关功能的了解程度不同。对于RAG价值的分歧，部分人认为构建标准RAG管道价值不大，而有些人则在实际应用中发现RAG非常有用。

趋势与预测

  • 新兴话题：Graph RAG可能成为新兴话题，有评论者对其好奇且认为比基本的RAG更有前景，后续可能会有更多关于Graph RAG的讨论，包括其技术实现和应用场景等。
  • 潜在影响：如果更多的公司重视RAG解决方案并加以完善和推广，可能会改变目前信息检索和处理的方式，在数据处理、人工智能应用等相关领域提高信息获取的准确性和效率。同时，对于企业和个人用户来说，可能会促使更多人探索如何将RAG与自己的业务或项目相结合。

详细内容：

标题：为何大型 AI 公司对 RAG 解决方案支持不足？

在 Reddit 上，一则关于“为何大型 AI 公司不支持 RAG 解决方案”的讨论引起了广泛关注。原帖作者表示自己在个人项目中使用本地 8b 网络和 RAG 取得了比最新 ChatGPT 更好的效果，特别是在数据召回和信息处理方面。此帖获得了众多点赞和大量评论，引发了关于 RAG 技术在实际应用中的可行性、准确性、成本以及在不同领域的适用性等多方面的热烈讨论。

讨论焦点与观点分析：

  1. 关于 RAG 技术的难度和复杂性：
    • 有人认为构建一个简单的 RAG 不难，但要达到 100%准确却非常困难。数据清理、标准化和优化等环节才是公司提供服务和解决方案的重点。
    • 也有人指出对于专业领域，如律师、医生等，对准确性的要求极高，接近零误差，因此构建高度优化和准确的 RAG 至关重要。
  2. 关于 RAG 与现有模型的比较：
    • 有人亲身体验将大量数据库数据输入 LLM 后，发现其速度慢、召回率低且成本高，相比之下 RAG 表现更优。
    • 但也有人认为在创意写作等领域，大型模型如 Claude 和 GPT 的新模型更出色。
  3. 关于 RAG 在不同领域的应用：
    • 有人以法律和医疗领域为例，说明高效准确的 RAG 能够节省大量时间和提高工作效率。
    • 也有人分享了在桌面角色扮演游戏（TTRPG）等特殊数据类型中的应用经验。
  4. 关于 RAG 的实现方式和工具：
    • 有人分享了使用 FAISS 和 transformers 库的 Python 工作流程，以及通过页面或块对输入文档进行处理的方法。
    • 还有人探讨了不同的嵌入模型、索引方式以及相关的技术挑战。

有趣的观点和案例： - 有人将桌面角色扮演游戏的记录转录输入 NotebookLM，并取得了良好的效果。 - 有人正在将 Obsidian 中的笔记与 Misty 和小 LLM 连接，设置简单且实用。

在这场讨论中，虽然对于 RAG 技术存在诸多不同的看法，但也达成了一些共识，例如都认可 RAG 技术在特定场景下具有巨大潜力，但在准确性、实现成本和应用范围等方面仍存在诸多挑战。一些独特而有见地的观点，如对不同领域应用的具体分析和对未来发展的预测，丰富了整个讨论，让人们对 RAG 技术有了更全面深入的理解。