Pourquoi votre évaluation de recherche AI ​​est probablement erronée (et comment y remédier)

depuis près d’une décennie, et on me demande souvent : « Comment savoir si notre configuration actuelle d’IA est optimisée ? La réponse honnête ? Beaucoup de tests. Des benchmarks clairs vous permettent de mesurer les améliorations, de comparer les fournisseurs et de justifier le retour sur investissement.

La plupart des équipes évaluent la recherche IA en exécutant une poignée de requêtes et en choisissant le système qui « semble » le mieux. Ils passent ensuite six mois à l’intégrer, pour découvrir que la précision est en réalité pire que celle de leur configuration précédente. Voici comment éviter cette erreur de 500 000 $.

Le problème : les tests ad hoc ne reflètent pas le comportement de production, ne sont pas reproductibles et les benchmarks d’entreprise ne sont pas personnalisés en fonction de votre cas d’utilisation. Les benchmarks efficaces sont adaptés à votre domaine, couvrent différents types de requêtes, produisent des résultats cohérents et tiennent compte des désaccords entre les évaluateurs. Après des années de recherche sur l’évaluation de la qualité des recherches, voici le processus qui fonctionne réellement en production.

Une norme d’évaluation de base

Étape 1 : Définissez ce que « bon » signifie pour votre cas d’utilisation

Avant même d’exécuter une seule requête de test, précisez à quoi ressemble une « bonne » réponse. Les traits communs incluent l’exactitude des lignes de base, la fraîcheur des résultats et la pertinence des sources.

Pour un client de services financiers, cela peut être : « Les données numériques doivent être précises à 0,1 % près des sources officielles, citées avec les horodatages de publication. » Pour une société d’outils de développement : « Les exemples de code doivent s’exécuter sans modification dans la version linguistique spécifiée. »

À partir de là, documentez votre seuil pour changer de fournisseur. Au lieu d’une « amélioration arbitraire de 5 à 15 % », associez-la à l’impact commercial : si une amélioration de la précision de 1 % fait gagner à votre équipe d’assistance 40 heures/mois et que le changement coûte 10 000 $ en temps d’ingénierie, vous atteindrez le seuil de rentabilité avec une amélioration de 2,5 % le premier mois.

Étape 2 : Créez votre ensemble de tests en or

Un ensemble d’or est un ensemble organisé de requêtes et de réponses qui met votre organisation sur la même longueur d’onde en matière de qualité. Commencez à rechercher ces requêtes en consultant vos journaux de requêtes de production. Je recommande de remplir votre ensemble d’or avec 80 % de requêtes dédiées aux modèles courants et les 20 % restants aux cas extrêmes. Pour la taille de l’échantillon, visez 100 à 200 requêtes minimum ; cela produit des intervalles de confiance de ±2 à 3 %, suffisamment serrés pour détecter des différences significatives entre les prestataires.

À partir de là, développez une grille de notation pour évaluer l’exactitude de chaque requête. Pour les requêtes factuelles, je définis : « Notez 4 si le résultat contient la réponse exacte avec une citation faisant autorité. Score 3 si correct, mais nécessite une inférence de l’utilisateur. Score 2 s’il est partiellement pertinent. Score 1 s’il est tangentiellement lié. Score 0 s’il n’y a aucun rapport.  » Incluez 5 à 10 exemples de requêtes avec des résultats notés pour chaque catégorie.

Une fois que vous avez établi cette liste, demandez à deux experts du domaine d’étiqueter indépendamment les 10 premiers résultats de chaque requête et de mesurer l’accord avec le Kappa de Cohen. S’il est inférieur à 0,60, il peut y avoir plusieurs problèmes, tels que des critères peu clairs, une formation inadéquate ou des différences de jugement, qui doivent être résolus. Lorsque vous effectuez des révisions, utilisez un journal des modifications pour capturer les nouvelles versions pour chaque grille de notation. Vous souhaiterez conserver des versions distinctes pour chaque test afin de pouvoir les reproduire lors de tests ultérieurs.

Étape 3 : Exécuter des comparaisons contrôlées

Maintenant que vous disposez d’une liste de requêtes de test et d’une rubrique claire pour mesurer l’exactitude, exécutez votre ensemble de requêtes sur tous les fournisseurs en parallèle et collectez les 10 premiers résultats, y compris la position, le titre, l’extrait, l’URL et l’horodatage. Vous devez également enregistrer la latence des requêtes, les codes d’état HTTP, les versions d’API et le nombre de résultats.

Pour les pipelines RAG ou les tests de recherche agentique, transmettez chaque résultat via les mêmes LLM avec des invites de synthèse identiques avec une température définie sur 0 (puisque vous isolez la qualité de la recherche).

La plupart des évaluations échouent car elles n’exécutent chaque requête qu’une seule fois. Les systèmes de recherche sont intrinsèquement stochastiques, de sorte que le caractère aléatoire de l’échantillonnage, la variabilité de l’API et le comportement d’expiration introduisent tous une variance d’un essai à l’autre. Pour mesurer cela correctement, exécutez plusieurs essais par requête (je recommande de commencer par n=8-16 essais pour les tâches de récupération structurées, n≥32 pour les tâches de raisonnement complexes).

Étape 4 : Évaluer avec les juges LLM

