Die Frage „Sollen wir RAG oder Fine-Tuning einsetzen?" ist die falsche Frage. Sie zwingt eine Architekturentscheidung in ein Entweder-oder, das es technisch gar nicht gibt. Die richtige Frage lautet: Wo soll die Intelligenz in Ihrem System leben — in den Gewichten des Modells, in externem, abrufbarem Wissen oder in den Anweisungen, die Sie dem Modell zur Laufzeit geben?
Diese drei Orte lösen drei verschiedene Probleme. Sie zu verwechseln ist der teuerste Fehler, den wir in DACH-Projekten immer wieder sehen — sechsstellige Budgets, die ein Problem mit dem falschen Werkzeug bearbeiten, während die einfache Lösung daneben ungenutzt liegt.
Drei Ansätze, drei Probleme
Prompt Engineering steuert das Verhalten über Anweisungen. Es verändert, wie das Modell antwortet, ohne zu verändern, was es weiß. System Prompts, Few-Shot-Beispiele, strukturierte Ausgabeschemata — schnell implementiert, ohne Trainingsinfrastruktur, sofort wirksam und sofort revidierbar. Für den Großteil der Aufgaben im Mittelstand ist das der richtige Startpunkt, nicht der Notbehelf.
Retrieval-Augmented Generation (RAG) gibt dem Modell zur Inferenzzeit Zugriff auf externes Wissen. Eine Retrieval-Pipeline holt relevante Passagen — meist aus einer Vektordatenbank, zunehmend hybrid mit klassischer Stichwortsuche kombiniert — und das Modell formuliert seine Antwort entlang dieser Belege. RAG löst das Wissensproblem: Ihre internen Richtlinien, Produktstammdaten, Vertragswerke, Prüfberichte existieren nicht in den Trainingsdaten eines Frontier-Modells. RAG macht sie zugänglich, ohne ein Gramm Gewicht anzufassen. Und es liefert etwas, das im DACH-Kontext keine Kür, sondern Pflicht ist: nachvollziehbare Quellen zu jeder Aussage.
Fine-Tuning verändert die Gewichte des Modells durch zusätzliches Training auf domänenspezifischen Daten. Es verschiebt das Verhalten — Tonalität, Ausgabeformat, Klassifikationsgrenzen, Fachvokabular. Fine-Tuning löst das Verhaltensproblem: Das Modell soll sich über tausende Interaktionen hinweg konsistent auf eine Weise verhalten, die sich durch Prompting nicht zuverlässig erzwingen lässt. Es bringt dem Modell nicht bei, was gilt, sondern wie es zu klingen und zu strukturieren hat.
Der entscheidende Satz: RAG fügt Wissen hinzu, Fine-Tuning formt Verhalten. Ein feinabgestimmtes Modell, das Ihre aktuelle Preisliste auswendig gelernt hat, ist in dem Moment falsch, in dem die Liste sich ändert — und es sagt Ihnen nicht, dass es falsch liegt.
Das Entscheidungsframework
Starten Sie mit Prompt Engineering. Erreicht es die geforderte Qualität nicht, stellen Sie genau eine Diagnosefrage: Ist die Lücke ein Wissensproblem oder ein Verhaltensproblem?
Wenn dem Modell Wissen fehlt, bauen Sie RAG. Compliance-Vorgaben, Produktdaten, Kundenhistorien, regulatorische Texte — nichts davon steckt in den Trainingsgewichten. RAG macht es zur Laufzeit verfügbar, ohne Nachtraining. Updates wirken sofort: Sie ändern das Dokument in der Wissensbasis, und die nächste Anfrage spiegelt den neuen Stand. Genau diese Eigenschaft — Wissen außerhalb des Modells, jederzeit austauschbar und auditierbar — ist der Grund, warum RAG in regulierten DACH-Branchen fast immer der erste ernsthafte Architekturschritt ist.
Wenn das Verhalten falsch ist, prüfen Sie Fine-Tuning. Das Modell versteht den Inhalt, liefert ihn aber im falschen Format, im falschen Ton oder mit inkonsistenten Klassifikationsentscheidungen. Fine-Tuning ist berechtigt, wenn das Modell verlässlich strukturierte Ausgaben in einem festen Schema erzeugen, eine konsistente Stimme über zehntausende Vorgänge halten oder Grenzfälle so klassifizieren soll, wie es Ihre Domäne — nicht das öffentliche Internet — definiert.
Wenn beides fehlt, kombinieren Sie beides. Die robusten Architekturen, die wir 2026 in Produktion sehen, kombinieren ein eher kleines, auf Verhalten feinabgestimmtes Modell mit RAG für das Wissen. Das feinabgestimmte Verhalten sorgt für Form, Ton und Schema; RAG liefert den jeweils aktuellen, zitierfähigen Inhalt. Das Ergebnis sind schnelle, markenkonforme, belegte Antworten zu spürbar niedrigeren Inferenzkosten als der Dauerbetrieb über ein großes Frontier-Modell.
Kosten und Komplexität — realistisch für den Mittelstand
Prompt Engineering kostet außer Engineering-Zeit praktisch nichts: keine Infrastruktur, keine Trainingsdaten, keine GPU-Stunden. Die Grenze ist die Zuverlässigkeit. Komplexes Verhalten lässt sich durch Prompts allein schwer stabil erzwingen, und lange System Prompts treiben im Skalierungsfall die Token-Kosten. Trotzdem: Wer diese Stufe überspringt, zahlt später doppelt.
RAG verlangt eine Retrieval-Pipeline, ein Embedding-Modell, einen Vektorspeicher und — der unterschätzte Teil — eine durchdachte Chunking- und Bewertungsstrategie. Ein belastbares Produktionssystem ist für ein eingespieltes Team realistisch in einigen Wochen statt Monaten machbar; die laufenden Kosten aus Embedding-Berechnung und Vektorspeicher bleiben für die meisten Mittelstands-Deployments moderat. Die eigentliche Schwierigkeit ist nicht, RAG zu bauen, sondern gutes RAG zu bauen. Erhebungen zu RAG-Fehlern zeigen ein wiederkehrendes Muster: Der häufigste Fehler ist das Retrieval, nicht die Generierung — das System zieht die falschen Passagen und das Modell formuliert darauf eine selbstbewusste, falsche Antwort. Und Retrieval beseitigt Halluzinationen nicht vollständig: In einer Untersuchung retrieval-gestützter juristischer Recherchewerkzeuge lagen die Halluzinationsraten je nach Tool bei bis zu rund einem Drittel der Antworten. Übersetzt für Ihren Kontext heißt das: RAG ohne Messung von Retrieval-Qualität ist kein Produktionssystem, sondern ein Demonstrator.
Fine-Tuning braucht kuratierte Trainingsdaten (in der Praxis hunderte bis tausende hochwertige Beispiele), GPU-Compute und eine Evaluations-Pipeline. Volles Fine-Tuning eines großen Modells ist teuer und riskiert Catastrophic Forgetting — das Modell gewinnt Domänenkönnen und verliert Allgemeinfähigkeiten. Parameter-effizientes Fine-Tuning ist der Weg, der den Mittelstand überhaupt erst handlungsfähig macht: Die ursprüngliche LoRA-Arbeit von Hu et al. friert die Gewichte des Basismodells ein und trainiert nur kleine, eingefügte Niedrigrang-Matrizen — und reduziert so die Zahl trainierbarer Parameter gegenüber vollem Fine-Tuning um bis zu vier Größenordnungen bei vergleichbarer oder besserer Qualität. Für die allermeisten Enterprise-Fälle erreicht oder übertrifft dieser Ansatz volles Fine-Tuning, zu einem Bruchteil der Compute-Kosten.
Der DACH-Zusatzfaktor: Nachvollziehbarkeit ist Architektur, nicht Beiwerk
In der DACH-Region wird die Architekturwahl nicht nur durch Kosten und Qualität entschieden, sondern durch Nachweisbarkeit. Die EU-KI-Verordnung verlangt von Anbietern allgemeiner KI-Modelle technische Dokumentation und stellt für viele Systeme Transparenzpflichten auf — unter anderem die maschinenlesbare Kennzeichnung KI-generierter Inhalte und die Offenlegung, dass Nutzer mit einem KI-System interagieren; die zugehörige Transparenz-Phase greift im Verlauf 2026. Wer in Geschäftsprozessen einsetzt, muss jederzeit zeigen können, warum das System geantwortet hat, wie es geantwortet hat.
Hier trennt sich die Architektur. RAG liefert von Natur aus eine Belegkette: Jede Aussage lässt sich auf das abgerufene Dokument zurückführen, das Dokument auf seinen Stand, der Stand auf eine Freigabe. Ein rein feinabgestimmtes Modell kann das nicht — das Wissen ist in den Gewichten zu nicht mehr trennbarem Nebel verrechnet, eine Quelle gibt es nicht. Für regulierte Prozesse im Mittelstand ist das oft das ausschlaggebende Argument: nicht die Antwortqualität im Demo, sondern die Frage, ob Sie die Antwort vor einem Prüfer verteidigen können.
Wo DACH-Unternehmen falsch abbiegen
Drei Muster sehen wir immer wieder.
Fine-Tuning, wo RAG genügt hätte. Ein Haus trainiert über Monate ein Modell auf seine Compliance-Dokumentation. Ein RAG-System über dieselben Dokumente, in einem Bruchteil der Zeit gebaut, hätte bessere und vor allem aktuelle Antworten geliefert — denn die Regeln ändern sich laufend, und das feinabgestimmte Modell hängt ohne erneutes Training jedem Update hinterher. Sobald sich Ihr Wissen schneller ändert als Ihr Trainingszyklus, ist Fine-Tuning das falsche Werkzeug.
RAG ohne Investition in Datenqualität. RAG ist nur so gut wie die Dokumente, die es abruft. Veraltete Richtlinien, widersprüchliche Versionen, unstrukturierte PDFs — und das System ruft zuverlässig Unsinn ab und gießt ihn in flüssige Sätze. Der Löwenanteil des Aufwands einer ernsthaften RAG-Einführung steckt nicht im Modell, sondern in der Aufbereitung, Versionierung und Strukturierung der Wissensbasis. Wer hier spart, baut eine Maschine, die schneller Fehler produziert.
Prompt Engineering komplett überspringen. Teams springen direkt auf RAG oder Fine-Tuning, bevor sie geprüft haben, was ein sauber gebauter Prompt leistet. Ein strukturierter System Prompt mit klarer Rolle, festem Ausgabeschema und einer Handvoll Beispielen macht den teureren Ansatz häufig schlicht überflüssig — oder klärt zumindest, welches Problem überhaupt zu lösen ist.
Die richtige Architekturentscheidung treffen
Die Entscheidung ist keine Einbahnstraße. Starten Sie mit Prompt Engineering. Reicht die Qualität nicht, ergänzen Sie RAG für die Wissenslücken. Bleibt danach die Verhaltenskonsistenz ein Problem, ergänzen Sie ein feinabgestimmtes, kleineres Modell für genau diese Anforderung. Jede Schicht erhöht Kosten, Komplexität und Wartungslast — fügen Sie sie erst hinzu, wenn die vorherige nachweislich, gemessen, nicht ausreicht.
Die Organisationen, die die wirksamsten KI-Systeme betreiben, sind nicht die mit den ausgefeiltesten Techniken. Es sind die, die die einfachste Technik einsetzen, die das Problem zuverlässig löst — und die genug messen, um zu wissen, wann das nicht mehr stimmt.
Ein Fit Call bestimmt die richtige Architektur für Ihre konkreten Use Cases — bevor ein sechsstelliges Budget in das falsche Werkzeug fließt. Wir helfen DACH-Unternehmen bei der Wahl zwischen Prompt Engineering, RAG und Fine-Tuning — entlang Ihrer Daten, Ihrer Workloads, Ihrer Compliance-Randbedingungen und der Nachweispflichten, die für Sie gelten.
Referenzen: Hu et al., „LoRA: Low-Rank Adaptation of Large Language Models", arXiv:2106.09685, 2021 (arxiv.org/abs/2106.09685); Europäische Kommission, „AI Act — Regulatory framework for AI" (digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai); EU AI Act, Artikel 50 — Transparency Obligations (artificialintelligenceact.eu/article/50/).