Codex, testé en russe, cesse de chercher sur Internet : son taux de réussite passe de 100 % à 0 %

Vous demandez à un agent de corriger l'export d'un entraînement vers une montre. Il modifie les champs, injecte des valeurs de fréquence cardiaque et présente un correctif soigné. Sauf que la montre ne comprend pas ce format. La bonne réponse se trouve sur un forum, et l'agent n'y a même pas jeté un œil. Dans une expérience publiée sur Habr, ce comportement est apparu après la traduction de la tâche de l'anglais vers le russe. La conclusion pratique est simple : face à des correctifs étranges, il est utile de vérifier le journal des accès aux sources et de donner à l'agent les particularités connues du projet.

L'autrice voulait vérifier si la langue de la tâche influence le travail des agents et s'il fallait traduire les récits issus de son projet worklore, une bibliothèque de cas d'ingénierie analysés. Au total, l'expérience a compté 1350 exécutions : six tâches, neuf configurations d'agents, cinq modes de présentation et cinq répétitions pour chaque combinaison. Il s'agit d'une petite expérience d'auteur, mais elle met en évidence une défaillance facile à manquer dans le travail courant.

Où l'agent s'est mis à deviner

Le cas le plus parlant est celui du format de la zone de fréquence cardiaque dans un entraînement pour Garmin. Selon les conditions de l'expérience, la particularité nécessaire était décrite sur un forum et absente de la documentation. Avec la tâche en anglais, Codex avec un faible niveau de raisonnement cherchait systématiquement le format sur Internet et a réussi les cinq tentatives.

Après la traduction de la tâche en russe, le même agent n'a jamais consulté Internet. Au lieu de vérifier, il a essayé des modifications plausibles : suppression de l'objectif structuré, passage à des valeurs absolues de fréquence cardiaque, ajout de nouveaux champs à côté de l'ancienne clé. Aucune tentative n'a réussi. La chute est donc de 100 % à 0 %, mais derrière chaque pourcentage il n'y a que cinq exécutions.

Chez Kimi K3.1, un tableau similaire est apparu sur une tâche portant sur les particularités d'un fournisseur OAuth. La version anglaise a donné cinq solutions réussies sur cinq, la version russe aucune. L'agent sautait la recherche et conservait de fausses hypothèses sur les paramètres d'accès et la durée de vie du jeton. L'autrice n'a pas vérifié pourquoi la langue modifiait la décision d'utiliser l'outil.

Le bon fait s'est révélé plus utile que la traduction

L'ajout d'une note sur un cas similaire éliminait une grande partie des problèmes. Par exemple, si un fournisseur délivre des jetons sans date d'expiration, il est utile d'indiquer directement cette particularité à l'agent. Il n'a alors pas à déduire le comportement d'un service précis à partir d'idées générales sur OAuth.

Sur les quatre tâches où la note contenait le fait manquant, le taux de réussite est passé de 47 % à 94 % pour les tâches en anglais et de 35 % à 92 % pour celles en russe. Sur les deux tâches de contrôle, où la réponse figurait déjà dans la documentation ou dans le journal, le gain était faible. Cela appuie une idée très concrète : conserver les particularités d'intégration découvertes par l'équipe et les transmettre à l'agent avec la tâche.

La traduction de la note elle-même n'a presque rien changé. Avec une tâche en russe, la version russe a donné environ deux points de pourcentage de solutions réussies en plus, mais l'intervalle d'incertitude incluait l'absence d'effet. Les identifiants, les chemins et les messages d'erreur sont restés en anglais dans les deux variantes. Pour ce type de mémoire technique, les détails précis comptaient plus que la langue de rédaction.

Que vérifier dans votre propre processus

Il est trop tôt pour désigner le russe comme la cause du mauvais travail des agents d'après ces données. Il n'y a ici que six tâches spécialement préparées, une seule langue autre que l'anglais et cinq répétitions par combinaison. De plus, ce sont des configurations entières qui ont été comparées : modèle, environnement d'exécution et outils disponibles. Le résultat ne peut pas être transposé automatiquement à d'autres versions ou réglages.

Il existe une limite supplémentaire : dans une partie des exécutions, les agents ont trouvé par la recherche les récits publiés de worklore lui-même. Cela modifiait le contexte à leur disposition. L'autrice a recalculé séparément les résultats globaux sans ces exécutions ; l'observation principale s'est maintenue, mais pour certaines combinaisons modèle-tâche, il ne restait plus de comparaison propre.

Un développeur gagnerait à prendre un problème familier nécessitant une source externe et à le lancer plusieurs fois dans les deux langues. Il faut regarder les appels d'outils et le résultat de la vérification du code. Si la recherche est régulièrement ignorée, on peut exiger explicitement de vérifier la source, puis répéter la comparaison. Mieux vaut joindre d'emblée le fait connu à la tâche, avec un lien ou un extrait. Quant au responsable produit qui évalue un agent pour une équipe, il a intérêt à inclure la langue des tâches de travail dans l'évaluation : un sens identique de la requête ne garantit pas un chemin de résolution identique.