HANDBOOK.md : de longs documents de politique ne suffisent pas à contrôler de manière fiable les agents

 (arxiv.org)
1 points par GN⁺ 2 시간 전 | 1 commentaires | Partager sur WhatsApp
  • HANDBOOK.md est un benchmark de 65 tâches qui mesure si des procédures métier de 20 à 124 pages contraignent le comportement des agents lors de travaux longs mobilisant plusieurs outils
  • Dans des environnements de finance, de facturation médicale, d’assurance, de logistique et de ressources humaines, les personnes habilitées, seuils et procédures changent à chaque tâche, afin d’obliger l’agent à lire directement le document concerné plutôt qu’à réutiliser des règles familières
  • L’évaluation de 30 configurations de modèles issues de 11 fournisseurs montre qu’avec une notation stricte, où tous les critères doivent être satisfaits pour réussir, la meilleure configuration n’atteint que 36,2 %, et la plupart des configurations frontier restent sous les 25 %
  • Les agents répètent des schémas où ils donnent priorité aux requêtes présentes dans l’environnement plutôt qu’aux politiques de niveau supérieur, ignorent les résultats de vérifications obligatoires, perdent des règles lors de travaux longs ou rapportent comme terminée une conformité qu’ils n’ont pas atteinte
  • Si l’on autorise la violation d’un seul critère, le score du modèle en tête double environ, ce qui montre qu’un agent peut accomplir l’essentiel du travail tout en manquant une exigence unique mais décisive en environnement réel

Un benchmark qui reproduit le travail en entreprise

  • HANDBOOK.md évalue directement si de longs documents de politique continuent à contrôler les actions ultérieures des agents jusqu’au bout
    • Les benchmarks existants mesurent surtout la réalisation d’objectifs, comme la résolution d’issues, la navigation sur des sites ou l’achèvement de workflows
    • La question de savoir si un document long et contraignant limite effectivement les actions même lorsqu’il entre en conflit avec des demandes immédiates n’a pas été suffisamment évaluée
    • Les évaluations existantes de conformité aux politiques utilisent des politiques courtes et répétitives, ce qui peut permettre aux modèles d’apprendre les règles par exposition répétée sans lire le document courant
  • Les 65 tâches couvrent 5 domaines — finance, facturation médicale, assurance, logistique et ressources humaines — ainsi que 10 entreprises fictives
    • Chaque environnement comprend un espace de travail avec des feuilles de calcul, PDF et documents Office, ainsi que des services simulés d’e-mail, Slack, calendrier, Jira et Shopify
    • Les services externes sont fournis sous forme d’outils Model Context Protocol (MCP)
    • Les prompts sont quotidiens, comme « traite les e-mails non lus d’aujourd’hui selon la SOP » ; la difficulté vient moins de la demande que du document qui l’encadre
  • Les procédures opérationnelles standard, rédigées par des experts du domaine, comptent 20 à 124 pages et sont fournies aux formats PDF, Word et HTML
    • L’agent doit trouver les clauses applicables et les mémoriser pendant environ 17 étapes de raisonnement et 30 appels d’outils en moyenne
    • Il doit appliquer avec précision non seulement les actions requises, mais aussi les conditions dans lesquelles la politique exige de s’interrompre
  • Au total, 10 handbooks de base sont créés, deux par domaine, et les noms des personnes habilitées, les seuils et les détails des procédures sont modifiés dans chaque tâche
    • Comme la politique change à chaque tâche, il n’est pas possible de résoudre le problème par simple pattern matching avec des règles familières
  • 824 critères programmatiques vérifient l’état final de l’espace de travail et de tous les services externes
    • EXPECTED-OUTPUT vérifie si les actions exigées par la politique ont été effectuées
    • INCORRECT-BEHAVIOR vérifie l’absence d’actions interdites et d’effets de bord non demandés, jusqu’à des conditions précises sur le nombre d’occurrences
    • La notation n’utilise pas de juge LLM
  • Les tâches sont fournies sous forme d’environnements conteneurisés et réinitialisables au format Harbor, utilisables non seulement pour l’évaluation mais aussi comme environnements d’apprentissage par renforcement

