Demandez à un modèle de langage combien il y a de lettres dans le mot « strawberry ». Il y a de fortes chances qu'il se trompe. Il pourrait dire dix. Il pourrait deviner onze. Il aura l'air tout à fait sûr de lui, et il aura pourtant tort. Demandez au même modèle de calculer des intérêts composés sur un prêt, d'additionner deux grands nombres ou de compter les jours ouvrables entre deux dates, et vous obtiendrez souvent une réponse d'apparence plausible, mais avec des chiffres légèrement, voire dangereusement, erronés.
Cela se produit parce que les grands modèles de langage ne raisonnent pas sur les nombres comme les humains. Ils prédisent des tokens. Un token peut être un mot entier, une partie de mot ou un seul chiffre. Quand le modèle voit « strawberry », il ne voit pas huit lettres individuelles alignées les unes après les autres. Il voit une poignée de segments. On ne lui a jamais appris à compter les caractères, seulement à prédire quel segment de texte vient ensuite. La même limitation s'applique à l'arithmétique. Le modèle n'a pas de calculatrice interne. Il n'a pas de logique de retenue. Il n'a aucune compréhension réelle de la valeur de position. Lorsqu'il multiplie 148 par 279, il n'effectue pas une multiplication. Il procède par reconnaissance de formes par rapport à des expressions similaires vues durant son entraînement, en devinant quelle séquence de chiffres devrait suivre. Pour de petites sommes, le motif est suffisamment fort pour fonctionner. Pour tout ce qui exige une réelle précision, la supposition finit par échouer.
Deux tâches, un seul bot
Les méthodes de prompting standard demandent à un seul système d'accomplir deux tâches très différentes à la fois. Premièrement, comprendre la logique du problème. Deuxièmement, exécuter le calcul exact. Le modèle est véritablement impressionnant pour la première tâche. Il peut lire un problème énoncé textuellement, extraire des variables, établir des relations et planifier un chemin de résolution. Mais il doit ensuite servir de sa propre calculatrice. C'est là que la chaîne se brise. Un seul chiffre glissé à l'étape trois infecte toutes les étapes suivantes. La logique elle-même peut être parfaite, et pourtant la réponse finale est erronée parce que le modèle s'est trompé dans ses calculs.
Les modèles de langage assistés par programme, ou PAL (Program-Aided Language Models), résolvent ce problème en divisant le travail. Au lieu de demander une réponse au modèle, vous lui demandez un programme.
Voici comment le flux fonctionne réellement. Vous présentez le problème. Le modèle détermine la logique, définit les variables et structure l'algorithme. Ensuite, au lieu de calculer lui-même le résultat, il écrit un court script, généralement en Python. Ce script est ensuite transmis à un véritable interpréteur de code. L'interpréteur exécute la logique et renvoie le résultat exact et déterministe. Le modèle décrit les mathématiques. Python effectue les calculs.
Le raisonnement exécutable en pratique
Considérez PAL comme un raisonnement exécutable. Si un script peut résoudre un problème, laissez le modèle écrire le script.
Considérons un exemple concret. Vous devez calculer le montant à l'échéance d'un dépôt à terme de 50 000 ₹ à un taux d'intérêt annuel de 8,5 %, avec capitalisation trimestrielle, détenu pendant sept ans. Demandez directement à un modèle de langage, et il pourrait écrire une formule, substituer les valeurs et calculer le résultat via une chaîne de pensée. Regardez de plus près, cependant, et vous pourriez constater qu'il a mal géré la capitalisation trimestrielle en divisant mal le taux, ou qu'il a arrondi une étape intermédiaire et a propagé l'erreur. La réponse semble raisonnable, mais elle est fausse de plusieurs centaines de roupies.
Avec PAL, l'interaction change. Vous demandez au modèle de générer un code Python qui définit principal = 50000, rate = 0.085, time = 7, et n = 4, puis calcule amount = principal * (1 + rate/n) ** (n * time). Le modèle émet le code. Un environnement d'exécution Python l'exécute. Vous obtenez le chiffre précis, jusqu'à la dernière décimale, à chaque fois. Il n'y a pas de supposition dans la multiplication, pas de reste halluciné, pas d'erreur d'arrondi confiante.
Ce même schéma s'applique au calcul de dates. Demandez à un modèle quelle date tombe exactement dans 120 jours ouvrables à partir d'aujourd'hui, en excluant les week-ends. Un modèle uniquement textuel pourrait compter les jours et se tromper un samedi. Une approche PAL demande au modèle d'écrire un script utilisant la logique datetime et calendar, puis laisse l'interpréteur itérer avec précision. La manipulation de données fonctionne de la même manière. Si vous devez analyser un fichier CSV mal formaté, filtrer un JSON imbriqué ou effectuer une transformation statistique rapide, le modèle doit concevoir la logique tandis que l'interpréteur gère l'itération.
Pourquoi cela est réellement important
Le passage des réponses en prose au code exécutable offre trois avantages pratiques.
Déterminisme. Un modèle de langage à qui l'on pose la même question deux fois peut varier sa formulation ou modifier un chiffre. Un interpréteur renvoie le même résultat pour la même entrée à chaque fois. Cette stabilité est cruciale en comptabilité, en logistique, en planification et dans tout calcul d'ingénierie où la cohérence n'est pas une option.
Vérifiabilité. Lorsqu'un modèle vous livre trois paragraphes de raisonnement, vous devez lire chaque phrase pour traquer le chiffre erroné. Lorsqu'il vous livre un script de dix lignes, vous pouvez réviser le code. Vous pouvez vérifier que la formule des intérêts composés est correcte avant même que l'interpréteur ne s'exécute. Vous pouvez inspecter les noms de variables, repérer les erreurs d'un pas et même utiliser le contrôle de version pour la solution. La surface d'exposition aux erreurs cachées diminue de manière spectaculaire.
Fiabilité. Le modèle reste dans son domaine de compétence. Il fait ce pour quoi il a été conçu : raisonner sur la structure, la sémantique et la décomposition de problèmes. La machine fait ce pour quoi elle a été conçue : calculer avec précision. Cette séparation des préoccupations est précisément la manière dont le logiciel fiable est architecturé. La composition l'emporte sur la conception monolithique.
Exécutez-le comme du code non fiable
Une mise en garde s'impose. Le code généré doit être traité comme une entrée non fiable. Le modèle pourrait écrire un script contenant une boucle infinie, une requête réseau inutile ou une opération sur le système de fichiers que vous n'avez pas demandée. Exécutez toujours ces programmes à l'intérieur d'un bac à sable isolé. Utilisez des conteneurs avec des privilèges restreints, des fonctions serverless sans accès réseau, ou des environnements étroitement contrôlés avec un temps CPU limité et sans stockage persistant. La sécurité n'est pas une simple note de bas de page ici. Elle fait partie intégrante de la conception du système.
Là où PAL brille, et là où il s'arrête
PAL fonctionne à merveille pour les mathématiques, les dates et la manipulation de données structurées. Il élimine les erreurs mécaniques qui parasitent le raisonnement purement textuel.
Il ne corrige cependant pas une mauvaise logique. Si le modèle choisit la mauvaise formule,