Недетерминизм LLM: почему автоматическая оценка кода может стоить дороже

Андрей Отинов -

Разработчик под ником vithoy решил собрать тренажёр, который учит читать чужой код и объяснять его словами. Оценку объяснений должна была давать языковая модель. Идея простая: пользователь видит фрагмент рабочего кода, пишет своими словами, как он работает, а нейросеть выставляет оценку. Но когда дело дошло до реализации, выяснилось: заставить LLM оценивать честно и стабильно — задача, которая съела больше времени, чем весь остальной проект.

Источник: Habr

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

Прежде чем встраивать LLM-оценщик в свой продукт, стоит проверить три вещи: понимаете ли вы, что именно оцениваете, готовы ли вы к тому, что модель будет врать, и есть ли у вас бюджет на итерации промпта.

Что именно пошло не так: недетерминизм LLM в оценке

Автор начал проект с бэкенда на Java. Собрал базовую архитектуру, накидал лендинг, переделывал фронт несколько раз. Но главная проблема оказалась не в коде, а в том, как заставить нейросеть оценивать стабильно.

Суть недетерминизма простая: одна и та же модель на один и тот же запрос может выдать разные ответы. Для генерации текста это терпимо, для оценки — катастрофа. Если сегодня модель оценила объяснение пользователя на 8 из 10, а завтра на 4, тренажёр теряет смысл. Пользователь не понимает, что он сделал не так, и перестаёт доверять системе.

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

Почему это меняет стоимость и сроки разработки

Когда вы заменяете человека-эксперта LLM-оценщиком, вы не убираете затраты на оценку — вы переносите их в другую фазу. Вместо оплаты часов ревьюера вы получаете:

  • время на написание и отладку промпта;
  • затраты на API-запросы при каждой оценке;
  • время на тестирование стабильности — прогон одного и того же ответа несколько раз;
  • риск, что после обновления модели вся калибровка слетит.

Автор начал с заглушки, которая на любой ответ возвращала случайные числа. Это позволило проверить, что бэкенд работает, но не дало никакой информации о качестве оценки. Когда он подключил реальную LLM, началась война с недетерминизмом.

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

Что можно проверить до того, как писать код

Прежде чем встраивать LLM-оценщик, проведите простой тест. Возьмите 5-10 примеров ответов, которые вы считаете хорошими, и 5-10 — плохими. Прогоните их через выбранную модель 10 раз каждый. Посмотрите разброс оценок.

Если разброс больше 2 баллов по 10-шкале — модель не подходит для вашей задачи без дополнительной калибровки. Если разброс меньше — проверьте, не совпадают ли оценки случайно из-за того, что модель всегда выдаёт среднее.

Автор не указывает, какую именно LLM он использовал, но его опыт показывает: даже после многих итераций промпта стабильность остаётся проблемой. Это значит, что проблема не в конкретной модели, а в самой природе задачи.

Где скрытые риски и ограничения

Кейс автора — единичный, не рецензированный, и сам автор признаёт, что он не эксперт. Это значит, что его решения могут быть наивными, а метод может не масштабироваться на другие задачи.

Основные риски:

  • Стоимость API. Каждая оценка — это запрос к LLM. Если у вас тысячи пользователей, затраты могут оказаться выше, чем оплата человека-ревьюера.
  • Зависимость от модели. Если вы используете внешний API, изменение модели провайдером может сломать вашу калибровку.
  • Отсутствие эталона. Вы не можете точно сказать, правильна ли оценка LLM, потому что у вас нет независимого эталона. Вы сравниваете оценку модели с собственным мнением, но это не объективная метрика.
  • Правовые риски. Если вы используете LLM для оценки сотрудников или кандидатов, недетерминизм может привести к несправедливым решениям и юридическим претензиям.

Автор не обсуждает эти риски, но для бизнеса они критичны. Прежде чем внедрять LLM-оценщик, проконсультируйтесь с юристом и убедитесь, что у вас есть процесс апелляции для пользователей.

Что делать на этой неделе: практический чек-лист

Если вы всё ещё хотите использовать LLM для оценки, вот что можно проверить за неделю без перестройки компании:

  1. Определите, что именно вы оцениваете. Не «качество ответа», а конкретные критерии: полнота, точность, структура, использование терминов. Запишите их.
  2. Соберите тестовый набор. 20 примеров: 10 хороших, 10 плохих. Убедитесь, что вы и ваши коллеги согласны с этой разметкой.
  3. Протестируйте стабильность. Прогоните каждый пример через LLM 5-10 раз. Запишите разброс оценок.
  4. Сравните с человеком. Попросите коллегу оценить те же примеры. Если оценки LLM и человека расходятся больше чем на 1-2 балла, модель не готова к продакшену.
  5. Оцените стоимость. Посчитайте, сколько будет стоить оценка одного ответа при вашем объёме пользователей. Сравните с оплатой человека.
  6. Подготовьте fallback. Что вы будете делать, если модель выдаст явно неверную оценку? Как пользователь может оспорить результат?

Автор потратил месяцы на итерации промпта и переделку фронта. Его главный урок: начинать надо не с интерфейса, а с бэкенда и с понимания того, что именно вы оцениваете. Если вы не можете сформулировать критерии оценки для человека, LLM тем более не сможет.

Источники

Дополнительный контекст: этот кейс — не единичный. Многие разработчики, пытающиеся автоматизировать оценку с помощью LLM, сталкиваются с теми же проблемами. Если вы хотите глубже разобраться в теме, обратите внимание на исследования в области калибровки LLM и методы few-shot промптинга для повышения стабильности оценок. Один из подходов — использовать ансамбль моделей или несколько запросов к одной модели с усреднением результата, но это увеличивает стоимость и время обработки.

Генерация изображения

  • Модель: flux-schnell
  • Провайдер: replicate

Что почитать дальше