Analyse approfondie · Environ 7 min de lecture
Le guide de Perplexity relie l’évaluation des agents aux traces et à des juges calibrés
Le guide officiel en six étapes associe échecs réels, données fixes et juges confrontés aux experts : une bonne réponse ne suffit pas à établir la fiabilité.
- Publié ici
- Date de la source
- Source vérifiée
Publié le 22 octobre, le guide de Perplexity porte sur l’organisation des évaluations d’agents. Il n’annonce ni modèle ni nouveau résultat de benchmark. Son exemple d’achat de pièces montre pourquoi un score suppose de comprendre les actions, la répétabilité et le jugement.
Écouter les actualités
Écoutez cet article ou poursuivez la lecture des actualités.
Préparation de la lecture…
Voix de l’appareil
La voix est traitée par votre navigateur ou appareil. AISubHub n’envoie pas le texte à une API audio. Les voix et la lecture écran verrouillé dépendent de l’appareil.
La reprise peut répéter une courte phrase.
En bref
- Une réponse plausible peut masquer des actions interdites ou une réponse divulguée ; résultat et parcours doivent être vérifiés.
- Environ 100 traces constituent un repère d’analyse, pas un seuil obligatoire. pass@k désigne au moins une réussite parmi k essais précisés.
- Noter plusieurs fois la même exécution enregistrée isole la variation du juge ; régression, suivi et A/B ont des rôles distincts.
Que peut masquer une réponse correcte ?
Un assistant de stock peut proposer une pièce apparemment adaptée tout en contournant une règle d’approbation. Dans l’exemple industriel de Perplexity, une pièce autorisée indisponible ou des informations fournisseur périmées exigent une réaction adaptée, pas un substitut sans justification. Le guide propose de définir à la fois le travail réussi et les moyens inacceptables d’y parvenir. Des experts métier doivent vérifier la pertinence de ces critères. Un texte fluide ne prouve pas le respect des autorisations.
L’évaluation porte donc aussi sur les informations récupérées, les appels d’outils et les décisions intermédiaires. Réussite de tâche, justesse des actions et qualité de réponse mesurent des propriétés distinctes ; la fiabilité concerne les répétitions et les cas limites. Temps, tokens et appels participent au coût d’une tâche réussie. Notre analyse : publier une version exige des conditions d’acceptation du processus entier, pas seulement une préférence pour une réponse bien rédigée.
Quels échecs transformer en tests ?
Le guide part de traces réelles : entrées, éléments récupérés, actions et sorties. Un expert relève la première erreur significative de chaque exécution, puis regroupe les observations en modes de défaillance. Un LLM peut suggérer des catégories, mais fréquence et gravité orientent les priorités. Les échecs importants deviennent des cas réutilisables avec entrée, conditions initiales, résultat attendu et critères de notation. On conserve ainsi le problème à réparer au lieu de le remplacer par un exercice synthétique commode.
Environ 100 traces sont un repère pratique, ni un effectif universel ni une garantie statistique. L’examen peut s’arrêter plus tôt à saturation théorique, lorsque les nouvelles traces ne révèlent plus de schémas pertinents. Avant lancement, des exemples synthétiques amorcent le jeu ; les usages réels doivent ensuite l’enrichir. Les benchmarks standardisés peuvent compléter les tests, mais les réussites ou échecs surprenants demandent d’examiner les tâches et leurs réponses attendues.
Comment soumettre deux versions au même problème ?
Le dossier illustré sépare une demande de maintenance des données fixes de stock et de pièces approuvées. maintenance_request_01.json conserve l’entrée et le résultat attendu ; inventory_snapshot.json et approved_parts.json assurent la comparaison. run_evals.py exécute et contrôle le processus ; results conserve sorties, traces et verdicts. Il s’agit d’un exemple d’organisation, pas d’un système de production ni d’un logiciel que nous avons exécuté. Notre analyse : modifier le stock entre les comparaisons change aussi la tâche.
Il faut conserver les récupérations et les actions des outils, pas seulement le texte final. Des entrées identiques pouvant donner des résultats différents, les répétitions dépendent du risque, de la fréquence et de la difficulté de correction. pass@1 décrit la réussite en un essai ; pass@k, au moins une réussite sur k essais spécifiés. Il faut indiquer k. Trouver une réponse correcte parmi plusieurs ne garantit ni une réussite systématique ni que l’agent sache choisir la bonne tentative.
Qui doit juger chaque exigence ?
Pour les conditions exactes, le guide privilégie le code : pièce autorisée, champs valides, arguments corrects ou état final attendu d’une base de données. Ces contrôles définissent une règle claire sans trancher sûrement tout jugement subjectif. Les questions contextuelles, comme la pertinence d’une explication refusant un remplacement, peuvent utiliser un LLM muni d’une grille explicite. Celle-ci doit préciser le comportement acceptable et les éléments justifiant le verdict.
Les experts restent nécessaires pour les décisions spécialisées ou contestées. Plusieurs juges peuvent vérifier différents aspects d’une même exécution ; une plateforme ne décide pas quels échecs importent à l’entreprise. Notre analyse : séparer autorisations et qualité d’explication rend un score combiné plus lisible. L’avis favorable d’un LLM sur le style ne doit pas remplacer discrètement le contrôle exact de la liste approuvée. Le guide ne mesure aucun gain de précision dû à cette répartition.
Comment distinguer l’erreur de l’agent de celle du juge ?
La calibration en cinq étapes rassemble entrées, sorties et traces ; recueille des jugements indépendants d’experts ; exécute le juge LLM ; compare les décisions ; puis examine les désaccords pour réviser la grille avant de tester de nouveaux exemples. Le jugement humain sert ici de référence, sans être déclaré infaillible. Calibrer revient à évaluer l’évaluateur, et non à relancer l’agent soumis au test.
Pour vérifier la constance du juge, il faut noter plusieurs fois exactement la même exécution sauvegardée et les mêmes fichiers, sans relancer l’agent. Sinon les deux variations restent mêlées. Une matrice de confusion permet d’examiner erreurs détectées, erreurs manquées et sorties acceptables signalées à tort. L’examen humain découvre aussi des défaillances inconnues des juges actuels. Le guide renvoie à des études sur les benchmarks ; nous ne les avons ni lues indépendamment en entier ni reproduites.
Quand une correction justifie-t-elle une publication ?
Reproduire l’échec avec l’entrée sauvegardée, modifier précisément le prompt, le modèle ou le processus, puis confirmer la réparation ne suffit pas : il faut aussi exécuter le reste des tests pour déceler les comportements auparavant corrects désormais cassés. Versions initiale et modifiée doivent employer les mêmes cas et critères. Assertions, frameworks et CI/CD automatisent contrôles et seuils, mais ne démontrent pas que les critères choisis couvrent les risques réels.
Après déploiement, des juges calibrés peuvent examiner un échantillon de traces, suivre les catégories de défaillance et être complétés par l’inspection humaine des demandes inhabituelles ou erreurs nouvelles. Un A/B pertinent ajoute des résultats métier, comme résolution ou satisfaction, sans remplacer l’évaluation ni expliquer toutes les causes. Notre analyse : la boucle utile relie un échec observé, un contrôle répétable et une décision de régression. Le guide ne démontre ni nouvelle disponibilité ni fiabilité mesurée indépendamment.
Pourquoi cela compte
Les équipes peuvent conserver échec, preuves et juge pour comparer une correction à l’ensemble du processus, puis l’ajuster au contact des usages réels.
Limites et disponibilité
Il s’agit des conseils méthodologiques de Perplexity et d’un exemple d’approvisionnement. Nous avons lu l’article et son schéma, pas les études externes, ni testé un agent déployé ou des droits de compte ; aucun gain de précision, d’économie ou seuil universel n’a été mesuré.
Sources et preuves
Date de la source: · Source vérifiée:
Articles assistés par IA, vérifiés avec les sources primaires citées. Les affirmations des fournisseurs sont attribuées ; la présence ne vaut pas recommandation.