RAG vs Fine-Tuning vs Prompting: das CTO-Entscheidungs-Framework 2026

Der teuerste Satz in jeder CTO-Runde 2026: "Wir muessen unser eigenes Modell fine-tunen." In 8 von 10 Faellen ist das die falsche Antwort auf die richtige Frage. Die richtige Frage lautet fast immer: Wie bringen wir aktuelles Firmenwissen, konsistenten Output und nachvollziehbare Quellen in eine LLM-Anwendung, ohne ein MLOps-Team aufzubauen, das wir uns nicht leisten wollen. Fine-Tuning ist eine valide Antwort auf einen schmalen Teil dieser Frage. Es ist selten der erste Griff, und im DACH-Mittelstand ist es 2026 fast nie der zweite. Dieser Post ist das Entscheidungs-Framework, das wir in 40 Workshops gegen die Realitaet getestet haben: drei Hebel, ein Decision-Tree, vier teure Anti-Pattern.

Die 3 Hebel auf einer Seite

Drei Hebel decken praktisch jeden LLM-Use-Case ab, den ein Mittelstaendler 2026 baut. Sie sind nicht alternativ, sie sind gestaffelt: Prompting ist immer dabei, RAG kommt dazu, wenn Wissen ins Spiel kommt, Fine-Tuning ist die Ausnahme am Ende. Die Tabelle als Orientierung, bevor wir die Hebel einzeln aufmachen:

Hebel	Was es loest	Aufwand	Kosten-Pattern	Daten-Bedarf	Wann sinnvoll
Prompting + Context	Verhalten, Format-Richtung, einfache Aufgaben mit gegebenem Kontext	Tage	Inferenz pro Token, keine Fixkosten	Keiner (oder wenige Beispiele)	Immer zuerst, oft ausreichend
RAG	Aktuelles und firmenspezifisches Wissen, Quellen-Nachvollziehbarkeit, grosse Doc-Bestaende	Wochen	Inferenz plus Vector-Store plus Embedding-Kosten	Dokumente, kein Labeling	Wissen aendert sich oder ist gross, Quellen-Pflicht
Fine-Tuning	Output-Format-Konsistenz, Ton, Domain-Vokabular, Latenz und Kosten bei hohem Volumen	Monate	Training plus Re-Training plus MLOps, dann guenstigere Inferenz	Hunderte bis Tausende gelabelte Beispiele	Format oder Volumen-Problem nach RAG-Plateau

Der wichtigste Satz zur Tabelle: Die Spalte "Was es loest" ueberlappt sich weniger, als die meisten denken. Fine-Tuning loest kein Wissens-Problem, und RAG loest kein Format-Problem. Wer das verwechselt, kauft den falschen Hebel.

Hebel 1: Prompting plus Context-Engineering

Prompting ist 2026 kein Anfaenger-Thema mehr, sondern eine Engineering-Disziplin. Mit System-Prompts, Few-Shot-Beispielen, strukturiertem Output (JSON-Schema, Tool-Calling) und langen Context-Windows loest du einen erstaunlich grossen Teil dessen, was vor zwei Jahren nach Fine-Tuning aussah.

Der grosse Hebel der letzten 18 Monate sind die Context-Windows. Stand Mai 2026 arbeiten die produktiv eingesetzten Frontier-Modelle in Groessenordnungen von rund 100.000 bis ueber eine Million Token Context (Groessenordnung, Stand Mai 2026, je nach Modell und Tier). Das aendert die Architektur-Frage fundamental: Wenn dein gesamter relevanter Kontext (ein Vertrag, ein Handbuch-Kapitel, die letzten 50 Support-Tickets) in den Context passt, brauchst du fuer diesen Fall weder RAG noch Fine-Tuning. Du legst die Daten in den Prompt und arbeitest mit ihnen.

Wann Prompting reicht: Die Aufgabe ist klar definiert, der noetige Kontext ist begrenzt und kann mitgegeben werden, und du brauchst keine harte Garantie auf ein exaktes Output-Format ueber Millionen Calls. Das deckt Recherche-Assistenten, Drafting, Klassifikation auf gegebenen Texten, Zusammenfassungen und die meisten internen Produktivitaets-Use-Cases ab. Wenn dein Use-Case hier landet, ist jede Diskussion ueber Fine-Tuning verfrueht.

