RAG 的未来，走向繁荣、重塑还是消亡？

检索增强生成 RAG 技术通过提供可靠且最新的外部知识，有效提升了大语言模型的输出质量，极大地便利了各类任务，并对多个行业产生了日益显著的影响。随着 RAG 技术的持续进步和应用领域的扩展，其在企业实际落地中所面临的局限性与技术挑战也逐渐显现，亟需进一步的探索与改进。

部分精彩观点如下：

• 将 RAG 和 O1 相结合，能够进一步提升推理效果。

• 不同的模型就像不同个性的人。

• 未来的趋势可能是将 RAG 和 agent 结合起来，形成更加综合的系统。

RAG 通过将外部知识库的检索与生成模型相结合，显著提升了生成内容的时效性、准确性，显著降低了幻觉率。如何应用和优化 GraphRAG、 Agentic RAG 等技术来提升复杂问题的解答能力；如何融合文本、图像、音频等多种数据形式的跨模态 RAG 的最新进展和应用创新？即将于 2025 年 4 月 10-12 日召开的 QCon 全球软件开发大会（北京站）将给大家带来相关实践案例，直击痛点，解锁可复制的经验与模式。如果你也有相关案例想要分享，欢迎通过以下链接提交演讲申请：https://jsj.top/f/tUOLpz

以下内容基于现场速记整理，经 InfoQ 删减。

周景博：RAG 对于 O1 类推理模型的意义何在？

夏源： 首先，我想简要介绍一下目前学界和业界对某些实现方案的看法。比如在训练阶段，需要大量涉及推理逻辑的数据。为了获取这样的推理逻辑数据，通常采用的方式之一是通过人工介入，预先标注一批推理逻辑路径数据，先建立一个种子模型，一旦有了这个种子模型，就可以进行训练并人工合成推理数据，再将其输入到模型中，以保证模型在输出时具有思考过程。

目前，在推理阶段业界猜测 O1 使用了谷歌提出 Testing Scaling Law（测试推理阶段的规模化法则）的方式。我们希望在训练完成后，能够通过生成多个推理路径进行选择。例如，可以采用 MCTS（蒙特卡洛树搜索）或 RL（强化学习）结合 PRM（过程奖励模型）的方法，针对模型生成的每条路径进行评估和打分。通过这种方式，我们可以筛选出最关键的推理路径，从而达到优化推理效果的目的。然而，这种方法在训练推理阶段消耗算力较大，需要对每一步路径进行评分。

关于 O1 模型，它在解决数学和物理问题上的表现非常突出，尤其是能够解决一些强推理问题，比如数学竞赛题。然而，当我们将其应用到真实世界的场景时，如医疗、金融等行业时，单纯使用 O1 模型并不适用。比如我尝试让 O1 回答“_ 速福达是否适合 5 岁小孩使用？_”这个问题时，得到的结果错误且离谱。这是因为 O1 只是一个推理强的模型，它并未引入真实世界的知识。为了解决这一问题，我认为 RAG 在 O1 模型中起到非常重要的作用。O1 作为一个具有规划能力的模型，擅长在推理过程中做得很好，但要使其适应实际应用，需要结合 RAG 来引入更多的领域知识。

我还想谈谈 O1 模型中的 PRM 打分问题。O1 模型依赖于其内化的知识来进行推理和打分，但对于一些真实问题，比如医疗领域的药品适应症，它可能缺乏足够的知识。因此，通过将 RAG 引入 O1 模型，能够在 PRM 环节引入真实的知识，并提高模型在特定业务场景中的判断能力。

我认为将 RAG 和 O1 相结合，能够进一步提升在真实世界场景的推理效果。然而，目前面临的挑战在于如何有效地标注数据，特别是在 RAG 阶段。人工标注的成本很高，因此需要更多依赖合成数据，这也是未来的大趋势。

周景博：在 RAG 场景中，数据引擎的检索能力还有哪些潜在的改进空间？

