Habr explique comment faire calculer un LLM sans erreur en lui faisant générer du code Python

Habr publie une analyse pratique : pourquoi les LLM se trompent régulièrement en arithmétique, et comment contourner le problème dans un produit réel. Plutôt que de demander au modèle de calculer lui-même, l'auteur lui attribue un autre rôle : écrire un script Python et confier les calculs à un programme classique.

Pourquoi les LLM se trompent

Le problème ne vient pas d'un chatbot qui se serait « dégradé ». Un transformer prédit le token suivant selon une probabilité ; il n'appelle pas de calculatrice. Lorsqu'il multiplie, ajuste une recette ou calcule des charges, le modèle peut donc produire une réponse convaincante, mais fausse de quelques pourcents, voire de plusieurs dizaines. L'utilisateur y voit une dégradation, alors qu'il s'agit d'une limite fondamentale de l'architecture : un LLM reproduit bien le schéma d'un calcul, mais n'exécute pas l'opération elle-même.

« Le modèle ne calcule pas.

Le modèle programme. Et c'est le programme qui calcule. »

Les tâches les plus risquées sont donc celles où l'erreur ne saute pas aux yeux. Quelqu'un capable de vérifier le résultat en posant l'opération n'a pas besoin d'un LLM. Mais quand on utilise le modèle précisément pour éviter de calculer à la main, un chiffre plausible passe facilement sans vérification. L'article cite l'exemple des charges de logement : le modèle peut se souvenir d'un tarif obsolète, le multiplier « de tête » et présenter une réponse soignée, alors que le calcul sous-jacent est faux.

Comment fonctionne le dispositif

Le dispositif repose sur une séparation des rôles. L'utilisateur envoie sa demande via une messagerie ; le LLM reçoit un prompt système contenant le contexte et les données nécessaires, puis génère du code Python. Ce code s'exécute dans une sandbox Docker isolée, et le service renvoie non seulement un texte détaillé ligne par ligne, mais aussi un fichier Excel prêt à l'emploi. Dans ce scénario, le modèle se charge de comprendre la demande et de structurer le programme, tandis que la précision arithmétique revient entièrement à l'interpréteur Python.

• En entrée : relevés de compteurs, tableau ou devis
• Les tarifs et référentiels sont injectés dans le prompt depuis un fichier de configuration
• Le modèle doit renvoyer du code Python, et non une réponse toute faite
• Le script s'exécute dans un conteneur isolé avec un délai d'expiration
• En sortie, l'utilisateur obtient un calcul textuel et un fichier Excel

L'auteur indique utiliser Qwen et DeepSeek pour ces tâches, plutôt que des modèles haut de gamme coûteux. Le raisonnement est pragmatique : pour générer un script de 20 à 200 lignes, l'écart de qualité de code entre modèles premium et modèles plus abordables reste faible, alors que l'écart de prix est sensible.

Autre point clé : les tarifs et référentiels doivent arriver dans le prompt depuis la configuration, et non depuis la « mémoire » du modèle. Si un taux change, il suffit de mettre à jour une ligne de données, sans toucher au modèle.

Les pièges rencontrés

L'erreur la plus fréquente au début : demander au modèle de trouver lui-même les tarifs. Dans ce mode, il insère avec aplomb des données obsolètes ou étrangères au cas traité, et l'erreur paraît plausible. L'auteur a donc déplacé tous les chiffres sensibles dans la configuration et les met à jour séparément à partir de sources officielles.

Deuxième problème : même après consigne, certains modèles tentent encore de « calculer de tête » et de livrer une réponse finale. La solution est simple : vérifier la présence de code Python et, si nécessaire, relancer la requête avec une formulation stricte.

Des soucis plus techniques sont aussi apparus : le cyrillique s'affichait mal dans Excel sans UTF-8 explicite, le modèle importait des bibliothèques superflues comme pandas, et, sans le stderr complet, il ne pouvait pas corriger ses propres erreurs après un plantage du script. Mais une fois que le service a renvoyé le traceback au modèle, le nombre d'itérations inutiles a été divisé par cinq, selon l'auteur.

La même approche a déjà été appliquée à une tâche plus complexe, l'analyse de devis de travaux : un test a révélé une surfacturation de 54 168 roubles et huit postes facturés plus de 50% au-dessus du prix du marché.

Ce que cela implique

L'approche « le LLM écrit du code, pas la réponse » apparaît comme l'une des façons les plus pragmatiques d'utiliser les modèles là où la précision compte. Pour la comptabilité, les devis, les impôts et tout scénario de calcul, elle neutralise le risque principal : le texte, la structure et l'automatisation restent du ressort du modèle, les chiffres vérifiables de celui d'un programme classique.