Vom Zero-Shot zur Selbstkonsistenz: Eine praktische Leitfaden für Prompting-Techniken

Sobald eine Anwendung festgelegt hat, was ein Modell sehen darf, welche Dokumente heruntergeladen werden, was zusammengefasst wird und was außen vor bleibt, tritt ein anderes Problem in den Vordergrund: die Formulierung der eigentlichen Anfrage. Keine einzige Anfragemethode ist in allen Fällen am besten. Eine sinnvolle Vorgehensweise ist, mit der einfachsten möglichen Anweisung zu beginnen und nur dann Beispiele oder eine schrittweise Struktur hinzuzufügen, wenn eine Aufgabe dies erfordert.

Das unten dargestellte Szenario betrifft einen Kundenservice-Assistenten.

Start ohne jegliche Beispiele

Eine Zero-Shot-Anfrage beschreibt die Aufgabe, zeigt aber nicht, wie eine gute Ausgabe aussehen sollte. Für den Support-Assistenten könnte das eine einzeilige Anfrage zur Zusammenfassung einer Beschwerde sein, wobei die Beschwerde darunter eingefügt wird:

Summarize the following customer complaint in one sentence.
<complaint>
The package arrived three days late and the box was damaged.
</complaint>

Das Modell erhält eine Aufgabe und nichts weiter. Genau diese Einfachheit ist der Grund, warum man es zuerst ausprobieren sollte. Alles, was zu einem Prompt hinzugefügt wird, hat seinen Preis: Beispiele verbrauchen Kontext, zusätzliche Anweisungen erhöhen die Komplexität, und jeder weitere Bestandteil ist ein weiterer Punkt, an dem zwei Regeln aufeinandertreffen können. Wenn eine direkte Anweisung bereits zu zuverlässigen Ergebnissen führt, ist ein aufwendiges Konstrukt nur ein Heilmittel für eine Krankheit, die niemand hat.

Was eine gute Anweisung beantwortet

Eine gut formulierte Aufgabenbeschreibung klärt vier Dinge: die zu durchführende Aktion, die zu verwendenden Materialien, die geltenden Grenzen sowie die Form, die die Antwort haben sollte. Eine ausführlichere Version des Beschwerdeprompts sieht so aus:

Task:
Summarize the customer complaint.

Source:
<complaint>
The package arrived three days late and the box was damaged.
</complaint>

Constraints:
- Use only the information in the complaint.
- Do not infer the cause of the damage.
- Use one sentence.

Output:
Return only the summary.

Es ist ausführlicher als ein einfaches „Zusammenfassen“, doch jede zusätzliche Zeile beseitigt eine Vermutung. Das Modell muss sich nicht mehr fragen, ob es über Ursachen spekulieren soll, wie lange es fortfahren muss oder ob Kommentare willkommen sind. Die von den Anbietern großer Modelle veröffentlichten Leitlinien weisen in dieselbe Richtung: Man sollte angeben, welche Aufgabe zu erledigen ist, wie das Ergebnis aussehen sollte, welche Einschränkungen gelten und welcher Kontext wichtig ist, anstatt zu hoffen, dass das Modell es selbst erkennt. Einfach ausgedrückt: Jeder Anforderung, die für die Anwendung relevant ist, sollte schriftlich festgehalten werden.

Konkrete Ziele sind besser als freundliche

„Hilfreich sein“ gibt dem Modell fast kein Ziel vor. „Nennen Sie das von dem Kunden beschriebene Problem und fassen Sie es in einem Satz zusammen“ gibt ihm hingegen ein klares Ziel. Vergleichen Sie zwei Anweisungen für das Support-Tool: Die schwächere fordert lediglich, dem Kunden zu helfen. Die stärkere verlangt das vom Kunden beschriebene Authentifizierungsproblem sowie maximal drei FehlerbehebungsSchritte, die durch die bereitgestellte Dokumentation gestützt werden.

Das ist wichtig, denn ein Modell kann eine Anweisung in vielen möglichen Richtungen fortsetzen. Ein vages Ziel lässt Raum dafür, dass es eine Interpretation wählt, die von der Absicht des Entwicklers abweicht, während ein präzises Ziel diesen Spielraum verringert.

Die Grenzen liegen innerhalb der Aufgabe

