Apprentissage par l'expérience concrète

La manière dont les utilisateurs interagissent avec nos produits dans le monde réel constitue une source précieuse pour l'entraînement des modèles. Les données sont abondantes, reflètent la distribution réelle des tâches des utilisateurs et capturent les corrections des utilisateurs ainsi que les pannes d'outils que les environnements synthétiques peuvent manquer.

Une méthode courante pour apprendre à partir de données du monde réel est l'affinage par échantillonnage par rejet : évaluer le résultat de chaque session, conserver les réussies et entraîner le modèle à les imiter. Mais un résultat positif ne signifie pas que chaque étape était correcte ; imiter toute la trajectoire risque donc de renforcer de mauvais comportements intermédiaires en plus des bons. Éliminer les sessions infructueuses fait également perdre des preuves cruciales quant aux points où le modèle pèche.

Nous associons le réglage fin par échantillonnage de rejet à l'autodistillation guidée par des indices pour apprendre des sessions réussies comme infructueuses. Un indice est une courte instruction corrective fondée sur des informations que le modèle possédait déjà lorsqu'il a commis l'erreur. Les étapes utiles des sessions réussies restent des cibles d'imitation, tandis que les indices ancrés transforment les erreurs évitables en cibles de correction.

Les corrections d'utilisateurs et les erreurs d'outils ajoutent une supervision quant à ce qui a mal tourné en chemin, en plus de déterminer si la tâche a finalement réussi. Nous appliquons cette étape après l'apprentissage par renforcement dans des environnements synthétiques pour aider à combler l'écart entre ces environnements et l'utilisation réelle.

En utilisation réelle, un point de contrôle post-entraîné ultérieur de GLM-5.2 a réduit les échecs d'appels d'outils de 21,2 % par rapport à un point de contrôle entraîné plus tôt. Pour GLM-5.3, le post-entraînement a réduit les échecs d'appels d'outils de 33,0 % et la probabilité moyenne estimée d'insatisfaction moyenne ou élevée de l'utilisateur de 17,2 % par rapport au modèle standard.

Les tâches synthétiques permettent de créer des problèmes contrôlés dont les résultats sont faciles à vérifier, mais elles se limitent généralement à une seule instruction et ne peuvent couvrir que les scénarios que nous concevons explicitement.

En revanche, dans les sessions du monde réel, les utilisateurs apportent des instructions, des contextes et des combinaisons d'outils divers au sein de sessions qui se déroulent sur plusieurs tours d'interaction. Une telle utilisation réelle génère naturellement deux précieux signaux d'erreurs : les corrections des utilisateurs révèlent là où l'agent a manqué de fournir ce qu'ils attendaient, et les erreurs d'outils montrent là où ses actions ont échoué dans de véritables environnements. Notre pipeline d'échantillonnage respecte la vie privée des utilisateurs et leurs choix en matière d'entraînement en excluant les sessions contenant des informations personnelles identifiables (PII) ainsi que celles provenant d'utilisateurs ayant opté pour le refus.

Les données du monde réel nous fournissent par conséquent des cas d'échec qu'un environnement synthétique peut ne pas exposer et intègrent souvent déjà le lieu où l'échec s'est produit.

Lors de l'entraînement sur des données du monde réel, l'affinage par échantillonnage par rejet (RFT) standard sélectionne les sessions réussies en fonction de leurs résultats finaux, sans utiliser explicitement les retours des utilisateurs et des outils pour distinguer les bonnes actions intermédiaires des mauvaises. Un agent peut se rétablir après un mauvais appel d'outil ou corriger une erreur à la suite de retours d'utilisateurs tout en fournissant le bon résultat à la fin.

L'élimination des sessions échouées limite également l'efficacité des échantillons. Une session qui n'aboutit pas à un bon résultat peut néanmoins révéler une erreur claire et évitable constituant un signal d'entraînement utile.

