Pourquoi les benchmarks de mémoire d’agent induisent en erreur, et comment évaluer avec vos propres données

Les benchmarks publics concernant la mémoire des agents ne permettent pas de déterminer quel système conviendra à un problème donné, et plusieurs ne peuvent même pas indiquer de manière fiable quel système est supérieur. Les preuves ne sont pas subtiles : sur le benchmark le plus cité, un système rudimentaire qui insère toute la conversation dans la requête bat les produits dédiés à la mémoire, selon un article publié par un fournisseur de mémoire lui-même. Un audit indépendant a révélé que près de six pour cent des réponses de ce benchmark étaient incorrectes, et que son correcteur automatique acceptait environ deux réponses délibérément fausses sur trois. La réponse logique est d’arrêter de choisir en se basant sur les classements et d’établir une évaluation à partir de ses propres données.

Considérez comment une équipe choisit généralement un système de mémoire. Elle consulte le classement, prend ce qui se trouve en tête et l’implémente. Trois semaines après le lancement, l’agent se trompe de manière flagrante concernant une donnée que l’utilisateur avait corrigée mardi dernier. Il a également commencé à contredire une décision prise la semaine précédente. La seule information nécessaire pour répondre à une requête revient classée en dessous de quatre autres données irrelevantes. Le référentiel qualifiait ce système de meilleur sur le marché, sans pour autant mentionner le problème propre à l’équipe.

Une question se pose toujours après la création d’un système de mémoire : comment savoir s’il fonctionne ? La réponse peu rassurante est que les chiffres auxquels les équipes ont généralement recours ne permettent pas de y répondre, et certains ne sont d’aucune utilité pour personne.

Un classement sur le tableau de bord indique que le système a bien performé dans un test réalisé par quelqu’un d’autre, noté par un autre juge, selon la conception que ce dernier a de la bonne réponse. Cela ne dit pas si votre agent se souviendra de ce qu’un utilisateur a mentionné il y a trois semaines. Ce sont des questions distinctes, et seule l’une d’elles vous concerne.

Le critère de sélection que vous examinez mesure quelque chose d’autre

Le résultat principal mérite une réflexion. Prenons le benchmark le plus cité relatif à la mémoire de conversation. Une méthode ne disposant d’aucun système de mémoire, qui se contente de coller l’intégralité de la conversation dans la requête pour y répondre, a terminé en tête, légèrement devant les produits dédiés à la mémoire dans cette comparaison. Aucun critique ne l’a souligné. Ce résultat figure dans un article scientifique accompagné d’une bibliothèque de mémoire bien connue, Mem0, publié dans une revue évaluée par des pairs, où les auteurs indiquent que le contexte complet surpassait leur propre système en termes de précision brute, avec un temps de réponse environ dix fois plus élevé. Un autre fournisseur concurrent cite ce même fait concernant cet article, ce qui prouve que ce n’est pas une interprétation biaisée d’un seul camp.

C’est moins gênant qu’il n’y paraît, et il est important de le lire correctement. Coller tout le texte permet d’obtenir une précision parfaite, car rien n’a été omis. Cependant, cela ne fonctionne pas à grande échelle en raison du débordement et du coût quadratique. Ainsi, le critère d’évaluation récompense principalement le système qui parvient le mieux à atteindre une précision totale tout en utilisant moins de tokens. C’est utile pour mesurer. Ce n’est pas la même chose que de tester si un système peut retrouver un détail fourni par l’utilisateur un mois plus tôt ; quiconque interprète le classement comme étant ce dernier s’est laissé induire en erreur par sa propre supposition.

