2/3+190 XP

Build vs buy: RAG vs Fine-tuning

2023 richtete ein mittelgroßer europäischer Versicherer ein GenAI "Center of Excellence" ein und steckte 4 Mio. € in das Fine-tuning eines Open-Weight-Modells auf seiner Schadenhistorie. Achtzehn Monate später wurde das fine-getunte Modell still und leise abgeschaltet. Das Problem war nicht das Modell, sondern dass sich die Schadenrichtlinien quartalsweise änderten und jede Änderung einen Retraining-Zyklus erforderte, den sie sich nicht leisten konnten. Ein dreiwöchiger RAG-Pilot, gebaut von zwei Engineers, trug am Ende die Produktionslast. Die 4 Mio. € haben ihnen eine teure Lektion erkauft: Sie hatten ein Problem der Wissensaktualität mit einem Werkzeug zur Verhaltensformung gelöst.

Das ist die folgenreichste und am häufigsten missverstandene Build-Entscheidung, die Sie in Enterprise-GenAI treffen werden. Das Anbieter-Ökosystem hat finanzielle Anreize, Ihnen die schwerste Option zu verkaufen. Ihre Aufgabe ist es, den Mechanismus auf das tatsächliche Problem abzustimmen und zu erkennen, wann die Antwort lautet: "keines davon, schreiben Sie einfach einen besseren Prompt".

Die drei Mechanismen und was jeder tatsächlich verändert

Nimmt man das Marketing weg, bleiben drei Hebel, geordnet nach Kosten und Komplexität.

Prompting verändert, was Sie das Modell im Moment *fragen*. Sie liefern Anweisungen, Beispiele und Constraints im Context Window. Am Modell selbst ändert sich nichts. Das ist Ihr Default, und es ist mächtiger, als die meisten Führungskräfte annehmen: Moderne Frontier-Modelle mit einem gut gebauten System-Prompt und einigen In-Context-Beispielen ("few-shot") lösen einen überraschend großen Anteil der Enterprise-Use-Cases direkt.

Retrieval-Augmented Generation (RAG) verändert, was das Modell zur Inferenzzeit *weiß*. Sie rufen relevante Dokumente aus Ihrem eigenen Korpus ab, fügen sie in den Prompt ein, und das Modell argumentiert darüber. Die Gewichte des Modells bleiben unangetastet; Sie liefern ihm bei Bedarf frischen, proprietären Kontext.

Fine-tuning verändert, wie sich das Modell *verhält*: seinen Default-Tonfall, das Format, die Struktur und die aufgabenspezifischen Instinkte. Sie trainieren das Basismodell auf kuratierten Beispielen weiter, sodass diese Muster in die Gewichte eingebacken werden.

Die nützlichste Formulierung, die Sie in jedes Architektur-Review mitnehmen können, ist diese:

> RAG gibt dem Modell Wissen. Fine-tuning gibt dem Modell Fähigkeiten. Prompting steuert das Wissen und die Fähigkeiten, die es bereits hat.

Der Fehler des Versicherers ist in dieser Sprache offensichtlich. Ihr Problem war *Wissen, das sich ändert*, also ein RAG-Problem. Sie griffen zum Fine-tuning, einem Werkzeug für *Fähigkeiten und Verhalten*, und erbten eine Retraining-Tretmühle für Informationen, die in einem abfragbaren Index hätten leben sollen.

Der Entscheidungstest

Wenn ein Use Case auf Ihrem Tisch landet, prüfen Sie ihn anhand von drei Fragen in dieser Reihenfolge:

1. Schafft es ein starker Prompt? Wenn ein gut gebauter System-Prompt plus 3-5 Beispiele akzeptable Qualität liefert, hören Sie auf. Sie sind fertig. Ausliefern.

2. Braucht die Aufgabe proprietäres oder frisches Wissen, das das Modell nicht hat? Wenn ja, ist das RAG. Denken Sie an: "antworte aus unseren aktuellen Policy-Dokumenten", "zitiere unsere Verträge", "beziehe dich auf den Produktkatalog dieses Quartals".