Sagen Sie, der Assistent darf niemals eine Lösung erfinden, die in der Dokumentation fehlt. Das ist eine Produktregel, daher muss die Anweisung dies ausdrücklich festlegen: Verwenden Sie ausschließlich die bereitgestellte Dokumentation, und wenn diese die Frage nicht abdeckt, geben Sie an, dass die verfügbaren Informationen unzureichend sind. Vergleichen Sie das mit „Seien Sie präzise“, das ein gewünschtes Ergebnis nennt, aber keine Anleitung dafür gibt, wie mit Unsicherheiten umzugehen ist.

Das Muster lässt sich verallgemeinern. Beschreiben Sie nicht nur das ideale Ergebnis; beschreiben Sie auch, was das Modell tun sollte, wenn dieses Ergebnis nicht sicher erzielt werden kann. Das ist später noch wichtiger, bei Toolaufrufen und strukturiertem Ausgabeformat.

Wo Zero-Shot ausreicht

Eine einfache Anweisung reicht in der Regel aus, wenn die Aufgabe einfach ist, das Verhalten leicht in Worte zu fassen ist, das Modell bereits die Art der Aufgabe kennt, die Ausgaberegeln bescheiden sind und die Eingabe keine ungewöhnlichen Randfälle aufweist. Die Anfrage nach der Produktversion in einer Nachricht – nur die Versionsnummer – ist eine solche Aufgabe. Ein Satz ins Französische zu übersetzen, ist eine weitere. Fünf Demonstrationen hintereinander zu verwenden, bringt wenig.

Daher ist die erste Regel der Prompt-Optimierung erstaunlich konservativ: Beginnen Sie mit Zero-Shot und fügen Sie nur dann zusätzliche Mechanismen hinzu, wenn eine Bewertung einen Bedarf zeigt.

Wege, auf denen Zero-Shot versagt

Mehrere Versagertypen treten wiederholt auf.

Ambiguität. Der Satz „Machen Sie das besser“ stellt die Frage: Kürzer, überzeugender, genauer, formeller? Das Modell muss raten. Vergleichen Sie das mit der Anfrage, eine Support-Antwort umzuschreiben, sodass sie prägnant, professionell und für einen nicht-technischen Kunden verständlich ist, während alle faktischen Angaben beibehalten werden. Diese Version ist weitaus besser definiert.

Fehlender Kontext. Ein Modell kann sich nicht auf Fakten stützen, die es nie erhalten hat und auch nicht abrufen kann. Fragen Sie es, warum die Authentifizierung eines Kunden fehlgeschlagen ist, ohne eine Fehlermeldung oder Systemdetails bereitzustellen – keine Umschreibung kann das fehlende Beweismaterial schaffen. Hier hilft besserer Kontext statt bessere Anweisungen. Das ist ein offensichtlicher Punkt und zugleich eine echte Grenze der Prompt-Engineering-Technik.

Konkurrierende Anforderungen. Eine Anfrage, die eine vollständige Erklärung in genau zehn Wörtern verlangt, fordert zwei Dinge, die nicht gleichzeitig gut erfüllt werden können. Ein gutes Prompt-Design vermeidet solche Konflikte, anstatt davon auszugehen, dass das Modell sie jeweils lösen kann.

Nicht ausgesprochene Annahmen. Ein Entwickler, der „Zusammenfassen der Beschwerde“ schreibt, meint vielleicht „nur die vom Kunden genannten Fakten aufzulisten“. Das Modell könnte stattdessen ein flüssiges Zusammenfassung mit sinnvollen Schlussfolgerungen liefern. Wenn dieser Unterschied wichtig ist, muss die Anweisung dies klar formulieren. Annahmen, die für das System relevant sind, sollten zu expliziten, maschinenlesbaren Anforderungen werden.

Beispiele hinzufügen

Wenn eine einfache Anweisung nicht ausreicht, kommt das nächste Werkzeug zum Einsatz: das Few-Shot-Prompting, bei dem funktionierende Beispiele der Aufgabe in den Kontext eingefügt werden. Ein Klassifikator, der Nachrichten in Kategorien wie Rechnungswesen, Technik und Konto einteilt, könnte vor der eigentlichen Nachricht einige beschriftete Nachrichten anzeigen:

Task:
Classify the customer message as BILLING, TECHNICAL, or ACCOUNT.

Example 1:
"My invoice contains an unexpected charge."
→ BILLING

Example 2:
"The application crashes when I upload a file."
→ TECHNICAL

Example 3:
"I cannot reset my password."
→ ACCOUNT