La vérité fondamentale est encore plus incertaine. Un audit distinct, public et reproductible mais non soumis à une revue par des pairs, a analysé en détail les réponses de référence du test et a constaté qu’environ six pour cent d’entre elles étaient erronées : faits inventés, raisonnement temporel défaillant, réponses attribuées au mauvais interlocuteur. Lorsque les auditeurs ont fourni au correcteur automatique standard des réponses fausses mais plausibles, celui-ci les a acceptées à hauteur d’environ deux tiers. Une mise en garde s’impose cependant. Les auteurs de l’audit, Penfield, conçoivent également des systèmes de mémoire, ce qui les rend pas entièrement neutres. Cependant, les résultats de cette étude peuvent être reproduits, et les problèmes non résolus dans le propre dépôt du test vont dans le même sens ; le problème est donc réel, même si son auteur est discrédité. Les implications en sont sévères. Un test de référence présentant un taux d’erreur de six pour cent dans ses résultats ne peut pas distinguer deux systèmes qui diffèrent de moins de six pour cent, et un outil d’évaluation qui valide les deux tiers des mesures peu fiables évalue la confiance, et non la justesse.

Les chiffres fournis par les fabricants ne coïncident pas non plus entre eux. Les deux fabricants de mémoire les plus connus publient des scores pour le même test de référence qui s’opposent, chacun ayant réexécuté le système de l’autre et obtenu un résultat contesté par l’autre, car le résultat dépend fortement de la manière dont chacun a configuré l’intégration. Un chiffre principal qui varie de plusieurs unités en fonction de la configuration n’est qu’un outil de marketing, pas une mesure fiable. Rien de tout cela ne signifie que les systèmes sont mauvais. Cela veut simplement dire qu’un classement ne peut pas les ordonner à votre place, et certainement pas pour votre domaine.

Un contexte long n’est pas de la mémoire, et les tests de référence confondent les deux

Une confusion plus subtile corrompt les comparaisons avant même qu’elles ne commencent. Un contexte long et la mémoire sont deux choses distinctes, pourtant de nombreuses évaluations les traitent comme un seul axe. La recherche d’une aiguille dans une botte de foin, où une phrase est cachée dans un document long et que le modèle doit la trouver, teste l’attention sur une seule entrée fixe. Il s’agit d’un test rapide pratique, sans fondement théorique solide, ne reposant que sur un script largement copié. Un benchmark plus rigoureux, RULER, a montré que de nombreux modèles présentés comme disposant de grandes fenêtres de contexte ont en réalité une portée effective bien plus courte que ce qui est indiqué. Ces deux méthodes mesurent la capacité du modèle, c’est-à-dire la quantité de texte d’une requête qu’il peut réellement utiliser.

La mémoire assure la continuité entre les sessions. Le lundi, l’agent prend quelque chose, la conversation se termine et la fenêtre est effacée, mais d’ici vendredi il devrait encore s’en souvenir. LoCoMo et LongMemEval, les benchmarks de mémoire conversationnelle, mettent à l’épreuve ce cycle de stockage puis de rappel sur de nombreuses sessions, ce qui les classe dans la même famille, quelles que soient leurs faiblesses.

Deux couches à tester

Lorsque les benchmarks publics ne suffisent pas, l’alternative est de créer son propre benchmark, et la première décision de conception concerne le point de division. Il faut le diviser en deux. Une couche est chargée du rappel : le système de mémoire a-t-il restitué les informations correctes ? L’autre couche concerne la réponse : l’agent a-t-il finalement répondu ou agi correctement ? Elles échouent de manière indépendante, et un indicateur d’exactitude globale est calculé en moyenne sur les deux, ce qui masque ce qui a mal fonctionné.

Cette séparation n’est pas nouvelle. Le framework open source RAGAS, décrit dans une étude de 2024, est construit sur ce principe, en distinguant la capacité d’un outil de récupération à trouver un contexte pertinent de celle d’un modèle à utiliser ce contexte de manière fiable. TruLens exprime la même idée sous forme de triade : la pertinence du contexte pour la récupération, le caractère fondé de la réponse par rapport au contexte récupéré, et la pertinence de la réponse pour le fait qu’elle réponde bien à la question. Les noms diffèrent, mais la logique de séparation reste identique.

