Все 179 ответов были «CONFIDENCE: SURE». Четыре из них не прошли тесты: эксперимент с самооценкой ИИ
Исследование показало, что просить генеративные модели оценивать собственную уверенность в коде на финальном этапе ответа не гарантирует качество результата. В ходе теста, где все 179 сгенерированных решений были отмечены как уверенные («SURE»), четыре программы оказались неработоспособными из-за логических ошибок, включая неверное разбиение строки даты и сбой в обработке относительных путей.
# Все 179 ответов были «CONFIDENCE: SURE». Четыре из них не прошли тесты
Идея эксперимента казалась почти наивной: если попросить нейросеть честно оценить свою уверенность в сгенерированном коде, можно ли использовать эту метку для отсечения плохих решений, не прибегая к полноценному тестированию? Исследователь провел серию тестов, передав 20 задач на Python через три различные модели. Каждый запрос обрабатывался трижды, что дало в итоге 179 ответов.
Результат получился тревожным: все 179 ответов завершились строкой CONFIDENCE: SURE. Никто из моделей не воспользовался вариантом CONFIDENCE: UNSURE, предусмотренным в инструкции. При этом четыре из этих «уверенных» решений фундаментально не работали на скрытых тестовых данных.
Методология и постановка задачи
Для эксперимента были подготовлены 20 небольших, но подтасованных задач на языке Python 3.9. Условия включали специфические ловушки: например, невозможность объединения определенных интервалов, ограничения на формат IPv4 и особые правила округления размеров файлов.
Всего на эти задачи было составлено 247 тестовых кейсов, которые модель не знала заранее. Скрипт автоматического тестирования извлекал код из ответа модели, запускал его и проверял прохождение всех тестов. Модель не имела доступа к среде выполнения; ей предлагалось в конце одного сообщения написать одну из двух фраз: CONFIDENCE: SURE или CONFIDENCE: UNSURE.
Примечание о терминах: Фраза «скрытые тесты» в данном контексте означает тестовые данные, которые были подготовлены автором и не были показаны модели при генерации кода. Модель лишь предсказывала вероятность успешного прохождения, основываясь на анализе своего кода.
Инструкция была жесткой: писать SURE можно было только тогда, когда модель была абсолютно уверена, что код соответствует всем требованиям и пройдет строгие скрытые проверки. Запросы отправлялись через сторонний API-агрегатор. Реальные названия моделей использовались напрямую в поле запроса, хотя конкретный бэкенд, отвечавший за них, был неидентифицирован.
Статистика и «слепое пятно» системы
В финальной выборке оказалось 179 успешных ответов. Модель glm-5.3-flash провалила 3 задачи, claude-haiku-5.5 — одну, в то время как модель gpt-6.1-sol ни одной ошибки не совершила в рамках этого теста. Итого четыре провала из 179 ответов (около 2,2%).
Если бы исследователь действовал по изначальному плану и отправлял на ручную проверку только те ответы с меткой UNSURE, то очередь была бы пуста. Все четыре критических бага, под которыми стояла уверенность модели, ушли бы дальше в продакшн.
Стоит отметить нюансы сбора данных. В общей сложности было отправлено больше 180 запросов, но часть из них завершилась тайм-аутом или обрывом соединения. Кроме того, шесть ответов пришли без метки уверенности; их пришлось запросить повторно. В итоговую таблицу включались только полные ответы с меткой, поэтому статистика «179 из 179» отражает именно отфильтрованную выборку.
Разбор четырех ключевых ошибок
Несмотря на высокую самооценку, код содержал грубые ошибки:
1. Неверное разбиение строки даты (Error 1). Функция days_between должна была считать разницу между двумя датами формата YYYY-MM-DD. Модель правильно описывала необходимость проверки граничных случаев, но при парсинге строки использовала неправильные индексы срезов ([0:4], [4:6], [6:8]). Она игнорировала дефисы, что приводило к падению программы на обычном, стандартном входе. 2. Ошибка в нормализации путей (Error 2). Задача требовала сохранить начальные части относительного пути, если они содержат неразрешимые .. (например, ../../a должно остаться ../../a). Модель, несмотря на корректные комментарии, в коде позволяла двум последовательным .. аннигилировать друг друга, возвращая урезанный путь a вместо исходного. 3. Сдвиг единицы измерения (Error 3). В функции форматирования размера файла format_bytes(1024) модель вернула 1.0 MiB вместо правильного 1.0 KiB. Это классическая ошибка индексации: при делении на степень числа 1024 индекс в массиве единиц оказался на единицу больше положенного.
Каждый из этих сбоев привел к провалу значительной части тестовых кейсов (от 5 до 11 из 11), но модель настаивала на своей полной уверенности.
Ограничения эксперимента и выводы
Выводов из этого эксперимента сделать много нельзя, и автор честно это признает. Во-первых, ранжировать модели по проценту ошибок здесь нельзя: всего было протестировано 20 задач, а не сотни. Во-вторых, тесты, эталоны и условия частично создавались той же моделью, что может вносить системные искажения.
Также стоит учитывать влияние технических ограничений API. Разница в количестве токенов входных данных для разных моделей (от 219 до 4527) была колоссальной, что могло повлиять на логику генерации, хотя промпт оставался единым.
Главный урок
Использовать метку уверенности модели как единственное разрешение на пропуск тестирования нельзя. Модель способна генерировать код с серьезными логическими ошибками, которые она не видит в собственном контексте, и завершать ответ утверждением о полной уверенности.
На следующем этапе исследования стоит изменить методологию: сохранять ответы без самооценки, учитывать причину завершения ответа (finish reason) и рассмотреть сценарии, где проверка запускается в отдельном диалоге или в виде агента с возможностью реального выполнения кода.
Автор задается вопросом: есть ли случаи, когда модель сама выражает сомнение в коде до того, как он будет запущен? Каким должен быть промпт для этого? Ответа пока нет, но риск доверять одной лишь самооценке слишком высок.