Как читать бенчмарк агентных ИИ на примере одной задачи: что значит 60% на SWE-bench
Разбираем одну реальную задачу из бенчмарка: почему 60% — это не ум, а 6 решённых кейсов из 10, где агент запнулся.
Представьте, что вы наняли нового джуна-тестировщика. Вчера он блестяще отвечал на собеседовании, а сегодня вы даёте ему реальную задачу: в вашем интернет-магазине после обновления корзины у части пользователей перестал работать промокод. Ошибка плавающая, в логах пусто, нужно найти и починить. Вы открываете бенчмарк (тестовый набор задач для сравнения моделей) SWE-bench — это экзамен для ИИ-агентов, где им дают доступ к коду реальных проектов на GitHub, терминалу и просят довести баг-фикс до конца, прогнав тесты. Вы видите счёт 60%. Это не значит, что модель на 60% умнее человека. Это значит, что из 10 таких же реальных поломок агент полностью решил 6, а в 4 запнулся на полпути. Сегодня мы пройдём через одну из этих четырёх нерешённых задач и посмотрим, где именно ломается искусственный интеллект.
Шаг 1. Что агент видит на старте и как он должен вести диалог
В бенчмарке агенту выдают ссылку на репозиторий (хранилище кода), описание бага (ошибки) и цель: «Сделай так, чтобы тесты корзины снова стали зелёными». У него есть инструменты: терминал для запуска команд, редактор кода и поисковик по файлам. В теории агент должен начать с диалога: «Я вижу, что ошибка возникает при применении промокода на сумму от 5000 рублей. Посмотрю логи тестового запуска и код модуля скидок». Но в 40% случаев на SWE-bench агент пропускает этот этап. Он не задаёт уточняющих вопросов, не проверяет граничные условия (например, что происходит, если промокод применить дважды) и сразу бросается писать код. Хороший сотрудник сначала сузит круг поиска, агент же часто пытается угадать. Если бы ваш джун сразу полез менять файл с расчётами налогов, вы бы его остановили. Агент в бенчмарке остановить себя не может — у него нет встроенного чувства самосохранения.
Шаг 2. Почему агент запинается на инструментах и теряет цель на длинной дистанции
Допустим, наш агент всё же начал расследование. Он открывает терминал и вводит команду для поиска слова «promo» по всему проекту. Терминал возвращает 200 совпадений. Агент читает первые пять, устаёт от объёма данных и решает, что проблема в файле utils.js, потому что тот чаще всего встречается в выдаче. Это классическая ошибка потери цели. В агентном тесте оценивают не красоту ответа, а достигнутый результат. Агент должен был сузить поиск до папки /cart/checkout/, но он этого не сделал. Далее он вызывает инструмент редактирования. В SWE-bench агент работает с кодом через специальные интерфейсы «агент—компьютер», которые позволяют ему создавать и менять файлы. Он вносит правку, но забывает обновить соседний файл с валидацией (проверкой) формы. В 60% случаев на SWE-bench тесты падают именно из-за таких разрывов: агент чинит точку А, попутно ломая точку Б, и не запускает полный набор тестов, чтобы это заметить. Он тратит одну из трёх разрешённых попыток на частичное решение, а на вторую попытку у него уже не остаётся контекста (памяти о том, что он делал минуту назад).
Шаг 3. Как читать цифру 60% и считать реальную цену успеха
Счёт в бенчмарке — это процент полностью решённых задач, где финальный прогон тестов выдал «ОК». Но цифра скрывает три критических параметра. Первый — количество шагов. В правилах теста стоит лимит: не больше 3 шагов и 1 запроса на уточнение. Если агент на второй попытке снова полез не в тот файл, он сжёг бюджет. Второй параметр — стоимость. Агентные системы тратят деньги на каждый вызов языковой модели и каждую секунду работы виртуальной машины. 60% успеха могут стоить в три раза дороже, чем 40% у другой модели, которая честно признаётся в незнании. Третий параметр — стабильность. В отчёте SWE-bench Verified (уточнённая версия теста с ручной проверкой задач) не видно, не сломает ли этот «фикс» соседние процессы при следующем обновлении. Вы видите зелёную галочку, но не видите технический долг, который агент оставил в файле конфигурации проекта.
Шаг 4. Как проверить это поведение на своей задаче без бенчмарка
Вам не нужен доступ к SWE-bench, чтобы увидеть эту механику. Возьмите свою текущую проблему — тот самый промокод. Скопируйте описание бага и ссылку на ветку кода в Cursor или Claude Code. Дайте агенту вводную: «Найди причину падения промокодов. Лимит — 3 шага. На каждом шаге пиши, что ты видишь и что будешь делать. Если сомневаешься — остановись и спроси». И смотрите не на финал, а на лог. На шаге 1 он должен был спросить: «Есть ли у вас доступ к боевым логам или только к тестам?». Если он промолчал — он уже играет в угадайку. На шаге 2 он должен был сузить поиск через git blame (команду, показывающую, кто и когда менял строку кода), а не читать весь проект. На шаге 3 он должен был запустить именно тест корзины, а не всю батарею тестов проекта, которая работает десять минут. Если агент запнулся и начал извиняться или предлагать переписать всё с нуля — вы поймали ту самую границу, на которой 60% задач в бенчмарке превращаются в 40%.
Что сделать завтра утром
Откройте вашу трекинговую систему (Jira, YouTrack или даже обычный чат с командой) и найдите одну задачу с тегом «баг», которую вы бы дали мидлу (разработчику среднего уровня). Скопируйте её в ИИ-агент с жёстким промптом: «Ты — инженер поддержки. Твоя цель — вернуть зелёный статус тестам. Не больше 3 действий. Если на втором действии ты не видишь явной причины — задай ровно один уточняющий вопрос и остановись. Не пиши код, пока не покажешь мне путь к файлу». Оцените ответ не по тому, предложил ли он решение, а по тому, где он запнулся: на уточнении вводных, на навигации по коду или на проверке результата. Этот один разбор покажет вам реальную применимость агента в вашем рабочем дне точнее любого глобального рейтинга.