Nous répondons à ces limitations en séparant deux décisions : quelles sessions contiennent un comportement digne d'être imité, et quels tours contiennent des erreurs dignes d'être corrigées. Le pipeline de données prend ces décisions séparément, puis attribue aux tours du modèle l'un des trois traitements suivants :

Imiter : les tours sans erreur dans les sessions réussies reçoivent une perte d'entropie croisée (CE) classique, ce qui augmente la probabilité des jetons enregistrés.
Correct : dans les sessions réussies comme infructueuses, les tours d'erreurs dotés d'un indice valide reçoivent une perte de divergence de Kullback–Leibler (KL), incitant le modèle à tendre vers les prédictions de jeton suivant qu'il émet lorsqu'il aperçoit l'indice.
Conserver comme contexte : les tours dans les sessions infructueuses qui manquent d'un indice validé, et les tours marqués comme erronés sans indice validé dans l'un ou l'autre type de session, servent de contexte mais ne reçoivent aucune des deux pertes.

Par conséquent, les sessions réussies peuvent fournir à la fois des cibles d'imitation et de correction, tandis que les sessions infructueuses ne fournissent que des cibles de correction. Tous les tours restants, y compris les sorties système, utilisateur et d'outils, restent au stade de contexte.

Diagramme de routage des sessions : les sessions réussies fournissent une imitation CE et des corrections guidées éligibles ; les sessions infructueuses ne fournissent que des corrections éligibles. — Routage actuel des sessions et masques de contenu de l'assistant. Les sessions réussies contribuent à des cibles d'imitation ; les historiques de retours conservés peuvent contribuer à des corrections guidées même si la session échoue. Les autres contenus restent au stade de contexte. Les sessions incomplètes sont exclues. L'exception CE du jeton d'arrêt/rendement non final n'est pas représentée, et ce diagramme n'établit pas le mélange utilisé par un point de contrôle antérieur.

La partie d'imitation utilise le RFT standard. La partie corrective utilise l'On-Policy Self-Distillation (OPSD) : le même modèle agit à la fois comme professeur et comme élève, le professeur disposant d'informations privilégiées. Ici, cette information privilégiée est un court indice expliquant une erreur évitable. Nous entrînons l'élève à reproduire les prédictions du jeton suivant du professeur sans qu'on lui communique l'indice.

Les deux parties ont leur importance. L'entraînement basé uniquement sur la correction peut exposer un raccourci : le professeur et l'élève peuvent se mettre d'accord en ignorant le contexte au lieu d'apprendre la correction. Le terme CE ancre l'entraînement sur un comportement utile, ce qui aide à décourager un accord découlant de l'ignorance du contexte.

L'élève post-entraîné devient alors une option de modèle dans Computer. Les nouvelles sessions issues de l'utilisation en direct passent par les mêmes filtres d'éligibilité et de confidentialité avant d'entrer dans un nouveau cycle du pipeline d'entraînement.

Ensuite, nous explorons un exemple concret qui intègre à la fois l'imitation et la correction.

Considérons une session finale réussie où l'utilisateur demande une comparaison des modifications d'asyncio dans Python 3.13 à l'aide de la documentation officielle. Notre documentation d'outils indique que search.web renvoie une liste de résultats, chacun comportant un champ url.

Le modèle effectue d'abord une recherche valide pour une version dans le cadre de la collecte de preuves pour la comparaison, ce qui constitue un bon comportement à imiter.

Cependant, l'appel d'exécution de code suivant traite incorrectement cette liste comme un dictionnaire. L'outil de code renvoie TypeError: list indices must be integers or slices, not str. Le type de retour ayant été documenté avant l'appel, il s'agit d'une erreur que le modèle aurait dû être capable d'éviter. Un indice contenant le bon appel peut être généré pour corriger cette action.

