大语言模型技术迅猛发展的脚步，正引领着信息检索技术进入一个新的纪元。在这一领域中， RAG  技术将传统信息检索技术与大语言模型技术相结合，为知识理解、知识获取提供了全新的解决方案。然而，尽管 RAG 在很多任务上表现出色，其在深度应用上仍面临诸多挑战。

在日前的 InfoQ 《极客有约》X AICon 直播中，我们邀请到了阿里巴巴总监 & TGO 鲲鹏会学员郭瑞杰、 阿里云高级算法专家欧明栋 、英飞流 CEO 张颖峰、合合信息研发总监常扬 ，深入探讨 RAG 技术的当前进展、面临的挑战、未来的发展方向以及在不同行业中的应用潜力。

• 数据杂乱、用户意图明确时的低命中率，以及用户意图不明确时的语义 gap，是阻碍 RAG 技术走向更多企业、让企业愿意为之付费的主要瓶颈；
• 解决掉  RAG 最基础、最本质的问题，是出现爆款产品的基础；
• 长上下文模型和 RAG 之间不应是冲突关系，而应是合作关系；
• 如果“烂大街”代表  RAG 技术理解和使用门槛降低，这是一件好事；
• RAG 加 Agent 的本质是复杂问题的分治。

在 8 月 18-19 日将于上海举办的 AICon 全球人工智能开发与应用大会上，郭瑞杰老师将出品【RAG  落地应用与探索】 专题，深入探讨 RAG 的最新进展、成果和实践案例，详细分析面向 RAG 的信息检索的创新方法，包括知识抽取、向量化、重排序、混合检索等在不同行业和场景下的微调和优化方法。而欧明栋、张颖峰、常扬老师也将在专题论坛上带来精彩分享。大会更多精彩议题已上线，点击链接可查看目前的专题安排：https://aicon.infoq.cn/2024/shanghai/track

以下内容基于直播速记整理，经过不改变原意的编辑。

郭瑞杰： 我们进入今天第一个讨论的话题， RAG  技术在不同领域 / 不同场景的应用现状、挑战和潜在影响。 今天几位老师也是来自不同的领域不同场景，首先有请欧明栋老师分享下 RAG 在阿里云 AI 搜索实际应用场景中碰到的问题及尝试的解决方案。

在服务过程中，我们发现最大的挑战在于如何将服务真正落地到客户的生产环境中。这主要是因为技术问题，尤其是客户数据的多样性。客户的数据格式各不相同，包括 PDF、DOC、纯文本，甚至 PPT 等。即便是相同格式的数据，不同客户的排版也大相径庭。这导致文档解析的准确性受到影响，例如文档结构未能正确解析，或者文字、内容、表格等丢失，最终影响了问答效果。此外，某些行业对大语言模型的精度和错误率有较高要求，希望控制模型的幻觉问题，特别是在医疗和政务领域，因为错误可能导致严重后果。然而，大模型的幻觉问题本质上是一个难以控制的缺陷。

在实际使用中，许多用户的问题并非简单直接，而是需要经过多步推理和检索才能得到答案的复杂问题。例如，多跳问题、意图不清晰需要澄清的问题，以及答案在文档中跨度较大的问题。目前，这些问题在传统的 Web 框架下解决得并不理想。RAG 系统提供了一种比传统搜索更进一步的解决方案。与以往需要人机协同、根据机器反馈进行调整的搜索方式不同， RAG 系统能够直接基于问题给出准确答案，大大减少了人工工作量。我们期望 RAG 系统能够在后续应用中进一步提高能力。

张颖峰： 我们对 RAG 技术的认知大致相同，可以认为 RAG 的应用分为两个阶段。最初，大约是去年，是 RAG 技术的普及期。在这个阶段，业界对使用 RAG 还是微调存在争议。我们的主要任务是将 RAG 的各个组件以尽可能易用的方式，通过 Ops 手段快速整合，以便让更多企业和个人能够搭建起这个系统。LLMOps 工具在 RAG 的普及中起到了重要作用。然而，我们也遇到了一些痛点，尤其是大模型本身的瓶颈问题，去年大模型的能力差距较大，模型的幻觉问题非常突出。

第二个阶段，我认为是从今年开始，是 RAG 加速普及的时期。根据我们接触的多个行业和客户，企业普遍认识到 RAG 技术的必要性。但在实际应用中，痛点依然很多。很少有企业愿意为一套基于开源的 RAG 系统付费。这也是我们愿意开发新的 RAG 平台的主要原因，因为瓶颈问题很多。

我们总结的瓶颈主要有以下几点：