田昕晖： 首先，我们观察到现在在信息检索领域，关于检索能力的需求达成了普遍共识。比如，涉及到向量检索、稠密和稀疏检索、文本搜索以及混合搜索等方向。这些都是目前较为关注的重点。

接下来，我认为目前数据引擎和大模型结合的潜力还未得到充分挖掘，尤其是像“Text to SQL”这种应用场景。如何更好地利用现有的大量结构化数据，尤其是如何让大模型更好地利用计算引擎的强大计算能力，这是一个亟待解决的问题。例如，复杂查询的处理和优化器的设计，已经在计算引擎领域有很多年的积累和性能优化，但如何让大模型能够更充分地利用现有数据引擎的能力，以获得更复杂的计算结果，仍是一个值得探索的方向。

从引擎的角度来看，我认为我们可能可以进一步深入探讨如何将大模型与数据引擎进行更加紧密的结合。当前，大模型调用链路中的数据引擎仅占据了一个较小的环节，后续是否可以进一步深入，将数据引擎作为大模型调用链路中的重要组成部分，从而支持更加复杂的应用场景。

费跃： 从数据引擎用户的角度来看，我们曾与多个做向量数据库的团队有过密切合作，发现了一些目前的问题。最初，向量数据库只支持单一的密集向量检索，后来随着需求增加，开始支持混合检索和全文搜索。然而，一些新的索引技术，如稀疏向量，ColBERT 多向量等等，大部分数据库还没有支持，更不用说目前比较火热的图结构索引了。这让我觉得数据检索引擎应该有更加统一的索引协议，减少下游用户使用的困难。

此外，向量数据库与 embedding 模型有较深的绑定关系，但由于 embedding 由客户选择，无法在创建时指定特定类型。当知识库创建后再改变 embedding 模型会出现不一致的问题，因此可能需要引入 Meta Data 审查机制，确保索引数据的一致性。

另一个问题是查询链路的执行过程，虽然介绍了很多算法，但对下游用户而言仍然是黑盒。我们是否可以借鉴数据库的思想，优化查询链路，进行调试、版本控制，引入容灾备份等核心功能？对于新兴的纯向量数据库，这可能是一个挑战。

观众：在做金融场景的年报解析时，对于一些专有名词，大模型找不到正确的向量。有什么解决方法？

费跃： 看起来像语义不匹配的问题。

尹一峰： 这个模型你们训练了吗？

观众： 没有，直接用 OpenAI 的。

尹一峰：OpenAI 上的金融数据很少，建议换一个模型。

观众： 但我觉得这不是模型本身的问题，就是你无论用什么模型，它都存在这个问题。

尹一峰： 因为向量很大，你可能把 200 个字压成了一个向量，但是你要的信息可能只是这一段话里一小段，这是你产品的问题了。你可以制定 hierarchy，把 trunk 做得很小很小，然后做 context enrichment，就能实现精准定位。

周景博：除了 RAG，还有哪些方法可以减少大型语言模型的幻觉问题并提高回答的准确性？

尹一峰： 我们将同一问题分别交给三个大型模型——Gemini、Claude 和 GPT，看看它们的回答是否一致。如果三者回答相同，说明答案基本可信，因为它们同时出错的概率非常小。

要降低错误率，可以通过优化模型来提升其表现。模型只是我们工作流中的一环，输入可以在进入模型前进行处理，输出后也可以做进一步操作，如分类或聚类，以验证其一致性。如果想大幅降低错误率，需要投入大量精力，尤其是在简单场景下可以每月调整一次模型合作阶段。复杂场景则难以做到如此低的错误率。

模型错误率受随机性和领域知识掌握程度影响。随机性意味着同一问题给模型两次，可能得到不同的答案；领域知识掌握得越深入，错误率越低。部分模型经过后期训练，可以明确告知“不知道”。不过，要让模型达到这种能力，成本非常高。

周景博： 一个不确定的问题，可以多问几个模型看一看，但是不知道将来会不会这些模型的答案最终会收敛到同一个值上去。

