Lernen aus realen Erfahrungen

Wie Benutzer in der realen Welt mit unseren Produkten interagieren, ist eine wertvolle Quelle für das Modelltraining. Die Daten sind reichlich vorhanden, spiegeln die tatsächliche Verteilung der Benutzeraufgaben wider und erfassen Benutzerkorrekturen und Werkzeugfehler, die synthetische Umgebungen möglicherweise übersehen.

Ein gängiger Weg, aus realen Daten zu lernen, ist Rejection Sampling Fine-Tuning: das Ergebnis jeder Sitzung bewerten, die erfolgreichen behalten und das Modell darauf trainieren, sie nachzuahmen. Ein erfolgreiches Ergebnis bedeutet jedoch nicht, dass jeder Schritt korrekt war; daher birgt das Nachahmen der gesamten Trajektorie das Risiko, schlechte Zwischenverhaltensweisen zusätzlich zu guten zu verstärken. Das Verwerfen erfolgloser Sitzungen führt zudem zum Verlust kritischer Belege dafür, wo das Modell hinter den Erwartungen zurückbleibt.

Wir kombinieren Rejection Sampling Fine-Tuning mit hinweisgeleiteter Selbst-Distillation (Hint-Guided Self-Distillation), um aus erfolgreichen und nicht erfolgreichen Sitzungen zu lernen. Ein Hinweis (Hint) ist eine kurze korrigierende Anweisung, die auf Informationen basiert, die dem Modell bereits beim Unterlaufen des Fehlers vorlagen. Nützliche Schritte aus erfolgreichen Sitzungen bleiben Nachahmungsziele, während begründete Hinweise vermeidbare Fehler in Korrekturziele verwandeln.

Benutzerkorrekturen und Werkzeugfehler fügen Überwachung darüber hinzu, was auf dem Weg schiefgegangen ist – zusätzlich zu der Frage, ob die Aufgabe letztendlich erfolgreich war. Wir wenden diese Stufe nach dem Reinforcement Learning in synthetischen Umgebungen an, um dazu beizutragen, die Lücke zwischen diesen Umgebungen und der realen Nutzung zu schließen.

Im Live-Einsatz reduzierte ein nachträglich trainierter GLM-5.2-Prüfpunkt (Checkpoint) die Tool-Call-Fehler um 21,2 % im Vergleich zu einem früher trainierten Prüfpunkt. Bei GLM-5.3 reduzierte das Post-Training die Tool-Call-Fehler um 33,0 % und die durchschnittliche geschätzte Wahrscheinlichkeit einer mittleren bis hohen Unzufriedenheit der Nutzer um 17,2 % im Vergleich zum Standardmodell.

Synthetische Aufgaben ermöglichen uns die Erstellung kontrollierter Probleme mit Ergebnissen, die sich leicht überprüfen lassen, beschränken sich jedoch typischerweise auf einen einzigen Prompt und können nur Szenarien abdecken, die wir ausdrücklich entwerfen.

Im Gegensatz dazu bringen Benutzer in realen Sitzungen diverse Anweisungen, Kontexte und Werkzeugkombinationen in Sitzungen ein, die sich über mehrere Interaktionsrunden entfalten. Solche realen Nutzungen liefern natürlicherweise zwei wertvolle Signale für Fehler: Benutzerkorrekturen offenbaren, wo der Agent nicht das geliefert hat, was sie wollten, und Werkzeugfehler zeigen, wo seine Aktionen in realen Umgebungen zusammenbrachen. Unsere Stichprobenpipeline respektiert die Privatsphäre und die Wahlmöglichkeiten der Benutzer bezüglich des Trainings, indem sie Sitzungen mit personenbezogenen Daten (PII) und von Benutzern, die sich gegen das Training entschieden haben, ausschließt.

Reale Daten liefern uns daher Fehlerfälle, die eine synthetische Umgebung möglicherweise nicht offenbart, und bringen häufig bereits den Ort des aufgetretenen Fehlers mit.

Beim Training mit realen Daten wählt das standardmäßige Rejection Sampling Fine-Tuning (RFT) erfolgreiche Sitzungen anhand ihrer Endergebnisse aus, ohne explizit Benutzer- und Werkzeugfeedback zu nutzen, um gute Zwischenaktionen von schlechten zu unterscheiden. Ein Agent kann sich von einem schlechten Werkzeugaufruf erholen oder einen Fehler nach Benutzerfeedback korrigieren und am Ende dennoch die richtige Ausgabe liefern.

Das Verwerfen fehlgeschlagener Sitzungen schränkt zudem die Stichprobeneffizienz ein. Eine Sitzung, die nie zu einem guten Ergebnis führt, könnte dennoch einen klaren, vermeidbaren Fehler als nützliches Trainingssignal offenbaren.

