Разработчик создал тренажёр чтения кода — и столкнулся с недетерминизмом LLM

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

Откуда взялась идея Два раздражителя накапливались постепенно.

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

Где сломалось: недетерминизм LLM Написать сам тренажёр оказалось несложно.

Трудности начались при настройке оценки. Задача выглядит тривиально: дать модели два текста — код и объяснение пользователя — и попросить оценить, насколько хорошо одно описывает другое. На практике модель вела себя непредсказуемо: За одно и то же объяснение при повторном запросе давала разные баллы Одни аспекты кода ценила несправедливо высоко, другие — игнорировала без причины «Строгость» оценщика менялась от запроса к запросу без видимых паттернов Непонятно было, что вообще считать хорошим объяснением — исчерпывающее или ёмкое? Это классический недетерминизм LLM — свойство, о котором все знают теоретически, но которое остро ощущается именно тогда, когда от модели нужна воспроизводимая оценочная функция, а не генерация текста.

Что именно оценивать

Разработчик обнаружил, что главная проблема не техническая, а концептуальная: что считать хорошим объяснением кода? Должно ли оно быть исчерпывающим — охватывать все ветки, граничные случаи, побочные эффекты? Или достаточно точно передать основную идею алгоритма? Нужно ли упоминать потенциальные баги? Важна ли терминология? Должен ли объясняющий показать, что понимает, зачем написан этот код, а не только что он делает? Без чётких ответов любые критерии оценки для LLM получаются размытыми — и модель заполняет неопределённость произвольно. Именно поэтому промпт-инжиниринг для задач оценивания значительно сложнее, чем для генеративных задач. Возможные технические подходы: строгие промпты с конкретными рубриками, голосование по нескольким независимым запросам к модели, эталонные объяснения как референс. Но сначала нужно определить, что именно измеряешь.

«Самым тяжёлым оказалось совсем не написать тренажёр, а заставить

нейросеть оценивать честно и стабильно — и вообще понять, что именно нужно оценивать»

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

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