MVP 聚技站｜Multi RAG：企业级 RAG 的重要架构

最新推荐文章于 2024-10-04 21:42:09 发布

dotNET跨平台

最新推荐文章于 2024-10-04 21:42:09 发布

阅读量99

点赞数

文章标签：架构

原文链接：https://mp.weixin.qq.com/s?__biz=MzAwNTMxMzg1MA==&mid=2654100002&idx=4&sn=6c582d4a8f40db2e66b35b84343ca0f3&chksm=81f5fba31fbb31b418986c5f87b9bcdcf1aa7cbfbfc624aaea577dfa33d5c034517c8f8f1e93&scene=126&sessionid=0

版权

点击蓝字 / 微软开发者MSDN

关注我们

作者：王豫翔 - 微软最有价值专家（MVP）

排版：Alan Wang

王豫翔

微软最有价值专家（MVP）

王豫翔，拥有20余年编程经验，Microsoft AI MVP，一直致力于分享 Azure AI 相关技术。曾在多个大型研讨会担任讲者，包含 TechEd、Tech Summit、Ignite China、Al Bootcamp 等。专注人工智能领域技术创新，尤其是自然语言对话方向的颠覆性机会。

在大模型的应用中，RAG 技术是一个值得持续讨论研究的话题。今天我们来聊聊在企业知识应用中关于联合 RAG 的实现。

大部分企业在构建知识库时，出于管理需要，不同业务部门都会各自维护自己的知识以及知识聊天机器人。但是在复杂的业务环境下，企业有强烈的愿望希望各部门维护的知识库可以复用和共享。要构建可以复用和共享的知识库是一个非常有挑战的任务，这个看似简单的工作会涉及到多种策略决策：我们不仅要定义 Retrieval 的关系，设计 Generation 推理方案，最后还要评估数据关系。

Multi RAG 遇到的第一个需要决策的工作是不同知识库的关系如何定义，他们之间的信息有矛盾冲突应该如何干预。

Master Slave Retrieval 主从召回模式

主从模式需要我们确定一个 Master Retrieval，当 Slave Retrieval 的内容和 Master Retrieval 有冲突时，我们要求以 Master Retrieval 的内容为基石，放弃 Slave Retrieval 的信息，为用户提供更权威的信息。

Master Slave Retrieval

场景

一家食品企业需要建立一个产品知识问答机器人，产品组为了让问答机器人的知识更丰富，希望把营养教育部门同事构建的基础营养知识库联合起来一起为用户提供在广度和深度上都非常强大的知识应用。但是产品组的同事认为，具体到一个特定产品时，该产品在某些营销成分的描述上可能会有自己的见解。因此，产品组将自己的产品知识设定为 Master Retrieval，一旦用户的提问在基础营养知识库和产品知识库之间有冲突，Master Slave 主从联合模式会以产品知识库为基石，直接放弃基础营养知识库的内容。

Cluster Retrieval 集群召回模式

在集群模式里，每一个召回通常是对等的，它们相互补充信息或者代表不同维度对知识的描述。集群模式中，当不同的 Retrieval 对知识有不同见解时，我们需要逐一输出每个 Retrieval 源对信息的描述，为用户提供更全面的信息。

Cluster Retrieval

场景1

医药企业在产品研发生产上市的过程中经常需要和药监局沟通并回复药监局的询问，为了提高相关医药企业工作人员回复药监局询问的效率，这家医药企业将药监局的相关政策法规精心构建了一个知识库，同时构建了一个药监局的沟通历史记录知识库，这样工作人员在回复药监局询问的时候就可以快速地得到高质量的回复建议。这时候我们可以将药监局法规知识库和沟通历史记录知识库作为集群 RAG 模式，机器人输出的内容可以帮助工作人员更全面地了解法规的描述以及过往基于相关法规的回复。

场景2

企业往往会构建内部流程政策知识库，人力资源、财务、法务、市场部、采购部、生产部等部门都会维护自己的知识库。在传统的 BERT 时代，由于技术限制，我们往往需要为每一个职能部门构建一个聊天机器人并基于部门独立的知识进行回答。大模型时代，企业必然期望以一个入口联合所有的知识库。这也是集群RAG 的典型场景，比如关于请假，人力资源部门的知识库中描述的是请假的流程，财务部门的知识库描述的是扣款的标注，具体不同业务部门的知识库可能还有自己的请假核准要求。因此在集群 RAG 模式下，机器人就可以全面地为用户提供企业关于请假方方面面的信息了。

Multi RAG 第二个需要决策的问题是推理由谁实现。

Distributed Generation 分布式推理模式

分布式推理要求每一个子应用独立完成一个完整的 RAG 过程，然后将 Generation 的结果汇聚到主应用再一次 Generation。

Distributed Generation

上图描述了一个典型的 Distributed Generation 架构：主应用将用户的 Query 分别提交给子应用1和子应用2，然后把子应用1和子应用2的推理结果和主应用的召回融合，作为新的召回提交给主应用的大模型进行推理。Distributed 模式下每一个应用都是一个黑盒，应用完整地管理自己的存储、检索和推理的所有计算资源。

Distributed Generation 架构的优势非常明显：