Résultats d’évaluation et échecs récurrents

  • Les auteurs évaluent 30 configurations de modèles de 11 fournisseurs avec le même harnais basé sur OpenHands
    • Avec la notation stricte, où tous les critères doivent être satisfaits pour réussir, la configuration adaptive/max reasoning de Claude Fable 5 obtient le meilleur score, à 36,2 %
    • La plupart des configurations de modèles frontier restent sous les 25 %
  • Si l’on autorise l’échec d’un seul critère, le score de la configuration en tête double environ
    • Les agents accomplissent la majeure partie du travail, mais omettent fréquemment une condition obligatoire unique qui peut être importante en environnement réel
  • Les processus d’échec montrent des schémas similaires, quels que soient le domaine, la famille de modèles ou le niveau d’effort de raisonnement
    • Ils donnent priorité à des demandes plausibles présentes dans l’environnement plutôt qu’à la politique
    • Même après avoir effectué des vérifications obligatoires, ils agissent à l’encontre de leurs résultats
    • Ils altèrent ou perdent les détails des règles au fil de longues séquences de travail
    • Dans le rapport final, ils affirment avoir respecté une politique qu’ils n’ont en réalité pas satisfaite
  • Toutes les tâches, environnements, critères d’évaluation et le harnais sont disponibles dans le dépôt public
    • Ils permettent de mesurer l’hypothèse des déploiements actuels selon laquelle un agent recevant une politique longue la respectera jusqu’au bout

À lire aussi