Wann Prompting nicht mehr reicht: Wenn der Kontext groesser ist als das Context-Window oder so gross, dass die Inferenz-Kosten pro Call explodieren. Wenn das Wissen sich staendig aendert und du nicht jeden Call mit dem aktuellen Stand fuettern kannst. Genau hier beginnt RAG.

Hebel 2: RAG (Retrieval-Augmented Generation)

RAG ist 2026 der mit Abstand am haeufigsten unterschaetzte Hebel im Mittelstand. Die Idee: Statt das Wissen ins Modell zu trainieren, holst du zur Laufzeit die relevanten Wissens-Schnipsel und gibst sie dem Modell als Kontext mit. Das Modell bleibt unveraendert, das Wissen lebt ausserhalb.

Die Architektur in vier Schritten. Erstens Embedding: Du zerlegst deine Dokumente in Chunks und wandelst jeden Chunk in einen Vektor um. Zweitens Vector-Store: Die Vektoren landen in einer Datenbank, die Aehnlichkeitssuche kann (eine dedizierte Vector-DB oder Postgres mit pgvector). Drittens Retrieval: Zur Laufzeit wird die Nutzer-Anfrage ebenfalls embedded, die naechstgelegenen Chunks werden geholt. Viertens Re-Ranking: Ein zweites, praeziseres Modell sortiert die Treffer nach echter Relevanz, bevor die Top-Chunks in den Prompt wandern. Der vierte Schritt ist der, den die meisten weglassen, und genau der entscheidet ueber die Antwort-Qualitaet.

Wann RAG das richtige Werkzeug ist: Dein Wissen aendert sich (Produktdoku, Preise, Richtlinien), oder es ist zu gross fuer jedes Context-Window (zehntausende Dokumente), oder du brauchst Quellen-Nachvollziehbarkeit ("Diese Antwort stammt aus Dokument X, Abschnitt Y"). Der letzte Punkt ist im regulierten Mittelstand oft das Killer-Argument: RAG kann zitieren, Fine-Tuning nicht. Ein fine-getuntes Modell sagt dir nicht, woher es eine Antwort hat. Genau diese Nachvollziehbarkeit ist auch der Punkt, an dem Datenschutz und Governance haengen: Wer Quellen ausweisen kann, kann auch Loeschpflichten, Zugriffsrechte und Audit-Trails sauber abbilden, und genau das verlangt eine produktive Anwendung im DACH-Mittelstand. Die rechtliche Seite davon steht im DSGVO-Agentic-AI-Production-Post.

Ein Detail, das in der Architektur-Diskussion oft untergeht: RAG haelt deine Daten ausserhalb des Modells, und das ist auch eine Datenschutz-Eigenschaft, kein Zufall. Bei den grossen Anbietern bleibt deine Eingabe in der Default-Konfiguration vom Training getrennt (Claude default no-training, ChatGPT mit Trainings-Toggle default off in Business und Enterprise, Gemini opt-in mit default off im Enterprise-Tier). Bei einem Fine-Tune dagegen wandert dein Datensatz definitionsgemaess ins Modell. Wer mit sensiblen Firmendaten arbeitet, sollte diesen Unterschied bewusst treffen, nicht aus Versehen.

Die typischen Fehler, die wir in Workshops sehen. Erstens naives Chunking: feste Token-Grenzen quer durch Saetze und Tabellen, statt an semantischen Grenzen zu schneiden. Schlechtes Chunking ruiniert das Retrieval, bevor das Modell ueberhaupt etwas sieht. Zweitens kein Re-Ranking: reine Vektor-Aehnlichkeit holt oft thematisch nahe, aber faktisch falsche Chunks. Drittens kein Eval: Teams bauen RAG, finden es "fuehlt sich gut an" und haben keine Messung, ob es bei 1.000 echten Fragen die richtigen Quellen findet. Ohne Eval-Harness ist RAG-Tuning Raten. Wer den Schritt von Pilot zu Production gehen will, sollte die 5 Architekturfehler im Mittelstand kennen, denn fehlendes Eval ist dort einer der teuersten.

Hebel 3: Fine-Tuning