• 第一，当前影响最大的是数据问题。杂乱无章的数据输入，如 PPT、Excel 表格、Word 文档、PDF 等，如果不合理处理，最终结果会非常糟糕。

• 第二，问答质量也是一个痛点。如果用户意图明确，当前的 RAG 方案仍然无法提供高召回率或精度，即命中较低。企业通常需要 90% 以上的召回率才可能付费。

• 第三，如果用户意图不明确， RAG 系统找到的相似问题，而不能直接作答，存在语义 gap，简单的检索方式无法找到答案。此外，长文档问答和多跳推理等问题也与此相关。

此外还有一些较小的瓶颈，比如幻觉问题。去年幻觉问题比较严重，但今年有所改善，因为大家对大模型的期待降低，不再指望它能回答高深的逻辑推理问题。我们更倾向于让模型回答总结性、摘要性的问题，这种情况下大模型的表现还可以。但许多 RAG 系统没有充分利用 RAG 的最大优势，即根据搜索结果生成有理有据的答案。如果模型没有生成引用，就无法提供有理有据的答案，这影响了用户体验。这个技术点相对较小，相比前面两点，对 RAG 技术的应用和推广影响不大。

目前我们面临的主要挑战包括数据杂乱、用户意图明确时的低命中率，以及用户意图不明确时的语义 gap，这些都是阻碍 RAG 技术走向更多企业、让企业愿意为之付费的主要瓶颈。

常扬： 从是否选择 RAG 的角度来看，我们首先需要从第一性原理出发，理解 RAG 的本质。RAG 通过利用外部数据源和文档知识，解决了大模型在偏见、幻觉、安全性以及实时性问题上的不足，满足了现实世界对数据的实时性、可追溯性、安全保护和隐私的需求。选择 RAG 与否，关键在于评估场景中是否存在对这些需求的刚需。例如， RAG 在解决数据实时性和可追溯性问题方面表现出色，特别是在精准问答领域。此外， RAG 也在推荐系统和信息抽取任务中表现优异。我们开发的开放域信息抽取产品，能够从任意文档中抽取信息，改变了以往需要为每种文档定制模型的情况，这不仅是技术上的革新，也解决了数据文档的实时性和可追溯性问题。

另一个视角是针对对幻觉问题要求严格的场景，如医疗行业， RAG 在药物研发和市场准入方面有很好的应用。在金融分析领域，由于市场信息每天都在变化，筛选有效信息并保证信息来源的可靠性至关重要， RAG  技术在这里同样适用。以及如投资分析场景，合合开发了分析师问答产品，专门针对财报、研报、公告等高信息密度、高实时性的知识库进行问答，满足分析师的需求。

我认为，RAG 能否解决问题的关键在于场景是否对 RAG 的能力有刚需。 如果刚需存在，这些场景的应用将会快速发展。对于非刚需的应用，我们可能需要考虑其他技术解决方案，如微调或选择具有超长上下文的大模型。

在挑战方面，互联网产品的思维可以用七个字概括：专注、极致、口碑、快。虽然 RAG 技术自 2020 年提出以来发展迅速，但许多产品并没有做到专注，技术效果也没有达到极致，导致口碑没有形成，产品未能通过 PMF 验证，难以进入市场。知识问答类产品可能一周就能做出演示版，但要达到好用的程度可能需要半年时间。现有的 RAG 基础流程存在许多需要优化的问题，包括检索文档内容解析错误、边缘案例处理不当、解析速度慢、知识库更新耗时长、机械分块丢失语义信息、目标检索内容召回不全、召回结果排序困难、答案生成存在遗漏等。

在今年 8 月 18-19 日的 AICon 上海站，我将分享 《向量化与文档解析技术加速大模型 RAG 应用落地》 主题，解决 RAG 最基础也是最本质的问题是出现爆款产品的基础。例如，文档数据中多种版式的精准解析，速度要快，精度要高。这些技术问题虽然讨论较少，但实际上非常重要。此外，如何在小资源下实现高性能和高精准度的 embedding 嵌入模型，也是目前面临的主要挑战。

郭瑞杰： 感谢常扬老师及前面两位老师的分享， RAG  技术在不同行业和场景下的应用仍在探索阶段，许多潜在的应用和优化尚未实现。当然， RAG  技术的发展和应用正在不断演进，随着技术的成熟和优化，预计 RAG 将在更多场景下发挥关键作用。接下来，我们进入今天的第二个话题。如何提高公众对 RAG 技术的认识和理解？在很多同学的认知里， RAG  技术似乎已经“烂大街”了？关于这个问题，大家怎么看？

