Habr explica cómo lograr que un LLM calcule sin errores generando código Python

Habr ha publicado un análisis práctico sobre por qué los LLM fallan con frecuencia en aritmética y cómo sortear el problema en un producto real. En lugar de pedir al modelo que haga las cuentas por sí mismo, el autor propone asignarle otro papel: escribir un script de Python y dejar los cálculos en manos de un programa convencional.

Por qué fallan los LLM

El problema no es que un chatbot concreto se haya «estropeado». Un transformer predice el siguiente token según probabilidades; no llama a una calculadora. Por eso, al multiplicar, reescalar una receta o calcular la factura de suministros, el modelo puede dar una respuesta que parece convincente, pero que se desvía de la correcta en un pequeño porcentaje o incluso en decenas de puntos. El usuario lo percibe como una degradación, aunque en realidad se trata de una limitación fundamental de la arquitectura: el LLM reproduce bien el patrón de un cálculo, pero no ejecuta la operación en sí.

«El modelo no calcula.

El modelo programa. Y el programa calcula.»

Por eso son especialmente peligrosas las tareas en las que el error no salta a la vista de inmediato. Si una persona ya sabe comprobar el resultado a mano, no necesita un LLM. Pero cuando se usa el modelo precisamente para no tener que calcular manualmente, una cifra verosímil pasa fácilmente sin revisión. El artículo pone como ejemplo las facturas de suministros: el modelo puede recordar una tarifa desactualizada, multiplicarla «de cabeza» y presentar la respuesta con buen formato, aunque el cálculo interno sea erróneo.

Cómo funciona el esquema

El esquema se basa en una separación de funciones. El usuario envía la tarea por mensajería; el LLM recibe un prompt de sistema con el contexto y los datos necesarios y, a continuación, genera código Python. Ese código se ejecuta en un sandbox aislado de Docker y, al final, el servicio devuelve no solo un texto con el desglose línea por línea, sino también un archivo de Excel listo para usar. En este escenario, el modelo se encarga de entender la petición y de estructurar el programa, mientras que la precisión aritmética queda por completo en manos del intérprete de Python.

• La entrada pueden ser lecturas de contadores, una tabla o un presupuesto
• Las tarifas y los datos de referencia se inyectan en el prompt desde un archivo de configuración
• El modelo debe devolver código Python, no una respuesta ya calculada
• El script se ejecuta en un contenedor aislado con tiempo límite
• Como resultado, el usuario recibe el cálculo en texto y un archivo de Excel

El autor explica que para estas tareas utiliza Qwen y DeepSeek, y no modelos punteros caros. La lógica es pragmática: si hay que generar un script de 20–200 líneas, la diferencia en calidad de código entre los modelos premium y los más asequibles es pequeña, mientras que la diferencia de precio es notable. Hace especial hincapié en que las tarifas y los datos de referencia deben llegar al prompt desde la configuración, no desde la «memoria» del modelo. Si una tarifa cambia, basta con actualizar una línea de datos sin tocar el modelo.

Dónde estuvieron los tropiezos

El error más habitual en la fase inicial fue pedir al modelo que buscara él mismo las tarifas. En ese modo, introduce con total seguridad datos desactualizados o ajenos, y el error parece verosímil. Por eso el autor trasladó todas las cifras sensibles a la configuración y las actualiza por separado a partir de fuentes oficiales.

El segundo problema es que algunos modelos, incluso tras recibir la instrucción, siguen intentando «calcular de cabeza» y dar una respuesta final. La solución es sencilla: validar que haya código Python y, si hace falta, reenviar la petición con una formulación más estricta.

En la práctica también surgieron cuestiones más técnicas: el cirílico se corrompía en Excel sin UTF-8 explícito, el modelo importaba bibliotecas innecesarias como pandas y, sin el stderr completo, no podía corregir sus propios errores cuando el script fallaba. Pero cuando el servicio empezó a devolver el traceback al modelo, el número de iteraciones inútiles se redujo cinco veces, según el autor. El mismo enfoque ya se ha aplicado a una tarea más compleja, el análisis de presupuestos de reformas, donde una prueba detectó un sobrecoste de 54 168 rublos y ocho partidas más de un 50% por encima del precio de mercado.

Qué significa

El enfoque «el LLM escribe código, no la respuesta» parece una de las formas más prácticas de usar modelos allí donde la precisión importa. En contabilidad, presupuestos, impuestos y cualquier escenario de cálculo, elimina el riesgo principal: el texto, la estructura y la automatización quedan a cargo del modelo, y las cifras verificables, a cargo de un programa convencional.