Wir begegnen diesen Einschränkungen, indem wir zwei Entscheidungen trennen: Welche Sitzungen enthalten nachahmenswertes Verhalten und welche Runden enthalten zu korrigierende Fehler. Die Datenpipeline trifft diese Entscheidungen separat und weist Modellrunden dann eine von drei Behandlungen zu:

Nachahmen: Nicht-Fehler-Runden in erfolgreichen Sitzungen erhalten gewöhnlichen Cross-Entropy-Verlust (CE-Verlust), wodurch die Wahrscheinlichkeit aufgezeichneter Token erhöht wird.
Korrekt: In sowohl erfolgreichen als auch erfolglosen Sitzungen erhalten Fehlerrunden mit einem gültigen Hinweis einen Kullback-Leibler-Divergenzverlust (KL-Verlust), wodurch das Modell in Richtung der Vorhersagen für das nächste Token bewegt wird, die es trifft, wenn es den Hinweis sieht.
Als Kontext behalten: Runden in erfolglosen Sitzungen ohne validierten Hinweis sowie markierte fehlerhafte Runden ohne validierten Hinweis in beiden Sitzungstypen dienen als Kontext, erhalten jedoch keinen der beiden Verluste.

Infolgedessen können erfolgreiche Sitzungen sowohl Nachahmungs- als auch Korrekturziele liefern, während erfolglose Sitzungen nur Korrekturziele liefern. Alle verbleibenden Runden, einschließlich System-, Benutzer- und Werkzeugausgabe, verbleiben als Kontext.

Sitzungs-Routing-Diagramm: Erfolgreiche Sitzungen bieten CE-Nachahmung und berechtigte, mit Hinweisen versehene Korrekturen; erfolglose Sitzungen bieten nur berechtigte Korrekturen. — Aktuelles Sitzungs-Routing und Masken für Assistenteninhalte. Erfolgreiche Sitzungen tragen zu Nachahmungszielen bei; aufbewahrte Feedback-Datensätze können auch dann mit Hinweisen versehene Korrekturen beisteuern, wenn die Sitzung erfolglos war. Anderer Inhalt bleibt als Kontext erhalten. Unvollständige Sitzungen sind ausgeschlossen. Die nicht finale Yield/Stop-Token-CE-Ausnahme ist nicht eingezeichnet, und dieses Diagramm begründet nicht die Mischung, die von einem früheren Checkpoint verwendet wurde.

Der Nachahmungsteil verwendet das standardmäßige RFT. Der korrigierende Teil verwendet On-Policy Self-Distillation (OPSD): Dasselbe Modell fungiert als Lehrer und Schüler, wobei dem Lehrer privilegierte Informationen gegeben werden. Hier sind diese privilegierten Informationen ein kurzer Hinweis, der einen vermeidbaren Fehler erklärt. Wir trainieren den Schüler so, dass er die Vorhersagen des Lehrers für das nächste Token anpasst, ohne dass ihm der Hinweis ausgehändigt wird.

Beide Teile sind wichtig. Ein reines Korrekturen-Training kann eine Abkürzung aufdecken: Lehrer und Schüler können sich einigen, indem sie den Kontext ignorieren, anstatt die Korrektur zu lernen. Der CE-Term verankert das Training in nützlichem Verhalten und hilft dabei, eine Einigung zu verhindern, die durch das Ignorieren des Kontexts entsteht.

Der nachgetrainierte Schüler wird daraufhin zu einer Modelloption in Computer. Frische Sitzungen aus der Live-Nutzung passieren dieselben Berechtigungs- und Datenschutzfilter, bevor sie in eine weitere Runde der Trainingspipeline eintreten.

Als Nächstes gehen wir ein konkretes Beispiel durch, das sowohl Nachahmung als auch Korrektur enthält.

Betrachten wir eine letztlich erfolgreiche Sitzung, in der der Benutzer unter Verwendung der offiziellen Dokumentation um einen Vergleich von asyncio-Änderungen in Python 3.13 bittet. Unsere Werkzeugdokumentation besagt, dass search.web eine Liste von Treffern zurückgibt, von denen jeder ein url-Feld aufweist.

Das Modell führt zunächst eine gültige Suche nach einer Version als Teil der Beweissammlung für den Vergleich durch, was ein nachahmenswertes Verhalten ist.

Der nächste Codeausführungsaufruf behandelt diese Liste jedoch fälschlicherweise als Wörterbuch. Das Code-Werkzeug gibt TypeError: list indices must be integers or slices, not str zurück. Da der Rückgabetyp vor dem Aufruf dokumentiert wurde, handelt es sich um einen Fehler, den das Modell hätte vermeiden können müssen. Zur Korrektur dieser Aktion kann ein Hinweis mit dem richtigen Aufruf generiert werden.