Les deux couches sont nécessaires, et c’est là que les équipes omettent quelque chose. Un bon récupérateur d’informations peut encore fournir une réponse fausse, car les faits corrects se trouvent dans le contexte mais le modèle les ignore, raisonne de manière erronée ou les mélange avec ce qu’il croyait déjà. C’est pourquoi la pertinence constitue une métrique à part entière. Un mauvais récupérateur peut néanmoins donner une réponse correcte, car le modèle comble le vide à partir de ses connaissances paramétriques, et c’est le cas le plus dangereux. Le score globale affiche « correct », tout en masquant le fait qu’une couche de mémoire n’a rien de utile fourni, une erreur qui se manifestera plus tard face à un fait du domaine que le modèle ne connaissait pas par hasard. Mesurer uniquement la réponse finale ne permet pas de distinguer une mémoire de travail efficace d’une simple supposition chanceuse.

Le récupération d’informations mérite des métriques de classement, et non l’arbitraire d’un LLM

La récupération constitue la couche où l’arithmétique peut effectuer l’évaluation, et l’arithmétique n’a pas d’opinions. Les métriques proviennent de la récupération d’informations classique et datent de plusieurs décennies :

• Recall@k représente la part des faits qui auraient dû être récupérés et qui se trouvent bien parmi les k premiers résultats. Elle est pertinente lorsque le modèle suivant tolère les éléments perturbateurs et que la principale préoccupation est la présence du fait nécessaire.
• Precision@k indique la proportion d’éléments récupérés qui s’avèrent pertinents. Elle est utile lorsque l’espace contextuel est limité et que chaque emplacement gaspillé coûte des tokens ou éloigne le modèle de sa trajectoire souhaitée.
• Mean reciprocal rank récompense le fait de placer en premier le seul fait correct, dans les cas où seul le premier résultat compte.
• Gain cumulé déprécié normalisé convient à une pertinence graduelle, où l’ordre est important car le modèle accorde plus de poids au contexte précédent.
• Taux de succès, c’est-à-dire la présence éventuelle de quelque chose de pertinent, constitue un critère global simpliste.

Choisissez celui qui correspond à la manière dont votre agent consulte sa mémoire.

Presque aucune équipe ne prête attention au point suivant, qui est pourtant peut-être le plus important ici. Des frameworks d’évaluation populaires tels que RAGAS, TruLens et DeepEval intègrent des métriques appelées rappel contextuel et précision contextuelle, et il est naturel de penser qu’il s’agit des métriques de classement mentionnées précédemment. Ce n’est pas le cas. Dans la plupart de ces outils, un juge basé sur un LLM lit les extraits récupérés et les évalue, plutôt que de les comparer à un ensemble étiqueté indiquant quels faits étaient réellement pertinents. Une équipe qui croit mesurer la qualité de la récupération demande donc à un modèle de langage son avis sur la récupération d’un autre modèle, héritant ainsi de tous les biais propres au juge LLM. Des chiffres réels nécessitent un ensemble étiqueté indiquant quels faits stockés sont pertinents pour chaque requête ; une fois cet ensemble disponible, le rappel@k et les autres métriques ne sont plus que des comptages. Créer cet ensemble représente le véritable effort, mais les frameworks permettent de l’éviter. Cela explique pourquoi les chiffres d’extraction honnêtes sont rares, tandis que les tableaux de bord qui semblent rigoureux mais ne le sont pas sont courants.

Quatre vérifications que l’évaluation générique RAG néglige

Si vous traitez la mémoire de l’agent comme s’il s’agissait d’un pipeline RAG classique, vous évaluerez à la fois la qualité de l’extraction et celle de la réponse, puis vous vous arrêterez là. Cela exclut quatre types de défaillances propres à la mémoire elle-même, qui ne surviennent que parce que la mémoire persiste et évolue avec le temps.

