Transformers paper
Article fondateur sur l'architecture Transformer.
Consulter l’original ↗Travaux fondateurs et protocoles d’évaluation, avec renvoi vers les documents originaux.
Bibliographie commentée : distinguez prépublication, publication évaluée et projet expérimental. Les résultats mesurent des configurations données et ne décrivent pas forcément les capacités actuelles des outils.
Article fondateur sur l'architecture Transformer.
Consulter l’original ↗Article de recherche sur génération augmentée par récupération.
Consulter l’original ↗Évaluation d'agents sur des tâches Web réalistes.
Consulter l’original ↗Évaluation de l'usage d'interfaces visuelles par les agents.
Consulter l’original ↗Environnement d'évaluation des agents utilisant un ordinateur.
Consulter l’original ↗Publication sur l'optimisation pour les moteurs génératifs.
Consulter l’original ↗Index ouvert de métadonnées scientifiques.
Consulter l’original ↗API de métadonnées et identifiants scientifiques.
Consulter l’original ↗Conception responsable et Web destiné aux agents.
Consulter l’original ↗Publication fondatrice de Lewis et al. (2020).
Consulter l’original ↗Étude de l’articulation entre production de plans et interactions avec des sources ou environnements. Elle aide à comprendre les agents utilisant des outils, sans établir une robustesse générale.
Méthode à examiner : Comparer les étapes de raisonnement rapportées et les interactions externes, puis examiner les succès comme les échecs dans les tâches expérimentales.
Attention : Les résultats du papier dépendent d’environnements et modèles précis et ne garantissent ni sécurité ni fiabilité des agents actuels.
Travail NeurIPS sur l’apprentissage du recours à des outils externes par des modèles de langage. Le périmètre expérimental concerne certaines APIs et tâches ciblées.
Méthode à examiner : Observer comment la sélection d’outil, ses arguments et son résultat s’intègrent à une réponse, puis mesurer les erreurs de sélection.
Attention : L’usage d’une API par un modèle ne suffit pas à établir autorisation, qualité de données ou conformité des systèmes déployés.
Étude publiée dans TACL montrant que la position d’informations pertinentes dans un long contexte peut influencer leur exploitation par des modèles. Important pour concevoir le RAG et tester les passages récupérés.
Méthode à examiner : Comparer des tâches avec passage utile au début, au milieu et à la fin, en conservant les autres paramètres.
Attention : Les effets varient selon le modèle, la tâche et la longueur de contexte ; ne pas transférer mécaniquement les résultats à tous les systèmes.
Environnement expérimental auto-hébergeable proposant des tâches Web réalistes pour mesurer l’aptitude d’agents à mener des actions. Les évaluations sont contextualisées par les sites et scénarios du banc d’essai.
Méthode à examiner : Utiliser des tâches reproductibles et vérifier l’état final du site, plutôt que noter uniquement la qualité des textes produits.
Attention : Un benchmark ne reproduit pas toutes les permissions et ambiguïtés d’un site public, ni les coûts d’une application réelle.
Environnement de tâches Web dans lesquelles la perception visuelle complète l’interprétation textuelle. Il aide à évaluer les agents qui naviguent dans des interfaces destinées aux humains.
Méthode à examiner : Comparer les succès d’agents multimodaux sur des tâches nécessitant une information visuelle difficile à retrouver dans le texte.
Attention : Les résultats ne démontrent pas automatiquement la qualité d’accès pour les personnes handicapées ou les performances en production.
Banc d’essai de tâches informatiques impliquant plusieurs applications et états de système. Il illustre la difficulté de réussir des opérations réelles malgré des interfaces apparemment compréhensibles.
Méthode à examiner : Comparer les versions des environnements, les critères de réussite et les contrôles d’état final, sans reporter des scores historiques comme performances actuelles.
Attention : Le benchmark connaît des évolutions ; les scores issus de versions ou jeux de tâches différents ne sont pas directement comparables.
Proposition d’évaluation de systèmes RAG sur plusieurs dimensions, notamment récupération des passages et fidélité de la génération. Les métriques automatiques demandent une validation appropriée.
Méthode à examiner : Composer une grille avec pertinence du contexte, fidélité et qualité de réponse sur des exemples annotés.
Attention : Les évaluations automatiques peuvent être instables ou manquer des erreurs de fond ; les comparaisons exigent des tests humains.
Étude de stratégies et métriques de visibilité dans des moteurs de recherche génératifs. Les résultats portent sur des configurations d’essai, pas sur des garanties de classement universelles.
Méthode à examiner : Comparer les mesures définies par les auteurs à des observations actuelles d’un site donné, en distinguant domaine, langue et interface.
Attention : Des effets expérimentaux ne prouvent pas que llms.txt ou une technique particulière est obligatoire pour les moteurs actuels.
Étude ICLR sur des tâches de correction de code issues de problèmes de dépôts réels. Elle permet d’étudier des tests exécutables plutôt que de juger seulement des explications de code.
Méthode à examiner : Examiner les tests échouant avant une modification et passant après, tout en contrôlant les régressions et les droits sur le code.
Attention : Les résultats historiques ne représentent pas les capacités de tous les assistants ni la qualité de maintenance d’un logiciel déployé.
Environnement de recherche pour analyser les injections de consignes et les défenses dans des agents utilisant des outils. Il distingue les attaques simulées des incidents réellement observés.
Méthode à examiner : Construire des tests contrôlés avec actions inoffensives, outils limités et journalisation des réussites comme des refus incorrects.
Attention : La réussite sur un jeu d’attaque ne démontre pas l’immunité face à de nouvelles variantes ou à des systèmes différents.