张颖峰： RAG 技术在实际使用中确实存在一些挑战。虽然部署起来相对容易，但实际效果往往并不理想。然而，我认为 RAG 技术本质上是一种普及性的架构，而非特定于某个场景的解决方案。它是大模型服务 B 端市场的一种方式，因此我们不能因为短期内效果不佳就认为这项技术会被未来替代。

公众对 RAG 的认知一直存在较大争议。去年， RAG 刚开始流行时，业界围绕是否使用 RAG 还是微调展开了激烈讨论。经过大半年的辩论，公众对 RAG 有了更广泛的认识。现在，愿意选择微调的企业已经非常少， RAG 已经证明自己能够解决大模型针对企业内部私有数据的提问问题，不再需要进一步普及。

今年进入第二阶段，关于长上下文大模型的争论变得更加激烈。例如，阿里、Kimi、谷歌等公司的模型，上下文长度甚至可达百万，未来可能达到千万。今年二三月份，这种争论达到了高潮。当时，谷歌发布的一篇评测显示，长上下文在解决某些问题时比 RAG 表现得更好。这些问题是客观存在的，长上下文确实能更好地解决问题。在这种背景下，许多人认为 RAG 应该尽可能简化，不使用复杂的向量技术，而是用最基本的数据库和关键词搜索，然后利用长上下文的大模型来提供答案。这种方案在当前情况下是一种简单有效的解决方案，因为模型本身的上下文能力比 RAG 强。

但我认为争论仍将继续，因为长上下文模型和 RAG 之间不应是冲突关系，而应是合作关系。如果是个人端或简单场景，如个人知识库问答，使用长上下文模型确实方便。但一旦涉及企业级场景，如垂直行业，长上下文模型的适用性就会受到很大限制。长上下文模型并非无敌，例如，英伟达最近发表的一篇文章指出，如果给模型的上下文窗口太多，其回答质量会明显下降。因此， RAG 提供的精准段落对改进效果有显著提升。

RAG 和长上下文模型之间应该是相互配合的关系。在企业级应用场景中，如营销、合同合规、法律合规或供应链库存管理等，仅依靠长上下文模型是不够的。两者的配合对于解决实际问题至关重要。通过不断的辩论， RAG 的普及得到了极大的推动。今年二三月份，与 RAG 相关的文章在 arXiv 上的更新并不多，但现在更新频率明显提高，每天都有多篇相关文章发布。这表明 RAG 在工业界、产业界和学术界已经得到了共识。现在的讨论焦点是如何从技术角度解决 RAG 的痛点，而不是 RAG 是否还有存在的必要。

常扬： 我非常赞同张总提到的 RAG 技术已经获得广泛认知。例如，7 月份微软开源了与 Graph  RAG 相关的项目，这也引发了很多讨论，学术界也在持续解决相关问题。我想从应用的角度补充几点看法。

首先，我们要实现“技术去魅”，即让 RAG 技术从最初的神秘和疑问，转变为开发者们讨论如何应用它。这需要让大家理解 RAG 技术的底层逻辑其实简单直接，而非复杂晦涩。RAG 技术的真正价值在于它能够实现更准确的回答和更快的搜索，本质上与搜索引擎相似。这意味着通过建立与用户之间的信任，提供快速的检索体验，并找到准确度与响应度之间的最佳平衡点。RAG 技术完全有能力替代传统搜索，因为它能提供比网页搜索更好的效果。

为了实现这一目标，我认为 RAG 技术的广泛应用需要通过打造爆款应用来推动。百度李彦宏在上海的世界人工智能大会上也提到了这一点，他希望大家不要仅仅局限于大模型的竞争，而是去创造一些爆款应用。周鸿祎在微博上也表示支持这一观点。实际上，这需要我们持续专注于技术，优化场景理解，做好产品，让产品既可用又好用，从而打造出能够深刻改变用户场景和认知的 RAG 产品。

其次，关于“烂大街”的问题，如果这代表降低 RAG 技术理解和使用的门槛，我认为这是一件好事。 我们应该坚持引用更多能力，迭代和优化 RAG 技术以增强效果，同时简化 RAG 技术的使用门槛，让更多开发者能够使用它。比如通过 InfoQ 举办的技术大会进行广泛传播，让更多人理解 RAG 是什么，能够在合适的场景中使用它。同时，“烂大街”也有另一层含义，即技术看起来很好，但实际使用效果不佳，需要进一步加工和调整。这是我们需要优化和避免的。我们要提升 RAG 在检索和生成每个细节环节的效果，确保技术不仅可用，而且越来越好用。

