Apprentissage à partir de l'expérience du monde réel

La façon 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 de ces derniers ainsi que les pannes d'outils que les environnements synthétiques pourraient rater.

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 celles qui réussissent et entraîner le modèle à les imiter. Mais un résultat fructueux ne signifie pas que chaque étape était correcte, de sorte qu'imiter toute la trajectoire risque de renforcer de mauvais comportements intermédiaires en plus des bons. Écarter les sessions infructueuses fait également perdre des preuves cruciales quant aux points où le modèle est défaillant.

Nous combinons l'affinage par échantillonnage de rejet avec l'autodistillation guidée par des indices pour apprendre à la fois des sessions réussies et infructueuses. Un indice est une courte instruction corrective ancrée dans 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 des utilisateurs et les erreurs d'outils ajoutent une supervision quant à ce qui a mal tourné en cours de route, en plus d'indiquer si la tâche a finalement réussi. Nous appliquons cette étape après l'apprentissage par renforcement dans des environnements synthétiques afin de contribuer à combler l'écart entre ces environnements et l'utilisation dans le monde réel.

En utilisation réelle, un point de contrôle post-entraîné ultérieur de GLM-5.2 a réduit les échecs d'appel 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'appel 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 de base.

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 invite et ne peuvent couvrir que les scénarios que nous concevons explicitement.

En revanche, les utilisateurs des sessions du monde réel apportent des instructions, des contextes et des combinaisons d'outils divers dans des sessions qui se déroulent sur plusieurs tours d'interaction. Une telle utilisation réelle génère naturellement deux signaux d'erreur précieux : les corrections des utilisateurs révèlent où l'agent n'a pas fourni ce qu'ils souhaitaient, et les erreurs d'outils montrent où ses actions ont échoué dans des environnements réels. 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 renseignements personnels (PII) et celles provenant d'utilisateurs s'étant désistés.

Les données du monde réel nous procurent donc des cas d'échec qu'un environnement synthétique ne saurait exposer et intègrent souvent déjà le lieu où l'erreur s'est produite.

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 la rétroaction 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 d'une rétroaction de l'utilisateur tout en fournissant le bon résultat à la fin.

Écarter les sessions ayant échoué limite également l'efficacité des échantillons. Une session qui n'atteint pas un bon résultat peut tout de même révéler une erreur claire et évitable, fournissant ainsi des signaux d'entraînement utiles.

Nous répondons à ces limites en séparant deux décisions : quelles sessions contiennent un comportement qui mérite d'être imité, et quels tours comportent des erreurs qui méritent 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 :

Imiter : les tours sans erreur dans les sessions réussies reçoivent une perte d'entropie croisée (CE) ordinaire, augmentant la probabilité des jetons enregistrés.
Correct : dans les sessions réussies comme dans les sessions infructueuses, les tours comportant une erreur munie d'un indice valide reçoivent une perte de divergence de Kullback-Leibler (KL), ce qui oriente le modèle vers les prédictions de jeton suivant qu'il formule lorsqu'il visualise l'indice.
Conserver comme contexte : les tours dans des sessions infructueuses qui ne possèdent pas d'indice validé, ainsi que les tours incorrects signalé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 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 du système, de l'utilisateur et de l'outil, restent au titre de contexte.

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

La partie imitation utilise la méthode RFT standard. La partie corrective recourt à l'auto-distillation sur politique (On-Policy Self-Distillation - OPSD) : le même modèle agit comme enseignant et comme élève, l'enseignant disposant d'informations privilégiées. En l'occurrence, cette information privilégiée est un bref indice expliquant une erreur évitable. Nous entrînons l'élève à reproduire les prédictions du prochain jeton de l'enseignant sans qu'on lui transmette l'indice.

Les deux parties ont leur importance. L'entraînement axé uniquement sur la correction peut exposer à un raccourci : l'enseignant et l'élève peuvent s'accorder en ignorant le contexte plutôt qu'en apprenant la correction. Le terme CE ancrant l'entraînement à un comportement utile, il aide à décourager tout accord découlant de l'omission du contexte.

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

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

