Zum Inhalt springen

Auswahl und Überschreibung von Sprachmodellen

Diese Seite enthält Informationen zur Auswahl eines zu verwendenden Modells und zu Optionen zur Bereitstellung Ihres eigenen Modells für GraphRAG. Beachten Sie, dass dies kein Leitfaden zur Auswahl des richtigen Modells für Ihren Anwendungsfall ist.

Standardmodell-Unterstützung

GraphRAG wurde mit OpenAI-Modellen entwickelt und getestet, daher ist dies die standardmäßige Modellreihe, die wir unterstützen. Dies soll keine Einschränkung oder Aussage über die Qualität oder Eignung für Ihren Anwendungsfall sein, sondern nur, dass es die Reihe ist, mit der wir uns beim Prompting, Tuning und Debugging am besten auskennen.

GraphRAG verwendet außerdem eine Sprachmodell-Wrapper-Bibliothek, die von mehreren Projekten in unserem Team verwendet wird und fnllm heißt. fnllm bietet zwei wichtige Funktionen für GraphRAG: Ratenbegrenzungskonfiguration, um unseren Durchsatz für große Indizierungsjobs zu maximieren, und robuste Zwischenspeicherung von API-Aufrufen, um den Verbrauch bei wiederholten Indizes für Tests, Experimente oder inkrementelle Erfassung zu minimieren. fnllm verwendet im Hintergrund das OpenAI Python SDK, daher sind OpenAI-kompatible Endpunkte standardmäßig eine Grundvoraussetzung.

Ab Version 2.6.0 unterstützt GraphRAG die Verwendung von LiteLLM anstelle von fnllm für den Aufruf von Sprachmodellen. LiteLLM unterstützt über 100 Modelle, wobei zu beachten ist, dass das gewählte Modell strukturierte Ausgaben gemäß einem JSON-Schema zurückgeben muss.

Beispiel für die Verwendung von LiteLLM als Sprachmodell-Tool für 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

Um LiteLLM zu verwenden, muss man

  • type auf entweder chat oder embedding setzen.
  • Einen model_provider angeben, z. B. openai, azure, gemini usw.
  • model auf ein vom API des model_provider unterstütztes Modell setzen.
  • Einen deployment_name angeben, wenn azure als model_provider verwendet wird.

Weitere Details zur Konfiguration finden Sie unter Detaillierte Konfiguration. Informationen zur grundlegenden Verwendung von LiteLLM finden Sie unter LiteLLm grundlegende Verwendung (Der model_provider ist der Teil vor /, während model der Teil nach / ist).

Überlegungen zur Modellauswahl

GraphRAG wurde am gründlichsten mit der gpt-4-Modellreihe von OpenAI getestet, einschließlich gpt-4, gpt-4-turbo, gpt-4o und gpt-4o-mini. Unser arXiv-Paper beispielsweise führte eine Qualitätsbewertung mit gpt-4-turbo durch. Wie oben erwähnt, werden Nicht-OpenAI-Modelle ab GraphRAG 2.6.0 über LiteLLM unterstützt, aber die gpt-4-Modellreihe von OpenAI bleibt die am besten getestete und unterstützte Modellreihe für GraphRAG.

