Comparez les modèles d'IA en fonction des invites dont votre produit a réellement besoin

Transformer une fonctionnalité en cas testables

Commencez par le résultat dont votre utilisateur a besoin, et non par un classement de modèle. Si la fonctionnalité extrait les éléments d'action, le succès signifie préserver le bon responsable, la bonne tâche et le bon délai tout en laissant les champs inconnus inconnus. Un résumé élégant qui invente un délai devrait échouer dans ce cas.

À titre d'ensemble de départ illustratif, préparez 12 exemples autorisés : 4 entrées ordinaires, 4 entrées ambiguës et 4 cas extrêmes. Ces chiffres constituent un exercice gérable et non une taille d’échantillon statistiquement validée. Supprimez les informations personnelles et confidentielles que vous n’êtes pas autorisé à partager. Conservez un résultat attendu ou une règle d'acceptation explicite à côté de chaque cas.

Exécutez une comparaison que vous pouvez interpréter

Le guide d'évaluation d'Anthropic distingue une tâche des essais répétés de cette tâche, car les résultats peuvent varier. Cet article applique cette distinction fondamentale à un exercice de sélection manuelle. Quelques réponses claires ne peuvent pas établir un taux d'échec de production.

Évitez de donner une invite corrigée à un candidat après qu'un autre ait déjà échoué. Si l'invite doit être améliorée, créez une nouvelle version et réexécutez chaque candidat dessus. Sinon, vous comparez des instructions ainsi que des modèles.

1. Choisissez explicitement les agents candidats dans le catalogue actuel. N'utilisez pas Auto lorsque vous avez besoin de savoir quel candidat a répondu.
2. Gardez le brief, le matériel source et le format demandé identiques. Utilisez Ask separately pour obtenir les premières réponses et conservez leurs étiquettes.
3. Enregistrez la date, le nom de l'agent affiché, la version de l'invite et tous les paramètres visibles. Notez les réponses manquantes séparément des réponses incorrectes.
4. Examinez chaque résultat par rapport aux règles avant de comparer la qualité de la prose. Répétez les cas importants ou ambigus et conservez chaque tentative, y compris les échecs.

• Anthropic : tâches, essais et conception de l'évaluation↗

Exemple : éléments d'action d'une note de réunion

Entrée fictive : "Mira enverra le brouillon mardi. L'équipe a encore besoin d'un responsable pour la révision des prix." Le résultat souhaité contient une tâche affectée et une tâche non affectée. Il n'attribue pas les deux à Mira et n'invente pas de date pour la révision des prix.

L'artefact utile est une fiche de cas, pas une capture d'écran de la plus belle réponse. Joignez le texte exact renvoyé à chaque ligne afin qu'un coéquipier puisse contester votre score. Séparez l'échec de formatage de l'échec factuel : une disposition de tableau réparable et un engagement inventé ont des conséquences différentes.

Une invite pour la première sélection

Conservez les instructions d'évaluation dans une liste de contrôle distincte que vous appliquerez à la réponse. Vous pouvez demander à un autre agent d'identifier d'éventuelles erreurs, mais son verdict est un autre résultat à inspecter. Le Consensus peut aider à résumer les compromis observés après la première comparaison ; fournissez explicitement les résultats étiquetés et vos scores.

Extrayez les éléments d’action de la note de réunion fournie : [note autorisée]. Renvoyez un tableau avec la tâche, le responsable, la date limite et un extrait à l'appui. Utilisez uniquement le texte fourni. Écrivez inconnu pour un responsable ou une date limite non précisée. Ne transformez pas une suggestion en un engagement convenu. Conservez les questions non résolues séparément. ID d'entrée : [ID de cas].

Utiliser la liste restreinte pour le prochain test

Résumez les dossiers traités par chaque candidat, ses échecs critiques et les questions encore sans réponse. Retenez un candidat uniquement si son comportement correspond aux exigences minimales de la fonctionnalité. Si aucun n'est qualifié, limitez la fonctionnalité ou améliorez le contexte fourni avant de sélectionner un gagnant.

Un essai d'intégration doit vérifier séparément le point de terminaison réel du modèle, l'accès aux outils, les instructions système, la latence, le coût d'utilisation et la gestion des échecs. Les crédits de Colay ne constituent pas un devis pour cette charge de travail API. Commencez dans Colay avec un cas réel et anonymisé que vous pouvez noter vous-même, puis développez-le uniquement lorsque la comparaison modifie votre liste restreinte.

Questions, réponses