Jeder will KI anpassen. Nur wenige verstehen ihre Optionen.

Du hast Unternehmensdokumente, die das Modell nie gesehen hat, einen bestimmten Schreibstil, den es ignoriert, oder Fachwissen, das ständig halluziniert wird – und du willst KI, die in deiner Situation wirklich funktioniert, statt generische Ausgaben zu produzieren, die am Ziel vorbeigehen.

Es gibt drei Wege nach vorn: Prompting, RAG und Feintuning. Die Branche behandelt sie wie eine Leiter, auf der man von simpel zu anspruchsvoll klettert. Aber dieses Bild führt zu teuren Fehlentscheidungen, weil jeder Ansatz grundlegend andere Probleme löst – und wer nach gefühlter Komplexität statt nach tatsächlicher Passung auswählt, verschwendet Zeit und Geld.

Die unbequeme Wahrheit über Feintuning

Fangen wir mit der Option an, die am eindrucksvollsten klingt.

Feintuning verändert das Modell selbst. Du gibst Beispiele für Eingaben und gewünschte Ausgaben, und der Trainingsprozess passt die internen Gewichte des Modells so an, dass es diese Art von Ausgabe zuverlässiger produziert – im Grunde bringt man dem Modell neue Verhaltensweisen bei, indem man es immer wieder mit deinen spezifischen Mustern konfrontiert.

Das klingt mächtig. Ist es auch.

Aber fast nie das, was du brauchst.

Auf Hacker News brachte intellectronica es auf den Punkt: “Fine-tuning is super important and powerful…in reality for most use cases it offers little advantage for a lot of effort.” Diese Einschätzung bestätigt sich immer wieder in realen Einsätzen: Teams verbringen Monate damit, Trainingsdaten vorzubereiten – nur um dann festzustellen, dass gute Prompts das Problem an einem Nachmittag gelöst hätten.

Der Irrtum sitzt tief. Viele glauben, Feintuning bringe dem Modell neue Fakten bei, so wie Lernen Menschen Wissen vermittelt. Aber dvt auf Hacker News widersprach direkt: “It does not teach the model new knowledge.” Feintuning ändert Verhalten und Stil, nicht das zugrunde liegende Wissen, auf das das Modell zugreifen kann. Heißt: Wenn dein Problem ist, dass das Modell deine Produkte oder Richtlinien nicht kennt, wird Feintuning das nicht reparieren.

Wo Feintuning glänzt, ist Konsistenz. Wenn du ein Modell brauchst, das jedes Mal perfekt formatiertes JSON ausgibt, oder über Tausende Interaktionen exakt denselben Ton hält, oder eine enge Aufgabe mit maschinenhafter Zuverlässigkeit erledigt, liefert Feintuning, was Prompts nicht können.

Die Kosten machen diese Entscheidung ernst. Trainingsläufe reichen von ein paar Hundert Dollar für kleine Modelle bis zu Zehntausenden für alles, was wirklich Substanz hat. Die Datenaufbereitung verdoppelt die Gesamtinvestition oft, weil du hochwertige Beispiele im exakten Format brauchst, das die Trainingspipeline erwartet. Und wenn sich deine Anforderungen ändern? Dann trainierst du erneut.

Warum RAG meistens gewinnt

Hier ist, was die meisten Teams tatsächlich brauchen: KI, die deine Inhalte kennt.

RAG funktioniert anders. Statt das Modell zu verändern, baust du ein Abrufsystem, das relevante Dokumente findet, wenn jemand etwas fragt. Dann nimmst du diese Dokumente in den Prompt auf, damit das Modell die Informationen hat, die es braucht, um korrekt zu antworten.

Das Modell bleibt generisch. Das Wissen bleibt extern.

Dieser Unterschied ist enorm. Wenn sich deine Produktdokumentation ändert, aktualisierst du die Dokumente – und RAG nutzt die neuen Informationen sofort. Kein erneutes Training. Kein Data-Science-Team nötig. Einfach Dateien aktualisieren.

Ein Praktiker auf Hacker News beschrieb den Kompromiss so: “RAG is focused more on capturing and using external resources on an ad hoc basis, where fine tuning looks to embed a specific ‘behaviour’ change in the model for a particular need.” Das trifft es genau. RAG kümmert sich um das Was. Feintuning um das Wie.

Auch das Transparenz-Argument ist stark. Wenn RAG eine Antwort liefert, kannst du sie auf konkrete Quelldokumente zurückführen. Das heißt: Du kannst Antworten prüfen, Halluzinationen entdecken und Nutzern genau zeigen, woher eine Information kommt. Feingetunte Modelle bieten keine solche Belegspur.

Kostenvergleiche sprechen klar für RAG. Der Aufbau einer Vektordatenbank und einer Embedding-Pipeline kostet bei typischen Umsetzungen $200 bis $2.000 pro Monat. Ein Produktionsmodell sauber zu feintunen kostet das allein an Trainingsrechenzeit – bevor du Datenaufbereitung und laufende Pflege überhaupt mitzählst.