Veranschaulichende Codierungs-Sitzung: System- und Benutzereingaben sowie Werkzeugfehler bleiben Kontext; nützliche aufgezeichnete Such- und Wiederherstellungsaufrufe erhalten CE in einer erfolgreichen Sitzung; eine markierte fehlerhafte Listenabfrage erhält KL hin zu einem Lehrer, dem ein begründeter Hinweis gegeben wurde. — Eine veranschaulichende Codierungs-Sitzung zeigt drei Trainingsrollen: nur auf Kontext bezogene Eingaben und Werkzeugausgaben (grau), CE-Nachahmung nützlicher aufgezeichneter Aufrufe (dunkel) und KL-Korrektur eines markierten Fehlers (türkis). Hier behandelt das Modell eine Liste von Suchetreffern fälschlicherweise als Wörterbuch; ein reiner Lehrerhinweis, der auf früherer Werkzeugdokumentation basiert, leitet die Korrektur an. CE-Ziele gelten nur dann, wenn die abgeschlossene Sitzung als erfolgreich bewertet wird, während eine erfolglose Sitzung dennoch ein berechtigtes KL-Korrekturziel liefern kann.

Die Trainingspipeline hat vier Stufen: Sitzungen auswählen und ihre Ergebnisse bewerten, Fehler identifizieren und Hinweise aus Benutzerfeedback und Werkzeugfehlern erstellen, Wahrscheinlichkeiten für das nächste Token sowohl vom Lehrer als auch vom Schüler generieren und das Modell mit einem kombinierten CE- und KL-Verlust trainieren.

Die Sampling-Pipeline bezieht sich aus einem trainingsberechtigten Teilmengenbestand realer Computer-Sitzungen, die von GLM 5.2 ausgeliefert werden. Training-Opt-outs und die PII-bezogenen Ausschlüsse der Pipeline werden vor der Auswahl von Beispielen für diesen Workflow angewendet.

Der anfängliche Screening-Prozess wählt Kandidaten aus, die von einem LLM-Prüfer auf einer fünfstufigen Schwierigkeitsskala mit 4 oder 5 bewertet wurden, und unterteilt sie in 2 Gruppen:

Die Benutzerfeedback-Gruppe enthält Sitzungen mit einem echten Benutzer-Follow-up oder einem Flag für mittlere bis hohe Unzufriedenheit. Wir finden diese Follow-ups mit hoher Absicht besonders nützlich zum Lernen: Benutzer versuchen aktiv, eine Aufgabe zu vervollständigen, und ihre Korrekturen pinpointergen, was das Modell verpasst hat.
Die Werkzeugfehler-Gruppe enthält Sitzungen mit fehlgeschlagenen Aufrufen, die durch regelbasierte Prüfungen markiert wurden, ausgenommen erkannte Infrastrukturausfälle und verweigerte Autorisierungen.

Zwei LLM-Prüfer bewerten dann das endgültige Ergebnis anhand der Anfrage des Benutzers; beide Prüfer müssen ein positives Urteil abgeben, damit die Sitzung als „erfolgreich“ eingestuft wird. Bei Fällen, in denen Artefakte geliefert werden, kann die Ergebnisphase das Ergebnis rekonstruieren und überprüfen; schlägt diese Phase fehl, greift sie auf ihre textbasierten Beurteilungen zurück. Als unvollständig eingestufte Sitzungen, wie etwa Arbeiten, die auf den Benutzer warten, werden ausgeschlossen.

Dieser Schritt identifiziert potenzielle Quellen für Lernsignale; allerdings ist nicht jeder Fehler dem Modell zuzuschreiben, da einige aus mehrdeutigen Anweisungen oder Infrastrukturausfällen resultieren. Eine spätere Annotation bestimmt, welche Kandidatenfehler tatsächlich vermeidbar und für das Training geeignet sind.

Betrachten wir eine Beispiel-Sitzung aus der Nutzerfeedback-Gruppe, in der der Benutzer fragt: „How do I find my w3 on paychex“. Das Modell behandelt „w3“ als Tippfehler für W-2, sucht nach W-2-Anweisungen und erklärt, wie man dieses Formular findet. Der Follow-up des Benutzers „I meant the W-3 transmittal form,“ identifiziert den Fehler, selbst wenn die Sitzung letztendlich erfolgreich verläuft.

Die Beschwerde hilft dabei, den Fehler zu lokalisieren, aber die Grundursache ist die frühere Entscheidung, „w3“ als W-2 zu uminterpretieren. Die ursprüngliche Anfrage macht den Fehler vermeidbar: Das Modell hätte W-3 beibehalten oder nach Klarstellung fragen können. Es stellt sich heraus, dass die letzte Assistentenrunde vor der Beschwerde nur in etwa der Hälfte der Fälle die Grundursache ist.