Now classify:
"I was charged twice for my subscription."

Durch diese Demonstrationen schließt das Modell die Zuordnung ab. Das wird als In-Context-Lernen bezeichnet, da das Modell sein Verhalten für die aktuelle Anfrage anhand der Beispiele in seinem Blickfeld ändert, während seine zugrunde liegenden Parameter unverändert bleiben. Im Grunde sagen die Beispiele: „So sieht die Aufgabe in der Praxis aus“, und sie können Details vermitteln, die in Prosa schwer auszudrücken sind.

Demonstrationen lehren die Aufgabe, nicht nur die Formatierung

Viele Entwickler betrachten Few-Shot-Beispiele lediglich als Hilfsmittel für die Formatierung. Tatsächlich leisten sie mehr. Nehmen wir beispielsweise die Kombination „Die Anwendung ist langsam“ mit dem Label TECHNICAL. Das zeigt nicht nur das Ausgabeformat, sondern auch, wie diese Anwendung die Kategorie TECHNICAL versteht. Beispiele prägen das Verständnis des Modells für die Aufgabe selbst.

Deshalb sind schlechte Beispiele riskant. Inkonsistente Etiketten, unbeabsichtigte Voreingenommenheiten oder Randfälle, die gegen die Richtlinien verstoßen, können alle vom Modell wieder übernommen werden.

Welche Beispiele einzubeziehen

Angesichts von 10.000 historischen Tickets ist es unpraktisch, alle in einen Prompt aufzunehmen, daher muss eine Untermenge ausgewählt werden. Die zufällige Auswahl ist der naive Ansatz. Ein besserer Ansatz berücksichtigt gezielt repräsentative Fälle:

Example 1: straightforward billing issue
Example 2: straightforward technical issue
Example 3: ambiguous issue
Example 4: boundary case
Example 5: short, poorly written request

Was als gute Auswahl gilt, hängt von der Aufgabe ab. Bei der Klassifizierung müssen die Hauptklassen sowie ihre Grenzen dargestellt werden. Bei einer Formatierungsaufgabe sind Beispiele erforderlich, die die gewünschte Struktur zeigen. Bei Aufgaben, die viel Schlussfolgern erfordern, helfen Beispiele, die zeigen, wie das Problem zerlegt oder überprüft werden kann. In jedem Fall verdient ein Beispiel seinen Platz durch die Informationen, die es liefert, und nicht allein durch seine Verfügbarkeit.

Wie viele

Mehr ist nicht automatisch besser. Wenn ein sorgfältig ausgewähltes Beispiel das Verhalten klar macht, können dreißig weitere Beispiele ohne Nutzen Tausende von Tokens hinzufügen und sogar widersprüchliche Muster einbringen. Somit hat das Few-Shot-Prompting denselben Kontextbudget-Druck wie alles andere, und die richtige Anzahl muss durch Testen ermittelt werden.

Hier beginnt die Prompt-Engineering-Methodik, wie experimentelle Arbeit auszusehen. Die Frage lautet nicht mehr, ob ein Prompt besser klingt, sondern ob diese Version bei repräsentativen Testfällen bessere Ergebnisse liefert. Dieser Wandel wird entscheidend, sobald die Bewertung eine Rolle spielt.

Vielfalt der Beispiele

Falls jede Demonstration eine kurze, klare, gut formulierte Anfrage ist, könnte das Modell ein eng gefasstes Muster lernen, das reale Nutzer nicht befolgen. Reale Nachrichten sehen so aus:

"can't login"
"I've been locked out since yesterday"
"Password reset isn't sending me anything"
"login broken after changing phone"

Alle beschreiben das gleiche Problem nur mit sehr unterschiedlichen Worten. Eine gute Menge an Beispielen spiegelt die Vielfalt wider, die die Anwendung erwartet. Das bedeutet nicht, zufällig Beispiele hinzuzufügen, sondern gezielt bedeutungsvolle Unterschiede abzudecken.

Zeigen, was zu vermeiden ist

Bei einigen Aufgaben ist es vorteilhaft, ein gutes Ergebnis mit einem schlechten zu kombinieren, damit das Modell die Grenzen erkennt. Im Support-Fall könnte eine Nachricht darüber, dass ein Paket verspätet angekommen ist, sowohl mit einer akzeptablen als auch mit einer fehlerhaften Zusammenfassung versehen sein:

