Vergleich · 01
Stand: September 2026
Build · KI-Entwicklung · KI-Implementierung · Testing & Evaluation
Nachschlagen
oder auswendig
lernen?
Retrieval-Augmented Generation. Zur Laufzeit durchsucht das System eure Dokumente, und das Modell antwortet aus dem, was es findet.
Weitertrainieren mit euren Beispielen. Die Gewichte des Modells ändern sich, das Verhalten bleibt ohne Nachschlagen.
01 · Nebeneinander
Eins ändert den Input.
Eins das Modell.
Beide machen ein allgemeines Modell für euren Fall brauchbar. Sie arbeiten auf verschiedenen Ebenen, scheitern verschieden und kosten verschieden. Kosten nur relativ: echte Zahlen hängen von Modell, Volumen und Anbieter ab.
RAGzur Laufzeit, jedes Mal
- Frage
- Suche im Index
- Frage + Passagen
- Modell
- Antwort mit Quelle
Fine-Tuningvorher, einmal pro Version
- Beispiele
- Trainingslauf
- Angepasstes Modell
- Frage
- Antwort
| Kriterium | RAG | Fine-Tuning |
|---|---|---|
| Was sich ändert | Der Prompt: passende Passagen kommen zur Laufzeit dazu | Das Modell: seine Gewichte werden an euren Beispielen angepasst |
| Stark bei | Fakten, Dokumente, allem, was aktuell sein oder belegt werden muss | Format, Ton, Stil, eng umrissenen Aufgaben, gleichbleibender Struktur |
| Aktualität | Index aktualisieren, und die nächste Antwort weiß es. Minuten bis Stunden. | Eingefroren zum Trainingszeitpunkt. Neue Fakten brauchen einen neuen Trainingslauf. |
| Nötige Daten | Eure Dokumente: bereinigt, in Chunks geteilt, mit Zugriffsrechten versehen | Kuratierte Paare aus Input und idealem Output für das gewünschte Verhalten. Qualität schlägt Menge. |
| Kostenprofil | Niedriger am Anfang, höher pro Anfrage: erst Pipeline und Index, dann längere Prompts bei jedem Aufruf | Höher am Anfang, niedriger pro Anfrage, wenn nun ein kleineres Modell oder ein kürzerer Prompt reicht. Jedes Nachtrainieren kostet erneut. |
| Latenz | Fügt einen Suchschritt und längeren Kontext hinzu | Kein Nachschlagen. Kann schneller sein, vor allem mit einem kleineren angepassten Modell |
| Nachvollziehbarkeit | Antworten können die Passage zitieren, aus der sie stammen | Keine Quelle zum Zeigen. Das Wissen steckt in den Gewichten. |
| Zugriffsschutz | Die Suche bei jeder Anfrage nach den Rechten der Person filtern | Was ins Training ging, steht allen offen, die das Modell nutzen |
| Evals | Zwei Ebenen: Hat es die richtige Passage gefunden, und hat die Antwort sie treu genutzt? | Jede trainierte Version gegen das Basismodell, auf zurückgehaltenen Fällen, bevor sie live geht |
| Typischer Fehler | Die falsche Passage wird gefunden, und die Antwort baut selbstbewusst darauf auf | Selbstbewusste Antworten aus halb gelernten Fakten |
02 · Wann was
Wählt nach
dem Problem.
Konkrete Situationen, und wozu wir zuerst greifen würden.
Nehmt RAG, wenn
- 01Support-Antworten aus einem Handbuch, das sich mit jedem Release ändert
Aktualität und Quellen. Bei jedem Release nachzutrainieren ist der teure Weg, zu spät zu sein.
- 02Mitarbeitende fragen nach HR-Richtlinien, und jede Antwort muss den Absatz zeigen
Nachvollziehbarkeit steckt im Retrieval. Gewichte können nicht zitieren.
- 03Verschiedene Teams dürfen verschiedene Dokumente sehen
Die Suche kann nach Rechten filtern. Ein trainiertes Modell kann nicht für eine Person vergessen.
- 04Ihr habt Dokumente, aber keine gelabelten Beispiele
RAG fängt mit dem an, was es heute gibt.
Nehmt Fine-Tuning, wenn
- 01Jede Ausgabe muss einer festen Struktur folgen, etwa einer Schadenzusammenfassung, die euer Team in zehn Sekunden liest
Verhalten, nicht Wissen. Tunen, wenn der Prompt allein immer wieder abdriftet.
- 02Ein hohes Ticketvolumen in eure eigenen Kategorien sortieren
Ein kleines angepasstes Modell kann pro Aufruf schneller und günstiger sein als ein großes mit Prompt.
- 03Hausstil oder Fachkürzel müssen jedes Mal stimmen
Wenn der Prompt sich mit Beispielen füllt, verschiebt die Beispiele in die Gewichte.
- 04Es muss auf einem kleinen Modell laufen, auf eurer eigenen Hardware
Tuning kann einen Teil des Abstands zu einem großen Modell schließen, bei einer eng umrissenen Aufgabe.
Und Vor beidem: ein guter Prompt mit ein paar Beispielen und ein Eval-Set aus echten Fragen. Viele Projekte brauchen nie mehr, und beide Ansätze brauchen das Eval-Set ohnehin.
03 · Entscheiden
Fünf Fragen,
eine Richtung.
Die Richtung bewegt sich, während ihr antwortet. Die Empfehlung erscheint, wenn alle fünf beantwortet sind.
01Was läuft heute schief?
Wissen oder Verhalten. Die nützlichste Frage auf dieser Seite.
02Wie oft ändern sich die Informationen?
03Müssen Antworten ihre Quelle zeigen?
04Sehen verschiedene Nutzer verschiedene Daten?
05Was habt ihr heute?
04 · Zusammen
Besser zusammen,
in dieser Reihenfolge.
In Produktion ist es selten entweder-oder. Fünf Stellen, an denen sich beide treffen.
- Fakten aus dem Retrieval, Format aus dem TuningRAGBringt aktuelle Passagen in den PromptFine-TuningBringt Aufbau, Ton bei, und wann es „steht nicht in den Quellen“ sagen sollüblich
- Tuning fürs RetrievalRAGGefundene Passagen enthalten Ablenker, die die Frage nicht beantwortenFine-TuningDas Modell darauf trainieren, die relevante Passage zu nutzen und den Rest zu ignorieren (RAFT, Zhang et al., 2024)Forschung
- Bessere SucheRAGDie Suchqualität hängt am Embedding-ModellFine-TuningEmbedding-Modelle lassen sich auf eure eigenen Paare aus Frage und Dokument tunenüblich
- Kleineres Modell, gleicher JobRAGHält das Wissen draußen, damit das Modell klein bleiben kannFine-TuningDestilliert das Verhalten eines großen Modells in ein kleineres, für Tempo und Kostenüblich
- Ein Eval-Set für beideRAGTrefferquote der Suche und Treue der AntwortFine-TuningBasismodell gegen angepasstes Modell, gleiche Fragenimmer
Immer: in jedem Aufbau nötig. Üblich: was wir in Produktion sehen. Forschung: veröffentlicht und vielversprechend, prüft es an euren eigenen Daten.
05 · Fragen
Gefragt in jedem
Architektur-Review.
Kann Fine-Tuning dem Modell unsere Fakten beibringen?
Teilweise, und schlecht. Eine Studie, die beides verglich, sah Retrieval beim Einbringen von Wissen durchgehend vorn (Ovadia et al., 2023). Eine andere fand, dass neue Fakten nur langsam gelernt werden und danach die Neigung zu Halluzinationen steigt (Gekhman et al., 2024). Nutzt Tuning für Verhalten; haltet Fakten dort, wo man sie nachschlagen kann.
Wie viele Beispiele braucht Fine-Tuning?
Weniger, als viele fürchten, und bessere, als viele mitbringen. Der Leitfaden eines Anbieters nennt mindestens 10 und empfiehlt, mit 50 sorgfältig gebauten Beispielen zu starten und dann zu evaluieren (OpenAI, geprüft September 2026). Derselbe Leitfaden sagt: erst Evals aufsetzen, dann in Fine-Tuning investieren.
Macht ein langes Kontextfenster RAG nicht überflüssig?
Meist nicht. Alles in den Prompt zu packen kostet pro Aufruf mehr, wird langsamer und macht es schwerer zu steuern, wer was sieht. Retrieval ist auch ein Filter.
Sind unsere Daten mit einem der beiden sicherer?
Bei RAG bleiben Dokumente in eurem Speicher und lassen sich pro Person filtern. Beim Fine-Tuning kann alles, was ins Training ging, bei jeder Person wieder herauskommen, die das Modell nutzt. Personenbezogene Daten im Trainingsset brauchen eine Rechtsgrundlage und einen Plan für Löschanfragen: sprecht vorher mit eurem Datenschutz, nicht nachher.
Lässt sich jedes Modell fine-tunen?
Nein. Viele geschlossene Modelle bieten kein Fine-Tuning an, oder nur für manche Versionen oder in manchen Clouds. Open-Weight-Modelle lassen sich überall tunen, wo ihr sie betreibt, etwa mit LoRA, das eine kleine Menge zusätzlicher Gewichte trainiert statt aller (Hu et al., 2021).
Was brauchen wir vor beidem?
Ein Eval-Set: echte Fragen mit erwarteten Antworten, auch die hässlichen. Ohne das könnt ihr nicht sagen, ob Retrieval oder Tuning geholfen hat, oder ob die nächste Änderung etwas kaputt gemacht hat.
Noch unentschieden?
Erst messen,
dann wählen.
Bringt echte Fragen mit. Das Eval-Set kommt zuerst, damit die Wahl eine Zahl ist, keine Meinung.