Unsere Annotationspipeline bildet Ursache und Wirkung innerhalb jeder Nutzerfeedback-Sitzung systematisch ab. Der Annotator filtert zunächst nach einer verpassten Anforderung oder einer Absicht, die durch früheren Kontext gestützt wird. Drei LLM-Prüfer identifizieren dann die verantwortlichen Runden, wobei mindestens zwei bezüglich einer bestimmten Runde übereinstimmen müssen. Manchmal begründet eine frühere Aussage die Anforderung ausdrücklich. In anderen Fällen tut dies keine einzelne vorherige Aussage allein, aber mehrere Teile des vorangegangenen Gesprächs machen das beabsichtigte Verhalten gemeinsam ableitbar. Dieses Design ermöglicht es ihnen, eine Beschwerde mit einem früheren Ursachenfehler zu verknüpfen, anstatt sie ausschließlich der letzten Antwort zuzuschreiben.

Vor der Annahme eines Hinweises prüft die Pipeline zudem, ob dessen korrigierende Behauptungen aus Informationen folgen, die vor der markierten Runde verfügbar waren. Diese Prüfungen sollen Hindsight Bias reduzieren, bei dem eine in der Beschwerde offenbarte neue Präferenz als etwas behandelt wird, das das Modell bereits hätte wissen müssen.

In diesem Beispiel weist der Hinweis das Modell an, auf Paychex nach dem W-3-Übermittlungsformular statt nach W-2 zu suchen oder zu fragen, welches Formular der Benutzer meint, wenn die Anfrage mehrdeutig ist. Die Korrektur zielt auf die frühere Interpretation und Suchentscheidung ab, nicht nur auf die endgültige Antwort. Die ursprüngliche Runde bleibt unverändert; die Annotation fügt is_bad_turn: true und einen nicht leeren hint hinzu.

Eine W-3-Anfrage wird als W-2 falsch interpretiert; eine spätere Beschwerde wird auf die frühere Suchentscheidung zurückgeführt und anhand früherer Belege überprüft. — Eine reale Sitzung, die zeigt, wie eine Beschwerde auf einen früheren Fehler zurückgeführt wird, überlagert mit dem Annotationsverfahren. Der Benutzer fragte nach „w3“ auf Paychex, aber das Modell behandelte dies als Tippfehler für W-2 und suchte nach dem falschen Formular. Der Konsens der Vorschlagenden lokalisiert die Grundursache, während zwei Erdungsprüfungen bewerten, ob die Belege dem Fehler vorausgehen und die Behauptungen des Hinweises aus Informationen folgen, die zu diesem Zeitpunkt verfügbar waren. Akzeptierte Annotationen bewahren den Originaltext und fügen Markierungen und Hinweise hinzu, anstatt umgeschriebene Ziele.

Betrachten wir eine weitere Sitzung in der Werkzeugfehler-Gruppe mit einem Suchaufruf, bei dem der Agent mit recency_filter: "year" sucht, das Werkzeug dies jedoch ablehnt, da die erlaubten Werte „day“, „week“ oder „month“ sind. Dies ist ein klarer Schemaverstoß.

Der Pfad für Werkzeugfehler verwendet deterministische Regeln für bekannte Fehler und Modellurteile für mehrdeutige Fälle. Eine Fehlermeldung allein reicht ebenfalls nicht aus, um dem Modell die Schuld zu geben; eine beurteilte Korrektur muss auf etwas verweisen, das das Modell aus dem Werkzeugschema, den Systemanweisungen oder dem früheren Gespräch hätte wissen können.

Ein Suchaufruf verwendet den ungültigen recency_filter-Wert „year“; ein begründeter Hinweis weist das Modell an, einen aufgelisteten Wert zu verwenden oder ein optionales Feld wegzulassen. — Das ungültige Suchargument des Berichts veranschaulicht das aktuelle Verfahren für Werkzeugfehler. Das Schema macht diesen Fehler vermeidbar; ein Ausfall allein würde dies nicht tun. Der ursprüngliche Aufruf verbleibt im Datensatz und erhält einen begründeten Hinweis. Der Hinweis erlaubt einen aufgelisteten Wert oder das Weglassen, wenn das Feld optional ist; er erfordert nicht für jede Anfrage „month“.

Hier benennt der Hinweis den fehlgeschlagenen Aufruf, enthält den Validierungsfehler und weist das Modell an, einen erlaubten Wert zu verwenden oder das Feld wegzulassen, wenn es optional ist.

Sobald eine Interaktion markiert ist, führt der Trainer denselben Checkpoint zweimal aus: einmal als Lehrer und einmal als Schüler. Der Lehrer sieht den Hinweis; der Schüler sieht ihn nicht.

Beide Durchläufe verwenden Teacher Forcing, bei dem wir dem Modell die aufgezeichnete Sitzung füttern, anstatt es neue Token auswählen zu lassen. Der Vorwärtsdurchlauf erzeugt bei jedem Schritt nach wie vor eine vollständige Verteilung des nächsten Tokens, ist jedoch stets an das feste Präfix aus der Aufzeichnung bedingt, nicht an Rollout-Token.