Input:
"The customer says the package arrived late."
Good output:
"The customer reports that the package arrived late."
Bad output:
"The courier lost the package."
Reason:
The customer did not state that the courier lost it.

Das schlechte Beispiel markiert eine Grenze: Schließen Sie keine Fakten aus, die in der Eingabe nicht erwähnt werden. Negative Beispiele erfordern jedoch Vorsicht. Ein als falsch gekennzeichnetes Beispiel kann versehentlich genau das Verhalten vermitteln, das es verhindern sollte – insbesondere wenn der Unterschied subtil ist. Die Anwendung sollte überprüfen, ob die negativen Beispiele die Ergebnisse verbessern, anstatt einfach davon auszugehen.

Beispiele für die Struktur

Wenn eine Ausgabestruktur schwer zu beschreiben ist, eignen sich Beispiele gut. Angenommen, der Assistent soll mit drei beschrifteten Zeilen antworten: Problem, Beweis und Maßnahme.

Issue: ...
Evidence: ...
Action: ...

Eine funktionierende Demonstration macht diese Gestaltung sofort greifbar:

Input:
"The login token expired after 30 days."
Output:
Issue: Expired authentication token
Evidence: Token expiration is reported after 30 days
Action: Regenerate the authentication token

Es behebt sowohl das Inhaltsmuster als auch die Präsentation. Beispiele sind jedoch nicht immer die richtige Lösung. Wenn eine Software maschinenlesbares JSON mit garantierter Gültigkeit benötigt, kann eine auf ein Schema beschränkte Ausgabefunktion zuverlässiger sein als das Zeigen eines Beispiels an das Modell.

Konsistenz der Beispiele gewährleisten

Few-Shot-Anfragen reagieren schlecht auf Widersprüche. Betrachten Sie zwei Demonstrationen mit derselben Eingabe „Kann mich nicht einloggen“, die in einer mit ACCOUNT und in der anderen mit TECHNICAL versehen sind:

Example 1:
"Can't log in" → ACCOUNT
Example 2:
"Can't log in" → TECHNICAL

Das Modell verfügt nicht über eine eindeutige Methode, um herauszufinden, welche Zuordnung beabsichtigt ist. Auch subtilere Unstimmigkeiten schaden. Wenn einige Beispiele die Bezeichnung „BILLING“ verwenden und andere den Ausdruck „Billing issue“, wird der Ausgabebereich unklar. Bezeichnungen, Formatierung, Terminologie, Detailgrad sowie die Handhabung von Randfällen sollten in allen Beispielen übereinstimmen. Die Demonstrationen sind Teil der Spezifikation und verdienen dieselbe Sorgfalt.

Lernen innerhalb des Fensters

Das In-Context-Lernen ist die grundlegende Idee hinter dem Few-Shot-Prompting: Beispiele befinden sich im aktuellen Kontext, wodurch sich das Verhalten für diese Interaktion ändert. Das bedeutet jedoch nicht, dass das Modell sie dauerhaft aufnimmt. Wenn die Anwendung ein beschriftetes Beispiel sendet und anschließend eine Benachrichtigung des Benutzers über fehlenden Zugriff auf ein Konto erhält:

Example:
"Password reset email never arrived." → ACCOUNT
User:
"I can't access my account."

Das Modell kann die Demonstration für diese Anfrage nutzen. Seine Parameter werden dabei nicht aktualisiert, und das Beispiel wird nicht zu seinem dauerhaften Wissen hinzugefügt. Dies spiegelt die zuvor beschriebene Trennung zwischen Kontext und Speicher wider. Methoden, die Parameter ändern, wie zum Beispiel Feinabstimmung an zusätzlichen Trainingsdaten, stellen einen separaten Mechanismus dar, und ihr Vergleich mit Prompting kommt erst viel später. Vorerst sollte das Few-Shot-Prompting am besten als vorübergehende Aufgabekonditionierung durch den Kontext betrachtet werden.

Entscheidung zwischen den beiden Ansätzen

Ein praktikabler Entscheidungsprozess beginnt damit, genau zu beschreiben, warum die Ausgabe fehlerhaft ist. Eine unklare Aufgabe erfordert präzisere Formulierungen. Fehlende Informationen erfordern einen besseren Kontext. Wenn das Modell eine subtile Konvention übersehen hat, können Beispiele hilfreich sein. Wenn die Aufgabe genaue Arithmetik oder Datenbankzugriff erfordert, kann mehr Prosa im Prompt völlig falsch sein.