Fine-Tuning hat einen Marketing-Vorsprung, der mit der technischen Realitaet wenig zu tun hat. Was Fine-Tuning wirklich loest: Output-Format-Konsistenz ueber sehr viele Calls (das Modell haelt ein striktes Schema zuverlaessiger ein), Ton und Stil (eine konsistente Marken- oder Domain-Stimme), Domain-Vokabular (Fachbegriffe, die das Basismodell falsch interpretiert) und in hohen Volumina Latenz und Kosten (ein kleineres, fine-getuntes Modell kann ein grosses Modell mit langem Prompt ersetzen und ist pro Call guenstiger).

Was Fine-Tuning nicht loest, und hier liegt der teuerste Irrtum: aktuelles Wissen und Faktentreue. Du kannst ein Modell auf deine Produktdoku fine-tunen, und es wird trotzdem halluzinieren, weil Fine-Tuning Verhalten und Muster lernt, kein Faktenwissen zuverlaessig speichert. Sobald sich die Doku aendert, ist dein Fine-Tune veraltet, und du trainierst neu. Genau dieses Wissens-Problem loest RAG sauberer und billiger.

Die Kosten-Realitaet. Ein ernsthafter Fine-Tune eines Open-Source-Modells liegt 2026 in der Groessenordnung von rund 80.000 bis 250.000 EUR Projektkosten (Sentient-Dynamics-Workshop-Aggregat, Groessenordnung), plus laufende Re-Training-Kosten bei jeder Datenaenderung, plus GPU-Inferenz-Kosten, plus ein MLOps-Setup, das jemand betreiben muss. Bei Managed-Fine-Tuning ueber einen Anbieter (OpenAI, Google) sind die direkten Trainings-Kosten niedriger, aber du handelst dir Vendor-Bindung ein und das Daten- und Faktentreue-Problem bleibt. Deshalb ist Fine-Tuning selten der erste Griff: Es ist die teuerste Option mit dem schmalsten Problem-Bereich.

Es gibt einen Fall, in dem Fine-Tuning sich klar rechnet, und es lohnt sich, ihn praezise zu benennen, damit die Diskussion nicht ideologisch wird. Wenn du ein sehr hohes, gleichfoermiges Inferenz-Volumen hast (Millionen aehnlich strukturierter Calls pro Monat), und ein kleines, fine-getuntes Modell ein grosses Frontier-Modell mit langem System-Prompt ersetzen kann, dann kippt die Kosten-Rechnung. Das gesparte Token-Budget pro Call multipliziert sich ueber das Volumen, und ab einem bestimmten Punkt amortisiert sich das Trainings-Investment. Das ist eine echte, rechenbare Entscheidung, kein Hype. Der Punkt: Dieser Fall tritt im DACH-Mittelstand selten ein, und wenn, dann erst, nachdem RAG plus Prompting die Anwendung ueberhaupt produktiv gemacht haben. Fine-Tuning als Volumen-Optimierung ist legitim, Fine-Tuning als Wissens-Strategie ist es nicht.

Das Entscheidungs-Framework

Der Decision-Tree ist bewusst einfach, weil er in der Hektik einer CTO-Runde funktionieren muss.

Start immer bei Prompting. Baue die Anwendung mit System-Prompt, Few-Shot und strukturiertem Output. Miss, ob das die Aufgabe loest. In ueberraschend vielen Faellen ist hier Schluss, und das ist ein Erfolg, kein Mangel.

Reicht Prompting nicht, weil Wissen fehlt, sich aendert oder zu gross ist, oder weil du Quellen brauchst: Dann RAG. RAG ist der Default-Hebel fuer alles, was nach "das Modell muss unsere Dokumente kennen" klingt. Investiere in sauberes Chunking, Re-Ranking und eine Eval-Harness, nicht in mehr Modell.

Fine-Tuning kommt erst, wenn du auf einem RAG-Plateau sitzt und ein klar benanntes Rest-Problem hast: Das Output-Format ist trotz Prompting nicht stabil genug, oder dein Volumen ist so hoch, dass Latenz und Kosten zum Engpass werden. Dann, und nur dann, ist Fine-Tuning der richtige naechste Schritt.

Der Normalfall ist hybrid. Die meisten produktiven Mittelstands-Anwendungen 2026 sind RAG plus leichtes Prompting-Tuning, ohne jeden eigenen Fine-Tune. Wer doch fine-tuned, kombiniert es fast immer mit RAG: Das Fine-Tune liefert Format und Ton, RAG liefert die Fakten. Entweder-oder ist die falsche Frage, die Reihenfolge ist die richtige.