Für das Suchbeispiel weist dasselbe Modell bei vorgegebenem Hinweis „month“ eine viel höhere und „year“ eine geringere Wahrscheinlichkeit zu. Das Training nutzt diese distributionale Verschiebung als weiches Ziel.

Dasselbe Modell bewertet eine protokollierte Runde mit und ohne Hinweis; abgekoppelte Lehrer-Wahrscheinlichkeiten liefern KL-Ziele, während CE die Nachahmung verankert. — Zwei Durchläufe, ein Satz Gewichte. Beide Durchläufe bewerten die protokollierte Fortsetzung; nur der Lehrer erhält Hinweise. Seine abgekoppelten Wahrscheinlichkeiten für das nächste Token leiten den Schüler durch Forward-KL. Separate CE-Ziele verankern die Nachahmung. Beide Verluste speisen ein Gewichtsupdate. Fröhliche Hinweise verbleiben möglicherweise im aktuellen Segment des Lehrers; keiner der Durchläufe generiert eine Ersatz-Trainingsantwort.

Die Vorhersagen des Lehrers sind abgekoppelt oder Stop-Gradient: Sie liefern ein Ziel, erhalten jedoch kein Update durch den Lehrer-Durchlauf. Nach dem Durchlauf des Schülers aktualisiert ein Optimierungsschritt das gemeinsame Modell.

Der CE-Verlust behandelt die aufgezeichneten Token, die zur Nachahmung ausgewählt wurden, als Ground-Truth-Ziele und bestraft das Modell dafür, dass es ihnen niedrige Wahrscheinlichkeiten zuweist. Dies erzeugt ein hartes Nachahmungsziel.

Sei bei Token-Position $i$ $p_i(v)$ die Wahrscheinlichkeit des Schülers für Token $v$ im gesamten Vokabular $V$ . Das aufgezeichnete nächste Token in der Antwort oder im Werkzeugaufruf ist $y_i$ , die One-Hot-Zielverteilung ist $r_i$ .

r_i(v)=\mathbf{1}[v=y_i]

Die Kreuzentropie misst, wie gut der Schüler dieses aufgezeichnete Token vorhersagt. Mit einem One-Hot-Ziel reduziert sie sich auf die negative Log-Wahrscheinlichkeit, die $y_i$ zugewiesen wird.

H(r_i,p_i)=-\sum_{v\in V}r_i(v)\log p_i(v)=-\log p_i(y_i)

Die CE-Maske $m_i^{\mathrm{CE}}$ ist $1$ , wo das Token nachgeahmt werden soll, und $0$ andernfalls. Durch Summieren über die ausgewählten Positionen erhält man den Nachahmungsverlust.

\mathcal{L}_{\mathrm{CE}}=\sum_i m_i^{\mathrm{CE}}H(r_i,p_i)

Der KL-Verlust verwendet stattdessen die vollständige Token-Wahrscheinlichkeitsverteilung des nächsten Tokens des Lehrers $q_i$ als weiches Korrekturziel. Der Kontext des Lehrers umfasst den aktuellen Hinweis und alle früheren Hinweise, die in diesem Trainingssegment beibehalten wurden; der Kontext des Schülers ist immer hinweisfrei.

Die KL-Maske $m_i^{\mathrm{KL}}$ ist $1$ , wo das Token korrigiert werden soll, und $0$ andernfalls; die CE- und KL-Masken überlappen sich nicht. An diesen Positionen bestraft der Forward-KL Uneinigkeit zwischen Lehrer und Schüler über das gesamte Vokabular hinweg:

\mathcal{L}_{\mathrm{KL}}=\sum_i m_i^{\mathrm{KL}}D_{\mathrm{KL}}(q_i\Vert p_i)=\sum_i m_i^{\mathrm{KL}}\sum_{v\in V}q_i(v)\log\frac{q_i(v)}{p_i(v)}

Beide Terme teilen sich einen Nenner, anstatt separat normalisiert zu werden. Dieser Nenner zählt die Gesamtzahl der Token, die im globalen Trainings-Batch für die Nachahmung ausgewählt wurden. Das Gewicht $\lambda$ steuert den Beitrag des korrigierenden Trainings relativ zur Nachahmung.

Diese gemeinsame Normalisierung passt zur Ein-Nenner-Schnittstelle unserer Trainingsinfrastruktur und stellt den Standard-SFT-Verlust wieder her, wenn $\lambda=0$ vorliegt, was Basislinienvergleiche vereinfacht. Da CE-Token weitaus häufiger vorkommen als KL-Token, vermeidet die Verwendung eines gemeinsamen Nenners zudem, dass einzelnen KL-Token in Batches mit wenigen markierten Token ein unverhältnismäßig großes Gewicht verliehen wird.

