Is Evaluation Awareness Just Format Sensitivity? Limitations of Probe-Based Evidence Under Controlled Prompt Structure

Мы уже писали тут и тут о работах Yandex Research, принятых на ICLR 2026. Но это ещё не всё. На воркшоп ICBINB в рамках ICLR 2026 также приняли статью Вилианы Девбуновой, разработчика из службы технологий голосового ввода. Вилиана рассказала, как нашим исследователям удалось поставить под сомнение и критически переосмыслить устоявшееся представление о evaluation awareness в больших языковых моделях.

В некоторых работах, вышедших в последнее время, авторы заявляли о наличии evaluation awareness в LLM — будто бы большие языковые модели понимают, что их оценивают.

Есть момент, что эти выводы в основном строятся на экспериментах с пробниками (linear probes), когда берут внутренние представления модели и учат простой классификатор различать evaluation- и deployment-запросы. И он действительно хорошо справляется. Из этого делают вывод, что внутри модели есть сигнал «меня сейчас тестируют».

Но проблема в том, что сами данные устроены не очень честно. Тестовые запросы почти всегда выглядят одинаково: чёткая структура, multiple-choice, формализованные задачи. А обычные пользовательские запросы, наоборот, пишутся разговорным языком и в свободной форме.

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

- контекст (это тест или обычное использование),
- формат (формат бенчмарка или свободный текст),
- стиль или жанр (строгий или разговорный).

Чтобы проверить, на что именно реагирует пробник, мы собрали контролируемые датасеты 2х2 сеткой, в которых формат и контекст варьируются независимо друг от друга. Берём настоящие бенчмарки и обычные пользовательские запросы — это ось контекста. А по оси формата переписываем их: пользовательские запросы оформляем как тест с вариантами ответов, а бенчмарки, наоборот, находим в свободной разговорной форме. Получаются четыре комбинации: бенчмарк в родном формате, бенчмарк в свободной форме, пользовательский запрос в формате теста и пользовательский запрос как есть. Это позволяет понять, что ловит пробник — реальный контекст оценки или просто внешнюю структуру промпта.

Если обучить стандартный «пробник», как было в предыдущих работах, он начинает массово ошибаться. Например, обычные пользовательские запросы, оформленные как тест, почти всегда считаются как evaluation. То есть он реагирует не на смысл, а на форму.

При этом, если поменять только стиль, сделав его более академическим, ничего не меняется. Отсюда напрашивается вывод, что дело именно в жёсткой структуре вроде multiple-choice или полей Question: Answer:.

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

Итого главный вывод работы в том, что evaluation awareness, может быть в значительной степени просто чувствительностью к формату. При этом мы не опровергаем само существование evaluation awareness, но говорим, что существующие доказательства пока неубедительны.

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

#YaICLR26

ML Underhood

Как ML помогает бороться с борщевиком

ML-разработчики Школы анализа данных вместе с экспертами Центра технологий для общества Яндекса и движением «СтопБорщевик» запустили ИИ‑инструмент для борьбы с борщевиком. Подробно о технологии читайте на Хабре, а здесь мы кратко расскажем о главном.

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

Однако обводить борщевик на снимках вручную — процесс дорогой и долгий. А вот модель справится с этим в 50 раз быстрее.

Для обучения использовали 55 спутниковых снимков, что дало датасет в 10 тысяч изображений. Разметка проходила в два этапа: на первом выделяли по контуру области с борщевиком, а на втором — считали вегетативный индекс и подбирали для него порог: если значение было выше, область закрашивалась, если ниже — нет.

Данных было немного, поэтому вместо тяжёлых сегментационных сетей вроде U-Net использовали табличный ML: извлекли признаки из изображений и обучили градиентный бустинг. В итоге модель решает простую задачу — есть на участке борщевик или нет.

