本文编译自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。
作为对比，GPT-4o的百万Tokens输入和输出价格分别是5美元和15美元，之前的入门款模型GPT-3.5 Turbo定价分别是0.5美元和1.5美元。这就是说，最新的“迷你模型”的价格比GPT-4o便宜了96%~97%，比起GPT-3.5 Turbo也要便宜60%~70%。 建立Langfuse日志记录 为了方便查看对LLM的调用，我使用了以下组件：
安装 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个令牌。系统提示开始如下：
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 中，我修改了本地搜索设置如下：
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
追踪结果很明显：令牌消耗更少，延迟也更低。
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 中的默认参数来减少调用次数和令牌成本。例如，我做了以下更改：
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 处理后续问题。
PS: 有测评人用4o的API拆解微软的测试例子（大概3万字）花了大概7-11刀左右。最近有的测试通过4o-mini的API用GraphRag对将近3万字的文档作为知识库进行问答，费用降到 0.12刀。
粤ICP备14082021号
免费POC，
零成本试错