Les LLM modernes ont une capacité de raisonnement nettement supérieure à celle des systèmes de recherche. Les moteurs de recherche utilisent de petits reclassements optimisés pour une latence en millisecondes, tandis que les LLM utilisent plus de 100 milliards de paramètres avec quelques secondes pour raisonner par jugement. Cette asymétrie de capacité signifie que les LLM peuvent juger de la qualité des résultats de manière plus approfondie que les systèmes qui les ont produits.

Cependant, cette analyse ne fonctionne que si vous équipez le LLM d’une invite de notation détaillée qui utilise la même rubrique que les évaluateurs humains. Fournissez des exemples de requêtes avec des résultats notés à titre de démonstration et exigez une sortie JSON structurée avec un score de pertinence (0-4) et une brève explication par résultat.

Dans le même temps, exécutez un juge LLM et demandez à deux experts humains d’évaluer un sous-ensemble de validation de 100 requêtes couvrant les requêtes faciles, moyennes et difficiles. Une fois cela fait, calculez l’accord interhumain en utilisant le Kappa de Cohen (cible : κ > 0,70) et la corrélation de Pearson (cible : r > 0,80). J’ai vu Claude Sonnet atteindre un accord de 0,84 avec des évaluateurs experts lorsque la rubrique est bien spécifiée.

Étape 5 : Mesurer la stabilité de l’évaluation avec ICC

La précision à elle seule ne vous dit pas si votre évaluation est digne de confiance. Vous devez également savoir si la variance que vous voyez entre les résultats de recherche reflète de véritables différences dans la difficulté des requêtes, ou simplement du bruit aléatoire dû au comportement incohérent du fournisseur de modèles.

Le coefficient de corrélation intraclasse (ICC) divise la variance en deux catégories : la variance entre requêtes (certaines requêtes sont simplement plus difficiles que d’autres) et la variance intra-requête (résultats incohérents pour la même requête d’une exécution à l’autre).

Voici comment interpréter l’ICC lors de la vérification des fournisseurs de recherche d’IA :

• ICC ≥ 0,75 : Bonne fiabilité. Les réponses des prestataires sont cohérentes.
• ICC = 0,50-0,75 : Fiabilité modérée. Contribution mitigée due à la difficulté des requêtes et à l’incohérence du fournisseur.
• ICC < 0,50 : Mauvaise fiabilité. Les résultats d’une seule analyse ne sont pas fiables.

Prenons l’exemple de deux fournisseurs, tous deux atteignant une précision de 73 % :

Précision	CPI	Interprétation
73%	0,66	Comportement cohérent à travers les essais.
73%	0,30	Imprévisible. La même requête produit des résultats différents.

Sans ICC, vous déploieriez le deuxième fournisseur, pensant obtenir une précision de 73 %, pour ensuite découvrir des problèmes de fiabilité en production.

Dans notre recherche évaluant les prestataires sur Gaïa (tâches de raisonnement) et CADRES (tâches de récupération), nous avons constaté que l’ICC varie considérablement en fonction de la complexité de la tâche, de 0,30 pour un raisonnement complexe avec des modèles moins performants à 0,71 pour une récupération structurée. Souvent, les améliorations de précision sans améliorations ICC reflétaient un échantillonnage chanceux plutôt que de véritables gains de capacités.

À quoi ressemble réellement le succès

Une fois cette validation en place, vous pouvez évaluer les fournisseurs sur l’ensemble de votre ensemble de tests. Les résultats pourraient ressembler à :

• Fournisseur A : précision de 81,2 % ± 2,1 % (IC à 95 % : 79,1-83,3 %), ICC=0,68
• Fournisseur B : précision de 78,9 % ± 2,8 % (IC à 95 % : 76,1-81,7 %), ICC=0,71

Les intervalles ne se chevauchent pas, donc l’avantage en termes de précision du fournisseur A est statistiquement significatif à p<0,05. Cependant, l'ICC plus élevé du fournisseur B signifie qu'il est plus cohérent : même requête, résultats plus prévisibles. En fonction de votre cas d'utilisation, la cohérence peut être plus importante que la différence de précision de 2,3 pp.

• Fournisseur C : précision de 83,1 % ± 4,8 % (IC à 95 % : 78,3-87,9 %), ICC=0,42
• Fournisseur D : précision de 79,8 % ± 4,2 % (IC à 95 % : 75,6-84,0 %), ICC=0,39

Le fournisseur C semble meilleur, mais ces larges intervalles de confiance se chevauchent considérablement. Plus important encore, les deux fournisseurs ont un ICC < 0,50, ce qui indique que la majeure partie de la variance est due au caractère aléatoire d'un essai à l'autre plutôt qu'à la difficulté de l'interrogation. Lorsque vous constatez un écart comme celui-ci, votre méthodologie d'évaluation elle-même doit être déboguée avant que vous puissiez faire confiance à la comparaison.

Ce n’est pas le seul moyen d’évaluer la qualité de la recherche, mais je trouve que c’est l’un des plus efficaces pour équilibrer précision et faisabilité. Ce cadre fournit des résultats reproductibles qui prédisent les performances de production, vous permettant ainsi de comparer les fournisseurs sur un pied d’égalité.

À l’heure actuelle, nous en sommes à une étape où nous nous appuyons sur des démos triées sur le volet, et la plupart des comparaisons de fournisseurs n’ont aucun sens car chacun mesure différemment. Si vous prenez des décisions qui coûtent des millions de dollars concernant l’infrastructure de recherche, vous devez à votre équipe de mesurer correctement.