Habr a Expliqué Comment Forcer les LLMs à Calculer sans Erreurs par la Génération de Code Python

Habr a publié une analyse pratique de la raison pour laquelle les LLM font régulièrement des erreurs en arithmétique et comment contourner cela dans un produit réel. Au lieu de demander au modèle de calculer seul, l'auteur suggère de lui donner un rôle différent : écrire un script Python et confier les calculs à un programme ordinaire.

Pourquoi les LLM Font des Erreurs

Le problème n'est pas qu'un chatbot spécifique "s'est cassé". Un transformateur prédit le prochain token par probabilité plutôt que d'invoquer une calculatrice. Donc, lors de la multiplication, du recalcul d'une recette ou du calcul des factures de services, le modèle peut donner une réponse qui semble convaincante, mais qui diffère de la correcte de plusieurs pour cent ou même de dizaines. Pour un utilisateur, cela semble être une dégradation, bien qu'en réalité il s'agisse d'une limitation fondamentale de l'architecture : les LLM reproduisent bien le schéma de calcul, mais n'effectuent pas l'opération elle-même.

"Le modèle ne calcule pas.

Le modèle programme. Et le programme calcule."

C'est pourquoi les tâches où l'erreur n'est pas immédiatement évidente sont particulièrement dangereuses. Si une personne peut déjà vérifier le résultat manuellement, elle n'a pas besoin d'un LLM. Mais quand le modèle est utilisé précisément pour éviter le calcul manuel, un chiffre plausible passe facilement sans vérification. L'article donne un exemple avec les factures de services : le modèle peut se souvenir d'un tarif obsolète, le multiplier « mentalement » et formuler la réponse élégamment, bien que le calcul interne soit incorrect.

Comment Fonctionne le Schéma

Le schéma fonctionnel est construit autour de la division des rôles. L'utilisateur envoie une tâche à un messager, le LLM reçoit une invite système avec le contexte et les données nécessaires, puis génère du code Python. Ce code s'exécute dans un bac à sable Docker isolé, et le service retourne non seulement du texte formaté, mais aussi un fichier Excel prêt. Dans un tel scénario, le modèle gère la compréhension de la demande et la structure du programme, tandis que la précision arithmétique incombe entièrement à l'interpréteur Python.

• L'entrée peut être des lectures de compteurs, un tableau ou un devis
• Les tarifs et les répertoires sont fournis à l'invite à partir d'un fichier de configuration
• Le modèle doit retourner du code Python, pas une réponse prête
• Le script s'exécute dans un conteneur isolé avec un délai d'expiration
• L'utilisateur reçoit un calcul textuel et un fichier Excel

L'auteur écrit que pour ces tâches, il utilise Qwen et DeepSeek plutôt que des modèles premium coûteux. La logique est pragmatique : si vous avez besoin de générer un script de 20 à 200 lignes, la différence de qualité du code entre les modèles premium et plus accessibles est faible, mais la différence de prix est notable. Un accent particulier : les tarifs et répertoires doivent provenir de l'invite à partir d'une configuration, non de la "mémoire" du modèle. Si un tarif change, il suffit de mettre à jour une ligne de données sans toucher au modèle.

Où Sont Apparus les Problèmes

L'erreur la plus courante au stade initial était de demander au modèle de trouver lui-même les tarifs. Dans ce mode, il substitue confiant aux données obsolètes ou extérieures, et l'erreur semble plausible. C'est pourquoi l'auteur a déplacé tous les chiffres sensibles vers un fichier de configuration et les met à jour à partir de sources officielles séparément.

Un deuxième problème : certains modèles tentent toujours de "calculer mentalement" et de donner une réponse prête même après les instructions. La solution est simple : valider la présence de code Python et, si nécessaire, envoyer une demande de suivi avec une formulation stricte. En pratique, des problèmes plus techniques ont émergé : le cyrillique dans Excel s'cassait sans UTF-8 explicite, le modèle tirait des bibliothèques inutiles comme pandas, et sans stderr complet, il ne pouvait pas corriger ses propres erreurs après l'échec du script.

Mais quand le service a commencé à retourner traceback au modèle, le nombre d'itérations inutiles, selon l'auteur, a diminué de cinq fois. La même approche a déjà été appliquée à une tâche plus complexe : l'analyse des devis de réparation, où un test a montré une surcharge de 54 168 roubles et huit postes plus chers que le marché de plus de 50 %.

Ce Que Cela Signifie

L'approche « le LLM écrit du code, pas une réponse » semble être l'un des moyens les plus pratiques d'utiliser des modèles où la précision importe. Pour la comptabilité, les devis, les impôts et tout scénario de calcul, cela élimine le risque principal : le texte, la structure et l'automatisation restent avec le modèle, tandis que les chiffres vérifiables restent avec un logiciel ordinaire.