RAG hat aber Grenzen. Es braucht relevante Dokumente, die überhaupt existieren. Der Abrufschritt sorgt für zusätzliche Verzögerung. Lange Dokumente sprengen Kontextfenster. Und vor allem: RAG kann nicht ändern, wie das Modell schlussfolgert oder schreibt.

Prompting ist nicht die Einsteiger-Option

Prompting als Stufe eins auf einer Leiter abzutun, unterschätzt seine tatsächliche Stärke.

Prompt-Engineering heißt, Anweisungen zu formulieren, die das Modellverhalten lenken, ohne irgendetwas Externes zu verändern. Du arbeitest komplett innerhalb des Gesprächs. Keine Infrastruktur. Keine Trainingsdaten. Keine Vektordatenbanken.

Klingt simpel. Das ist die Falle.

Gutes Prompt-Engineering umfasst strukturierte Denkrahmen, Few-shot-Beispiele, die exakte Muster vorführen, Schritt-für-Schritt-Aufschlüsselungen für komplexe Aufgaben und eine präzise Festlegung von Grenzen, die Ausgaben formt, ohne dass du explizite Regeln hinschreibst. Teams, die Prompting als grundlegend abtun, haben oft nicht ausgelotet, was möglich ist, wenn man wirklich Arbeit hineinsteckt.

adamgordonbell teilte eine bezeichnende Erfahrung: “When I first wanted to tackle a hard problem I thought to reach for fine-tuning with lots of input and output pairs, but it wasn’t needed.” Dieses Muster wiederholt sich ständig. Ingenieure nehmen an, Komplexität erfordere komplexe Lösungen – und stellen dann fest, dass gute Prompts das Problem eleganter lösen.

Die Kostenstruktur macht Prompting zu einer ernsthaften Option. Stunden an Prompt-Iteration kosten nichts außer Abo-Gebühren. Wenn du ein Problem allein mit Prompts lösen kannst, sparst du dir Infrastruktur komplett. Das heißt: schnellere Iterationszyklen, einfachere Pflege und weniger Risiko, wenn sich Anforderungen ändern.

Die Grenze ist trotzdem real. Prompts können Verhalten nur innerhalb dessen formen, was das Modell grundsätzlich schon kann. Du kannst ein Modell nicht per Prompt dazu bringen, Konzepte zu verstehen, denen es im Training nie begegnet ist. Und du kannst dich nicht zu Informationen prompten, die das Modell nicht hat.

Die Entscheidung, auf die es wirklich ankommt

Hör auf zu fragen, was am besten ist. Frag, was dein tatsächliches Problem ist.

Das Modell liefert falsche Fakten über dein Unternehmen, deine Produkte oder aktuelle Ereignisse. Das ist ein Wissensproblem. RAG löst Wissensprobleme, indem es dem Modell zur Anfragezeit die Informationen gibt, die ihm fehlen.

Das Modell kennt die richtigen Informationen, aber es produziert Ausgaben in falschen Formaten, falschen Stilen oder mit schwankender Qualität über viele Interaktionen hinweg. Das ist ein Verhaltensproblem. Feintuning löst Verhaltensprobleme, indem es anpasst, wie das Modell Antworten erzeugt.

Das Modell könnte tun, was du willst, aber es tut es nicht, weil deine Anweisungen nicht klar genug sind. Das ist ein Anweisungsproblem. Prompt-Engineering löst Anweisungsprobleme, indem es innerhalb des Gesprächs bessere Führung gibt.

Die meisten Teams werfen diese Kategorien durcheinander. Sie haben ein Wissensproblem und glauben, Feintuning würde neues Wissen beibringen. Sie haben ein Anweisungsproblem und glauben, RAG würde Anweisungen liefern. Die Lösung an das echte Problem anzupassen, spart Monate verschwendeter Arbeit.

Der gefährliche Mittelweg

Manchmal überlappt das Problem. Du brauchst Unternehmenswissen UND konsistente Formatierung UND bestimmte Denkmuster.

Hier entstehen Kombinationsarchitekturen. RAG liefert aktuelle Informationen. Feintuning sorgt für eine konsistente Ausgabestruktur. Prompts geben anfrage-spezifische Führung. Alle drei zusammen.

phillipcarter auf Hacker News warnte vor falschen Dichotomien: “Fine-tuning doesn’t eliminate the need for RAG, and RAG doesn’t obviate the need for fine-tuning either.”

Aber Kombinationen vervielfachen Komplexität. Drei Systeme, die gepflegt werden müssen. Drei mögliche Fehlerquellen. Drei Kostenblöcke. Bau Kombinationen nur, wenn einzelne Ansätze nachweislich scheitern – nicht als Absicherung gegen hypothetische Probleme.

Die stärksten KI-Teams behandeln das als Routing-Logik. Einfache Anfragen laufen nur über Prompts. Wissensintensive Anfragen aktivieren RAG. Hochwertige, formatkritische Operationen laufen über feingetunte Modelle. Das System selbst entscheidet, welchen Weg jede Anfrage nimmt.

Diese Architektur erfordert spürbar Entwicklungsaufwand. Die meisten Teams brauchen sie nicht. Die meisten Teams müssen einen Ansatz wählen und ihn gut umsetzen.

