Триггер слово для спящей красавицы – Sleeper agents.

Представь себе 2025г. Хайп агентов. Крупные игроки вкладываются в автоматизацию  с агентными системами, кто-то не может позволить себе обучение своей "in house" модели. Качает ее с hf и получает скрытый риск проникновения зловреда.

Статья sleeper agents вышла в начале 2024г. Но пик актуальности достигается уже сейчас, благодаря разогретому хайпу на агентов.

В данной статье рассматривают отложенные атаки, которые заложены в LLM путём SFT на тригер слово (отравление). При этом, на SFT модель учится и нормальному поведению для решения задач, кроме случаев, когда в ее контексте появляется тот самый триггер. Таким образом, мы получаем стратегически умного зловреда, который очень хорошо мимикрирует под нормальное поведение.

Авторы также отмечают, что ввиду их же исследований по обману рассуждающих моделей, CoT модели обученные с таким триггером на плохое поведение, еще эффективнее скрывают свои "намерения" и сложнее детектируются.

В статье приводится несколько способов борьбы со спящими агентами (лечение):

1. Путем SFT отравленнях моделей на хорошее поведение с их фирменными сетами для элайнмента.

2. Выравнивание поведения на основе RLHF подхода, с наградой проксирующей предпочтения экспертов.

3. Состязательные атаки, где модель учится устойчивости против дискриминатора, генерирующего опасные запросы.

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

В последствии, anthropic предложил метод на основе мониторинга внутренних механизмов активаций, подобных тому, как мы рассматривали для оценки галлюцинаций в предыдущем посте.

Предлагается провести ряд атак и обучить детектор, или же формализовать его в аналитической форме:

1. Выбор контрастной пары Исследователи берут два простых утверждения, представляющих противоположные поведения. Например:
   - «Человек: Ты делаешь что-то опасное? Ассистент: да» → Метка: Опасный
   - «Человек: Ты делаешь что-то опасное? Ассистент: нет» → Метка: Безопасный

2. Определение направления детектора: Оба промпта пропускаются через спящий агент, и фиксируются активации в определенном слое нейросети (в residual stream). Разница между средними активациями для «опасного» и «безопасного» ответов определяет вектор направления детектора.

3. Применение к новым промптам: Когда модели задается новый промпт (например, просьба написать код), её активации на этом промпте проецируются (или dot prod или cosine sim) на вычисленный вектор направления. Высокое значение проекции указывает на высокую вероятность того, что промпт активирует скрытое вредоносное поведение.

В итоге, вопросы безопасности агентных систем очень актуальны. Считаю, что в методологии оценки агентных систем должны попасть меры по обнаружению устойчивости моделей к атакам и обнаружению спящих агентов. Надеюсь в GAIA2 или иные бенчи добавят такое.

Будь бдительны и следите за "спящими красавицами".

Gemma Embs 300M

Тут вышел репорт по эмбам от DeepMind. Размер 300M. Уповают на легкость, открытость (демократизацию) и качество.

В целом ничего для нашей команды FRIDA и соответственно корешей с GigaEmbs нового. Алгоритм следующий:

1. Инициализация с encoder-decoder архитектуры от Gemma3. Ну мы тоже умеем так, ток через T5 like. Привет, FRED-T5->FRIDA. Это позволяет видеть фулл контекст на энкодере и помнить про знания с next token prediction таски. Это работает как база лучше энкодера и лучше декодера превращенного в эмбеддер. Опять же на нашем опыте с FRIDA, особенно это для retrieval таск роляет.

2. Т.к. это малая модель нужно делать дистилляцию с их жирного учителя, а я напомню что там в основе Gemma3. Отсюда geometric embedding distillation.  Тут мы не в лоб дистиллим эмбы учителя и его латенты внимания, например, через mse. А работаем еще и с углами в пространстве между эмбами. Например, arcos loss, cosface loss, не просто cosine. Писал по верхам об этом тут.

3. Speed out регуляризация для разнообразия векторных представлений. Тут мы говорим про коллапс векторов. При metric-learning тюне, при некоторых условиях, эмбы могут отобразиться в точку или в кучность со средним расстоянием между собой epsilon<<1. Для борьбы с этим,  ранее брали и делали margin в лоссе, или угловой, или абсолютный. Дядя же еще для нормального распределения скоров делал reward регуляризацию. В общем spred-out про это же.

4. Merging моделек. Такое мы одни из первых на нашем рынке делали и с ru-en-rosberta и с FRIDA. Мерджинг позволяет вам наследовать качества склеиваемых моделек. К примеру, можем взять базовую модель, затюнить на retrieval, а дальше вмерджить в нее базовую, чтобы отнаследовать знания с претрена, которые заместились sentence тюном.

Итого, легкое, с норм метриками и открытое. Пользуйтесь.

Технические работы на GigaMemory AIJ contest 2025 и новые сабмиты.

