Évaluation LLM construite à partir de vos propres échecs

Recherchez ceci et vous obtenez une taxonomie. Basé sur des références et sans référence, évaluation du modèle par rapport à l'évaluation du produit, un catalogue de métriques avec des noms comme la fidélité et la pertinence des réponses, et une comparaison du cadre en bas. Les pages sont écrites par les sociétés qui vendent les plateformes d'évaluation, elles sont techniquement correctes et elles partagent toutes une hypothèse qui ne tient pas : que vous savez ce que vous mesurez avant de commencer.

Ce n’est pas le cas, et ce n’est pas une lacune dans votre préparation. Lors d'une intégration réelle, ce qui mérite d'être mesuré n'est pas connu à l'avance, car il est déterminé par ce que votre système particulier fait de mal, et votre système particulier n'a pas encore fonctionné. Partir d'une liste de métriques signifie choisir des mesures avant d'avoir des preuves des échecs importants, et le résultat prévisible est un tableau de bord de chiffres verts situés au-dessus d'une file d'attente d'assistance qui n'est pas d'accord avec eux.

L’alternative consiste à construire l’ensemble d’évaluation à rebours, à partir d’échecs plutôt que de mesures. Son démarrage est plus lent et c'est la seule version qui reste utile au-delà du premier mois.

Le problème du benchmark, énoncé clairement

Un benchmark vous indique les performances d'un modèle sur la distribution des intrants de quelqu'un d'autre. Ce sont des informations véritablement utiles lorsque vous choisissez entre des modèles, une décision que vous prenez une fois et à laquelle vous arrêtez généralement de penser.

Cela ne vous dit presque rien sur le système que vous avez construit. Votre invite n'est pas leur invite, votre corpus de récupération n'est pas leur corpus, vos utilisateurs ne formulent pas les choses comme le faisaient les auteurs de référence, et les échecs qui vous coûteront réellement de l'argent sont ceux spécifiques à cette combinaison. Un modèle qui obtient de bons résultats puis échoue dans la façon dont vos clients écrivent les dates est un système qui est défectueux, et aucun classement public ne pourra jamais le rattraper.

Ainsi, le benchmark répond à la question de sélection du modèle puis s'arrête. Tout ce qui suit vous appartient. La sélection du modèle a ses propres entrées, et si telle est la décision qui vous attend, la comparaison de fenêtre contextuelle et le compteur de jetons sont les deux choses qui valent la peine d'être vérifiées avant un tableau de référence, car les deux sont des propriétés de vos entrées plutôt que du modèle.

D'où viennent les cas

Un ensemble d'évaluation est aussi bon que les entrées qu'il contient, et les bonnes entrées sont déjà dans votre système. Quatre endroits les produisent, et ils les produisent continuellement, ce qui est la propriété qui compte.

Le chemin d'exception. Chaque intégration en a un : la branche qui se déclenche lorsque le modèle renvoie quelque chose que le code n'a pas pu utiliser. Sortie mal formée, un appel d'outil avec des arguments qui ne valident pas, un refus, un timeout, une réponse analysée mais vide. La plupart des équipes les enregistrent et traitent ensuite le journal comme un problème opérationnel, quelque chose à pager et à effacer. Il s'agit de la source de cas d'évaluation la plus riche que vous ayez jamais eue, car chaque entrée est une véritable entrée envoyée par un utilisateur réel, et elle est déjà étiquetée comme un échec par le code lui-même. Rien n'a besoin d'être annoté.

Les corrections. Partout où un humain touche la sortie avant qu'elle ne s'éteigne, la différence entre ce que le modèle a produit et ce qui a été expédié est une paire étiquetée, gratuite. Il s'agit de la seule source dont disposent la plupart des équipes et qu'elle ne récolte jamais, généralement parce que la correction se produit dans un outil différent de celui dans lequel se trouvent les journaux.

Les plaintes. Les tickets d'assistance concernant une mauvaise réponse sont des cas où l'échec a réussi tous les contrôles automatisés que vous avez effectués. Ce sont les plus précieux et les plus difficiles à obtenir, car ils nécessitent que quelqu'un connecte un ticket à une génération spécifique. Un système sans chemin depuis un ticket jusqu’à l’entrée qui l’a provoqué est un système qui ne peut pas apprendre de ses pires échecs, et ce chemin mérite d’être construit avant qu’une métrique ne soit choisie.

Les quasi-accidents. Des sorties qui étaient techniquement bonnes et que vous ne voudriez pas défendre. Ceux-ci nécessitent du jugement et c’est là que l’expert du domaine gagne sa place, car ils sont par définition invisibles à chaque contrôle automatisé.

Commencez par le chemin d’exception. Il est déjà instrumenté, il ne nécessite aucune annotation et il produira plus de cas en quinze jours qu'un brainstorming n'en produit en une journée.

