基于RAPTOR实现高质量长上下文的RAG

RAGFlow (https://github.com/infiniflow/ragflow) 在本周发布了 0.6 版本，解决了自开源以来在易用性，稳定性上等等面临的诸多问题。从下个版本开始，RAGFlow 将开始向 RAG 深层次演进。当下 RAG 仍然处于一个搭建 PoC 容易，但实际应用难的局面，这其中根本原因在于 RAG 本身面临诸多挑战，主要包括：

1. 数据质量问题。RAGFlow 提供了开源的数据清洗和切分工具，有助于缓解这方面的问题，这方面 RAGFlow 的内置模型会继续迭代和进化。

2. 数据召回问题。主要是针对对话意图明确的场景下，需要提供多路召回方法方便用户提取到准确的上下文。目前RAGFlow 采用能够提供多路召回能力的数据库，可以缓解这方面的问题。

3. 寻找答案困难。在很多情况下，利用问题内容本身去检索，并不能真正找到答案的上下文，这两者之间存在语义空间的 GAP。

针对上面的最后一点，可以在多方面做工作，比如：

1. 引入外部知识图谱做查询改写，识别用户意图。

2. 引入 Agent 机制，让对话跟 LLM 产生更多交互和反省机制，从而提升回答质量。

3. 增加召回上下文，让 LLM 可以在更长的上下文窗口找到答案。

以上这些工作，都在 RAGFlow 未来的规划中。今天我们要讲的是在 RAGFlow 正在开发的版本上 (github main 分支，docker dev tag)，针对上面的第三点，提供了的一个实验性功能，就是本文标题所提到的基于 RAPTOR 实现长上下文 RAG。

RAPTOR 来自于今年初的一篇论文《Recursive Abstractive Processing for Tree Organized Retrieval》，它介绍了一种文档增强预处理的方法：对文档内容做层次化聚类，如图所示：

在原始文档被切分成 Chunks 之后，RAPTOR 基于这些 Chunks 进一步聚类，这个聚类是递归和层次化进行的：图中叶子节点（蓝色的区块）代表起始 Chunks，叶子基于 embedding 进行聚类总结成更高层次的信息整合，并递归执行，最终形成从原始叶子开始的“树”。聚类的结果是摘要内容，这些摘要可用 LLM 生成。采用聚类并生成摘要内容是因为它能够捕捉到文本的高层次和细节方面，这对于处理复杂的主题查询和问答任务中的多步推理更有价值。对于聚类后的内容，RAPTOR 论文提到了两种检索处理形式，如下图所示：

第一种是保持树结构，在查询时按照树结构，从根节点开始分层检索。这种检索实现比较复杂，而且对于多路召回并不友好。

第二种是把树状结构平铺，统一检索。这种实现比较简单，而且很方便跟多路召回融合在一起。

根据论文的实验结果，推荐采用第二种，因此 RAGFlow 也直接采用了平铺结构。具体实现中，RAGFlow 在基于Deepdoc 的文档解析预处理阶段完成后，可选择性的打开 RAPTOR 开关进行聚类并生成摘要，随后把这些生成的内容跟原始的 Chunking 结果合并，然后共同送到数据库，分别建立全文索引和向量索引，后续的操作跟常规的 RAG 没有区别。

需要指出的是，默认情况下，RAPTOR 开关并没有打开，需要手动打开开关：

这样做的原因是因为需要针对聚类结果生成摘要，这会消耗用户的 LLM Token，因此当用户更追求对于长上下文窗口内更好的上下文理解时，可选择打开开关。

下图是一个样例返回：图中的左边方框中内容，就是 LLM 根据聚类结果生成的信息摘要，RAGFlow将这些摘要也以可视化的方式呈现给用户。这些摘要与原始数据一起被用到 RAG 的检索过程中，从而可以获得更好的提示词信息。

为什么采用 RAPTOR 可以更好的理解上下文？这是因为在聚类后的树状结构中，上层节点具备对文本更加宏观的理解，对于一些需要多跳问答（Multi-Hop QA，意思是并不能直接从检索对应的上下文找到答案），以及需要跨Chunk 进行总结的场景非常友好。

RAPTOR 是 RAGFlow 改善检索痛点的一个尝试，后续的更新，会带来更多这方面的工作。欢迎持续关注RAGFlow！