Consistance. L’agent a-t-il dit quelque chose qui entre en conflit avec ce qu’il a affirmé précédemment à l’utilisateur, ou avec sa propre déclaration antérieure ? L’évaluation standard RAG ne peut pas détecter cela, car chaque requête est évaluée séparément, mais une mémoire contenant deux faits opposés peut les présenter à des jours différents, ce qui donne l’impression d’incohérence. Une solution possible consiste à utiliser un modèle NLI capable de marquer une déclaration ultérieure comme contradictoire avec une précédente, en analysant à la fois la conversation et les informations renvoyées par le système, ce qui permet de considérer la contradiction comme une métrique à suivre plutôt que comme une plainte de l’utilisateur. Les ensembles de données conçus pour identifier un échange contradictoire formalisent précisément cette idée.

Récency. Lorsqu’un fait change, la mémoire restitue-t-elle la nouvelle valeur ou l’ancienne ? LongMemEval (ICLR 2025) compte le raisonnement temporel et les mises à jour des connaissances parmi les cinq capacités testées, ce qui en fait une dimension reconnue et non un luxe. La conception qui réussit est bitemporale : un fait enregistre le moment où il était valable dans le monde réel ainsi que celui où le système l’a découvert, et une mise à jour invalide la version ancienne en se basant sur une date et une heure, plutôt que de la remplacer directement. Les systèmes de graphes temporels tels que Graphiti et Zep fonctionnent de cette manière. Le test est simple : après une mise à jour, la requête renvoie la nouvelle valeur, et le système peut encore indiquer que la valeur ancienne était vraie auparavant.

Abstention. Lorsqu’un fait n’a jamais été enregistré, l’agent le mentionne-t-il ou invente-t-il quelque chose ? LongMemEval considère l’abstention comme une capacité à part entière, et à juste titre : une mémoire qui invente des informations est pire qu’une mémoire qui admet un manque, car c’est la fabrication convaincante que le client finit par lire. Cette idée existe depuis avant même la notion de mémoire, remontant à un test de compréhension de texte de 2018 comportant des questions délibérément sans réponse. Ici, le test est simple : on demande des informations jamais stockées ; un système correct ne trouve rien et refuse de répondre, tandis qu’un système défectueux comble le silence par des réponses inventées.

Oubli. Pour les données qui devraient s’estomper ou être supprimées, ont-elles vraiment disparu ? Les travaux sur l’« unlearning » des machines fournissent un modèle à cet égard. TOFU, l’un de ces critères d’évaluation, divise les données en un ensemble à oublier et un ensemble à conserver, et vérifie non seulement que le matériel oublié est inaccessible, mais aussi que ses voisins restent intacts. Les tests de mémoire suivent la même logique : après une suppression, l’information concernée ne peut ni être récupérée ni déduite, tandis que les informations apparentées demeurent. Cela n’est pas identique au principe de proximité temporelle. Remplacer une valeur conserve délibérément l’ancienne version dans les fichiers, tandis qu’une véritable suppression, celle exigée par une demande de confidentialité, doit ne laisser aucune trace. Un système qui se contente de rendre les données invalides réussit le test de proximité temporelle mais échoue silencieusement à un audit relatif au droit d’être oublié ; seuls des tests capables de distinguer ces deux cas le détecteront.

Évaluez les réponses avec un juge, mais ne laissez pas cela définir la vérité

