WikiSkill de Google : apprendre aux agents les règles de votre entreprise, tout seuls

Google Research a publié une étude intitulée WikiSkill qui fait beaucoup parler, et le nom induit en erreur au premier abord : ce n'est pas une compétence unique mais un framework pour applications agentiques. La métaphore centrale est celle d'un nouvel employé lors de sa première semaine. Le débutant fait des erreurs, note ce qui n'a pas fonctionné, et cesse de répéter l'erreur, le tout sans retourner à l'école. Ici, le modèle de langage sous-jacent n'est jamais réentraîné et aucun fine-tuning n'a lieu ; à la place, le framework réécrit en continu le fichier d'instructions de l'agent jusqu'à ce que les résultats tiennent.

Le problème qu'il attaque, ce sont les règles d'entreprise non écrites. Un nouveau venu en finance peut maîtriser les tableurs sur le bout des doigts et échouer quand même le premier mois, car les conventions décisives ne vivent que dans la tête des collègues. Dans la démo, un cas signifie six unités là où la norme habituelle serait de douze, et un produit retourné est saisi comme un chiffre de revenu négatif. Aucun modèle ne peut déduire de telles habitudes locales de la connaissance générale, aussi capable soit-il, car elles n'ont jamais été écrites nulle part.

Le remède est une boucle avec un test d'acceptation strict. Chaque fois que l'agent échoue, une leçon décrivant l'échec est ajoutée au fichier d'instructions, et le changement ne survit que si les scores s'améliorent sur des travaux que l'agent n'a jamais vus. Chaque tour se termine donc par un verdict : garder ou jeter, et le fichier continue d'évoluer jusqu'à ce que l'ensemble passe. L'automatisation remplace l'humain qui, sinon, rééditerait les instructions à la main après chaque erreur.

Pour la démo, le présentateur a reconstruit cette boucle sur son propre ordinateur portable autour d'une feuille de clôture mensuelle en désordre d'une entreprise fictive, pilotant tout depuis une fenêtre de chat construite sur le kit de développement d'agents de Google. Demander à l'agent de se présenter révèle l'architecture : un worker qui lit les fichiers en désordre, écrit un petit script de nettoyage, l'exécute et enregistre un fichier propre ; un checker qui note le résultat par rapport à des chiffres connus comme corrects ; un preneur de notes qui enregistre chaque échec ; un rédacteur de guide qui convertit les notes en un seul changement d'instruction ; et un manager strict qui teste ce changement sur dix feuilles jamais vues et ne le conserve que si le score augmente.

Les données de test elles-mêmes sont délibérément moches, comme le sont les vrais exports de ventes. Un tableau mélange plusieurs formats de dates, laisse des trous, orthographie les noms de régions de façon incohérente, abrège les unités de manière incompatible et mélange les majuscules dans les libellés de produits. Les retours apparaissent sous forme de lignes de revenus négatifs qu'un débutant lirait facilement de travers. Quiconque a déjà fusionné des tableurs de bureaux régionaux reconnaîtra le genre instantanément.

La spécification de l'équipe finance ajoute une seconde difficulté : elle exige un tri par date, région et identifiant de commande, plus les conventions financières standard pour les dates, les unités, les retours et les doublons, mais personne n'a défini ce qu'est réellement la norme locale. Exécuté sans aucun apprentissage, avec le comportement du premier jour, l'agent repère les valeurs de région manquantes et liste les échecs mais ne peut pas les résoudre, ce qui est exactement le propos : la détection sans le règlement local ne mène nulle part.

C'est là que le schéma de l'article, trois collègues plus un manager strict, prouve sa valeur, et là que la comparaison avec les techniques plus anciennes prend tout son sens. La récupération d'information a besoin d'un document à consulter, mais ici les règles n'existent dans aucun document. Le fine-tuning prend des jours et ses leçons ne peuvent pas être relues. La mémoire simple enregistre des choses mais ne vérifie jamais si la mémoire était correcte. WikiSkill apprend des erreurs, écrit la leçon en prose lisible et ne la conserve que lorsqu'elle aide de manière démontrable, c'est pourquoi le présentateur qualifie le résultat de spécial.

L'entraînement a porté sur vingt fichiers : dix pour la pratique et dix feuilles mises de côté pour le verdict du manager. Le tableau de score visible part d'une base de soixante-dix pour cent, rejette les onzième et douzième tentatives à quarante pour cent, et accepte finalement la septième itération avec dix sur dix. Les tentatives trois à six se sont effondrées pour une raison banale : le quota d'utilisation épuisé sur le compte du présentateur lui-même, ce qui relève d'un problème de configuration plutôt que d'une défaillance du framework, mais reste instructif sur le coût d'exploitation.

Puis vient la scène de la récompense : le même fichier et le même modèle, cette fois avec les consignes apprises chargées. L'exécution passe, chaque ligne correspond à la vérité terrain attendue, et les retours sont traités avec le bon signe. Mieux encore, les consignes obtenues sont une prose lisible indiquant quand chaque règle financière s'applique et quand elle ne s'applique pas, y compris des habitudes que l'agent a déduites lui-même plutôt que de les recevoir toutes faites.

À qui cela s'adresse-t-il ? À toute équipe exécutant un travail répétitif où les erreurs viennent des habitudes maison plutôt que de la connaissance du monde : la clôture mensuelle où l'export de chaque magasin a ses propres particularités, ou le routage des factures où seule l'équipe comptable fournisseurs connaît le bon centre de coûts. Le présentateur a monté toute l'expérience en la décrivant en langage clair à un assistant de codage, en téléchargeant l'article et en s'appuyant sur le kit d'agents de Google, et il renvoie vers une implémentation communautaire ainsi que le lien de l'article pour la reproduction. Les agents de longue durée aux routines stables en tirent le plus de bénéfices ; les tâches ponctuelles, le moins.