语言模型选择和覆盖

此页面包含有关为 GraphRAG 选择要使用的模型以及提供您自己的模型的选项的信息。请注意，这并非寻找适合您用例的模型的指南。

默认模型支持

GraphRAG 是使用 OpenAI 模型构建和测试的，因此这是我们支持的默认模型集。这并非旨在限制或声明其质量或是否适合您的用例，只是我们对提示、调优和调试最熟悉的一组模型。

GraphRAG 还利用了我们团队中多个项目使用的语言模型包装库，名为 fnllm。fnllm 为 GraphRAG 提供了两个重要功能：速率限制配置，以帮助我们最大限度地提高大型索引作业的吞吐量，以及稳健的 API 调用缓存，以最大程度地减少测试、实验或增量摄取时重复索引的消耗。fnllm 在底层使用 OpenAI Python SDK，因此 OpenAI 兼容的端点是开箱即用的基本要求。

从 2.6.0 版本开始，GraphRAG 支持使用 LiteLLM 而不是 fnllm 来调用语言模型。LiteLLM 支持 100 多个模型，但需要注意的是，在选择模型时，它必须支持返回符合 JSON 模式的结构化输出。

使用 LiteLLm 作为 GraphRAG 语言模型工具的示例

models:
  default_chat_model:
    type: chat
    auth_type: api_key
    api_key: ${GEMINI_API_KEY}
    model_provider: gemini
    model: gemini-2.5-flash-lite
  default_embedding_model:
    type: embedding
    auth_type: api_key
    api_key: ${GEMINI_API_KEY}
    model_provider: gemini
    model: gemini-embedding-001

要使用 LiteLLM，必须

将 type 设置为 chat 或 embedding。
提供一个 model_provider，例如 openai、azure、gemini 等。
将 model 设置为 model_provider 的 API 支持的模型。
如果使用 azure 作为 model_provider，则提供 deployment_name。

有关配置的更多详细信息，请参阅详细配置。查看 LiteLLm 基本用法，了解模型的调用方式（model_provider 是 / 之前的部分，而 model 是 / 之后的部分）。

模型选择考量

GraphRAG 已经对 OpenAI 的 gpt-4 系列模型进行了最彻底的测试，包括 gpt-4、gpt-4-turbo、gpt-4o 和 gpt-4o-mini。例如，我们的 arXiv 论文使用 gpt-4-turbo 进行了质量评估。如上所述，从 GraphRAG 2.6.0 及更高版本开始，通过使用 LiteLLM 支持非 OpenAI 模型，但 OpenAI 的 gpt-4 系列模型仍然是 GraphRAG 测试和支持最全面的模型套件。

GraphRAG 2.2.0 之前的版本大量使用了 max_tokens 和 logit_bias 来控制生成的响应长度或内容。o 系列模型的引入增加了新的、不兼容的参数，因为这些模型包含一个推理组件，其消耗模式和响应生成属性与非推理模型不同。GraphRAG 2.2.0 现在支持这些模型，但在切换之前需要了解一些重要的区别。

以前，GraphRAG 在几个位置使用 max_tokens 来限制响应。这样做是为了在构建用于摘要的下游上下文窗口时，我们可以获得可预测的内容大小。我们现在已从使用 max_tokens 切换到使用提示方法，这在我们的测试中效果良好。我们建议仅出于预算原因在语言模型配置中使用 max_tokens，如果您想限制消耗，而不是用于预期响应长度控制。我们现在还支持 o 系列等效的 max_completion_tokens，但如果您使用此项，请记住除了响应 token 外，可能还有一些未知的固定推理消耗量，因此这不是一种好的响应控制技术。
以前，GraphRAG 在收集信息时使用 max_tokens 和 logit_bias 的组合来严格控制二元是/否问题。这对于推理模型是不可能的，因此我们再次切换到提示方法。我们对 gpt-4o、gpt-4o-mini 和 o1 的测试表明这始终有效，但如果您的模型较旧或较小，可能会出现问题。
o 系列模型更慢且更昂贵。在配置中采用模型使用的非对称方法可能很有用：您可以在 settings.yaml 的 models 块中定义任意数量的模型，并按键引用它们以用于需要语言模型的每个工作流。例如，您可以使用 gpt-4o 进行索引，使用 o1 进行查询。进行实验以找到适合您的用例的成本、速度和质量之间的最佳平衡。
o 系列模型包含一种原生的原生思维链推理形式，而非 o 系列模型中没有。GraphRAG 的提示有时包含 CoT，因为它在 gpt-4* 系列中是一种有效的技术。它可能与 o 系列适得其反，因此您可能需要调整甚至重写提示模板的大部分内容（特别是对于图和声明提取）。

非对称模型使用的配置示例

models:
  extraction_chat_model:
    api_key: ${GRAPHRAG_API_KEY}
    type: openai_chat
    auth_type: api_key
    model: gpt-4o
    model_supports_json: true
  query_chat_model:
    api_key: ${GRAPHRAG_API_KEY}
    type: openai_chat
    auth_type: api_key
    model: o1
    model_supports_json: true

...

extract_graph:
  model_id: extraction_chat_model
  prompt: "prompts/extract_graph.txt"
  entity_types: [organization,person,geo,event]
  max_gleanings: 1

...


global_search:
  chat_model_id: query_chat_model
  map_prompt: "prompts/global_search_map_system_prompt.txt"
  reduce_prompt: "prompts/global_search_reduce_system_prompt.txt"
  knowledge_prompt: "prompts/global_search_knowledge_system_prompt.txt"

另一个选择是完全避免使用语言模型进行图提取，而是使用 fast 索引方法，该方法在索引阶段的部分内容中使用 NLP 而不是 LLM API。

使用非 OpenAI 模型

如上所示，从 GraphRAG 2.6.0 版本开始，可以通过 LiteLLM 使用非 OpenAI 模型，但某些用户可能仍然希望使用 LiteLLM 不支持的模型。连接到不支持的模型有两种方法

代理 API

许多用户已使用 ollama 和 LiteLLM 代理服务器等平台将底层模型 HTTP 调用代理到不同的模型提供商。这似乎效果良好，但我们经常发现响应格式错误（尤其是 JSON）的问题，因此如果您这样做，请理解您的模型需要可靠地返回 GraphRAG 期望的特定响应格式。如果您在使用模型时遇到问题，您可能需要尝试提示以哄骗格式，或者在您的代理中拦截响应以尝试处理格式错误的响应。

模型协议

从 GraphRAG 2.0.0 开始，我们支持通过使用标准聊天和嵌入协议以及随附的 ModelFactory 进行模型注入，您可以使用 ModelFactory 注册您的模型实现。CLI 不支持此功能，因此您需要将 GraphRAG 作为库使用。

我们的协议在此处定义
我们包装 fnllm 的基本实现在此处
我们在测试中有一个简单的模拟实现，您可以在此处参考

拥有模型实现后，您需要将其注册到我们的 ModelFactory

class MyCustomModel:
    ...
    # implementation

# elsewhere...
ModelFactory.register_chat("my-custom-chat-model", lambda **kwargs: MyCustomModel(**kwargs))

然后，在您的配置中，您可以引用您使用的类型名称

models:
  default_chat_model:
    type: my-custom-chat-model


extract_graph:
  model_id: default_chat_model
  prompt: "prompts/extract_graph.txt"
  entity_types: [organization,person,geo,event]
  max_gleanings: 1

请注意，您的自定义模型将被传递与我们在 GraphRAG 中使用的相同的初始化和方法调用参数。目前无法定义自定义参数，因此您可能需要在实现中使用闭包范围或工厂模式来获取自定义配置值。