Les scores de récupération sont calculés par comptage. Les réponses ne peuvent généralement pas être évaluées de cette manière, car une bonne réponse peut être formulée de multiples façons ; c’est pourquoi la plupart des équipes utilisent un LLM comme juge. Cette méthode fonctionne dans des limites bien définies mais facilement oubliées. L’étude de 2023 qui a introduit l’idée d’utiliser un LLM comme juge a montré qu’un juge performant égalait les évaluateurs humains dans plus de quatre-vingts pour cent des cas, ce qui explique la popularité de cette technique. Elle a également listé les modes de défaillance : le biais de position, où le juge favorise la première réponse qu’il voit ; le biais de longueur, où la complexité syntaxique prime sur le contenu ; et le biais d’autorenforcement, où le juge préfère les réponses écrites dans son propre style. Une étude de suivi de 2024 a précisé ce dernier point de manière préoccupante : un modèle peut reconnaître son propre style d’écriture, et plus il y parvient bien, plus il le préfère. Un autre article de 2023, G-Eval, a montré que la notation de GPT-4 correspond raisonnablement à celle des humains, mais a souligné l’échec le plus important dans ce contexte : les juges ont tendance à privilégier des textes fluides, assurés et bien structurés. C’est précisément le profil d’une réponse fausse mais présentée avec assurance, ce qui permet à une mémoire qui semble correcte mais donne un mauvais résultat de passer inaperçue.

Utilisez le juge, mais restreignez son influence :

• Notez en vous basant sur un critère d’évaluation lié à une réponse correcte connue, plutôt que sur une question ouverte du type « lequel est le meilleur », afin que le juge vérifie des faits et ne se base pas sur son impression.
• Vérifiez avec quelle fréquence il est d’accord avec des échantillons étiquetés par des humains issus de vos propres données, car un juge en désaccord avec vous dans votre domaine d’expertise est un outil décalibré.
• Neutralisez le biais de positionnement, comme l’a fait l’étude originale : inversez l’ordre des candidats et calculez la moyenne des résultats.
• Considérez la mise à niveau vers un modèle de juge comme une migration de l’ensemble d’évaluation et non comme une amélioration automatique. Les scores obtenus avec un nouveau modèle ne sont pas comparables à ceux des anciens, et un remplacement silencieux modifie ces chiffres pour des raisons qui n’ont rien à voir avec le système testé.

Un juge est un outil à calibrer, pas un oracle à suivre aveuglément.

Assemblage du dispositif à partir de vos propres données

Tout fonctionne sur un ensemble de référence : une collection figée et étiquetée de cas provenant de votre propre domaine, où chaque entrée associe une requête aux faits à récupérer ainsi qu’à la réponse attendue. Cela fonctionne comme un ensemble de tests de régression, c’est-à-dire quelque chose qui doit continuer de fonctionner, adapté à des résultats non déterministes. De nombreuses équipes commencent avec quelques centaines de cas sélectionnés manuellement. Cette fourchette constitue une règle de prudence pour les professionnels et non une loi, donc considérez-la comme un point de départ qui peut évoluer.

Construire l’ensemble n’est pas la partie difficile ; le faire rester fiable, si. Un ensemble « doré » figé cesse progressivement de correspondre au trafic réel au fur et à mesure que le produit, le corpus et les utilisateurs évoluent, tandis qu’un ensemble entièrement « vert » basé sur des données obsolètes engendre une confiance fausse, la plus coûteuse qui soit. La solution réside dans une boucle : on prend les échecs survenus en production et on les intègre à l’ensemble « doré » en tant que cas nouvellement étiquetés, on retire ceux qui ne reflètent plus la réalité, et ainsi l’ensemble suit l’évolution du produit plutôt que de n’être qu’un instantané de son passé. Des cas synthétiques peuvent servir à initier la couverture, et plusieurs frameworks en génèrent, mais les cas générés présentent les limites du modèle qui les a créés, ce qui explique pourquoi un ensemble de référence vérifié par des humains reste nécessaire.