Der letzte Fall führt in schwierigeres Gebiet. Einige Aufgaben sind zu kompliziert, um zuverlässig mit einer einzigen Anweisung und einer einzigen Antwort bewältigt zu werden. Sie müssen in kleinere Schritte aufgeteilt, überprüft oder mit externen Berechnungen verknüpft werden. Ab einem bestimmten Punkt besteht die Herausforderung nicht mehr darin, den perfekten Satz zu finden, sondern vielmehr darin, ein kleines Verfahren zu entwerfen, das das Modell befolgen kann.

Betrachten Sie ein Ticket, bei dem ein Kunde unmittelbar nach einem Passwortwechsel nicht mehr ins System gelangt, und dem Assistenten gesagt wird, er solle die Vorgeschichte durchgehen, die wahrscheinliche Ursache ermitteln und anschließend antworten. Das sieht wie eine einzige Aufgabe aus. In Wirklichkeit verbirgt sich dahinter mehrere: herausfinden, was passiert ist, relevante Beweise suchen, Fakten von Annahmen trennen, über mögliche Ursachen nachdenken, entscheiden, was sicher empfohlen werden kann, diese Empfehlung überprüfen und schließlich die endgültige Antwort verfassen. Das Erkennen dieser Aspekte ist der Einstieg zur Aufteilung der Aufgabe.

Ein Auftrag in mehrere Aufgaben aufteilen

Durch die Aufteilung wird eine komplexe Aufgabe durch mehrere kleinere Aufgaben mit klaren Grenzen ersetzt. Anstatt alles auf einmal zu verlangen, kann die Anwendung die Anfrage in Schritten darstellen:

Task:
Analyze this customer support case.

Step 1:
Extract the relevant facts.

Step 2:
Identify the customer's actual problem.

Step 3:
List plausible causes supported by the evidence.

Step 4:
Select the safest supported resolution.

Step 5:
Draft the customer-facing response.

Das Modell benötigt buchstäblich nicht das Wort „Schritt“. Entscheidend ist, dass ein vager Zielzustand in eine Abfolge von handhabbaren Aufgaben umgewandelt wurde. Dies hilft am meisten, wenn die einzelnen Komponenten unterschiedliche Eigenschaften haben: Das Extrahieren von Fakten ist eine Informationsaufgabe, die Auswahl einer Diagnose ist ein Schlussfolgern, und das Verfassen der Nachricht ist Kommunikation. Sie in einer einzigen, nicht differenzierten Anweisung zusammenzufassen, erschwert es, das Ergebnis zu steuern und zu bewerten.

Ein zerlegtes System bietet außerdem mehr Möglichkeiten zum Testen. Wenn die endgültige Antwort falsch ist, kann man prüfen, ob bei der Faktenerfassung, bei der Diagnosestellung oder beim Verfassen der Antwort ein Fehler aufgetreten ist. Der Denkansatz ändert sich dadurch, dass ein Prompt wie ein Prozessfluss aufgebaut werden kann und nicht nur wie eine Frage formuliert werden muss.

Zuerst planen, dann handeln

Eine verwandte Technik fordert das Modell auf, einen Plan zu erstellen, bevor es eine komplexe Aufgabe ausführt. Dies hilft, wenn das Modell entscheiden muss, welche Operationen erforderlich sind, bevor es antworten kann. Der Support-Assistent kann mit einem Ziel und einem geordneten Plan beginnen:

Goal:
Resolve the customer's login problem using only supported evidence.
Plan:
1. Read the latest customer message.
2. Check the relevant conversation history.
3. Identify authentication-related evidence.
4. Compare the evidence with the known troubleshooting guidance.
5. Produce a response that does not claim unsupported facts.

Planung trennt die Entscheidung darüber, wie etwas gelöst werden soll, von der tatsächlichen Lösung. Diese Trennung wird bedeutender, sobald Werkzeuge zum Einsatz kommen, da das Modell möglicherweise feststellen muss, dass es zunächst in einer Wissensdatenbank suchen, ein Kontoinformationen prüfen oder eine Berechnung durchführen sollte. Anleitungen können die Struktur der Arbeit bereits vor Beginn festlegen.

