Fine-Tuning vs. RAG vs. Prompting: Was sollten Sie verwenden?
Automatische Übersetzung
Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.
Verwenden Sie Prompting, um die Aufgabe zu präzisieren, Retrieval-Augmented Generation (RAG), um aktuelles oder privates Wissen bereitzustellen, und Fine-Tuning, um das wiederholbare Verhalten eines Models zu ändern. Diese Techniken lösen unterschiedliche Probleme und gehören häufig in dasselbe System.
Beginnen Sie mit einer gemessenen Prompt-Baseline. Fügen Sie RAG hinzu, wenn Antworten externe Belege oder häufig wechselnde Fakten benötigen. Ziehen Sie Fine-Tuning bei anhaltenden Fehlern in Tonalität, Klassifikation, Tool Use oder Domänensprache in Betracht, sofern genügend geprüfte Beispiele vorhanden sind. Bei Fehlern im Antwortformat sollten Sie zunächst Structured Output mit Schema-Beschränkung ausprobieren.
Entscheiden Sie anhand der beobachteten Fehler, der Häufigkeit von Faktenänderungen und der verfügbaren Daten, mit denen Sie eine Korrektur testen können.
Entscheidungstabelle
| Problem | Erste Maßnahme | Warum |
|---|---|---|
| Anweisungen sind unklar oder Beispiele fehlen | Prompting | Damit lässt sich prüfen, ob klarere Anweisungen und Beispiele die beobachteten Fehler beheben. |
| Fakten sind privat, zitierpflichtig oder ändern sich häufig | RAG | Retrieval aktualisiert Wissen ohne Retraining und kann die Herkunft der Quellen bewahren. |
| Wiederholbares Verhalten bleibt nach Prompt-Tests fehlerhaft | Fine-Tuning erwägen | Geprüfte Beispiele können Stil, Labels oder Tool-Verhalten vermitteln; vergleichen Sie das Ergebnis mit der Prompt-Baseline. |
| Eine sorgfältige Prompt-Baseline schlägt weiterhin fehl | Anderes Model oder Systemdesign testen | Vergleichen Sie Alternativen anhand derselben Fälle; ein Prompt-Fehler allein zeigt nicht, ob Tuning helfen würde. |
| Antworten benötigen aktuelle Fakten und spezialisiertes Verhalten | RAG plus Fine-Tuning | Retrieval liefert die Belege, während Tuning verändert, wie das Model sie verwendet. |
Verwenden Sie zuerst Prompting
Prompting ist eine Methode mit geringem Setup-Aufwand zur Diagnose von Fehlern. Definieren Sie die Aufgabe, den Ausgabevertrag, Beispiele, erlaubte Tools und Bedingungen für Verweigerungen. Erstellen Sie ein kleines Eval-Set, bevor Sie weitere Infrastruktur hinzufügen. Wenn ein besserer Prompt die repräsentativen Fehler behebt, belassen Sie es dabei.
Wenn ein wachsender Prompt schwerer zu pflegen ist, prüfen Sie, was hinzugefügt wurde. Sich ändernde Produktinformationen können in Retrieval gehören. Wiederholte Verhaltensbeispiele können sich als Trainingsdaten eignen. Die Prompt-Länge allein belegt nicht, dass eine dieser Änderungen das Ergebnis verbessert.
Verwenden Sie RAG für Wissen und Provenienz
RAG eignet sich für Produktdokumentationen, Richtlinien, interne Dokumente, aktuelle Ereignisse und Antworten, die eine Quelle zitieren müssen. Das ursprüngliche RAG-Paper kombiniert einen Generator mit abgerufenen Passagen; die abgerufenen Belege werden zum Anfragezeitpunkt bereitgestellt. Die Qualität hängt von Parsing, Chunking, Retrieval, Ranking, Berechtigungen und der Unterstützung von Zitaten ab. Eine Änderung des Generators allein liefert keine Quelle, die Retrieval nicht abgerufen hat.
RAG ist keine Methode zum Training von Verhalten. Das Model kann dadurch ein Beispiel oder eine Regel sehen, aber dieses Verhalten wird dadurch nicht für jede Anfrage stabil.
Bei einem Support-Assistenten deutet eine veraltete Antwort zur Garantie auf eine fehlende aktuelle Richtlinie hin: Stellen Sie diese über Retrieval bereit. Wenn die richtige Richtlinie bereits vorliegt, der Assistent aber wiederholt die falsche Beschwerdekategorie zuweist, testen Sie zuerst klarere Beispiele. Fine-Tuning kommt infrage, wenn dieser gleichbleibende Klassifikationsfehler bestehen bleibt und geprüfte Trainingsbeispiele vorliegen.
Verwenden Sie Fine-Tuning für wiederholbares Verhalten
Supervised Fine-Tuning trainiert anhand von Input/Output-Beispielen, wie im TRL-Trainingsleitfaden beschrieben. Es kommt für Klassifikation, Extraktionsstil, Antwortstruktur, Domänenterminologie und wiederkehrende Tool-Use-Muster infrage. Bei reinen Formatfehlern sollten Sie zunächst Structured Output mit Schema-Beschränkung ausprobieren, sofern Ihre Runtime dies unterstützt. Eine gültige Struktur muss weiterhin auf korrekte Feldwerte geprüft werden.
Fine-Tuning erfordert geprüfte Trainingsdaten, ein separates Eval-Set, Model-Versionierung und einen Rollback-Pfad. Führen Sie kein Fine-Tuning für Fakten durch, die sich häufig ändern, wenn Retrieval sie zum Anfragezeitpunkt bereitstellen kann.
Eine praxisnahe Abfolge
- Definieren Sie den Erfolg und erstellen Sie ein repräsentatives Eval-Set.
- Etablieren Sie eine Prompt-only-Baseline mit dem stärksten akzeptablen Model.
- Fügen Sie RAG hinzu, wenn Fehler auf fehlende oder sich ändernde Belege zurückgehen.
- Sammeln und prüfen Sie Beispiele der verbleibenden stabilen Fehler.
- Führen Sie Fine-Tuning nur durch, wenn der Gewinn bei Qualität, Latency oder Kosten den zusätzlichen Aufwand für Daten und Model Operations übersteigt.
- Führen Sie nach jeder Änderung an Prompt, Index, Model oder Adapter dieselbe Evaluation erneut durch.
Weiterführende Literatur
- Fine-Tuning von LLMs behandelt Daten, LoRA, Evaluation und Deployment.
- RAG-Evaluationsmetriken zeigt, wie sich Fehler nach Pipeline-Stufe lokalisieren lassen.
- Context Engineering für AI Agents behandelt den Runtime-Kontext rund um Prompts und Retrieval.