Build vs. buy: RAG vs. Fine-tuning

2023 stellte ein mittelgroßererDas Verhältnis von Interaktionen (Likes, Kommentare, Shares) zur Reichweite eines Inhalts. Zeigt, wie stark die Zielgruppe reagiert, gemessen an der Zahl der Personen, die den Inhalt gesehen haben.Vollständige Definition ansehen → europäischer Versicherer ein GenAI-"Center of Excellence" auf die Beine und steckte 4 Mio. € in das Fine-tuningFine-tuningFine-Tuning passt ein vortrainiertes Modell an eine bestimmte Aufgabe oder Domäne an, indem das Training auf einem kleineren, gezielten Datensatz fortgesetzt wird. Das verbessert Genauigkeit und Stil für den jeweiligen Anwendungsfall.Vollständige Definition ansehen → 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 vierteljährlich änderten und jede Änderung einen Retraining-Zyklus erforderte, den sie sich nicht leisten konnten. Ein dreiwöchiger RAGRAGVerfahren, mit dem ein KI-Modell aus Ihren eigenen Dokumenten antwortet, indem es relevante Passagen abruft, bevor es eine Antwort erzeugt.Vollständige Definition ansehen →-Pilot, gebaut von zwei Engineers, trug am Ende die Produktionslast. Die 4 Mio. € haben ihnen eine teure Lektion gekauft: sie hatten ein Problem der Wissensaktualität mit einem Werkzeug zur Verhaltensformung gelöst.

Das ist die folgenreichste und meist missverstandene Build-Entscheidung, die Sie im 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: "nichts davon, schreiben Sie einfach einen besseren Prompt."

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

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

PromptingPromptingPrompt Engineering ist die Praxis, Texteingaben so zu gestalten und zu verfeinern, dass große Sprachmodelle präzise, relevante und verlässliche Ergebnisse liefern.Vollständige Definition ansehen → verändert, was Sie das Modell im Moment *fragen*. Sie liefern Anweisungen, Beispiele und Constraints im Context WindowContext WindowDas Context Window ist die maximale Textmenge (gemessen in Tokens), die ein Sprachmodell auf einmal verarbeiten kann, einschließlich Input-Prompt und generiertem Output.Vollständige Definition ansehen →. Am Modell selbst ändert sich nichts. Das ist Ihr Default, und er ist mächtiger, als die meisten Führungskräfte annehmen: moderne Frontier-Modelle mit einem gut konstruierten System-Prompt und einigen In-Context-Beispielen ("few-shot") lösen einen überraschend großen Anteil an Enterprise-Use-Cases direkt.

Retrieval-Augmented Generation (RAG) verändert, was das Modell zur Inferenzzeit *weiß*. Sie holen relevante Dokumente aus Ihrem eigenen Korpus, fügen sie in den Prompt ein, und das Modell schlussfolgert darüber. Die Gewichte des Modells bleiben unangetastet; Sie füttern es bei Bedarf mit frischem, proprietärem Kontext.

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

Die nützlichste Formel, die Sie in jedes Architektur-Review mitnehmen kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen, ist diese:

RAG gibt dem Modell Wissen. Fine-tuning gibt dem Modell Skills. Prompting steuert das Wissen und die Skills, die es schon hat.

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

Der Entscheidungstest

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

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. Shippen Sie es.
2. Erfordert die Aufgabe proprietäres oder frisches Wissen, das das Modell nicht hat? Wenn ja, ist das RAG. Denken Sie an: "antworte aus unseren aktuellen Richtliniendokumenten", "zitiere unsere Verträge", "verweise auf den Produktkatalog dieses Quartals".
3. Erfordert die Aufgabe ein konsistentes Verhalten, Format oder einen spezialisierten Skill, den Prompting nicht zuverlässig erzwingen kann? Wenn ja, ist das Fine-tuning. Denken Sie an: "gib immer valides JSON in unserem SchemaSchemaEin Schema ist der formale Bauplan, der festlegt, wie Daten in einer Datenbank, einer Datei oder einer Nachricht strukturiert, benannt, typisiert und miteinander verknüpft sind.Vollständige Definition ansehen → aus", "übernimm das spezifische Schreibregister unserer Marke", "klassifiziere Support-Tickets mit hoher Konsistenz in unsere 40 internen Kategorien".

Der Großteil des Enterprise-GenAI-Werts 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 entscheidend: RAG und Fine-tuning schließen sich nicht gegenseitig aus. Die ausgefeiltesten Produktionssysteme tunen für Verhalten *und* nutzen RAG für Wissen.

RAG: der Default für Enterprise-Wissen

RAG ist aus einem Grund zum Arbeitspferd geworden: Unternehmen ertrinken in proprietärem Text, Verträge, Richtlinien, Tickets, Wikis, Research, den kein Basismodell je gesehen hat und der sich ständig ändert. RAG erlaubt Ihnen, diesen Korpus dem Modell zugänglich zu machen, ohne Retraining, ohne Daten in fremde Gewichte 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 das Schwierige 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 zerlegt, indexiert und durchsucht? Naives Chunking mit fester Größe zerstört Kontext; ein halbierter Absatz liefert Müll. Das ist ein Data-Engineering-Problem, das Sie bereits kennen, es ist ETLETLETL (Extract, Transform, Load) ist ein Datenintegrationsprozess, der Daten aus Quellsystemen extrahiert, in ein konsistentes Format bringt und in ein Zielsystem schreibt.Vollständige Definition ansehen → für unstrukturierten Text. Die Qualität Ihrer Antworten ist durch die Qualität Ihres Retrievals begrenzt, Punkt.

