Comment évaluer les agents de recherche IA open source

Les agents de recherche IA open source promettent davantage de contrôle qu'un service de réponses fermé, mais la disponibilité du code source n'est que le début d'une évaluation utile. Un dépôt peut exposer son code tout en laissant des questions importantes sans réponse : quelles preuves ont produit un résultat, quelles données ont franchi une frontière réseau, si un autre chercheur peut réexécuter le workflow et quelle quantité de travail opérationnel l'institution doit absorber.

Une évaluation solide commence donc par la pratique de recherche, et non par un décompte de fonctionnalités. L'objectif est de déterminer si un agent rend un véritable workflow plus facile à inspecter, répéter, gouverner et maintenir. AIPOCH Open Science est une étude de cas utile, car il combine gestion de littérature, agents, notebooks, connecteurs scientifiques, fichiers de projet et calcul distant dans une application de bureau local-first. Sa conception illustre à la fois le potentiel d'un espace de travail inspectable et l'écart entre l'activité enregistrée et la science reproductible.

Définir l'unité d'évaluation

N'évaluez pas un agent de recherche uniquement en demandant s'il peut répondre à une question difficile. Définissez d'abord l'unité complète de travail. Elle peut inclure la découverte de publications, l'ajout de fiches sources, la préparation du code, la sélection des données, l'exécution d'un notebook, la soumission d'une tâche de cluster, la collecte des résultats, la production d'une figure et la documentation des révisions. Un rapport fluide est une sortie dans cette chaîne, et non la chaîne elle-même.

Dressez la liste des artefacts et décisions qu'un évaluateur qualifié devrait examiner. Ils comprennent couramment les entrées d'origine, les citations, les scripts générés, l'état du notebook, les journaux d'exécution, les détails de l'environnement, le choix du modèle, les appels externes, les fichiers intermédiaires, les sorties finales et les constats de l'évaluateur. Vérifiez ensuite que le produit préserve les relations entre eux. Un dossier rempli de fichiers est moins utile qu'un enregistrement montrant quelles entrées, quel code et quelle exécution ont produit une version particulière d'un résultat.

La documentation technique d'AIPOCH décrit des projets persistants contenant des conversations, des fichiers, des notebooks Python et R, des enregistrements d'exécution, des aperçus et la provenance des artefacts. La version 0.26.0 relie aussi une bibliothèque de références à une exécution SSH ou Slurm directe sur des ordinateurs distants enregistrés. Cette ampleur n'est pertinente que si les liens survivent aux changements ordinaires de la recherche : prompts révisés, analyses alternatives, tâches interrompues, sources remplacées et sorties mises à jour.

Cartographier la véritable frontière de contrôle

« Local-first » doit être traité comme une question à examiner, et non comme une conclusion complète sur la confidentialité. L'état du projet peut rester sur un ordinateur local tandis que les prompts, le contexte, les requêtes de recherche ou les paramètres de tâche voyagent vers un fournisseur de modèle choisi, une base de données scientifique, un dépôt ou un cluster distant. La frontière de contrôle significative est le chemin complet suivi par l'information.

Pour chaque workflow, schématisez où les données commencent, quel composant les reçoit, quels identifiants sont utilisés, ce qui quitte l'appareil et où les résultats sont stockés. Répétez l'exercice pour les extensions. Une compétence réutilisable peut exécuter du code, tandis qu'un connecteur peut envoyer des paramètres à un service externe. L'open source rend l'inspection possible, mais ne réalise pas cette inspection pour l'utilisateur.

AIPOCH expose le choix du modèle, les connecteurs, les ordinateurs distants et les politiques d'approbation pour des actions telles que les commandes, les modifications de fichiers et les appels réseau. Cela peut aider une institution à aligner l'outil sur ses propres fournisseurs et son infrastructure. Cela transfère aussi du travail à l'institution : quelqu'un doit examiner les configurations, vérifier les points de terminaison, maintenir les identifiants, comprendre le comportement des extensions et décider quelles actions méritent une autorisation persistante.

Incluez les contrôles propres aux plateformes dans l'évaluation. Les notes d'AIPOCH v0.26.0 indiquent que les contrôles réseau des notebooks s'appliquent par défaut sur macOS et Linux, tandis que Windows exige une configuration unique par un administrateur. La même documentation de version précise que ses installateurs Windows ne sont pas signés Authenticode. Aucun détail ne détermine si l'outil convient, mais tous deux peuvent affecter la politique de déploiement et l'effort de support.

Remonter d'un résultat, de l'affirmation jusqu'à la preuve

Un agent de recherche utile doit permettre à un évaluateur de remonter d'une conclusion vers les preuves et les opérations qui la sous-tendent. Sélectionnez un résultat représentatif, tel qu'un tableau issu d'une analyse ou une affirmation issue de plusieurs publications, et essayez de reconstruire sa lignée sans vous appuyer sur la mémoire de l'opérateur d'origine.

