RAG架构在复杂场景中的演进：跨模态知识联邦和统一语义推理实践

伴随着大语言模型（LLM）产生检索增强（RAG）随着技术的深度整合，智能客服、医疗辅助诊断、金融智能投资研究等场景已经实现了知识库检索和问答系统的规模化。但是，传统的企业级知识交互场景下， RAG 在知识片段的语义联系和跨模式结合推理等方面，技术遇到了瓶颈。当检索到的文本内容分散在不同的段落、文档和不同的数据源中时，如何高效、准确地检索和关联所有相关片段，并准确地总结和生成最终答案？

在 InfoQ 举办的 QCon 枫清科技合作伙伴、智能平台事业部总经理王传阳在全球软件开发大会(北京站)上分享了“在复杂的场景中 RAG 结构演进:跨模态知识联邦和统一语义推理实践”，他深入剖析了基于跨模态知识的联邦和统一语义推理。 RAG 结构化，并结合生产实践分享实际应用效果，以及后续技术演进方向进行系统分享。

内容亮点

• 面向复杂场景应用：聚焦企业级复杂知识交互，解决实际业务痛点
• 跨模态知识联邦：打破传统 RAG 模态限制，实现多模态数据的组合
• 统一语义推理：提高知识联系和问答的准确性，更加智能化

下面是演讲实录(经典) InfoQ 不改变本意的编辑整理)。

RAG 技术概览

当模型出现时，我们发现它有许多问题，其中最典型的就是“幻觉”现象。因为大型模型在实践初期并没有接触到最新的知识，但是在应用大型模型时，也没有使其了解我们希望掌握的最新知识。所以，当被问及较新的问题时，大模型很难获得新的知识，从而产生各种幻觉。这样就让我们思考如何让大模型了解这些知识。所以，我们在外部建立知识库，并利用它。 RAG（Retrieval-Augmented Generation）框架，使大型模型能得到相关的前后文本，对其进行润色后，最终回到用户的答案。

RAG 主要范式

在 RAG 在演变过程中，出现了多种形式。从最初的朴素开始 RAG，到高级 RAG，再到模块化 RAG，其核心链接始终围绕三个步骤：检索、检索和内容生成。高级 RAG 更多的处理是在检索阶段前后增加的，而模块化 RAG 然后将这三个步骤进一步细化为五个不同的阶段，使每一个部分都能够更加专注于理论和技术突破。例如，在检索部分，针对分层。（chunk）对许多论文和框架进行了优化。基于模块化 RAG，能衍生出适合不同场景的各种场景。 RAG 形态。另外，还有与组织安排有关的东西。 graph RAG，运用知识图谱（knowledge graph）对知识提取、实体与关系联系等进行操作，这些内容也在相关图中得到总结。

RAG 主要使用场景

RAG 过去一段时间的典型应用领域包括但不限于下列。在判断 RAG 是否适用，关键在于本场景中的知识库或大模型是否需要参考动态频繁更新的知识库。要是需要，那么 RAG 这几乎是不可或缺的。尽管类似的功能可以通过大模型微调或使用私人信息进行蒸馏来实现，但是从成本和速度来看，RAG 见效速度更快。例如，在智能客户服务场景下，产品库将实时更新， RAG 技术构建外部知识库，无论知识库如何变化，大型模型都可以随时从中提取最新产品的相关信息，以回答用户的问题。

复杂的场景挑战 一 异构知识

在 RAG 在场景中，除了上面提到的一些简单的场景，还会有各种复杂的场景，尤其是异构知识的处理。异构知识有很多特点。今天，我们主要关注两个特点:结构的离散性和模式的多样性。

结构的离散性

异构知识的结构离散是一个复杂的问题。虽然“结构离散”这个词可能有点牵强，但是异构知识确实有这个特点，同步知识也会面临类似的问题。例如，相同主题的知识可能分散在不同的文档和媒体中，甚至可能出现在照片、文档、视频或关系数据库中。他们都可能描述同样的事情。如果你想让大模型统一理解这些知识，你需要考虑如何去做。

即使在同一文档中，知识的离散也是一个问题。比如，一个 200 页的 PDF 在文档中，可能会在第一页提到“我是张三，今年多大，绰号小三子”，而在最后一页总结中，我提到“小三子这一生是辉煌的一生”。在这种情况下，如何让大模型理解“小三子”其实就是“张三”，在文档的不同部分取得联系是一个实际问题。传统的 RAG 在处理这一问题时，技术面临着挑战，因为很难保证切片逻辑在语义上是连贯的，同一主题的内容也不能切割在一起。另外，切片的大小也是个问题。若切片过大，将影响最终召回知识的准确性；如果切片过小，内容就会更加分散。与此同时，只要进行切片和向量进库，就很难保证跨文档知识的完整性。最后，客户很难获得关于某个知识主题的完整信息，大模型无法以此为前后回答客户的各种问题，一般只能给出片面的答案。

