微软最近新出了个 graphrag，号称其能提取有意义的结构化数据，不过遗憾的是默认情况下其只能读取txt或者csv数据。这次就让我们用(我写的)外部库pdfdeal将PDF转换为带格式化的txt，再结合更便宜的deepseek进行构建。

安装并配置相应的库

为了避免不必要的麻烦，请使用虚拟环境：

• miniconda3：conda的最小化安装版本，当然你也可以直接使用Anaconda。

• uv：一个非常快的包安装程序和解析器，使用Rust构建。

• 或者我写的调用uv以及conda，达成多版本Python虚拟uv环境的脚本uvv。

#condaconda create -n rag python=3.12conda activate ragpip install --upgrade pdfdeal graphrag

# uvuv venvsource .venv/bin/activate # For Linuxsource .venv/Scripts/activate # For Windowsuv pip install --upgrade graphrag pdfdeal

# uvvuvv create -n rag -p 3.12uvv activate raguvv install graphrag pdfdeal

随后找一个你喜欢的文件夹，准备开始构建吧。

Step1:转换PDF

由于微软这玩意儿只吃txt或者csv，首先我们需要将其转换txt才行。

一般而言有几种转换的选择，效果从最差到最好有：

• 直接提取纯文本部分转存(效果最差)

• 提取纯文本部分+图片进行OCR，也就是我写的pdfdeal

• 干的事情，不过这种方式遇到表格和公式就抓瞎

• 新型的（识别公式&格式的）OCR工具，一些代表：

• 闭源(mathpix，Doc2X，simpletex)

• 开源(nougat，marker)

此处选择了效果最好的Doc2X作为转换的工具(甚至每天免费500页，属于是做慈善了)。首先得获得个人的API密匙，进入网站后通过点击身份信息，复制你的身份令牌作为api即可。

建议使用我的邀请码4AREZ6(手动滑稽)

随后新建两个文件夹，用于存储处理前的PDF以及处理后的txt文件：

mkdir ./pdfmkdir -p ./ragtest/input

随后把要处理的pdf丢到pdf文件夹中，此处我选择的是巨硬的graphrag论文本身以及随机选了一个我感觉很重要的参考文献。

使用pdfdeal的CLI工具doc2x进行批处理，其中记得加上长标示--graphrag以启用对graphrag的特殊适配：

doc2x -k "Your Key Here" -o ./ragtest/input -p --graphrag ./pdf

等待其处理完成，就将所有的PDF文件转换为带格式(指md语法)的txt文档了：

Step2:构建知识图谱(DeepSeek)

首先生成一下graphrag的配置文件，让我们对其进行修改一下使用DeepSeek：

python -m graphrag.index --init --root ./ragtest

如果你只打算使用默认的OpenAI的LLM以及嵌入模型，你仅需要修改.env中的Key就好了。 剧透提醒：graphrag的token消耗即为恐怖，不建议使用默认的gpt-4进行构建

到settings.yaml文件，这就是我们需要修改的文件了。

我们需要修改两个部分，第一个部分为llm，由于deepseek并不支持直接输出JSON，记得修改model_supports_json为false：

llm:  api_key: Your DeepSeek Key  type: openai_chat # or azure_openai_chat  model: deepseek-chat  model_supports_json: false # recommended if this is available for your model.  max_tokens: 4000  api_base: https://api.deepseek.com/v1

随后修改嵌入部分，此处我直接使用的是OpenAI的text-embedding-3-small。注意，由于llm中我们修改了api_base的值，嵌入中的api_base也需要相应修改，你可以改为任何兼容OpenAI格式的嵌入模型，例如智谱的嵌入模型：

embeddings:  ## parallelization: override the global parallelization settings for embeddings  async_mode: threaded # or asyncio  llm:    api_key: ${GRAPHRAG_API_KEY}    type: openai_embedding # or azure_openai_embedding    model: text-embedding-3-small    api_base: https://api.openai.com/v1

python -m graphrag.index --root ./ragtest

随后就可以对graphrag发起提问了，注意其分为global和local两种模式：

python -m graphrag.query \--root ./ragtest \--method global \//或者使用local模式，换成：--method local \"Q"

总结

由于效果部分实在是太长了，总结就放前面了。

graphrag有效果吗？有，尤其是在有关联性的问题上效果非常明显，与Doc2X配合可以相当好的提取文档中的内容。

问题就出在：这是一个token杀手，不管是构建还是在回答阶段。

统计这两个PDF文件的内容，如果直接放上下文中的话，加起来会消耗52525token，而以下是构建阶段消耗的token：

2024-07-14,deepseek-chat,graphrag,sk-b30da***********************283e,1334747,344702,1148

消耗了133万输入token，34万输出token。

虽然使用的Deepseek，仅花费了$0.28(¥2.02)，但是如果使用OpenAI的模型，即使是较为便宜的gpt-4o也需要$11.85(¥85.92)才能完成构建。

甚至于回答一个问题简单的问题，都会花费输入85293token，输出1848token。不过好在还有deepseek这个性能足够，并且非常便宜的异类来以支撑使用。

同时，由于消耗的token相当恐怖，实际的输出速度也很慢。因此现阶段，graphrag恐怕不像是某些地方所说的RAG解决方案，仅仅作为这个方向是可行的一个demo。

效果

从这儿往下就是实际的效果演示啦。

用的问题为：

讨论使用 LLM 生成图索引和回答用户查询的局限性。在 Graph RAG 方法的未来迭代中如何解决这些限制？

graphrag(使用DeepSeek-Chat进行构建)，global模式

deepseek-chat

gpt-4o

graphrag(使用DeepSeek-Chat进行构建)，local模式

deepseek-chat

gpt-4o

Dify

作为对比，我加入了Dify的结果。注意，此处的Dify是按照这个流程配置的，使用带Rerank模型的完全体RAG流程。其中提示词等直接使用的默认模板，并未改动。

deepseek-chat

gpt-4o