Les trois lignes qui n'apparaissent jamais sur une facture

Il existe un modèle dans la façon dont le travail d'intégration est vendu, et c'est le même modèle décrit dans l'article AI Integration Services : la citation couvre les parties visibles dans une démo et omet les parties qui décident si la chose survit. L'évaluation comporte trois de ces omissions, et ce ne sont pas des extras facultatifs.

Quelqu'un possède la mauvaise réponse. Ce n'est pas l'infrastructure, la réponse. Lorsque le modèle dit quelque chose d'incorrect à un client, il y a une personne désignée dont le travail consiste à le remarquer et à décider quoi faire. Sans ce nom, les échecs s'accumulent sans être examinés, car les lire n'est la tâche de personne. Il s’agit d’une ligne organisationnelle plutôt que technique, c’est exactement pourquoi c’est celle qui est le plus souvent ignorée.

La vérification de la dérive s'exécute selon un calendrier. Le comportement du modèle change sous vos ordres. Les fournisseurs mettent à jour les modèles, vous modifiez une invite, votre corpus de récupération s'agrandit, vos utilisateurs commencent à poser des questions sur une fonctionnalité qui n'existait pas au dernier trimestre. N'importe lequel de ces éléments modifie le comportement sans que rien ne change dans votre référentiel. Une suite qui s'exécute uniquement lorsque quelqu'un s'en souvient est une suite qui est silencieusement obsolète au moment où vous en avez le plus besoin, elle s'exécute donc selon un calendrier et vous alerte lorsqu'elle bouge.

L'ensemble est organisé. Un ensemble d'évaluation qui ne fait que croître devient un mur de cas que personne ne lit, et un autre qui n'est jamais élagué continue de tester les modes de défaillance que vous avez corrigés il y a deux trimestres tout en manquant ceux que vous avez actuellement. La curation est un travail récurrent avec un propriétaire, pas une tâche qui se termine.

Aucun des trois n’est cher. Ces trois éléments font la différence entre une pratique d’évaluation et un dossier de fichiers de test.

Choisir le chèque, après avoir les dossiers

Une fois que les cas existent, la question de la mesure devient beaucoup plus simple, car vous ne choisissez plus une métrique dans l’abstrait. Vous choisissez comment détecter une défaillance spécifique que vous avez déjà constatée, et la plupart des défaillances sont classées en trois types.

Certains sont vérifiables par un programme. A-t-il produit un JSON valide, l'appel de l'outil était-il bien formé, l'identifiant du document cité existait-il, la réponse se trouve-t-elle dans l'ensemble autorisé. Ce sont des affirmations ordinaires, leur mise en œuvre ne coûte rien et elles devraient être épuisées avant d’envisager quelque chose de plus intelligent. Une proportion surprenante de véritables échecs vivent ici.

Certains ont besoin d’un modèle pour les juger, car la propriété est sémantique. La réponse découle-t-elle du passage récupéré, se contredit-elle, répond-elle à la question posée. Un modèle notant un autre modèle est une technique légitime et elle pose un problème évident, à savoir que le juge a ses propres modes de défaillance. La discipline qui le rend fiable consiste à vérifier le juge par rapport aux étiquettes humaines sur un échantillon avant de s'y fier, et à revérifier lorsque le modèle du juge change, exactement comme vous le feriez avec n'importe quel autre instrument de mesure.

Certains ont besoin d'une personne. Ton, exactitude du domaine, si une réponse est défendable auprès d'un régulateur ou d'un client. Ces sommes étant coûteuses, elles sont consacrées aux quasi-accidents et à l'audit du juge plutôt qu'aux affaires qu'un programme peut déjà régler.

L’ordre est le point important. Programmez d'abord, modèlez ensuite, personne troisième, et chaque couche ne gère que ce que la précédente ne pouvait pas gérer.

À quoi ressemble le bien

Une pratique d’évaluation fonctionnelle n’est pas glamour et a une forme reconnaissable. Les cas arrivent continuellement de la production plutôt que d’être rédigés une seule fois. La suite fonctionne à chaque changement rapide et selon un calendrier en plus. Les échecs ont un propriétaire qui les lit. L'ensemble est taillé aussi souvent qu'il est étendu. Personne ne cite un score de référence dans une mise à jour de statut, car tout le monde comprend qu'il décrit un système différent.

La version qui échoue est également reconnaissable. Il a été construit en une semaine à partir d'une liste de mesures, il a immédiatement obtenu de bons résultats et personne ne l'a examiné depuis, car le regarder n'a jamais révélé à personne quelque chose qu'il ne savait pas. Numéros verts au-dessus d'une file d'attente d'assistance qui n'est pas d'accord.

La différence entre les deux ne réside pas dans l'outillage. Il s’agit de savoir si les cas proviennent d’un catalogue ou de vos propres échecs.