多样化的模态

模式多样性是构造离散的基本原因之一。知识模式包括文本、音频、视频、照片、关系数据库、表格等。传统 RAG 过去，技术主要处理文本数据。现在，虽然有些技术已经开始处理多模态数据，但总的来说，很难有一个理想的。 RAG 该框架可以很好地处理各种多模态数据。它带来了两个主要问题：

多模式检索：例如，提供一段文字，可以检索出不同模式的内容，如照片、视频、表格等。

跨模态检索:比较简单，比如提供一段文字，可以检索相关照片，或者反过来输入一张图片，检索相关文字。

怎样应对异构知识的考验？

面临这样的挑战，我正在制作。 PPT 试着咨询一下 DeepSeek 他们的观点，他们给出的答案和思考过程在大方向上是可靠的。对于构造离散的问题，他们提到可以动态地将这些段落合并起来，这个指导方针很好，但是具体怎样做到合并并不详细。另外，他们还提到相关段落可以通过图形结构或者知识图谱来连接，这似乎是一个比较接近解决方案的方向。对模式多样性的问题，他们指出需要处理不同模式的数据，尽管这是一个正确的方向，但是感觉并不深入。它们提到图像应该怎么处理，文字应该怎么处理，并且强调处理后需要处理。综合多模态信息，结合两者综合生成。总的来说，这些想法是没有问题的。但是，在细节上，如果继续基于这些内容提问，DeepSeek 有可能提供更多详细的信息。

基于知识库和统一语义层的结合 RAG 架构

核心部件 —— 结合知识库

结合知识库主要是通过知识融合技术将左侧分散的各种多元异构数据整合到统一的知识库中，包括指标、结构化数据、文档、图片等信息。知识融合的过程涉及到许多常用的技术手段。例如，对于文档数据，将使用文档分析器和切片工具进行处理，并提取元数据。对关系数据库中的数据源，将提取其中的指标和元数据。另外，还可以通过可视化工具帮助用户理解知识库中融合了哪些数据及其关系。将不同粒度、不同模式的数据结合到知识库中，作为一个逻辑存储单元，位于结构的底部。实际上，整个过程就是将多模态数据转化为知识的过程。

