Wenn ein Unternehmen sein eigenes Wissen in ein Sprachmodell bringen muss —seinen Katalog, seine Handbücher, seinen Ticket-Verlauf— kommt fast immer dieselbe Diskussion auf: RAG, Fine-Tuning oder einfach alles in den Kontext packen? Das Gespräch dreht sich meist um die Qualität: Welches antwortet besser, welches halluziniert weniger, welches ist leichter zu pflegen.
Das ist die falsche Frage zum Anfang. In den meisten Projekten, die wir sehen, bricht die Entscheidung nicht an der Qualität —alle drei können eine akzeptable Qualität liefern— sondern an den Kosten pro Aufgabe. Und dort verhalten sich die drei Optionen je nach Volumen radikal unterschiedlich. Die, die in der Demo am günstigsten wirkt, wird im Produktivbetrieb zur teuersten, und umgekehrt.
Die drei Optionen, in einem Satz zu den Kosten
Langer Kontext. Sie packen das relevante Wissen bei jeder Anfrage direkt in den Prompt. Null Infrastruktur, null Vorbereitung. Aber Sie bezahlen diese Tokens jedes Mal, wenn Sie fragen. Es ist das „das ganze Handbuch kopieren und einfügen” vor jeder Anfrage.
RAG (retrieval-augmentierte Generierung). Statt das gesamte Wissen zu schicken, holt ein Suchsystem nur die für jede Anfrage relevanten Fragmente, und diese —und nur diese— reisen im Prompt mit. Der Kontext pro Anfrage bleibt klein. Im Gegenzug bauen und pflegen Sie eine Pipeline: die Dokumente zerlegen, Embeddings erzeugen, eine Vektordatenbank, die Retrieval-Logik.
Fine-Tuning. Sie passen das Modell selbst mit Ihren Daten an. Sie zahlen im Voraus Trainingskosten, aber danach lebt das Wissen (oder der Stil, oder das Format) im Modell, sodass der Prompt bei jeder Anfrage viel kürzer sein kann: Sie müssen keine Anweisungen und Beispiele mehr mitschicken.
Wo jede bezahlt wird
Der Schlüssel ist, Einrichtungskosten (einmalig) von Kosten pro Aufgabe (jede Anfrage, für immer) zu trennen. Es ist dieselbe Logik wie bei den Kosten pro Aufgabe: Was Ihr Budget versenkt, ist nicht der Listenpreis, sondern das, was Sie mit Ihrem monatlichen Volumen multiplizieren.
Langer Kontext hat nahezu keine Einrichtungskosten und die höchsten Kosten pro Aufgabe der drei. Wenn Sie bei jeder Anfrage 8.000 Tokens Handbuch mitschleppen und hunderttausend Anfragen im Monat lösen, haben Sie dieses Handbuch hunderttausendmal bezahlt. Billig aufzusetzen, teuer im Betrieb.
Fine-Tuning kehrt die Aufteilung um: hohe Einrichtungskosten (den Datensatz vorbereiten, trainieren, und jedes Mal neu trainieren, wenn sich das Wissen ändert), aber die niedrigsten Kosten pro Aufgabe, weil der Prompt schlank wird. Es ist die Option „einmal viel zahlen, um viele Male wenig zu zahlen”.
RAG liegt in beiden Dimensionen in der Mitte: eine moderate Einrichtung (die Retrieval-Pipeline) und niedrige Kosten pro Aufgabe, weil Sie nur die nötigen Fragmente schicken, nicht alles. Es hat zudem einen Kostenpunkt, den die anderen beiden nicht so deutlich zeigen: Jede Anfrage bezahlt auch das Retrieval (Embedding der Frage, Suche in der Vektordatenbank), auch wenn das gegenüber der Ersparnis bei den Modell-Tokens meist klein ist.
Ein Beispiel mit Zahlen
Nehmen wir eine Aufgabe, die sich auf eine Wissensbasis stützen muss. Antwort mit 300 Tokens in allen drei Fällen. Beispielhafte Preise von 2 $ pro Million Eingabe und 12 $ pro Million Ausgabe.
| Ansatz | Eingabe-Tokens pro Aufgabe | Kosten pro Aufgabe |
|---|---|---|
| Langer Kontext (ganzes Handbuch) | 8.000 | 0,0196 $ |
| RAG (nur relevante Fragmente) | 1.500 | 0,0066 $ |
| Fine-Tuning (minimaler Prompt) | 500 | 0,0046 $ |
Auf den ersten Blick gewinnt Fine-Tuning. Aber es fehlt die andere Hälfte. Bei tausend Aufgaben im Monat beträgt der Unterschied zwischen langem Kontext und Fine-Tuning etwa 15 $ monatlich: bei Weitem nicht genug, um die Kosten für Vorbereitung und Pflege eines angepassten Modells zu rechtfertigen. Bei einer Million sind es rund 15.000 $ im Monat —180.000 $ im Jahr— und plötzlich amortisiert sich Fine-Tuning in Wochen.
Der Break-even wird nicht davon bestimmt, welche Option „besser” ist, sondern davon, wie oft Sie die Aufgabe wiederholen werden.
Wie man entscheidet, ohne das halbe Team zu instrumentieren
Drei Fragen ordnen fast jeden Fall:
Wie hoch ist Ihr Volumen? Bei geringem Volumen gewinnt der lange Kontext fast immer: Die Kosten pro Aufgabe sind gegenüber der eingesparten Entwicklungszeit unerheblich. Bauen Sie keine RAG-Pipeline, um tausend Anfragen im Monat zu lösen.
Wie oft ändert sich das Wissen? Ändert sich Ihre Basis täglich —Preise, Bestand, Richtlinien—, ist Fine-Tuning eine Falle: ständiges Neutrainieren ist teuer und langsam. RAG glänzt genau hier, denn Aktualisieren ist so einfach wie das Austauschen der indexierten Dokumente. Fine-Tuning passt, wenn das, was Sie beibringen, stabil ist: ein Ton, ein Ausgabeformat, ein Fachjargon.
Was bringen Sie ein, Wissen oder Verhalten? RAG ist dafür da, Dinge zu wissen (Fakten, Dokumente, Daten, die man nachschlägt). Fine-Tuning ist dafür da, sich auf eine bestimmte Weise zu verhalten (in einem Stil antworten, einer Struktur folgen, Ihre Fachsprache sprechen). Sie zu verwechseln ist der teuerste Fehler: eine sich ändernde Wissensbasis per Fine-Tuning einbringen zu wollen, oder ein starres Format zu erzwingen, indem man den Prompt bei jeder Anfrage streckt.
Und sie schließen sich nicht aus. Die häufigste Kombination im Produktivbetrieb ist Fine-Tuning für das Verhalten + RAG für das Wissen: ein Modell, das so antwortet, wie Sie es wollen, gespeist mit im Flug abgerufenen Fragmenten. Man zahlt die Fine-Tuning-Einrichtung einmal, hält das Wissen mit RAG günstig, und der Prompt pro Aufgabe bleibt auf beiden Seiten kurz.
Eine ehrliche Einschränkung
Die Zahlen in diesem Artikel sind ein Beispiel, um den Mechanismus zu zeigen, keine Messung Ihres Falls. Der reale Break-even hängt von Ihrem Volumen ab, davon, wie viel Kontext jede Anfrage heute mitschleppt, und davon, wie oft sich Ihr Wissen ändert. Er kann bei zehntausend Aufgaben im Monat liegen oder bei zehn Millionen.
Was sich nicht ändert, ist die Reihenfolge der Entscheidung: Messen Sie zuerst, was Sie eine Aufgabe heute kostet und wie viele Sie davon machen, und wählen Sie erst dann eine Architektur. Nach der Mode zu wählen —„alle machen RAG”— statt nach Ihren Zahlen ist der häufigste Weg, am Ende für eine Architektur zu viel zu zahlen, die Ihr Volumen nicht rechtfertigt.
Dieser Beitrag gehört zum Cluster rund um die Kosten pro Aufgabe — dem Leitfaden, der alles andere verankert.
Bei e-ficient messen wir die Kosten pro Aufgabe von Unternehmen, die KI bereits produktiv einsetzen, einschließlich dessen, was Sie jede Architektur bei Ihrem realen Volumen kosten würde. Das erste Audit ist kostenfrei, wenn Sie einen Plan mit drei Monaten Laufzeit abschließen, und liefert innerhalb von 72 Stunden eine Diagnose.