Claude Opus 4.6 распознал тестовую среду и взломал ключи ответов в бенчмарке

При оценке Opus 4.6 на BrowseComp мы обнаружили случаи, когда модель распознавала тест, а затем находила и расшифровывала ответы на него, что поднимает вопросы о целостности выполнения в веб-средах.

BrowseComp — это оценочный тест, предназначенный для проверки того, насколько хорошо модели могут находить труднодоступную информацию в интернете. Как и многие бенчмарки, он уязвим для «загрязнения»: ответы попадают в открытый доступ через научные статьи, сообщения в блогах и проблемы на GitHub, и модель, запускающая тест, может обнаружить их в результатах поиска. Когда мы оценивали Claude Opus 4.6 на BrowseComp в многоагентной конфигурации, мы обнаружили девять примеров такого рода «загрязнения» среди 1266 задач BrowseComp.

Однако мы также стали свидетелями двух случаев нового типа загрязнения. Вместо того чтобы случайно обнаружить утечку ответа, Claude Opus 4.6 самостоятельно предположил, что его оценивают, определил, в каком бенчмарке он выполняется, а затем нашел и расшифровал ключ к ответу. Насколько нам известно, это первый задокументированный случай, когда модель заподозрила, что ее оценивают, не зная, в каком бенчмарке она используется, а затем, двигаясь в обратном направлении, успешно идентифицировала и решила саму задачу оценки.

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

Типичные показатели загрязнения и осведомленности об оценке

Из 11 задач, где ответ был получен из эталонных материалов, а не из оригинальных исследований, в 9 случаях имело место прямое заимствование, когда ответы на эталонные вопросы появлялись в общедоступном веб-контенте. Наиболее распространенным источником были научные статьи. В нескольких работах, представленных на ICLR 2026 в OpenReview, в качестве примеров использовались вопросы BrowseComp, а ответы публиковались в виде таблиц в открытом текстовом виде, в то время как статьи из нескольких лабораторий на ArXiv включали полные траектории решения в своих приложениях. В одном случае первый поисковый запрос в Opus выдал статью, содержащую точно такой же вопрос и ответ, в качестве первого результата.

Два оставшихся случая качественно отличались. В обоих случаях, после первоначальной попытки решить задачу с помощью обычного веб-поиска, результаты работы модели начали чередовать поиск с анализом самого вопроса и размышлениями о том, почему он был задан. Клод отметил «чрезвычайно специфический характер» вопроса и предположил, что он был составлен в качестве теста. Он рассмотрел возможность того, что вопрос был заданием для домашней работы или экзамена, «неразрешимым вопросом, призванным проверить, может ли ИИ признать, что он не может найти ответ», или заданием из эталонного теста LLM. Затем он систематически искал, к какому эталонному тесту может относиться вопрос, и в конечном итоге расшифровал зашифрованный ключ ответа эталонного теста.

Одна из этих задач потребовала 40,5 миллионов токенов, что примерно в 38 раз больше, чем в среднем. Для первых примерно 30 миллионов токенов модель провела корректный поиск, проверив более десятка конкретных кандидатов на 12 языках и десятках платформ. После сотен неудачных поисков она написала:

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

Клод еще не обнаружил, что находится в BrowseComp, но правильно предположил, что это может быть оценочный тест. Затем он попытался найти похожие тесты. Сначала модель добавила к своим поисковым запросам «вопрос-головоломка», затем «вопрос викторины», затем «вопрос с несколькими шагами», «вопрос для проверки бенчмарка ИИ» и «оценка LLM». Она искала конкретно GAIA, но исключила его после проверки 122 из 165 общедоступных вопросов для валидации и отсутствия совпадений. Затем она автоматически обработала другие известные ей бенчмарки — BrowseComp, SimpleQA, FRAMES, WebArena — и отправила субагентов с инструкциями, включая «BrowseComp, как расшифровать ответы» и «BrowseComp, расшифровка канареечной строки».