\mathcal{L}=\frac{\mathcal{L}_{\mathrm{CE}}+\lambda\mathcal{L}_{\mathrm{KL}}}{\sum_i m_i^{\mathrm{CE}}}

Auf die früheren Beispiele angewendet, erhalten die Runden, die die W-3/W-2-Verwechslung und den ungültigen Suchaufruf enthalten, KL. Andere nicht markierte Assistenteninhalte in einer erfolgreichen Sitzung erhalten weiterhin CE. Andere Assistenteninhalte in einer erfolglosen Sitzung werden als Kontext beibehalten, erhalten jedoch weder CE noch KL.

Unsere Evaluierungen beantworten zwei verschiedene Fragen. Erstens: Hilft ein Hinweis dem Modell tatsächlich, einen Fehler zu korrigieren, wenn der Hinweis vorhanden ist? Zweitens: Hilft das Training dem Modell, diesen Fehler später ohne den Hinweis zu vermeiden? Ersteres testet, ob Hinweise nützliche Trainingssignale liefern. Letzteres testet, ob das Modell aus ihnen lernt.

Wir testen die erste Frage vor dem Trainingslauf, um sicherzustellen, dass Hinweise das Modell tatsächlich von den Fehlern wegsteuern können.

Wir haben markierte Nutzerfeedback-Runden mit und unter Verwendung desselben GLM-5.2-Basismodells bei Temperatur null regeneriert. Ein blinder Prüfer sieht die spätere Beschwerde, aber weder den Hinweis noch die Bedingung, die die Antwort erzeugt hat.

Im W-3-Beispiel verschiebt der Hinweis die Wahrscheinlichkeit des nächsten Tokens nach dem Präfix „W-“ hin zu „3“ und weg von „2“.

Wahrscheinlichkeiten für das nächste Token nach W- verschieben sich bei Erhalt eines Hinweises durch das unveränderte Basismodell eher hin zu 3 als zu 2. — Ein Hinweis bewahrt die angeforderte W-3-Form. Die Balken zeigen die mittleren Wahrscheinlichkeiten für das nächste Token über acht Vorwärtsdurchläufe; die Antennen zeigen den beobachteten Bereich, kein Konfidenzintervall. Beide Bedingungen verwenden das unveränderte Basismodell.

Anhand einer größeren, zurückgehaltenen Stichprobe von 40 Runden, die durch explizit dargelegte frühere Belege gestützt wird, steigt der Anteil, der als behoben oder auf Kurs eingestuft wird, von 40,0 % ohne Hinweis auf 75,0 % mit Hinweis. Bei weiteren 40 Runden, die durch eine erschlossene Absicht gestützt werden, steigt er von 32,5 % auf 80,0 %.

Hinweisvalidierung: Raten für feste oder auf Kurs befindliche Fälle steigen von 40,0 % auf 75,0 % bei expliziten Belegen und von 32,5 % auf 80,0 % bei erschlossener Absicht. — Hinweisvalidierung, keine Evaluierung nach dem Training. Dieselben 40 markierten Runden in jeder Belegruppe werden mit und ohne Hinweis unter Verwendung von unverändertem GLM-5.2 bei Temperatur null regeneriert. Der Prüfer sieht die Beschwerde, aber nicht den Hinweis oder die Bedingung. Die Anzahlen werden aus den Raten und Stichprobengrößen des Berichts abgeleitet; Konfidenzintervalle werden nicht ausgewiesen.

Im Beispiel für den Suchwerkzeugfehler verschiebt ein Hinweis tatsächlich die Wahrscheinlichkeitsmasse vom Token „year“ zum Token „month“.

Ein Hinweis verschiebt die Wahrscheinlichkeiten des nächsten Tokens des unveränderten Basismodells weg von „year“ und hin zu dem erlaubten Wert „month“. — Ein Hinweis verschiebt die Wahrscheinlichkeit hin zu einem erlaubten Wert. Die Balken zeigen die mittleren Wahrscheinlichkeiten für das nächste Token über acht Vorwärtsdurchläufe; die Antennen zeigen den beobachteten Bereich, kein Konfidenzintervall. Beide Bedingungen verwenden dasselbe Basismodell; es wird kein trainierter Checkpoint verglichen.

Anhand einer größeren Stichprobe von 985 zurückgehaltenen Runden regenerieren wir jede Runde viermal mit und ohne Hinweis unter Verwendung desselben Basismodells. Ein blinder Prüfer bewertet, ob jede Regeneration den ursprünglichen Fehler vermeidet. Hinweise erhöhen die Fehlervermeidung von 75,1 % auf 93,7 %, ein paarweiser Gewinn von 18,6 Prozentpunkten, und steigern den Anteil der korrigierten Aktionen von 60,6 % auf 82,3 %. Die Gewinne sind bei Fehlern am größten, die durch wiederholte Stichproben allein kaum zu beheben sind.