Was der Markt auf die harte Tour gelernt hat

Frühe KI-Einsätze in Unternehmen setzten standardmäßig auf Feintuning, weil es substantieller wirkte, sich in Vorstandsfolien besser verkaufen ließ und offensichtlicher „anders“ war als einfach ChatGPT zu nutzen. Diese Vorhaben blieben oft in der Datenaufbereitung stecken – Phasen, die sich über Monate zogen.

solidasparagus fasste die praktische Realität so zusammen: “collecting data and then fine-tuning models is orders of magnitude more complex than just throwing in RAG.”

Die Komplexität ist nicht nur technisch. Feintuning verlangt kuratierte Datensätze, die deinen Anwendungsfall sauber abbilden. Das heißt: festlegen, wie „gute“ Ausgaben aussehen, genügend Beispiele sammeln, sie korrekt formatieren und prüfen, dass der Trainingssatz keine Fehler enthält, die sich ins Modell fortpflanzen. RAG erfordert, Dokumente hochzuladen, die du wahrscheinlich ohnehin schon hast.

Das heißt nicht, dass Feintuning nie richtig ist. Unternehmen, die täglich Millionen ähnlicher Anfragen bearbeiten, können kleinere Modelle feintunen, die schneller und günstiger laufen als große Universalmodelle. Spezialisierte Bereiche mit eigener Terminologie und besonderen Denkmustern brauchen manchmal Verhaltensänderungen, die Prompts nicht erreichen. Und latenzkritische Anwendungen profitieren von kleineren feingetunten Modellen gegenüber größeren, die nur per Prompt gelenkt werden.

Aber die Hürde ist hoch. Du brauchst Volumen, um die Investition zu rechtfertigen. Du brauchst klare Verhaltensanforderungen, die sich nicht ständig ändern. Du brauchst hochwertige Trainingsdaten oder das Budget, sie zu erstellen. Und du brauchst Geduld für einen Iterationszyklus, der in Wochen statt in Stunden gemessen wird.

Die unterschätzte Option

Für viele Geschäftsanwendungen ist die Antwort einfacher als all das.

Nutze das Modell so, wie es ist, mit ordentlichen Prompts. Akzeptiere etwas Unschärfe. Liefere aus.

Die Jagd nach perfekter KI-Anpassung verzögert echten Nutzen. Teams verbringen Monate mit RAG-Architekturen, obwohl eine Prompt-Vorlage und manuelle Prüfung ihren Nutzern kurzfristig besser dienen würden.

Das heißt nicht, dass man sich dauerhaft damit abfindet. Es heißt, richtig zu sequenzieren: Erst mit einfachen Ansätzen beweisen, dass das Konzept funktioniert, dann durch echte Nutzung konkrete Lücken identifizieren und anschließend in die Anpassung investieren, die genau diese Lücken schließt.

Mit Feintuning zu starten, bevor du den Anwendungsfall validiert hast, ist wie Code zu optimieren, bevor du weißt, ob es der richtige Code ist. Der Aufwand kann auf ein Problem gehen, das gar nicht existiert – oder sich verschiebt, sobald du mehr über echte Nutzerbedürfnisse lernst.

Praktische Einstiegspunkte

Wenn dein Problem Wissen ist, starte mit RAG. Bring deine Dokumente in einen Vektorspeicher, baue den Abruf in deine Prompts ein und prüfe, ob das Modell korrekte Antworten liefert, wenn es die richtigen Informationen verfügbar hat.

Wenn dein Problem Konsistenz ist, starte mit detaillierten Prompts inklusive Beispielen. Zeig dem Modell mit kommentierten Mustern exakt, was du willst. Die meisten Konsistenzprobleme lassen sich mit Few-shot-Prompting lösen, bevor Feintuning nötig wird.

Wenn dein Problem Fähigkeit ist – also dass das Modell die Aufgabe grundsätzlich nicht kann – dann hinterfrage, ob KI überhaupt die richtige Lösung ist. Feintuning kann Fähigkeiten am Rand erweitern, aber es kann ein Sprachmodell nicht in etwas verwandeln, wofür es nicht gebaut wurde.

Wenn du nicht sicher bist, was dein Problem ist, dann ist das dein eigentliches Problem. Nimm dir Zeit, Fehlschläge zu klassifizieren, bevor du in Lösungen investierst. Sprich mit Nutzern. Schau dir die schlechten Ausgaben an. Verstehe konkret, was schiefging und warum, bevor du entscheidest, wie du es behebst.

Teams, die mit KI-Anpassung erfolgreich sind, haben eine Gemeinsamkeit: Sie definieren das Problem präzise, bevor sie eine Lösung auswählen. Dann validieren sie ihre Wahl mit minimalem Einsatz, bevor sie den Ansatz in der Organisation breit ausrollen.

Teams, die scheitern, springen zu Lösungen, die nach Raffinesse klingen, ohne das Problem gut genug zu verstehen, um zu wissen, ob diese zusätzliche Komplexität überhaupt nötig ist.

Starte einfach. Füge Komplexität nur hinzu, wenn einfach nachweislich nicht reicht.

Das ist kein aufregender Rat. Aber er funktioniert.