Revue d’articles — Suivi des instructions, cohérence de sécurité et conception d’agents avec Agentic RAG

Résumé exécutif

Cette fois (2026-04-01), nous abordons de nouvelles approches d’évaluation, d’alignement et de stabilité des représentations, ainsi que de conception d’agents, qui déterminent si un LLM « fonctionne sur le terrain ».

Concrètement, nous cherchons à faire avancer une « évaluation proche de l’implémentation » avec FireBench, qui mesure le suivi des instructions dans les entreprises et les scénarios de collaboration via API.

Par ailleurs, nous examinons pourquoi l’alignement RLHF a tendance à devenir « superficiel » via un article qui creuse théoriquement le sujet, ainsi que la stabilité des représentations internes liée à la cohérence des conditions de persona.

Enfin, le SoK, qui vise à systématiser l’agentic RAG comme cadre unifié, cherche à dresser une « carte » de la recherche.

Articles à surveiller : les points de contact entre suivi des instructions, cohérence, stabilité des représentations et conception d’agents

Article 1 : FireBench : évaluation du suivi des instructions dans les applications LLM pilotées par des entreprises et des API

• Auteurs & affiliation : Yunfan Zhang, Yijie Bei, Jetashree Ravi, Pawel Garbacki. L’affiliation est supposée consultable à partir de la page de l’article ; au moins, les noms d’auteurs peuvent être vérifiés sur cette page. La source est FireBench (page de l’article).
• Contexte de recherche et question : l’évaluation des LLM a longtemps été centrée sur des « réponses façon chat ». Or, en pratique, ce sont l’exactitude du format de sortie, le respect des étapes, l’hypothèse d’appel d’outils, ou encore les contraintes propres aux domaines métiers qui comptent. L’article cherche alors à répondre à la question : « quel benchmark permet de mesurer le “suivi des instructions” dans les environnements réels des entreprises et des API ? » FireBench (page de l’article)
• Méthode proposée : la proposition est le benchmark de suivi des instructions “FireBench”, conçu à partir de schémas observés en situation réelle. L’article résume l’idée en indiquant qu’il évalue 6 dimensions de compétences centrales, avec plus de 2 400 échantillons, et qu’il met en évidence, pour 11 types de LLM, le comportement et les défis dans des scénarios à visée entreprise. FireBench (page de l’article)
• Résultats principaux : à partir de la page de l’article, l’objectif consistant à combler le manque des benchmarks davantage « orientés chat » est clair, notamment via la description de la configuration de l’évaluation (plus de 2 400 échantillons, 6 dimensions, 11 LLM).
• Intérêt et limites : l’intérêt est que les indicateurs d’évaluation se déplacent de « la conversation en laboratoire » vers « les exigences d’exploitation ». La limite est que si la conception de l’évaluation est trop optimisée pour le terrain, il devient difficile de l’étendre à d’autres domaines. Un benchmark n’est pas universel : il est essentiel de comprendre quelles hypothèses d’« exploitation réelle » il adopte.
• Source : FireBench: Evaluating Instruction Following in Enterprise and API-Driven LLM Applications（FireBench）

Si l’on compare l’idée de FireBench à une analogie pour débutants, on peut dire que l’évaluation traditionnelle ressemblait davantage à une « dégustation des plats », tandis que FireBench consiste à tester « les règles d’hygiène de la cuisine, les procédures, les quantités et la chronologie ». Le suivi des instructions (instruction following) ne consiste pas simplement à renvoyer des phrases qui « ressemblent » à ce qu’on attend : c’est la capacité à produire de façon stable les sorties attendues en respectant les spécifications.

De plus, à mesure que ce type d’évaluation progresse, les entreprises peuvent parler de la sélection de modèles non plus comme d’une « question de préférence », mais comme de la « probabilité d’adéquation aux exigences ». Par exemple, dans des contextes où des contraintes de format strictes sont imposées lors de l’intégration via API — résumés de demandes, classification de tickets, assistance au codage — les tests deviennent des briques de garantie de qualité (QA), directement mobilisables. Cependant, si la distribution de l’ensemble d’évaluation est biaisée, les scores le seront aussi : avant toute mise en production, il faut mettre en place une vérification opérationnelle pour s’assurer que l’ensemble d’évaluation contient une « difficulté proche de celle des données de l’entreprise ».

