Habr Explicó Cómo Obligar a las LLMs a Calcular Sin Errores Mediante la Generación de Código Python

Habr publicó un análisis práctico de por qué los LLM cometen errores regularmente en aritmética y cómo evitarlo en un producto real. En lugar de pedir al modelo que calcule por sí solo, el autor sugiere darle otro papel: escribir un script en Python y pasar los cálculos a un programa común.

Por Qué los LLM Cometen Errores

El problema no es que un chatbot específico "se rompiera". Un transformador predice el siguiente token por probabilidad, no invoca una calculadora. Por tanto, al multiplicar, recalcular una receta o calcular facturas de servicios, el modelo puede dar una respuesta que parece convincente, pero que difiere de la correcta en varios por ciento o incluso decenas. Para un usuario, parece una degradación, aunque en realidad se trata de una limitación fundamental de la arquitectura: los LLM reproducen bien el patrón de cálculo, pero no realizan la operación en sí.

"El modelo no calcula.

El modelo programa. Y el programa calcula."

Por eso son especialmente peligrosas las tareas donde el error no salta a la vista de inmediato. Si una persona ya puede verificar el resultado manualmente, no necesita un LLM. Pero cuando el modelo se usa precisamente para evitar cálculos manuales, un número plausible pasa fácilmente sin verificación. El artículo da un ejemplo con facturas de servicios: el modelo puede recordar una tarifa desactualizada, multiplicarla "mentalmente" y formular la respuesta elegantemente, aunque el cálculo interno sea incorrecto.

Cómo Funciona el Esquema

El esquema funcional se construye alrededor de la división de roles. El usuario envía una tarea a un mensajero, el LLM recibe un prompt del sistema con contexto y datos necesarios, luego genera código en Python. Este código se ejecuta en una sandbox Docker aislada, y el servicio retorna no solo texto formateado, sino también un archivo Excel listo. En tal escenario, el modelo se encarga de la comprensión de la solicitud y la estructura del programa, mientras que la precisión aritmética recae completamente en el intérprete Python.

• La entrada pueden ser lecturas de medidores, una tabla o un presupuesto
• Los aranceles y directorios se suministran al prompt desde un archivo de configuración
• El modelo debe devolver código Python, no una respuesta lista
• El script se ejecuta en un contenedor aislado con tiempo límite
• El usuario recibe un cálculo en texto y un archivo Excel

El autor escribe que para tales tareas usa Qwen y DeepSeek en lugar de modelos premium caros. La lógica es pragmática: si necesitas generar un script de 20–200 líneas, la diferencia en la calidad del código entre modelos premium y más accesibles es pequeña, pero la diferencia de precio es notable. Un énfasis aparte: los aranceles y directorios deben provenir del prompt desde una configuración, no de la "memoria" del modelo. Si cambia una tarifa, es suficiente actualizar una línea de datos sin tocar el modelo.

Dónde Surgieron Problemas

El error más común en la etapa inicial fue pedir al modelo que encontrara los aranceles por sí solo. En ese modo, confiadamente sustituye datos desactualizados o ajenos, y el error parece plausible. Por eso el autor movió todos los números sensibles a un archivo de configuración y los actualiza desde fuentes oficiales por separado.

Un segundo problema: algunos modelos aún intentan "calcular mentalmente" y dar una respuesta lista incluso después de las instrucciones. La solución es simple: validar la presencia de código Python y, si es necesario, enviar una solicitud de seguimiento con formulación rigurosa. En la práctica, surgieron problemas más técnicos: el cirílico en Excel se rompía sin UTF-8 explícito, el modelo traía librerías innecesarias como pandas, y sin stderr completo no podía corregir sus propios errores después de la caída del script.

Pero cuando el servicio comenzó a devolver traceback al modelo, el número de iteraciones inútiles, según el autor, se redujo cinco veces. El mismo enfoque se aplicó ya a una tarea más compleja: análisis de presupuestos de reparación, donde una prueba mostró un cargo excesivo de 54.168 rublos y ocho partidas más caras que el mercado en más del 50%.

Qué Significa Esto

El enfoque "el LLM escribe código, no una respuesta" parece ser una de las formas más prácticas de usar modelos donde importa la precisión. Para contabilidad, presupuestos, impuestos y cualquier escenario de cálculo, esto elimina el riesgo principal: el texto, la estructura y la automatización quedan con el modelo, mientras que los números verificables quedan con el software común.