最近微软开源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 文件：
1 2 3 4 5 6 7 8 9 | model_list: - model_name: gpt-4o litellm_params: model: gpt-4o - model_name: text-embedding-3-small litellm_params: model: text-embedding-3-small litellm_settings: success_callback: ["langfuse"] |
在启动代理之前，请设置以下环境变量：
1 2 3 | export OPENAI_API_KEY=my-api-key export LANGFUSE_PUBLIC_KEY="pk_kk" export LANGFUSE_SECRET_KEY="sk_ss" |
你可以从 OpenAI 和 Langfuse 门户获取这些值。确保还使用 pip install langfuse 安装 Langfuse。
接下来，我们可以使用 litellm --config config.yaml --debug 启动代理。
要让 GraphRAG 与代理一起工作，请打开 GraphRAG 的 settings.yaml 并在 llm settings 下设置以下值：
1 | api_base: http://localhost:4000 |
LiteLLM正在监听该端口上传入的OpenAI请求。
运行本地查询
当地查询首先通过相似性搜索创建您的问题的嵌入，并在知识图中找到相关实体。这些嵌入在索引期间存储在 LanceDB 中。基本上，相似性搜索的结果被用作进入图的入口点。
这就是为什么您需要将嵌入模型添加到 LiteLLM 的 config.yaml 中的原因。全局查询不需要这个设置。
在 LanceDB 中找到相似实体后，它们被放入提示中，以回答您的原始问题以及相关实体。
一个本地查询可通过单个 LLM 调用处理。让我们来看一下追踪：
Trace from local query查询大约用了10秒和11500个令牌。系统提示开始如下：
它实际操作的数据（称为数据表）在提示中进一步列出。您可以在下面找到一些数据点：
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 奥布莱恩形象的存在，他与之互动。该提示还包含了提到这些实体的书籍来源。例如：
对此提示的回应类似于以下回应：
响应中包含对实体和源的引用及其 ID。请注意，您可以影响检索到的实体数和消耗的标记数目。在 Graph RAG 的 settings.yaml 中，我修改了本地搜索设置如下：
1 2 3 4 5 6 7 | local_search: # text_unit_prop: 0.5 # community_prop: 0.1 # conversation_history_max_turns: 5 top_k_mapped_entities: 5 top_k_relationships: 5 max_tokens: 6000 |
追踪结果很明显：令牌消耗更少，延迟也更低。
当然，答案会缺少一些细节。您将不得不尝试这些数值，以查看在您的情况下效果最好的是什么。
Global Queries 全局查询
全局查询非常适合关于数据集的广泛问题。例如：“1984年的主题是什么？”全局查询不是单个LLM调用，比本地查询更昂贵。
让我们看看全局查询的追踪。每个迹象都是一个LLM调用来回答全局查询：
列表中的最后一个是开始的地方：
正如您可能已经注意到的那样，上面的调用并不直接返回给用户。系统提示不包含图中的实体，而是社区报告。社区报告是在索引过程中创建的。首先，使用Leiden算法检测社区，然后进行总结。数据集中可能有很多社区和摘要。
这个第一个跟踪要求LLM回答这个问题：“1984年的主题是什么？”给一个社区报告的第一个集合并生成中间答案。这些中间答案会保存直到最后一个调用，用来根据所有中间答案回答问题。完全有可能使用与查询不相关的社区报告。
以下是最后一次调用：
根据中间答案回答问题。我这里没有展示整个提示。上面，您看到被提供给最终提示的数据：社区报告中的中间答案。然后得出最终答案：
Final answer to the global query全局问题的最终答案下面是再次列出的所有调用清单：
总的来说，在默认设置的基础上，进行了 12 次 LLM 调用，消耗了大约 150K 个令牌。无法从此列表中计算总延迟，因为调用是并行进行的。总成本约为 80 美分。
可以通过调整 settings.yaml 中的默认参数来减少调用次数和令牌成本。例如，我做了以下更改：
1 2 3 4 5 6 | global_search: max_tokens: 6000 # was 12000 data_max_tokens: 500 # was 1000 map_max_tokens: 500 # was 1000 # reduce_max_tokens: 2000 # concurrency: 32 |
然而，这导致了更多的调用次数，大约有 140K 个标记。没有太大的减少。我尝试设置更低的值，但然后我收到了 Python 错误，并且由于重试而发生了更多的 LLM 调用。我需要进一步深入研究，以解释为什么会这样。
Conclusion结论
从上面可以明显看出，本地查询比全局查询更少耗费且成本较低。通过调整本地查询设置，您可以接近基准 RAG 成本，其中你返回大约 500 个标记的 3-5 个文本块。延迟也相当不错。当然，根据您的数据，本地搜索的响应不一定比基准 RAG 更好。
全局查询成本更高，但确实可以让您对数据集进行广泛提问。我不会在聊天助手场景中一贯使用这些全局查询。然而，您可以从全局查询开始，然后用本地查询或基准 RAG 处理后续问题。