Article 2 : Why Is RLHF Alignment Shallow? A Gradient Analysis (Pourquoi l’alignement RLHF est-il superficiel ? Une analyse des gradients)

• Auteurs & affiliation : Robin Young (l’affiliation est supposée consultable à partir de la page de l’article). La source est arXiv
  .04857.
• Contexte de recherche et question : l’alignement via RLHF (Reinforcement Learning from Human Feedback) semble efficace dans de nombreuses expériences ; pourtant, on observe un phénomène où l’amélioration paraît « limitée ». L’article cherche alors à expliquer, d’un point de vue théorique, « à quelle position, et avec quelle intensité, le signal d’alignement atteint la phase d’apprentissage », autrement dit comment les gradients se comportent. arXiv
  .04857
• Méthode proposée : l’article décrit comment le gradient se concentre sur certaines positions de tokens et disparaît ailleurs. Il caractérise cela en décomposant l’idée de sequence-level harm (nocivité sur la séquence entière), et en modélisant le tout comme une covariance entre une espérance conditionnelle et une fonction de score. En résumé, l’article affirme que le gradient au temps/position t peut s’exprimer sous forme de relation entre « la nocivité espérée conditionnellement » et la « fonction de score ». arXiv
  .04857
• Résultats principaux : ce qui compte comme résultat pour un résumé de texte, c’est qu’une structure émerge : « l’alignement basé sur les gradients concentre le signal sur la position qui fixe la nocivité, et le fait disparaître ailleurs (à distance) ». En outre, cette propriété pourrait expliquer des observations où la divergence KL entre le modèle aligné et le modèle de base est biaisée vers les premiers tokens. arXiv
  .04857
• Intérêt et limites : l’intérêt est de dépasser l’idée « si on exécute RLHF, ça s’améliore à peu près » et de formuler théoriquement le mécanisme expliquant pourquoi les signaux d’apprentissage parviennent difficilement à destination. La limite est que la modélisation sur laquelle repose la théorie (définition de la nocivité, hypothèses de décomposition, etc.) peut ne faire qu’approximations des risques de sécurité complexes du monde réel.
• Source : Why Is RLHF Alignment Shallow? A Gradient Analysis（arXiv
  .04857）

Cet article offre un angle différent : il évite de simplifier l’alignement (alignment) comme s’il s’agissait d’une « classification supervisée ».

En reformulant pour débutants : si, pendant l’apprentissage, « les endroits où cela fonctionne » se limitent à une zone finie, la conduite aux endroits plus éloignés a plus de chances de ne pas s’améliorer.

Intuitivement, c’est comme dans un jeu où les mauvais résultats se décident dans les derniers coups : s’entraîner surtout au début ne suffit pas à augmenter le taux de victoire. Autrement dit, si le signal d’apprentissage fourni par RLHF (récompense ou perte liée à la nocivité) apparaît fortement au moment où la nocivité se confirme, mais reste faible avant et après ce moment, alors il est naturel que l’optimisation donne l’impression d’un « alignement superficiel ».

Du point de vue de l’impact sur la société et l’industrie, la conception des stratégies d’évaluation et d’apprentissage pourrait évoluer vers une prise en compte de « l’étape où la sécurité se décide ». Par exemple, renforcer les contraintes dès les premiers tokens (ou concevoir des points d’intervention avant que la nocivité ne soit déterminée) pourrait être relié plus facilement à des justifications théoriques, et pas seulement à des règles empiriques.

Article 3 : Probing the Lack of Stable Internal Beliefs in LLMs (Explorer l’absence de croyances internes stables dans les LLM)

• Auteurs & affiliation : Yifan Luo, Kangping Xu, Yanzhen Lu, Yang Yuan, Andrew Chi-Chih Yao (l’affiliation est supposée consultable à partir de la page de l’article). La source est arXiv
  .25187.
• Contexte de recherche et question : on attend qu’un LLM doté d’une personnalité (persona) conserve, à chaque interaction, « la même personnalité et la même tendance de croyances ». Pourtant, en réalité, même avec des dialogues dans les mêmes conditions, le comportement peut varier. L’article cherche donc à répondre à la question suivante : « sous quelles formes l’absence de croyances internes stables (internal beliefs) se manifeste-t-elle dans les observations ? » arXiv
  .25187
