IBM: вопросы заказчику до генерации подняли точность смарт-контрактов с 54% до 73%

Агенты на базе больших языковых моделей умеют превращать описание на обычном английском в код, который компилируется и запускается. Но делает ли он то, что хотел автор, обычно никто толком не измеряет. Для смарт-контрактов вопрос острый: это программы в блокчейне, они сами хранят и переводят деньги, и после запуска их нельзя исправить. Исследователи IBM T.J. Watson Research Center взяли 600 существующих контрактов на Solidity, дали модели описать каждый словами, а затем попросили ИИ-агентов написать контракт заново. Точность считали по доле транзакций, на которых новый контракт ведёт себя так же, как оригинал. Лучший конвейер получил 72,9% на 500 отложенных контрактах. Генерация «с одного раза» дала 53,9%, прежний конвейер самих авторов — 39,3%. Больше всего помогли вопросы заказчику до написания кода.

Чем на самом деле меряли «понимание»

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

• Статический анализатор Slither, заточенный под известные классы уязвимостей, выдал новое замечание лишь после 3 из 200 удалённых проверок доступа. • Языковая модель в роли судьи, читающая код, находит многие ошибки, но помечает 80% нетронутых контрактов. Если требовать от неё исполняемое доказательство, ложных тревог меньше, но и ловит она всего 30%. • Эталонная модель на Python, написанная по описанию, ловит 94,3% типовых ошибок вроде снятого модификатора или перевёрнутого сравнения. Но такая же модель, написанная только по названиям функций, ловит 87,5%.

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

Точность воспроизведения при этом считали строго. Из каждого контракта делали 60 случайных последовательностей по 8 вызовов. Те же вызовы прогоняли на оригинале и копии, и шаг засчитывали, только если совпал исход и изменились те же наблюдаемые значения. Отсутствующая функция или другая сигнатура — провал шага.

Где теряется замысел

Короткое описание на 140 слов опускает много деталей. Проверка показала, что в 76 из 100 таких описаний есть хотя бы одно прямое противоречие контракту, например «администратор может открыть торги», хотя на деле открыть может любой. В среднем не хватает 14,9 правил. Полное описание на 1700 слов устраняет это.

В эксперименте эталонная модель по короткому описанию поймала 65,9% ошибок, специфичных для контракта, а по полному — 87,5%. Разрыв составил 21,6 пункта. Контракты, которые пишет генератор (GPT-5.4-mini, 92 контракта), показали ту же картину:

• короткое описание — 55,6%; • плюс ответы на вопросы интервьюера-агента — 79,4%; • плюс ответы на десять фиксированных вопросов — 76,0%; • полное описание — 91,0%.

С Claude Sonnet 5 результат вырос с 56,1% до 75,1%, с Gemini 3.5 Flash — с 51,8% до 74,5%. Пример из работы: в описании контракта управления ликвидностью перечислены состояния и операции, но не сказано, кто может их вызывать. Модель добавила роль владельца, и контракт совпал лишь с 25% транзакций. Один ответ клиента «все операции открыты любому аккаунту» поднял совпадение до 100%.

Проверки после генерации почти не помогают: все протестированные стадии вместе добавляют около одного пункта. Автоматический цикл, который переписывает код по замечаниям аудитора безопасности, отнимает 12,8 пункта, потому что вместе с рискованным поведением вырезает и нужное.

Сколько вопросов нужно и что с оговорками

Конвейер с вопросами сначала опрашивает заказчика по чек-листу. Потом сверяет контракт с независимо написанной эталонной моделью, а каждое расхождение показывает заказчику как слепой выбор между двумя вариантами. Замечания по безопасности он только сообщает и код не переписывает. Хватает трёх–пяти хорошо подобранных вопросов, чтобы вернуть 60–75% выигрыша.

Главная оговорка: заказчика изображала GPT-5.4, у которой перед глазами был сам оригинальный контракт. Прирост в 19–23 пункта для трёх семейств генераторов — это оптимистичная оценка того, что даст живой автор. Кроме того, оригиналы тоже несовершенны: в исходном датасете у 35,1% из 21 976 контрактов есть заглушки, у 27,8% — тело функции из одних комментариев, их отфильтровали. Выигрыш сохранился и на 24 описаниях без противоречий, хотя на такой выборке подгруппы не различить.

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