Votre IA a besoin d'un enregistreur de vol, et vous le construisez le premier jour.
La poignée de enregistrements qui vous permet d'expliquer toute sortie d'IA des mois plus tard, et de détecter un dérive de qualité avant qu'un client ne le fasse.
Quand un système d'IA atteint la production : les premières questions
La première question qui se pose lorsqu'un système d'intelligence artificielle (IA) est déployé en production n'est pas « comment fonctionne-t-il ? », mais plutôt « pourquoi a-t-il dit cela ? ». Un client conteste une citation, un auditeur demande comment une décision a été prise, ou un membre de votre équipe remarque que les résumés se sont détériorés ce mois-ci sans pouvoir déterminer quand cela a commencé.
À ce moment-là, vous détenez soit le record, soit vous ne le détenez pas, et il est impossible de le reconstruire par la suite. Répéter la même question aujourd'hui ne vous donnera qu'une réponse actuelle basée sur le modèle actuel, le prompt actuel et les données actuelles. Cela n'est pas une preuve.
La journalisation est une décision prise dès le début. Ajoutée plus tard, elle ne couvre que ce qui se passe ensuite.
Les six éléments qui produisent une réponse
Une réponse d'IA est le résultat d'un petit ensemble d'entrées. Enregistrez tous ces éléments à chaque appel, depuis la première requête :
- La requête - un identifiant unique, une horodatage, l'identité de la personne ou du système qui a posé la question, et le texte ou les données exacts soumis.
- Le contexte - tous les documents, enregistrements ou lignes que le système a récupérés et placés devant le modèle, identifiés individuellement, ainsi que leur version.
- Les instructions - le modèle de prompt plus tout assemblé en temps réel, ainsi que la version du modèle de prompt.
- Le modèle - l'identifiant exact du modèle, sans nom de famille, ainsi que les paramètres utilisés : température, limites de jetons, outils qu'il pouvait appeler.
- La sortie - la réponse brute avant tout nettoyage, et la version traitée si elles diffèrent.
- La conséquence - ce qui s'est passé ensuite : affichée à un utilisateur, envoyée par e-mail à un client, utilisée pour approuver une réclamation, et si une personne l'a acceptée, éditée ou rejetée.
En supprimant le contexte et les instructions, vous êtes laissé avec la moitié d'une conversation. Vous pouvez voir ce que le système a répondu, mais vous ne pouvez pas établir pourquoi cette réponse était raisonnable.
Les versions sont la partie que tout le monde omet
Trois choses changent sous un système d'IA sans qu'aucun demandeur n'en fasse la demande. Quelqu'un modifie un prompt un mardi après-midi. Le fournisseur met à jour le modèle derrière le même nom d'API. La base de connaissances est réindexée et le système commence à récupérer différents documents pour la même question.
Chacun de ces changements peut affecter la qualité, et aucun n'apparaît dans les journaux de sortie. Enregistrez un identifiant de version pour le prompt, le modèle et l'index des données sur chaque appel, et la question « qu'est-ce qui a changé entre une bonne semaine et une mauvaise semaine ? » ne prendra que quelques minutes à répondre. Sans ces enregistrements, il faudra une semaine d'essais et d'erreurs, souvent pendant que quelqu'un de senior attend.
Les corrections humaines sont votre meilleur signal
Lorsque quelqu'un édite un brouillon généré par l'IA avant de l'envoyer, il vous a dit exactement ce qui était erroné, dans les termes les plus spécifiques disponibles. Enregistrez la version originale aux côtés de la version éditée.
Faire cela entraîne deux conséquences. Le taux d'édition devient une mesure de qualité que vous pouvez suivre chaque semaine, et il réagit avant les plaintes. Et les corrections s'accumulent en un ensemble d'exemples que vous pouvez utiliser pour améliorer le système, construit à partir de votre propre travail plutôt qu'acheté ou inventé.
La dérive est une comparaison, pas une alarme
Rien ne vous alertera sur la détérioration des sorties. La dégradation est progressive et chaque réponse individuelle semble plausible.
La méthode pratique consiste à conserver un ensemble fixe de demandes réelles - cent est suffisant, choisies parmi le trafic réel et couvrant vos cas les plus délicats - et à les relancer tous les mois. Comparez les nouvelles réponses avec celles stockées. Là où elles diffèrent, une personne lit les deux et dit laquelle est meilleure. Cette méthode ne fonctionne que si vous avez conservé les entrées, ce qui est l'argument entier pour la journalisation.
Accompagnez-la des chiffres dont vous disposez déjà : taux d'édition, taux de rejet, escalade à un humain, part des réponses où le système n'a trouvé aucun document pertinent. Une augmentation dans cette dernière indique souvent que vos données sont obsolètes, et non que votre modèle a un problème.
Décidez de la rétention et de la redaction en premier
Ces journaux contiennent tout ce que vos clients ont tapé, ce qui signifie qu'ils portent les mêmes obligations que toute autre donnée personnelle. Classez les champs comme ils sont écrits, masquez ou tokenisez ce qui ne doit pas être lisible, et stockez les journaux séparément de l'application pour qu'une défaillance dans un domaine n'entraîne pas la perte des enregistrements.
Définissez une rétention délibérément. Pour les décisions ayant des implications contractuelles ou réglementaires, conservez le registre aussi longtemps que l'exposition dure, et faites en sorte que ce magasin soit uniquement en écriture pour empêcher qu'on ne réécrive l'histoire plus tard. Pour le trafic habituel, un stockage plus court est préférable et moins coûteux. Nommez une seule personne responsable de la politique.
Le stockage est la partie bon marché. L'aspect coûteux est d'intégrer toutes ces pratiques dans un système en direct tout en étant déjà invité à expliquer une sortie que vous ne pouvez pas justifier. Nous construisons ces enregistrements dès le départ, car ils sont ce qui transforme un système d'IA en quelque chose dont vous pouvez avoir confiance et que vous pouvez démontrer.