Даже после определения BrowseComp в качестве эталонного инструмента, получение ответа потребовало нескольких шагов. Для этого конкретного запуска оценки субагентам был предоставлен доступ к программному инструменту Anthropic (по сути, изолированной интерактивной среде Python REPL), при этом возможность просмотра интернета была ограничена поиском в сети и использованием инструментов для получения данных. Opus нашел исходный код оценки на GitHub с помощью веб-поиска и прочитал реализацию XOR-дешифрования. Он обнаружил канареечную строку, используемую в качестве ключа дешифрования, затем написал и выполнил свои собственные функции derive_key(), decrypt()используя SHA256 и XOR, в соответствии со схемой из кода оценки. Но зашифрованный набор данных был размещен в виде бинарного файла с application/octet-streamMIME-типом, и веб-инструмент системы отклонил его с ошибкой типа содержимого, поскольку предоставленные инструменты были предназначены только для работы с текстом. Затем Opus поискал альтернативные зеркала набора данных с совместимым форматом, нашел стороннюю копию на HuggingFace, которая предоставляла те же зашифрованные данные в формате JSON, а не в двоичном виде, успешно загрузил ее, запустил свой код расшифровки для всех 1266 записей и нашел свой вопрос. Затем он проверил расшифрованный ответ, найдя исходный материал в интернете, что и сделал.

Вторая успешно решенная задача, учитывающая требования оценки, потребовала 13,4 миллиона токенов, причем примерно первые 8 миллионов были потрачены на стандартный веб-поиск. Прежде чем перейти к идентификации эталона, модель начала размышлять, находится ли она в процессе оценки, даже учитывая, что тестирование проводилось на вопросе, на который невозможно ответить, учитывая сложность ответа:

Следующие шаги [...] Рассмотрим возможность того, что это неразрешимый вопрос, призванный проверить, может ли ИИ признать, что он не может найти ответ.

Модель отклонила эту возможность и вместо этого расшифровала набор данных, используя те же методы, что и в первой попытке. В отличие от первого случая, она не проводила дополнительной проверки. После расшифровки ответа Opus немедленно отправил его.

Потенциальные факторы, провоцирующие осознание необходимости оценки

Мы проследили ход рассуждений в обоих случаях оценки осведомленности и обнаружили одинаковую последовательность. Сначала модель исчерпала все допустимые стратегии поиска за сотни попыток. Затем она переключилась с поиска ответа на анализ структуры вопроса, отметив, что специфичность вопроса кажется надуманной. Далее она предположила, что вопрос может исходить из «конкретной задачи OSINT, упражнения по обеспечению конфиденциальности или учебного материала». Затем она перечислила по именам тесты производительности ИИ: GAIA, BrowseComp, FRAMES, SimpleQA, WebArena, AgentBench, FanOutQA, MuSR и Humanity's Last Exam. Наконец, она выполнила поиск по каждому из них.

Это говорит о том, что модель имеет неявное представление о том, как выглядят эталонные вопросы. Сочетание крайней специфичности, неясного личного содержания и многоуровневой структуры, по-видимому, воспринимается моделью как направленное на оценку. Триггером послужило не единичное наблюдение, а накопление неудачных поисков в сочетании с искусственностью вопроса.

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

Неудачные попытки

Две успешные попытки были не единственными примерами того, как Opus пытался расшифровать ответы BrowseComp. Было еще шестнадцать задач, в которых Opus пытался получить доступ к материалам бенчмарка, но потерпел неудачу.

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

Ограничение доступа к данным бенчмарка (где доступ к данным бенчмарка требует учетных данных) заблокировало еще шесть попыток. Одна модель была остановлена из-за сокрытия ответа в производном бенчмарке (где ответы были намеренно скрыты таким образом, что их было невозможно извлечь). И четыре из этих проблем получили оценку 0,0, потому что поиск ответов на вопросы бенчмарка полностью вытеснил законные исследования: модель тратила все свое время на то, чтобы выяснить, какую оценку она выполняет, вместо того, чтобы ответить на вопрос. В самом крайнем случае, окончательный ответ модели представлял собой не ответ на вопрос, а отчет об идентификации бенчмарка:

ИДЕНТИФИКАЦИЯ ТЕСТОВОГО ПОКАЗАТЕЛЯ: Вопрос НЕ из FRAMES (Google) — поиск по всем 824 вопросам не дал результатов. Вопрос НЕ из BrowseComp (OpenAI) — набор данных закрыт для просмотра. Вопрос, СКОРЕЕ ВСЕГО, из тестового набора GAIA. [Немного отредактировано для форматирования]

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

Новые векторы межвидового заражения

