RAG reicht nicht aus: Wann Fine-Tuning, Agents oder Knowledge Graphs sinnvoll sind

Retrieval-Augmented Generation ist zur Standardantwort auf die Frage „Wie sollten wir Enterprise-KI bauen?" geworden. Und das aus gutem Grund — RAG löst die häufigste LLM-Limitierung (Wissensgrenze und Halluzination) mit einer relativ einfachen Architektur: Dokumente indexieren, relevante Chunks abrufen und dem Modell zuführen.

Aber RAG ist ein Muster in einer Familie von vier. Unternehmen, die es als einziges Muster betrachten, bauen zunehmend komplexe RAG-Pipelines, um Probleme zu lösen, für die RAG nie konzipiert war. Dieser Beitrag bietet einen Entscheidungsrahmen für die Wahl zwischen RAG, Fine-Tuning, Agentic Retrieval und Knowledge Graphs — und dafür, wann eine Kombination von Ansätzen die richtige Antwort ist.

Die vier Muster

Muster 1: Retrieval-Augmented Generation (RAG)

Das Modell erhält abgerufenen Kontext zusammen mit der Benutzeranfrage. Das Wissen liegt in einem externen Index, nicht in den Modellgewichten.

Stärken:

• Wissen kann ohne erneutes Training aktualisiert werden
• Quellenangabe ist unkompliziert
• Funktioniert gut für faktische Q&A über einen bekannten Dokumentenbestand
• Kosteneffektiv — kein Modelltraining erforderlich

Limitierungen:

• Die Retrieval-Qualität ist die Obergrenze. Wenn die richtigen Chunks nicht abgerufen werden, ist die Antwort falsch.
• Chunk-Grenzen sind willkürlich. Wichtiger Kontext erstreckt sich oft über mehrere Chunks.
• Multi-Hop-Reasoning ist schwach. Fragen wie „Welche Lieferanten hatten Lieferverzögerungen in Q3, die auch Qualitätsprobleme in Q4 hatten?" erfordern eine Synthese über viele Dokumente.
• Kontextfenster-Sättigung. Das Einfügen von 20 Chunks in den Kontext verschlechtert oft die Antwortqualität im Vergleich zu 5 gut ausgewählten Chunks.

Muster 2: Fine-Tuning

Die Modellgewichte werden mit domänenspezifischen Trainingsdaten aktualisiert. Das Wissen und die Reasoning-Muster sind im Modell selbst codiert.

Stärken:

• Konsistentes Ausgabeformat und -stil (entscheidend für regulatorische Dokumente)
• Domänenspezifische Reasoning-Muster (medizinische Differentialdiagnose, Rechtsanalyse)
• Geringere Latenz — kein Retrieval-Schritt
• Kleinere Kontextfenster pro Anfrage erforderlich (geringere Kosten pro Anfrage)

Limitierungen:

• Teuer in Training und Wartung. Fine-Tuning von GPT-4o kostet deutlich mehr als der Aufbau einer RAG-Pipeline.
• Wissen veraltet. Erneutes Training ist erforderlich, um neue Informationen aufzunehmen.
• Risiko des katastrophalen Vergessens. Aggressives Fine-Tuning kann die allgemeinen Fähigkeiten des Modells beeinträchtigen.
• Evaluation ist schwieriger. Sie benötigen eine Bewertung der Fine-Tuned-Outputs durch Domänenexperten.

Wann Fine-Tuning statt RAG

Muster 3: Agentic Retrieval

Ein KI-Agent entscheidet, was abgerufen wird, wann abgerufen wird und ob die abgerufenen Informationen ausreichend sind. Im Gegensatz zu einfachem RAG, bei dem der Abruf einmal erfolgt, ist Agentic Retrieval iterativ und reasoning-gesteuert.

Stärken:

• Bewältigt Multi-Hop-Reasoning auf natürliche Weise. Der Agent zerlegt komplexe Fragen in abrufbare Teilfragen.
• Multi-Source-Retrieval. Der Agent kann Vektordatenbanken, SQL-Datenbanken, APIs und Knowledge Graphs in derselben Interaktion abfragen.
• Selbstkorrigierend. Bei schlechten anfänglichen Retrieval-Ergebnissen kann der Agent die Abfrage umformulieren und erneut versuchen.
• Dynamische Tool-Auswahl. Der Agent wählt die richtige Retrieval-Methode basierend auf dem Abfragetyp.

Limitierungen:

• Höhere Latenz. Mehrere Retrieval-Runden fügen 3-10x Latenz im Vergleich zu Single-Shot-RAG hinzu.
• Höhere Kosten. Jede Retrieval-Runde und jeder Reasoning-Schritt verbraucht Tokens.
• Nicht-deterministisch. Dieselbe Abfrage kann bei verschiedenen Durchläufen unterschiedliche Retrieval-Pfade nehmen.
• Erfordert Leitplanken. Ohne Budget-Obergrenzen und Iterationslimits können Agents in Retrieval-Schleifen geraten.

Implementierung: Agentic RAG mit Semantic Kernel

// Agentic RAG — agent decides retrieval strategy
var kernel = Kernel.CreateBuilder()
    .AddAzureOpenAIChatCompletion("gpt-4o", endpoint, credential)
    .Build();

// Multiple retrieval tools available to the agent
kernel.Plugins.AddFromType<VectorSearchPlugin>();   // Semantic search
kernel.Plugins.AddFromType<SqlQueryPlugin>();        // Structured data
kernel.Plugins.AddFromType<GraphQueryPlugin>();      // Knowledge graph
kernel.Plugins.AddFromType<ApiPlugin>();             // External APIs

var agent = new ChatCompletionAgent
{
    Name = "ResearchAgent",
    Instructions = """
        You are a research agent with access to multiple data sources.
        
        For factual questions about documents, use vector_search.
        For questions involving numbers, dates, or comparisons, use sql_query.
        For questions about relationships between entities, use graph_query.
        For real-time external data, use api_call.
        
        Always verify your findings by cross-referencing at least two sources
        when possible. If initial results are insufficient, reformulate your
        query and try again. Cite your sources in the final response.
        
        Maximum retrieval rounds: 5. If you cannot find sufficient information
        in 5 rounds, state what you found and what remains uncertain.
        """,
    Kernel = kernel,
};

Muster 4: Knowledge Graphs

Entitäten, Beziehungen und Hierarchien werden aus Dokumenten extrahiert und in einer Graphdatenbank gespeichert. Zur Abfragezeit liefert die Graphtraversierung strukturierten, beziehungsbewussten Kontext für das LLM.

Stärken:

• Multi-Hop-Reasoning ist nativ. „Wer leitet das Team, das für das Produkt mit den meisten Qualitätsproblemen verantwortlich ist?" traversiert den Graphen direkt.
• Strukturierte Beziehungen. Im Gegensatz zu flachen Text-Chunks bewahrt der Graph-Kontext Entitätstypen, Beziehungstypen und Hierarchien.
• Erklärbarkeit. Der Graph-Traversierungspfad ist die Reasoning-Kette — vollständig nachvollziehbar.
• Komplementär zu RAG. Graph-Kontext liefert strukturelles Verständnis; Text-Chunks liefern Details.

Limitierungen:

• Graphkonstruktion ist aufwendig. Entitätsextraktion und Beziehungsmapping erfordern erhebliche Vorabinvestitionen.
• Wartungsaufwand. Der Graph muss mit den Quelldokumenten synchron gehalten werden.
• Komplexität des Schema-Designs. Ein schlecht konzipiertes Graph-Schema erzeugt irrelevante Traversierungen.
• Abfragemuster müssen antizipiert werden. Der Graph ist nur so nützlich wie die dafür entworfenen Traversierungsabfragen.

Der Entscheidungsrahmen

Schritt 1: Klassifizieren Sie Ihre Abfragetypen

Analysieren Sie eine repräsentative Stichprobe der Abfragen, die Ihr System verarbeiten soll. Klassifizieren Sie jede Abfrage:

Schritt 2: Bewerten Sie die Rahmenbedingungen

Schritt 3: Kombinationen in Betracht ziehen

Die effektivsten Enterprise-Systeme kombinieren Muster:

GraphRAG — Der Knowledge Graph liefert strukturellen Kontext. RAG liefert detaillierten Text aus relevanten Chunks. Das LLM erhält beides.

Agentic RAG — Ein Agent orchestriert den Abruf aus mehreren Quellen, einschließlich RAG-Pipelines, SQL-Datenbanken und APIs. Der Agent entscheidet, was wann abgerufen wird.

Fine-Tuned Model + RAG — Das Modell wird für domänenspezifische Reasoning-Muster und das Ausgabeformat fine-getuned. RAG liefert aktuellen faktischen Kontext. Das Fine-Tuned-Modell produziert qualitativ hochwertigere Outputs aus demselben abgerufenen Kontext, da es die Domäne tiefgreifend versteht.

Enterprise-Szenario-Beispiele

Szenario: Interner Rechtsreview-Assistent

• Abfragetyp: Vertragsklauselanalyse, Risikobewertung, Präzedenzfallrecherche
• Muster: Fine-Tuning (juristisches Reasoning) + RAG (Klauselabruf) + Knowledge Graph (Präzedenzfallbeziehungen)
• Warum: Juristisches Reasoning erfordert domäneninternalisierte Muster. Spezifische Klauseln benötigen Retrieval. Präzedenzfallbeziehungen sind graph-nativ.

Szenario: Kundensupport-Bot

• Abfragetyp: Produktfragen, Bestellstatus, Fehlerbehebung
• Muster: RAG (Produktdokumentation) + Agentic (Bestellabfrage via API)
• Warum: Produktwissen ist dokumentenbasiert (RAG). Bestelldaten sind strukturiert (Agent mit API-Tools). Kein Fine-Tuning nötig — das generische Modell bewältigt den Konversationsstil gut.

Szenario: Lieferkettenrisikoanalyse

• Abfragetyp: Multi-Hop-Reasoning über Lieferanten, Komponenten, Regionen und Risikofaktoren
• Muster: Knowledge Graph (Lieferanten-/Komponenten-/Risikobeziehungen) + Agentic RAG (aktuelle Nachrichten und Berichte)
• Warum: Lieferkettenbeziehungen sind inhärent graphstrukturiert. Aktuelle Risikobewertung erfordert Echtzeit-Retrieval.

Szenario: Medizinische Literaturrecherche

• Abfragetyp: Ergebnisse über klinische Studien hinweg synthetisieren, Widersprüche identifizieren
• Muster: Fine-Tuning (medizinisches Reasoning) + Knowledge Graph (Studien-/Medikamenten-/Erkrankungsbeziehungen) + RAG (Studiendetails)
• Warum: Medizinisches Reasoning erfordert internalisiertes Domänenwissen. Studienbeziehungen sind graph-nativ. Einzelne Studiendetails benötigen Retrieval.

Kosten- und Komplexitätsvergleich

Muster-Auswahl-Entscheidungsfluss

Praktische Empfehlungen

1. Beginnen Sie mit RAG. Es löst 60–70 % der Enterprise-Wissensabruf-Anwendungsfälle mit der geringsten Investition. Beweisen Sie den Wert, bevor Sie Komplexität hinzufügen.

2. Fügen Sie Agentic Retrieval hinzu, wenn RAG an seine Grenzen stößt. Wenn Benutzer regelmäßig Fragen stellen, die mehrere Retrieval-Runden oder quellenübergreifende Synthese erfordern, adressiert Agentic Retrieval diese Lücken.

3. Investieren Sie in Knowledge Graphs, wenn Beziehungen den Kernwert darstellen. Lieferketten, Organisationsstrukturen, regulatorische Rahmenwerke, Produktabhängigkeiten — wenn die Beziehungen zwischen Entitäten wichtiger sind als die Entitäten selbst, ist ein Knowledge Graph gerechtfertigt.

4. Fine-Tunen Sie, wenn Ausgabequalität und -konsistenz stagnieren. Wenn Ihr RAG-System die richtigen Informationen abruft, das Modell aber Schwierigkeiten hat, darüber zu reasonen oder domänengerechte Outputs zu produzieren, adressiert Fine-Tuning die Lücke in den Modellfähigkeiten.

5. Kombinieren Sie niemals alle vier Muster von Anfang an. Jedes Muster fügt operative Komplexität hinzu. Beweisen Sie, dass jede Ergänzung eine spezifische, gemessene Qualitätslücke schließt, bevor Sie das nächste hinzufügen.

Die ehrliche Realität

RAG ist für die meisten Enterprise-KI-Anwendungen heute tatsächlich ausreichend. Der Trend zu Agents, Knowledge Graphs und Fine-Tuning sollte durch gemessene Qualitätslücken getrieben sein, nicht durch Technologiebegeisterung.

Die Unternehmen, die den besten ROI aus ihren KI-Investitionen erzielen, sind diejenigen, die:

• Zuerst eine solide RAG-Baseline aufbauen
• Messen, wo sie bei echten Benutzerabfragen versagt
• Komplexität nur dort hinzufügen, wo die Daten es rechtfertigen
• Ihre Architektur so einfach halten, wie das Problem es zulässt

Die Unternehmen, die Schwierigkeiten haben, sind diejenigen, die mit der komplexesten Architektur beginnen, weil sie beeindruckend klingt, und dann Monate damit verbringen, einen Knowledge Graph zu debuggen, den eine gut konfigurierte RAG-Pipeline übertroffen hätte.

Benötigen Sie Unterstützung bei der Auswahl der richtigen KI-Retrieval-Architektur für Ihren Anwendungsfall? Kontaktieren Sie unser Team — wir helfen Unternehmen, KI-Systeme zu entwerfen, bei denen die Komplexität der Lösung zur Komplexität des Problems passt.