Session de codage illustrative : les entrées système, utilisateur et les erreurs d'outils restent au stade de contexte ; les appels de recherche et de récupération enregistrés utiles reçoivent la perte CE dans une session réussie ; une recherche de liste erronée et marquée reçoit la perte KL vers un professeur muni d'un indice ancré. — Une session de codage illustrative met en lumière trois rôles d'entraînement : les entrées et sorties d'outils faisant uniquement office de contexte (en gris), l'imitation par entropie croisée (CE) d'appels enregistrés utiles (en foncé) et la correction par divergence KL d'une erreur marquée (en bleu sarcelle). Ici, le modèle traite incorrectement une liste de résultats de recherche comme un dictionnaire ; un indice réservé au professeur ancré dans la documentation d'outils précédente guide la correction. Les cibles CE s'appliquent uniquement lorsque la session achevée est jugée réussie, tandis qu'une session infructueuse peut tout de même fournir une cible de correction KL éligible.

Le pipeline d'entraînement comporte quatre étapes : sélectionner les sessions et juger leurs résultats, identifier les erreurs et créer des indices à partir des retours d'utilisateurs et des erreurs d'outils, générer des probabilités de jeton suivant à la fois à partir du professeur et de l'élève, et entraîner le modèle avec une perte combinée CE et KL.

Le pipeline d’échantillonnage s’appuie sur un sous-ensemble éligible à l’entraînement de sessions Computer réelles servies par GLM 5.2. Les exclusions liées au refus d’entraînement et à la PII du pipeline sont appliquées avant la sélection des exemples pour ce flux de travail.

Le processus de sélection initiale retient les candidats notés 4 ou 5 sur une échelle de difficulté de tâche à cinq points par un juge LLM et les répartit en 2 groupes :

Le groupe de retours d'utilisateurs contient des sessions comportant une relance authentique de l'utilisateur ou un signal d'insatisfaction moyen à élevé. Nous constatons que ces relances à forte intention sont particulièrement utiles pour l'apprentissage : les utilisateurs essaient activement d'accomplir une tâche, et leurs corrections ciblent précisément ce que le modèle a manqué.
Le groupe d'erreurs d'outils contient des sessions présentant des appels échoués signalés par des vérifications basées sur des règles, à l'exclusion des pannes d'infrastructure reconnues et des autorisations refusées.

Deux juges LLM évaluent ensuite le résultat final par rapport à la demande de l'utilisateur ; les deux juges doivent émettre un verdict positif pour qualifier la session de « réussie ». Pour les cas qui génèrent des Artifacts, l'étape de résultat peut reconstruire et inspecter la livraison, en se rabattant sur ses jugements textuels en cas d'échec de cette étape. Les sessions classées comme incomplètes, telles que le travail en attente de l'utilisateur, sont exclues.

Cette étape identifie les sources potentielles de signaux d'apprentissage ; cependant, toutes les erreurs ne sont pas imputables au modèle, certaines découlant d'instructions ambigües ou de défaillances de l'infrastructure. Une annotation ultérieure détermine quelles erreurs candidates sont réellement évitables et adaptées à l'entraînement.

Considérons un exemple de session dans le groupe de retours d'utilisateurs, où l'utilisateur demande : « How do I find my w3 on paychex ». Le modèle traite « w3 » comme une faute de frappe pour W-2, recherche les instructions relatives au W-2 et explique comment trouver ce formulaire. La relance de l'utilisateur, « I meant the W-3 transmittal form », identifie l'erreur, même si la session finit par réussir.

La plainte aide à localiser l'erreur, mais la cause fondamentale est la décision initiale de réinterpréter « w3 » en W-2. La requête d'origine rend l'erreur évitable : le modèle aurait pu préserver W-3 ou demander des éclaircissements. Il s'avère que le dernier tour de l'assistant précédant la plainte n'est la cause fondamentale qu'environ la moitié du temps.