RAG 在很多基础流程上仍存在问题，有很大的优化空间。去年有篇澳大利亚学者的论文，提出了 RAG 的七宗罪，涉及数据源、检索、排名、生成等多个方面的问题，这也是我们这些从事相关工作的人员的研究方向。此外， RAG 技术与其他技术的结合，如与 Agent 的结合，以及与更多场景的结合，都有很大的发展潜力。总结来说，我认为 RAG 技术的关键还是要有爆款产品，而从事 RAG 技术的人的关键是解决其基本问题，让 RAG 技术在这些爆款产品中可用，满足用户的期望体验。

欧明栋： 关于长上下文是否会替代 RAG 的问题，我们进行了许多测试。测试结果表明，当长上下文的内容过长时，其效果会受到影响。此外，长上下文的响应速度也会显著下降。为了让人们更深入地了解和认识 RAG ，我认为需要有经验丰富的产品经理来设计一些易于使用的产品功能，这可能会激发大家对 RAG 更大的兴趣。

最近，无论是在技术论坛还是社交媒体上，我们经常看到有人批评 RAG 的技术含量低。传统的 RAG 是很容易上手，而且有像 LlamaIndex、LangChain 这样的框架，只需几行代码就能部署一个 RAG 系统。但从产业落地的角度来看， RAG 目前还不能完全满足需求。例如，我们采用的 Native  RAG ，即搜索加上大模型总结的链路，实际上并不能很好地解决用户抽取信息和解决问题的场景。从 RAG 本身的目标来看，目前的 Native RAG 技术还远远达不到这个目标。正如刚才两位老师提到的，要实现这个目标，还有许多问题需要解决， RAG 领域还有很多技术需要我们去探索。

郭瑞杰： 虽然 RAG 技术可能被广泛讨论，但这并不意味着它已经普遍应用或失去了创新性。相反，这可能是技术发展和成熟过程中的一个自然阶段。接下来，我们来讨论今天的第三个话题。基于 Agent 的高级 RAG 如何针对复杂问题提供解决方案？

常扬： 在今年 8 月的 AICon 上海站上，很多演讲都涉及到了 Agent。由于今天没有投屏，我们讨论的更多是方向性的内容，届时在大会现场，各位老师的分享一定是内容丰富、干货满满的。

欧老师刚才提到，目前大家关注的是 Naive  RAG ，而不是包含 Advanced 或 Modular 特性的 RAG 。现在的关注点确实是纯粹的问题检索，核心在于单轮检索的准确性和速度。 例如，企业可能需要迅速检索与公司相关的最新公关新闻及其应对策略。然而，在现实场景中，问题往往更复杂，企业希望结合他们的知识库解决项目中的问题，这些需求的复杂性往往无法通过单轮 RAG 来解决。

这就引出了基于 Agent 的高级 RAG 的问题。在真正的企业场景中，包含几个问题：用户的意图往往不明确，需要多轮对话来确认；需要从多个来源收集信息，包括文档数据库、知识库、外部 API 和搜索网页等；还需要多步推理才能得到综合答案。在这种场景下，就需要基于 Agent 的高级 RAG 。

以我们正在开发的分析师问答产品为例，我们调研了基金公司的需求。基金公司的领导需要对某个调研方向进行全面调研，这个需求给到分析师。分析师需要与领导进行多轮对话，了解具体需求，如技术可行性、产品市场占有率、市场分析、竞争对手调研等。这些信息需要从多个数据源获得，经过复杂检索和分析整合，最后按照用户要求的格式（如 PPT 或 PDF）完成需求。这种场景反映了真正的企业需求是非常细致的。

大家看到的或讨论的 Naive  RAG 案例，实际上只是项目中的某个部分需求。为了实现这一点，系统必须能够处理和整合来自多元的多样化数据，并在每一步提供精准信息，最后根据用户意图准确回答。

我再谈谈 RAG 加 Agent 的本质。我认为它的本质是复杂问题的分治。Agent 的定义大家都很清楚，我想从另一个角度简单解读一下。Agent 通过将任务拆解为 Plan（对应多轮对话，理解用户意图和任务规划）、Do（使用外部工具完成任务）、Check（任务总结）、Action（记忆及任务经验改进后的执行），整个 Agent 对应了我们做项目的整套 PDCA 流程。融合 Agent 的 RAG 可以将原来的单轮对话调整为多轮对话，理解用户意图，拆解任务，使用更多工具解决非结构化、半结构化数据检索的问题。这种方式让 RAG 系统变得可定制、可扩展，可以根据具体任务调整使用工具完成复杂任务。以分析师问答场景为例， RAG 加 Agent 可以自动检索、分类和分析反馈，最终形成一个详细的报告来帮助企业决策。这样的场景本质上是将技术转化为企业可接受的项目价值，这是 Agent 的关键，它符合企业对复杂度的判断。

