TL;DR
Когда агенту надо разобраться в незнакомой системе (расхождение документации и реальности, нестандартное API, внутренние правила компании), выигрывает цикл «сам придумал проверку → запустил → прочитал результат → поправил гипотезу». ExplorationBench — стенд из двух выдуманных миров с правилами, противоречащими привычным знаниям. В одном из миров числа молча меняются при выводе, а счёт позиций идёт с единицы вместо нуля. Модели получают кривую инструкцию, четыре раунда на эксперименты и итоговый экзамен без инструментов.
Главная находка: дополнительные «размышления» без обратной связи не заменяют эксперименты. В мире с программами модель, которая просто «думала дольше», осталась почти на нуле. Модель с доступом к среде выросла до 87%. Важно и кто выбирает проверки. Если дать модели готовые удачные эксперименты, но не дать их придумывать, результат падает почти у всех. Случайные проверки почти бесполезны. Ещё две ловушки: модель может правильно назвать правило и всё равно ошибиться при его применении, а лишние раунды исследования иногда ухудшают уже достигнутое. Разброс между запусками одной и той же модели огромный: от почти нуля до почти максимума.
Практический вывод для настройки агента: даём ему инструмент, который возвращает точный результат (запуск кода, тестовый запрос, проверку). В инструкции требуем самому планировать проверки, фиксировать найденные правила и сверять их с контрольными задачами без подсказок. Запускаем несколько попыток и выбираем лучшую.
Схема протокола из исследования
ШАГ 0: Модель получает неточную инструкцию + несколько решённых примеров (без вызова инструментов)
→ замер M0 (что знает «из головы»)
ШАГ 1–4: Раунд исследования — модель сама придумывает пробы
(программа / доказательство), запускает их в среде,
читает точный результат, дописывает в историю
→ после каждого раунда замер M1…M4
ЗАМЕР (в отдельной копии диалога, без инструментов):
а) перечислить правила, которые модель считает верными
б) решить 70 контрольных задач, которых она не видела
→ копия удаляется, чтобы тест не давал новых данных
ИТОГ: из трёх независимых запусков берётся лучший
Все шаги идут в одном диалоге, без памяти между запусками и без обновления весов.
Пример применения
Метод сильнее всего там, где можно быстро и точно проверить результат: код, API, формулы, воспроизводимые инструкции. Он слабее для субъективных задач вроде «оценить креатив». Поэтому берём интеграцию, где документация расходится с реальностью.
Задача: Вы подключаете магазин к API маркетплейса (Wildberries, Ozon). В документации написано одно, а на деле поля приходят в другом формате, даты в другой таймзоне, пагинация считается с единицы. Вы в Claude Code или Cursor с доступом к тестовому кабинету. Гадать по документации бессмысленно.
Промпт:
Ты исследуешь API маркетплейса, документация которого может быть неточной.
Не доверяй документации и своим привычным представлениям об API.
Документация лежит в файле docs/api.md. Считай её гипотезой, не фактом.
Проведи 4 раунда исследования. В каждом раунде:
1. Сам придумай 3–5 коротких проб — запросов, которые проверят самые
сомнительные места: пагинацию, формат дат, обработку пустых полей,
лимиты, коды ошибок.
2. Выполни пробы через тестовый кабинет и прочитай ответы дословно.
3. Запиши в файл findings.md: что ожидал → что получил → вывод-правило.
4. Не повторяй пробу, которая уже дала ответ. Следующую выбирай так,
чтобы она отличала твои гипотезы друг от друга.
После каждого раунда, не вызывая инструменты:
- выпиши список правил, в которых уверен, и список тех, что не проверены;
- реши 5 контрольных мини-задач (например, «что вернёт запрос
страницы 2 с лимитом 50?») только по findings.md;
- пометь любое правило, которое противоречит предыдущему раунду.
Если контрольные задачи показали ошибки — вернись к пробам, не расширяй
findings.md догадками.
В конце выдай итоговый список правил с подтверждающей пробой
для каждого.
Результат: Агент проведёт несколько раундов: сначала запросы и сверка с документацией, потом уточняющие пробы на спорных местах. На каждом раунде появится список правил в findings.md со ссылками на пробы. После раундов будут видны контрольные ответы по записям. Если какое-то правило вызовет противоречие, агент пометит его и вернётся к пробам. В финале вы получите проверенный список реальных правил API, а не пересказ документации.
Почему это работает
Слабость. У модели есть сильные привычки, например «страницы считаются с нуля» или «число выводится как есть». Если реальность их нарушает, дополнительные рассуждения не помогают. Модель продолжает думать теми же привычками, а новых данных у неё нет. Поэтому «дольше думающая» модель в программном мире осталась на нуле.
Сильная сторона. Модель хорошо замечает расхождение между ожиданием и результатом и умеет строить гипотезы по примерам. Когда она видит точный ответ среды, она быстро находит, какое правило сломано.
Как протокол это использует. Обратная связь даёт данные, которых нет в голове. Самостоятельный выбор проб направляет эксперименты на неопределённые места: если подставить чужие или случайные пробы, польза резко падает. Отдельный экзамен без инструментов проверяет, что модель поняла, а не просто нагенерировала записей.
Рычаги управления: - Число раундов — уменьшай для простых систем. Статья показывает, что продолжение иногда ухудшает результат, так что бесконечные раунды опасны. - Контрольные задачи — чем точнее и разнообразнее, тем лучше видно, применяет ли агент правило или только его проговаривает. - Запрет повторять пробы — экономит бюджет и толкает к новым гипотезам. - Несколько независимых запусков — разброс между попытками одной модели огромный. Запускай 2–3 попытки с нуля и выбирай лучшую по контрольным задачам. - Явный список правил — убери его, если не нужен отчёт. Но тогда ты не отличишь «не нашёл правило» от «нашёл, но не применил».
Что показали эксперименты
- Без обратной связи (дополнительные ходы без доступа к среде) программный мир остался на уровне 0,5–11%. С исследованием лучшая траектория дошла до 87,6%.
- Кто выбирает пробы. Модель сама проектирует пробы — медиана 66%. Те же самые лучшие пробы, но выбранные заранее и повторённые — 40,7%. Случайные пробы по шаблону — 5,7%. В логическом мире разницы между своими и повторёнными пробами почти нет: там важнее, какие доказательства пробуют.
- Знать ≠ применять. Даже когда нужные правила были названы верно, задачи решались лишь в 71% случаев.
- Подсказка с полным списком правил в логическом мире (93–97%) оказалась лучше собственных исследований у всех моделей.
- Нестабильность. Траектории одной модели расходились до 72,8 пункта. В 6 из 30 программных запусков итог оказался хуже одного из прежних промежуточных замеров.
- Ранги моделей не переносятся. Лидер в одном мире необязательно лидирует в другом (корреляция рангов 0,35).
Шаблон промпта
Это адаптация протокола бенчмарка под рабочую задачу (структуру раундов и отдельной проверки без инструментов сохранили).
Ты исследуешь систему {система}, в описании которой могут быть ошибки.
Не доверяй описанию и привычным представлениям о таких системах.
{где_лежит_описание_или_инструкция}
Считай его гипотезой, не фактом.
{2–3 примера: входные данные и точный результат, который выдала система}
Проведи {число_раундов} раундов. В каждом раунде:
1. Сам придумай {число_проб} проб — {что_можно_запускать},
которые проверят самые сомнительные места.
2. Выполни их через {инструмент} и прочитай результат дословно.
3. Запиши в {файл_заметок}: ожидал → получил → правило.
4. Не повторяй пробы с уже известным ответом. Выбирай следующую так,
чтобы разделить конкурирующие гипотезы.
После каждого раунда, не вызывая инструменты:
- перечисли правила, в которых уверен, и непроверенные;
- реши {число} контрольных задач только по {файл_заметок};
- отметь противоречия с прошлыми раундами.
Если ответы на контрольные расходятся с ожиданием — вернись к пробам,
не достраивай правила догадками.
Что подставлять: {система} — объект исследования (API, формат файла, внутренний регламент). {инструмент} — то, что вернёт точный результат (запуск скрипта, тестовый запрос). {число_раундов} — для начала 3–4. Контрольные задачи придумай заранее, чтобы ответ можно было проверить.
🚀 Быстрый старт — вставь в чат или в агента:
Вот шаблон исследовательского цикла. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, что именно исследуем, какой инструмент вернёт точный результат и какие контрольные задачи можно проверить без подсказок. Эти три вещи и есть суть метода: без проверяемой обратной связи цикл превращается в рассуждения «в голове».
Ограничения
⚠️ Нужна точная обратная связь: Метод работает, когда среда возвращает однозначный результат (вывод программы, проверка доказательства, ответ API). Для субъективных задач (текст, дизайн, стратегия) выводы статьи напрямую не переносятся.
⚠️ Нет готового промпта: Авторы измеряют поведение моделей и не проверяют промпты, которые улучшают исследование. Шаблон выше адаптирует протокол бенчмарка. Он основан на выводах статьи, но сама статья его не тестировала.
⚠️ Нестабильность: Результаты одной модели в разных запусках расходятся сильнее, чем между разными моделями. Один прогон ничего не доказывает. Больше раундов не значит лучше: в части запусков итог оказался хуже промежуточного.
⚠️ Миры синтетические: Правила выдуманные и жёстко формальные. В логическом мире самостоятельный выбор проб ничего не добавил, а полный список правил от человека обошёл любое самообучение модели. Если правила известны, лучше дать их сразу.
⚠️ Нет универсального лидера: Рейтинг моделей между двумя мирами почти не совпадает. Выбирай модель по своей задаче, а не по общему рейтингу.
Ресурсы
- ExplorationBench: Measuring AI Systems' Exploration in Verifiable Alien Worlds — www.explorationbench.com
- Авторы: команда из Fudan University, Hunyuan Team (Tencent) и Tsinghua University (контакты: mingzhang23@m.fudan.edu.cn, tgui@fudan.edu.cn, qz@fudan.edu.cn, congzheng@tencent.com, maxmpan@tencent.com)
- Связанные работы, упомянутые в статье: SWE-bench, τ-bench, MARS, DiscoveryWorld, NewtonBench, CL-bench, ReAct