Versionen von GraphRAG vor 2.2.0 verwendeten intensiv max_tokens und logit_bias zur Steuerung der generierten Antwortlänge oder des Inhalts. Die Einführung der o-Serien-Modelle brachte neue, inkompatible Parameter mit sich, da diese Modelle eine Denkkomponente enthalten, die andere Verbrauchsmuster und Antwortgenerierungsattribute als Modelle ohne Denkkomponente aufweist. GraphRAG 2.2.0 unterstützt diese Modelle nun, es gibt jedoch wichtige Unterschiede, die Sie verstehen müssen, bevor Sie wechseln.

  • Zuvor verwendete GraphRAG max_tokens, um Antworten an einigen Stellen zu begrenzen. Dies geschah, um vorhersagbare Inhaltsgrößen beim Aufbau nachgelagerter Kontextfenster für die Zusammenfassung zu gewährleisten. Wir sind von der Verwendung von max_tokens zu einem Prompt-basierten Ansatz übergegangen, der in unseren Tests gut funktioniert. Wir empfehlen, max_tokens in Ihrer Sprachmodell-Konfiguration nur aus Budgetgründen zu verwenden, wenn Sie den Verbrauch begrenzen möchten, und nicht zur Steuerung der erwarteten Antwortlänge. Wir unterstützen jetzt auch das o-Serien-Äquivalent max_completion_tokens, aber wenn Sie dies verwenden, beachten Sie, dass zusätzlich zu den Antwort-Tokens ein unbekannter fester Betrag für das Denken anfallen kann, sodass dies keine gute Technik zur Antwortsteuerung ist.
  • Zuvor verwendete GraphRAG eine Kombination aus max_tokens und logit_bias, um binäre Ja/Nein-Fragen während des Gleaning streng zu steuern. Dies ist bei Denkmodellen nicht möglich, daher sind wir erneut zu einem Prompt-basierten Ansatz übergegangen. Unsere Tests mit gpt-4o, gpt-4o-mini und o1 zeigen, dass dies konsistent funktioniert, könnte aber Probleme verursachen, wenn Sie ein älteres oder kleineres Modell haben.
  • Die o-Serien-Modelle sind wesentlich langsamer und teurer. Es kann sinnvoll sein, einen asymmetrischen Ansatz zur Modellnutzung in Ihrer Konfiguration zu verwenden: Sie können beliebig viele Modelle im models-Block Ihrer settings.yaml definieren und sie per Schlüssel für jeden Workflow referenzieren, der ein Sprachmodell benötigt. Sie könnten beispielsweise gpt-4o für die Indizierung und o1 für die Abfrage verwenden. Experimentieren Sie, um die richtige Balance zwischen Kosten, Geschwindigkeit und Qualität für Ihren Anwendungsfall zu finden.
  • Die o-Serien-Modelle enthalten eine Form der nativen Chain-of-Thought-Logik, die in den Nicht-o-Serien-Modellen fehlt. Die Prompts von GraphRAG enthalten manchmal CoT, da dies bei der gpt-4*-Serie eine effektive Technik war. Dies kann bei der o-Serie kontraproduktiv sein, daher möchten Sie möglicherweise die Prompt-Vorlagen (insbesondere für die Graph- und Claim-Extraktion) anpassen oder sogar große Teile davon neu schreiben.

Beispielkonfiguration mit asymmetrischer Modellnutzung

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"

Eine weitere Option wäre, überhaupt kein Sprachmodell für die Graph-Extraktion zu verwenden, sondern stattdessen die fast Indexing-Methode zu nutzen, die NLP für Teile der Indexierungsphase anstelle von LLM-APIs verwendet.

Verwendung von Nicht-OpenAI-Modellen

Wie oben gezeigt, können Nicht-OpenAI-Modelle ab GraphRAG Version 2.6.0 über LiteLLM verwendet werden, aber es können immer noch Fälle auftreten, in denen einige Benutzer Modelle verwenden möchten, die nicht von LiteLLM unterstützt werden. Es gibt zwei Ansätze, um eine Verbindung zu nicht unterstützten Modellen herzustellen

Proxy-APIs

Viele Benutzer haben Plattformen wie ollama und LiteLLM Proxy Server verwendet, um die zugrunde liegenden Modell-HTTP-Aufrufe an einen anderen Modell-Anbieter zu leiten. Dies scheint recht gut zu funktionieren, aber wir sehen häufig Probleme mit fehlerhaften Antworten (insbesondere JSON). Wenn Sie dies tun, stellen Sie bitte sicher, dass Ihr Modell die spezifischen Antwortformate, die GraphRAG erwartet, zuverlässig zurückgibt. Wenn Sie Probleme mit einem Modell haben, müssen Sie möglicherweise versuchen, das Format durch Prompting zu erzwingen oder die Antwort in Ihrem Proxy abzufangen, um fehlerhafte Antworten zu behandeln.

Modell-Protokoll

Ab GraphRAG 2.0.0 unterstützen wir die Modell-Injektion durch die Verwendung eines standardmäßigen Chat- und Embedding-Protokolls und einer begleitenden ModelFactory, mit der Sie Ihre Modellimplementierung registrieren können. Dies wird mit der CLI nicht unterstützt, sodass Sie GraphRAG als Bibliothek verwenden müssen.

Sobald Sie eine Modellimplementierung haben, müssen Sie diese bei unserer ModelFactory registrieren

class MyCustomModel:
    ...
    # implementation

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

Dann können Sie in Ihrer Konfiguration auf den von Ihnen verwendeten Typnamen verweisen

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

Beachten Sie, dass Ihrem benutzerdefinierten Modell die gleichen Parameter für die Initialisierung und Methodenaufrufe übergeben werden, die wir in ganz GraphRAG verwenden. Derzeit gibt es keine Möglichkeit, benutzerdefinierte Parameter zu definieren. Möglicherweise müssen Sie daher einen Closure-Scope oder ein Factory-Muster innerhalb Ihrer Implementierung verwenden, um benutzerdefinierte Konfigurationswerte zu erhalten.