• Méthode proposée : l’approche met au centre le fait de considérer les représentations internes comme des « croyances » et de mesurer/prober leur cohérence. Même dans l’abstract, l’article indique que pour qu’un LLM guidé par une persona imite des traits de personnalité humains (ténacité, fiabilité, etc.), il faut des tendances d’action cohérentes. arXiv
  .25187
• Résultats principaux : l’essentiel de cet article est de montrer, via du probing, que des croyances internes stables pourraient manquer. Au moins, le cadre de la problématique est clair : pour qu’un LLM piloté par persona ait une « cohérence de comportement », il faut une stabilité interne. arXiv
  .25187
• Intérêt et limites : l’intérêt est de faire descendre au niveau des représentations internes « pourquoi cela n’est pas cohérent », au-delà de la simple qualité des sorties en surface. La limite est que la notion de croyances internes dépend d’hypothèses sur l’interprétation du modèle ; les résultats observés pourraient aussi s’expliquer par d’autres causes (distribution des données d’entraînement, facteurs de sampling pendant l’inférence, différences de prompts).
• Source : Probing the Lack of Stable Internal Beliefs in LLMs（arXiv
  .25187）

Pour les débutants, on peut comprendre les croyances internes (internal beliefs) comme des « notes de politique dans la tête ». Les humains prennent des décisions similaires dans des situations proches, et c’est la stabilité des croyances derrière cela. De la même façon, dans le cas des LLM, lorsque l’on donne une persona spécifique, si les représentations internes sont maintenues « dans la même direction », alors une cohérence apparaît.

En revanche, si l’interne oscille, chaque réponse peut sembler plausible à chaque fois, mais à long terme, on observe plus facilement un « décalage » : ce phénomène se répercute directement sur l’expérience utilisateur (UX) et la fiabilité des opérations. Par exemple, si un agent de support client change brusquement de ton en plein milieu de la conversation, ce n’est peut-être pas seulement un problème de formulation sur le moment : c’est peut-être un signe que la « structure osseuse » de la persona conçue n’est pas maintenue.

Côté industrie, on peut s’attendre à ce que les LLM à persona soient étudiés non seulement comme un « problème de templates de sortie », mais aussi comme une question portant sur le maintien d’état pendant le raisonnement et l’alignement pendant l’entraînement.

Article 4 : SoK : Agentic RAG — First Unified Framework for Autonomous Retrieval-Generation Systems (SoK : Agentic RAG — premier cadre unifié pour les systèmes autonomes de recherche-génération)

• Auteurs & affiliation : dans un format SoK (Survey of Knowledge), il est possible que les auteurs soient multiples ; cependant, la source consultée confirme au moins l’ID et le résumé du cadre. La source est la page de résumé du SoK Agentic RAG (un ID arXiv est indiqué comme arXiv
  .07379).
• Contexte de recherche et question : le RAG (Retrieval-Augmented Generation) évolue : il ne s’agit plus seulement d’un pipeline « recherche → génération », mais d’une « agentification » où le LLM ajuste de façon autonome plusieurs étapes. Toutefois, la recherche est fragmentée et l’évaluation n’est pas unifiée, tout comme les taxonomies ne sont pas partagées. L’article cherche donc à créer une « carte des connaissances » : comment organiser l’agentic RAG, comment l’évaluer, et sur quoi faut-il faire attention. Page SoK Agentic RAG
• Méthode proposée : en tant que SoK, l’article explique d’abord la nécessité d’un agentic RAG (pourquoi le SoK est nécessaire), puis présente comme objet de systématisation les éléments de l’architecture autonome ayant évolué à partir du retrieve-and-generate (raisonnement multi-étapes, gestion dynamique de la mémoire, recherche itérative, etc.). Page SoK Agentic RAG
• Résultats principaux : les « résultats principaux » identifiables sur cette page consistent à expliciter la fragmentation de la recherche et les risques associés en vue d’un cadre unifié (par exemple : incohérence des évaluations, risques systémiques potentiels, absence de classification), tout en mettant en avant la nécessité de l’intégration. Page SoK Agentic RAG
• Intérêt et limites : l’intérêt est qu’un « remue-méninges » qui aligne termes et axes d’évaluation pourrait être fourni dans un domaine qui s’étend rapidement, celui de l’agentic RAG. La limite est que, comme un SoK est essentiellement une « mise en ordre », il ne présente pas forcément des améliorations numériques aussi directes que les articles produisant un nouvel SOTA expérimental.
• Source : SoK: Agentic RAG — First Unified Framework for Autonomous Retrieval-Generation Systems（arXiv
  .07379）