主应用的算力资源规划稳定，无需规划复杂的弹性资源管理。
开发相对简单，主应用会收到较多的 Retrieval，在窗口容量有限的情况下，需要使用 MapReduce 编程模型。
主应用无需关心子应用的 RAG 架构（我们在《一文道尽 RAG，为大模型提供你的私有知识》中曾经讨论过6种 RAG（Vector RAG、Search RAG、FAQ RAG、Graph RAG、DB RAG、Internet RAG）方案）。
子应用只返回推理结果，无需暴露自己的原始召回。

但是在有些情况下，Distributed Generation 架构的优势可能也是缺点：

大模型成本管理复杂，因为大模型的推理成本是需要付费的，主应用的请求成本被分摊到了子应用，在企业中可能会出现跨部门结算的复杂性。
由于推理被分布，需要编写复杂的逻辑检查子应用的服务稳定性。
由于子应用不返回详细的召回信息，因此主应用可能缺少更全局的信息。

Centralized Generation 集中式推理模式

集中式推理的思路非常简单，子应用仅实现 Retrieval 不负责推理，把 Retrieval 的结果提交给主应用，由主应用进行推理。

Centralized Generation

上图描述了一个典型的 Centralized Generation 架构，主应用将用户的 Query 分别提交给子应用1和子应用2，然后把子应用1和子应用2的召回结果和主应用的召回融合，作为新的召回提交给大模型进行推理。Centralized 模式下每一个应用仅负责召回，不负责推理。

Centralized Generation 架构的优势也非常明显：

存储、检索和推理的分开，使得企业可以将所有的资料（无论存储方案是向量库，文件、数据库等）通过分布式存储的方式解决高可用性。
每一个子应用不再负责推理，仅实现 Retrieval，因此召回性能将有明显的提升。
主应用负责推理，确保本次结果的推理能力保持一致，并且主应用更具有全局性。
推理的资源成本由主应用（发起者）承担，成本计算简单且更合理。
同样主应用无需关心不同应用的 RAG 架构，只需要获得子应用的 Retrieval 即可。

但是这些优点也是需要付出代价的：

因为大模型的推理窗口 Token 是有限的，主应用面对不同子应用返回的不同召回数据结构设计一个装载策略：尽可能把最有效的信息装到有限的 Token 中。

主应用面对各自召回数据结构

在实际的生产经验中，我们推荐大家按如下的思路规划你的集中式推理。

模型的选择

因为主应用面临的各自数据结构，因此集中式推理的模型要尽可能选择 Token 最大，推理能力最强的。真的，相信我。

优选次序

信息的装载应该优先考虑高质量信息密集的数据格式：

第一梯队	数据行、API JSON 和三元组：这三类数据是数据质量最高的，理论上他们应该只返回高精度的命中数据。
第二梯队	FAQ：无论是 BERT 还是 FAQ Chunk 召回的信息一般质量也很高，建议作为第二梯队考虑。
第三梯队	Vector 借助 Embedding 技术可以对内容进行相似的、跨语言和多模态的容错性检索。而 Search 在短语、实体关键字方面的优势是目前 Vector 还比较欠缺的。我们建议对 Search 做优先但苛刻的数据甄选，Vector 排在其次。
第四梯队	Internet 是外部数据，在企业知识库范围可以作为最后梯队考虑。

甄选范围

向量数据库和关系型数据库不一样，不同的向量库供应商因为他们的价值主张、架构算法不同对相同的向量集合返回的排序结果也不同，更因为 Embedding 的不同，相同资料在不同向量库的返回差异更大。

对不同向量库供应商表现的不同可以参考向量库专业评测专家 Dmitry Kan 在2021年10月2号的一篇博客《Not All Vector Databases Are Made Equal》。

所以，我们对不同 Vector Retrieval 不能简单粗暴地设定一个距离值进行甄选。虽然不同 Vector Retrieval 的距离值不能简单对比，但是在一定程度上我们是可以相信 Vector Retrieval 的 TopK（用于筛选与用户问题相似度最高的文本片段），因此我们可以设计一个雨露均沾的方式尽可能把不同 Vector Retrieval 的 TopK 轮流装载进来。

polling TopK Load

这种轮巡装载 TopK 的方式不一定是最好的方案，但是相对开发比较简单。在具体工程化过程中也可以根据 Retrieval Provider 的不同设计不同的 Polling 权重。

Multi RAG 第三个需要决策的问题是知识库的数据关系

我们要规划主应用和子应用在知识传递过程中的关系，以更好地进行知识管理。

引用：最简单的方式。主应用将 Query 提交给子应用等待召回返回就可以。这种数据关系中子应用的数据变更会使得主应用的数据一起变更。子应用的知识召回质量也会影响主应用最后的推理结果。
副本：主应用和子应用约定以当前的数据为副本，之后的子应用数据变更不影响主应用。但是推理或召回还是子应用实现。
导入：我们已经讨论过 Centralized Generation 的实现非常复杂，如果你打算使用一个低成本的集中推理方案，你可以采用导入的方式，将子应用的数据全部导入到主应用进行统一的检索召回。

最后我们汇总一下 Multi RAG 实施的方案：