Notre pipeline d'annotation met en correspondance la cause et l'effet de manière systématique au sein de chaque session de retours d'utilisateurs. L'annotateur recherche d'abord une exigence manquée ou une intention soutenue par le contexte précédent. Trois juges LLM identifient ensuite les tours responsables, exigeant qu'au moins deux d'entre eux s'accordent sur un tour donné. Parfois, une déclaration antérieure établit explicitement l'exigence. Dans d'autres cas, aucune déclaration préalable isolée ne le fait, mais plusieurs éléments de la conversation précédente rendent collectivement le comportement intentionnel déductible. Cette conception leur permet de relier une plainte à une erreur fondamentale antérieure au lieu de l'attribuer uniquement à la dernière réponse.

Avant d'accepter un indice, le pipeline vérifie également que ses allégations correctives découlent d'informations disponibles avant le tour marqué. Ces vérifications visent à réduire le biais de rétrospection, par lequel une nouvelle préférence révélée dans la plainte est traitée comme quelque chose que le modèle aurait déjà dû savoir.

Dans cet exemple, l'indice indique au modèle de rechercher le formulaire de transmission W-3 sur Paychex plutôt que le W-2, ou de demander quel formulaire l'utilisateur désigne si la requête est ambigüe. La correction cible l'interprétation antérieure et la décision de recherche, et pas seulement la réponse finale. Le tour d'origine demeure inchangé ; l'annotation ajoute is_bad_turn: true et un hint non vide.

Une requête W-3 est mal interprétée en W-2 ; une plainte ultérieure est retracée jusqu'à la décision de recherche antérieure et vérifiée par rapport aux preuves préalables. — Une session réelle montrant comment une plainte est rattachée à une erreur antérieure, avec superposition de la procédure d'annotation. L'utilisateur a demandé « w3 » sur Paychex, mais le modèle l'a traité comme une faute de frappe pour W-2 et a recherché le mauvais formulaire. Le consensus des proposers localise la cause fondamentale, tandis que deux vérifications d'ancrage évaluent si la preuve anticipe l'erreur et si les affirmations de l'indice découlent des informations disponibles à ce stade. Les annotations acceptées préservent le texte original et y ajoutent des repères et des indices, plutôt que des cibles réécrites.

Considérons une autre session du groupe d'erreurs d'outils comportant un appel de recherche où l'agent effectue une recherche avec recency_filter: "year", mais où l'outil la rejette car les valeurs autorisées sont « day », « week » ou « month ». Il s'agit d'une violation manifeste du schéma.

Le chemin d'erreur d'outil utilise des règles déterministes pour les erreurs connues et le jugement du modèle pour les cas ambigües. Un message d'erreur seul ne suffit pas non plus pour incriminer le modèle ; une correction évaluée doit pointer vers un élément que le modèle aurait pu connaître d'après le schéma de l'outil, les instructions système ou la conversation précédente.

Un appel de recherche utilise la valeur invalide year pour recency_filter ; un indice ancré indique au modèle d'utiliser une valeur répertoriée ou d'omettre un champ facultatif. — L'argument de recherche invalide du rapport illustre la procédure actuelle en cas d'erreur d'outil. Le schéma rend cette erreur évitable, contrairement à une simple panne. L'appel d'origine reste dans l'historique et reçoit un indice ancré. L'indice autorise une valeur répertoriée ou une omission si le champ est facultatif ; il n'exige pas « month » pour chaque requête.

Ici, l'indice nomme l'appel échoué, inclut l'erreur de validation et demande au modèle d'utiliser une valeur autorisée ou d'omettre le champ s'il est facultatif.

Une fois un tour marqué, le système d'entraînement exécute le même point de contrôle deux fois : une première fois en tant que professeur, et une seconde en tant qu'élève. Le professeur voit l'indice ; l'élève ne le voit pas.