AIPOCH fournit un modèle concret pour ce test. Son système d'artefacts peut conserver des versions immuables et des sommes de contrôle, tandis que sa vue de provenance peut associer une sortie aux entrées disponibles, au code, aux enregistrements d'exécution, aux informations d'environnement, au contexte de conversation et aux constats de revue. Sa version antérieure 0.8.0 a également introduit des branches pour des chemins de conversation alternatifs. Ensemble, ces fonctions peuvent rendre les changements visibles plutôt que de remplacer silencieusement un état précédent.

L'évaluation doit néanmoins séparer la conservation des preuves de la validité scientifique. Une somme de contrôle peut montrer qu'un fichier a changé ou non ; elle ne peut pas montrer que la méthode était appropriée. Un journal d'exécution peut montrer quel code a tourné ; il ne peut pas établir que les hypothèses statistiques étaient solides. Un enregistrement de citation peut identifier une publication ; il ne peut pas prouver que l'agent l'a interprétée correctement. L'inspectabilité crée une meilleure surface pour la revue experte, et non une vérité automatisée.

Utilisez plusieurs questions orientées vers l'échec. L'évaluateur peut-il identifier quelle branche a produit l'artefact publié ? Peut-il voir si une source a été remplacée ? Peut-il distinguer le code généré du code exécuté ? Peut-il déterminer quels résultats proviennent d'une tâche distante ? Peut-il préserver la correction d'un évaluateur sans effacer la sortie d'origine ? Des réponses faibles révèlent les lacunes de provenance plus sûrement qu'une démonstration soignée.

Séparer l'auditabilité de la reproductibilité

L'auditabilité demande si le processus peut être examiné. La reproductibilité demande si suffisamment d'état a été capturé pour l'exécuter de nouveau et obtenir un résultat comparable. Un agent peut bien remplir la première norme tout en restant incomplet sur la seconde.

Une revue de reproductibilité doit rechercher des entrées identifiées, des verrous de dépendances, des détails sur les paquets et le système d'exploitation, des états aléatoires, l'ordre d'exécution, des informations sur le modèle et le fournisseur, la configuration distante et les identités des jeux de données externes. Elle doit aussi enregistrer ce qui ne peut pas être figé. Les fournisseurs de modèles peuvent modifier le routage ou l'implémentation, les bases de données scientifiques peuvent être mises à jour et les clusters distants peuvent différer par le matériel ou les bibliothèques. Enregistrer uniquement un nom de modèle ou la transcription d'une conversation n'élimine pas ces variables.

AIPOCH présente explicitement la restauration portable d'environnement et la relecture complète de session comme un travail inachevé. C'est une limite importante, pas une omission mineure. Ses artefacts et sa provenance conservés peuvent soutenir une enquête aujourd'hui, mais ils ne doivent pas être décrits comme la preuve d'une reconstruction déterministe. Une évaluation doit consigner cette distinction dans la décision elle-même afin que les utilisateurs sachent quels workflows exigent encore une gestion externe de l'environnement.

Exécutez une reprise contrôlée avec des données non sensibles. Donnez à une deuxième personne qualifiée le dossier de projet conservé, retirez les connaissances informelles et demandez-lui de reproduire un artefact. Notez chaque dépendance manquante, approbation non documentée, service indisponible, déplacement manuel de fichier et instruction ambiguë. La liste de lacunes obtenue est plus exploitable qu'une affirmation générale selon laquelle un workflow est reproductible.

Lire les benchmarks comme des preuves limitées

Les benchmarks peuvent comparer des systèmes dans des conditions définies, mais ils ne certifient pas la qualité de la recherche dans toutes les disciplines. Avant d'accepter un score, examinez la source des tâches, la séparation publique et privée, le modèle sélectionné, la méthode de jugement, le budget d'exécution, la configuration de référence et la disponibilité des traces. Demandez-vous si une équipe extérieure peut reproduire la configuration et si la métrique rapportée expose des modes de défaillance conséquents.

AIPOCH rapporte un résultat de 79.05 sur la partie publique de BiomniBench-DA avec un modèle particulier et deux juges automatisés. La fiche de données du benchmark décrit 100 tâches d'analyse de données biomédicales dérivées de publications, avec 50 tâches publiques et 50 tâches privées. C'est une preuve utile et limitée sur des trajectoires analytiques à plusieurs étapes. Ce n'est pas une validation pour tous les domaines de recherche, modèles, institutions ou jeux de données non publiés.

Accordez davantage de poids à la réplication indépendante et à l'analyse détaillée des défaillances qu'à une moyenne unique. Des erreurs de citation, d'unité, des choix statistiques inappropriés, des interprétations fabriquées et des échecs de récupération peuvent être masqués par un score agrégé. Un agent inspectable n'a un avantage que lorsque ses enregistrements aident réellement les évaluateurs à localiser et corriger ces défaillances.

