Rendre les compétences IA déterministes dans les applications de données

Déplacez chaque étape devant être reproductible hors du modèle, vers du code qu'il appelle.

La question que les responsables techniques nous posent le plus souvent : « Il donne une réponse différente à chaque fois. Comment le rendre assez fiable pour le mettre devant un client ? »

La réponse n'est pas une température plus basse. C'est une autre répartition du travail.

La règle : le modèle choisit, le code calcule

Un modèle de langage est bon pour décider quelle opération s'applique à une demande floue et ambiguë. Il est mauvais comme moteur de calcul, et mauvais comme source de vérité pour des chiffres.

Séparez donc le travail :

Le modèle décide : quel rapport, quelle période, quel filtre, quel client désigne cette formulation vague.
Le code calcule : la somme, la marge, le classement, l'arithmétique des dates.

Chaque chiffre qu'un client voit devrait avoir été produit par une fonction que vous pourriez couvrir par un test unitaire, et non généré sous forme de texte. Si vous pouvez désigner un chiffre dans une réponse sans pouvoir nommer la fonction qui l'a produit, ce chiffre est une supposition.

Donnez au modèle des outils, pas des tableaux

Donner un large tableau à un modèle et lui demander un total, c'est l'inviter à faire la somme lui-même. Lui donner un outil revenue_by_period(customer, from, to), non. Des outils étroits, bien nommés, à arguments typés : voilà le mécanisme — ils font du chemin déterministe le chemin le plus facile.

Trois propriétés rendent un outil fiable en pratique :

Des arguments typés et bornés. Validez à la frontière et rejetez une entrée incorrecte avec un message exploitable par le modèle. Un outil qui accepte silencieusement une date mal formée produit une réponse fausse et assurée.
Une forme d'erreur récupérable. Quand une recherche ne trouve rien, renvoyez un résultat d'erreur que le modèle peut lire et à partir duquel il peut réessayer — pas une exception qui interrompt le tour.
Aucun état caché. Les mêmes arguments doivent donner la même réponse. Un outil qui dépend de l'historique de conversation ne peut être ni testé ni jugé fiable.

Figez ce que vous pouvez, mesurez ce que vous ne pouvez pas figer

Une température à zéro réduit la variation sans l'éliminer, et elle n'est pas disponible dans tous les déploiements. Considérez-la comme une petite amélioration, pas comme une garantie.

Ce qui donne réellement confiance, c'est une suite de non-régression : un ensemble fixe de questions aux réponses connues, exécuté à chaque changement du prompt, des outils ou de la version du modèle. Les montées de version du modèle sont la cause la plus fréquente d'une compétence qui « marchait avant ». Sans suite, c'est un client qui vous l'apprend.

Ce que vous acceptez de laisser non déterministe

La formulation variera, et c'est très bien. Figez les faits, pas la prose. Exigez :

les mêmes chiffres,
le même ensemble d'enregistrements,
la même décision ou recommandation.

Acceptez que la phrase qui les entoure soit tournée autrement à chaque fois. Les équipes qui tentent de figer la prose y passent des mois et récoltent de la fragilité en échange.