L'écart entre capacité et fiabilité
Voici un schéma qui brûle presque tous ceux qui mettent de l'IA entre les mains de vrais utilisateurs pour la première fois :
Le modèle fait la chose parfaitement dans votre test. Il échoue en production. Vous êtes perplexe, parce que vous l'avez vu fonctionner.
Ce sur quoi vous venez de buter, c'est l'écart entre capacité et fiabilité.
La capacité signifie que le modèle peut accomplir une tâche — il produit une sortie correcte au moins une fois, dans certaines conditions.
La fiabilité signifie que le modèle accomplit la tâche correctement de manière constante — sur des entrées variées, sur des exécutions répétées, sur de légères variations de formulation ou de contexte.
Les démos prouvent la capacité. La production exige la fiabilité. Ce sont des propriétés différentes, et la plupart des guides les confondent.
Pourquoi les démos mentent
Quand vous testez un prompt, vous procédez généralement ainsi :
- Vous l'exécutez sur des entrées que vous avez conçues vous-même
- Vous l'exécutez une poignée de fois
- Vous sélectionnez la sortie qui a l'air bonne
- Vous peaufinez le prompt jusqu'à ce qu'il ait l'air correct
Ce processus optimise pour la capacité. Le prompt fonctionne désormais sur vos exemples. Vous avez vu une sortie correcte. Vous l'expédiez.
Le problème, c'est que les entrées des utilisateurs en production ne sont pas vos exemples. Elles sont plus désordonnées, plus variées, formulées de façons que vous n'avez pas anticipées. Le modèle n'a jamais été testé dessus. Vous n'avez aucune idée de ses performances sur elles.
Une seule bonne sortie n'est pas une estimation de performance. C'est une anecdote.
La variance est la variable cachée
Les LLM sont stochastiques. Exécutez le même prompt deux fois et vous obtenez souvent des sorties différentes. Cette variance est normale et généralement sans gravité. Mais elle implique que la question pertinente n'est pas « est-ce que ça a marché ? » — c'est « quelle fraction du temps est-ce que ça marche ? »
Une tâche où le modèle réussit 95 % du temps a l'air formidable en démo et se casse chez environ un utilisateur sur vingt. Une tâche où il réussit 60 % du temps a l'air correcte quand c'est vous qui l'exécutez. Ce sont des situations très différentes, et vous ne pouvez pas les distinguer sans mesurer.
Le spectre capacité-fiabilité en pratique
| Dimension | Capable mais peu fiable | Fiable |
|---|---|---|
| Entrées testées | Exemples conçus par l'auteur | Entrées diverses, issues de vrais utilisateurs |
| Taille d'échantillon | Quelques exécutions | Exécutions répétées sur de nombreux exemples |
| Visibilité du mode de défaillance | Les échecs sont rares en test, fréquents en production | Les échecs sont mesurés et compris |
| Comment vous découvrez que ça a cassé | Plaintes des utilisateurs | Votre suite d'évals |
| Comment vous l'améliorez | Tâtonner et tester des prompts | Suivre le taux de réussite, déboguer les échecs systématiquement |
| Confiance au déploiement | Au feeling | Fondée sur des preuves |
Les évals sont le vrai rempart
De meilleurs prompts peuvent augmenter la capacité. Seules les évals peuvent vous dire si vous avez augmenté la fiabilité.
Une éval est un test structuré : un ensemble d'entrées, des sorties attendues ou des critères d'évaluation, et un moyen de mesurer le taux de réussite. Vous exécutez le modèle sur les entrées, vous notez les sorties, et vous obtenez un chiffre. Puis vous changez quelque chose — le prompt, le modèle, la température — et vous le réexécutez. Vous avez maintenant un signal.
Ce n'est pas glamour. C'est la partie du travail produit en IA que la plupart des tutoriels sautent entièrement. Mais c'est la seule façon de répondre à la question qui compte vraiment quand vous expédiez : « À quelle fréquence cela fonctionne-t-il sur des entrées que je n'ai pas vues ? »
Une manière simple de commencer
Vous n'avez pas besoin d'infrastructure pour démarrer. Voici une boucle d'éval minimale viable :
-
Constituez un jeu de référence. Rassemblez 20 à 50 entrées réelles ou réalistes. Pour chacune, écrivez à quoi ressemble une sortie correcte (ou les critères pour la juger). Ce sont vos exemples de référence.
-
Exécutez-la N fois. Exécutez votre prompt sur chaque exemple plusieurs fois. La variance entre les exécutions vous renseigne sur la stabilité du prompt ; la variance entre les exemples vous renseigne sur la couverture.
-
Suivez le taux de réussite. Pour chaque paire (entrée, exécution), notez réussite ou échec. Calculez le taux global. Ce chiffre est le début de votre image de fiabilité.
-
Faites-en un test de non-régression. Chaque fois que vous changez le prompt, réexécutez l'éval. Si le taux de réussite baisse, vous avez cassé quelque chose. S'il monte, vous avez réalisé une vraie amélioration.
C'est tout. Un tableur suffit. La discipline compte plus que l'outillage.
Pourquoi c'est un problème d'ingénierie, pas un problème de prompting
L'instinct, quand un modèle échoue, est de réécrire le prompt. Parfois c'est juste. Mais souvent, c'est une manière d'optimiser pour le cas d'échec que vous avez vu, au prix d'une régression sur des cas que vous n'avez pas vérifiés.
L'ingénierie de la fiabilité pour l'IA ressemble à ceci :
- Définir ce que « correct » signifie avant d'exécuter quoi que ce soit
- Mesurer par rapport à une distribution d'entrées représentative
- Suivre les changements dans le temps avec une méthodologie cohérente
- Distinguer « ce modèle ne peut pas accomplir cette tâche » de « cette tâche est mal spécifiée »
L'ingénierie de prompt est un outil au sein de ce processus. Elle n'en est pas un substitut.
Le cadrage honnête
La plupart des capacités de l'IA sont réelles. Les modèles peuvent véritablement faire des choses remarquables. L'écart entre capacité et fiabilité n'est pas un argument selon lequel les capacités seraient fictives — c'est un argument selon lequel savoir qu'elles existent ne suffit pas.
Si vous avez besoin qu'une tâche fonctionne 95 % du temps, vous avez besoin d'une preuve qu'elle fonctionne 95 % du temps. Cette preuve vient de l'exécution de tests structurés, pas de la confiance dans la démo.
Les ingénieurs qui construisent des produits d'IA durables ne sont pas nécessairement ceux qui écrivent les meilleurs prompts. Ce sont ceux qui savent ce que « ça marche » signifie avant d'expédier, et qui disposent d'une mesure leur disant si c'est vrai.