Bei 985 zurückgehaltenen, markierten Werkzeugfehler-Runden erhöhen Hinweise die Fehlervermeidung von 75,1 % auf 93,7 % und die Raten korrigierter Aktionen von 60,6 % auf 82,3 %. — Validierung von Werkzeugfehler-Hinweisen an 985 zurückgehaltenen, markierten Runden mit vier Regenerationen pro Bedingung. Die Balken zeigen die Fehlervermeidung und Raten korrigierter Aktionen für das unveränderte Basismodell mit und ohne Hinweise. Die Vermeidung des anvisierten Fehlers begründet keinen Erfolg des Werkzeugaufrufs oder der Aufgabe.

Wir testen als Nächstes, ob das trainierte Modell ohne Hinweise weniger Fehler macht. Wir evaluieren das Basismodell und verschiedene nachtrainierte Checkpoints anhand von Offline-Benchmark-Aufgaben und in Live-User-Sitzungen und prüfen dabei auf weniger Tool-Fehler und geringere Nutzerunzufriedenheit.

Die Offline-Evaluierung verwendet BrowseComp, Finch, WideSearch, DRACO, DSQA, SpreadsheetBench, HLE, einen repräsentativen Computer-Aufgabensatz und prüft auf das Laden von Skills, Dokumentenüberprüfung und Inline-Zitate. Wir messen den Anteil der Werkzeugaufrufe, deren Ergebnisse in den Evaluierungstrajektorien ausdrücklich als Fehler markiert sind.

Bei diesen Evaluierungen betrug die aufgezeichnete Werkzeugfehlerquote 2,79 % für Standard-GLM 5.2, 1,35 % für den RFT-only-Checkpoint und 0,87 % für einen RFT-plus-OPSD-Checkpoint. Diese Checkpoints wurden mit unterschiedlichen Daten trainiert, sodass dies keine Ablation mit übereinstimmenden Daten von OPSD ist. Die Benchmark-Ergebnisse auf Aufgabenebene waren durchwachsen, sodass weniger Werkzeugfehler allein nicht notwendigerweise zu einer breiten Verbesserung des Aufgabenerfolgs führen.

Aufgezeichnete Offline-Werkzeugfehlerquoten: 2,79 % für Standard-GLM 5.2, 1,35 % für RFT-only und 0,87 % für RFT plus OPSD; die Trainingsdaten unterscheiden sich. — Offline-Werkzeugfehlerquoten für Checkpoints von Standard-GLM-5.2, RFT-only und RFT-plus-OPSD. Die Trainingsdaten unterscheiden sich über Checkpoints hinweg; dies ist keine kontrollierte Ablation.

Für GLM-5.2 führten wir zwei separate A/B-Tests mit jeweils rund einhunderttausend Nutzern durch. Im ersten Test wies ein früher RFT-plus-OPSD-Checkpoint eine etwas geringere Werkzeugfehlerquote auf als das Standard-GLM-5.2 (2,82 % gegenüber 2,94 %), wobei der Unterschied jedoch statistisch nicht signifikant war.

Im späteren Test haben wir zwei RFT-plus-OPSD-Checkpoints verglichen: einen früheren (Checkpoint eins) und einen späteren (Checkpoint zwei). Werkzeugaufrufausfälle fielen von 2,24 % auf 1,77 % der Aufrufe mit einem aufgezeichneten Status. Dies war eine statistisch signifikante relative Reduzierung um 21,2 %. Wir haben Checkpoint zwei nicht direkt online mit dem Standard-GLM 5.2 verglichen.

Die Ergebnisse des Nutzerfeedbacks waren weniger eindeutig. Im zweiten GLM-5.2-Experiment betrug die durchschnittliche Wahrscheinlichkeit für starke Unzufriedenheit (mittel oder hoch) 2,58 % für den ersten Checkpoint und 2,54 % für den zweiten Checkpoint, ohne statistisch signifikanten Unterschied.

Zwei separate Online-A/B-Tests; nur der spätere Checkpoint-Vergleich weist eine signifikante Reduzierung von Werkzeugfehlern auf, ohne signifikante Änderung der MID+-Unzufriedenheit. — Zwei separate Live-A/B-Tests mit GLM-5.2. Checkpoint 1 wird mit dem Standard-GLM-5.2 verglichen; Checkpoint 2 wird mit Checkpoint 1 verglichen. Innerhalb dieser beiden Tests ist nur die spätere Reduzierung von Werkzeugfehlern statistisch signifikant. MID+-Raten bilden durchschnittliche geschätzte Wahrscheinlichkeiten für mittlere bis starke Unzufriedenheit ab, keine Beschwerdezahlen.