张颖峰： 我在这里稍微补充一些与我们最近发布的 RAG  Flow 功能密切相关的内容。我们在周一晚上发布了新版本，其中包括了 Agent 功能。RAG 和 Agent 之间的关系是相互基础性的。关键的一点是，Agent 为 RAG 提供了基于有环图的编排能力。因为我们知道 RAG 的效果有待提升，所以我们需要用各种技术手段来补充，这种补充意味着我们不能只使用简单的单轮对话。我们需要将对话转化为多轮，引入查询意图、分类、关键词抽取等不同的算子，以编排的方式而不是单轮对话的方式，将对话组织在一起。Agent 的编排能力及其反思机制是其重要能力之一，即评估 RAG 生成和检索出来的质量，如果质量不高，则需要不断消耗 token 进行搜索，直到得到满意的答案。

如果将 Agent 视为 RAG 的基石，它主要起到的就是上述作用。为了解决前面提到的各种痛点，比如数据抽取、命中率不高、找不到答案等问题，我们都需要通过 Agent 或称为 Agentic 的 RAG 来编排，以解决这些问题。Agent 提供了这样一个框架和机制，我们在这个框架内不断添加各种算子，如查询意图、改写、关键词抽取、知识图谱抽取等，将这些不同的算子加入后， RAG 的质量就会得到提升。

反过来，当 RAG 能够以这种方式提供满意的答案后，Agent 就可以在 RAG 的基础上进一步包含企业所需的具体场景业务。例如，我们最近开源的产品中加入了 Agent，并提供了两个模板：一个是客服系统，它实际上是将 RAG 应用于垂直领域时所需的业务系统，需要用工作流的方式进行编排。工作流通常是有向无环图，而 Agentic  RAG 引入高级 RAG 时，需要反思来编排查询意图、查询改写等。有了这些能力后，实现工作流就可以让 RAG 以 Agent 的方式对接企业的业务系统。另一个是通用模板，用户可以用来创建自己的工作流，如猎头寻找候选人并与他们沟通。当对话意图不明确或需要直接获取候选人的联系方式时，这实际上就是一种企业的业务工作流。因此， RAG 和 Agent 结合时，关键在于如何让 RAG 服务于具体的垂直场景。我认为 RAG 和 Agent 是互为基石的作用。

欧明栋： 基于 Agent 的 RAG 应用实际上是很自然的一步。从客户反馈来看，传统的单轮 RAG 无法解决很多问题。当前，许多研究正在探讨多跳问题和模糊意图问题，这类问题都需要 Agent 的参与。因此，开发 Agent 功能成为了一个自然的趋势。我们的 Agent 开发还没有达到完美的效果，但我愿意分享一些我们的实践、经验和教训。

目前，我们在开发的 Agent 是完全自主的。在之前的版本中，我们已经支持用户编排，而现在我们希望 Agent 能自主解决客户问题。我们设计的 Agent 分为两层：第一层 Agent 负责简单的路由，将任务分配给更大特定任务的 Agent 流水线，例如问答、总结、意图澄清，甚至包括自定义功能，如客服中直接转人工等。基本上，第一层 Agent 执行的是大的路由任务。第二层 Agent 则负责更细致的任务。以问答 Agent 为例，它是一个比较常规的自主 Agent，利用大模型的逻辑推理能力进行规划，然后调用工具。模型本身的规划能力非常关键，它需要判断问题回答的进度、缺失信息和补充需求。工具也很重要，可能需要进行问题改写、搜索、SQL 查询，或者使用 Code Interpreter 进行编程和计算，以提供更准确的答案。关于幻觉问题，许多论文提到通过 self- RAG critic 和 self-refine 等 进行自我检查可以减少幻觉。这里会有各种工具，包括客户自定义的工具。例如，金融客户可能需要非常专业的金融指标计算，这就需要明确定义的自定义工具应用。问答 Agent 主要依赖模型的规划能力和调用工具的能力。