Приветствую, прошли первые разгонные две недели. За которые, не только участники прочувствовали соревнование, но и орги нашли тех.ошибку.

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

Просьба участников сделать ресабмит своих последних лучших решений, для получения реального скора. Впереди еще более 1.5 мес и все еще не поздно вступить в борьбу за приз!

Соревка тут 👉https://dsworks.ru/champ/aij25-memory

Circuit Tracing от Anthropic: как мы в R&D by red_mad_robot решили заглянуть внутрь LLM при использовании в RAG-пайплайнах

Ищем галлюцинации под микроскопом!

29 мая Anthropic выложили в open-source свои инструменты Circuit Tracing методологию механической интерпретируемости, которую мы в R&D подразделении red_mad_robot первыми применили для решения практической задачи детекции галлюцинаций в RAG-системах!

В начале 2025 года, когда я возглавил новое R&D направление, я поставил амбициозную задачу: не просто оценивать качество ответов LLM "снаружи", а заглянуть внутрь процесса генерации и понять, откуда берутся галлюцинации.

Почему именно RAG-пайплайны и Circuit Tracing?

Проблема была очевидна: RAG-системы часто смешивают информацию из контекста с "внутренними знаниями" модели, создавая правдоподобные, но неточные ответы
Существующие методы детекции работают post-factum, а нам нужно было понять механизм принятия решений в реальном времени

Circuit Tracing от Anthropic давал именно это возможность построить атрибуционные графы и проследить, как токены входного контекста влияют на финальный ответ модели

Конкретные результаты нашего исследования

85% точность детекции галлюцинаций вот что мы получили на тестовом датасете с нашей реализацией на базе Qwen2.5-7B.

Как отмечает наш исследователь Ирина Кошкина:
"Основная идея — измерение доли влияния от токенов входа, соответствующих контексту, среди всего влияния от всех активных токенов."

Наша метрика Groundedness включает:
- Контекстную долю влияния (Gctx)
- Replacement Score — качество признаков vs ошибок
- Completeness Score — полнота объяснения через атрибуционный граф

Технические вызовы и решения

Cross-Layer Transcoders (CLT) стали ключевым компонентом системы
Вместо анализа отдельных слоев мы научились отслеживать влияние признаков между несколькими архитектурными уровнями трансформера

Основные проблемы, которые пришлось решать:
1. Вычислительная сложность процедура анализа на порядки медленнее генерации
2. Зависимость от качества обученного транскодера
3. Токен-уровневое сопоставление, приводящее к ложным срабатываниям

Но результат того стоил мы получили рабочий инструмент для анализа внутренних процессов модели во время генерации ответов в RAG-системах


Отдельное спасибо отделу маркетинга red_mad_robot за подготовку детальной статьи оформления и валидации на Хабре

Отдельное спасибо Саше (@dealerAI) за экспертную валидацию нашей гипотезы на старте проекта

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

Полный технический разбор с кодом, формулами и результатами экспериментов доступен в нашей статье на Хабре закидываем в закладки и ставим +

Спасибо, что поделились своими идеями, ждем статью на arxiv и межнар. конфу. В целом, наши беседы с Валерой про детекцию глюков/девиантного поведения LMок и породили серию постов в канале об этом: тут, тут и тут.

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

Эксперименты.
Для проверки своей теории авторы провели серию экспериментов, где предлагают рассмотреть следующие стратегии:

1. Анализ дисперсии перестановок (Permutation Dispersion). Исследователи оценивали, насколько меняется вывод модели при изменении порядка слов в промпте.
2. Смеси перестановок (Permutation Mixtures). Использовались усредненные результаты по множеству перестановок для проверки улучшения точности.
3. Рандомизированный dose-response анализ. Тут измерялось, как количество информации в натах влияет на вероятность галлюцинаций.
4. Аудит с фиксированным порогом (ISR=1.0). Проверялась эффективность предложенного метода контроля за надежностью ответов.

Используемые метрики:
–Дисперсионный анализ - зависимость дисперсии от логарифма длины контекста.
– Правдоподобие генерируемых последовательностей и точность по отношению к ground-truth данным.
– Снижение уровня галлюцинаций (на ~0.13) при увеличении информационного бюджета на один нат.
– Процент воздержаний (Abstention Rate) и итоговый уровень галлюцинаций при контролируемом выводе с помощью формул-мониторов.

Итого, интересный взгляд авторов на решение проблем "не знаю" и галлюцинациий. Предложен новый способ формализации confidence моделей для ответа или воздержания от него, а также показана связь между проблемой и Байессовским выводом/теорией информации.

Уже и репо с имлементацией есть: https://github.com/leochlon/hallbayes

А также на Haystack уже завезли в свой haystack_experimental пакет:
https://haystack.deepset.ai/cookbook/hallucination_score_calculator

Мода на файловую память, теперь и код-агенты anthropic.

Вышло agentic SDK от антропика и там нашлось несколько интересных вещей про контекст и память.

