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

На Habr вышел практический разбор того, почему LLM регулярно ошибаются в арифметике и как это обойти в реальном продукте. Вместо того чтобы просить модель считать самой, автор предлагает дать ей другую роль: написать Python-скрипт и передать вычисления обычной программе.

Почему LLM ошибаются Проблема не в том, что конкретный чат-бот «испортился».

Трансформер предсказывает следующий токен по вероятности, а не вызывает калькулятор. Поэтому при умножении, пересчёте рецепта или расчёте коммуналки модель может выдать ответ, который выглядит убедительно, но отличается от правильного на несколько процентов или даже на десятки. Для пользователя это выглядит как деградация, хотя на деле речь о фундаментальном ограничении архитектуры: LLM хорошо воспроизводит шаблон вычисления, но не выполняет саму операцию.

«Модель не считает.

Модель программирует. А программа считает.» Из-за этого особенно опасны задачи, где ошибка не бросается в глаза сразу. Если человек и так умеет проверить результат в столбик, LLM ему не нужна. Но когда модель используют именно для того, чтобы не считать вручную, правдоподобная цифра легко проходит без проверки. В статье приводится пример с коммунальными платежами: модель может вспомнить устаревший тариф, перемножить его «в уме» и красиво оформить ответ, хотя внутри расчёт неверный.

Как работает схема Рабочая схема строится вокруг разделения ролей.

Пользователь отправляет задачу в мессенджер, LLM получает системный промпт с контекстом и нужными данными, затем генерирует Python-код. Этот код запускается в изолированной Docker-песочнице, а на выходе сервис возвращает не только текст с разбивкой по строкам, но и готовый Excel-файл. В таком сценарии модель отвечает за понимание запроса и структуру программы, а точность арифметики полностью уходит интерпретатору Python.

• Входом могут быть показания счётчиков, таблица или смета Тарифы и справочники подаются в промпт из конфига Модель обязана вернуть именно Python-код, а не готовый ответ Скрипт исполняется в изолированном контейнере с таймаутом На выходе пользователь получает текстовый расчёт и Excel-файл Автор пишет, что для таких задач использует Qwen и DeepSeek, а не дорогие топовые модели. Логика прагматичная: если нужно сгенерировать скрипт на 20–200 строк, разница в качестве кода между премиальными и более доступными моделями невелика, зато разница в цене заметная. Отдельный акцент — тарифы и справочники должны приходить в промпт из конфига, а не из «памяти» модели. Если ставка изменилась, достаточно обновить одну строку данных, не трогая саму модель.

Где были грабли Самая частая ошибка на раннем этапе — попросить модель самой найти тарифы.

В таком режиме она уверенно подставляет устаревшие или чужие данные, и ошибка выглядит правдоподобно. Поэтому все чувствительные числа автор вынес в конфиг и обновляет из официальных источников отдельно. Вторая проблема — некоторые модели даже после инструкции всё равно пытаются «посчитать в уме» и выдать готовый ответ.

Решение простое: валидировать наличие Python-кода и при необходимости отправлять повторный запрос с жёсткой формулировкой. На практике всплыли и более технические вещи: кириллица в Excel ломалась без явного UTF-8, модель тянула лишние библиотеки вроде pandas, а без полного stderr не могла исправлять свои же ошибки после падения скрипта. Но когда сервис начал возвращать traceback обратно в модель, число бесполезных итераций, по словам автора, сократилось в пять раз.

Тот же подход уже применили к более сложной задаче — анализу ремонтных смет, где один тест показал завышение на 54 168 рублей и восемь позиций дороже рынка более чем на 50%.

Что это значит

Подход «LLM пишет код, а не ответ» выглядит одним из самых практичных способов использовать модели там, где важна точность. Для бухгалтерии, смет, налогов и любых расчётных сценариев это снимает главный риск: текст, структура и автоматизация остаются за моделью, а проверяемые числа — за обычной программой.