目前，我们在开发的 Agent 是完全自主的。在之前的版本中，我们已经支持用户编排。我们设计的 Agent 分为两层：第一层 Agent 负责简单的路由，将任务分配给特定任务的 Agent 流水线，例如问答、总结、意图澄清，甚至包括自定义功能，如客服中直接转人工等。基本上，第一层 Agent 执行的是大的路由任务。第二层 Agent 则负责更细致的任务。以问答 Agent 为例，它是一个比较常规的自主 Agent，利用大模型的逻辑推理能力进行规划，然后调用工具。模型本身的规划能力非常关键，它需要判断问题回答的进度、缺失信息和补充需求。工具也很重要，可能需要进行问题改写、搜索、SQL 查询，或者使用 Code Interpreter 进行编程和计算，以提供更准确的答案。这里也会有各种工具，包括客户自定义的工具。例如，金融客户可能需要非常专业的金融指标计算，这就需要明确定义的自定义工具应用。问答 Agent 主要依赖模型的规划能力和调用工具的能力。关于幻觉问题，许多论文提到通过 self-critic 和 self-refine 等 进行自我检查可以减少幻觉。

在实际使用中，Agent 虽然理想美好，但现实依然充满挑战。Agent 相比传统的 Native Agent，迭代步骤更多，可能会有误差累积。在多次迭代中，幻觉可能会累积，我们在多步 Agent 之后发现了这种问题。此外，Agent 还可能出现死循环，无法停止迭代，或者出现早停，即在未得到答案前就停止了。我们还面临一个较大的问题是上下文长度的管理。由于 RAG 会进行多次检索，我们需要决定是否保留这些检索内容。如果全部保留，上下文可能会过长；如果不保留，可能会遗漏信息。在这方面，我们还需要不断迭代和平衡。

郭瑞杰： 下面请老师回答一个观众问题：“在整个 RAG 过程中添加各种技术手段，使得处理过程过长，如何进行优化呢？”

常扬： 我认为技术发展初期遇到无法解决的问题是很自然的，这会促使我们引入新的模块来应对。但我依然坚持，在最基础的关键流程中，我们必须实现速度和性能的最优化。例如，我们一直在研究文档解析问题，这不仅需要解决不同版式元素的稳定性和准确性，还要提高效率。最近，我们已经能够做到在大约 1.5 秒内完整解析 100 页的 PDF。

我的观点是，从最基础的产品出发，长的编排并不是问题。真正的挑战在于，在横向探索技术复杂度时，要在每个基础模块上提升效率。 目前，许多服务过程相当冗长。以微信春晚抢红包为例，这个过程背后需要经历的步骤非常多。尽管在技术初期确实较慢，无法满足高并发需求，但在当前更复杂的场景和更高要求下，即便面对上亿的并发量，依然能够保持良好表现。这是因为每个模块都达到了产品级的性能标准。现在，没有人会说移动互联网技术在多个微服务串行的情况下会出现效率问题。

张颖峰： 在我看来，目前 RAG 处理过程的时间过长并不是一个主要问题。我们可以将 RAG 的工作流程分为几个阶段：首先是数据抽取，我们会使用多种模型以语义的方式抽取和解析数据；其次是文档预处理，包括知识图谱的抽取和文档聚类等；然后是索引构建，以及排序和查询改写等操作。每个阶段都需要进行大量工作，以确保最终的效果。每个阶段的工作与我们后面可能遇到的问题息息相关，都需要精心处理，从而保证最终效果。因此，目前阻碍 RAG 普及的主要痛点不是速度，而是效果。 实际上， RAG 的速度已经相当快。如果我们从数据库的角度来看， RAG 更倾向于服务于一个“写少读多”的场景，即我们可能会上传一些数据，一旦这些数据被加工处理，接下来更多的是围绕这些数据进行问答。

如果技术发展必须在速度和效果之间做出取舍，我认为速度是可以有所牺牲的。 毕竟，目前我们必须通过不断迭代来确保效果，这是需要优先解决的问题。我预计，要达到令人满意的效果，可能还需要半年到一年的时间周期。在此期间，我们应该专注于提升 RAG 的效果，即使这意味着在速度上做一些妥协。

郭瑞杰： 有个用户提问说，用 RAG 来做推荐系统，但是效果一直不太好，请问老师们有什么建议？他做的推荐系统是一个专家推荐系统，用户提出需求，然后从人才库中推荐信息。

张颖峰： 我不妨为我们的数据库做个广告。推荐系统实际上需要一些复杂的业务逻辑。例如，你需要通过各种混合召回方式，将候选对象（candidate）搜索出来。接下来，使用不同的排序方法，包括引入基于业务逻辑的排序和基于模型的排序，将它们结合起来，最终给出一个答案。如果仅使用单一策略，效果可能并不理想。