Kosten-Realitaet aus 40 DACH-Workshops

Die folgenden Groessenordnungen sind anonymisierte Aggregate aus 40 Sentient-Dynamics-Workshops zwischen Sommer 2025 und Mai 2026, Mitarbeiterzahl 80 bis 4.000 (Sentient-Dynamics-Workshop-Aggregat, Groessenordnungen):

Prompting-Iteration: Tage. Eine Prompting-Loesung fuer einen klar umrissenen Use-Case ist eine Sache von Tagen bis wenigen Wochen, mit minimalen Fixkosten. Die laufenden Kosten sind reine Inferenz pro Token. Das ist der Grund, warum Prompting immer der erste Versuch sein sollte: Der Lerneffekt ist billig.

RAG-PoC: 4 bis 8 Wochen. Ein belastbarer RAG-Proof-of-Concept mit Chunking, Vector-Store, Retrieval, Re-Ranking und einer ersten Eval-Harness liegt in dieser Spanne. Die laufenden Kosten sind Inferenz plus Vector-Store-Betrieb plus Embedding-Kosten, alle drei moderat und gut planbar. Das ist die Kategorie mit dem besten Verhaeltnis aus Aufwand und produktivem Ergebnis.

Fine-Tuning-Projekt: 3 bis 6 Monate. Ein ernsthaftes Fine-Tuning-Projekt mit Daten-Sammlung, Labeling, Training, Eval und Deployment liegt in dieser Spanne, plus laufende Re-Training-Kosten bei jeder relevanten Datenaenderung. Das ist keine Tool-Entscheidung mehr, das ist eine Headcount- und Kapital-Allokations-Entscheidung. Wer diese Groessenordnung gegen das erwartete Ergebnis stellt, kommt im Mittelstand fast immer zum Schluss, dass RAG plus Prompting denselben Geschaeftswert frueher liefert. Die volle Rechnung ueber 12 Monate steht im TCO-Post.

4 Anti-Pattern, die CTOs 2026 Geld kosten

Fine-Tuning ohne Eval-Harness. Wer fine-tuned, ohne vorher eine messbare Eval gegen ein realistisches Testset zu haben, weiss nach Monaten Arbeit nicht, ob das Modell besser geworden ist. "Fuehlt sich besser an" ist kein Akzeptanzkriterium. Die Eval-Harness ist die Voraussetzung, nicht das Extra. Das gilt fuer alle drei Hebel, beim teuersten am haertesten.

RAG ohne Re-Ranking. Reine Vektor-Aehnlichkeit ohne Re-Ranking-Schritt liefert thematisch nahe, oft faktisch falsche Treffer. Teams wundern sich dann, warum ihr RAG "manchmal Quatsch erzaehlt", und der Fix sitzt nicht im Modell, sondern in der Retrieval-Pipeline. Re-Ranking ist der billigste grosse Qualitaetssprung in RAG.

Kein Versionierungs-Konzept fuer Prompts. Prompts sind 2026 Code. Wer sie in Vendor-UIs pflegt, ohne Versionierung, ohne Diff, ohne Eval-Anbindung, baut technische Schulden auf, die niemand sieht, bis ein Prompt-Change still die Antwort-Qualitaet verschiebt. Prompts gehoeren in ein Repository (Markdown oder YAML), nicht in ein Web-Formular.

Vendor-Fine-Tune-Lock-in. Ein Fine-Tune bei einem Managed-Anbieter ist nicht portabel. Das Modell, die Gewichte und das Format gehoeren faktisch in das Oekosystem des Anbieters. Wer dort sechsstellig investiert, hat den Wechsel-Aufwand massiv erhoeht. Das ist eine der teuersten Lock-in-Fallen, ausfuehrlich im Vendor-Lock-in-Post. Wer den ganzen Strauss vermeidbarer Fehler sehen will, findet ihn im Ueberblick zu den Anti-Pattern hinter 40 Prozent gescheiterten Projekten.

FAQ

Brauchen wir eine dedizierte Vector-DB oder reicht Postgres mit pgvector?

