Construire de l’IA dans une entreprise régulée

Presque tous les gains rapides se situent dans les deux premiers. Trouver les trois clauses d'un contrat de deux cents pages qui portent sur une question, rédiger la première version d'une procédure à partir des règles qui la gouvernent, résumer un dossier dans la structure dont l'analyste a besoin : tout cela comprime le travail sans déplacer la décision.

Passer au troisième mode est un autre projet. Il exige que la sortie soit contrainte à un ensemble fermé, que le raisonnement soit reconstituable, que les modes d'erreur soient mesurés sur une population réelle, et qu'un chemin défini permette à la personne concernée de contester le résultat.

En environnement régulé, une réponse sans source est inutilisable, aussi bonne soit-elle, parce que personne ne peut la vérifier et personne ne peut en répondre. La recherche documentaire compte moins pour l'exactitude que pour l'attribution : elle transforme une affirmation en une assertion référencée.

Cela change ce qu'il faut optimiser. Un système qui répond à huit questions sur dix avec une citation exacte et décline les deux autres est plus utile qu'un système qui répond aux dix avec aisance et sans références, parce que le second transfère le coût de vérification au lecteur sans le lui dire.

Concevez délibérément le chemin du refus. « Je n'ai pas trouvé cela dans le corpus » est une réponse correcte et précieuse, et les modèles ne la produiront pas si le système ne la rend pas facile et si l'évaluation ne la récompense pas.

Les benchmarks publics ne disent rien de la performance sur vos contrats, vos alertes, vos clients et votre vocabulaire. La seule évaluation qui fonde une décision de mise en production est bâtie sur un ensemble de vos propres cas aux réponses connues, constitué par les gens qui font le travail aujourd'hui.

Deux cents cas bien choisis valent mieux que vingt mille cas ramassés. Incluez les cas difficiles et les cas ambigus, parce que c'est là que le modèle échouera d'une façon qui compte. Gardez le jeu versionné et rejouez-le à chaque changement de prompt, de modèle, de corpus ou de découpage, parce que ces quatre-là déplacent la performance et qu'un seul est habituellement remarqué.

Pour toute sortie qui influence un processus régulé, conservez les entrées, le contexte récupéré, le modèle et sa version, les paramètres, la sortie, et la décision humaine. Rien de tout cela n'est de l'observabilité exotique. C'est l'exigence de preuve ordinaire applicable à tout contrôle, appliquée à un composant qui se trouve être probabiliste.

Les versions de modèles changent sous vos pieds quand vous utilisez un service hébergé. Épinglez ce que vous pouvez, enregistrez ce que vous ne pouvez pas, et traitez un changement de comportement non annoncé comme un incident plutôt que comme la météo.

Où la donnée a le droit d'aller, qui la traite, sur quelle base légale, sous quelles conditions contractuelles, et si elle peut servir à améliorer le modèle d'un tiers. Ces questions décident de l'architecture plus souvent que la latence ou le coût, et elles se répondent tôt.

L'habitude qui va avec vaut d'être installée : minimiser ce qui sort. La plupart des travaux documentaires n'ont pas besoin de documents entiers dans un prompt. Une recherche qui envoie trois paragraphes pertinents au lieu de quarante pages est meilleure sur le coût, meilleure sur l'exactitude, et meilleure sur toutes les questions de protection des données qui suivront.

L'exactitude tue rarement ces projets. L'outil se place à côté du flux de travail au lieu d'être dedans, si bien que l'utiliser devient une étape supplémentaire qu'une personne pressée saute. Juste derrière : personne ne s'est mis d'accord sur qui possède la sortie quand elle se révèle fausse.

Les deux se règlent avant la première ligne de code de modèle. Mettez l'assistance là où le travail se fait déjà, et écrivez qui répond du résultat. Les questions techniques deviennent alors la partie facile.