Les deux passes utilisent le forcing de professeur (teacher forcing), où nous fournissons au modèle la session enregistrée au lieu de le laisser choisir de nouveaux tours. La passe avant produit toujours une distribution complète du jeton suivant à chaque étape, mais elle est toujours conditionnée par le préfixe fixe de l'enregistrement, et non par les jetons de déploiement.

Pour l'exemple de recherche, le même modèle attribue une probabilité beaucoup plus élevée à « month » et moins à « year » lorsqu'il reçoit l'indice. L'entraînement utilise ce décalage distributionnel comme cible souple.

Le même modèle évalue un tour enregistré avec et sans indice ; les probabilités du professeur détaché fournissent des cibles KL tandis que l'entropie croisée (CE) ancre l'imitation. — Deux passes, un seul jeu de poids. Les deux passes évaluent la suite enregistrée ; seul le professeur reçoit des indices. Ses probabilités de jeton suivant détachées guident l'élève via la divergence KL avant (forward KL). Des cibles CE distinctes ancrent l'imitation. Les deux pertes alimentent une seule mise à jour de poids. Des indices antérieurs peuvent subsister dans le segment actuel du professeur ; aucune des deux passes ne génère de réponse d'entraînement de remplacement.

Les prédictions du professeur sont détachées, ou à gradient stoppé (stop-gradient) : elles fournissent une cible mais ne reçoivent pas de mise à jour via la passe du professeur. Après la passe de l'élève, une étape d'optimisation met à jour le modèle partagé.

La perte CE traite les jetons enregistrés sélectionnés pour l'imitation comme des cibles de vérité terrain (ground-truth) et pénalise le modèle lorsqu'il leur attribue de faibles probabilités. Cela crée une cible d'imitation stricte.

À la position de jeton $i$ , soit $p_i(v)$ la probabilité par l'élève du jeton $v$ dans tout le vocabulaire $V$ . Le jeton suivant enregistré dans la réponse ou l'appel d'outil est $y_i$ , la distribution cible one-hot est $r_i$ .

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

L'entropie croisée mesure la capacité de l'élève à prédire ce jeton enregistré. Avec une cible one-hot, elle se réduit à la log-probabilité négative attribuée à $y_i$ .

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

Le masque CE $m_i^{\mathrm{CE}}$ vaut $1$ là où le jeton doit être imité et $0$ sinon. La somme sur les positions sélectionnées donne la perte d'imitation.

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

La perte KL utilise plutôt la distribution de probabilité complète du jeton suivant du professeur $q_i$ comme cible de correction souple. Le contexte du professeur comprend l'indice actuel et tout indice précédent conservé dans ce segment d'entraînement ; le contexte de l'élève est toujours dépourvu d'indice.

Le masque KL $m_i^{\mathrm{KL}}$ vaut $1$ là où le jeton doit être corrigé et $0$ sinon ; les masques CE et KL ne se chevauchent pas. À ces positions, la divergence KL avant pénalise le désaccord entre le professeur et l'élève sur l'ensemble du vocabulaire :

\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)}

Les deux termes partagent un dénominateur unique plutôt que d'être normalisés séparément. Ce dénominateur compte le nombre total de jetons sélectionnés pour l'imitation dans l'ensemble du lot d'entraînement global. Le poids $\lambda$ contrôle la contribution de l'entraînement correctif par rapport à l'imitation.

Cette normalisation partagée s'adapte à l'interface à dénominateur unique de notre infrastructure d'entraînement et rétablit la perte SFT standard lorsque $\lambda=0$ , ce qui simplifie les comparaisons de référence. Les jetons CE étant beaucoup plus abondants que les jetons KL, l'utilisation d'un dénominateur partagé évite également d'attribuer des poids anormalement élevés aux jetons KL individuels dans les lots comportant peu de jetons marqués.

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