Dafür entstehen Kosten. Die Aufteilung in Schritte verlängert die Länge der Anweisungen, und wenn jeder Schritt eine eigene Aufrufoperation darstellt, entstehen zusätzliche Modellaufrufe sowie Verzögerungen. Ein fünfstufiger Prozess kann weitaus teurer sein als ein einziger Aufruf. Es lohnt sich, wenn die zusätzliche Kontrolle und Zuverlässigkeit den Aufwand rechtfertigen – nicht, weil mehr Schritte per se besser sind.

Erstellen, kritisieren, überarbeiten

Ein weiteres effektives Muster ermöglicht es dem Modell, nochmals seinen eigenen Entwurf zu prüfen. Die erste Antwort gilt nicht als endgültig; bei einer zweiten Überprüfung wird sie anhand expliziter Kriterien geprüft. Für das Unterstützungssystem bedeutet das, zunächst die Antwort zu entwerfen und anschließend den Entwurf anhand einer Liste benannter Probleme zu überprüfen:

First:
Draft the response.

Then:
Check the draft for:
- unsupported claims,
- missing evidence,
- incorrect troubleshooting steps,
- promises the support team cannot make,
- failure to answer the customer's actual question.

Finally:
Revise the response to correct any problems.

Dies funktioniert, weil Erstellen und Beurteilen unterschiedliche Aufgaben sind. Erstellen bedeutet, etwas Plausibles zu konstruieren. Die Überprüfung einer vorhandenen Antwort ermöglicht es dem Modell, nach Verstößen gegen eine Checkliste zu suchen. Die Kriterien klar zu formulieren ist in der Regel wirksamer, als es einfach dazu aufzufordern, intensiver nachzudenken.

Das Muster lässt sich auf unterschiedliche Tiefebenen anwenden: Entwurf, Überprüfung, endgültige Antwort – oder bei einer strukturierteren Aufgabe: Extrahieren, die Extraktion überprüfen, klassifizieren, die Klassifizierung überprüfen, erzeugen. Die zweite Form ist leichter zu debuggen, da jede Phase einen definierten Ablauf hat.

Eine Grenze ist von Bedeutung: Ein Modell, das aufgefordert wird, sich selbst zu kritisieren, ist dadurch keine unabhängige Quelle der Wahrheit. Wenn die ursprüngliche Antwort auf einer falschen Annahme beruht, kann der Kritiker diese ebenfalls teilen. Selbstkritik kann die Konsistenz verbessern, ohne die Richtigkeit zu garantieren; bei entscheidenden Entscheidungen lohnt es sich daher, die Ergebnisse mit etwas außerhalb des Modells zu überprüfen – beispielsweise mit einer Datenbank, einer bekannten Regel, einer Berechnung, einem abgerufenen Dokument oder deterministischem Code.

Aufforderungen, die die Denkstruktur offenlegen

Forschungen zu sogenannten „Chain-of-Thought“-Aufforderungen haben gezeigt, dass das Zeigen von Beispielen mit Zwischenschritten im Denkprozess die Ergebnisse bei einigen mehrschrittigen Problemen verbessern kann – mit Verbesserungen in arithmetischen, gesunden Menschenverstandsbasierten sowie symbolischen Tests. Die daraus resultierende Erkenntnis für die Ingenieurwissenschaft ist umfassender: Eine komplexe Aufgabe profitiert, wenn die Aufforderung ihre Zwischenschritte explizit macht:

Identify the relevant facts.
Determine which facts support each possible conclusion.
Eliminate conclusions that require unsupported assumptions.
Select the conclusion supported by the evidence.

Das ist anschlussorientiertes Prompting: Die Aufgabe wird so gestaltet, dass die Zwischenergebnisse klar genug sind, um das Modell zum gewünschten Ergebnis zu lenken. Es zwingt eine Anwendung nicht, dem Benutzer die internen Überlegungen des Modells anzuzeigen. Oft ist eine bessere Benutzeroberfläche so konzipiert, dass sie das Ergebnis der Überprüfung anfordert, statt eine lange Erklärung. Die Anwendung kann eine kompakte interne Aufzeichnung wie die unten gezeigte verwenden und anschließend eine kurze Antwort für den Kunden separat erstellen:

classification: password_reset_issue
evidence_supported: true
recommended_action: resend_reset_link
confidence: high

