Tester et comparer équitablement les systèmes de recherche qui donnent une mémoire aux agents d’IA

## N’affirmer que ce que montrent vraiment les résultats des tests Différenciez les affirmations sur l’ensemble du système de celles qui portent sur une fonctionnalité. Affirmer qu’un système de recherche complet est le meilleur exige des preuves couvrant la qualité de recherche, la mémoire à contexte long, l’étalonnage, la fiabilité, le coût et le comportement opérationnel. Aucune fonctionnalité ni aucun test comparatif isolé ne peut l’établir. Lors de l’évaluation d’une fonctionnalité, demandez-vous si elle apporte une valeur réelle aux utilisateurs du système. Ne consacrez pas l’évaluation à prouver qu’un algorithme propriétaire en surpasse un autre lorsque la décision produit dépend des résultats obtenus par les utilisateurs. Avant d’exécuter une expérience, notez l’affirmation, l’unité d’analyse, l’effet attendu, le seuil de décision et les conditions dans lesquelles le résultat ne pourrait pas être généralisé. Rejetez les conclusions dont la portée dépasse la population, la charge de travail, le moteur ou la configuration testés. ## Choisir séparément la base de données et la source qu’elle contient Modélisez l’acheminement des connaissances selon deux axes indépendants : - le corpus ou la base de données qui contrôle le stockage et la politique d’accès ; - la source ou collection située dans ce corpus. Résolvez les deux axes selon une chaîne de priorité explicite, par exemple l’entrée propre à l’appel, l’autorisation authentifiée, le contexte de session, le marqueur du dépôt, la configuration utilisateur, puis la valeur par défaut. Enregistrez les valeurs résolues avec chaque requête afin de diagnostiquer tout mauvais acheminement silencieux. Considérez les appelants distants ou destinés aux agents comme non fiables, sauf si leur fiabilité a été explicitement établie. Appliquez la portée de la source à chaque chemin de lecture au moyen d’une seule fonction auxiliaire partagée ; ne construisez pas manuellement les filtres dans chaque requête. Validez les identifiants avant de les utiliser dans des jointures ou dans la construction de clés et définissez l’unicité sur la clé complète tenant compte de la source. ## Comparer les modes de recherche avec tous leurs réglages ensemble Définissez les modes nommés comme des ensembles cohérents comprenant la politique de cache, le budget en jetons, l’enrichissement des requêtes, la recherche relationnelle, la pondération de l’intention et la limite de résultats. Résolvez la configuration au moyen d’une chaîne déterministe unique, avec les remplacements propres à l’appel prioritaires sur la configuration de déploiement et une solution de repli documentée. Comparez les modes comme des choix complets proposés aux utilisateurs au lieu de sélectionner un seul réglage favorable. Indiquez la valeur active et sa source pour chaque réglage. Appliquez la résolution du mode dans le chemin de recherche partagé le plus bas afin que les requêtes de production et les répétitions d’évaluation suivent le même comportement. Lorsqu’une nouvelle branche de recherche ne s’applique qu’à un type de requête reconnu, rendez-la déterministe et sans effet dans les autres cas. Fournissez un remplacement par requête pour les expériences contrôlées sans modifier la valeur par défaut de l’ensemble du système. ## Estimer le coût selon des niveaux d’usage réels Calculez le coût en aval à partir du volume de requêtes, du nombre de jetons de contexte fournis, du prix d’entrée du modèle, des appels d’enrichissement et du taux de réussite du cache. Présentez au moins des niveaux d’utilisation faible, typique et intensive afin que les lecteurs puissent mettre le résultat à l’échelle sans extrapoler depuis une seule requête. Séparez le coût isolé par requête des dépenses réelles d’une boucle d’agent. La mise en cache des instructions, les réussites du cache de recherche, les variations de préfixe et les appels répétés d’outils peuvent modifier sensiblement le total réel. Indiquez quelles économies sont mesurées, supposées ou exclues. Évaluez le mode de recherche et le modèle en aval comme une paire. Un contexte surdimensionné peut submerger un modèle de faible capacité, tandis qu’un budget trop restrictif peut priver d’informations un modèle coûteux. Préférez les associations naturelles et présentez les incompatibilités comme des modes d’échec distincts au lieu de classer uniquement les coûts. ## Décider avant le test ce qu’on mesure et comment on juge Pour chaque métrique communiquée, publiez une définition en langage simple avec le résultat lisible par machine. Utilisez un glossaire de référence unique pour des termes tels que la précision à un seuil, le gain actualisé, le rang réciproque, le recouvrement, l’étalonnage, la latence et le coût. Avant de collecter les résultats, précisez les jeux de données, la sélection des échantillons, la direction attendue, les métriques principales, les menaces pour la validité et les règles d’exclusion. Pour des comparaisons appariées, utilisez une méthode de rééchantillonnage appariée et corrigez les comparaisons multiples lorsque vous testez plusieurs métriques ou variantes. Conservez à la fois des résumés lisibles par des personnes et des métadonnées structurées. N’ajoutez pas de champs de glossaire improvisés à côté de valeurs individuelles ; joignez un seul bloc de métadonnées cohérent par réponse afin que les outils en aval puissent l’analyser de manière fiable. ## Rendre les tests d’aiguillage des questions faciles à refaire par tous Séparez les cas d’entraînement des cas réservés à l’évaluation. Évaluez avec des critères stricts et avec des critères souples explicitement documentés lorsque des variations de format risquent de masquer un acheminement sémantiquement correct, mais ne modifiez pas les critères après avoir vu les résultats réservés. Pour chaque exécution entre modèles, conservez un reçu qui relie l’identifiant du modèle, l’empreinte du gabarit d’instructions, l’empreinte des cas, la révision du banc d’essai, l’horodatage et la version de notation. Gardez les prédictions brutes afin d’améliorer ou d’auditer la logique de notation sans payer une nouvelle exécution du modèle. Utilisez des ablations pour identifier les signaux essentiels. Retirez une seule clause d’acheminement, couche hiérarchique ou champ de contexte à la fois, puis comparez avec le même ensemble réservé. Une baisse des performances étaye une affirmation causale de conception ; une anecdote avant-après non appariée ne le fait pas. ## Empêcher que les résultats enregistrés (cache) se mélangent entre réglages Incluez dans la clé de cache toutes les entrées qui modifient le comportement : portée de la source, réglages du mode, limite de résultats, état d’enrichissement, branches et profondeur de recherche, fournisseur de vectorisation, colonne ou modèle de vectorisation et tout indicateur de fonctionnalité qui modifie le classement. Versionnez le contrat de la clé de cache. Lorsque la sémantique change, augmentez la version afin que les anciennes lignes deviennent inaccessibles par un échec de cache normal au lieu d’être interprétées avec la nouvelle configuration. Testez l’isolation entre les modes, les sources et les fournisseurs, ainsi qu’entre la recherche relationnelle activée et désactivée. Exécutez des tests de parité sur chaque moteur de stockage pris en charge, car un moteur intégré peut masquer un comportement d’encodage ou de type qui n’apparaît que dans une base de données de production. ## Protéger les données privées et expliquer les correctifs de sécurité sans révéler les points faibles Stockez les enregistrements d’évaluation dans la zone d’audit du projet, jamais dans le corpus privé actif d’un utilisateur. Utilisez des noms et des organisations fictifs dans les cas, exemples, rapports, notes de version et discussions publiques. Remplacez les requêtes qui révèlent des relations par des marqueurs génériques. Décrivez les correctifs de sécurité de manière fonctionnelle dans les documents publics. Expliquez le mécanisme de protection et l’action requise de l’opérateur sans publier une liste préparée d’enregistrements sensibles, la durée d’exposition ni le chemin de sondage le plus simple pour les systèmes non corrigés. Conservez l’analyse détaillée de l’exposition dans des preuves de révision à accès restreint. Avant toute publication, demandez-vous si une personne sans contexte préalable pourrait déduire des relations privées ou viser directement un ancien déploiement ; si c’est le cas, généralisez la formulation. ## Garder les documents de recherche à jour et courts grâce à des vérifications automatiques Utilisez une structure documentaire en couches : - une orientation toujours chargée qui contient l’objectif de recherche, le modèle d’acheminement, l’architecture et les invariants transversaux ; - des documents de référence sur l’état actuel chargés uniquement pour le sous-système concerné ; - un journal des modifications et un historique des versions pour les comportements passés. N’ajoutez pas un récit version par version aux références sur l’état actuel. Mettez à jour l’entrée existante pour refléter la nouvelle réalité et conservez les détails historiques dans le contrôle de versions et le journal des modifications. Appliquez dans l’intégration continue les limites de taille, les marqueurs historiques interdits, l’actualité du glossaire généré et l’actualité de l’ensemble documentaire. Une règle écrite sans protection automatisée n’est pas une contrainte durable. ## Conserver toute la sortie et les réglages de chaque exécution Écrivez la progression dans un canal distinct des résultats de données. Gardez les noms de phase stables, faites de la progression structurée une option explicite et veillez à ce que les opérations longues émettent des signaux d’activité sans corrompre les résultats lisibles par machine. Pour les tests et évaluations, enregistrez le résultat complet dans un fichier avant d’afficher sa fin ou un résumé filtré. Notez le code de sortie de la commande d’origine avant de lancer tout programme d’affichage. Ne faites jamais passer directement un contrôle de qualité par une commande qui tronque le contenu, car la chaîne peut signaler la réussite du programme d’affichage tout en rejetant les détails de l’échec réel. Chaque exécution doit conserver la configuration, le mode résolu, l’identité du jeu de données, les empreintes, les métriques, le coût, les avertissements, l’état de sortie et les horodatages. Un résultat ne permet une décision que lorsqu’une autre personne chargée de la révision peut reconstruire l’exécution et distinguer les faits mesurés des hypothèses.