Appliqués aux exemples précédents, les tours contenant le mélange W-3/W-2 et l'appel de recherche invalide reçoivent la perte KL. Tout autre contenu d'assistant non marqué dans une session réussie reçoit toujours la perte CE. Tout autre contenu d'assistant dans une session infructueuse est conservé comme contexte mais ne reçoit ni CE ni KL.

Nos évaluations répondent à deux questions distinctes. Premièrement, un indice aide-t-il réellement le modèle à corriger une erreur lorsqu'il est présent ? Deuxièmement, l'entraînement aide-t-il le modèle à éviter cette erreur par la suite, sans l'indice ? La première teste si les indices fournissent des signaux d'entraînement utiles. La seconde teste si le modèle en tire des enseignements.

Nous testons la première question avant le lancement de l'entraînement pour nous assurer que les indices peuvent effectivement écarter le modèle des erreurs.

Nous avons régénéré les tours de retours d'utilisateurs marqués avec et sans indice, en utilisant le même modèle de base GLM-5.2 à température zéro. Un juge à l'aveugle voit la plainte ultérieure, mais ni l'indice ni la condition ayant produit la réponse.

Dans l'exemple W-3, l'indice déplace la probabilité du jeton suivant vers « 3 » et l'éloigne de « 2 » après le préfixe « W- ».

Les probabilités de jeton suivant après W- s'orientent vers 3 plutôt que vers 2 lorsque le modèle de base inchangé reçoit un indice. — Un indice préserve le format W-3 demandé. Les barres indiquent les probabilités moyennes des jetons suivants sur huit passes avant ; les moustaches (whiskers) indiquent la plage observée, et non un intervalle de confiance. Les deux conditions utilisent le modèle de base inchangé.

Sur un échantillon retenu plus important de 40 tours étayé par des preuves antérieures explicitement formulées, la proportion jugée corrigée ou sur la bonne voie passe de 40,0 % sans indice à 75,0 % avec un indice. Sur 40 autres tours étayés par une intention déduite, elle passe de 32,5 % à 80,0 %.

Validation des indices : les taux de correction ou de bonne voie augmentent de 40,0 % à 75,0 % pour les preuves explicites et de 32,5 % à 80,0 % pour l'intention déduite. — Validation des indices, et non évaluation du post-entraînement. Les 40 mêmes tours marqués dans chaque groupe de preuves sont régénérés avec et sans indice en utilisant le GLM-5.2 inchangé à température zéro. Le juge voit la plainte mais ni l'indice ni la condition. Les décomptes sont dérivés des taux et tailles d'échantillons du rapport ; les intervalles de confiance ne sont pas communiqués.

Dans l'exemple d'erreur d'outil de recherche, un indice déplace effectivement la masse de probabilité du jeton year vers le jeton month.

Un indice éloigne les probabilités du jeton suivant du modèle de base inchangé de year pour les orienter vers la valeur autorisée month. — Un indice déplace la probabilité vers une valeur autorisée. Les barres indiquent les probabilités moyennes des jetons suivants sur huit passes avant ; les moustaches (whiskers) indiquent la plage observée, et non un intervalle de confiance. Les deux conditions utilisent le même modèle de base ; aucun point de contrôle entraîné n'est comparé.

Sur un échantillon retenu plus vaste de 985 tours, nous régénérons chaque tour quatre fois avec et sans indice en utilisant le même modèle de base. Un juge à l'aveugle évalue si chaque régénération évite l'échec initial. Les indices augmentent la prévention des échecs de 75,1 % à 93,7 %, soit un gain apparenté de 18,6 points de pourcentage, et augmentent la proportion d'actions corrigées de 60,6 % à 82,3 %. Les gains sont les plus importants sur les erreurs que l'échantillonnage répété seul peine à corriger.