Encore une fois, on peut le reformuler par analogie pour débutants. Le RAG « classique » donne l’impression de « chercher un livre en bibliothèque, puis le lire et en faire un résumé ». En revanche, l’agentic RAG ressemble davantage à un état de fonctionnement où l’on « cherche → lit → identifie ce qu’on ne comprend pas → cherche à nouveau de façon supplémentaire → change éventuellement de stratégie » en une seule activité.

Dans ce contexte, ce qui complique la vie des chercheurs, c’est que, même si le niveau de granularité des tâches diffère d’un article à l’autre, cela soit appelé par le même nom. Le cadre unifié visé par le SoK cherche à aligner ce qui constitue des « composants indispensables », ce qui relève des « choix d’implémentation », et ce qu’il faut mesurer dans l’évaluation. Une fois cela fait, les comparaisons entre modèles et conception d’agents peuvent être discutées non plus seulement comme des « différences de performances de surface », mais comme des écarts de capacité dans les mêmes conditions.

Du point de vue industriel, le résultat pourrait être qu’on conçoive le RAG non pas comme une fonction isolée, mais comme un système incluant recherche, mémoire, prise de décision et interconnexion d’outils. En conséquence, il deviendrait plus facile de répondre à des exigences comme l’insertion d’informations erronées (hallucination), la capacité à suivre les mises à jour de l’information, et l’auditabilité.

Réflexions transversales entre les articles

Bien que les quatre articles semblent porter sur des thèmes différents, ils partagent un point commun : la direction consistant à mesurer, expliquer et concevoir les LLM comme des « systèmes qui garantissent un comportement », et non comme de simples « générateurs de sorties ».

FireBench vise à mesurer des propriétés de suivi des instructions dans une forme proche du terrain, au plus près des entreprises et des API. L’analyse des gradients pour RLHF explique la dynamique d’apprentissage « jusqu’où le signal d’alignement atteint », et fournit ainsi une justification quant à pourquoi les améliorations en sécurité peuvent rester limitées. Le probing des croyances internes cherche à observer les oscillations de cohérence de persona sous l’angle des états internes, menant à un diagnostic une étape plus profond que l’évaluation de qualité en surface. Le SoK de l’agentic RAG organise, via un cadre unifié, la fragmentation et l’absence d’unification de l’évaluation qui apparaissent quand la recherche-génération se transforme en agent.

En synthétisant, on voit se dessiner une migration du champ principal de la R&D : de « l’amélioration des scores du modèle » vers « la manière de garantir les propriétés que possède le modèle, sous quels hypothèses, dans quels états, et selon quels axes d’évaluation ». De plus, comme on le voit dans la page d’OpenAI Research, l’intérêt récent autour de la sécurité et de l’alignement s’étend aussi vers des contrôles de sécurité utiles en exploitation, comme la supervision et les niveaux hiérarchiques d’instructions (instruction hierarchy). OpenAI Research

Les articles suggèrent également que l’ensemble de la recherche est étroitement lié à l’agentification. Par exemple, Google DeepMind décrit des workflows agentic dans le contexte de la promotion de la découverte scientifique, comme Gemini Deep Think. Google DeepMind（Gemini Deep Think）

Plus l’agentification progresse, plus l’importance de l’évaluation, de l’alignement, du diagnostic des états internes et de la systématisation augmente. En effet, puisque les agents accumulent des décisions et des actions multiples, il devient impossible d’améliorer efficacement si l’on ne sait pas clairement « à quelle étape l’échec se produit ».

Comme feuille de route, on peut imaginer que ce cycle se renforce : (1) identifier le « mode de casse » grâce à des évaluations orientées terrain comme FireBench ; (2) réduire « les raisons pour lesquelles l’apprentissage n’atteint pas » grâce à des théories comme l’analyse des gradients de RLHF ; (3) diagnostiquer « où se situe l’oscillation » via le probing des croyances internes ; et (4) organiser « l’espace de conception » et « la base de comparaison » avec le SoK de l’agentic RAG.

Références

Cet article a été généré automatiquement par LLM. Il peut contenir des erreurs.