Considérons une session potentiellement réussie où l'utilisateur demande une comparaison des modifications apportées à 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 doté d'un champ url.

Le modèle exécute 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 erronément 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 du système et de l'utilisateur ainsi que les erreurs d'outils demeurent du contexte ; les appels de recherche et de récupération enregistrés utiles reçoivent la perte CE dans une session réussie ; une consultation de liste erronée marquée reçoit la perte KL vers un enseignant muni d'un indice fondé. — Une session de codage illustrative montre trois rôles d'entraînement : les entrées et sorties d'outils réservées au contexte (en gris), l'imitation CE des appels enregistrés utiles (en foncé), et la correction KL d'une erreur marquée (en sarcelle). Ici, le modèle traite par erreur une liste de résultats de recherche comme un dictionnaire ; un indice émanant uniquement de l'enseignant et fondé sur la documentation d'outils antérieure 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 admissible.

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

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

Le processus de filtrage initial sélectionne les candidats notés 4 ou 5 sur une échelle de difficulté de tâche à cinq niveaux par un juge LLM et les répartit en 2 groupes :

Le groupe de rétroaction des utilisateurs contient des sessions caractérisées par un véritable suivi de l'utilisateur ou par un indicateur d'insatisfaction de niveau moyen à élevé. Nous trouvons ces suivis à forte intention particulièrement utiles pour l'apprentissage : les utilisateurs essaient activement de mener à bien 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 ayant échoué 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 évaluateurs LLM évaluent ensuite le résultat final par rapport à la demande de l'utilisateur; les deux juges doivent émettre un verdict positif pour qu'une session soit qualifiée de « réussie ». Dans le cas des tâches produisant des artefacts, l'étape de résultat peut reconstituer et inspecter la livraison, en se rabattant sur ses jugements textuels si cette étape échoue. Les sessions classées comme incomplètes, telles que celles en attente d'une action de l'utilisateur, sont exclues.

Cette étape identifie les sources potentielles de signaux d'apprentissage ; toutefois, toutes les erreurs ne sont pas imputables au modèle, certaines découlant d'instructions ambiguës 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 rétroaction des 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 à W-2 et explique comment trouver ce formulaire. Le suivi de l'utilisateur, « I meant the W-3 transmittal form », identifie l'erreur, même si la session finit par aboutir.

La plainte aide à localiser l'erreur, mais la cause profonde réside dans 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 précisions. Il s'avère que le dernier tour de l'assistant précédant la plainte n'est la cause profonde qu'environ la moitié du temps.

Notre pipeline d'annotation cartographie systématiquement la cause et l'effet au sein de chaque session de rétroaction des utilisateurs. L'annotateur recherche d'abord une exigence manquée ou une intention soutenue par un contexte antérieur. 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 permettent conjointement de déduire le comportement attendu. Cette conception leur permet de relier une plainte à une erreur fondamentale antérieure plutôt 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 rétrospectif, où une nouvelle préférence révélée dans la plainte est traitée comme un élément que le modèle aurait déjà dû connaître.

Dans cet exemple, l'indice indique au modèle de rechercher le formulaire de transmission W-3 sur Paychex plutôt que W-2, ou de demander quel formulaire l'utilisateur désigne si la requête est ambiguë. La correction cible l'interprétation et la décision de recherche antérieures, et pas seulement la réponse finale. Le tour d'origine demeure inchangé ; l'annotation ajoute is_bad_turn: true ainsi qu'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 initiale et vérifiée par rapport aux preuves antérieures. — Session réelle illustrant la façon dont une plainte est reliée à une erreur antérieure, avec la 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 profonde, tandis que deux vérifications de fond évaluent si la preuve précède l'erreur et si les affirmations de l'indice découlent des informations disponibles à ce moment-là. Les annotations acceptées préservent le texte original tout en y ajoutant des repères et des indices, plutôt que de réécrire les cibles.

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