La suite s’exécute alors en deux endroits, car le mode hors ligne et le mode en ligne détectent des erreurs différentes. En mode hors ligne, en se basant sur l’ensemble de référence, elle contrôle les déploiements : de manière reproductible et déterministe, elle confirme que rien de ce qui était déjà connu comme fonctionnel n’a été endommagé. En mode en ligne, en analysant des traces réelles échantillonnées, elle repère ce que l’ensemble figé ne pourrait jamais détecter, comme un changement de distribution, des requêtes atypiques à longue queue que personne n’avait prévues, ainsi qu’un ralentissement progressif qui ne se manifeste qu’après des semaines d’accumulation d’état. Un exécution hors ligne avec un statut vert indique que ce qui est connu est intact ; la surveillance en ligne révèle ce qui est inconnu. Considérez le premier cas comme une autorisation de mise en production, et jamais comme une preuve que le système fonctionne correctement.

Le coût et la latence doivent figurer sur le même tableau de suivi

Le coût et la latence sont les éléments que la plupart des évaluations omettent, alors que pour la mémoire, ils sont indispensables. La mémoire se trouve sur le chemin critique de chaque tour, de sorte que sa latence de récupération, mesurée à p95 et non masquée par une moyenne, détermine la vitesse à laquelle l’agent peut répondre. Le nombre de tokens par tour constitue l’argument économique principal : la mémoire existe pour permettre d’utiliser moins de tokens que de copier l’historique complet ; par conséquent, une couche qui consomme plus de tokens qu’elle n’en économise échoue dans son objectif principal, même lorsque la précision reste identique. La croissance de la mémoire représente une régression lente qui ajoute de la latence et des distractions un peu plus chaque semaine, jusqu’à ce que la récupération devienne clairement plus lente, sans que aucun test de précision à un instant donné n’ait signalé de problème. Le coût lié à l’écriture, c’est-à-dire le travail d’extraction et de conciliation, correspond à des calculs réels que les chiffres de précision ne reflètent pas.

Une mémoire doit être conçue pour l’efficacité et la cohérence, et c’est lors de l’évaluation que cela se vérifie. Une plus grande précision obtenue au prix d’une demi-seconde supplémentaire par tour, dont le coût dépasse les économies réalisées, ne fait pas d’une mémoire une meilleure solution ; en revanche, un tableau de scores ne contenant que la colonne de précision le laissera croire. Lorsque la latence et le coût sont indiqués à côté de la qualité, les compromis deviennent visibles plutôt que le fruit du hasard.

À quoi ressemble l’équipement en pratique

En théorie, l’équipement se compose de deux couches, de quatre vérifications de mémoire, d’un juge calibré, d’un ensemble de référence mis à jour à partir de la production, ainsi que du coût indiqué à côté de la précision. Deux schémas illustrent ce que cela signifie en pratique.

Supposons qu’une plateforme de gestion de patrimoine stocke ses données sous forme de graphe de connaissances comprenant un petit nombre de types d’entités et de relations, alimenté par un processus d’extraction en plusieurs étapes qui attribue à chaque fait un score de confiance allant de zéro à un. L’équipe ne l’évaluera pas en demandant à un modèle si les réponses semblent bonnes. Elle testera directement la couche de récupération à l’aide d’un ensemble de documents étiquetés où les entités et relations correctes sont déjà connues, de sorte que le taux de rappel et la précision de l’extraction sont des chiffres concrets et non des impressions subjectives. La fraîcheur des informations fera également l’objet d’un test délibéré : si un document plus récent modifie ce qui a été indiqué dans un document plus ancien, la requête doit renvoyer la valeur mise à jour. La même discipline de notation appliquée au graphe avant que les agents ne s’y fient est également utilisée pour la mémoire des agents.

Supposons maintenant un système d’analyse juridique comprenant une vingtaine d’agents, certains agissant en tant que juges de qualité et d’autres en tant qu’analystes, qui partagent un tableau structuré de scores au lieu d’échanger des transcriptions. La cohérence devient alors une métrique primordiale, car un agent qui contredit un score établi dans l’état partagé représente un défaut mesurable et non simplement une impression subjective. Le coût par tour est affiché sur le même tableau de bord que la qualité, car une couche de routage qui détermine quels agents sont réellement nécessaires pour un document et réduit considérablement le nombre d’appels au modèle ne mérite d’être conservée que si l’évaluation montre que la qualité reste stable tout en diminuant les coûts. Aucun de ces systèmes ne gagne la confiance en surpassant des références externes ; tous deux y parviennent grâce à des mesures basées sur leurs propres données, à travers les différentes couches et les contrôles adaptés à leur travail.

