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

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

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

内容亮点

• 面向复杂场景应用：聚焦企业级复杂知识交互，解决实际业务痛点

• 跨模态知识联邦：突破传统 RAG 模态限制，实现多模态数据融合

• 统一语义推理：提升知识关联和问答准确性，更智能

预告：将于 10 月 23 - 25 召开的 QCon 上海站设计了「AI 搜索」专题，想要深入了解 AI 搜索的前沿技术、应用场景和未来发展趋势，拓宽技术视野，从实践案例中获得启发，并在自己的业务场景中实现更智能的搜索体验的同学不要错过。

以下是演讲实录（经 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 框架能够很好地处理各种多模态数据。这带来了两个主要问题：

1. 多模态检索：例如，提供一段文字，能够检索出相关的图片、视频、表格等不同模态的内容。

2. 跨模态检索：相对简单一些，例如提供一段文字，能够检索出相关的图片，或者反过来，输入一张图片，能够检索出相关联的文字。

如何应对异构知识的挑战

在面对这样的挑战时，我在制作 PPT 时尝试咨询了 DeepSeek 的观点，他们给出的回答和思考过程在大方向上是比较靠谱的。对于结构离散的问题，他们提到可以动态地将相关段落进行合并，这是一个很好的指导思想，但具体如何实现合并并没有详细说明。此外，他们还提到可以使用图结构或知识图谱来连接相关段落，这似乎是一个比较接近解决方案的方向。对于模态多样性的问题，他们指出需要处理不同模态的数据，这虽然是一个正确的方向，但感觉并没有深入展开。他们提到图像应该如何处理，文本应该如何处理，并且强调在处理完成后需要综合多模态信息，结合两者进行综合生成。从大方向上看，这些思路是没有问题的。不过，在细节上，如果基于这样的内容继续追问，DeepSeek 可能会提供更多的详细信息。

基于融合知识库与统一语义层的 RAG 架构

核心组件 —— 融合知识库

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

从技术形态和产品形态来看，融合知识库是一个逻辑概念。底层的物理存储保持不变，例如文档仍然存储在向量数据库中，关系型数据库的数据源（如 MySQL 或 PostgreSQL）仍然保留在原处，只是它们的元数据被抽取出来，以逻辑视图的形式存储在融合知识库中。

从产品形态上来说，我们可以通过产品中的知识库模块向用户展示融合知识库的概念。例如，用户可以创建不同类型的单体知识库，如文档知识库、网页知识库、数据源知识库、指标知识库等，也可以创建一个融合知识库。创建融合知识库后，用户有两种选择：一是在空的融合知识库中新建文档库、指标库、图片库等，统一组织数据；二是将已有的文档库、指标库、数据源等导入融合知识库，以逻辑方式组织起来，形成新的融合知识库。此外，用户还可以在融合知识库中指定关注的领域模型，即关注的实体和关系。例如，在教育行业的融合知识库中，可以配置关注教师、试题、学生等与教学相关的实体及其关系，这为后续生成统一语义层做好铺垫。

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

统一知识图谱在使用时首先需要考虑的是如何生成，然后才是如何使用。生成统一知识图谱的过程可以通过一个图来理解。在图的最左边，我们有各种不同模态的数据，如文档、图片、视频和关系型数据库等。对于这些不同模态的数据，我们提取相应的元素放入知识图谱时，这些元素并不完全相同。

对于文档数据，我们使用了简化版的 Graph RAG（例如 Graph RAG Light）来提取文档中的实体和关系。通常不会提取全部内容，因为这会带来较高的成本和性能问题。我们会指定关注的实体和关系，这与前面构建融合知识库时的业务问题和领域模型密切相关。如果在构建知识库时明确了要解决的业务问题和关注的领域模型，那么在提取文档内容时就会更有针对性和高效性。

对于图片和视频，我们可以通过多模态大模型或客户已有的系统（这些系统在大模型时代之前就做过很多打标签等工作）来提取元信息，并将这些信息放入统一知识图谱中。对于关系型数据库，我们会提取各种元数据，例如数据表的用途、字段的业务含义等，并将这些信息也放入统一知识图谱中。在放入知识图谱的过程中，必然会涉及实体的合并以及关系的发现，最终形成一个完整统一的知识图谱。

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

有了这样一个知识图谱后，我们如何在框架中使用它呢？从用户问题出发，用户提出问题或表达任务需求时，我们会先在向量库中进行实体和关系的匹配，这其实是一种语义搜索。目的是理解用户问题中涉及的实体和关系类型。然后，我们会根据这些实体和关系，在统一知识图谱中进行 N 度扩展查询（例如二跳或三跳查询），以提取相关的子图。二跳或三跳查询的具体跳数可以根据实际需求配置，通常二跳查询已经足够，因为三跳查询可能会过于庞大。通过这种查询，我们可以关联出问题中相关的其他实体和关系，形成一个子图。

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

