GPT-4 : pourquoi vos premiers essais échouent en production
ProductionGPT-4ArchitectureTerrain2023-04-188 min
Un prototype convainc parce qu'on choisit ses exemples. La production, elle, choisit les siens. Les quatre écarts qui font tomber les premiers essais.
La démonstration choisit ses exemples
Un prototype d'IA générative réussit parce que celui qui le construit choisit les documents sur lesquels il le montre. Ce n'est pas de la malhonnêteté, c'est le fonctionnement normal d'une démonstration : on illustre une capacité.
La production ne choisit pas. Elle apporte le contrat scanné de travers, la note de 2011 qui contredit la procédure actuelle, le tableau dont trois colonnes sont vides. Et le système, qui répondait bien, se met à répondre avec la même assurance sur des bases fausses.
Le premier écart est toujours celui des données
Sur les projets que j'ai repris après un premier échec, la cause première était presque toujours la même : les données de démonstration ne ressemblaient pas aux données réelles.
Non pas parce qu'elles étaient meilleures en qualité, souvent elles l'étaient, mais parce qu'elles étaient homogènes. Un corpus réel est hétérogène par nature : plusieurs formats, plusieurs époques, plusieurs conventions de nommage, plusieurs niveaux de mise à jour. C'est cette hétérogénéité qui casse les systèmes, pas le volume.
Ce que je regarde avant d'écrire la moindre ligne
- L'âge du document le plus ancien qui sera indexé, et s'il fait encore autorité.
- Le nombre de formats réellement présents, y compris les images de texte scannées.
- Qui met à jour, à quelle fréquence, et ce qui se passe quand personne ne le fait.
- Les droits d'accès : si un document est réservé à trois personnes, la réponse qui le cite doit l'être aussi.
- Le coût d'une erreur, exprimé par le métier et non par la technique.
Le deuxième écart : personne n'a défini le succès
Je demande systématiquement, avant de commencer : à quoi ressemble une bonne réponse, et qui en juge.
Si la réponse est « on verra bien », le projet n'a pas de critère d'arrêt. Il ira jusqu'à ce que l'enthousiasme retombe, ce qui arrive vers la douzième semaine.
Un critère utilisable ressemble plutôt à ceci : sur un jeu de trente dossiers réels, un juriste senior valide la réponse sans correction dans au moins vingt cas, et les dix autres sont corrigibles en moins de deux minutes. Ce n'est pas élégant, mais c'est mesurable, et surtout, c'est vérifiable à chaque changement de modèle.
La phrase qui devrait alerter
« On affinera les prompts après. » L'ajustement de prompt corrige une formulation, pas une architecture. Si le système ne retrouve pas le bon document, aucun prompt ne le sauvera, il rendra simplement une erreur mieux écrite.
Ce que je fais différemment depuis
Je ne construis plus de démonstration. Je construis directement sur un échantillon de production, réduit mais non filtré : cinquante dossiers pris au hasard, avec leurs défauts.
Le résultat est moins impressionnant en réunion. Il est infiniment plus utile, parce qu'il montre dès la deuxième semaine ce qui va poser problème au sixième mois. Et il rend la conversation possible avec les équipes, qui reconnaissent leurs dossiers plutôt qu'un exemple de brochure.
La suite logique de ce constat, c'est le choix d'architecture : pourquoi le RAG reste la seule architecture qui tienne.
Le quatrième écart, apparu plus tard
Aux trois écarts habituels s'en ajoute un quatrième, découvert seulement en exploitation : le corpus vieillit. Il ne se manifeste pas au démarrage, ce qui le rend particulièrement traître.
Un système indexé une fois répond sur des documents périmés six mois plus tard, avec assurance et sans aucun signal d'erreur. Aucun utilisateur ne le signale, parce que la réponse est cohérente et sourcée.
C'est la première des quatre charges récurrentes décrites dans ce qui occupe l'équipe la deuxième année, et celle qui explique le plus d'abandons silencieux.
Ce qu'il faut construire avant la première réponse correcte
Le jeu de tests doit exister avant que le système ne fonctionne, pas après. C'est contre-intuitif et c'est ce qui distingue les projets qui avancent.
Construit avant, il définit ce que « bon » veut dire, ce qui règle d'emblée le deuxième écart, personne n'a défini le succès. Construit après, il entérine ce que le système fait déjà, ce qui n'a plus aucune valeur d'arbitrage.
Sa constitution prend une journée et la méthode est décrite dans construire un jeu de tests en une journée. C'est le premier livrable que je demande, avant toute ligne de code.
Questions fréquentes
- Pourquoi une démonstration réussie ne prédit-elle rien ?
Parce qu'elle choisit ses exemples : des documents propres, des questions bien formulées. La production apporte les documents mal numérisés et les questions incomplètes, qui sont la majorité des cas réels.
- Quel est l'écart le plus fréquent ?
Celui des données. Le prototype tourne sur un échantillon choisi ; la production tourne sur le corpus réel, avec ses versions multiples, ses documents périmés et ses formats hétérogènes.
- Quand faut-il construire le jeu de tests ?
Avant que le système ne fonctionne. Construit après, il entérine ce que le système fait déjà et perd toute valeur d'arbitrage ; construit avant, il définit ce que « bon » veut dire.
- Quel écart n'apparaît qu'en exploitation ?
Le vieillissement du corpus. Un index constitué une fois répond sur des documents périmés six mois plus tard, sans aucun signal, et personne ne le signale car la réponse reste cohérente.
L'ordre dans lequel traiter les quatre écarts
Le corpus d'abord, la définition du succès ensuite, l'intégration en troisième, le coût en dernier : cet ordre évite de corriger un symptôme dont la cause est ailleurs. Il est rarement suivi.
Le réflexe habituel consiste à ouvrir le prompt, parce qu'il est visible et modifiable. C'est la troisième chose à regarder, jamais la première, et le détour coûte des semaines.
La vérification qui tranche prend dix minutes : sur cinq mauvaises réponses réelles, l'information correcte figurait-elle dans les extraits fournis au modèle ? Si elle n'y était pas, aucun travail sur le prompt ne changera quoi que ce soit.
Cette méthode de diagnostic est développée dans reprendre un système d'IA construit par quelqu'un d'autre, et elle s'applique aussi bien à un premier essai qu'à un système hérité.