Signes que l’évaluation constitue le goulot d’étranglement

Quelques symptômes indiquent le processus d’évaluation lui-même et non le modèle, le stockage ou le système de récupération :

• Le système de mémoire a été sélectionné à partir d’un classement, et la production continue de ne pas correspondre à son score.
• La précision de la réponse de bout en bout est la seule métrique utilisée, ce qui empêche d’attribuer un échec à une erreur de récupération ou aux erreurs du modèle dans l’interprétation des données reçues.
• Les chiffres relatifs à la récupération proviennent d’une métrique de rappel contextuel d’un framework, et il n’existe aucun ensemble étiqueté, ce qui signifie qu’un LLM évalue la récupération en la considérant comme une mesure fiable.
• L’agent se contredit ou fournit des informations obsolètes, mais le système ne s’en apercevrait jamais, car il teste uniquement des requêtes isolées et ignore la cohérence, la fraîcheur, l’abstention et l’oubli.
• Personne ne sait quel effet les dernières modifications de la mémoire ont eu sur la latence ou l’utilisation des tokens, puisque seule la précision est enregistrée.

Compte tenu de ce schéma, un modèle plus puissant ou un outil de récupération plus intelligent ne pourra pas résoudre la situation, car ce qui ne peut pas être observé ne peut pas être amélioré. La solution réside dans une approche structurée : séparer la récupération des informations de la génération de la réponse, évaluer la récupération à l’aide de métriques de classement sur un ensemble étiqueté, ajouter les quatre vérifications de mémoire, calibrer l’interprétation des résultats plutôt que de se fier aveuglément à elles, mettre à jour l’ensemble de référence avec des données réelles, et indiquer le coût et le temps de réponse en plus de la précision.

Cela clôt également l’argument principal. Une fenêtre de contexte n’est pas une mémoire. Le stockage mis en place à sa place doit être consulté par classement et non par recherche. L’ensemble de données en mémoire devant le modèle doit être géré, et non simplement agrandi, et le mécanisme d’écriture doit consolider les informations plutôt que de les accumuler. Il faut ensuite évaluer l’ensemble sur vos propres données, en prenant en compte la récupération, la réponse ainsi que les quatre vérifications que les benchmarks publics omettent, en additionnant coût et latence à la précision, car un classement ne peut vraiment pas vous fournir ce dont vous avez besoin de savoir. Construisez la mémoire et son évaluation ensemble, et vous saurez, à l’aide de chiffres, si l’agent se souvient. Omettez l’évaluation, et vous vous baserez sur les résultats d’un tiers pour un problème qui n’a jamais été le sien.

Lectures complémentaires

• Optimiser un agent Terraform avec DSPy : construire le vérificateur avant l’optimiseur — Les agents Terraform inventent des schémas. Construisez un vérificateur déterministe, établissez une référence pour l’agent, puis utilisez DSPy et GEPA pour optimiser son fichier de compétences, en obtenant des résultats fiables.
• Forme de l’ontologie vs taille du modèle : quel est le coût du design d’un graphe pour un agent IA — Comment trois formes sans perte d’un graphe de connaissances en assurance ont modifié la précision, le nombre d’appels d’outils, les tokens et les coûts pour des modèles petits et grands sur Azure Cosmos DB.

Pourquoi la mémoire d’un agent de codage ne doit contenir que le delta, et comment le stocker — La mémoire de l’agent ne doit enregistrer que ce que le modèle ne peut pas deviner. Quatre tests pour chaque entrée, trois exigences pour le stockage, et pourquoi le markdown dans git convient.