Tester l'adéquation opérationnelle, pas seulement la capacité

L'intégration peut réduire les transferts entre outils de référence, interfaces de chat, notebooks, terminaux et navigateurs de fichiers. Elle élargit aussi la surface que les responsables de maintenance doivent prendre en charge. L'empaquetage de bureau, les migrations de base de données, les identifiants, les API de modèles, l'exécution de notebooks, les aperçus scientifiques, les connecteurs et les ordonnanceurs de cluster peuvent chacun échouer indépendamment.

La prise en charge de Slurm par AIPOCH illustre la différence entre intégration et infrastructure fournie. L'application de bureau peut soumettre, surveiller, récupérer, annuler, nettoyer et collecter les résultats de tâches sur un hôte configuré. Elle ne transforme pas un ordinateur portable en environnement de calcul haute performance et ne fournit pas de service GPU cloud intégré. Un laboratoire a toujours besoin de ressources de calcul fonctionnelles, de contrôles d'accès, d'une politique d'ordonnancement et de personnes capables de diagnostiquer les défaillances.

Les autorisations méritent un test d'utilisabilité fondé sur les tâches. Un ticket public d'une première version d'AIPOCH décrivait des demandes d'autorisation répétées pendant le travail d'écriture de code ; le ticket a ensuite été fermé, et des versions ultérieures ont inclus des changements de permissions. Cet historique n'établit pas le comportement actuel, mais il identifie un test productif : les demandes surviennent-elles à des frontières de risque compréhensibles ou deviennent-elles des interruptions routinières que les utilisateurs approuvent automatiquement ?

Mesurez l'effort d'installation, la récupération après l'échec d'une tâche, le comportement lors des mises à niveau, la revue des extensions, la clarté des journaux et le temps nécessaire pour intégrer un deuxième opérateur. Consignez qui possède chaque tâche après l'adoption. Un outil peut offrir un contrôle précieux et rester néanmoins inadapté si l'organisation ne peut pas maintenir le plan de contrôle qui l'entoure.

Utiliser une liste de contrôle d'évaluation par étapes

Commencez par un workflow représentatif et non sensible ainsi qu'une référence établie. Gardez le pilote assez étroit pour que chaque étape puisse être examinée. Utilisez ensuite cette liste de contrôle :

1. Définissez la question de recherche, les artefacts attendus, les preuves acceptables et l'évaluateur expert avant d'exécuter l'agent.
2. Inventoriez chaque composant local et externe, y compris les modèles, connecteurs, compétences, bases de données, dépôts et ordinateurs distants.
3. Consignez quelles données franchissent chaque frontière et vérifiez que les autorisations correspondent aux règles institutionnelles.
4. Remontez une affirmation finale à travers les citations, entrées, code, exécution, fichiers intermédiaires et versions d'artefacts.
5. Modifiez une hypothèse et confirmez que le chemin alternatif reste distinguable de l'original.
6. Remettez le dossier conservé à un deuxième opérateur et documentez chaque obstacle à la réexécution du workflow.
7. Examinez les conditions et les traces du benchmark ; considérez les scores comme une preuve pour la configuration testée uniquement.
8. Introduisez une défaillance d'exécution ou de réseau et évaluez la récupération, les journaux, le nettoyage et l'intégrité des artefacts.
9. Examinez les extensions importées pour leur source, licence, scripts, comportement réseau, version et responsable de maintenance.
10. Comparez la qualité de sortie, le temps de revue, l'effort de configuration, le taux d'échec et la charge de support avec le processus existant.
11. Classez les lacunes non résolues comme risques scientifiques, de sécurité, d'utilisabilité ou opérationnels et attribuez un responsable.
12. N'approuvez que les workflows dont les preuves et contrôles satisfont à la norme exigée ; évitez d'accorder par défaut au produit une confiance plus large.

La décision finale doit être précise. Indiquez quelles tâches l'agent peut accomplir, à quelles données il peut accéder, quelles actions exigent une approbation, quelles preuves doivent accompagner une sortie et quand la revue humaine est obligatoire. Indiquez également ce que l'évaluation n'a pas prouvé.

Les agents de recherche open source sont les plus précieux lorsqu'ils rendent le travail conséquent plus facile à questionner. AIPOCH montre comment des enregistrements de littérature, des notebooks, l'exécution distante, les branches et la provenance des artefacts peuvent être assemblés en un espace de travail inspectable. Il montre aussi pourquoi un dépôt ouvert, un score de benchmark ou un workflow visible ne suffisent pas à eux seuls. La norme durable est de savoir si une autre personne qualifiée peut comprendre le chemin, contester la méthode, réexécuter ce qui peut l'être et exploiter le système dans des frontières institutionnelles claires.