Sobald ein Sprachmodell mit eigenem Firmenwissen arbeiten soll, steht dieselbe Frage im Raum: RAG oder Fine-Tuning? In Erstgesprächen hören wir sie fast jede Woche, meist verbunden mit der Annahme, man müsse sich für einen der beiden Wege entscheiden. Diese Annahme führt in die falsche Richtung.
Die beiden Verfahren beantworten unterschiedliche Fragen. RAG (Retrieval-Augmented Generation) regelt den Zugriff auf Wissen: Das System sucht zur Laufzeit passende Textstellen aus Ihren Dokumenten heraus und gibt sie dem Modell als Kontext mit. Fine-Tuning verändert das Verhalten des Modells selbst: Es lernt aus vielen Beispielpaaren, wie eine Antwort klingen, aufgebaut sein oder formatiert werden soll. Es geht also nicht um ein Entweder-oder, sondern um zwei Werkzeuge für zwei verschiedene Probleme. Wer diese Trennung einmal sauber gezogen hat, trifft die Entscheidung oft in einer Stunde. Ohne sie diskutieren Projektteams wochenlang aneinander vorbei.
Wofür RAG gebaut ist
Vier Anforderungen sprechen klar für ein RAG-System.
Aktuelles Firmenwissen. Preislisten, Wartungshandbücher und QM-Dokumente ändern sich laufend. Bei RAG werden Dokumente in Abschnitte zerlegt, als Embeddings in einer Vektordatenbank abgelegt und bei jeder Anfrage frisch durchsucht. Das Modell selbst bleibt unverändert.
Quellenangaben. Ein RAG-System kann zu jeder Antwort die Fundstelle nennen: Dokument, Abschnitt, Version. Für interne Freigaben und für Fachabteilungen, die einer KI-Antwort erst nach Prüfung trauen, ist das der Unterschied zwischen einem Spielzeug und einem Arbeitswerkzeug. Ein praktischer Nebeneffekt kommt dazu: Zugriffsrechte aus SharePoint oder dem DMS lassen sich auf den Index übertragen, sodass jede Person nur Antworten aus Dokumenten erhält, die sie auch selbst öffnen dürfte.
Löschbarkeit nach Art. 17 DSGVO. Verlangt eine Person die Löschung ihrer Daten, entfernen Sie das betreffende Dokument aus dem Index. Fertig. Bei einem Modell, das personenbezogene Daten im Training gesehen hat, gibt es diesen sauberen Weg nicht, denn die Information steckt in den Gewichten. Wie ein DSGVO-konformes Setup mit EU-Hosting aussieht, haben wir im Beitrag zum europäischen RAG-Setup beschrieben.
Schnelle Inhalts-Updates. Neue Produktdokumentation heute eingespielt, morgen in den Antworten. Kein Trainingslauf, keine Wartezeit auf GPU-Kapazität. In der Praxis heißt das: Die Fachabteilung pflegt ihre Dokumente wie gewohnt weiter, eine Pipeline synchronisiert den Index nachts oder direkt bei jeder Änderung.
Wofür Fine-Tuning gebaut ist
Fine-Tuning lohnt sich dort, wo das Modell anders arbeiten soll, als es von Haus aus tut.
Ton, Format und Stil. Sollen zehntausende Antworten exakt im Stil Ihres Serviceteams klingen, inklusive Anrede und Aufbau, lernt ein Modell das aus Beispielen zuverlässiger, als ein immer länger werdender Prompt es erzwingen kann.
Domänen-Terminologie. Fachsprache aus Maschinenbau, Labor oder Versicherung, die ein Basismodell falsch verwendet oder ins Englische abrutschen lässt, lässt sich antrainieren.
Strukturierte Ausgaben. Ein feinjustiertes Modell hält ein vorgegebenes JSON-Schema stabiler ein. Das senkt die Zahl der Fehler, die nachgelagerte Systeme wie ERP oder Ticketsystem abfangen müssen.
Latenz und Kosten. Ein kleines Modell mit 7 oder 8 Milliarden Parametern, per LoRA auf eine eng umrissene Aufgabe trainiert, antwortet schneller und günstiger als ein großes API-Modell. Bei hohem Anfragevolumen rechnet sich das.
Das häufigste Missverständnis
Der teuerste Irrtum in LLM-Projekten: Fine-Tuning als Methode, um Faktenwissen ins Modell zu bekommen. Der Wunsch klingt plausibel: "Wir trainieren das Modell auf unsere 10.000 Dokumente, dann kennt es unsere Firma." So funktioniert es leider nicht.
Drei Gründe. Erstens lagert Fine-Tuning Fakten unzuverlässig ein. Das Modell übernimmt Formulierungen und Muster, einzelne Fakten aber nur lückenhaft. Zweitens bleiben Halluzinationen bestehen. Nach dem Training klingen sie sogar überzeugender, weil das Modell die Firmenterminologie jetzt fließend beherrscht. Drittens veralten die Inhalte: Jede Preisänderung und jede neue Richtlinie erfordert einen neuen Trainingszyklus samt Datenaufbereitung und Evaluation.
Ein einfacher Test entlarvt den Irrtum. Fragen Sie ein feinjustiertes Modell nach einer Artikelnummer oder einem Termin aus den Trainingsdokumenten. Die Antwort kommt flüssig, stimmt aber häufig nicht, und ohne Quellenangabe fällt das erst auf, wenn der Fehler im Angebot beim Kunden liegt. Wer verlässlichen Zugriff auf Faktenwissen braucht, braucht Retrieval.
Sechs Kriterien für die Entscheidung
Für die Vorentscheidung genügt meist der Abgleich mit sechs Kriterien. Die Detailanalyse ersetzt das nicht, es sortiert aber die Diskussion:
| Kriterium | Spricht für RAG | Spricht für Fine-Tuning | |---|---|---| | Datenaktualität | Neue Dokumente sind nach dem Indexieren sofort verfügbar | Inhalte ändern sich selten, ein Trainingsstand pro Quartal genügt | | Nachvollziehbarkeit | Jede Antwort mit Quellenangabe auf Dokument und Abschnitt | Herkunft der Antwort ist zweitrangig, es zählt Form und Ton | | DSGVO-Löschbarkeit | Dokument aus dem Index entfernen genügt (Art. 17) | Personenbezug in Trainingsdaten lässt sich nachträglich kaum entfernen | | Team-Skills | Data Engineering: Pipelines, Vektordatenbank, Retrieval-Tuning | ML-Engineering: Trainingsdaten kuratieren, Hyperparameter, Evaluationssets | | Budgetprofil | Laufende Infrastrukturkosten für Hosting, Embeddings und Index | Trainingszyklen mit GPU-Kosten, dazwischen günstiger Betrieb | | Datenmenge | Funktioniert bereits ab einigen hundert Dokumenten | Braucht tausende saubere, geprüfte Beispielpaare |
Was ein RAG-System über den Lebenszyklus kostet, haben wir in einem eigenen Beitrag aufgeschlüsselt. Für die Werkzeugwahl auf der RAG-Seite lohnt der Blick auf unseren Vergleich von LlamaIndex, LangChain und Haystack.
Der Hybrid-Fall: kleines Modell plus RAG
Ein bewährtes Muster für hohe Lasten kombiniert beide Verfahren: ein kleines Modell, per LoRA auf Terminologie und Ausgabeformat feinjustiert, plus RAG für die Fakten. Das Modell liefert Ton und Struktur, der Retrieval-Schritt liefert aktuelles, belegbares Wissen.
Lohnend wird das, wenn mehrere Faktoren zusammenkommen: ein Anfragevolumen, bei dem die Token-Kosten großer API-Modelle spürbar werden; ein festes Ausgabeformat, das stabil eingehalten werden muss; oder die Vorgabe, das Modell on-premises beziehungsweise in einer EU-Cloud zu betreiben.
Als erster Schritt taugt der Hybrid selten. Bauen Sie zuerst ein RAG-System mit einem soliden Basismodell, messen Sie Qualität und Kosten im echten Betrieb und entscheiden Sie danach, ob ein Trainingszyklus die verbleibende Lücke schließt. Die Messdaten aus dem Betrieb sind zugleich die beste Grundlage für die Trainingsdaten.
Drei typische Fälle aus dem Mittelstand
Interner Wissensassistent. Handbücher, Verfahrensanweisungen, Verträge, Projektablagen: Hier gewinnt RAG in praktisch jeder Zeile der Tabelle. Die Inhalte ändern sich, die Antworten müssen belegbar sein, und die Datenmenge reicht selten für sinnvolles Training. Wie ein solches Projekt strukturiert abläuft, zeigt unser Beitrag zur RAG-Systemberatung im Mittelstand.
Antwortstil im Kundenservice. Beginnen Sie mit Prompting: eine präzise Stilvorgabe plus fünf bis zehn gute Beispielantworten direkt im Prompt. Das deckt erstaunlich viel ab. Fine-Tuning wird interessant, wenn der Stil über sehr viele Tickets hinweg konsistent bleiben muss und die langen Prompts selbst zum Kostenfaktor werden. Rechnen Sie dann allerdings den Kuratierungsaufwand ehrlich mit ein: Für ein brauchbares Stil-Training müssen tausende historische Antworten bereinigt werden, von Kundennamen über veraltete Produktaussagen bis zu schlicht schlechten Beispielen. Dieser Aufwand wird regelmäßig unterschätzt.
Extraktion aus Angeboten und Bestellungen. Positionen, Preise und Lieferzeiten aus PDF-Angeboten ins ERP übernehmen: Dafür braucht es in vielen Fällen weder RAG noch Fine-Tuning. Ein aktuelles Basismodell mit striktem JSON-Schema, Validierungsregeln und einem Beispiel im Prompt erledigt die Aufgabe oft zuverlässig. Diese Ehrlichkeit gehört zur Beratung dazu, denn ein Teil der angefragten LLM-Projekte braucht schlicht gutes Prompting statt neuer Infrastruktur.
Fazit
Zwei Fragen führen fast immer zur richtigen Architektur. Erstens: Muss die Anwendung auf Firmenwissen zugreifen, das sich ändert und belegbar sein soll? Dann RAG. Zweitens: Soll das Modell anders klingen, strenger formatieren oder mit kleinerer Hardware auskommen? Dann Fine-Tuning, nach einem ehrlichen Prompting-Versuch. Treffen beide Antworten zu, lohnt der Blick auf den Hybrid-Fall, allerdings erst ab spürbarem Volumen.
Die Architekturmuster hinter diesen Entscheidungen haben wir in unserem RAG-Playbook zusammengefasst. Wenn Sie Ihren konkreten Fall prüfen lassen wollen: Schildern Sie uns Ihr Vorhaben über den kostenlosen Check. Wir antworten innerhalb eines Werktags mit einer ersten Einschätzung.