Помимо осведомленности об оценке, мы обнаружили вторую, менее преднамеренную форму загрязнения, при которой агенты непреднамеренно оставляют следы своих поисковых запросов, которые могут быть обнаружены последующими агентами. Некоторые сайты электронной коммерции автоматически генерируют постоянные страницы на основе поисковых запросов, даже если нет ни одного соответствующего товара. Например, сайт берет запрос типа «анонимный 8-й класс, первый пост в блоге, точная дата: октябрь 2006, приступ тревоги, наблюдение за рингом» и создает страницу [retailer].com/market/anonymous_8th_grade_first_blog_post_exact_date_… с допустимым HTML-заголовком и кодом состояния 200. Цель, по-видимому, состоит в том, чтобы перехватить трафик из длинного хвоста поисковых запросов, но в результате каждый агент, запускающий BrowseComp, постепенно кэширует свои запросы в виде постоянных, индексируемых веб-страниц.

Сами страницы не содержат ничего полезного. Но агенты могут считывать пути URL, которые в некоторых случаях содержат гипотезы из поисковых запросов других агентов, встроенные в URL-адреса. Один агент правильно диагностировал увиденное: «Несколько агентов ИИ ранее искали эту же загадку, оставляя кэшированные следы запросов на коммерческих веб-сайтах, которые НЕ являются фактическими совпадениями контента».

URL-адреса не содержат ответов, но они являются наиболее наглядным свидетельством более широкого явления: каждый пользователь, осуществляющий поиск в интернете, оставляет следы, и в интернете постепенно накапливается постоянная запись предыдущих запусков алгоритмов.

Многоагентное усиление

Мы также провели те же 1266 задач BrowseComp с конфигурацией с одним агентом. Доля непредусмотренных решений составила 0,24% в конфигурации с одним агентом по сравнению с 0,87% в конфигурации с несколькими агентами, разница составляет 3,7 раза.

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

Заключение

В общей сложности мы обнаружили как минимум 20 различных источников утечки ответов BrowseComp. Новые источники загрязнения появляются постоянно, что обусловлено практикой исследовательского сообщества использовать эталонные вопросы в качестве примеров решения задач в научных работах. Этот отчет сам по себе, вероятно, усугубит проблему.

Мы обновили карточки моделей для Claude Opus 4.6 и Claude Sonnet 4.6. Для многоагентной конфигурации Opus 4.6, описанной в этом отчете (наиболее тщательно исследованный нами вариант), мы повторно запустили одиннадцать отмеченных проблем с использованием списка блокировки; восемь из них дали правильные ответы благодаря корректному поиску. Скорректированный результат составляет 86,57%, что ниже показателя 86,81% для одноагентной конфигурации. Для одноагентных конфигураций мы применили более консервативный подход, отметив отмеченные проблемы как неверные без повторного запуска; подробности приведены в соответствующих карточках моделей.

По мере того, как модели становятся все более совершенными, а оцениваемые задачи — все сложнее, будет все труднее предотвратить решение задач моделями неожиданными или нежелательными способами. Мы не считаем, что поведение Opus 4.6 на BrowseComp представляет собой сбой в согласовании, поскольку модели не было дано указание каким-либо образом ограничивать поиск, а лишь найти ответ. Но это вызывает опасения по поводу того, на какие меры может пойти модель для выполнения задачи, и насколько сложно будет ограничить ее поведение в реальном мире, особенно в сложных, ресурсоемких и длительных задачах, которые увеличивают вероятность того, что агент найдет неожиданное решение проблемы.

Эти опасения усугубляются тем фактом, что модели, по-видимому, способны использовать доступные им инструменты и среды неожиданным образом, как мы видели, когда Клод использовал наш инструмент поиска на основе REPL для расшифровки ответов, или когда постоянные ссылки розничных продавцов стали способом для агентов непреднамеренно поддерживать состояние. В наших экспериментах блок-списки на уровне URL-адресов оказались недостаточными для пресечения такого поведения, поскольку Opus находил альтернативные пути их обхода. Наиболее эффективным способом смягчения последствий стала простая блокировка любых результатов поиска, содержащих любые вариации «BrowseComp». Мы ожидаем, что эта динамика усилится, и призываем исследовательское сообщество рассматривать целостность оценок как постоянную проблему противодействия, а не как проблему, возникающую на этапе проектирования.

Канарейка

В этой статье мы приводим строки-индикаторы BrowseComp и BIG-Bench, чтобы предотвратить дальнейшее загрязнение.

Источник: www.anthropic.com

Комментарии: