Ihr Unternehmen will ein Large Language Model (LLM) mit firmeneigenen Daten nutzen. Die zentrale Frage: Wie bringen Sie Ihr Wissen in das Modell? Die zwei gängigsten Ansätze sind Retrieval-Augmented Generation (RAG) und Fine-Tuning — und die Wahl zwischen beiden hat massive Auswirkungen auf Kosten, Qualität und Wartbarkeit Ihrer KI-Lösung.
Dieser Artikel erklärt beide Ansätze technisch fundiert, vergleicht sie anhand konkreter Kriterien und gibt Ihnen eine Entscheidungshilfe für den Enterprise-Einsatz.
Was ist RAG (Retrieval-Augmented Generation)?
RAG wurde 2020 von Meta AI (damals Facebook Research) vorgestellt und hat sich seitdem zum Standardansatz für wissensbasierte KI-Anwendungen entwickelt.
Das Prinzip: Anstatt das Modell selbst zu verändern, wird ihm bei jeder Anfrage relevantes Wissen aus einer externen Wissensbasis mitgegeben.
Der RAG-Prozess in vier Schritten:
1. Indexierung: Ihre Dokumente (PDFs, Datenbanken, Wikis, E-Mails) werden in kleine Textabschnitte (Chunks) zerlegt. Jeder Chunk wird durch ein Embedding-Modell in einen mathematischen Vektor umgewandelt und in einer Vektordatenbank gespeichert (z. B. Pinecone, Weaviate, Qdrant oder pgvector).
2. Retrieval: Wenn ein Nutzer eine Frage stellt, wird diese ebenfalls in einen Vektor umgewandelt. Die Vektordatenbank findet die semantisch ähnlichsten Chunks — also die Textabschnitte, die am wahrscheinlichsten die Antwort enthalten.
3. Augmentation: Die gefundenen Chunks werden zusammen mit der ursprünglichen Frage als Kontext an das LLM übergeben. Der Prompt enthält also sowohl die Frage als auch das relevante Firmenwissen.
4. Generation: Das LLM generiert eine Antwort basierend auf dem mitgelieferten Kontext. Es nutzt sein allgemeines Sprachverständnis, um eine kohärente Antwort zu formulieren, stützt sich aber inhaltlich auf die bereitgestellten Dokumente.
Vorteile von RAG:
- Keine Modellveränderung nötig — funktioniert mit jedem LLM
- Wissen kann jederzeit aktualisiert werden (Dokumente austauschen/ergänzen)
- Quellen sind nachvollziehbar (jede Antwort kann auf Quelldokumente zurückgeführt werden)
- Geringere Kosten als Fine-Tuning
- Reduziert Halluzinationen, da das Modell auf konkreten Dokumenten basiert
Nachteile von RAG:
- Latenz: Der Retrieval-Schritt kostet Zeit (typisch 100-500ms)
- Kontextfenster-Limitierung: Nur begrenzt viele Chunks passen in den Prompt
- Retrieval-Qualität: Wenn die Suche die falschen Dokumente findet, ist auch die Antwort falsch
- Chunking-Herausforderung: Die Art, wie Dokumente in Abschnitte zerlegt werden, beeinflusst die Ergebnisqualität erheblich
Was ist Fine-Tuning?
Fine-Tuning verändert das Modell selbst. Ein vortrainiertes LLM wird mit unternehmensspezifischen Daten weitertrainiert, sodass das neue Wissen direkt in die Gewichte des Modells eingeht.
Der Fine-Tuning-Prozess:
1. Datenvorbereitung: Ihre Daten werden in Trainingsbeispiele umgewandelt — typischerweise Frage-Antwort-Paare, Konversationen oder Instruktionen mit erwarteter Ausgabe. Die Qualität dieser Trainingsdaten ist entscheidend: „Garbage in, garbage out" gilt hier besonders.
2. Training: Das vortrainierte Modell wird mit Ihren Daten weitertrainiert. Moderne Techniken wie LoRA (Low-Rank Adaptation) oder QLoRA ermöglichen effizientes Fine-Tuning, das nur einen Bruchteil der Modellparameter anpasst und damit deutlich weniger Rechenleistung benötigt.
3. Evaluation: Das fine-getunte Modell wird gegen Testdaten evaluiert. Metriken wie Genauigkeit, Konsistenz und Halluzinationsrate werden gemessen.
4. Deployment: Das angepasste Modell wird in der Produktionsumgebung bereitgestellt — on-premise oder in der Cloud.
Vorteile von Fine-Tuning:
- Das Modell „versteht" domänenspezifische Sprache und Konzepte nativ
- Keine Latenz durch Retrieval — Antworten kommen direkt
- Konsistenterer Stil und Tonalität
- Bessere Performance bei hochspezialisierten Aufgaben
- Kein Kontextfenster-Limit für das eintrainierte Wissen
Nachteile von Fine-Tuning:
- Teure Trainingsinfrastruktur (GPU-Cluster)
- Wissens-Updates erfordern erneutes Training
- Risiko des „Catastrophic Forgetting" — das Modell vergisst allgemeines Wissen
- Keine Quellenangaben — das Modell kann nicht sagen, woher eine Information stammt
- Größeres Halluzinationsrisiko bei Fragen außerhalb der Trainingsdaten
- Erfordert hochqualitative, kuratierte Trainingsdaten
Der direkte Vergleich
| Kriterium | RAG | Fine-Tuning |
|---|---|---|
| Wissensaktualisierung | Echtzeit (Dokumente austauschen) | Erneutes Training nötig (Stunden/Tage) |
| Initialkosten | Gering (Vektordatenbank + Embedding) | Hoch (GPU-Infrastruktur + Datenaufbereitung) |
| Laufende Kosten | Vektordatenbank + LLM-API-Calls | Modell-Hosting (GPU-Server) |
| Antwortlatenz | Höher (Retrieval + Generation) | Niedriger (nur Generation) |
| Quellenangaben | Ja (Chunks sind nachvollziehbar) | Nein (Wissen in Gewichten) |
| Halluzinationsrisiko | Geringer (bei gutem Retrieval) | Höher (außerhalb der Trainingsdaten) |
| Datenmenge nötig | Wenig (auch 10 Dokumente funktionieren) | Viel (hunderte bis tausende Beispiele) |
| Spezialisierungsgrad | Gut für Faktenabfragen | Besser für Stil/Tonalität/Domänensprache |
| DSGVO-Compliance | Einfacher (Daten bleiben in Datenbank) | Komplexer (Daten gehen in Modellgewichte) |
| Wartungsaufwand | Gering (Dokumente pflegen) | Hoch (re-training Pipeline) |
| Time-to-Production | 2-4 Wochen | 4-8 Wochen |
Entscheidungsframework
Die Wahl ist selten absolut. Hier ein pragmatischer Entscheidungsbaum:
RAG wählen, wenn:
- Ihr Wissen sich regelmäßig ändert (Produktkataloge, Richtlinien, Dokumentationen)
- Nachvollziehbarkeit wichtig ist (Compliance, regulierte Branchen)
- Sie schnell starten wollen (PoC in 2-4 Wochen)
- Die Datenmenge begrenzt ist
- Faktenbasierte Antworten im Vordergrund stehen
- DSGVO-Compliance eine hohe Priorität hat
Fine-Tuning wählen, wenn:
- Das Modell eine spezifische Domänensprache beherrschen muss (Medizin, Recht, Technik)
- Konsistenz in Stil und Tonalität entscheidend ist
- Die Antwortlatenz minimal sein muss
- Sie eine große Menge an hochwertigen Trainingsdaten haben
- Das Wissen sich selten ändert
Beide kombinieren (Hybrid-Ansatz), wenn:
- Sie sowohl Domänenexpertise als auch aktuelles Faktenwissen brauchen
- Das fine-getunte Modell die Sprache versteht, und RAG aktuelle Daten liefert
- Zum Beispiel: Ein auf medizinische Sprache fine-getuntes Modell, das via RAG aktuelle Leitlinien und Studien abruft
Der Hybrid-Ansatz: Das Beste aus beiden Welten
In der Praxis empfehlen wir bei Ai11 häufig einen Hybrid-Ansatz:
- Basis: Ein leistungsfähiges Foundation Model (GPT-4, Claude, Gemini)
- Fine-Tuning (optional): Für domänenspezifische Sprache und konsistenten Output-Stil
- RAG: Für aktuelle, faktenbasierte Antworten mit Quellenangaben
- Agentic Layer: Für die Fähigkeit, eigenständig zu handeln und Tools zu nutzen
Dieser Stack ist im Wesentlichen das, was wir in unserem Artikel Von RAG zu Agentic RAG beschrieben haben: Das RAG-System wird um Agenten-Fähigkeiten erweitert, sodass es nicht nur Fragen beantwortet, sondern aktiv Aufgaben erledigt.
Praxisbeispiel: Interne Wissensdatenbank
Ein mittelständisches Unternehmen mit 500 Mitarbeitern will eine interne KI-Wissensdatenbank aufbauen:
RAG-Ansatz:
- Alle internen Dokumente (Handbücher, Richtlinien, Prozessdokumentationen) werden indexiert
- Mitarbeiter stellen Fragen in natürlicher Sprache
- Das System liefert Antworten mit Quellenangaben
- Neue Dokumente sind sofort verfügbar
- Kosten: ca. 30.000 € Setup + 2.000 €/Monat
- Time-to-Production: 4 Wochen
Fine-Tuning-Ansatz:
- Aus den internen Dokumenten werden 5.000+ Trainingsbeispiele erstellt
- Ein Modell wird auf die Unternehmenssprache und -prozesse trainiert
- Das Modell versteht Fachbegriffe und Abläufe nativ
- Wissens-Updates erfordern erneutes Training (alle 2-4 Wochen)
- Kosten: ca. 50.000 € Setup + 4.000 €/Monat
- Time-to-Production: 8 Wochen
Empfehlung: Für diesen Use Case ist RAG klar überlegen — schnellere Implementierung, niedrigere Kosten, aktuelle Daten und Quellenangaben. Fine-Tuning wäre nur sinnvoll, wenn das System auch komplexe Berichte in unternehmensspezifischem Stil generieren müsste.
FAQ: RAG vs. Fine-Tuning
Kann RAG mit sehr großen Dokumentenmengen umgehen?
Ja. Moderne Vektordatenbanken skalieren auf Millionen von Dokumenten. Die Retrieval-Geschwindigkeit bleibt auch bei 10 Millionen+ Chunks im Millisekundenbereich. Die Herausforderung liegt nicht in der Menge, sondern in der Qualität des Retrievals — gutes Chunking und Embedding-Modell-Auswahl sind entscheidend.
Wie viele Trainingsdaten braucht Fine-Tuning?
Das hängt von der Aufgabe ab. Für einfache Stilanpassungen können 100-500 Beispiele ausreichen. Für echte Domänenanpassung empfehlen wir mindestens 1.000-5.000 hochwertige Trainingsbeispiele. Die Qualität der Daten ist wichtiger als die Menge — 500 exzellente Beispiele schlagen 5.000 mittelmäßige.
Ist Fine-Tuning mit Open-Source-Modellen günstiger?
Ja, deutlich. Open-Source-Modelle wie Llama 3, Mistral oder Qwen können ohne API-Kosten fine-getuned und betrieben werden. Die Kosten verlagern sich auf GPU-Infrastruktur (Cloud oder On-Premise). Mit Techniken wie QLoRA ist Fine-Tuning eines 7B-Parameter-Modells auf einer einzelnen A100-GPU in wenigen Stunden möglich.
Welcher Ansatz ist besser für DSGVO-Compliance?
RAG ist grundsätzlich einfacher zu handhaben: Personenbezogene Daten bleiben in der Vektordatenbank und können dort gezielt gelöscht werden (Recht auf Löschung). Bei Fine-Tuning gehen Daten in die Modellgewichte ein — eine gezielte Löschung einzelner Datenpunkte ist technisch kaum möglich. Für regulierte Branchen empfehlen wir daher RAG oder den Hybrid-Ansatz.
Sie möchten wissen, welcher Ansatz für Ihren Use Case am besten geeignet ist? Kontaktieren Sie uns für eine technische Beratung — wir analysieren Ihre Anforderungen und empfehlen die passende Architektur.