本文编译自Geert Baeke的Token consumption in Microsoft’s Graph RAG – baeke.info，https://blog.baeke.info/2024/07/11/token-consumption-in-microsofts-graph-rag/ 

最近微软开源GraphRAG后，业界反响热烈。重磅 - 微软官宣正式在GitHub开源GraphRAG 。做一个GraphRAG到底能有多贵呢？本质上来说要基于场景，数据量以及KG构建的细粒度和算法等综合因素。小的项目十几万也可以做。规模化的话就得基于这些因素综合评估。

我们将看一下用于查询知识图谱的token令牌消耗，无论是用于本地查询还是全局查询。

注意：此测试是在 gpt-4o 上执行的。最近OpenAI 发布了 gpt-4o-mini。使用 gpt-4o-mini 进行的初始测试显示，索引创建和查询效果良好，成本显著降低。您可以在下面的设置中用 gpt-4o-mini 替换 gpt-4o。

建立Langfuse日志记录

为了方便查看对LLM的调用，我使用了以下组件：

• LiteLLM：配置为代理；我们配置 Graph RAG 使用该代理，而不是直接与 OpenAI 或 Azure OpenAI 对话；请查看 https://www.litellm.ai/

• Langfuse：一种可以用来跟踪 LLM 调用的 LLM 工程平台；请查看 https://langfuse.com/

安装 LiteLLM，请按照此处的说明进行操作：https://docs.litellm.ai/docs/proxy/quick_start。我为 LiteLLM 创建了以下 config.yaml 文件：

在启动代理之前，请设置以下环境变量：

你可以从 OpenAI 和 Langfuse 门户获取这些值。确保还使用 pip install langfuse 安装 Langfuse。

接下来，我们可以使用 litellm --config config.yaml --debug 启动代理。

要让 GraphRAG 与代理一起工作，请打开 GraphRAG 的 settings.yaml 并在 llm settings 下设置以下值：

LiteLLM正在监听该端口上传入的OpenAI请求。

运行本地查询

当地查询首先通过相似性搜索创建您的问题的嵌入，并在知识图中找到相关实体。这些嵌入在索引期间存储在 LanceDB 中。基本上，相似性搜索的结果被用作进入图的入口点。

这就是为什么您需要将嵌入模型添加到 LiteLLM 的 config.yaml 中的原因。全局查询不需要这个设置。

在 LanceDB 中找到相似实体后，它们被放入提示中，以回答您的原始问题以及相关实体。

一个本地查询可通过单个 LLM 调用处理。让我们来看一下追踪：

Trace from local query

查询大约用了10秒和11500个令牌。系统提示开始如下：

First part of local query system prompt本地查询系统提示的第一部分

它实际操作的数据（称为数据表）在提示中进一步列出。您可以在下面找到一些数据点：

Entity about Winston Smith, a character in the book 1984 (just a part of the text)关于《1984年》一书中的角色温斯顿·史密斯的实体。

Entity for O’Brien, a character he interacts with 奥布莱恩形象的存在，他与之互动。

该提示还包含了提到这些实体的书籍来源。例如：

Relevant sources相关来源

对此提示的回应类似于以下回应：

响应中包含对实体和源的引用及其 ID。请注意，您可以影响检索到的实体数和消耗的标记数目。在 Graph RAG 的 settings.yaml 中，我修改了本地搜索设置如下：

追踪结果很明显：令牌消耗更少，延迟也更低。

Lower token cost更低的令牌成本

当然，答案会缺少一些细节。您将不得不尝试这些数值，以查看在您的情况下效果最好的是什么。

Global Queries 全局查询

全局查询非常适合关于数据集的广泛问题。例如：“1984年的主题是什么？”全局查询不是单个LLM调用，比本地查询更昂贵。

让我们看看全局查询的追踪。每个迹象都是一个LLM调用来回答全局查询：

列表中的最后一个是开始的地方：

众多调用中的第一个，以回答全局问题

正如您可能已经注意到的那样，上面的调用并不直接返回给用户。系统提示不包含图中的实体，而是社区报告。社区报告是在索引过程中创建的。首先，使用Leiden算法检测社区，然后进行总结。数据集中可能有很多社区和摘要。

这个第一个跟踪要求LLM回答这个问题：“1984年的主题是什么？”给一个社区报告的第一个集合并生成中间答案。这些中间答案会保存直到最后一个调用，用来根据所有中间答案回答问题。完全有可能使用与查询不相关的社区报告。

以下是最后一次调用：

根据中间答案回答问题。

我这里没有展示整个提示。上面，您看到被提供给最终提示的数据：社区报告中的中间答案。然后得出最终答案：

Final answer to the global query全局问题的最终答案

下面是再次列出的所有调用清单：

All calls to answer a global query回答全局查询的所有调用

总的来说，在默认设置的基础上，进行了 12 次 LLM 调用，消耗了大约 150K 个令牌。无法从此列表中计算总延迟，因为调用是并行进行的。总成本约为 80 美分。

可以通过调整 settings.yaml 中的默认参数来减少调用次数和令牌成本。例如，我做了以下更改：

然而，这导致了更多的调用次数，大约有 140K 个标记。没有太大的减少。我尝试设置更低的值，但然后我收到了 Python 错误，并且由于重试而发生了更多的 LLM 调用。我需要进一步深入研究，以解释为什么会这样。

Conclusion结论

从上面可以明显看出，本地查询比全局查询更少耗费且成本较低。通过调整本地查询设置，您可以接近基准 RAG 成本，其中你返回大约 500 个标记的 3-5 个文本块。延迟也相当不错。当然，根据您的数据，本地搜索的响应不一定比基准 RAG 更好。

全局查询成本更高，但确实可以让您对数据集进行广泛提问。我不会在聊天助手场景中一贯使用这些全局查询。然而，您可以从全局查询开始，然后用本地查询或基准 RAG 处理后续问题。