Le cheminement des erreurs d'outils utilise des règles déterministes pour les erreurs connues et le jugement du modèle pour les cas ambigus. Un message d'erreur ne suffit pas non plus pour rejeter la faute sur le modèle ; une correction évaluée doit pointer vers un élément que le modèle aurait pu connaître à partir du schéma de l'outil, des instructions système ou de la conversation précédente.

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

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

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

Les deux passes utilisent le forcage d'enseignant (teacher forcing), où nous fournissons au modèle la session enregistrée au lieu de le laisser choisir de nouveaux jetons. 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éroulement.

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 de l'enseignant détaché fournissent des cibles KL tandis que la perte CE ancre l'imitation. — Deux passes, un ensemble de poids. Les deux passes évaluent la suite enregistrée ; seul l'enseignant reçoit des indices. Ses probabilités de jeton suivant détachées guident l'élève par le biais d'une divergence KL vers l'avant. Des cibles CE distinctes ancrent l'imitation. Les deux pertes alimentent une seule mise à jour des poids. Des indices antérieurs peuvent subsister dans le segment actuel de l'enseignant ; aucune passe ne génère de réponse d'entraînement de remplacement.

Les prédictions de l'enseignant sont détachées, ou dotées d'un gradient stoppé (stop-gradient) : elles fournissent une cible mais ne reçoivent pas de mise à jour via la passe de l'enseignant. 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 référence absolue (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 l'ensemble du vocabulaire $V$ . Le jeton suivant enregistré dans la réponse ou l'appel d'outil est $y_i$ , la distribution cible binaire (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 binaire (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 sommation 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 prochain jeton de l'enseignant $q_i$ comme cible de correction souple. Le contexte de l'enseignant inclut l'indice actuel ainsi que 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 superposent pas. À ces positions, la divergence KL vers l'avant pénalise le désaccord entre l'enseignant 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 seul dénominateur au lieu 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 la confusion W-3/W-2 et l'appel de recherche non valide reçoivent la perte KL. Les autres contenus non marqués de l'assistant dans une session réussie reçoivent toujours la perte CE. Tout autre contenu de l'assistant dans une session infructueuse est conservé en tant que contexte, mais ne reçoit ni la perte CE ni la perte 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 ? Le premier teste si les indices fournissent des signaux d'entraînement utiles. Le second teste si le modèle en tire des leçons.

Nous testons la première question avant le début 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 rétroaction utilisateur marqués avec et sans indice, en utilisant le même modèle de base GLM-5.2 à une température de zéro. Un juge à l'aveugle examine 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 formulaire W-3 demandé. Les barres indiquent les probabilités moyennes du jeton suivant sur huit passes avant ; les moustaches 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 en bonne voie passe de 40,0 % sans indice à 75,0 % avec un indice. Sur 40 autres tours étayés par une intention inférée, elle passe de 32,5 % à 80,0 %.

Validation des indices : les taux de correction ou de progression passent de 40,0 % à 75,0 % pour les preuves explicites et de 32,5 % à 80,0 % pour l'intention inférée. — Validation des indices, et non évaluation post-entraînement. Les 40 mêmes tours marqués de chaque groupe de preuves sont régénérés avec et sans indice à l'aide du modèle GLM-5.2 inchangé à une température de zéro. Le juge voit la plainte mais pas l'indice ni la condition. Les totaux sont déduits des taux et des tailles d'échantillon du rapport ; les intervalles de confiance ne sont pas communiqués.

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

Un indice éloigne les probabilités de jeton suivant du modèle de base inchangé de l'année pour les rapprocher de la valeur autorisée du mois. — Un indice déplace la probabilité vers une valeur autorisée. Les barres indiquent les probabilités moyennes du jeton suivant sur huit passes avant ; les moustaches indiquent la plage observée, et non un intervalle de confiance. Les deux conditions utilisent le 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 font passer l'évitement des échecs de 75,1 % à 93,7 %, soit un gain apparenté de 18,6 points de pourcentage, et augmentent la part des actions corrigées de 60,6 % à 82,3 %. Les gains sont les plus importants sur les erreurs que l'échantillonnage répété seul a du mal à corriger.

Sur 985 tours d'erreurs d'outils marqués et retenus, les indices font passer l'évitement 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 retenus, avec quatre régénérations par condition. Les barres indiquent l'évitement 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é fait moins d’erreurs sans recevoir d’indices. Nous évaluons le modèle standard et divers points de contrôle post-entraînement sur des tâches de référence hors ligne et dans des sessions utilisateurs en direct, en vérifiant s’il y a moins d’échecs d’outil et moins d’insatisfaction chez les utilisateurs.

L'évaluation hors ligne utilise BrowseComp, Finch, WideSearch, DRACO, DSQA, SpreadsheetBench, HLE, un ensemble de tâches représentatives Computer, et vérifie le chargement des compétences, l'examen de documents ainsi que les citations intégrées. 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 modèle stock GLM 5.2, de 1,35 % pour le point de contrôle RFT seul et de 0,87 % pour un 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 sur données appariées de l'OPSD. Les résultats des repères 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 modèle stock GLM 5.2, 1,35 % pour RFT seul, et 0,87 % pour RFT plus OPSD ; les données d'entraînement diffèrent. — Taux d'erreurs d'outils hors ligne pour les points de contrôle GLM-5.2 stock, 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 sur données appariées.

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

Lors du test ultérieur, nous avons comparé deux points de contrôle RFT-plus-OPSD : un plus ancien (point de contrôle 1) et un plus récent (point de contrôle 2). 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 2 avec le modèle stock GLM 5.2 en ligne.

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

Deux tests A/B en ligne distincts ; seule la comparaison des points de contrôle ultérieurs présente une réduction significative des pannes d'outils, sans changement significatif de l'insatisfaction MID+. — Deux tests A/B en direct distincts avec 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. Parmi ces deux tests, seule la réduction ultérieure des défaillances d'outils est statistiquement significative. Les taux MID+ représentent des probabilités moyennes estimées d'insatisfaction moyenne ou élevée, et non des nombres de plaintes.

Pour GLM-5.3, nous avons comparé directement un point de contrôle post-entraîné avec le modèle de base GLM-5.3. Les échecs d'appel 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'insatisfaction moyenne ou élevée, est passé de 4,12 % à 3,41 %, soit une réduction relative de 17,2 %. Les deux réductions étaient statistiquement significatives.

Test A/B de GLM-5.3 : le taux d'échec des outils passe de 3,56 % à 2,38 % et le taux MID+, qui est la probabilité moyenne estimée d'une insatisfaction moyenne ou élevée, passe 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 de 95 % excluent zéro ; la mesure d'engagement principale n'est pas significative. — GLM-5.3 post-entraîné par rapport au GLM-5.3 de base 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 de 95 % utilisent l'ajustement CUPED. Les deux réductions sont statistiquement significatives. Les taux MID+ représentent des probabilités moyennes estimées d'insatisfaction moyenne ou élevée sur les fils de discussion de suivi admissibles et évalués, et non des nombres de plaintes. 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 non pas seulement de la session.

Un résultat fructueux peut dissimuler 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 défaillances évitables, et entraînons le modèle vers les prédictions qu'il formule lorsque ces erreurs et corrections sont explicitées. La réussite fournit un comportement à préserver ; l'échec fournit une orientation pour l'amélioration.

L'utilisation dans le monde réel rend cette approche particulièrement utile. Les utilisateurs réels apportent des objectifs, des contraintes et des flux de travail qu'il est difficile de prévoir 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 permet. 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 la correction d'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 bien 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 deux leçons

Fonctionnement de l'entraînement

Sélectionner les sessions, puis évaluer le résultat

Trouver les erreurs à partir de la rétroaction des utilisateurs

Trouver les erreurs à partir des erreurs d'outils

Deux passes avant

La fonction de perte

La perte CE

Perte KL

Perte combinée

Ce que démontrent les évaluations

Les indices peuvent écarter le modèle des erreurs

Rétroaction des utilisateurs

Erreurs d'outils

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

Évaluation hors ligne

Évaluation en ligne : GLM-5.2

Évaluation en ligne : GLM-5.3

Conclusion

Citation