В IBM показали: вопросы клиенту повысили точность смарт-контрактов по транзакциям до 72,9%

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

Как измеряли точность

Авторы взяли 600 реальных контрактов из набора FSM-SCG. Для каждого Gemini 2.5 Flash написал короткое описание примерно на 140 слов и полный документ требований примерно на 1700 слов. Основная метрика — implementation fidelity, то есть точность воспроизведения поведения оригинала. Для каждого контракта прогоняли 60 случайных последовательностей по 8 шагов в локальной виртуальной машине EVM. Шаг засчитывается, только если совпали исход вызова и все наблюдаемые значения. Авторы оговаривают, что метрика отражает замысел автора лишь настолько, насколько его воплощает исходный контракт.

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

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

На 100 свежих контрактах и 279 ошибках, специфичных для контракта, эталонная модель по короткому описанию нашла 65,9% ошибок, а по полному документу — 87,5%. Разрыв составил 21,6 пункта. Агент-экстрактор и агент-критик ничего не изменили. Чек-лист из десяти фиксированных вопросов клиенту закрыл разрыв почти полностью: 89,4% против 88,9% у полного документа.

Для генератора GPT-5.4-mini точность по транзакциям равна 55,6% при коротком описании, 76,0% с ответами на чек-лист, 79,4% с ответами интервьюера и 91,0% при полном документе. У чек-листа есть слабость: он описывает поведение, но не типы аргументов и хранимые значения, поэтому реализуется 88,7% нужных сигнатур против 94,8% у интервьюера. Прирост воспроизвёлся на других семействах: у Claude Sonnet 5 точность выросла с 56,1% до 75,1%, у Gemini 3.5 Flash — с 51,8% до 74,5%. Для трёх семейств моделей авторы оценивают выигрыш от ответов симулированного клиента в 19–23 пункта.

Описания тоже ненадёжны. Модель-аудитор нашла хотя бы одно противоречие с оригиналом в 76 из 100 описаний, например несуществующее правило доступа. Поэтому уточнение часто исправляет ложные утверждения, а не только заполняет пропуски. Среди 24 описаний без противоречий прирост от чек-листа сохраняется, но выборка слишком мала для строгого сравнения.

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

Три–пять тщательно выбранных вопросов возвращают 60–75% всего прироста. Этапы после генерации добавляют не более одного пункта, а автоматический цикл исправления безопасности отнимает 12,8 пункта: он вырезает нужное поведение вместе с уязвимостями. Итоговый конвейер сперва задаёт клиенту вопросы, затем сверяет контракт с независимой эталонной моделью и показывает расхождения клиенту как слепой выбор. Находки по безопасности он только отмечает, не переписывая код.

Ограничения существенны. Клиента имитирует GPT-5.4, который читает исходный контракт, поэтому прирост — оптимистичная оценка того, что дадут реальные авторы. Реальные люди ответят менее полно и точно. Интервалы не учитывают разброс между запусками, а 36 критериев проверялись без поправки на множественные сравнения. Авторы публикуют тестовую обвязку, 600 задач и все оценки.

Практический вывод для тех, кто строит агентов по генерации кода: вкладывайтесь в уточнение требований до генерации и не доверяйте LLM-судьям и автоматическому «ремонту» безопасности без проверки на подсаженных ошибках.