尹一峰： 所有模型的预训练数据可能是相似的，通常来自 CC 数据集，但它们的后期训练数据差异很大。因此，不同的模型就像不同个性的人。例如，Claude 注重安全性，表现得像一个 60 岁的老者，谨慎且不敢冒险；Gemini 则像是一个充满惊喜的黄毛青年，偶尔给你带来意外的回答；而 GPT 更像是一个大学生，时常表现出天真与自信，即便犯错也不愿承认。我们可以根据问题的特点和模型的特性，决定信任哪个模型。

田昕晖： 模型的准确度可以通过多种机器学习技巧来提升，很多方法可以在数据引擎中通过算子实现。例如，使用多模型比较或评估精度的策略。从数据引擎的角度来看，我认为可以将这种流水线式的处理方式整合到数据引擎中。若数据引擎能够支持机器学习中的最佳实践，如复用和抽象，那么我们就可以将这些方法转化为数据操作算子，甚至构建成一个流水线，提升使用的便利性和可操作性。

观众：MOE 模型对于幻觉解决是否能带来一些帮助？

夏源：MOE 最初并不是为了解决幻觉问题，而是为了解决推理速度。虽然 MOE 的效果很好，但它的核心目的是在推理时通过选择性调用专家模型来加速推理过程，而不是全量运行。原始的技术报告和论文也没有提到 MOE 能解决幻觉问题。MOE 应用减少的原因可能是由于最初其创新性吸引了大量关注，尤其是在 LLaMa 模型较弱时，大家认为 MOE 是更好的选择。然而，后续实践表明，增加数据量和训练轮次同样能提升效果，导致 MOE 的使用逐渐减少。

观众： 老师能再详细解释一下对 Claude、Gemini 和 GPT 的比喻吗？国内的大模型也能这样比喻吗？

尹一峰： 在硅谷，生意通常有三种类型：第一种是降维打击，比如特斯拉用电动汽车替代传统燃油车；第二种是“挖金子，我卖水”，即通过提供基础设施支持来盈利；第三种是差异化竞争，即在相似产品中定位不同市场。例如，Anthropic 专注于安全；OpenAI 则更侧重于帮助用户解决问题，而且它不喜欢说“不”，不愿意承认自己不懂；Gemini 的模型则表现得比较不稳定，其目标和定位不太明确。相比之下，国内的模型大多没有明显的“性格”，缺乏差异化竞争的优势，这与国外的商业策略不同。

目前，Transformer 架构的潜力几乎已经被挖掘殆尽，很多技术问题已经成为组合学问题，选择不同的激活函数等已经不再具有突破性的科技含量。因此，商业决策成为了主要的推动力，模型的设计往往取决于企业的商业目标。国内的大模型往往缺乏个性和鲜明的市场定位，大家做的东西差不多，竞争非常激烈。

周景博：最近市面上出现了很多开源类的 RAG 类产品，如何看待这类产品的竞争力，以及他们未来的商业模式？

费跃： 我觉得现在很多开源产品都做得很不错，尤其是在易用性方面。比如在构建大模型应用的流程和交互上，它们做得很用心。开源产品的优势在于它们非常适合初创公司或者用于快速验证想法，也能很好地应用于一些不需要特别复杂的严肃场景，或者体量较小的服务，可以用开源工具像 Dify、fastgpt 这样的方案快速部署和尝试。

至于开源产品潜在的商业模式，我认为一种是通过建立自己的 SaaS 服务，另一种是和云厂商合作，像 Dify 与 AWS 的合作，通过 AWS 的资源提供高阶版本和企业级支持。

田昕晖： 一个产品能否成功商业化并且稳定落地，关键在于其壁垒有多强，以及其生态系统是否能够防止被撬动。如果一个框架太过相似、没有明显的差异化，那么它就容易被其他产品取代。因此，产品的成功不仅要看框架的设计，更要看它是否能在某些场景中与生态紧密结合，形成不可替代的壁垒。

