Skip to content

语言模型选择与覆盖

本页包含关于选择使用模型和为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，但使用时请记住，除了响应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模型

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

代理API

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

模型协议

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

一旦有了模型实现，您需要将其注册到我们的ModelFactory：

class MyCustomModel:
    ...
    # implementation

其他地方...

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

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

```yaml
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中使用的相同的初始化参数和方法调用参数。目前没有定义自定义参数的能力，因此您可能需要在实现中使用闭包作用域或工厂模式来获取自定义配置值。