RAGFlow v0.15.0：2024 年最后一个发行版

2024 年 RAGFlow 的最后一个版本 v0.15.0 发布，主要带来如下更新：

Agent 改进

在这个版本中，Agent 推出了多项改进，除了新增更多的 API 之外，还推出了单步调试和导入导出能力。从 v0.13.0 开始，RAGFlow 的 Agent 开始进行了重构，使之在易用性上逐渐接近大众使用习惯。而单步调试，则补上了最后一环。

单步调试的能力展示如下图所示，Agent 链路上的算子可以单独执行，根据输出信息来帮助用户调试。

Agent 导入导出，为 Agent 复用提供了基础。当前，在 LLM 应用生态中，Agent/工作流已经有很多框架可以选择，这类系统，本质上是一个提供给非程序员的 IDE ，因此，针对业务场景编排特定的 Agent/工作流，并不是非常轻松的事情，我们可以把编排好的 Agent 类比为 App，而发布和执行 Agent 的框架可以类比为 App Store。所以从长远来看，各框架的 Agent ，应该会逐步走向接口兼容和允许互操作。另一方面，当前的 Agent 产品形态以工作流为主，但今年已经有很多工作，开始把 Reasoning 能力体现到 Agent 框架中。到明年，这方面的工作会出现更多，特别是涉及多 Agent 的场景。LangGraph 已经发布了 LLM Agent 互操作协议，RAGFlow 在后续版本中也将会兼容该协议。

Agent 作为跟 RAG 交互密切的生态组成，RAGFlow 站在用户使用方便的角度出发，需要提供这个特性。但 RAGFlow 本身更加专注于 RAG 本身，因此 RAGFlow 既欢迎用户采用自己的 Agent ，也欢迎用户采用其他 Agent 和工作流类框架访问 RAGFlow。

DeepDoc 升级

文档布局模型是 DeepDoc 的入口模型。DeepDoc 在 4月1日公开后，一直没有进行升级。不断有社区的小伙伴建议我们提供统一接口，让 DeepDoc 一律输出 Markdown 文件格式，从而做到模型和后续处理之间的松耦合。这类建议，也因为社区出现了一些优秀的开源项目如 MinerU ，变得更加强烈。我们一直没有进行这方面的工作，主要是因为 Markdown 格式，并不能完全表达多模态文档转化后的结果。例如对于表格数据来说，Markdown无法表达复杂的嵌套表格。同样，对于未来的流程图、饼图等数据，直接输出 Json 会更加方便。但另一方面，DeepDoc 自身的开源模型，也有升级的必要。本次升级，主要是文档布局模型的升级，它同样采用 YOLO 训练，因此在效率上跟之前并无变化，但对于文档布局识别的精确度，有了明显提升。

检索增强

即使 DeepDoc 工作非常完美，也同样无法完全解决召回的命中率问题。对于文本数据来说，除了混合搜索之外，命中率还受到2个因素的影响：

其一是语义鸿沟。我们知道，GraphRAG 和 RAPTOR 可以用来解决语义鸿沟的问题，但这些处理是重量级的，而且消耗较多的 Token。有一类相对轻量级的做法，就是 Claude 在今年 9月推出的 Contextual Retrieval，它借助于 LLM 给每个 Text Chunk 生成一些辅助信息，用来帮助解决召回不足的问题。例如文本中如果包含疾病治疗方案，而治疗方案却没有疾病描述，那么检索时，可能就无法命中这段文本。LLM 可以很方便的给这段文字添加相应的补充信息，方便最终召回。这种 Contextual Retrieval，在 v0.13.0 版本的 RAGFlow ，已经提供类似能力，在知识库配置页面，如果选择了自动提取关键词，就可以打开这个开关。

其二是大规模数据。数据的增多对于命中率是很大的伤害，v0.15.0 版本推出了分级知识库功能，针对海量数据，用户如果可以区分数据的质量高低，那么通过分级知识库，可以让质量高的数据排在前边。具体在使用的时候，打开下图的“Page rank”开关，就可以启用分级知识库排序。本功能实质上，就是允许用户自定义知识库得分权重：

Task Executor 改进

Task Executor 一直是 RAGFlow 自开源以来被一直诟病的地方。从 v0.14.0 版本开始，Task Executor 在健壮性上进行了一系列改进，在 v0.15.0 版本，Task Executor 针对诸如 GraphRAG/RAPTOR 这样的重型任务进行了改进。这些任务都需要消耗大量的 Token，如果在文档解析过程中发生了异常，任务就会中断从而导致之前消耗 Token 解析的结果都会丢失，这对于使用是非常不好的体验。在 v0.15.0 版本中，通过消耗 LLM 进行的文档解析和预处理任务，即使发生了异常中断，在任务继续执行后，过去已经解析完成的结果依然可以复用，从而避免浪费。

Infinity 改进

Infinity 数据库在 v0.14.0 被引入 RAGFlow 作为备选，在 v0.15.0 中，修复了大量采用 Infinity本身导致的错误，这既有 Infinity 本身的 bug ，也有 RAGFlow 封装所导致的问题。此外，Infinity 针对RAGFlow 生成的查询，也进行了性能优化：RAGFlow 在获取一个用户查询后，并不是简单地将它发给后端搜索引擎，而是引入一系列操作，包含：

1. 分词后删除无意义词

2. 针对分词后的结果为每个词生成不同的权重信息，它们会影响最终的得分

3. 针对分词后的结果，进一步产生以分词为基础的组合，将它们生成短语查询，用来辅助召回。这些查询，连同第二步的分词结果，共同被送到搜索引擎查询。

举例来说，一个对话“在原文中，教师应该在什么时候提问？”，它产生的查询可能会有如下的结果：

((原文中 OR "原文" OR ("原文"~2)^0.5)^1.0) OR ((教师)^0.9991 (提问)^0.000541 (应该)^0.000368 ("教师 应该 提问"~4)^1.5)((企业)^0.550884 (格局)^0.252471 (文章)^0.195081 (新发)^0.000607 (提到)^0.000261 (展)^0.000262 (适应)^0.000230 (应该)^0.000203 ("文章 提到 企业 应该 适应 新发 展 格局"~4)^1.5)

因此可以看到，RAGFlow 针对任何提问，都会生成大量的短语查询。Infinity 在过去的全文搜索实现中，只对普通的查询实现了查询动态剪枝优化，对于短语查询，以及包含短语查询的组合查询，均没有做相应处理。在 Infinity 的最新 0.5 版本中，实现了对这些组合查询的优化，这使得 RAGFlow 生成的整体查询性能，提升了 3-5倍。

写在最后

RAGFlow v0.15.0 是 2024 年度的最后一个 release，从 RAGFlow 开源以来，一直处于快速迭代中，因此在过去的代码中遗留了不少技术债。最近的几个版本，我们花了大量时间进行代码重构，bug fix，这是 RAGFlow 迈向企业级生产环境的重要一步。