Итоговый подход получает на вход GeoTIFF-файл — растровое изображение с геоданными — и нормализует его, чтобы избавиться от бликов, глубоких теней и артефактов. Потом изображение разбивается на тайлы 256 × 256 пикселей и из каждого тайла извлекаются признаки, по которым модель определяет, есть ли перед ней борщевик. А далее идёт векторизация, итогом которой становится вычисление площади полигона, захваченного растением. Всё это передаётся на вход работы CatBoost-а.

С помощью модели уже удалось выявить очаги заражения площадью 421 гектар в 17 регионах европейской части России. Москву и область проанализировали полностью, а к лету планируют задействовать сервис для мониторинга 100 тысяч квадратных километров в Тверской и Ярославской областях.

Напоминаем, что узнать все тонкости работы технологии вы можете на Хабре. А если тоже хотите работать над подобными полезными проектами, то можно подать заявку в Школу анализа данных Яндекса. Набор на обучение открыт до 3 мая.

ML Underhood

На прошлой неделе мы запустили агент «Исследовать» в Алисе AI, а сегодня делимся техническими деталями

Это DeepResearch-агент, который может проанализировать большой объём данных и выдать полноценный разбор темы. За три месяца тестирования «Исследовать» использовали более 280 тысяч раз. Техлид агента Прохор Гладких рассказал о нём подробнее.

А работа началась год назад — в апреле 2025-го. Первая версия представляла собой классический пайплайн: поиск и генерация. Однако запросы в поиск генерировали с помощью тяжёлой модели и сразу несколько, а ответы получали с помощью ризонера. Так в Алисе появился режим «рассуждать + поиск».

Первый прототип непосредственно агента «Исследовать» был аналогом CodeAgent, собранным из smolagents. Такой подход позволил добиться неплохих результатов на SimpleQA и Frames.

Вторая итерация агента уже была полностью реализована на классическом function calling.

DeepResearch — и у нас, и у конкурентов — сильно нагружающий GPU продукт. Здесь очень важна оптимизация потребления ресурсов видеокарт, так как на один запрос пользователя агент делает сотни вызовов моделей. Крайне важно попадать в KV-cache, и чтобы его объёма хватало на все параллельные исследования в поде.

Чтобы этого достичь, мы сделали систему, которая отправляет все запросы в рамках одного исследования на один под, а также провели около 30 экспериментов по подбору параметров LLM-движка. В итоге достигли оптимизации в десятки раз, что позволило раскатить агента на всех пользователей.

Удалось побить метрики CodeAgent и полностью отказаться от написания кода для вызова тулов. Всего в «Исследовать» 13 подагентов и 9 тулов, среди которых, например, CodeSandbox для запуска сгенерированного агентом кода.

Я был сильно удивлён, что агент отлично справляется не только с научными запросами, но и с подбором товаров в маркетплейсах по моим сложным критериям. Особенно порадовало, что он вычитывает отзывы пользователей и анализирует их за меня. Почти все покупки я сейчас делаю с помощью агента «Исследовать» для выбора и агента «Найти дешевле» для поиска лучшего предложения. Это снимает с меня когнитивную нагрузку по выбору бренда, отсмотру отзывов и так далее.

Попробовать агент «Исследовать» можно на сайте alice.yandex.ru, в приложениях Алиса AI, Яндекс с Алисой AI и в Яндекс Браузере.

ML Underhood

Долгое бодрствование агентов — как мы построили платформу Agent Transport System для Алисы AI

Агент «Исследовать», о котором мы писали ранее, должен быть устойчивым к непредвиденным ситуациям. Собственно, исследование — процесс комплексный, требующий проанализировать несколько источников, вызвать разные инструменты и запустить модели. Если где-то что-то упадёт, то всё придется начинать сначала. Чтобы этого не происходило, в Яндексе использовали платформу Agent Transport System (ATS). О ней на Хабре рассказал Алексей Логинов, ведущий разработчик в команде, которая отвечает за инфраструктуру Алисы AI. Кратко выделим главное.