Die Struktur der Argumentation und die für den Kunden zugängliche Erklärung sind getrennte Anforderungen. Sie voneinander zu trennen verhindert außerdem einen häufigen Fehler, nämlich anzunehmen, dass eine sichtbarere Argumentation eine zuverlässigere Antwort ergibt. Auch Zwischenschritte können Fehler enthalten. Studien zu Chain-of-Thought-Prompting haben gezeigt, dass Eigenschaften der Demonstrationen, wie ihre Relevanz und Reihenfolge, von großer Bedeutung sind; daher ist das Einfügen langer Begründungen kein universelles Heilmittel.

Mehrere Versuche, anschließend Abstimmung

Die Erzeugung ist probabilistisch, sodass ein und derselbe Problem bei verschiedenen Durchläufen unterschiedliche Antworten liefern kann. Selbstkonsistenz nutzt dies aus, indem sie mehrere Argumentationswege auswählt und die Antwort wählt, die von den meisten unterstützt wird, anstatt sich auf einen einzigen ausgewählten Weg zu verlassen.

Nehmen wir an, das Support-System ist sich nicht sicher, ob es sich um ein Problem mit der Passwortrücksetzung oder um ein Konto-Lockout handelt. Anstatt sich für eine einzige Klassifizierung zu entscheiden, könnte es mehrere Analysen erstellen und die daraus resultierenden Klassifizierungen miteinander vergleichen.

Auch bei Übereinstimmung fehlt es noch an Genauigkeit. Wenn das Modell die Situation konsequent falsch einordnet, können viele unabhängige Analysen zum selben falschen Ergebnis kommen. Konsistenz ist ein Zeichen für Stabilität, aber kein Beweis für Richtigkeit. Zudem verursacht sie mehr Rechenleistung und verlängert die Latenzzeit, wodurch sie nur für Aufgaben attraktiv ist, die so schwierig sind, dass der Gewinn an Zuverlässigkeit die damit verbundenen Kosten rechtfertigt.

Wo Anfragen an Code übergeben werden sollten

Hier liegt die Grenze zwischen immer ausgefeilteren Anfragen und gutem Systemdesign. Stellen Sie sich vor, man möchte die Gesamtsumme einer Rechnung mit 17 Positionen à ₹1500 ermitteln. Ein Modell kann diese Summe wahrscheinlich berechnen, doch wenn eine genaue finanzielle Angabe entscheidend ist, gibt es keinen Grund, es dazu zu zwingen, durch immer längere Anweisungen Arithmetik zu simulieren. Ein Taschenrechner oder ein gewöhnliches Programm multipliziert dabei deterministisch.

Die gleiche Logik gilt für andere Aufgaben:

• Kontodaten sollten aus einer Datenbankabfrage stammen, nicht aus dem Gedächtnis des Modells.
• Aktuelle Fakten sollten abgerufen werden, nicht aus der Trainingsdatenbasis wiederhergestellt.
• Arithmetische Berechnungen gehören zu einem Taschenrechner oder Programm.
• Die Überprüfung eines Schemas ist Aufgabe eines Parsers und Validators.
• Authentifizierung und Berechtigungssteuerung obliegen dem Anwendungscode sowie den Zugriffsregeln.
• Kritische Geschäftsregeln sollten soweit wie möglich deterministisch kodiert werden.

Es gilt eine nützliche Regel: Nutzen Sie Anfragen, um das Verhalten von Sprachmodellen zu steuern, und wenden Sie deterministische Software an, wenn die Aufgabe tatsächlich eine deterministische Berechnung oder Durchsetzung erfordert.

Externe Aktionen verdeutlichen diesen Punkt noch weiter. ReAct, ein bekanntes Forschungsansatz, kombiniert Schlussfolgerungen mit Aktionen, sodass ein Modell auf externe Quellen oder Umgebungen zurückgreifen kann, anstatt sich nur auf interne Kenntnisse zu verlassen. Dabei zeigte sich, dass eine solche Interaktion Probleme wie Halluzinationen und Fehlerverbreitung bei bestimmten Aufgaben verringern kann.

Das ist die Brücke zu dem, was kommt. Das Unterstützungssystem begann als Prompt und ähnelt nun einem kleinen Programm. Sobald die Überprüfung eine Datenbank, eine Wissensdatenbank, eine API oder eine andere externe Funktion benötigt, arbeitet das Modell nicht mehr nur mit Text, und die Frage rückt auf das Kontextengineering: Es geht nicht nur darum, welche Anweisungen geschrieben werden sollen, sondern auch, welche Informationen das Modell erhalten sollte.