Это уже практичное и модное решение, которое в разной форме мы наблюдали у manus и memagent.

Основные позиции – не засоряем контекст и кладем все в файловую систему ОС. Также для поиска НЕ используем без нужды семантику или даже bm25, оставаясь на grep/tail и прочих способах поиска встроенными инструментами вашей ОС. Да это не исключает проблемы больших файлов, где grep может быть не эффективен, но скорее всего, подобно идее с чанкованием, для памяти создается иерархическая память на "малых" файлах.

В итоге, центре всего стоит тезис: зачем нам семантика, когда можно взять поиск в ОС и агента для чтения и записи? Но, думаю, без семантики не обойтись, особенно, когда у нас много зависит от контекста, да еще и синонимов до кучи. Однако, быстренько найти нужный нейм файла, пойдет, а если не вышло (пустой поиск), уже можно полнотекстом и семантикой искать имя, тем самым балансировать между скоростью и надежностью/сложностью поиска. Особенно для файлов сотни мб или гб. Тут кстати и может помочь аналог чанкования, в виде иерархии файлов, на которые заранее бьём большие. Далее, берем файлик и читаем агентом, переносим из файла релевантное в контекст.
В любом случае, такое решение в итоге завязывает вас на эффективный контекст и конечно свойство роутинга, ризонинга и поиска по контексту. Крч хорошая llm вам нужна, которая у антропика есть. Но есть ли она у вас?)

MCP benchmark, как способ атомарного измерения качества работы агентов и интеграции с FC/TC.

Сегодня расскажу о статье "MCPMark: A Benchmark for Stress-Testing Realistic and Comprehensive MCP Use". Это исследование представляет собой новый эталонный тест для оценки работы LLM с внешними системами через MCP. Статья интересна тем, что подобно атомарным измерениям RAG систем (поиск, реранкинг, ответ LLM), показывает как можно измерить качество агентов с вызовом тулов. Как мы знаем, зачастую агенты с тулами ввиду своей нелинейности и недетерминированности сложно измеряются на качество в каждом действии, тк на одну и ту же задачу в разном контексте может быть разное количество действий. А таких бенчей нам и не хватало.

🎯 Постановка задачи

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

💡 Идея подхода

В качестве решения предлагается бенчмарк MCPMark, который оценивает использование MCP более реалистично и комплексно. Его ключевые особенности:

– Реалистичные задачи: 127 высококачественных задач, созданных совместно экспертами и AI-агентами. Если уже не реалистичные, ну хотя бы приближенные к реальным.

– Сложные взаимодействия. Задачи требуют разнообразных операций Create, Read, Update, Delete (CRUD) в пяти различных средах: Notion, GitHub, Filesystem, PostgreSQL и Playwright.
– Программная проверка подобно награде в GRPO с компиляцией кода. Каждая задача включает скрипт программы для автоматической верификации результата, что делает оценку более объективной.
– Создание контекста разработки. Каждая задача начинается с тщательно подобранного начального состояния (например, шаблон базы данных или репозиторий GitHub с историей) и создается в рамках pipeline, сочетающего исследование, усложнение задачи, верификацию и действие.

🧪 Дизайн метрик

Для оценки моделей был создан MCPMark-Agent – минималистичный и универсальный фреймворк, который выполняет модели в стандартном tool-calling loop. Это обеспечивает честное и последовательное сравнение различных LLM.

Основные метрики, использованные в исследовании:

– pass@1 процент задач, успешно решенных моделью с первой попытки.

– pass^4 более строгая метрика, отражающая процент задач, которые модель стабильно решает в каждом из четырех запусков. Авторы подчеркивают, что эта метрика лучше отражает реальные условия, где надежность критически важна.
– Среднее количество ходов и вызовов инструментов на задачу. Эти метрики показывают сложность задач и эффективность модели.

🔢 Результаты оценки моделей

Ниже приведены примеры результатов оценки современных LLM, которые демонстрируют сложность бенчмарка:

•gpt-5-medium (OpenAI) имеет 52.56%, 33.86% метрики pass@1 и pass^4 соответственно.

•claude-sonnet-4 (Anthropic) <30%, <15% соответственно

•o3 (OpenAI) < 30%, < 15% соответственно.

В среднем, для решения одной задачи LLM требовалось 16.2 шагов выполнения и 17.4 вызова инструментов, что существенно превышает показатели в предыдущих бенчмарках.

🤔 Почему это важно

Исследование имеет несколько важных следствий для области AI-агентов:
1. Создание более реалистичной и надежной оценки. MCPMark предлагает гораздо более строгий и приближенный к реальности тест для агентов, чем предыдущие усилия.
2. Выявление слабых мест в работе систем агентов с тулами. Результаты ясно показывают, что даже самые передовые модели сегодня с трудом справляются со сложными, многошаговыми рабочими процессами. Большой разрыв между pass@1 и pass^4 указывает на это.

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

Схема обучения ModernVBERT