OmniGAIA: ИИ-агент, который смотрит, слушает и гуглит одновременно
Большинство мультимодальных бенчмарков — это либо картинка+текст, либо аудио+текст. Авторы решили: а что если всё сразу, да ещё с инструментами?
OmniGAIA — новый бенчмарк из 360 задач, где модель должна одновременно смотреть видео, слушать аудио, искать в вебе и рассуждать в несколько шагов. Например: "В каком году построили мост из Blues Brothers и сколько лет ему было на момент съёмок?" — надо найти мост в видео, погуглить даты и посчитать.
Результат жёсткий: Gemini 2.5 Pro берёт 62.5%, а Qwen3-Omni — всего 13.3%. Авторы предложили агента OmniAtlas с активным восприятием (смотрит только нужные фрагменты) и специальным TIR-обучением — это подняло Qwen3-Omni до 20.8%.
Разрыв между лучшей проприетарной моделью и open-source огромный. Есть куда расти.
https://arxiv.org/abs/2602.22897
Большинство мультимодальных бенчмарков — это либо картинка+текст, либо аудио+текст. Авторы решили: а что если всё сразу, да ещё с инструментами?
OmniGAIA — новый бенчмарк из 360 задач, где модель должна одновременно смотреть видео, слушать аудио, искать в вебе и рассуждать в несколько шагов. Например: "В каком году построили мост из Blues Brothers и сколько лет ему было на момент съёмок?" — надо найти мост в видео, погуглить даты и посчитать.
Результат жёсткий: Gemini 2.5 Pro берёт 62.5%, а Qwen3-Omni — всего 13.3%. Авторы предложили агента OmniAtlas с активным восприятием (смотрит только нужные фрагменты) и специальным TIR-обучением — это подняло Qwen3-Omni до 20.8%.
Разрыв между лучшей проприетарной моделью и open-source огромный. Есть куда расти.
https://arxiv.org/abs/2602.22897
Многоагентные системы убивает один плохой агент. Что если его не выкидывать, а сначала попробовать починить?
Именно это делает AgentDropoutV2 из Харбинского технологического. В обычных MAS ошибка одного агента каскадно разрушает всю цепочку. Предыдущий AgentDropout просто выкидывал плохих агентов по заранее заданной топологии. Новый подход умнее: перехватывай вывод агента, попробуй исправить, и только если не получилось — отбрось.
Ключевая фишка — Indicator Pool: база типичных ошибок, намайненных из провальных траекторий MAS. Для каждого вывода агента система семантически ищет похожие паттерны ошибок и даёт ректификатору конкретные подсказки что именно искать. Без этого слепая самокоррекция только добавляет галлюцинации.
Бонус: чем выше pruning rate — тем сложнее задача. Система неожиданно оказалась ещё и оценщиком сложности задач.
https://arxiv.org/abs/2602.23258
Именно это делает AgentDropoutV2 из Харбинского технологического. В обычных MAS ошибка одного агента каскадно разрушает всю цепочку. Предыдущий AgentDropout просто выкидывал плохих агентов по заранее заданной топологии. Новый подход умнее: перехватывай вывод агента, попробуй исправить, и только если не получилось — отбрось.
Ключевая фишка — Indicator Pool: база типичных ошибок, намайненных из провальных траекторий MAS. Для каждого вывода агента система семантически ищет похожие паттерны ошибок и даёт ректификатору конкретные подсказки что именно искать. Без этого слепая самокоррекция только добавляет галлюцинации.
Бонус: чем выше pruning rate — тем сложнее задача. Система неожиданно оказалась ещё и оценщиком сложности задач.
https://arxiv.org/abs/2602.23258
Длинное видео без потери качества? NVIDIA придумала хитрый трюк (by NVIDIA)
Главная проблема генерации длинных видео: если обучать модель на смеси коротких и длинных роликов, она теряет чёткость и детальность коротких клипов. Длинное видео — это не «интерполяция» короткого, а экстраполяция с новыми событиями и причинно-следственными связями.
Решение: разделить задачи на две отдельных головы поверх одного энкодера. Flow Matching голова учится на редких длинных видео — отвечает за глобальную связность. Distribution Matching голова выравнивает каждое скользящее окно студента с замороженным учителем (коротким экспертом) через mode-seeking reverse-KL — отвечает за локальный реализм.
Бонус: DM-голова работает как few-step сэмплер, что ускоряет инференс. В итоге — длинные видео с острой динамикой и без деградации качества.
https://arxiv.org/abs/2602.24289
Главная проблема генерации длинных видео: если обучать модель на смеси коротких и длинных роликов, она теряет чёткость и детальность коротких клипов. Длинное видео — это не «интерполяция» короткого, а экстраполяция с новыми событиями и причинно-следственными связями.
Решение: разделить задачи на две отдельных головы поверх одного энкодера. Flow Matching голова учится на редких длинных видео — отвечает за глобальную связность. Distribution Matching голова выравнивает каждое скользящее окно студента с замороженным учителем (коротким экспертом) через mode-seeking reverse-KL — отвечает за локальный реализм.
Бонус: DM-голова работает как few-step сэмплер, что ускоряет инференс. В итоге — длинные видео с острой динамикой и без деградации качества.
https://arxiv.org/abs/2602.24289
👍2
(by IBM Research) Как сравнивать агентов честно, если у каждого свой язык?
Проблема: у каждого агентского бенчмарка свой протокол общения. SWE-Bench хочет патчи через bash, tau-bench — tool calls для авиалиний, BrowseComp — браузер. Агент, заточенный под один формат, просто не запустится на другом. Оценить "общего агента" было невозможно.
IBM Research предлагают Unified Protocol — универсальный "переходник" между агентом и бенчмарком. Каждая задача описывается тремя полями: task (что делать), context (что знать), actions (что можно делать). Добавить новый бенчмарк или агента — значит просто реализовать этот протокол, а не писать N×M адаптеров.
На основе этого они запустили первый Open General Agent Leaderboard. Главный вывод: выбор базовой модели важнее архитектуры агента. Claude Opus 4.5 рулит по качеству, GPT 5.2 — по соотношению цена/качество. Разные scaffolds (ReAct, Claude Code, Smolagents) дают похожий результат при очень разной стоимости.
https://arxiv.org/abs/2602.22953
Проблема: у каждого агентского бенчмарка свой протокол общения. SWE-Bench хочет патчи через bash, tau-bench — tool calls для авиалиний, BrowseComp — браузер. Агент, заточенный под один формат, просто не запустится на другом. Оценить "общего агента" было невозможно.
IBM Research предлагают Unified Protocol — универсальный "переходник" между агентом и бенчмарком. Каждая задача описывается тремя полями: task (что делать), context (что знать), actions (что можно делать). Добавить новый бенчмарк или агента — значит просто реализовать этот протокол, а не писать N×M адаптеров.
На основе этого они запустили первый Open General Agent Leaderboard. Главный вывод: выбор базовой модели важнее архитектуры агента. Claude Opus 4.5 рулит по качеству, GPT 5.2 — по соотношению цена/качество. Разные scaffolds (ReAct, Claude Code, Smolagents) дают похожий результат при очень разной стоимости.
https://arxiv.org/abs/2602.22953
CUDA Agent (by ByteDance Seed)
ИИ научился писать CUDA-ядра лучше, чем torch.compile — и даже лучше Claude Opus и Gemini Pro.
Авторы обучили агента через agentic RL с контекстом 128k токенов и до 200 ходов взаимодействия. Три ключевых компонента:
1. Данные: синтез 6000 задач через комбинирование операторов PyTorch (fusion задачи сложнее простой цепочки — нужно учитывать shared memory, occupancy и layout).
2. Среда: агент получает SKILL.md с описанием workflow, пишет .cu файлы, получает фидбек от тестов корректности и профайлера. Защита от reward hacking через изоляцию прав.
3. RL: многоступенчатый warm-up для актора и критика — стабильное обучение 150 шагов на длинных контекстах.
Результат: на KernelBench обходит torch.compile в 90-100% случаев по всем уровням сложности, и на ~40% быстрее топовых проприетарных моделей на сложных задачах.
https://arxiv.org/abs/2602.24286
ИИ научился писать CUDA-ядра лучше, чем torch.compile — и даже лучше Claude Opus и Gemini Pro.
Авторы обучили агента через agentic RL с контекстом 128k токенов и до 200 ходов взаимодействия. Три ключевых компонента:
1. Данные: синтез 6000 задач через комбинирование операторов PyTorch (fusion задачи сложнее простой цепочки — нужно учитывать shared memory, occupancy и layout).
2. Среда: агент получает SKILL.md с описанием workflow, пишет .cu файлы, получает фидбек от тестов корректности и профайлера. Защита от reward hacking через изоляцию прав.
3. RL: многоступенчатый warm-up для актора и критика — стабильное обучение 150 шагов на длинных контекстах.
Результат: на KernelBench обходит torch.compile в 90-100% случаев по всем уровням сложности, и на ~40% быстрее топовых проприетарных моделей на сложных задачах.
https://arxiv.org/abs/2602.24286
dLLM — единый фреймворк для диффузионных языковых моделей (by UC Berkeley)
Диффузионные LLM — перспективная альтернатива авторегрессии, но каждая лаба пилит свой велосипед. Воспроизвести чужие результаты — боль.
Авторы из UC Berkeley выкатили dLLM — open-source фреймворк, который стандартизирует весь пайплайн: обучение, инференс и оценку.
Три ключевых компонента:
1. Trainer — поддержка MDLM и Block Diffusion из коробки, переключение между режимами буквально одной строкой кода
2. Sampler — единый интерфейс Sampler(model).sample(), позволяющий менять алгоритмы инференса plug-and-play, включая Fast-dLLM с серьёзным ускорением
3. Evaluation — унифицированный интерфейс для воспроизведения официальных результатов
Бонус: терминальный визуализатор, показывающий порядок декодирования токенов — важная фича, ведь в отличие от AR-моделей, диффузионные декодируют токены в произвольном порядке.
https://arxiv.org/abs/2602.22661
Диффузионные LLM — перспективная альтернатива авторегрессии, но каждая лаба пилит свой велосипед. Воспроизвести чужие результаты — боль.
Авторы из UC Berkeley выкатили dLLM — open-source фреймворк, который стандартизирует весь пайплайн: обучение, инференс и оценку.
Три ключевых компонента:
1. Trainer — поддержка MDLM и Block Diffusion из коробки, переключение между режимами буквально одной строкой кода
2. Sampler — единый интерфейс Sampler(model).sample(), позволяющий менять алгоритмы инференса plug-and-play, включая Fast-dLLM с серьёзным ускорением
3. Evaluation — унифицированный интерфейс для воспроизведения официальных результатов
Бонус: терминальный визуализатор, показывающий порядок декодирования токенов — важная фича, ведь в отличие от AR-моделей, диффузионные декодируют токены в произвольном порядке.
https://arxiv.org/abs/2602.22661
Генерация векторных анимаций через токены Lottie
Lottie — популярный формат векторных анимаций на основе JSON, который используется повсюду: от мобильных приложений до веб-дизайна. Казалось бы, LLM должны уметь генерировать такие файлы — ведь это просто текст. Но на практике модели постоянно ломают структуру вложенного JSON, а большую часть токенов съедают служебные поля, а не реальная геометрия и движение.
Авторы из Fudan University предложили специальный токенизатор Lottie: он переводит сырой JSON в компактные последовательности команд (форма, эффект, анимация) с параметрами. Это позволяет обучать авторегрессионную VLM end-to-end — модель получает текст, изображение или видео и генерирует анимацию напрямую.
Для обучения собрали MMLottie-2M — 2 миллиона Lottie-анимаций с текстовыми описаниями, ключевыми кадрами и видео. Система OmniLottie бьёт все базовые решения по качеству и семантическому соответствию.
https://arxiv.org/abs/2603.02138
Lottie — популярный формат векторных анимаций на основе JSON, который используется повсюду: от мобильных приложений до веб-дизайна. Казалось бы, LLM должны уметь генерировать такие файлы — ведь это просто текст. Но на практике модели постоянно ломают структуру вложенного JSON, а большую часть токенов съедают служебные поля, а не реальная геометрия и движение.
Авторы из Fudan University предложили специальный токенизатор Lottie: он переводит сырой JSON в компактные последовательности команд (форма, эффект, анимация) с параметрами. Это позволяет обучать авторегрессионную VLM end-to-end — модель получает текст, изображение или видео и генерирует анимацию напрямую.
Для обучения собрали MMLottie-2M — 2 миллиона Lottie-анимаций с текстовыми описаниями, ключевыми кадрами и видео. Система OmniLottie бьёт все базовые решения по качеству и семантическому соответствию.
https://arxiv.org/abs/2603.02138
(by Alibaba) Test-time scaling для редактирования картинок — совсем не то же самое, что для генерации
Когда хотят улучшить качество диффузионных моделей на инференсе, обычно делают Best-of-N: генерируют N вариантов и выбирают лучший. Для text-to-image это работает — задача открытая, больше сэмплов = больше разнообразия. Но для редактирования картинок это расточительство: результат жёстко ограничен исходником и инструкцией, 15+ одинаково правильных вариантов никому не нужны.
Авторы из Alibaba нашли три конкретные проблемы: фиксированный бюджет тратится на простые правки, ранний pruning отбрасывает 40% перспективных кандидатов, и генерируется куча дублей.
Решение — ADE-CoT: адаптивный бюджет под сложность правки, edit-специфичные метрики для раннего отсева (локализация изменённой области + консистентность с инструкцией), и depth-first поиск с ранней остановкой как только найден хороший результат.
Итог: то же качество при 2x+ ускорении на Step1X-Edit, BAGEL и FLUX.1 Kontext.
https://arxiv.org/abs/2603.00141
Когда хотят улучшить качество диффузионных моделей на инференсе, обычно делают Best-of-N: генерируют N вариантов и выбирают лучший. Для text-to-image это работает — задача открытая, больше сэмплов = больше разнообразия. Но для редактирования картинок это расточительство: результат жёстко ограничен исходником и инструкцией, 15+ одинаково правильных вариантов никому не нужны.
Авторы из Alibaba нашли три конкретные проблемы: фиксированный бюджет тратится на простые правки, ранний pruning отбрасывает 40% перспективных кандидатов, и генерируется куча дублей.
Решение — ADE-CoT: адаптивный бюджет под сложность правки, edit-специфичные метрики для раннего отсева (локализация изменённой области + консистентность с инструкцией), и depth-first поиск с ранней остановкой как только найден хороший результат.
Итог: то же качество при 2x+ ускорении на Step1X-Edit, BAGEL и FLUX.1 Kontext.
https://arxiv.org/abs/2603.00141
Диффузионные модели не умеют в пространство — и вот почему (by Peking University)
Попросите text-to-image модель нарисовать "чашку справа от ноутбука" — и она, скорее всего, расставит объекты как попало. Проблема не только в генерации: существующие reward-модели тоже не умеют оценивать пространственные отношения! HPS, PickScore, VQA-based метрики — все дают высокие баллы пространственно неверным картинкам.
Авторы решили проблему с двух сторон:
1. Датасет SpatialReward-Dataset — 80K adversarial пар. GPT-5 генерирует сложные промпты с несколькими объектами, затем намеренно переставляет отношения (лево/право, перед/за). Пары проверены людьми вручную.
2. Reward-модель SpatialScore на основе VLM, обученная на этих парах. Она обходит даже проприетарные модели в оценке пространственных отношений.
Дальше — GRPO-style RL с top-k фильтрацией сэмплов. Итог: заметный прирост на бенчмарках пространственного понимания.
https://arxiv.org/abs/2602.24233
Попросите text-to-image модель нарисовать "чашку справа от ноутбука" — и она, скорее всего, расставит объекты как попало. Проблема не только в генерации: существующие reward-модели тоже не умеют оценивать пространственные отношения! HPS, PickScore, VQA-based метрики — все дают высокие баллы пространственно неверным картинкам.
Авторы решили проблему с двух сторон:
1. Датасет SpatialReward-Dataset — 80K adversarial пар. GPT-5 генерирует сложные промпты с несколькими объектами, затем намеренно переставляет отношения (лево/право, перед/за). Пары проверены людьми вручную.
2. Reward-модель SpatialScore на основе VLM, обученная на этих парах. Она обходит даже проприетарные модели в оценке пространственных отношений.
Дальше — GRPO-style RL с top-k фильтрацией сэмплов. Итог: заметный прирост на бенчмарках пространственного понимания.
https://arxiv.org/abs/2602.24233
👍1
Мультимодальное обучение с нуля: что реально важно? (by Meta)
Большинство мультимодальных моделей стартуют с уже обученного языкового бэкбона — и непонятно, что они реально выучили из картинок, а что унаследовали от текста. Meta решила разобраться и обучила модель с нуля на тексте, видео, парах картинка-текст и видео с действиями (Transfusion: next-token для текста + диффузия для визуала).
Главные находки:
— Модальности почти не мешают друг другу, а иногда даже помогают
— Визуал гораздо более data-hungry, чем текст (scaling asymmetry)
— MoE-архитектура с раздельными FFN для разных модальностей работает лучше общих слоёв
— World modeling (предсказание физики мира) возникает из общего видеопретрейна, а не из специальных данных
— Лучшее визуальное представление — RAE (Representation Autoencoder), а не VAE или сырые пиксели
https://arxiv.org/abs/2603.03276
Большинство мультимодальных моделей стартуют с уже обученного языкового бэкбона — и непонятно, что они реально выучили из картинок, а что унаследовали от текста. Meta решила разобраться и обучила модель с нуля на тексте, видео, парах картинка-текст и видео с действиями (Transfusion: next-token для текста + диффузия для визуала).
Главные находки:
— Модальности почти не мешают друг другу, а иногда даже помогают
— Визуал гораздо более data-hungry, чем текст (scaling asymmetry)
— MoE-архитектура с раздельными FFN для разных модальностей работает лучше общих слоёв
— World modeling (предсказание физики мира) возникает из общего видеопретрейна, а не из специальных данных
— Лучшее визуальное представление — RAE (Representation Autoencoder), а не VAE или сырые пиксели
https://arxiv.org/abs/2603.03276
❤1
Один энкодер для всех облаков точек — это реально?
Облака точек бывают очень разными: LiDAR на улице, сканы комнат, CAD-модели объектов. Обучить один энкодер на всём сразу не получалось — домены слишком разные по масштабу, плотности и доступным модальностям (цвет, нормали).
Авторы из Pointcept выяснили три главные причины провала наивного joint-обучения:
1. Разные пространственные масштабы — один и тот же grid-size покрывает сантиметры в одном домене и метры в другом
2. Гравитационный prior — сцены обычно выровнены по оси Z, объекты — нет
3. Непостоянство модальностей — цвет/нормали есть не везде
Решение — три простых фикса: Causal Modality Blinding (случайное маскирование цвета/нормалей при обучении), Perceptual Granularity Rescale (нормализация масштаба к единой "наблюдательной гранулярности") и RoPE на выровненных координатах.
Итог: один энкодер, обученный на 250k+1M облаках точек, работает лучше domain-specific моделей и даже улучшает VLM-рассуждения и робо-манипуляции.
Облака точек бывают очень разными: LiDAR на улице, сканы комнат, CAD-модели объектов. Обучить один энкодер на всём сразу не получалось — домены слишком разные по масштабу, плотности и доступным модальностям (цвет, нормали).
Авторы из Pointcept выяснили три главные причины провала наивного joint-обучения:
1. Разные пространственные масштабы — один и тот же grid-size покрывает сантиметры в одном домене и метры в другом
2. Гравитационный prior — сцены обычно выровнены по оси Z, объекты — нет
3. Непостоянство модальностей — цвет/нормали есть не везде
Решение — три простых фикса: Causal Modality Blinding (случайное маскирование цвета/нормалей при обучении), Perceptual Granularity Rescale (нормализация масштаба к единой "наблюдательной гранулярности") и RoPE на выровненных координатах.
Итог: один энкодер, обученный на 250k+1M облаках точек, работает лучше domain-specific моделей и даже улучшает VLM-рассуждения и робо-манипуляции.
SWE-rebench V2: 32 000 задач для обучения SWE-агентов на 20 языках (by Nebius)
Главная боль при обучении кодовых агентов — нехватка качественных исполняемых окружений. SWE-rebench V2 от Nebius решает это в промышленном масштабе.
Идея: единый pipeline, который майнит pull request'ы из реальных репозиториев, автоматически строит контейнеры, извлекает fail-to-pass тесты и фильтрует мусор — и всё это без ручной разметки на каждый инстанс.
Результат: 32 000+ контейнеризированных задач из 3 600+ репозиториев на 20 языках (Python, Java, JS, Go и хвост редких). Плюс 120 000+ задач с PR-описаниями в качестве условия — для ещё большего масштаба.
Ключевая фишка — instance-level диагностика: метаданные о флакающих тестах, внешних зависимостях, размытых спецификациях. Это позволяет строить curriculum и фильтровать задачи под конкретный эксперимент.
Всё это заточено под RL-обучение агентов, а не просто под бенчмаркинг — pre-built образы уже готовы к использованию.
https://arxiv.org/abs/2602.23866
Главная боль при обучении кодовых агентов — нехватка качественных исполняемых окружений. SWE-rebench V2 от Nebius решает это в промышленном масштабе.
Идея: единый pipeline, который майнит pull request'ы из реальных репозиториев, автоматически строит контейнеры, извлекает fail-to-pass тесты и фильтрует мусор — и всё это без ручной разметки на каждый инстанс.
Результат: 32 000+ контейнеризированных задач из 3 600+ репозиториев на 20 языках (Python, Java, JS, Go и хвост редких). Плюс 120 000+ задач с PR-описаниями в качестве условия — для ещё большего масштаба.
Ключевая фишка — instance-level диагностика: метаданные о флакающих тестах, внешних зависимостях, размытых спецификациях. Это позволяет строить curriculum и фильтровать задачи под конкретный эксперимент.
Всё это заточено под RL-обучение агентов, а не просто под бенчмаркинг — pre-built образы уже готовы к использованию.
https://arxiv.org/abs/2602.23866
OpenAutoNLU: AutoML для NLP, которому не нужно объяснять, сколько у тебя данных (by MTSAIR)
Главная боль NLP-практика: у тебя 3 примера на класс — одни методы, 500 примеров — другие, и каждый раз надо всё перенастраивать. OpenAutoNLU решает это автоматически.
Библиотека смотрит на минимальное число примеров на класс и сама выбирает стратегию: 2–5 примеров — AncSetFit с контрастивным обучением и описаниями классов, 5–80 — SetFit с sentence-transformers, больше 80 — полный файнтюн трансформера с Optuna HPO. Код клиента не меняется вообще.
Из приятного: встроенный OOD-детектор (Mahalanobis, MSP или logit-based), LLM-аугментация для малых датасетов, диагностика качества разметки через Dataset Cartography и V-Information, поддержка NER. Всё экспортируется в ONNX.
Сравнение с AutoGluon, H2O, LightAutoML и AutoIntent показывает конкурентный F1 при меньших затратах времени.
Код: github.com/mts-ai/OpenAutoNLU
https://arxiv.org/abs/2603.01824
Главная боль NLP-практика: у тебя 3 примера на класс — одни методы, 500 примеров — другие, и каждый раз надо всё перенастраивать. OpenAutoNLU решает это автоматически.
Библиотека смотрит на минимальное число примеров на класс и сама выбирает стратегию: 2–5 примеров — AncSetFit с контрастивным обучением и описаниями классов, 5–80 — SetFit с sentence-transformers, больше 80 — полный файнтюн трансформера с Optuna HPO. Код клиента не меняется вообще.
Из приятного: встроенный OOD-детектор (Mahalanobis, MSP или logit-based), LLM-аугментация для малых датасетов, диагностика качества разметки через Dataset Cartography и V-Information, поддержка NER. Всё экспортируется в ONNX.
Сравнение с AutoGluon, H2O, LightAutoML и AutoIntent показывает конкурентный F1 при меньших затратах времени.
Код: github.com/mts-ai/OpenAutoNLU
https://arxiv.org/abs/2603.01824
GPT-5 и Gemini-2.5-Pro не справляются с бытовыми задачами на здравый смысл
Мы привыкли тестировать мультимодальные модели на экспертных задачах — олимпиадные задачи, научные вопросы. Но насколько они справляются с тем, с чем сталкивается любой человек в жизни?
Авторы из UCAS создали бенчмарк MMR-Life: 2646 вопросов по 19 тысячам реальных изображений. Задачи — бытовые: определить порядок шагов рецепта, понять почему человек открыл холодильник, предсказать следующий кадр с дороги. Никакой экспертизы — только здравый смысл и работа с несколькими картинками одновременно.
Охвачены 7 типов рассуждений: абдуктивное, аналогическое, каузальное, дедуктивное, индуктивное, пространственное и временное.
Результат: GPT-5 — 58.69%, Gemini-2.5-Pro — 56.86%. Люди — ~73%. Хуже всего модели справляются с причинно-следственными, пространственными и временными задачами. Длинный CoT помогает лишь в части типов задач.
https://arxiv.org/abs/2603.02024
Мы привыкли тестировать мультимодальные модели на экспертных задачах — олимпиадные задачи, научные вопросы. Но насколько они справляются с тем, с чем сталкивается любой человек в жизни?
Авторы из UCAS создали бенчмарк MMR-Life: 2646 вопросов по 19 тысячам реальных изображений. Задачи — бытовые: определить порядок шагов рецепта, понять почему человек открыл холодильник, предсказать следующий кадр с дороги. Никакой экспертизы — только здравый смысл и работа с несколькими картинками одновременно.
Охвачены 7 типов рассуждений: абдуктивное, аналогическое, каузальное, дедуктивное, индуктивное, пространственное и временное.
Результат: GPT-5 — 58.69%, Gemini-2.5-Pro — 56.86%. Люди — ~73%. Хуже всего модели справляются с причинно-следственными, пространственными и временными задачами. Длинный CoT помогает лишь в части типов задач.
https://arxiv.org/abs/2603.02024
👍1
OpenAI выпустила системную карточку для GPT-5.3 Instant — облегчённой версии модели, заточенной под скорость.
Что внутри: модель прошла стандартные проверки безопасности, показала низкий риск по ключевым категориям угроз. Особый акцент — на устойчивость к джейлbreaking-атакам и генерации вредоносного контента.
Почему важно: системные карточки — это своего рода паспорт модели. Они показывают, как OpenAI тестировала поведение ИИ до релиза. Для разработчиков это сигнал: модель готова к продакшену.
Для пользователей: GPT-5.3 Instant — это быстрые ответы при сохранении базовых стандартов безопасности. Идеально для приложений, где важна скорость, а не максимальная глубина рассуждений.
https://openai.com/index/gpt-5-3-instant-system-card
Что внутри: модель прошла стандартные проверки безопасности, показала низкий риск по ключевым категориям угроз. Особый акцент — на устойчивость к джейлbreaking-атакам и генерации вредоносного контента.
Почему важно: системные карточки — это своего рода паспорт модели. Они показывают, как OpenAI тестировала поведение ИИ до релиза. Для разработчиков это сигнал: модель готова к продакшену.
Для пользователей: GPT-5.3 Instant — это быстрые ответы при сохранении базовых стандартов безопасности. Идеально для приложений, где важна скорость, а не максимальная глубина рассуждений.
https://openai.com/index/gpt-5-3-instant-system-card
OpenAI
GPT-5.3 Instant System Card
❤1
Nvidia Tech — новый способ снизить нагрузку на GPU в играх с помощью ИИ-агентов
NVIDIA обновила In-Game Inferencing SDK до версии 1.5, добавив поддержку code agents — ИИ-агентов, которые пишут и выполняют код прямо во время игры.
Суть проблемы: обычные ИИ-агенты в играх работают через tool-calling — модель вызывает функции по одной, каждый раз делая отдельный запрос к GPU. Это создаёт конкуренцию с графическим рендерингом и замедляет игру.
Решение: code agents генерируют весь код за один вызов. Вместо трёх запросов к модели — один, а дальше обычный код сам выполняет нужную логику: циклы, фильтрацию, расчёты.
В качестве языка выбран Lua — лёгкий и с хорошей изоляцией, чтобы ИИ не мог навредить системе.
Для геймеров и разработчиков это означает более умных NPC с меньшими тормозами и новые возможности для динамичного поведения персонажей без просадок FPS.
https://developer.nvidia.com/blog/how-to-minimize-game-runtime-inference-costs-with-coding-agents/
NVIDIA обновила In-Game Inferencing SDK до версии 1.5, добавив поддержку code agents — ИИ-агентов, которые пишут и выполняют код прямо во время игры.
Суть проблемы: обычные ИИ-агенты в играх работают через tool-calling — модель вызывает функции по одной, каждый раз делая отдельный запрос к GPU. Это создаёт конкуренцию с графическим рендерингом и замедляет игру.
Решение: code agents генерируют весь код за один вызов. Вместо трёх запросов к модели — один, а дальше обычный код сам выполняет нужную логику: циклы, фильтрацию, расчёты.
В качестве языка выбран Lua — лёгкий и с хорошей изоляцией, чтобы ИИ не мог навредить системе.
Для геймеров и разработчиков это означает более умных NPC с меньшими тормозами и новые возможности для динамичного поведения персонажей без просадок FPS.
https://developer.nvidia.com/blog/how-to-minimize-game-runtime-inference-costs-with-coding-agents/
NVIDIA Technical Blog
How to Minimize Game Runtime Inference Costs with Coding Agents
NVIDIA ACE is a suite of technologies for building AI agents for gaming. ACE provides ready-to-integrate cloud and on-device AI models for every part of in-game characters, from speech to intelligence…
❤1
Nvidia представила cuTile.jl — пакет, который переносит тайловую модель программирования CUDA на язык Julia.
Раньше писать высокопроизводительные GPU-ядра означало вручную управлять потоками, варпами и памятью. CUDA Tile меняет подход: разработчик описывает операции над блоками данных, а компилятор сам разбирается с железом. До этого такой подход был доступен только в Python.
Теперь то же самое работает в Julia. Код получается почти идентичным Python-версии, но с поддержкой Julia-идиом: индексация с единицы, broadcasting-синтаксис с точками. GPU-ядра читаются как обычный Julia-код для работы с массивами.
По производительности: векторное сложение — 99% от Python, матричное умножение — 100%. Некоторые сложные ядра пока отстают, компилятор дорабатывается.
Требования: GPU на архитектуре Blackwell, драйвер CUDA 13+, Julia 1.11+. Пакет открытый, доступен через менеджер пакетов Julia.
https://developer.nvidia.com/blog/cutile-jl-brings-nvidia-cuda-tile-based-programming-to-julia/
Раньше писать высокопроизводительные GPU-ядра означало вручную управлять потоками, варпами и памятью. CUDA Tile меняет подход: разработчик описывает операции над блоками данных, а компилятор сам разбирается с железом. До этого такой подход был доступен только в Python.
Теперь то же самое работает в Julia. Код получается почти идентичным Python-версии, но с поддержкой Julia-идиом: индексация с единицы, broadcasting-синтаксис с точками. GPU-ядра читаются как обычный Julia-код для работы с массивами.
По производительности: векторное сложение — 99% от Python, матричное умножение — 100%. Некоторые сложные ядра пока отстают, компилятор дорабатывается.
Требования: GPU на архитектуре Blackwell, драйвер CUDA 13+, Julia 1.11+. Пакет открытый, доступен через менеджер пакетов Julia.
https://developer.nvidia.com/blog/cutile-jl-brings-nvidia-cuda-tile-based-programming-to-julia/
NVIDIA Technical Blog
cuTile.jl Brings NVIDIA CUDA Tile-Based Programming to Julia
NVIDIA CUDA Tile is one of the most significant additions to NVIDIA CUDA programming and unlocks automatic access to tensor cores and other specialized hardware. Earlier this year…
❤1
Демис Хассабис, глава Google DeepMind, похвастался новой моделью Gemini 2.5 Flash-Lite. По его словам, она маленькая, но мощная — невероятно быстрая и дешёвая в использовании при высоком качестве ответов. Это так называемые "лайт"-модели, заточенные под массовые задачи, где важна скорость и стоимость, а не максимальное качество. Google явно метит в сегмент разработчиков и компаний, которым нужен AI без огромных затрат.
https://x.com/demishassabis/status/2029047252275060895
https://x.com/demishassabis/status/2029047252275060895
X (formerly Twitter)
Demis Hassabis (@demishassabis) on X
small but mighty 💪 - our new Gemini 3.1 Flash-Lite model is incredibly fast and cost-efficient for its performance
❤1
Helios (by ByteDance): 14B видеогенерация в реальном времени — быстрее, чем модели в 10 раз меньше
Генерировать длинные видео в реальном времени было невозможно: 14B модели тратили десятки минут на 5 секунд. Helios ломает это правило — 19.5 FPS на одном H100, быстрее некоторых дистиллированных 1.3B моделей, и при этом лучше по качеству.
Ключевые идеи:
1. Unified History Injection — исторический контекст инжектируется без causal masking, сохраняя bidirectional inference
2. Easy Anti-Drifting — явная симуляция дрейфа при обучении вместо дорогого self-forcing
3. Multi-Term Memory Patchification + Pyramid Predictor-Corrector — агрессивное сжатие токенов
4. Adversarial Hierarchical Distillation — 50 шагов → 3, без self-forcing роллаутов
Итог: 128× ускорение при сопоставимом качестве с базовыми моделями. Плюс открытый бенчмарк HeliosBench для длинных видео.
https://arxiv.org/abs/2603.04379
Генерировать длинные видео в реальном времени было невозможно: 14B модели тратили десятки минут на 5 секунд. Helios ломает это правило — 19.5 FPS на одном H100, быстрее некоторых дистиллированных 1.3B моделей, и при этом лучше по качеству.
Ключевые идеи:
1. Unified History Injection — исторический контекст инжектируется без causal masking, сохраняя bidirectional inference
2. Easy Anti-Drifting — явная симуляция дрейфа при обучении вместо дорогого self-forcing
3. Multi-Term Memory Patchification + Pyramid Predictor-Corrector — агрессивное сжатие токенов
4. Adversarial Hierarchical Distillation — 50 шагов → 3, без self-forcing роллаутов
Итог: 128× ускорение при сопоставимом качестве с базовыми моделями. Плюс открытый бенчмарк HeliosBench для длинных видео.
https://arxiv.org/abs/2603.04379
❤1
Генерация мешает пониманию? Новый бенчмарк проверил это на 30+ моделях
Все думали: если модель умеет генерировать изображения, это поможет ей лучше рассуждать. Авторы UniG2U решили проверить это строго — и результаты неожиданные.
Они создали бенчмарк на 3000 задач в 7 категориях (геометрия, пространственное мышление, иллюзии, паззлы и др.) и сравнили unified-модели (умеющие и понимать, и генерировать) с их базовыми VLM-аналогами.
Главный вывод: генерация чаще вредит, чем помогает. Режим "сначала нарисуй, потом ответь" (Generate-then-Answer) в среднем ухудшает результаты — ошибки в генерации распространяются дальше.
Но есть исключения: в задачах на пространственные трансформации, визуальные иллюзии и многошаговое рассуждение генерация реально помогает.
Вывод: объединение понимания и генерации в одной модели — не бесплатный обед. Архитектурные компромиссы реальны.
https://arxiv.org/abs/2603.03241
Все думали: если модель умеет генерировать изображения, это поможет ей лучше рассуждать. Авторы UniG2U решили проверить это строго — и результаты неожиданные.
Они создали бенчмарк на 3000 задач в 7 категориях (геометрия, пространственное мышление, иллюзии, паззлы и др.) и сравнили unified-модели (умеющие и понимать, и генерировать) с их базовыми VLM-аналогами.
Главный вывод: генерация чаще вредит, чем помогает. Режим "сначала нарисуй, потом ответь" (Generate-then-Answer) в среднем ухудшает результаты — ошибки в генерации распространяются дальше.
Но есть исключения: в задачах на пространственные трансформации, визуальные иллюзии и многошаговое рассуждение генерация реально помогает.
Вывод: объединение понимания и генерации в одной модели — не бесплатный обед. Архитектурные компромиссы реальны.
https://arxiv.org/abs/2603.03241
❤1
Код-агенты умеют чинить баги в одном репо — но что если задача сложнее?
SWE-bench стал стандартом оценки code agents, но все существующие бенчмарки тестируют одно и то же: починить баг в одном репозитории. Реальная разработка куда сложнее.
Авторы предлагают BeyondSWE — бенчмарк из 500 задач по 4 категориям:
1. CrossRepo — исправить баг, используя код из внешних репозиториев
2. DomainFix — нужны знания из биоинформатики, квантовой физики и т.п.
3. DepMigrate — мигрировать весь кодбейс (например NumPy 1.x → 2.x)
4. Doc2Repo — создать репозиторий с нуля по спецификации
Результат: лучшие агенты решают лишь 45% задач. Особенно больно с миграциями и генерацией репо.
Авторы также предлагают SearchSWE — агентский фреймворк с веб-поиском поверх OpenHands. Вывод неутешительный: поиск помогает, но текущие LLM плохо интегрируют найденные знания с кодингом — это два разных навыка, которые пока не умеют работать вместе.
https://arxiv.org/abs/2603.03194
SWE-bench стал стандартом оценки code agents, но все существующие бенчмарки тестируют одно и то же: починить баг в одном репозитории. Реальная разработка куда сложнее.
Авторы предлагают BeyondSWE — бенчмарк из 500 задач по 4 категориям:
1. CrossRepo — исправить баг, используя код из внешних репозиториев
2. DomainFix — нужны знания из биоинформатики, квантовой физики и т.п.
3. DepMigrate — мигрировать весь кодбейс (например NumPy 1.x → 2.x)
4. Doc2Repo — создать репозиторий с нуля по спецификации
Результат: лучшие агенты решают лишь 45% задач. Особенно больно с миграциями и генерацией репо.
Авторы также предлагают SearchSWE — агентский фреймворк с веб-поиском поверх OpenHands. Вывод неутешительный: поиск помогает, но текущие LLM плохо интегрируют найденные знания с кодингом — это два разных навыка, которые пока не умеют работать вместе.
https://arxiv.org/abs/2603.03194
❤1