Grounding und Zitation. 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 Quellverweise 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 Analyst HR-Gehaltsdaten ausspielt, weil "es im Index lag", ist ein Governance-Vorfall mit Anlauf. Ihre Zugriffskontrollen müssen auf der Retrieval-Ebene leben, nicht nachträglich angeschraubt werden.

Ein nützliches Mental Model 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 in Retrieval und Datenpipeline, nicht im Modell. Das ist eine gute Nachricht für einen CDO, denn es ist größtenteils eine Disziplin, die Ihre Organisation schon hat. Die Teams, die bei RAG gewinnen, sind die, die es als Such- und Datenqualitätsproblem behandelt haben, nicht als KI-Problem.

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 aufnehmen. 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 fehlgenutzt

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, das Sie nicht zuverlässig prompten können. Wenn das Modell *immer* Output in einer strikten Struktur liefern, eine konsistente Stimme übernehmen oder eine Fachkonvention einhalten soll, die kein Prompting im Maßstab erzwingt. Fine-tuning brennt 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 ist dabei pro Call dramatisch günstiger und schneller. Bei Millionen Calls pro Tag dominiert diese Rechnung. Sie tauschen Vorabtrainingskosten und Rigidität gegen Effizienz pro Inferenz.

3. Ein spezialisierter Skill oder eine Klassifikation, die das Basismodell schlecht beherrscht. Hochgradig 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 der teuerste Irrglaube der Branche. Fine-tuning ist ein schlechter und unzuverlässiger Weg, Wissen einzuspeisen, das Modell merkt sich vielleicht etwas davon, halluziniert an den Rändern, und Sie müssen bei jeder Faktenänderung neu trainieren. Das ist ein RAG-Job. 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 einen kleinen Satz Adapter-Gewichte über einem eingefrorenen Basismodell, senken die Kosten um Größenordnungen und erlauben Ihnen, 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 tatsächlich zählt:

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

Die Entscheidung am Montagmorgen

So lässt sich das in Governance übersetzen, 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 freigeben. Diese eine Policy erspart Ihnen den 4-Mio.-€-Fehler des Versicherers. Lassen Sie Teams sich die Komplexitätsleiter erarbeiten.

Trennen Sie das Wissensproblem vom Verhaltensproblem, explizit und 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*." Sobald Sie es so zerlegen, wählt sich die Architektur selbst. Wissen → RAG. Verhalten → Fine-tuning. Beides → beides.

Behandeln Sie RAG als Data Product, nicht als KI-Projekt. Es sollte unter demselben Governance-, Lineage- und Zugriffskontroll-Regime laufen wie Ihre anderen Data Products. Der Retrieval-Index erbt die Berechtigungen der zugrunde liegenden Quellen, das können Sie schon. Der Failure Mode sind Teams, die Shadow-Indizes bauen und Ihre Governance komplett umgehen.

Budgetieren Sie Fine-tuning als Optimierung, nicht als Fundament. Die richtige Reihenfolge für die meisten hochwertigen 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 senken, 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, das MLOps zum Versionieren und Evaluieren von Adaptern und die organisatorische Muskulatur, um Evaluations-Datensätze zu pflegen. Die Kosten von RAG sind nicht die Vector-Datenbank, sondern die laufende Hygiene der Datenpipeline. Lassen Sie Anbieter und interne Teams die *18-Monats*-Kosten inklusive Wartung modellieren, nicht den 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 erfordert dieser Use Case tatsächlich?" und ihn an den günstigsten Mechanismus zu leiten, der die Latte erreicht. Meistens ist das ein guter Prompt über solidem Retrieval, und das zu wissen ist mehr wert als jedes einzelne Modell.

Key Takeaways

1. Leiten Sie jeden Use Case über die Leiter, Prompt, dann RAG, dann Fine-tuning, und verlangen Sie von Teams, sich jede Sprosse zu verdienen. Ein "Prompt-first"-Mandat ist die Governance-Policy mit dem höchsten ROI, die Sie einführen können.
2. Lösen Sie ein Wissensproblem nie 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 Skills, nicht für Fakten.
3. Behandeln Sie RAG als Data Product unter Ihrer bestehenden Governance. 80 % des Aufwands sind Retrieval- und Pipeline-Qualität; Zugriffskontrollen müssen auf der Retrieval-Ebene liegen, 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 verlangen Sie standardmäßig parameter-effiziente Methoden (LoRA), nicht als spekulativen ersten Schritt oder Full Retrain eines großen Modells für eine enge Aufgabe.
5. Bewerten Sie auf Basis der Total Cost of Ownership über 18 Monate, nicht der Demo. An der Retraining-Tretmühle und der Pipeline-Hygiene sterben Budgets, modellieren Sie die Wartung, nicht nur den Build.