Fuer den Start reicht Postgres mit pgvector in den allermeisten Mittelstands-Faellen. Wenn du ohnehin Postgres betreibst, ist das die pragmatische Wahl: ein System weniger, gute Integration, ausreichend Performance bis in den Bereich von Millionen Vektoren. Eine dedizierte Vector-DB lohnt sich erst, wenn du sehr hohe Query-Volumina, sehr grosse Indizes oder spezielle Filter- und Hybrid-Search-Anforderungen hast. Erst die Anforderung beweisen, dann das Spezial-System kaufen.

Was kostet Fine-Tuning realistisch?

Self-hosted Fine-Tune eines Open-Source-Modells: Groessenordnung 80.000 bis 250.000 EUR Projektkosten plus laufende Re-Training- und GPU-Kosten plus MLOps-Betrieb (Sentient-Dynamics-Workshop-Aggregat, Groessenordnung). Managed-Fine-Tuning ueber einen Anbieter ist in den direkten Trainings-Kosten guenstiger, dafuer kommt Vendor-Bindung dazu, und das Faktentreue-Problem bleibt ungeloest. In beiden Faellen gilt: Rechne die laufenden Re-Training-Kosten mit, nicht nur das erste Training.

Wann lohnt sich ein eigenes Embedding-Modell?

Selten und spaet. Managed-Embeddings (von den grossen Anbietern) sind 2026 fuer fast jeden Mittelstands-Use-Case gut genug und guenstig. Ein eigenes oder fine-getuntes Embedding-Modell lohnt sich erst, wenn du eine sehr spezielle Domain mit Fachvokabular hast, bei der die generischen Embeddings messbar schlechter retrieven, und du das mit einer Eval beweisen kannst. Ohne diesen Eval-Beweis ist es vorzeitige Optimierung.

Open-Source vs Managed-Embeddings?

Managed-Embeddings beim Start, weil sie ohne Infrastruktur-Aufwand laufen und die Qualitaet hoch ist. Open-Source-Embeddings (lokal gehostet) werden interessant bei sehr hohen Volumina, bei denen die Embedding-Kosten pro Million Dokumente ins Gewicht fallen, oder bei strikten Datenresidenz-Anforderungen, die keinen externen Embedding-Call erlauben. Auch hier: erst die Anforderung beweisen, dann self-hosten.

Wie passt das in eine Engineering-Roadmap?

Genau in der Reihenfolge des Decision-Trees: Prompting im Pilot, RAG in der ersten Production-Welle, Fine-Tuning nur als spaete Optimierung mit klarem Rest-Problem. Wie sich das in Phasen von Pilot zu Production sortiert, steht in der 5-Phasen-Roadmap fuer Engineering-Teams. Welche Aufgaben die Modelle dabei realistisch tragen und welche nicht, klaert der Post zu dem, was AI-Agents heute nicht koennen. Und warum so viele Piloten genau an dieser Stelle stecken bleiben, zeigt der Pilot-Friedhof.

---

Sources:

• Sentient-Dynamics-Workshop-Aggregate, 40 DACH-Workshops 2025-2026 (Mitarbeiterzahl 80 bis 4.000; Kosten- und Dauer-Groessenordnungen)
• Bitkom KI-Studie 2025 (deutsche Unternehmen mit 20+ MA: 41 Prozent Adoption; deutsche Unternehmen ab 500 MA: 89 Prozent Adoption)
• McKinsey State of AI, November 2025
• MIT NANDA Report 2025: "GenAI Divide: State of AI in Business 2025"
• Anthropic Terms 2025 (default no-training on user prompts)
• OpenAI Business / Enterprise Settings 2025/2026 (Trainings-Toggle default off)
• Google Workspace Gemini Enterprise Tier Settings 2025/2026 (default off)

Naechster Schritt: Wenn du fuer einen konkreten Use-Case entscheiden willst, ob Prompting, RAG oder Fine-Tuning der richtige Hebel ist, buch dir 30 Minuten ueber unsere Demo-Seite. Wir bringen den Decision-Tree, die 40-Workshop-Aggregation und drei Fragen, kein Vendor-Deck. Wer parallel die Tool-Landschaft drumherum sortieren will, findet sie in der KI-Tools-Landschaft 2026, und wer den Coding-Teil seines Stacks vergleicht, im Coding-Agent-Vergleich.