与 GraphRAG 的对比

在文本处理方面，我们会使用 GraphRAG 相关技术。大家可能会问，整个技术是否主要围绕 GraphRAG 展开，这种想法其实是有一定道理的。我们在文本处理上是站在巨人肩膀上的，但也做了一些改进。例如，通过指定实体和关系，减轻了 GraphRAG 盲目抽取的工作。这与其说是与 GraphRAG 的对比，不如说是对它的优化和改进。

在多模态知识方面，GraphRAG 目前主要支持针对文本（如单篇或多篇文档）抽取实体关系并构建图谱。从算力角度讲，通过预先指定领域模型、实体或关系，可以让抽取过程更加聚焦。在冷启动难度上，我们提到的架构中，各种图表、指标等元数据的准备工作确实需要花费一些时间来整理并放入统一图谱中。在技术复杂度方面，我们对 GraphRAG 进行了纵向简化，没有使用其完整的链路。同时，在横向工程化方面进行了扩展，例如加入了元数据提取、多模态图片和视频识别等功能，构建了一个包含多模态信息的知识图谱。

基于融合知识库与统一语义层的应用架构

重新梳理一下我们提到的架构，两个关键词依然是融合知识库 和 统一语义层，它们都在这个架构图中得到了体现。下面是融合知识库，其中包含了各种不同粒度、不同模态的数据；上面则是统一语义层，包括统一语义库和统一知识图谱，为上层的语义服务提供支持。通常，我们会通过企业知识中台或其他平台来管理底层的统一语义层和融合知识库，进行优化和更新等工作。企业知识中台还能承上启下，为上层应用提供应用构建的支持。因为我们需要将底层的知识和数据转化为应用价值并落地，最终还是要通过具体的应用来实现。所以，企业知识中台在这里提供构建应用的能力，比如智能体应用、工作流应用等各种形式的应用。这些应用结合统一语义层和融合知识库构建而成，最终交付给客户并落地为具体的智能体。

生产场景实践分享

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

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

具体场景是这样的：张三因流鼻涕和发热等症状来看病，医生将这些症状输入智能小助手，查询推荐的治疗方案。为此，我们采用了基于融合知识库与统一语义层的方案。融合知识库中包含了关系型数据库中的结构化数据（如患者信息、医嘱、住院记录）和电子病历中的文本数据。统一语义层则对医疗相关的概念进行了定义，例如“发热”是指体温在 37℃到 40℃之间，并描述了相关症状。

在统一知识图谱中，我们构建了一个以患者为中心的图结构，包括医嘱、住院记录、手术记录等实体，并从电子病历文本中抽取病症、治疗措施和效果等信息，将其关联到图中。例如，一个患者节点下会关联具体的病症（如支气管炎）、治疗措施（如药物名称）和治疗效果（如康复情况）。

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

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

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

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

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

未来演进方向展望

在分享的场景中，虽然许多案例是成功的，但在实践过程中也确实存在一些挑战。从正面来看，这些挑战可以被视为未来展望的方向；反过来，也可以说目前这些方面还存在不足。以下从四个方面进行分享。

统一语义层的动态更新

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

图像、视频数据的高效处理

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

行业语义模型与行业图谱的赋能

目前，企业通常需要依靠自身力量构建与自身业务相关的语义模型和图谱。如果同行业之间能够共享已有的行业语义模型，显然会对整个架构的发展起到很大的推动作用。然而，目前这方面的建设还相对薄弱。

融合知识库的标准化和场景化

在多个实践场景中，我们发现某些模态组合非常顺畅，能够体现很多场景价值，例如指标库与文档库的组合，或者文档库与关系型数据库的组合。然而，并非所有模态组合都能找到相关的应用场景，因此还需要进一步摸索。如果能够对这些组合进行更深入的分析并固化下来，例如建立一个“指标 + 文档”的知识库，那么在效率、性能等方面都可以进行有针对性的优化。这显然比开放式的自由组合更容易实现。

这些挑战虽然存在，但也为未来的发展提供了方向。通过不断探索和改进，我们可以逐步克服这些问题，推动技术的进一步发展。

嘉宾介绍

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

演讲征集

日前，由极客邦旗下 InfoQ 中国主办的 QCon 全球软件开发大会在北京圆满落幕。140 多场精彩演讲放送，直击行业痛点，为现场 1500+ 参会者传递可复制的经验与模式。10 月 23 - 25 日，QCon 上海站即将召开，如果你有相关案例想要分享，欢迎提交演讲申请。