3. Braucht die Aufgabe ein konsistentes Verhalten, Format oder eine spezialisierte Fähigkeit, die Prompting nicht zuverlässig erzwingen kann? Wenn ja, ist das Fine-tuning. Denken Sie an: "gib immer valides JSON in unserem Schema aus", "übernimm das spezifische Schreibregister unserer Marke", "klassifiziere Support-Tickets mit hoher Konsistenz in unsere 40 internen Kategorien".

Der größte Teil des Enterprise-GenAI-Werts in 2024-2025 liegt auf Stufe 1 und 2. Fine-tuning ist real und wertvoll, aber es ist das *letzte* Werkzeug, zu dem Sie greifen, nicht das erste, und ganz wichtig: RAG und Fine-tuning schließen sich nicht gegenseitig aus. Die ausgereiftesten Produktionssysteme machen Fine-tuning für das Verhalten *und* nutzen RAG für das Wissen.

RAG: der Default für Unternehmenswissen

RAG ist aus einem Grund zum Arbeitspferd geworden: Unternehmen versinken in proprietären Texten, Verträgen, Richtlinien, Tickets, Wikis, Research, die kein Basismodell je gesehen hat und die sich ständig ändern. RAG erlaubt Ihnen, diesen Korpus dem Modell zugänglich zu machen, ohne Retraining, ohne Daten in die Gewichte eines Dritten zu verschieben, und mit der Möglichkeit, nahezu in Echtzeit zu aktualisieren.

Aber "wir machen einfach RAG" ist der Punkt, an dem die meisten Programme still scheitern, denn der schwierige Teil ist nicht das LLM, es ist das Retrieval. Ein CDO sollte einen RAG-Vorschlag in drei Dimensionen hinterfragen:

Chunking- und Retrieval-Qualität. Wie wird der Korpus geteilt, indexiert und durchsucht? Naives Chunking mit fixer Größe zerstört Kontext; ein in der Mitte durchgeschnittener Absatz liefert Müll. Das ist ein Data-Engineering-Problem, das Sie bereits kennen, es ist ETL für unstrukturierten Text. Die Qualität Ihrer Antworten ist durch die Qualität Ihres Retrievals begrenzt, Punkt.

Grounding und Quellenangaben. Kann das System zeigen, *welche Quelle* jede Aussage erzeugt hat? Für ein reguliertes Unternehmen ist eine nicht belegte Antwort ein Risiko, kein Feature. Bestehen Sie darauf, dass das Retrieval Quellenreferenzen zurückgibt, die das Modell zitieren muss.

Aktualität und Zugriffskontrolle. Wer darf welche Dokumente sehen? RAG muss Ihre bestehenden Berechtigungen respektieren; ein Retrieval-System, das einem Junior-Analysten HR-Gehaltsdaten liefert, weil "sie im Index waren", ist ein Governance-Vorfall mit Ansage. Ihre Zugriffskontrollen müssen auf der Retrieval-Ebene leben, nicht nachträglich angeschraubt werden.

Ein nützliches Denkmodell für die Retrieval-Pipeline:

