为了提升 RAG 效果做的一些尝试

[Valdanitooooo]

为了提升 RAG 效果，尝试了很多方法和工具，这里记录一些经验

从构建知识库的角度进行优化

GraphRAG

一些开源工具

https://github.com/microsoft/graphrag
https://github.com/infiniflow/ragflow
https://github.com/Cinnamon/kotaemon

https://github.com/eosphoros-ai/DB-GPT

ragflow、kotaemon 也是用的 microsoft/graphrag

DB-GPT是另一套架构，接入Tugraph

使用体验都不是很好，都是玩具，效果还不如传统RAG

自研工具

我自己也设计并了一套知识抽取和检索的工具，用的 dgraph 作为存储

参考的博客是 https://dgraph.io/blog/post/20240724_rag_on_graph/
最终效果也不好哈哈 😅 ，就不开源代码了，只讲下我的思路

1. 设计通用建模方法
   适应任意文档，不再需要人工建模
   
   实体只有两个属性，Entity0.content 就是实体的全部内容了，Entity0.embedding 存的就是从 Entity0.content 转成的向量

实体只有一种关系类型 Entity0.relationship
真正的关系类型我存到了关系的属性里，利用 dgraph的特性，关系属性可以是任意的，不被建模约束 https://dgraph.io/docs/query-language/facets/

当我查询时，再处理查询结果，把关系属性拿出来作为关系名字替换掉 Entity0.relationship

2. 基于 LLM 开发实体关系抽取工具
   抽取 RDF 三元组，然后导入到图数据库中
   使用 dgraph 的 dql 查询语句进行检索
   过程如下：
   

3. 解决实体融合问题, 相同的实体内容自动融合为一个实体

将实体内容(Entity0.content)转为 16 进制字符串作为 xid，导入数据 uid 与 xid 映射，也是利用 dgraph 的特性 https://dgraph.io/docs/howto/importdata/live-loader/#xidmap-flag

dgraph live --files ./rdf --xidmap ./xidmap --alpha 10.**.**.**:9680

4. 用 dql 检索

我先让 LLM 分析用户意图，提取关键字，然后将关键字转为向量，传入我的查询模板，所以关键字的数量不固定，我设置不超过 5 个，查询速度还是非常快的

这个 dql 就是先通过向量相似度查找到一些实体，再扩展这些实体，查询一跳、两跳的有关联的实体

给 LLM 之前，我要转换一下格式，就是上文提到的用关系属性替换关系，json 的结构也做一些优化，最终还是类似三元组的格式给到 LLM

KAG

https://github.com/OpenSPG/KAG

抽取效果不行，效果还不如传统RAG

从文档解析的角度进行优化

• https://github.com/adithya-s-k/omniparse 支持对多种文档格式的解析，效果差

• https://github.com/bhavnicksm/chonkie 主要做文档切片的，效果差

• https://github.com/DS4SD/docling 可以把 pdf 转为 markdown，效果还凑合

  贴一下使用 docling 的代码

   from docling.backend.pypdfium2_backend import PyPdfiumDocumentBackend
   from docling.datamodel.base_models import InputFormat
   from docling.datamodel.document import ConversionResult
   from docling.datamodel.pipeline_options import PdfPipelineOptions, RapidOcrOptions
   from docling.document_converter import (
       DocumentConverter,
       PdfFormatOption,
       WordFormatOption,
   )
   from docling.pipeline.simple_pipeline import SimplePipeline
   
   ocr_options = RapidOcrOptions()
   
   pipeline_options = PdfPipelineOptions()
   pipeline_options.do_ocr = True
   pipeline_options.do_table_structure = True
   pipeline_options.table_structure_options.do_cell_matching = True
   pipeline_options.ocr_options = ocr_options
   
   doc_converter = (
       DocumentConverter(
           allowed_formats=[
               InputFormat.PDF,
               InputFormat.IMAGE,
               InputFormat.DOCX,
               InputFormat.HTML,
               InputFormat.PPTX,
           ],
           format_options={
               InputFormat.PDF: PdfFormatOption(
                   pipeline_options=pipeline_options,
                   backend=PyPdfiumDocumentBackend
               ),
               InputFormat.DOCX: WordFormatOption(
                   pipeline_cls=SimplePipeline
               ),
           },
       )
   )
   if __name__ == '__main__':
       source = "xx.pdf"
       conv_res: ConversionResult = doc_converter.convert(source)
       print(conv_res.document.export_to_markdown())
  

• https://github.com/getomni-ai/zerox 挺不错的，用过的效果最好了
  我使用Qwen2-VL-7B-Instruct模型进行识别

下面是使用 zerox 将 pdf 批量转为 markdown 的代码

https://github.com/Valdanitooooo/code_snippets/blob/main/pdf2md/pdf2md.py

总结

我目前的方案是

1. 先用 zerox 将 pdf 转成 markdown
2. 再把这些 markdown 上传到 RAGflow 里进行解析
   RAG问答效果提升了一些，尤其一些 pdf 扫描件，效果提升明显

至于 GraphRAG 和 KAG 之类的，持续关注吧，至少在我的业务中，还不具备上生产的条件

[Valdanitooooo]

又看到一个 https://github.com/CatchTheTornado/pdf-extract-api 下周试试

[Valdanitooooo]

待测试：

• https://github.com/microsoft/markitdown
• https://github.com/opendatalab/MinerU