构建更精准的检索系统：RAGFlow对GraphRAG与标签库的强化支持

1.GraphRAG 增强与重构

RAGFlow 在 2024 年 8 月的 0.9 版本引入了 GraphRAG，之后的 GraphRAG 模块一直没有再更新。而从那时起至今，GraphRAG 本身的技术也在不断演进，主要围绕轻量化等方面进行了诸多工作，例如香港科大的 LightRAG，MiniRAG，Circlemind的 fast-graphrag 等等。在 0.16.0 版本中，RAGFlow 对 GraphRAG 模块进行了重构，并进行了功能增强，具体如下： 数据写入：

• 过去的 GraphRAG 为每个文档构建一个 Knowledge Graph，而 0.16.0 版本则为每一个知识库构建一个 Knowlege Graph，单个文档可选择是否进行 Graph 实体抽取，抽取的 Graph 实体会动态更新到知识图谱当中，删除亦然。
• 实体抽取可以有两种模式的选择，Light/Gerneral。Light 采用了 LightRAG 的实体抽取 prompt，General 则采用了微软 GraphRAG 的 prompt，后者更长，耗费的 token 更多。抽取效果跟大模型和用户的数据相关，用户可以选择性对比。
• 实体去重 （[Entity Resolution]变成可选项。在 0.9 版本引入的 GraphRAG 中，实体去重是内置的，在某些情况下，它确实提高了知识图谱的质量，但也增加了 token 消耗。在 GraphRAG 中，自动构造的知识图谱，通常无法达到数据可视化的要求，因此一般是作为辅助召回存在，所以把实体去重作为可选项，可以让用户来在知识图谱的质量和成本之间作出选择。
• 社区摘要变成可选项。在微软的标准 GraphRAG 中， 社区摘要是一个必选项，它提升了辅助召回的问答质量，但也是 token 消耗的重要来源之一，因此变成可选项，可以让用户在效果和成本中作出选择。

GraphRAG 查询： 对查询进行优化，查询时可以勾选是否需要提取知识图谱相关信息。

如果勾选了该选项，在查询时的处理步骤如下：

1. 利用大模型对问题进行分析，提取相关的实体 1 和实体类型。
2. 用相关的实体类型在知识图谱中做 PageRank 计算（随机游走），得到 PageRank 值前 N 的实体及其描述。
3. 通过实体 1 的向量相似度召回相似实体及其描述，以及 N-hop 的实体关系。
4. 通过原问题用向量相似度召回实体关系及其描述。
5. 对实体和实体关系进行排序。排序理论支撑贝叶斯，P(E|Q) => P(E) * P(Q|E)，实体或关系本身的 PageRank 值乘以实体或关系和 Query/Question 的相似度。
6. 用相关的实体召回 Top 1 社区摘要。
7. 将实体和关系描述以及社区摘要报告作为 prompt 扔给大模型。

0.16 版本重构和增强后的 GraphRAG，给予了用户更多的选项，在效果和成本之间作出 Trade off，同时在查询时引入更多信息，利用知识图谱增强查询来做到确保更高的召回。

2.支持标签库

众所周知，RAG 的核心门槛就是各种检索和召回的质量。从 0.15.0 版本起 RAGFlow 提供了系列工具用来帮助改进检索质量，例如分级知识库、Contextual Retrieval（利用 LLM 对文档打标签） 等。在 0.16.0 版本中，引入的一个重要功能就是标签库，它同样是用来改进检索质量的有效工具。举例如下： 场景 1：2000 个手机附件（贴膜、耳机、手机壳）的文档 chunk，20 个关于手机的 chunk。搜华为手机的信息，用现在的手段，手机信息大概率无法被搜到。 场景 2：政府某机构内部文献，从省到市县镇乡都有关于某一政策的不同版本的文件。各种子级别的文件远远多于省市级别单位的文档，当查询省市级别的文档时，如：“浙江省关于 xx 的管理办法具体有哪些？” 用现在的手段大概率难以将省市的文档内容排在其他的占多数的文档内容的前面（所有浙江省的其他子集机构文档都带有浙江省的字样）。 采用标签库可以解决以上问题： 首先上传标签库文件：

标签库文件是用户对业务数据的定义，可以看作是领域知识，标签库在 RAGFlow 中也作为知识库存在，解析的时候选择 “Tag” 作为 Chunk 手段。标签库文件的格式样例如下所示，其中 Description/Question 代表用户的业务知识数据，Category 代表用户对该数据定义的标签，用逗号分隔。标签库文件实际上是引入人工定义的垂直场景知识来对大模型自动提取文档关键词的补充。

标签库文件上传完成后，可以管理标签： 下图是标签可视化：

下图是标签信息，可以允许用户进一步修改：

标签库建立好之后，业务使用方就可以利用它对其他知识库进行自动标签操作：其他知识库的文档，每个 Chunk 都可以根据标签库内容，来自动计算是否该 Chunk 可以包含若干用户自定义标签。具体算法是利用 Chunk 和标签库文件的 Description/Question 字段文本的相似度，如果该相似度达到阈值，那么该 Chunk 就被打上 Tag 字段的各标签：

在查询时，Query 也会被打上不同权重的标签，计算方法跟上述类似，这样在排序阶段，包含相关标签的 Chunk 就会得到加权。

标签库是解决查询和答案语义鸿沟的重要措施。对于 RAG 来说，语义鸿沟总是搜索阶段面临重大挑战之一。可以利用大模型来弥补语义鸿沟，在 RAGFlow 中，相应的措施包含：RAPTOR，GraphRAG，Contextual Retrieval 等；同时，也不应忽略来自人工的领域知识，这些知识并不能被及时为大模型所学习到，因此通过 RAGFlow 的配套措施（目前包含分级知识库，以及本次发布的标签库功能），可以让它们也可以被有效体现到原始数据中，从而改进检索质量。 需要说明的是，标签库的功能，目前采用 [Infinity 版本]的 RAGFlow 暂时还无法运行，这是因为标签库功能会用到 Elasticsearch 的一些独有高级特性，这些特性将在 Infinity 的下个 Release 中包含，因此希望采用 Infinity 作为 RAGFlow 后端的朋友可以等 RAGFlow 发布到 0.17.0 的时候再来体验。 RAGFlow 0.16.0 版本的其他更新还包含：

3.支持自定义 Chunk 的元数据

这是社区用户提出的 Feature Request，用户添加的 Chunk 元信息会随着 Chunk 一起被加到 prompt 中从而可以回答相关问题，例如：

4.Agent / 工作流支持循环

Agent / 工作流的功能支持，基本跟上了同类其他项目的节奏。也欢迎广大用户提出这方面的 Feature Request。同时，v0.16 还给 Agent 增加了 Research 报告生成器的模板。

5.DeepDoc支持用 GPU 加速

开源版本的 DeepDoc 是很小的模型，采用 Onnx 提供推理服务。由于模型较小，因此过去的 DeepDoc 在 GPU 上加速不明显，且由于 OnnxRuntime 的一些 GPU 显存问题，过去 DeepDoc 只运行在 CPU 模式。 随着 0.15.0 对 DeepDoc 做了升级，内置的文档布局模型尺寸相比过去有了较大尺寸的增长，在整个文档解析过程中所占的比例也大幅提升。因此 0.16.0 版本开启了利用 GPU 对 DeepDoc 的加速，采用 GPU 后文档布局识别的速度大大提升。