使用 RAG 构建推荐系统，我认为这是一个非常前沿的领域。目前，大家使用 RAG 进行搜索还没有做得很好，而推荐系统是一个更加复杂的系统，涉及的效果和业务场景变数都很大。我们目前还没有开发推荐系统。不过，根据我过去在推荐系统领域的经验，解决问题的方法无非是从召回和排序两个角度入手。召回时，你需要采用多种手段，比如关键词召回和向量召回，至少要进行混合搜索。排序时，则需要结合业务逻辑规则和基于模型的排序。这些手段都需要应用到系统中，以解决推荐问题。目前构建推荐系统不会面临我们之前提到的数据抽取、查询改写或知识图谱抽取等问题。因此，仅从索引和召回排序这两个角度出发应该就足够了。

常扬： 我认为使用目前效果较好的方案，比如张总提到的 RAG 工作流，是一个很好的选择。此外，实际上可以使用像 LangChain 这样的工具，它提供了一些回调功能。这些回调函数能够展示 RAG 过程中的内容，包括检索到的内容和与文本块排序相关的信息。通过深入观察每个环节，你可以确定针对你的具体情况是哪些环节出现了问题。这样的工具可以帮助你更细致地了解和优化 RAG 的工作流程。

欧明栋： 使用 RAG 构建推荐系统确实是一个相当大的挑战。与传统的推荐系统不同，传统系统更多依赖用户的行为数据，而使用 RAG 进行推荐，我理解其核心是基于大语言模型，也就是基于语义来进行推荐。过去，基于用户行为的推荐系统能够学习到许多行业特定的模式。如果我们不再依赖行为数据，只使用语义信息，我们可能需要在上下文中体现出行业内的模式和常识信息。如果这些信息能够在上下文中得到体现，大型语言模型或许能够通过学习这些模式来进行合理的推荐。如果直接让大型语言模型自己做出判断，在某些情况下可能会比较困难，特别是在长尾场景中，大模型可能缺乏相应的知识，无法直接进行合理的推理。在这种情况下，可能需要引入一些上下文相关的包或特征，加入一些先验知识以辅助模型做出更好的推荐。

郭瑞杰： 前面 3 个话题主要讨论了 RAG 技术的现状、应用情况、高级 RAG 技术解法等，最后，咱们聊聊 RAG 技术未来的发展方向，有哪些新兴的技术和方法可能会给 RAG 技术带来冲击？

常扬： 我们的理念始终是从用户出发，开发出既可用又好用的产品。我们希望推动 RAG 行业的发展，比如提高数据源清洗的准确性，加快知识库更新速度，改进 trunk 分配的智能化，提升 embedding 模型的性能，以及优化 rerank 模型和 prompt 生成的最佳实践。我相信，在未来半年到一年内，这些方面会取得很好的进展，这将是 RAG 发展的一个方向。

就像 ChatGPT 解决了传统深度学习中数据不足和算力消耗大的问题，并推出了爆款产品一样，技术的底座打好后，爆款产品自然会出现。这种技术的范式或大规模应用从两年前开始，已经席卷了整个 AI 行业。在 8 月份的 AICon 上海站上，我分享的也是关于文档解析、embedding 模型等方面的工作，如何使 100 页 PDF 的解析更准确、速度更快。

当然，还有很多基础工作要做，比如用户意图识别、检索技术（结合稀疏向量检索、张量检索、关键词全文检索等）、多路索引、多级路由，以及海量数据的高性能检索，可能还会涉及到向量数据库。此外，还有上下文压缩、句子窗口使用、Self- RAG 等，这些都是 RAG 最基础环节中的提升点。我认为，这些基础工作完成后，才有可能出现爆款产品。

接下来发展可能是多模态应用。RAG 技术和思想能否应用于图片、音频、视频、3D 模型和代码等多模态情况，我认为这非常值得期待。我们可以检索文本、图片、视频，进行图文搜索，甚至检索视频片段。现在互联网上的信息很多是视频信息，包括短视频和长视频，它们包含了丰富的知识内容。如果能够检索视频中的某一帧，那将是应用广度和深度的巨大提升，可能会出现很多 C 端的爆款产品。

至于冲击，我认为 RAG 能够长期立足的原因在于它的实时性和数据安全性。微调和 RAG 之间始终存在时间差，即使微调不断迭代，这个时间差也不会消失。大模型虽然有更强的上下文能力，但它们无法处理非常海量的数据，无法保障数据安全性，也无法解决 ROI 问题，即收益和高推理成本的比较。这些其实都是 RAG 的强项。