开源对于提升差异性有帮助吗？我觉得现在的开源框架的确很多都很相似，大家都在集中讨论如何找到一种最适合大模型的框架，能在多种场景中良好运作。每个人都可以根据自己的需求做出定制，框架的定义变得非常灵活，因此还没有一个特别稳定的调用方式。

但开源框架在大模型的演进中仍然非常重要，因为它们提供了一个探索和共识的过程。就像关系数据库模型的演进一样，开源推动了共识的形成。当我们确定了一些基本的框架和调用方式后，接下来就是看哪些大模型框架能在这基础上持续发展，并推动更多的创新。所以，开源生态对 RAG 模型的构建是非常有帮助的。

尹一峰： 我觉得这些专注于 RAG 的公司，比如 LangChain、LangGraph 和 LLaMa Index，可能面临的最大挑战是它们的应用场景比较窄，可能难以像 Docker 那样广泛普及。Docker 的应用几乎是所有软件开发者都需要的，而这些 RAG 框架，虽然在某些场景下很有用，但对于很多工程师来说，尤其是高水平的工程师，这些框架提供的功能并没有特别大的优势。如果你能写 Python 代码，使用这些框架可能需要花费更多的时间和精力，而实际上自己写代码可能会更简洁、更优雅。

举例来说，LangChain 现在已经变得有点繁琐，许多优秀的工程师觉得它不够简洁和优雅，开始选择自己动手开发解决方案。因此，尽管它们现在可能有一定的市场，但最终能否达到 Docker 的水平，我并不看好。它们可能最终成为一些爱好者项目，或者在市场竞争中逐渐被淘汰。

夏源： 我认为，目前的 RAG 开源架构对于通用领域的应用可能有一定的价值，但对于垂直行业来说，它们的适用性非常有限。大部分现有的框架集中在检索环节，而检索只是整个 RAG 流程的一部分。即使检索做得再好，如果前置的内容理解不足，结果依然不理想。就像常说的，“垃圾进，垃圾出”。

例如，在处理金融表格时，即使检索很好，若前期没有将表格内容整理好，直接将表格上传到模型中，效果会大打折扣。一个更好的方法可能是先将表格解析成结构化的数据（，再结合类似于 Pandas 这样的工具进行数据处理，然后用代理模型来进一步分析。这种方法相比直接放入未处理的表格可能更有效。

周景博：未来 RAG，是否有希望发展成类似像数据库一样的独立基础设施？

夏源： 狭义的 RAG 通常指的是仅仅在中间环节进行检索，但我认为这种做法最终会融入到更大的框架中。其实，Agent 可以看作是更广义的 RAG，因为它不仅仅限于检索环节，可能还包括了召回、数据库查询，甚至是基于其他模型的结果或校验工具。未来的趋势可能是将 RAG 和 Agent 结合起来，形成更加综合的系统。

尹一峰： 我把 RAG 类比为 Docker，因为 Docker 已经成为底层基础设施的一部分，而我认为 RAG 也有类似的潜力。Docker 的成功在于它被许多 SaaS 公司作为基础架构的一部分，类似于一种“载体”帮助他们构建产品。未来，RAG 也可能会被一些大型模型，如 LLaMa，所吸收，但我认为它不会完全消失。

田昕晖： 我认为 RAG 能否发展出自己的一套通用范式是关键。如果能的话，它就有可能沿着数据库的发展路径，逐步形成类似于“Schema”和“Data Model”的概念。同时，RAG 的核心也还是和大模型的调用环节相关，无论是与 Agent 结合，还是与其他 PE 技术融合。最近，也有一些大佬在讨论 LMOS（大模型操作系统）这一概念，大家似乎都在朝这个方向探索。

费跃： 我认为 RAG 肯定会成为一个独立的基础设施，并且大模型可能会将其纳入其中，作为一个模块或单元。未来，大模型可能会发展成一个复杂的系统，类似于夏老师提到的 Agent 和 RAG 将是其中的一部分。