社区来稿丨RAGFlow 正式进入 Agentic 时代
//
「具备反思能力,是 Agent 走向智能的必备基础。」
本文转自 RTE 开发者社区成员 InfiniFlow。InfiniFlow 的 RAGFlow 开源刚满 3 个月,已经获得了 Github 万星。
本文除了介绍 RAGFlow 在 Agentic RAG 上的思路和解决方案,作者还列举了若干最先有可能落地的场景,例如客服中心、HR 候选人沟通对话、翻译等。
本月,RTE 开发者社区将举办一次面向开发者的小规模 RTE Meetup(线上+线下),包括 InfiniFlow、Fish Audio 在内的诸多 AI Infra 开发者也会参与分享。我们期待更多相关领域开发者加入 meetup,分享自己的项目和技术思考,有意分享者请联系我们(微信 bob_fu)。
RAGFlow 正式进入 Agentic 时代
作者:InfiniFlow
-
Embedding 是针对整块文本的处理,对于一个特定的问题,它无法区分文字中特定的实体/关系/事件等权重明显需要提高的 Token,这样导致 Embedding 的有效信息密度有限,整体召回精度不高。
-
Embedding 无法实现精确检索。例如如果用户询问“2024年3月我们公司财务计划包含哪些组合”,那么很可能得到的结果是其他时间段的数据,或者得到运营计划,营销管理等其他类型的数据。
-
对 Embedding 模型很敏感,针对通用领域训练的 Embedding 模型在垂直场景可能表现不佳。
-
对如何数据分块很敏感,输入数据的解析、分块和转换方式不同,导致的搜索返回结果也会大不同。而依托于 LLMOps 工具的体系,对于数据分块的逻辑往往简单粗暴,忽视了数据本身的语义和组织。
-
缺乏用户意图识别。用户的提问可能并没有明确的意图,因此即便解决了前述的召回精度问题,在意图不明的情况下,也没有办法用相似度来找到答案。
-
无法针对复杂提问进行回答,例如多跳问答。
-
RAG 2.0 是以搜索为中心的端到端系统,它将整个 RAG 按照搜索的典型流程划分为若干阶段:包含数据的信息抽取、文档预处理、构建索引以及检索。
-
RAG 2.0 是典型的 AI Infra,它无法用类似的 LLMOps 工具来编排。因为以上环节之间相互耦合,接口远没有到统一API和数据格式的地步,并且环节之间还存在循环依赖。例如对问题进行查询重写,是解决多跳问答、引入用户意图识别必不可少的环节。查询重写和获得答案,是一个反复检索和重写的过程。
-
需要一个更全面和强大的数据库,来提供更多的召回手段,这是由于为解决 RAG 1.0 中召回精度不高的痛点,需要采用多种方法混合搜索。
-
数据库只能涵盖 RAG 2.0 中的数据检索和召回环节,还需要站在整个 RAG 的链路上,针对各环节进行优化,这包括:需要有单独的数据抽取和清洗模块,来针对用户的数据,进行切分。切分的粒度,需要跟最终搜索系统返回的结果进行迭代。数据抽取模块,需要考虑到用户的各种不同格式,包含复杂文档例如表格处理和图文等,因此它必须依托于若干模型才能完成任务。高质量的数据抽取模块,是保证高质量搜索的前置条件。
-
抽取出的数据,在送到数据库索引之前,还可能需要若干预处理步骤,包括知识图谱构建,文档聚类,以及针对垂直领域的 Embedding 模型微调等。这些工作,本质上是为了辅助在检索阶段提供更多的依据,从而让检索更加精准。这个步骤不可或缺,它是针对用户的复杂提问,例如多跳问答,意图不确定,以及垂直问答等情况下的必要手段。通过把文档中包含的内部知识以多种方式组织,才能确保在召回结果包含所需要的答案。
-
检索阶段分为粗筛和精排。精排通常放在数据库外进行,因为它需要不同的重排序模型。除此之外,还需要对用户的查询不断改写,根据模型识别出的用户意图不断改写查询,然后检索直至找到满意的答案。这些阶段,可以说每个环节都是围绕模型来工作的。它们联合数据库一起,共同保证最终问答的效果。