总结一下，我认为 RAG 发展的基础效果是第一位的。当这些基础打好后，我们就会看到很多 ToC 和 ToB 的应用出现。其次是多模态应用，我相信这会开启一个新时代。现在大模型在 C 端的产品和应用还不多，但多模态的发展可能会出现消费级爆款。微调和长上下文对 RAG 没有冲击，反而是一个非常好的结合，通过这种结合可以完成非常好的产品。

欧明栋： 多模态确实是一个重要的领域，它应该会显著提升 RAG 的体验。原因在于，用户的理解往往是基于多模态信息的，我们日常接触到的数据也大多是多模态的。例如，人们通过结合文本、图片、音频和视频等多种形式的信息来获得更全面的理解。

近期，关于大型模型在非文本（non-context）模态上的能力以及 Agent 能力对 RAG 影响的讨论越来越多。长上下文大模型的能力确实能够提升 RAG 本身的效能。但是这并不意味着检索和逻辑推理的能力就能被完全替代。这些能力仍然是 RAG 不可或缺的一部分。

对于 Agent 而言，目前的趋势是将传统 RAG 的检索过程作为 Agent 的一个工具，以此来实现更好的集成。Agent 可以利用 RAG 的检索功能，结合自身的优势，比如任务规划和执行，来解决真实场景中的复杂问题。

张颖峰： 我想从两个方面来探讨 RAG 的未来发展。首先是 RAG 应如何演进，其次是未来 RAG 可能受到哪些技术的冲击和影响。

对于 RAG 的演进，我认为可以从四个阶段来考虑：数据抽取、数据预处理、索引和查询改写。

第一阶段：数据抽取

在数据抽取方面，理想的情况是有一个能够处理各种文档的抽取大模型，无论文档中包含什么内容，如流程图、柱状图、饼图等，都能解读出来。如果能够开发出这样的大模型，它将解决 RAG 在数据落地方面的许多痛点。

第二阶段：数据预处理

数据预处理目前主要包括 embedding 模型和知识图谱的抽取。Embedding 模型在一些垂直场景中的应用需要进一步优化，以减少向量干扰。知识图谱的自动化构建，如微软的 Graph  RAG 所展示的，为 RAG 问答质量的提升提供了一个很好的起点，尤其是对于多跳或长文本问答。

第三阶段：索引

索引阶段，我们已经尝试了多种搜索手段，包括全文搜索、向量搜索、系数向量搜索，甚至张量搜索。IBM 研究院提出的 Blended  RAG 通过三路召回混合搜索，可以达到最佳效果。我们复现了这一结果，并发现使用张量等手段可以进一步提升效果。

第四阶段：查询改写和排序

最后一个阶段是查询改写和排序。这一环节的技术进步将进一步影响 RAG 的迭代和发展。

我认为，在半年到一年的时间里，这四个阶段都会有显著的进展。这些进展将决定 RAG 如何应对未来的技术冲击和影响。

关于未来对我们技术可能产生的冲击，我认为主要有以下几个方面。

首先，我坚信 AGI（人工通用智能）终将到来。随着大模型能力的不断升级，例如未来可能出现的 GPT-5 或其他更高级、具备推理能力的模型，它们的到来可能会对我们目前 RAG 的检索行为产生影响。在这种情况下，我们可能需要重新考虑是否继续使用现有的技术堆栈和检索策略，这是一个目前我还无法回答的问题，但可以预见的是，它将对 RAG 产生一定的影响。

其次，技术的演进可能会导致我们更深入地将 RAG 与大模型结合起来。目前，有些研究方向并不是简单地称之为 RAG ，而是称为基于检索增强的大模型。这种研究将数据库检索结果与模型内部的 embedding 深度耦合。我认为这是一种有趣且有益的探索方向，两者之间的交互应当是非常深入的。

从这些角度来看，未来 RAG 产品的技术演进形态可能会受到显著影响。然而，核心的行为和需求是不会改变的。我们始终需要一个长期记忆体，如硬盘，来配合模型，以服务于更复杂的场景。这一点是不会改变的。不过，具体的技术栈和表现形式可能会随着技术的发展而发生较大变化。

郭瑞杰： 未来多模态  RAG 、Agent、基于 LLM 的知识图谱等技术深度结合，可能会带来新的优化方法和产生新的应用场景。这些新兴技术和方法可能会给 RAG 技术带来新的冲击和发展机遇，推动 RAG 技术在更多领域和场景中的深度应用，并实现更高的性能和可用性。感谢 3 位老师的精彩分享，期待 3 位老师在 AICon 现场的发挥。