Für GLM-5.3 verglichen wir einen nachträglich trainierten Prüfpunkt direkt mit dem Standard-GLM-5.3. Die Tool-Call-Fehler sanken von 3,56 % auf 2,38 % der Aufrufe mit aufgezeichnetem Status, was einer relativen Reduzierung von 33,04 % entspricht. Die MID+-Rate, die durchschnittliche geschätzte Wahrscheinlichkeit einer mittleren bis hohen Unzufriedenheit, sank von 4,12 % auf 3,41 %, was einer relativen Reduzierung von 17,2 % entspricht. Beide Reduzierungen waren statistisch signifikant.

GLM-5.3-A/B-Test: Die Tool-Fehlerrate sinkt von 3,56 % auf 2,38 % und die MID+-Rate (die durchschnittliche geschätzte Wahrscheinlichkeit einer mittleren bis hohen Unzufriedenheit) sinkt von 4,12 % auf 3,41 %. Die CUPED-bereinigten relativen Reduzierungen betragen 33,04 % bzw. 17,16 %. Beide sequenziellen 95-%-Intervalle schließen Null aus; die primäre Engagement-Metrik ist nicht signifikant. — Post-trainiertes GLM-5.3 im Vergleich zu Standard-GLM-5.3 in einem separaten Online-A/B-Test. Tool-Fehler- und MID+-Raten, relative Änderungen und sequenzielle 95-%-Konfidenzintervalle verwenden eine CUPED-Bereinigung. Beide Reduzierungen sind statistisch signifikant. MID+-Raten sind durchschnittliche geschätzte Wahrscheinlichkeiten für eine mittlere bis hohe Unzufriedenheit über berechtigte bewertete Follow-up-Thread hinweg, keine Beschwerdezahlen. Tool-Fehlerraten schließen Aufrufe ohne aufgezeichneten Erfolg- oder Fehlerstatus aus.

Die zentrale Idee besteht darin, auf der Ebene der Entscheidung zu lernen, nicht nur der Sitzung.

Ein erfolgreiches Ergebnis kann Fehler verdecken, und eine erfolglose Sitzung kann dennoch offenbaren, wie man sich verbessern kann. Wir behalten nützliches Verhalten aus erfolgreichen Sitzungen als Anker bei, nutzen Beschwerden und Werkzeugfehler, um vermeidbare Fehlschläge zu identifizieren, und trainieren das Modell auf die Vorhersagen hin, die es trifft, wenn diese Fehler und Korrekturen explizit gemacht werden. Erfolg liefert zu bewahrendes Verhalten; Misserfolg liefert die Richtung für Verbesserungen.

Die reale Nutzung macht diesen Ansatz besonders nützlich. Reale Benutzer bringen Ziele, Einschränkungen und Workflows mit, die in einer synthetischen Umgebung schwer vorherzusehen sind. Ihre Korrekturen offenbaren Anforderungen, die das Modell verpasst hat, während Werkzeugfehler Lücken zwischen dem aufdecken, was das Modell versucht hat, und dem, was die Umgebung erlaubt. Diese Signale ergänzen das ergebnisbasierte Training: Anstatt nur zu fragen, ob eine Aufgabe erfolgreich war, können wir fragen, wo das Modell falsch abgebogen ist und welche Informationen ihm hätten helfen können, eine bessere Entscheidung zu treffen.

Die Grenzen sind gleichermaßen wichtig. Bewerter können sich irren, und die Korrektur einer Interaktion garantiert nicht, dass die gesamte Aufgabe gelingt. Das Ziel ist nicht nur ein Agent, der sich nach einer Korrektur erholt. Es ist ein Agent, der seltener eine Korrektur benötigt.

BibTeX

@online{perplexity2026LearningFromRealWorldExperience,
  author = {{Perplexity} and Senzeyu Zhang and Chuan Wang and Hang Wu and Hao Zhang and Yuan Liang and Yunfan Zhong and Phi Hoang and Claire Beamer and Jeremy Yang and Andrew Wilson and Denis Yarats},
  title = {{Learning from real-world experience}},
  date = {2026-09-21},
  url = {https://www.perplexity.ai/hub/blog/learning-from-real-world-experience}
}

Von synthetischen zu realen Daten

Die guten Schritte nachahmen, die schlechten korrigieren

Ein Beispiel: Eine Sitzung kann beide Lektionen lehren

Wie das Training funktioniert

Sitzungen auswählen, dann das Ergebnis bewerten

Fehler aus Benutzerfeedback finden

Fehler aus Werkzeugfehlern finden

Zwei Vorwärtsdurchläufe

Die Verlustfunktion

Der CE-Verlust

KL-Verlust

Kombinierter Verlust

Was die Evaluierungen zeigen

Hinweise können das Modell von den Fehlern wegsteuern

Benutzerfeedback

Werkzeugfehler

Werkzeugzuverlässigkeit und Nutzerfeedback nach dem Training

Offline-Evaluierung

Online-Evaluierung: GLM-5.2

Online-Evaluierung: GLM-5.3

Fazit

Zitieren