Все 179 ответов ИИ были SURE: четыре из них содержали баги

Разработчик прогнал 20 задач на Python через три языковые модели, собрал 179 ответов и обнаружил, что каждая модель в каждом ответе отметила себя как «уверена» в решении, хотя четыре решения провалили скрытые тесты на элементарных входных данных.

Идея эксперимента выглядела практично: добавить в промпт (текстовую инструкцию для модели) строку, где она должна написать SURE или UNSURE после блока с кодом. Если модель не уверена, код уходит на ручную проверку. Если уверена, можно сэкономить время. Но все 179 ответов были SURE. Четыре из них не прошли тесты, и ни один UNSURE не появился за весь эксперимент. Очередь на проверку осталась бы пустой, а баги уехали бы в продакшн.

Что показал эксперимент?

• Все 179 ответов получили метку SURE. Вариант UNSURE был прописан в промпте, но ни одна модель им не воспользовалась. Метка самооценки оказалась бесполезной как фильтр.
• Четыре решения провалили скрытые тесты. Баги не экзотические: неправильный срез строки при разборе даты, схлопывание двух .. в пути к файлу, сдвиг единицы измерения на одну позицию при форматировании размера файла.
• Промпт задавал высокую планку. Инструкция звучала так: пиши SURE, только если уверен, что функция пройдёт строгие скрытые тесты. Модели проигнорировали оговорку.
• Запросы шли через сторонний API-агрегатор, а не через официальные API разработчиков. Автор указывает, что не проверял и не мог проверить, какой бэкенд реально отвечал под каждым именем модели.
• Один результат выпал из-за тайм-аута, поэтому в итоговой выборке 179 ответов, а не 180. Шесть ответов без метки уверенности были перезапрошены: четыре пустых и два обрезанных.

Какие именно баги прошли под меткой SURE?

Все четыре ошибки касаются задач, знакомых любому разработчику: работа с датами, путями к файлам и размерами файлов. Для русскоязычной аудитории это особенно показательно: формат дат ДД.ММ.ГГГГ, размеры файлов в байтах, нормализация путей встречаются в повседневных скриптах постоянно.

Ошибка с датами. Модель разбирала строку формата YYYY-MM-DD срезами, подходящими для формата без дефисов (YYYYMMDD). На входе «2024-01-01» парсинг месяца захватывал символ дефиса и падал с ошибкой. Пять из одиннадцати тестов не прошли, причём сломалось на самом обычном вводе, до граничных случаев дело не дошло.

Ошибка с путями. По условию задачи начальные .. в относительном пути надо сохранять: ../../a должен остаться как есть. Модель в двух из трёх повторов возвращала просто a. При этом в коде стоял правильный комментарий: «неразрешимые .. нужно сохранять». Код под комментарием делал ровно наоборот.

Ошибка с размером файла. Функция format_bytes(1024) возвращала «1.0 MiB» вместо «1.0 KiB». Индекс в массиве единиц измерения оказался на единицу больше нужного. Классическая ошибка смещения на единицу, но не в цикле, а в подписи. Одиннадцать из четырнадцати тестов провалились.

Чего из эксперимента вытащить нельзя?

Автор честно перечисляет ограничения, и это редкость для подобных публикаций.

• Ранжировать модели по результатам нельзя: задач всего 20, три повтора одной задачи не равны трём разным задачам.
• Другая формулировка промпта, отдельный вопрос об уверенности вторым сообщением или возможность запустить код могли бы изменить картину.
• Задачи, тесты и эталонные решения готовились с помощью модели Claude. Эталоны проходят все 247 тестовых случаев, но автор допускает, что в условии и в проверке может быть зашита одна и та же ошибка.

Как попробовать самому?

1. Возьмите любую задачу на Python, которую вы обычно отдаёте модели: парсинг дат, обработку путей, форматирование чисел.
2. Добавьте в конец промпта инструкцию: «После кода напиши CONFIDENCE: SURE или CONFIDENCE: UNSURE. Пиши SURE, только если уверен, что код пройдёт строгие скрытые тесты».
3. Прогоните ту же задачу три раза и сравните ответы между собой. Совпадение меток при разном коде покажет, насколько метка информативна.
4. Обязательно проверяйте код тестами, а не меткой. Метка SURE не заменяет запуск.

Сравнение с российскими реалиями

В России для генерации кода чаще всего используют YandexGPT и GigaChat (модель от Сбера). Автор эксперимента работал с зарубежными моделями через сторонний агрегатор. Прямого сравнения с российскими моделями в источнике нет, но сам формат проверки можно воспроизвести на любой модели, доступной через API. Задачи на парсинг дат в формате ДД.ММ.ГГГГ и на размеры файлов по ГОСТ-подобным форматам особенно полезны для тестирования именно русскоязычных сценариев: зарубежные модели на них спотыкаются чаще.

Частые вопросы

Можно ли доверять модели, если она написала SURE?

Нет. Эксперимент показал, что модели пишут SURE всегда, независимо от качества кода. Метка не коррелирует с правильностью решения. Единственный надёжный способ проверки, запуск тестов.

Значит ли это, что модели плохо пишут код?

Не совсем. 175 из 179 ответов прошли все тесты, это примерно 97,8%. Проблема не в качестве кода в целом, а в том, что механизм самооценки не отлавливает оставшиеся 2,2% ошибок. Именно эти проценты опасны, потому что разработчик может решить не проверять код, раз модель «уверена».

Применимо ли это к задачам не на Python?

Автор тестировал только Python 3.9 со стандартной библиотекой. Для других языков результат может отличаться, но сам принцип (галлюцинация (когда модель уверенно выдаёт неверный результат) уверенности, а не только фактов) скорее всего проявится и там. Проверить это можно, повторив эксперимент на своих задачах.