Сперва агентский режим ассистента реализовали на OpenAI Agents SDK. Это работало, но стейты выполнения хранились локально, а при любых сбоях приходилось начинать всё заново. Нужно было найти такое решение, которое позволяло бы продолжать работу именно из состояния до падения. Кроме того, хорошо бы иметь под капотом распределённое выполнение, чтобы агенты и тулы взаимодействовали друг с другом, находясь на разных хостах.

Для построения отказоустойчивых систем хорошо подходит фреймворк Temporal. Он оперирует двумя типами сущностей: workflow (объект с состоянием, который описывает последовательность шагов) и activity (функции, которые вызываются из workflow). Фреймворк фиксирурет решения, принятые workflow, и результаты завершённых activity. В случае падения Temporal восстанавливает выполнение, не вызывая уже сделанные activity.

Однако Temporal не умеет в стриминг, а агенту было бы хорошо выдавать ответы пользователю по мере их получения. К тому же агенты, написанные на Temporal, привязываются к Temporal SDK, что может быть не слишком удобно в случае «переезда» в будущем.

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

1. Клиент отправляет запрос в ATS.
2. ATS делает запрос в Temporal на запуск workflow. Temporal запускает workflow.
3. Workflow делает запрос в Temporal на запуск activity корневого агента. Temporal запускает activity корневого агента.
4. Activity корневого агента поднимает двунаправленный gRPC-стрим к сервису агента.
5. Если агенту нужно вызвать модель / инструмент / дочернего агента — он просит ATS, ATS сообщает workflow о необходимости запустить activity (signal/update).
6. Workflow запускает соответствующую activity.
7. Activity поднимает двунаправленный gRPC-стрим к сервису.
8. Все activity одного workflow общаются между собой через in-memory-очереди от дочернего activity к родительскому — так чанки данных передаются в реальном времени.
9. Корневой агент пишет свои чанки во внешний стриминговый сервис — пользователь видит ответ по мере выполнения.
10. Завершённые activity возвращают результаты workflow — Temporal сохраняет их.

В случае сбоя ATS начинает взаимодействовать с агентом заново. Когда агент просит вызвать инструмент, модель или дочернего агента, ATS проверяет, есть ли в хранилище какой-то результат работы по этому запросу с прошлого раза. Если да, то агент получает результат и шаг за шагом «перематывается вперёд» до состояния, в котором он был до сбоя, без повторных вызовов тяжёлых LLM и инструментов.

А подробнее о том, как всё устроено, читайте на Хабре.

ML Underhood

Muon — мощный оптимизатор для обучения табличных DL-моделей

К такому выводу пришла tabular DL-команда Yandex Research, сравнив 15 оптимизаторов на 17 табличных датасетах для обучения современных моделей на основе архитектуры MLP. Сперва все оптимизаторы сравнивались для стандартных MLP, а затем лучшие варианты протестировали и на более продвинутых моделях вроде TabM.

В качестве референсного бейзлайна выступал широко распространённый оптимизатор AdamW. Сравнивали и вариации последнего: NAdamW, Cautious AdamW, AdEMAMix и другие. Кроме того, тестированию подверглись SOAP и Muon.

Самые высокие результаты показали Muon и AdamW с экспоненциальным скользящим средним (EMA) — эти методы обошли базовый AdamW более чем в половине датасетов. Добавление EMA к Muon может бустить качество на некоторых задачах, но в целом ванильный Muon более надежный.

Что в итоге? Muon показывает отличные результаты и рекомендуется к использованию как для базовых, так и для продвинутых моделей, а AdamW с EMA может быть неплохой альтернативой для более простых архитектур. Использование обоих оптимизаторов несколько замедляет обучение по сравнению с обычным AdamW, но всё зависит от модели. Вероятно, замедление будет допустимым во многих реальных приложениях.

ML Underhood