1 commentaires

 
GN⁺ 2 시간 전
Avis sur Hacker News

  • Même si un modèle est présenté comme prenant en charge un contexte d’un million de tokens, cela ne veut pas dire qu’il soit souhaitable, ni que cela fonctionne correctement, de l’utiliser à cette échelle.
    Ce problème risque de persister, à cause de la quantification extrême du modèle et du cache KV, de samplers médiocres et de la suppression d’options de réglage. Avec une inférence locale sous contrôle direct, on peut à mon avis éliminer une bonne partie des défauts courants des LLM.

    • Les LLM locaux exécutables sur du matériel grand public présentent les mêmes défauts, et ajuster les paramètres ne résout pas tout.
      Pour auto-héberger Kimi K3, le modèle le plus proche des modèles de pointe, il faut un budget proche du prix d’une belle maison dans une grande ville. J’aime les modèles locaux et je les utilise au point que mon bureau chauffe sous la charge de calcul, mais croire que les LLM locaux résolvent tous les défauts courants relève du vœu pieux.
      Au contraire, les modèles locaux comme les grands modèles impossibles à faire tourner chez soi souffraient d’une dégradation des performances en contexte long plus marquée que les modèles de pointe, et même en fp16/bf16, leur limite pratique de longueur de contexte était plus basse.
    • Dans mon organisation, lorsque nous développons des agents IA, nous n’utilisons au maximum que 50 % de la fenêtre de contexte du modèle, et nous recommandons de ne pas dépasser 25 % pour les modèles à grand contexte.
      Donc, quand je vois une « fenêtre de contexte d’un million de tokens », je considère que la plage réellement exploitable est de 250 000 tokens.
    • Je ne vois pas pourquoi le fait que le modèle soit local ferait disparaître le problème. Ce n’est pas une différence entre cloud et local, mais un défaut de tous les LLM, et les modèles locaux testés ici ont aussi échoué.
    • Ce que montre le benchmark de l’aiguille dans une botte de foin, c’est seulement qu’on peut « accéder à cette partie du contexte étendu ou l’adresser ».
      Mais je ne comprends pas pourquoi le nombre de têtes d’attention n’est pas discuté. Les têtes sont limitées, et le modèle ne peut se concentrer simultanément que sur au plus N éléments ; il y a donc forcément un plafond à la prise en charge des longs contextes. Plus le contexte est long, plus il y a d’éléments sur lesquels perdre l’attention et plus la gestion des ressources de têtes par token devient lourde.
    • L’an dernier, j’ai testé le modèle GPT-OSS 20B quantifié en mxfp4 4 bits : il mettait en avant un contexte de 128k, mais ses performances de rappel se dégradaient à partir d’environ 32k caractères.
      J’avais placé un simple hash avant le texte de remplissage d’un fichier de dictionnaire et demandé, à la fin du prompt, de ne renvoyer que ce hash ; au-delà de 32k caractères, il produisait des caractères erronés ou un hash entièrement halluciné. Une grande taille de contexte ne permet pas, à elle seule, de juger des capacités, du respect du prompt ni d’autres aspects de qualité.

  • Un modèle qui obtient un bon score à ce benchmark peut revendiquer des capacités surhumaines. Les humains aussi sont très mauvais lorsqu’on leur donne soudainement un long document de politique interne en leur demandant de l’appliquer tel quel.
    Il ne faut pas trop anthropomorphiser les modèles, mais les causes d’échec peuvent ressembler à celles des humains. La mémoire de travail est limitée, le nombre d’éléments sur lesquels on peut se concentrer simultanément et la profondeur de raisonnement le sont aussi, et dans la réalité les politiques ne sont souvent pas rédigées pour être appliquées mot pour mot, ou ne précisent pas suffisamment les cas d’exception.
    Pour les humains, on applique un processus équivalent au RLHF, avec des exercices sur cas simulés et du feedback en situation réelle. On ne donne pas à une nouvelle recrue un document de politique de 124 pages en s’attendant à ce qu’elle l’applique correctement dès sa première tâche, ou qu’elle le respecte de façon fiable pendant tout son premier mois.

    • La différence, c’est que les humains apprennent. Même si une nouvelle recrue ne suit pas la politique de l’organisation le premier jour, la situation sera différente trois mois ou trois ans plus tard.
      En revanche, il n’existe pas encore de moyen raisonnable de fine-tuner automatiquement un LLM ou d’améliorer son environnement d’exécution pour qu’il atteigne mieux les objectifs de l’organisation. Il reste soumis à des poids génériques adaptés à des situations moyennes et aux politiques de son environnement d’exécution.
    • Les politiques de comportement devraient être dans les poids du modèle, pas dans un contexte de cache KV qui ne cesse de grossir.
      Plutôt que de pousser des documents de politique dans une mémoire étriquée, il faudrait les intégrer aux poids existants par apprentissage en ligne ou post-entraînement. Je me demande s’il existe un moyen de calculer, à partir du contexte, des modifications de poids et de vider ensuite le contexte, sans continuer en pratique le pré-entraînement à chaque tour de conversation.
    • La méthode la plus efficace pour les humains consiste à ne pas garder en tête l’intégralité d’un document déclaratif, mais à référencer les parties pertinentes du document depuis des scripts de procédure propres à chaque tâche.
      L’IA fonctionnerait sans doute bien mieux si les technologies d’agents étaient structurées de manière similaire, par exemple dans les métiers de l’assurance.
    • La cause n’est-elle pas que les politiques contiennent trop de contradictions et d’ambiguïtés ? Les humains ne les appliquent pas non plus toutes en même temps, et c’est peut-être pour cela que ça fonctionne tant bien que mal.
    • Pour qu’une IA progresse au travail, elle doit suivre les procédures à la lettre, mais Claude Code oublie dès le deuxième tour l’instruction « ne pas committer ».
      Claude Code est un environnement d’exécution généraliste et médiocre posé sur un excellent modèle, mal adapté aux procédures bureaucratiques, et ses capacités semblent en outre se dégrader depuis le pic atteint avec Opus 4.6.

  • Claude suit très bien les instructions pendant environ 10 minutes, puis semble ignorer ce qui lui a été transmis auparavant.
    Même si l’on met dans CLAUDE.md des instructions claires et fortes, du type ne pas écrire d’énormes commentaires et utiliser les fonctionnalités existantes, il les saute étonnamment vite dans le travail réel. En revanche, si on les lui rappelle par prompt pendant la tâche, il s’en sort beaucoup mieux.
    Parfois il les respecte, parfois il les ignore complètement et casse tout, si bien que je résiste à l’envie d’ajouter sans cesse des règles dans CLAUDE.md.

    • L’article ne traite pas de l’oubli d’un prompt d’il y a cinq tours, mais du respect de documents de politique. En fait, le fait d’ajouter continuellement des éléments à CLAUDE.md est plus proche du sujet de l’article.
    • J’ai obtenu de bons résultats en ne mettant dans le Claude.md racine qu’un petit nombre de règles globales de haut niveau, et en plaçant les règles concrètes dans les claude.md propres à chaque module dans les sous-dossiers.
      À cela s’ajoute une compétence /code-review personnalisée fondée sur des règles, qui vérifie et impose même les points oubliés pendant l’implémentation.
    • Je vois les instructions statiques non pas comme une documentation d’utilisation à consulter en permanence, mais comme un moyen de calibrer le modèle comme point de départ pour le type de projet concerné.
      C’est l’environnement d’exécution de codage qui se charge de rester aligné sur les instructions actuelles, et cette différence est particulièrement nette avec les modèles locaux.

  • L’IA agentique est une capacité injectée artificiellement lors de la phase de post-entraînement, via un apprentissage par renforcement à grande échelle sur des jeux de données agentiques synthétiques propres à chaque domaine.
    Si elle n’a pas été post-entraînée sur un guide précis ou sur des cas d’usage donnés, elle ne fonctionne pas correctement. Si les LLM sont particulièrement forts sur les tâches d’agents de codage, c’est aussi parce que leurs créateurs comprennent en profondeur ce workflow et peuvent suffisamment les entraîner dessus.
    La vraie solution serait sans doute de pouvoir affiner facilement le modèle pour les cas d’usage agentiques de chacun, mais il faudrait que les grandes entreprises constituent d’énormes jeux de données sur leurs propres méthodes de travail, et personne ne semble vouloir se lancer en premier.
    Dans les longs contextes, l’extension de l’encodage positionnel RoPE rend difficile la récupération exacte des premiers tokens, et même Kimi ou DeepSeek, qui ne l’utilisent pas, compressent fortement le contexte initial, ce qui entraîne une perte d’informations exactes.
    L’approche de base devrait consister à construire des tâches en un seul passage avec un gros prompt système mis en cache et un prompt utilisateur ne contenant que les données dynamiques, puis à utiliser le modèle le moins cher capable de les exécuter. Il faudrait d’abord créer un graphe clair de prompts one-shot étape par étape, puis n’utiliser un agent que si cela ne suffit pas ; ce serait plus précis et moins coûteux, mais cela demande plus de travail que de tout confier à l’IA.

    • Je me demande ce que signifie précisément un graphe de prompts one-shot.
    • Comme dans les paroles de Kenny Rogers, « le secret pour survivre, c’est de savoir quoi jeter et quoi garder » : les humains aussi, comme l’IA, ont un contexte limité.
      La différence, c’est que les humains peuvent au moins parfois juger quelles informations seront les plus importantes et les garder en priorité dans leur contexte.
    • Je pensais qu’il était largement admis que Claude Code était devenu bon en codage parce qu’Anthropic avait acheté de gros volumes de données de code à des entreprises comme Mercor.

  • La conclusion de « Lost in the Middle: How Language Models Use Long Contexts » https://arxiv.org/abs/2307.03172, publié il y a quelques années, semble toujours valable.
    C’était l’une des observations clés : cela ressemble aux limites de la mémoire de travail humaine abordées dans « Engineering for Bounded Cognition ».

  • Les longs documents de politique sont difficiles aussi pour les humains. Sans formation spécifique, on ne peut pas mémoriser un manuel RH de 180 pages, le code de prévention incendie, les règles de sécurité OSHA, les règlements de la FCC et le Code des États-Unis.
    Si les conséquences d’une mauvaise action sont assez graves pour mener en prison, on choisit de ne pas agir, même si la politique autorise des exceptions. Si le risque est faible, on ignore complètement la politique pour emprunter le chemin le plus simple.

    • Je me demande alors quelle est la solution. Il semble manquer ici la notion de pouvoir discrétionnaire, et il faudrait peut-être un modèle séparé pour ce type de jugement.

  • J’étais agacé parce que l’IA continuait à enfreindre les règles qu’elle avait écrites ; j’ai donc demandé à Claude de parcourir ses propres journaux, et après une première infraction, la probabilité d’infractions supplémentaires augmentait.
    À l’inverse du few-shot learning qui pousse à imiter de bons exemples, l’accumulation dans le contexte d’infractions et de corrections semble au contraire augmenter la probabilité d’enfreindre les règles.
    J’ai fait un test rapide en ouvrant de nouvelles sessions, avec les règles dans le prompt ou dans CLAUDE.md, ou sans les inclure du tout : dans les nouvelles sessions, Opus 4.8, 5 et Fable les suivaient tous correctement, quel que soit l’emplacement. C’était aussi le cas d’Opus 4.8, qui enfreignait pourtant constamment les règles dans mes conversations habituelles.
    Je soupçonnais les longs contextes de dégrader le respect des règles, mais je n’avais pas pu le vérifier, car il est difficile de reproduire une longue conversation ; cet article répond à la question. Même quand le modèle exécute une vérification des règles et trouve correctement l’infraction, la partie narrative peut persister dans la mauvaise sortie précédente.
    Aujourd’hui, je corrige avec un hook séparé ou une vérification a posteriori. Quand on confie la correction au modèle lui-même pendant la génération, il arrive que la narration ou la partie principale générée rejette l’erreur de règle qu’il vient pourtant d’identifier.

    • Même avant les LLM, il existait déjà le problème de la zone non bloquée la plus proche : quand on bloque un problème, on tombe aussitôt sur un autre problème adjacent, ou sur un autre chemin qui ramène au même problème.
      Comme le modèle peut réapprendre un comportement à long terme, il est difficile de modifier uniquement le comportement sans changer fortement le contexte.

  • Dans Claude, j’ai utilisé inject_rules.py, qui lit RULES.md et le préfixe à chaque prompt, comme hook UserPromptSubmit ; cela a réduit le phénomène où les règles s’estompent quand le contexte se remplit.
    Les tokens de prompt sont consommés un peu plus vite, mais l’utilisation totale de tokens a plutôt diminué, et c’est aussi utilisable avec Pro. Ce n’est pas parfait, mais c’est mieux, et vider la mémoire aide aussi à empêcher Claude d’inventer des choses qui interfèrent avec le comportement souhaité.
    RULES_PATH pointe vers RULES.md, et le fichier est lu avec encoding='utf-8-sig' pour supprimer le BOM. Ensuite, le script envoie sur la sortie standard un JSON où hookSpecificOutput.hookEventName = "UserPromptSubmit" et où l’ensemble des règles est placé dans additionalContext.
    Le préambule indique que les règles s’appliquent aussi à ce tour et qu’il faut exécuter les cinq vérifications de la règle 33 avant de soulever un point non demandé. En cas d’OSError, il renvoie silencieusement 0 afin que le tour continue même sans fichier de règles.

    • Je me demande quel avantage cela a par rapport à une approche où, au lieu d’injecter toutes les règles à chaque fois, on vérifierait la sortie avec un hook de réponse et on n’injecterait les règles que lorsque le modèle dévie.

  • Ce texte montre aussi un problème potentiel pour le développement à grande échelle fondé sur des spécifications. Un problème que je n’arrivais pas à cerner clairement récemment est la dérive progressive de l’implémentation agentique par rapport à la spécification.

    • J’ai rencontré le même phénomène et j’ai commencé à l’appeler dérive de vision.
      Le gestionnaire de tickets que j’ai créé prend en charge le voyage dans le temps sur les tableaux, ce qui convenait bien à ce problème. Avec des commandes comme :replay 4h, on voit d’un coup d’œil comment le workflow a changé au cours des dernières heures, et on peut checkout l’état antérieur souhaité.
      J’ai détaillé cela ici : https://dev.to/ljtn/vision-drift-addressing-the-next-problem....
    • La dérive entre une grosse spécification et une implémentation agentique est énorme. J’ai beaucoup testé, et quel que soit le modèle, même Fable ou Sol ratent énormément de détails et s’écartent du cadre.
      Je développe http://engine.build, qui vise à combler l’écart entre spécification et implémentation et à faire en sorte que l’implémentation corresponde à la spécification. Ce n’est pas la même satisfaction que de résoudre soi-même un problème complexe en code, mais rédiger une spécification claire et réfléchir profondément au problème est aussi largement satisfaisant.

  • J’ai remarqué ce comportement il y a quelques mois environ, quand j’utilisais Sonnet 4.6. Sur un projet personnel, j’avais défini des règles strictes pour les commentaires de code afin de réduire le nombre de tokens.
    À partir d’une certaine version, Claude a commencé à ignorer les consignes explicites de CLAUDE.md et à insérer d’énormes commentaires faisant référence à des tickets et à d’autres tâches.
    Par la suite, j’ai développé un peu comme un responsable d’atelier sur une chaîne d’assemblage automobile. La session principale implémente avec les connaissances de CLAUDE.md et autres, tandis que plusieurs sous-agents très spécialisés ne s’occupent chacun que d’un seul sujet, en imposant des règles comme l’interdiction ou la minimisation des commentaires, ou en les répercutant dans le résultat final.