Sur 985 tours d'erreurs d'outils marqués et retenus, les indices augmentent la prévention des échecs de 75,1 % à 93,7 % et les taux d'actions corrigées de 60,6 % à 82,3 %. — Validation des indices d'erreurs d'outils sur 985 tours marqués et retenus, avec quatre régénérations par condition. Les barres indiquent la prévention des échecs et les taux d'actions corrigées pour le modèle de base inchangé, avec et sans indices. Éviter l'erreur ciblée ne garantit pas la réussite de l'appel d'outil ou de la tâche.

Nous testons ensuite si le modèle entraîné commet moins d’erreurs sans recevoir d’indications. Nous évaluons le modèle standard et divers points de contrôle post-entraînement sur des tâches de benchmark hors ligne et dans des sessions utilisateur en direct, en vérifiant qu’il y a moins d’échecs d’outils et moins d’insatisfaction utilisateur.

L'évaluation hors ligne utilise BrowseComp, Finch, WideSearch, DRACO, DSQA, SpreadsheetBench, HLE, un ensemble de tâches Computer représentatif, et vérifie le chargement de compétences (Skills), la révision de documents et les citations en ligne. Nous mesurons la proportion d'appels d'outils dont les résultats sont explicitement signalés comme des erreurs parmi les trajectoires d'évaluation.

Dans ces évaluations, le taux d'erreurs d'outils enregistré était de 2,79 % pour le GLM 5.2 standard, de 1,35 % pour le point de contrôle RFT seul et de 0,87 % pour le point de contrôle RFT-plus-OPSD. Ces points de contrôle ont été entraînés sur des données différentes, il ne s'agit donc pas d'une ablation à données appariées de l'OPSD. Les résultats des benchmarks au niveau des tâches étant mitigés, une baisse des erreurs d'outils ne se traduit pas nécessairement par une amélioration globale de la réussite des tâches.

Taux d'erreurs d'outils enregistrés hors ligne : 2,79 % pour le GLM 5.2 standard, 1,35 % pour le RFT seul, et 0,87 % pour le RFT plus OPSD ; les données d'entraînement diffèrent. — Taux d'erreurs d'outils hors ligne pour les points de contrôle du GLM-5.2 standard, RFT seul et RFT-plus-OPSD. Les données d'entraînement diffèrent selon les points de contrôle ; il ne s'agit pas d'une ablation à données contrôlées.

Pour GLM-5.2, nous avons mené deux tests A/B distincts auprès d'environ cent mille utilisateurs dans chaque condition. Dans le premier, un point de contrôle précoce RFT-plus-OPSD présentait un taux d'échec d'outils légèrement inférieur à celui du modèle de base GLM 5.2 (2,82 % contre 2,94 %), mais la différence n'était pas statistiquement significative.

Dans le test ultérieur, nous avons comparé deux points de contrôle RFT-plus-OPSD : un plus ancien (point de contrôle un) et un plus récent (point de contrôle deux). Les échecs d'appels d'outils sont passés de 2,24 % à 1,77 % des appels ayant un statut enregistré. Il s'agit d'une réduction relative statistiquement significative de 21,2 %. Nous n'avons pas comparé directement le point de contrôle deux avec le GLM 5.2 standard en ligne.

Les résultats des retours utilisateurs se sont révélés moins concluants. Dans la deuxième expérience GLM-5.2, la probabilité moyenne de forte insatisfaction (moyenne ou élevée) était de 2,58 % pour le premier point de contrôle et de 2,54 % pour le second, sans différence statistiquement significative.

Deux tests A/B en ligne distincts ; seule la comparaison du point de contrôle ultérieur présente une réduction significative des pannes d'outils, sans changement significatif de l'insatisfaction MID+. — Deux tests A/B en direct distincts pour GLM-5.2. Le point de contrôle 1 est comparé au modèle GLM-5.2 de base ; le point de contrôle 2 est comparé au point de contrôle 1. Dans ces deux tests, seule la réduction ultérieure des échecs d'outils est statistiquement significative. Les taux MID+ correspondent aux probabilités estimées moyennes d'insatisfaction moyenne ou élevée, et non au nombre de réclamations.