从技术形式和产品形式来看，结合知识库是一个逻辑概念。底层物理存储是一致的。例如，向量数据库中仍然存储文档，关系数据库的数据源(例如 MySQL 或 PostgreSQL）它们仍保留在原来的地方，只是它们的元数据被提取出来，并以逻辑视图的形式存储在一个整合的知识库中。

就产品形态而言，我们可以通过产品中的知识库模块向用户展示结合知识库的概念。例如，客户可以创建文档知识库、网页知识库、数据库知识库、指标知识库等不同类型的单一知识库，也可以创建知识库。建立知识库后，客户有两种选择:一种是建立新的文档库、指标库、图片库等。在空洞的知识库中，统一组织数据；二是将现有的文档库、指标库、数据库等引入到知识库中，以逻辑的方式组织起来，产生新的知识库。另外，用户还可以在整合知识库中指定关注的领域模型，即关注的实体和关系。比如在教育行业的知识库中，可以配置与教学相关的实体及其关系，如关注教师、考题、学生等，为后续统一语义层的生成铺平了道路。

核心部件 —— 统一知识图谱：图谱生成

使用统一知识地图时，首先要考虑如何生成，然后如何使用。通过一张图片可以理解生成统一知识地图的过程。在图片的左侧，我们有各种不同模式的数据，如文档、照片、视频和关系数据库。当我们在知识地图中提取相应的元素时，这些元素是不同的。

对文档数据，我们使用了简化版本 Graph RAG（比如 Graph RAG Light）从文档中提取物理和关系。由于这会带来更高的成本和性能问题，所以一般不会提取所有内容。在建立知识库之前，我们会指定关注的实体和关系，这与业务问题和领域模型的结合密切相关。假如在建立知识库时明确了要解决的业务问题和支持的领域模型，那么在提取文档内容时就会更加有针对性和高效。

对于图片和视频，我们可以提取人民币信息(这些系统在模型时代之前做了很多标签等工作)。通过多模式模型或客户现有的系统，并将这些信息放入统一的知识地图中。对于关系数据库，我们会提取各种元数据，如数据表的用途、字段的业务意义等。，并将这些信息放入统一的知识地图中。将知识图谱放入其中，必然会涉及到实体的合并和关系的发现，最终形成一个完整统一的知识图谱。

核心部件 —— 统一知识图谱：图谱检索

有了这样的知识地图，我们如何在框架中使用它？从客户问题出发，当客户提出问题或表达任务需求时，我们会先在向量库中匹配实体和关系，这实际上是一种语义搜索。目的是了解客户问题中涉及的实体和关系类型。然后，我们将根据这些实体和关系在统一的知识地图中进行。N 度拓展查询(如二跳或三跳查询)，提取相关子图。二跳或三跳查询的实际跳数可以根据实际需要配置。一般二跳查询就够了，因为三跳查询可能太大了。通过这种查询，我们可以将问题中的其他相关实体和关系联系起来，形成子图。

这个子图必须涉及多模态信息，包括文本、关系数据库和音视频文件的元数据。基于这些元数据，我们从底层物理存储中获取具体数据，并将其发送到大型模型中进行润色和输出，从而为用户提供相对完整的答案。因此，这里的核心是基于统一的知识地图，生成包括多模态数据在内的子地图。

与 GraphRAG 的对比

就文本处理而言，我们将使用它 GraphRAG 相关技术。每个人都可能会问，整个技术是否重点关注？ GraphRAG 这样的想法实际上是有道理的。在文字处理方面，我们站在巨人的肩膀上，但是也做了一些改进。例如，通过指定实体和关系，可以得到缓解 GraphRAG 盲目抽取工作。这与其说与 GraphRAG 与其说是对其进行优化和改进，不如说是对比。

就多模态知识而言，GraphRAG 现在主要支持抽取实体关系，为文本(如单篇或多篇文档)构建图谱。从计算率的角度来看，提前指定的领域模型、实体或关系可以使提取过程更加集中。在冷启动难度方面，在我们提到的架构中，确实需要投入一些时间来整理和放入统一的图表、指标和其他元数据。就R&D的复杂性而言，我们 GraphRAG 在没有使用完整链接的情况下，进行了垂直简化。同时，在横向工程化方面进行了拓展，如增加了元数据提取、多模态图片和视频识别等功能，构建了包括多模态数据在内的知识地图。

基于知识库和统一语义层的结合应用架构。

对我们提到的架构进行重新梳理，两个关键字仍然是结合知识库和统一语义层，它们都体现在这个结构图中。以下是知识库的组合，包括不同粒度和模式的各种数据；上面是统一的语义层，包括统一的语义库和统一的知识图，为上层的语义服务提供支持。一般情况下，我们会通过公司知识中台或其它平台对底层的统一语义层和整合知识库进行优化和更新。企业知识中台也可以承前启后，为上层应用建设提供支持。由于我们需要把底层的知识和数据转化为实用价值，最终还是要通过具体的应用来实现。所以，公司知识中台在这里提供了构建应用的能力，如智能体应用、工作流应用等多种形式的应用。这类应用结合了统一的语义层和整合的知识库，最终交付给客户并落地为特定的智能体。

分享生产情景实践

案例分析一：某医院电子病历查询与智能问答业务

我们在生产场景中有两个具体的实践案例，首先是某医院的电子病历查询和智能问答业务。近几年来，呼吸道传染病频繁发生，如甲流、乙流等，给医疗行业带来了巨大的压力。病人看病时常面临“看病” 30 秒，排队 3 “小时”的困境，医生也希望有一个更智能的方法，帮助他们快速回顾过去患者的疾病、治疗方法和恢复情况，从而为当前患者提供更准确的治疗建议。

具体情况如下：张三因流鼻水、发热等症状来看病，医生将这些症状输入智能助手，查询推荐的治疗方法。所以，我们采用了基于知识库和统一语义层的方案。结合关系数据库中的结构化数据(如病人信息、医嘱、住院记录)和电子病历中的文本数据。统一语义层定义了医疗相关的概念。例如，“热”是指体温在体温中。 37℃到 在40℃之间，并描述了相关症状。

在统一的知识地图中，我们构建了以患者为中心的地图结构，包括医生建议、住院记录、手术记录等实体，从电子病历文本中提取疾病、治疗方法和质量信息，并将其与地图相关联。例如，具体症状(如支气管炎)可以在患者节点下联系起来。、治疗方法(如药物名称)和疗效(如康复状态)。

在实际应用中，医生提出了“张三有这些症状，需要治疗”等问题。系统会根据时间段(如过去一个月)进行语义搜索，找出相关的实体和关系，在知识地图中获取子地图。例如，系统将通过向量库快速搜索与“发热”和“干咳”相关的患者记录，并结合电子病历中的详细信息，生成综合治疗建议。最终，医生可以看到历史上类似病人的治疗方案，并据此为张三提供参考。

案例分析二：某银行风险监管指标分析助手

银行风险指标控制是第二种情况的业务背景。银行已经建立了风险指标库，并希望通过传统 BI 系统通过点击按钮等方式查询指标。当前，许多产品和解决方案都支持通过归因分析和辅助决策等自然语言查询指标，并在此基础上进行预测和分析。但是，顾客的需求并不止于此。它们指出，指标不仅与数据有关，而且与许多文档规定有关。例如，其它部门经常发送与指标和监督有关的文件，提示指标应符合有关规定，或通知指标算法的变更。在真实场景中，这些文件可能会干扰指标系统的输出。

对于这些问题，客户提出了一个要求：在指标应用场景中，结合文档分析，对指标进行全面的查询和分析。具体效果如下:当查询“过去一个月不良贷款率是多少”时，一般的指标系统可能只会回归。 5.01% 因此，更高级的系统将进一步分析相关数据的波动。但是，如果文件库中有明确规定不良贷款率不能高于不良贷款率的文件 5%，而且这份文件被列入知识库，所以当查询记录显示超过时， 5% 当时，系统需要额外的提醒，显示具体的规定来源和内容，提示业务人员注意这个问题。

这种效果的实现是基于我们之前提到的框架。具体来说，我们会根据知识库中的指标库和文档提取统一的元数据和数据实体。在分析模型的指标时，通过提示引导模型检查文档库中是否有相关的警告或规定。一旦发现相关规定，模型就会发出相应的警告或提醒。通过这种方式，业务人员可以快速了解指标问题的根源，从而做出更准确的决策。

展望未来演进方向

在共享的场景中，虽然很多案例都是成功的，但在实践中确实存在一些挑战。从积极的角度来看，这些挑战可以被视为未来前景的方向；另一方面，也可以说这些方面还存在一些不足。以下是四个方面的分享。

动态更新统一语义层

那是一个很实际的问题。由于使用了图片（graph）与算法相关，图纸的更新，尤其是实时动态更新，并不容易。目前，虽然有一些工具或框架可以支持实时图纸的更新和计算，但这些技术手段只能部分处理统一语义层动态更新的问题。

高效处理图像、视频数据

目前，在处理图像和视频数据时，我们仍然处于元数据阶段，没有将图像本身的数据和文本联合嵌入，也没有实现统一的召回。虽然我们肯定会评估和考虑相关的技术手段，包括它们的性能和质量，但可以肯定的是，这是未来的发展方向。

赋能行业语义模型和行业图谱。

目前，公司通常需要依靠自己的力量来构建与自己业务相关的语义模型和地图。如果现有的行业语义模型能够在同行业之间共享，显然会极大地促进整个结构的发展。但是目前这方面的建设还是比较薄弱的。

知识库标准化与场景化相结合

在多种实践场景中，我们发现有些模式组合非常流畅，可以反映指标库与文档库的匹配，或者文档库与关系数据库的匹配等多种场景价值。但是，并非所有的模态组合都能找到相关的使用场景，因此需要进一步探索。假如能够更深入地分析和固化这些组合，例如建立一个“指标” 文件中的知识库，那么在效率、性能等方面都能有针对性地提高。与开放的随意搭配相比，这显然更容易实现。

尽管存在这些挑战，但它们也为未来的发展提供了方向。通过不断的探索和优化，我们可以逐步克服这些问题，促进技术的进一步发展。

嘉宾介绍

王传阳，枫清科技（Fabarta）合作伙伴，智能平台事业部总经理，曾任 IBM 认知计算研究院企业数字化转型R&D负责人拥有十余年的软件开发和软件工程经验，以及丰富的图形数据库和图形算法应用实践和客户交付经验。

本文来自微信微信官方账号 “InfoQ”（ID：infoqchina），作者：QCon，36氪经授权发布。

本文仅代表作者观点，版权归原创者所有，如需转载请在文中注明来源及作者名字。

免责声明：本文系转载编辑文章，仅作分享之用。如分享内容、图片侵犯到您的版权或非授权发布，请及时与我们联系进行审核处理或删除，您可以发送材料至邮箱：service@tojoy.com