语言模型选择和覆盖

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

默认模型支持

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

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

模型选择注意事项

GraphRAG 已经过 OpenAI 的 gpt-4 系列模型的彻底测试，包括 gpt-4 gpt-4-turbo、gpt-4o 和 gpt-4o-mini。例如，我们的 arXiv 论文使用 gpt-4-turbo 进行了质量评估。

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

以前，GraphRAG 在几个位置使用 max_tokens 来限制响应。这样做是为了使我们在为摘要构建下游上下文窗口时可以具有可预测的内容大小。我们现在已从使用 max_tokens 切换到使用提示方法，该方法在我们的测试中运行良好。我们建议仅出于预算原因在语言模型配置中使用 max_tokens，如果您想限制消耗，而不是为了预期的响应长度控制。我们现在还支持 o 系列等效的 max_completion_tokens，但如果您使用它，请记住，除了响应令牌之外，可能还有一些未知的固定推理消耗量，因此它不是响应控制的好技术。
以前，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 模型

如上所述，我们的主要经验和重点一直在 OpenAI 模型上，因此这是开箱即用的支持。许多用户要求支持其他模型类型，但处理当今可用的许多模型超出了我们研究的范围。您可以使用两种方法连接到非 OpenAI 模型

代理 API

许多用户使用 ollama 等平台来将底层模型 HTTP 调用代理到其他模型提供商。这似乎运行得相当好，但我们经常看到响应格式错误（尤其是 JSON）的问题，因此如果您这样做，请理解您的模型需要可靠地返回 GraphRAG 期望的特定响应格式。如果您在模型方面遇到问题，您可能需要尝试提示来诱使格式，或者拦截代理中的响应以尝试处理格式错误的响应。

模型协议

从 GraphRAG 2.0.0 开始，我们支持通过使用标准聊天和嵌入协议以及您可以用来注册模型实现的随附 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

请注意，您的自定义模型将被传递相同的 init 参数和方法调用参数，这些参数我们在整个 GraphRAG 中使用。目前没有任何定义自定义参数的能力，因此您可能需要在您的实现中使用闭包范围或工厂模式来获取自定义配置值。