Pour GLM-5.3, nous avons comparé un point de contrôle post-entraîné directement avec le modèle standard GLM-5.3. Les échecs d'appels d'outils sont passés de 3,56 % à 2,38 % des appels avec un statut enregistré, soit une réduction relative de 33,04 %. Le taux MID+, qui correspond à la probabilité moyenne estimée d'une insatisfaction moyenne ou élevée, est passé de 4,12 % à 3,41 %, soit une réduction relative de 17,2 %. Ces deux réductions sont statistiquement significatives.

Test A/B de GLM-5.3 : le taux d'échec des outils chute de 3,56 % à 2,38 % et le taux MID+, qui correspond à la probabilité moyenne estimée d'une insatisfaction moyenne ou élevée, chute de 4,12 % à 3,41 %. Les réductions relatives ajustées par CUPED sont respectivement de 33,04 % et de 17,16 %. Les deux intervalles séquentiels à 95 % excluent zéro ; la métrique d'engagement principale n'est pas significative. — GLM-5.3 post-entraîné par rapport au GLM-5.3 standard dans un test A/B en ligne distinct. Les taux d'échec des outils et MID+, les variations relatives et les intervalles de confiance séquentiels à 95 % utilisent l'ajustement CUPED. Les deux réductions sont statistiquement significatives. Les taux MID+ correspondent aux probabilités moyennes estimées d'une insatisfaction moyenne ou élevée sur les fils de suivi éligibles notés, et non aux nombres de réclamations. Les taux d'échec des outils excluent les appels sans statut de réussite ou d'échec enregistré.

L'idée centrale est d'apprendre au niveau de la décision, et pas seulement de la session.

Un résultat positif peut masquer des erreurs, et une session infructueuse peut tout de même révéler comment s'améliorer. Nous conservons le comportement utile des sessions réussies comme point d'ancrage, utilisons les plaintes et les erreurs d'outils pour identifier les échecs évitables, et entraînons le modèle vers les prédictions qu'il formule lorsque ces erreurs et corrections sont explicitées. Le succès fournit un comportement à préserver ; l'échec fournit une orientation pour l'amélioration.

L'utilisation en direct rend cette approche particulièrement utile. Les utilisateurs réels apportent des objectifs, des contraintes et des flux de travail qu'il est difficile d'anticiper dans un environnement synthétique. Leurs corrections révèlent des exigences que le modèle a manquées, tandis que les erreurs d'outils exposent les écarts entre ce que le modèle a tenté et ce que l'environnement autorise. Ces signaux complètent l'entraînement axé sur les résultats : au lieu de se demander seulement si une tâche a réussi, nous pouvons chercher où le modèle s'est trompé et quelles informations auraient pu l'aider à prendre une meilleure décision.

Les limites sont tout aussi importantes. Les évaluateurs peuvent se tromper, et corriger un tour ne garantit pas la réussite de l'ensemble de la tâche. L'objectif n'est pas simplement d'obtenir un agent qui récupère après une correction, mais un agent qui a besoin de corrections moins souvent.

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}
}

Des données synthétiques aux données du monde réel

Imiter les bonnes étapes, corriger les mauvaises

Un exemple : une seule session peut enseigner les deux leçons

Fonctionnement de l'entraînement

Sélectionner des sessions, puis juger le résultat

Trouver les erreurs à partir des retours d'utilisateurs

Trouver les erreurs à partir des erreurs d'outils

Deux passes avant (forward passes)

La fonction de perte

La perte CE

Perte KL

Perte combinée

Ce que montrent les évaluations

Les indices peuvent écarter le modèle des erreurs

Retours d'utilisateurs

Erreurs d'outils

Fiabilité des outils et retours des utilisateurs après l'entraînement

Évaluation hors ligne

Évaluation en ligne : GLM-5.2

Évaluation en ligne : GLM-5.3

Conclusion

Citation