Quel modèle allons-nous utiliser ? Le jeu d'évaluation d'abord

La question derrière la question

Quand quelqu'un demande quel modèle nous allons utiliser, il demande en général deux choses. Sera-t-il assez bon, et sera-t-il cher. Les deux ont la même réponse, et ce n'est pas un benchmark tiré de la page d'un fournisseur. C'est un ensemble de cas issus de votre propre travail, avec, à côté de chacun, la réponse que votre équipe accepterait.

Les benchmarks publics mesurent ce qu'un modèle fait du problème de quelqu'un d'autre. Vos clients ne posent pas ces questions. Ils demandent vos conditions contractuelles, vos codes produit, vos règles de remboursement, dans votre langue et avec leurs fautes de frappe. Un modèle en tête d'un classement peut échouer là-dessus, et un plus petit peut réussir.

Ce qu'est un jeu d'évaluation

Une liste d'entrées et de sorties attendues. Une entrée est ce que le système recevra : un message client, une facture scannée, un paragraphe d'un rapport. La sortie attendue est ce qu'une personne soigneuse de votre équipe produirait, ou la règle qui décide si une réponse est acceptable. Parfois c'est une valeur exacte. Souvent c'est une courte liste : cite la bonne clause, ne promet pas de date, indique le document source.

Le jeu n'a pas besoin d'être grand pour être utile. Quelques dizaines de cas qui couvrent la vraie diversité de votre travail en disent plus que mille qui se ressemblent. Ce qui compte, c'est qu'il contienne les cas gênants : la demande ambiguë, le document en deux versions, la question qu'il faut refuser.

Qui l'écrit

Votre équipe, avec nous dans la pièce. Les personnes qui répondent à ces questions aujourd'hui savent quelles erreurs sont embarrassantes et lesquelles coûtent cher. Nous apportons la structure et l'outillage. Elles apportent le jugement. Écrire le jeu prend en général deux ou trois séances de travail pendant la phase d'évaluation, et c'est le document le plus précieux que produit le projet, parce que tout ce qui suit est mesuré contre lui.

Il règle aussi les désaccords tôt. Quand deux personnes ne sont pas d'accord sur ce qu'est une bonne réponse, elles s'en aperçoivent en écrivant un cas, pas après la mise en production.

Le modèle devient alors une mesure

Une fois le jeu en place, choisir un modèle cesse d'être une opinion. Nous faisons passer les candidats, hébergés et ouverts, sur les mêmes cas, avec la même recherche documentaire et les mêmes règles autour. Chacun obtient un taux de réussite, un coût par requête et une latence. Le plus petit modèle qui passe est celui que nous recommandons, parce qu'il coûte moins cher à exploiter, répond plus vite et se remplace plus facilement.

Le résultat surprend souvent l'équipe. Un modèle d'une fraction de la taille du plus connu réussit, dès que la recherche lui fournit le bon paragraphe et que les contrôles arrêtent les réponses qu'il ne doit pas donner. Le modèle est une pièce du système, et rarement celle qui décide s'il fonctionne.

Écrit, pour pouvoir changer

Le choix entre dans le document d'évaluation avec les taux de réussite à côté. Six mois plus tard, quand un fournisseur publie un nouveau modèle ou augmente ses prix, le même jeu est relancé et la décision est revue sur des faits. Rien n'a besoin d'être retenu, et personne n'a de préférence à défendre.

C'est aussi pour cela que le jeu reste le vôtre. C'est la seule chose qui vous permet de changer de fournisseur, de changer de studio ou de reprendre le travail en interne sans repartir de zéro.