Drei Monate nach dem Aufbau der Handelssignal-Extraktionsschicht von AlgoVesta hatten wir 8.000 US-Dollar für die Feinabstimmung von GPT-3.5 über 15.000 Finanzdokumente verbrannt. Die Genauigkeit verbesserte sich um 3 %. Dann wechselten wir zu einem anderen Prompting-Ansatz und einer RAG-Architektur – dieselben Daten, dieselben Modelle, andere Struktur. Die Genauigkeit sprang auf 89 %. Das Problem war nicht die Technik. Es war die falsche Technik für das Problem.
Feinabstimmung, Prompt Engineering und Retrieval-Augmented Generation (RAG) sind keine austauschbaren Werkzeuge, die um denselben Job konkurrieren. Sie lösen unterschiedliche Probleme, haben unterschiedliche Kosten und erfordern unterschiedlichen Wartungsaufwand. Die meisten Teams wählen eine Methode, weil sie ihnen vertraut klingt oder weil sie ein Tutorial gelesen haben, nicht weil sie ihren tatsächlichen Einschränkungen entspricht.
Dieser Rahmen schafft Klarheit. Er basiert auf wiederholten Produktionsfehlern – meinen und denen anderer –, nicht auf theoretischen Vergleichen.
Die Kernunterschiede: Was jede einzelne tatsächlich tut
Beginnen Sie hier, denn die Unterschiede sind wichtig.
Prompt Engineering formt das Verhalten des Modells, ohne seine Gewichte zu verändern. Sie schreiben Anweisungen, strukturieren Beispiele und entwerfen das Eingabeformat. Das Modell selbst bleibt eingefroren. Kosten fallen pro Token an. Latenz ist deterministisch. Änderungen dauern Sekunden.
Feinabstimmung aktualisiert die Gewichte des Modells, indem es auf Ihren spezifischen Daten trainiert wird. Sie erstellen einen Datensatz, führen einen Trainingslauf durch (Stunden bis Tage) und stellen eine neue Modellversion bereit. Die Kosten umfassen die anfängliche Trainingszeit, dann die Inferenz pro Token. Dies ist permanent, es sei denn, Sie trainieren neu.
RAG verändert das Modell überhaupt nicht. Es ruft relevante Kontexte aus einer externen Datenbank ab, fügt sie in den Prompt ein und lässt das Basismodell mit fundierten Informationen antworten. Die Kosten hängen von der Abrufgeschwindigkeit und der Größe des eingefügten Kontexts ab. Es skaliert mit Ihrer Wissensbasis, nicht mit Ihren Trainingsdaten.
Der Unterschied erscheint offensichtlich, wenn er aufgeschrieben wird. In der Praxis verwechseln Teams sie ständig. Ein häufiger Fehler: Jemand trainiert ein feinabgestimmtes Modell, um die Genauigkeit zu „verbessern“, wenn das eigentliche Problem darin besteht, dass der Prompt nicht spezifisch genug war. Ein anderer: ein RAG-System aufbauen, wenn Feinabstimmung schneller und günstiger wäre.
Wann Prompt Engineering ausreicht (und wann es nicht mehr funktioniert)
Prompt Engineering ist Ihr erster Schritt. Immer.
Es funktioniert, wenn das Basismodell das Konzept bereits versteht und nur bessere Anweisungen benötigt. Es kostet nichts im Voraus. Sie erhalten Feedback in Sekunden. Sie können 20 Mal in einer Stunde iterieren. Für Klassifizierung, Zusammenfassung und strukturierte Extraktion aus Texten, die das Modell während des Pretrainings gesehen hat, löst Prompt Engineering oft 70–85 % des Problems.
Hier ein reales Vorher/Nachher-Beispiel für die Extraktion von Risikofaktoren aus SEC-Einreichungen mit Claude Sonnet 4:
## Schlechter Prompt
Extrahieren Sie die wichtigsten Risikofaktoren aus diesem Dokument.
## Ausgabe
- Allgemeine Marktbedingungen könnten unser Geschäft beeinträchtigen
- Wir stehen im Wettbewerb mit anderen Unternehmen
- Vorschriften können sich ändern
- Wir sind auf Schlüsselpersonal angewiesen
(Vage, mangelt an Spezifität, vermischt Schweregrade)
## Verbesserter Prompt
Extrahieren Sie aus der beigefügten 10-K-Einreichung alle Risikofaktoren, die im Abschnitt „Item 1A. Risk Factors“ erscheinen. Für jedes Risiko:
1. Geben Sie die genaue Überschrift aus der Einreichung an
2. Geben Sie eine prägnante Kernthese (welche schlimme Sache könnte passieren) in einem Satz an
3. Kennzeichnen Sie, ob das Unternehmen die Wahrscheinlichkeit oder die Auswirkung quantifiziert (falls ja, geben Sie sie an)
4. Markieren Sie als: MARKT / OPERATIV / REGULATORISCH / STRATEGISCH / FINANZIELL
5. Wenn die Einreichung ausdrücklich angibt, dass dieses Risiko im Vergleich zum Vorjahr abgenommen hat,
vermerken Sie dies
Lassen Sie Standardrisiken weg, die in jeder 10-K vorkommen (z. B. „allgemeine wirtschaftliche Bedingungen“). Konzentrieren Sie sich auf Risiken, die für das Geschäft dieses Unternehmens spezifisch sind.
## Ausgabe
- Cybersicherheitsverletzungen und Datenverluste (OPERATIV):
Könnten Kundendaten kompromittieren und regulatorische Maßnahmen auslösen.
Das Unternehmen schätzte die potenzielle Auswirkung auf „bis zu 500 Mio. USD“, wenn ein „wesentlicher Verstoß“ auftritt.
- Verlust wichtiger Partnerschaften (STRATEGISCH):
Spezifisch für dieses Unternehmen. Zwei der Top-5-Umsatzkanäle hängen von jährlich erneuerbaren Verträgen ab.
(Spezifisch, hierarchisch, sortierbar)
Der zweite Prompt funktioniert, weil er:
- Die Ausgabeform festlegt (das Modell folgt strukturierten Anweisungen besser als vagen Anfragen)
- Negative Beispiele hinzufügt (was NICHT enthalten werden soll, hilft genauso viel wie was enthalten werden soll)
- Ein Klassifizierungssystem erstellt (MARKT/OPERATIV/usw. – dies gibt dem Modell einen Entscheidungsbaum)
- Die Präzision quantifiziert („Kernthese in einem Satz“ nicht „Risiko zusammenfassen“)
Prompt Engineering funktioniert nicht mehr, wenn:
- Das Konzept außerhalb der Trainingsdaten des Modells liegt. Sie können dies nicht durch Prompting umgehen. Wenn Sie GPT-4o bitten, domänenspezifische Fachbegriffe aus medizinischen Bildberichten zu extrahieren, und das Modell diese Daten während des Pretrainings nie gesehen hat, wird es raten.
- Sie ein konsistentes Verhalten bei mehr als 10.000 ähnlichen Anfragen benötigen. Prompt-Varianz verstärkt sich. Einige Anfragen stoßen auf Grenzfälle, und der Prompt wird sie nicht abdecken. Sie benötigen eine systematische Neuschulung des Verhaltens.
- Ihre Genauigkeitsgrenze bei ~85–90 % liegt, Sie aber 96 %+ benötigen. Prompt Engineering stagniert. Kleine Gewinne danach erfordern entweder Feinabstimmung oder architektonische Änderungen (wie RAG).
- Die Aufgabe Fakten erfordert, die nicht in den Trainingsdaten enthalten sind. Wenn Sie Produktpreise von 2024 extrahieren und Ihr Modell bis April 2023 trainiert wurde, hilft Prompting nicht. RAG schon.
RAG: Wenn Ihr Problem fehlender oder veralteter Kontext ist
RAG löst ein spezifisches, häufiges Problem: Das Modell weiß, wie es denken soll, hat aber nicht die Fakten, die es benötigt.
Sie bauen ein RAG-System, wenn:
- Ihr Wissen schneller aktualisiert wird als die Trainingszyklen des Modells. Wenn Sie ein feinabgestimmtes Modell jede Woche neu trainieren, um neue Daten hinzuzufügen, ist RAG günstiger. Sie aktualisieren stattdessen eine Vektordatenbank. Die Kosten pro Abfrage sind höher (Abruf + Einbettungsabfrage), aber Sie vermeiden den Aufwand für das Neutrainieren.
- Ihre Genauigkeit aufgrund von Halluzinationen fehlschlägt, nicht aufgrund von Fehlern im logischen Denken. Das Modell weiß, wie es Informationen extrahieren und strukturieren soll – es erfindet einfach Details, wenn es etwas nicht weiß. RAG verankert es in tatsächlichen Daten.
- Sie eine Quellenangabe benötigen. „Aus welchem Dokument stammt diese Tatsache?“ Feinabstimmung kann das nicht beantworten. RAG kann das, weil es explizit die Quelle abruft.
- Ihre Aufgabe Fakten beinhaltet, die das Modell wirklich nie gesehen hat. Ein feinabgestimmtes Modell kann nichts lernen, was nicht in seinen Trainingsdaten enthalten war. Ein RAG-System kann es aus einer Datenbank abrufen.
Reales Beispiel von AlgoVesta: Wir verarbeiten täglich über 500 Forschungsberichte und extrahieren Kauf-/Verkaufssignale. Die Berichte beziehen sich auf spezifische Metriken und Daten. Preise und Zeitkontexte ändern sich ständig. Wir haben RAG aufgebaut, indem wir:
- Jeden Bericht in Abschnitte von 300–500 Token zerlegt haben (semantische Grenzen sind wichtig – das Aufteilen mitten im Satz zerstört den Kontext)
- Jeden Abschnitt mit OpenAI’s text-embedding-3-small eingebettet haben (günstig, schnell, gut genug für Finanzdaten)
- Einbettungen + Originaltext in einer Vektordatenbank gespeichert haben (Pinecone, in unserem Fall)
- Zur Abfragezeit: Die Frage des Benutzers eingebettet, die Top-5 semantisch ähnlichsten Abschnitte abgerufen, in den Prompt eingefügt und an Claude Sonnet 4 gesendet
Die Schlüsselmetrik: Ohne RAG halluzinierte das Modell etwa 15 % der Zeit spezifische Zahlen. Mit RAG 1,2 %. Wir haben nicht feinabgestimmt. Wir haben den Prompt (kaum) verbessert. Wir haben dem Modell einfach das Quellmaterial gegeben, das es benötigte.
RAG schlägt fehl, wenn:
- Ihre Abruflogik fehlerhaft ist. Wenn Ihre Vektordatenbank irrelevante Abschnitte zurückgibt, arbeitet das Modell mit fehlerhaften Eingaben. Sie haben das Problem nur nach oben verlagert. Sie müssen die Abrufqualität validieren – tatsächlich die Top-5-Ergebnisse für eine Stichprobe von Abfragen prüfen.
- Sie zu viel Kontext einfügen. Das Kontextfenster von Claude Sonnet 4 beträgt 200.000 Token. Klingt unendlich, bis Sie 15 Abschnitte × 500 Token pro Stück einfügen, plus einen langen Prompt, plus die Anfrage des Benutzers. Kontext-Bloat verursacht Latenz- und Kostensteigerungen. Mehr Kontext verbessert nicht immer die Genauigkeit – er kann Rauschen einführen.
- Ihr Einbettungsmodell nicht zu Ihrer Domäne passt. Wenn Sie ein Allzweck-Einbettungsmodell für hochspezialisierte Daten (Verträge, medizinische Aufzeichnungen, Handelssignale) verwenden, bricht die semantische Ähnlichkeit zusammen. Sie benötigen möglicherweise domänenspezifische Einbettungen oder feinabgestimmte Retriever.
- Ihre Wissensbasis klein oder statisch ist. Wenn Sie 50 Dokumente haben, die sich selten ändern und Ihre Daten aus der Trainingsperiode des Modells stammen, fügt RAG Komplexität für minimalen Gewinn hinzu. Prompt Engineering ist schneller.
Feinabstimmung: Wenn Sie eine systematische Verhaltensänderung benötigen
Feinabstimmung ist Ihr letzter Ausweg – nicht, weil sie schwach ist, sondern weil sie teuer ist und einen Bereitstellungsaufwand mit sich bringt.
Sie stimmen fein ab, wenn:
- Das Basismodell durchgängig mit Ihrem spezifischen Format oder Ihrer Domäne kämpft. Wenn Prompt Engineering Sie auf 75 % bringt und Sie Prompt-Variationen erschöpft haben, kann Feinabstimmung Sie auf 88–92 % bringen, indem die Gewichte des Modells auf Ihre Datenverteilung umgelegt werden.
- Sie Latenzgarantien benötigen, die Prompt Engineering nicht bieten kann. Ein feinabgestimmtes Modell ist kleiner, schneller und vorhersehbarer als Basismodelle mit langen, komplexen Prompts. Wenn Sie 10.000 Abfragen pro Sekunde bedienen und Latenz-SLAs eng sind, ist dies wichtig.
- Die Kosten pro Abfrage Ihr limitierender Faktor sind, nicht die Vorabkosten. Feinabstimmung ist im Voraus teuer (50–500 US-Dollar, abhängig von der Datensatzgröße und dem Modell), aber die Inferenz pro Token ist günstiger als die Inferenz des Basismodells. Wenn Sie ein hohes Volumen betreiben, kehrt sich die Rechnung um.
- Sie konsistentes Verhalten bei Grenzfällen benötigen, die Ihr Prompt nicht abdecken kann. Wenn Sie einen 2.000-Token-Prompt erstellt haben, um 12 verschiedene Eingabevarianten zu behandeln, und dieser immer noch 8 % der Zeit fehlschlägt, wird ein feinabgestimmtes Modell, das auf diesen Variationen trainiert wurde, robuster sein.
Beispiel: Ein Kundensupport-Team verwendet GPT-4o zur Klassifizierung von Tickets. Prompt Engineering brachte ihnen 82 % Genauigkeit über 50 Ticketkategorien. Sie haben 2.000 Tickets manuell beschriftet, Mistral 7B (kleineres Modell, schnellere Inferenz) feinabgestimmt und 91 % Genauigkeit erreicht. Vorabkosten: 4 Stunden Beschriftung + 60 US-Dollar Feinabstimmungskosten. Monatliche Einsparungen: 1.200 US-Dollar an API-Aufrufen (weniger GPT-4o-Token benötigt). Amortisation: 3 Wochen.
Feinabstimmung schlägt fehl, wenn:
- Sie keine hochwertigen Trainingsdaten haben. Wenn Ihr beschrifteter Datensatz klein (<500 Beispiele) oder verrauscht ist, wird die Feinabstimmung überanpassen oder falsche Muster lernen. Prompt Engineering ist bei begrenzten Daten robuster.
- Ihr Problem domänenspezifisch ist und Ihr Modell zu allgemein ist. Die Feinabstimmung von GPT-4o auf 1.000 Beispiele zur Klassifizierung von Molekülstrukturen wird ihm keine Chemie beibringen. Ein domänenspezifisches Modell oder ein spezialisierter Einbettungsansatz wäre besser.
- Ihre Datenverteilung häufig schwankt. Feinabgestimmte Modelle verschlechtern sich, wenn sie auf Daten stoßen, die sich von ihrem Trainingssatz unterscheiden. Wenn Sie heute feinabstimmen und sich Ihre Eingabemuster nächsten Monat ändern, müssen Sie neu trainieren. RAG behandelt Verteilungsverschiebungen besser, da Sie die Wissensbasis und nicht das Modell aktualisieren.
- Sie mehrere Varianten bereitstellen müssen. Wenn Sie ein Modell für Englisch und eines für Spanisch und eines für eine andere Domäne feinabstimmen, verwalten Sie jetzt drei separate Modelle, drei separate Bereitstellungen, drei separate Überwachungspipelines. Dieser operative Aufwand ist real.
Die Entscheidungsmatrix: Konkrete Anleitung für Ihr Problem
Verwenden Sie diese Tabelle, um die Analyse zu beschleunigen. Finden Sie Ihre Einschränkung links, folgen Sie der Zeile, und sie weist auf das richtige Werkzeug hin.
| Einschränkung / Anforderung | Prompt Engineering | RAG | Feinabstimmung |
|---|---|---|---|
| Benötigt >90 % Genauigkeit bei domänenspezifischer Aufgabe | ❌ Oft Stagnation bei 80–85 % | ✅ Wenn Daten extern sind | ✅ Primäre Wahl |
| Wissen wird täglich/wöchentlich aktualisiert | ⚠️ Nur wenn Fakten im Prompt enthalten sind | ✅ Beste Wahl | ❌ Aufwand für Neutraining |
| Latenz-SLA <200ms, hohes Volumen | ❌ Lange Prompts verlangsamen Inferenz | ⚠️ Abruf fügt 50–100ms hinzu | ✅ Kleinere, schnellere Modelle |
| Benötigt Quellenangabe (welche Quelle?) | ❌ Kann die Argumentation nicht nachvollziehen | ✅ Gibt Quellabschnitte zurück | ❌ Kann die Argumentation nicht nachvollziehen |
| Aufgabe beinhaltet Fakten außerhalb der Modell-Trainingsdaten | ❌ Modell kann es nicht wissen | ✅ Beste Wahl | ⚠️ Nur wenn in Trainingsdaten |
| Begrenzte beschriftete Daten (<500 Beispiele) | ✅ Beste Wahl | ✅ Funktioniert gut | ❌ Risiko der Überanpassung |
| Kosten pro Abfrage sind entscheidend (>10.000 Abfragen/Monat) | ⚠️ Lange Prompts = teuer | ⚠️ Mittlere Kosten | ✅ Beste Skalierung |
| Verhalten basierend auf Feedback anpassen müssen | ✅ Änderungen werden in Sekunden bereitgestellt | ⚠️ Abruflogik ändert sich langsam | ❌ Neutraining erforderlich |
Ein realer Entscheidungsfluss: Drei Fallstudien
Fall 1: Kennzeichnung von Risiken in Rechtsverträgen
Ein Startup muss eingehende Verträge scannen und ungewöhnliche Klauseln kennzeichnen. Sie haben 200 beschriftete Verträge. Ihr Basismodell (Claude Sonnet 4) erkennt 70 % der Risiken, verpasst aber domänenspezifische Sprache.
Entscheidung: Beginnen Sie mit Prompt Engineering (2 Stunden, kostenlos). Ergebnisse: 78 %. Fügen Sie dann RAG hinzu, indem Sie ihre beschrifteten Verträge als Wissensbasis verwenden (8 Stunden Einrichtung, 50 US-Dollar Einbettungskosten). Ergebnisse: 86 %. Die Genauigkeitsgrenze scheint erreicht. Feinabstimmung würde über 1.000 beschriftete Verträge erfordern (Wochen Arbeit). Entscheidung: Stopp bei RAG. Kosten: ca. 2 USD/Monat in der Vektordatenbank. Dies funktioniert für 3–6 Monate, bis sie mehr beschriftete Daten haben.
Fall 2: Klassifizierung von Produktbewertungen (50.000 Bewertungen/Monat)
Ein SaaS-Unternehmen muss 50.000 monatliche Bewertungen in 12 Sentiment-Kategorien klassifizieren. Die API-Kosten von GPT-4o betragen 400 US-Dollar/Monat für diese Aufgabe. Sie beschriften 3.000 Beispiele und stimmen Mistral 7B fein ab. Kosten: 120 US-Dollar Feinabstimmung + 8 USD/Monat Inferenz (mit Together AI für günstige Inferenz). Ergebnisse: 88 % Genauigkeit (gegenüber 82 % mit Prompt Engineering). Monatliche Einsparungen: 370 US-Dollar. ROI der Feinabstimmung: 4 Wochen.
Entscheidung: Feinabstimmung. Aber hier ist der Haken: Sie stellen jeden Monat eine neue Feinabstimmung bereit, wenn neue Bewertungen eintreffen. Nach 6 Monaten haben sie 6 Feinabstimmungszyklen durchgeführt. Im 7. Monat schneidet die neueste Version bei alten Mustern schlechter ab (Drift). Sie hätten stattdessen in RAG oder eine aktualisierte Prompting-Strategie investieren sollen. Live and learn.
Fall 3: Q&A über Unternehmensdokumentation (über 1.000 Seiten)
Die Personalabteilung möchte, dass Mitarbeiter Fragen zu Leistungen, Richtlinien und Verfahren stellen können. Sie haben ein 1.500-seitiges Handbuch, das vierteljährlich aktualisiert wird. Das Basismodell (GPT-4o) halluziniert Richtliniendetails in 12 % der Fälle.
Option A: Prompt Engineering. Das gesamte Handbuch in den Prompt einfügen. Ergebnisse: über 100 KB Token-Overhead pro Abfrage. Latenz: 4–5 Sekunden. Kosten: 0,80 USD pro Abfrage. Halluzinationen: 5 %. Bei Skalierung untragbar.
Option B: RAG. Das Handbuch zerlegen (1.500 Seiten = ca. 1.000 Abschnitte). Einmal einbetten. Zur Abfragezeit: die Top-5 relevanten Abschnitte abrufen, einfügen (ca. 2 KB Token), an das Modell senden. Latenz: 800 ms. Kosten: 0,12 USD pro Abfrage. Halluzinationen: 0,8 %. Entscheidung: offensichtlich. RAG bauen. Implementierung: Pinecone + Claude Sonnet 4 = zwei Wochen von Anfang bis Ende.
Hybride Ansätze: Wenn eine Technik nicht ausreicht
Die reale Welt wählt selten nur eine Methode. Erfolgreiche Teams kombinieren sie strategisch.
Prompt Engineering + RAG (häufig, effektiv)
Sie verwenden RAG, um Fakten zu verankern, und dann Prompt Engineering, um das logische Denken zu steuern. Beispiel: Risikofaktoren aus einer 10-K extrahieren (RAG ruft relevante Abschnitte ab) und dann deren Schweregrad mit einer strukturierten Prompt-Vorlage klassifizieren (Prompt Engineering). Kosten: Abruf-Overhead + Inferenz. Latenz: akzeptabel. Genauigkeit: hoch.
Feinabstimmung + RAG (fortgeschritten, teuer)
Sie stimmen ein Modell fein ab, um Ihre Domäne zu verstehen, und verwenden dann RAG, um ihm aktuelle Fakten zu liefern. Beispiel: Ein medizinisches Modell feinabstimmen, um Patientensymptome zu klassifizieren, aber RAG verwenden, um es mit aktuellen Medikamenteninteraktionsdaten zu verankern, die nicht im Training enthalten waren. Kosten: hoch (zwei zu wartende Systeme). Nutzen: Domänenverständnis + faktische Genauigkeit. Anwendungsfall: Hochrisikodomänen, in denen beides wichtig ist.
Prompt Engineering + Prompt Engineering (kaskadierend) (unterschätzt)
Sie verwenden ein günstiges Modell für die anfängliche Filterung und dann ein leistungsstarkes Modell für die verfeinerte Ausgabe. Beispiel: GPT-3.5 klassifiziert, ob eine E-Mail supportbezogen ist (günstig, schnell), dann entwirft Claude Sonnet 4 eine Antwort, nur wenn dies der Fall ist (spart Geld). Kosten: zwei API-Aufrufe, aber insgesamt 70 % günstiger. Latenz: akzeptabel, wenn das erste Modell schnell ist. Funktioniert gut für Routing- und Filterungsaufgaben.
Benchmarking Ihres Ansatzes: Was Sie messen sollten
Sie können die richtige Technik nicht ohne Basis-Metriken auswählen. Bevor Sie etwas bauen, messen Sie:
- Genauigkeit auf einem zurückgehaltenen Testdatensatz (50–100 Beispiele, die Sie nicht trainieren). Genauigkeit ist kontextabhängig – 80 % können für einige Aufgaben großartig, für andere schrecklich sein. Kennen Sie Ihr Ziel.
- Kosten pro Abfrage (Token × Modellpreis). Berücksichtigen Sie die Abrufkosten, wenn Sie RAG verwenden. Berücksichtigen Sie die amortisierten Feinabstimmungskosten über das erwartete Abfragevolumen, wenn Sie feinabstimmen.
- Latenz-Perzentile, nicht Durchschnittswerte (p50, p95, p99). Durchschnittliche Latenz verbirgt langsame Spitzen. Wenn 1 % der Abfragen 30 Sekunden dauert, beeinträchtigt dies die Benutzererfahrung, auch wenn der Durchschnitt 2 Sekunden beträgt.
- Fehlermodi (nicht nur die Gesamtgenauigkeit). Klassifizieren Sie Ihre Fehler: Halluzinationen, Denkfehler, Formatfehler, mehrdeutige Eingaben. Verschiedene Techniken scheitern unterschiedlich. Halluzinationen deuten auf RAG hin. Formatfehler deuten auf besseres Prompting oder Feinabstimmung hin.
- Varianz über Eingabetypen (keine monolithische Genauigkeitszahl). Wenn Ihr Modell bei kurzen Eingaben gut funktioniert, aber bei langen versagt, haben Sie ein strukturelles Problem, kein Technikproblem.
Beispiel von AlgoVesta: Wir haben die Genauigkeit der Handelssignalextraktion nicht als einzelne Zahl gemessen, sondern als:
- Genauigkeit bei aktuellen Berichten (2024): 91 %
- Genauigkeit bei archivierten Berichten (2020–2022): 73 % (Wissenslücke)
- Genauigkeit bei Bezugnahme auf Preisdaten: 88 %
- Genauigkeit bei Randfällen von Tickersymbolen: 62 % (seltene Aktien, Halluzinationen nehmen zu)
Diese Aufschlüsselung zeigte, dass RAG das Problem von 2020–2022 und das Problem der Preisreferenz löste (sie sind in der Wissensbasis enthalten), aber das Problem der Randfälle von Tickersymbolen nicht löste (das Modell benötigt Feinabstimmung oder eine bessere Ticker-Disambiguierung im Prompt). Eine einzelne Zahl hätte uns das nicht gesagt.
Was Sie am Montag tun können
Wenn Sie jetzt vor dieser Entscheidung stehen:
Schritt 1: Wählen Sie eine kleine Stichprobe (10–50 Beispiele) aus Ihrem Anwendungsfall und messen Sie die Basisgenauigkeit mit der günstigsten Option zuerst: GPT-3.5 Turbo mit einem einfachen Prompt. Dies dauert 30 Minuten und gibt Ihnen eine Untergrenze. Es könnte gut genug sein. Oft ist es das nicht.
Schritt 2: Schreiben Sie einen spezifischeren Prompt (siehe Abschnitt weiter oben für Regeln zur Prompt-Vorlage). Messen Sie erneut.** Normalerweise 5–15 % Verbesserung ohne zusätzliche Kosten. Stoppen Sie, wenn dies Ihre Zielgenauigkeit erreicht. Überkomplizieren Sie nicht.
Schritt 3: Wenn Prompt Engineering stagniert, ermitteln Sie, welcher der folgenden Punkte Ihr tatsächlicher Engpass ist:
- Fehlende Fakten (z. B. Daten außerhalb des Trainingsfensters des Modells): Bauen Sie RAG
- Konsistente Halluzinationen bei denselben Randfällen: Bauen Sie RAG oder stimmen Sie fein ab
- Format-/Strukturfehler (Modell versteht, gibt aber nicht das richtige Format aus): Verbessern Sie Prompting oder stimmen Sie fein ab
- Latenz oder Kosten bei Skalierung: stimmen Sie fein ab oder wechseln Sie zu einem kleineren Modell
Schritt 4: Wenn Sie sich für RAG entscheiden: Implementieren Sie zuerst ein kleines RAG-System (eine Vektordatenbank, einen Retriever, ein Modell). Messen Sie die tatsächliche Abrufqualität – stichprobenartig die Top-5-Ergebnisse bei 10 Abfragen. Wenn der Abruf fehlerhaft ist, wird die Genauigkeit fehlerhaft sein. Iterieren Sie nicht am Prompting, wenn der Abruf das Problem ist.
Schritt 5: Wenn Sie sich für Feinabstimmung entscheiden: Sammeln Sie zuerst über 500 beschriftete Beispiele. Wenn Sie weniger haben, werden Prompt Engineering oder RAG wahrscheinlich besser abschneiden, da die Feinabstimmung überanpassen wird. Überspringen Sie diesen Schritt nicht, um Zeit zu sparen.
Die Entscheidung ist nicht endgültig. Sie beginnen mit einem Ansatz, stoßen an dessen Grenzen und fügen eine weitere Ebene hinzu. Das ist normal. Die Teams, die katastrophale Überausgaben vermeiden, sind diejenigen, die bei jedem Schritt messen, anstatt alles auf eine einzige Technik im Voraus zu setzen.