query → embed → vector search (filtered by user's access rights)
      → rerank top-k → assemble context + citations
      → LLM generates grounded answer

Die unglamouröse Wahrheit: 80 % des RAG-Engineering-Aufwands liegen im Retrieval und in der Datenpipeline, nicht im Modell. Das ist eine gute Nachricht für einen CDO, denn es ist weitgehend eine Disziplin, die Ihre Organisation schon hat. Die Teams, die mit RAG gewinnen, sind die, die es als Search- und Datenqualitätsproblem behandelt haben, nicht als KI-Problem.

RAG vs Fine-Tuning: A Practical Guide

Watch on YouTube

Wann RAG Over-Engineering ist

Wenn Ihre Wissensbasis klein und stabil ist und bequem in das Context Window eines modernen Modells passt, brauchen Sie möglicherweise überhaupt kein Retrieval-System, Sie können die relevanten Dokumente einfach in den Prompt legen. Eine Vector-Datenbank, eine Embedding-Pipeline und einen Reranker aufzusetzen, um ein 30-seitiges Mitarbeiterhandbuch zu bedienen, das sich zweimal im Jahr ändert, ist Infrastruktur-Theater. Passen Sie die Maschinerie an die Größenordnung an.

Fine-tuning: mächtig, eng und häufig falsch eingesetzt

Fine-tuning verdient seinen Platz in genau drei Situationen, und Sie sollten jedem Vorschlag skeptisch gegenüberstehen, der nicht klar in eine davon fällt:

1. Verhalten und Format, die Sie nicht zuverlässig prompten können. Wenn Sie brauchen, dass das Modell *immer* Output in einer strikten Struktur produziert, eine konsistente Stimme übernimmt oder einer Domänenkonvention folgt, die kein Prompting im Maßstab erzwingt. Fine-tuning backt das Muster ein.

2. Latenz und Kosten bei hohem Volumen. Ein fine-getuntes kleineres Modell kann die Qualität eines großen Modells bei einer *engen* Aufgabe erreichen und dabei pro Call dramatisch günstiger und schneller sein. Bei Millionen Calls pro Tag dominiert diese Rechnung. Sie tauschen Vorab-Trainingskosten und Starrheit gegen Effizienz pro Inferenz.

3. Eine spezialisierte Fähigkeit oder Klassifikation, die das Basismodell schlecht beherrscht. Stark domänenspezifische Aufgaben, medizinische Kodierung, Klassifikation von Vertragsklauseln, Nischensprachen, bei denen das allgemeine Training des Basismodells einfach nicht reicht.

Wofür Fine-tuning *nicht* taugt: dem Modell Fakten beizubringen. Das ist das teuerste Missverständnis der Branche. Fine-tuning ist ein schlechter und unzuverlässiger Weg, Wissen einzuspeisen; das Modell merkt sich vielleicht einen Teil, halluziniert an den Rändern, und Sie müssen bei jeder Faktenänderung neu trainieren. Das ist ein Job für RAG. Jedes Mal.

Die parameter-effiziente Realität

Modernes Fine-tuning bedeutet selten, das ganze Modell neu zu trainieren. Techniken wie LoRA (Low-Rank Adaptation) trainieren eine kleine Menge von Adapter-Gewichten auf einem eingefrorenen Basismodell, senken die Kosten um Größenordnungen und erlauben es, mehrere aufgabenspezifische Adapter über einer Basis zu pflegen. Wenn ein Anbieter oder Team "Fine-tuning" vorschlägt, ist Ihre erste Frage: *Full Fine-tune oder parameter-effizient?* Wenn ein Full Fine-tune eines großen Modells für eine enge Aufgabe vorgeschlagen wird, ist das meist ein Warnsignal für Over-Engineering.

Die Ökonomie, die für einen CDO wirklich zählt:

|---|---|---|---|

Beachten Sie die Zeile zur Auditierbarkeit. In einem regulierten Umfeld ist die Fähigkeit von RAG, Quellen zu zitieren, keine technische Nettigkeit, sie ist oft das, was den Einsatz gegenüber Ihren Risk- und Compliance-Funktionen vertretbar macht. Die Argumentation eines fine-getunten Modells steckt in Gewichten, die Sie nicht inspizieren können.

Wissenscheck

1. Was verändert Retrieval-Augmented Generation (RAG) gemäß der Kernformulierung der Lektion in erster Linie an einem Modell?

2. Der Versicherer in der Fallstudie hat einen teuren Fehler gemacht. Worin bestand dieser Fehler in der Sprache der Lektion?

3. Warum beschreibt die Lektion Prompting als die sinnvolle "Default"-Wahl, bevor man RAG oder Fine-tuning erwägt?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE Aussagen, die die Unterscheidung der drei Mechanismen gemäß der Lektion korrekt wiedergeben.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE Szenarien, in denen Fine-tuning gemäß der Argumentation der Lektion der passende Mechanismus ist.

Wählen Sie alle richtigen Antworten aus.

Die Entscheidung am Montagmorgen

So übersetzt sich das in Governance, die Sie tatsächlich betreiben können.

Etablieren Sie ein "Prompt-first"-Mandat. Verlangen Sie von jedem GenAI-Use-Case den Nachweis, dass Prompting allein nicht ausreicht, *bevor* Sie RAG-Budget freigeben, und dass RAG nicht ausreicht, bevor Sie Fine-tuning-Ausgaben genehmigen. Diese eine Regel erspart Ihnen den 4-Mio.-€-Fehler des Versicherers. Lassen Sie Teams sich den Weg nach oben auf der Komplexitätsleiter verdienen.

Trennen Sie das Wissensproblem vom Verhaltensproblem, explizit, schriftlich. Zwingen Sie das Team, für jeden Use Case einen Satz zu schreiben: "Hier muss das Modell X *wissen* und sich wie Y *verhalten*." In dem Moment, in dem Sie es so zerlegen, wählt sich die Architektur selbst. Wissen → RAG. Verhalten → Fine-tuning. Beides → beides.

Behandeln Sie RAG als Datenprodukt, nicht als KI-Projekt. Es sollte unter demselben Governance-, Lineage- und Zugriffskontrollregime stehen wie Ihre anderen Datenprodukte. Der Retrieval-Index erbt die Berechtigungen der zugrunde liegenden Quellen, das können Sie längst. Der Failure Mode sind Teams, die Shadow-Indexe bauen, die Ihre Governance komplett umgehen.

Budgetieren Sie Fine-tuning als Optimierung, nicht als Fundament. Die richtige Reihenfolge für die meisten wertvollen Produkte ist: Wert mit Prompting + RAG beweisen, Kosten und Latenz in Produktion messen, *dann* ein kleineres Modell fine-tunen, um die Kosten pro Call zu drücken, sobald das Volumen es rechtfertigt. Fine-tuning als erster Schritt ist Spekulation; Fine-tuning als Optimierung einer bewährten Workload ist solides Engineering.

Achten Sie auf die Total Cost of Ownership, nicht auf die Demo. Die Kosten des Fine-tunings sind nicht der Trainingslauf, sondern die Retraining-Tretmühle, die MLOps für Versionierung und Evaluierung der Adapter und die organisatorische Muskulatur, um Evaluierungsdatensätze zu pflegen. Die Kosten von RAG sind nicht die Vector-Datenbank, sondern die laufende Hygiene der Datenpipeline. Verlangen Sie von Anbietern und internen Teams eine Modellierung der Kosten über *18 Monate*, inklusive Wartung, nicht die des Piloten.

Der strategische Punkt: Der Markt wird Sie weiter zum komplexesten, teuersten Mechanismus drängen, weil dort die Margen liegen. Ihr Vorteil als CDO ist die Disziplin, zu fragen "was braucht dieser Use Case tatsächlich?" und ihn auf den günstigsten Mechanismus zu routen, der die Messlatte erfüllt. Meistens ist das ein guter Prompt über solidem Retrieval, und das zu wissen ist mehr wert als jedes einzelne Modell.

Key Takeaways

1. Führen Sie jeden Use Case über die Leiter: erst Prompt, dann RAG, dann Fine-tuning, und lassen Sie Teams jede Stufe verdienen. Ein "Prompt-first"-Mandat ist die Governance-Regel mit dem höchsten ROI, die Sie einführen können.

2. Lösen Sie nie ein Wissensproblem mit Fine-tuning. Frische, proprietäre oder sich ändernde Informationen gehören in eine RAG-Retrieval-Ebene. Fine-tuning ist für Verhalten, Format und spezialisierte Fähigkeiten, nicht für Fakten.

3. Behandeln Sie RAG als Datenprodukt unter Ihrer bestehenden Governance. 80 % des Aufwands liegen in Retrieval- und Pipeline-Qualität; Zugriffskontrollen müssen auf der Retrieval-Ebene leben, und jede Antwort sollte ihre Quelle zitieren, damit sie auditierbar ist.

4. Budgetieren Sie Fine-tuning als Kosten-/Latenz-Optimierung einer bewährten Workload und fordern Sie standardmäßig parameter-effiziente Methoden (LoRA), nicht als spekulativen ersten Schritt oder als vollständiges Retraining eines großen Modells für eine enge Aufgabe.

5. Bewerten Sie nach Total Cost of Ownership über 18 Monate, nicht nach der Demo. Die Retraining-Tretmühle und die Pipeline-Hygiene sind die Stellen, an denen Budgets sterben, modellieren Sie die Wartung, nicht nur den Build.

Was Sie aus dieser Lektion umsetzen

Diese Maßnahmen sind im Playbook der Rolle zusammengefasst.

Jeden Use Case über die Stufenfolge Prompt, dann RAG, dann Fine-Tuning führen
KI-Unit-Economics von Tag eins an für den Produktionsmaßstab modellieren

Vollständiges Action Playbook ansehen →