Статьи Yandex Research на грядущей ICLR — 1/2
Интересный факт: в фильме «Бразилия» не очень-то много о Бразилии. Зато о ней будет в нашем канале, когда мы возьмёмся освещать конференцию ICLR 2026. Она пройдёт уже в апреле в Рио-де-Жанейро. Туда отправляются исследователи Yandex Research — и не с пустыми руками, а с целой пачкой в шесть статей. Сперва расскажем о первых трёх.
Bridging the Gap Between Promise and Performance for Microscaling FP4 Quantization
Авторы статьи — Денис Кузнеделев из Yandex Research и коллеги из ISTA, Red Hat AI и ETH Zürich. Они детально изучили представленные компанией NVIDIA форматы хранения весов и активаций (MXFP4, NVFP4) для квантования после обучения, чтобы понять, насколько заявленные преимущества соответствуют реальной производительности.
Анализ показал, что современные методы сталкиваются с трудностями при работе с FP4. Причины:
— привычные способы борьбы с выбросами (нетипичными значениями) не работают;
— при квантовании MXFP4 возникает ошибка.
В работе предложена улучшенная версия алгоритма квантования GPTQ. Она учитывает особенности FP4 и заметно повышает точность по сравнению с предыдущими методами. Кроме того, разработаны быстрые ядра для инференса.
Scale-wise Distillation of Diffusion Models
А это статья уже полностью от Yandex Research — Никиты Стародубцева, Дениса Кузнеделева, Артёма Бабенко и Дмитрия Баранчука. Авторы предлагают новый подход к помасштабной дистилляции диффузионных моделей — дообучать генерации изображений прогрессивно, от низкого разрешения к высокому. Это позволяет добиться более высокого качества, чем во время генерации с фиксированным разрешением при том же вычислительном бюджете.
Nesterov Finds GRAAL: Optimal and Adaptive Gradient Method for Convex Optimization
Авторы статьи — Екатерина Бородич и Дмитрий Ковалев из Yandex Research — разработали ускоренный по Нестерову и не требующий подбора гиперпараметров градиентный метод, который автоматически адаптирует размер шага к локальной кривизне целевой функции с линейной (геометрической) скоростью. Эффективность алгоритма подтвердили, доказав, что он даёт оптимальную скорость сходимости для выпуклых задач оптимизации в условиях обобщенной гладкости.
#YaICLR26
ML Underhood
Интересный факт: в фильме «Бразилия» не очень-то много о Бразилии. Зато о ней будет в нашем канале, когда мы возьмёмся освещать конференцию ICLR 2026. Она пройдёт уже в апреле в Рио-де-Жанейро. Туда отправляются исследователи Yandex Research — и не с пустыми руками, а с целой пачкой в шесть статей. Сперва расскажем о первых трёх.
Bridging the Gap Between Promise and Performance for Microscaling FP4 Quantization
Авторы статьи — Денис Кузнеделев из Yandex Research и коллеги из ISTA, Red Hat AI и ETH Zürich. Они детально изучили представленные компанией NVIDIA форматы хранения весов и активаций (MXFP4, NVFP4) для квантования после обучения, чтобы понять, насколько заявленные преимущества соответствуют реальной производительности.
Анализ показал, что современные методы сталкиваются с трудностями при работе с FP4. Причины:
— привычные способы борьбы с выбросами (нетипичными значениями) не работают;
— при квантовании MXFP4 возникает ошибка.
В работе предложена улучшенная версия алгоритма квантования GPTQ. Она учитывает особенности FP4 и заметно повышает точность по сравнению с предыдущими методами. Кроме того, разработаны быстрые ядра для инференса.
Scale-wise Distillation of Diffusion Models
А это статья уже полностью от Yandex Research — Никиты Стародубцева, Дениса Кузнеделева, Артёма Бабенко и Дмитрия Баранчука. Авторы предлагают новый подход к помасштабной дистилляции диффузионных моделей — дообучать генерации изображений прогрессивно, от низкого разрешения к высокому. Это позволяет добиться более высокого качества, чем во время генерации с фиксированным разрешением при том же вычислительном бюджете.
Nesterov Finds GRAAL: Optimal and Adaptive Gradient Method for Convex Optimization
Авторы статьи — Екатерина Бородич и Дмитрий Ковалев из Yandex Research — разработали ускоренный по Нестерову и не требующий подбора гиперпараметров градиентный метод, который автоматически адаптирует размер шага к локальной кривизне целевой функции с линейной (геометрической) скоростью. Эффективность алгоритма подтвердили, доказав, что он даёт оптимальную скорость сходимости для выпуклых задач оптимизации в условиях обобщенной гладкости.
#YaICLR26
ML Underhood
🔥10❤8👍6
Статьи Yandex Research на грядущей ICLR — 2/2
Статьи такие подробные и крутые, что просто рассказать о них всех в одном посте невозможно. Вот продолжение — ещё три работы.
SGD with Adaptive Preconditioning: Unified Analysis and Momentum Acceleration
Статья Дмитрия Ковалева посвящена унифицированному теоретическому анализу стохастического градиентного метода с адаптивным предобуславливанием в предположении матричной гладкости и шума, включающий популярные алгоритмы оптимизации, такие как AdaGrad-Norm, AdaGrad и Shampoo. Также автор разработал анализ ускоренного по Нестерову варианта метода, который позволяет получить теоретическое обоснование эффективности алгоритма Adam.
Revisiting Global Text Conditioning in Diffusion Transformers
Диффузионные трансформеры обычно используют текст двумя способами: через аттеншн и через модуляцию с pooled-эмбеддингом. В последние годы второй вариант часто убирают, оставляя только первый. Авторы показывают, что в стандартном виде pooled-эмбеддинг почти не влияет на качество — аттеншна обычно достаточно.
Однако если использовать pooled-эмбеддинг иначе, как guidance для управляемого смещения генерации к нужным свойствам, он даёт заметный прирост. Подход простой, не требует обучения, почти не добавляет времени и работает для разных моделей, улучшая результаты в text-to-image/video и image editing. В авторах статьи — Никита Стародубцев, Илья Дробышевский и Дмитрий Баранчук, а также исследователи из Adobe Research.
Sign-SGD is the Golden Gate between Multi-Node to SingleNode Learning: Significant Boost via Parameter-Free Optimization
Совместная работа Филиппа Змушко и Егора Петрова из Yandex Research с коллегами из BRAIn Lab. Претрейн больших моделей — крайне трудоёмкая задача, особенно в части подбора гиперпараметров. На практике шаг обучения часто выбирают эвристически через перебор, так как теоретически оптимальные значения требуют знания глобальных констант целевой функции (гладкости, липшицевости и тд), которые часто невозможно вычислить в реальных прикладных задач.
Авторы работы предложили новый parameter-free метод оптимизации, основанный на Sign-SGD. Решение (в частности алгоритм ALIAS) позволяет автоматически адаптировать шаг обучения в процессе оптимизации. Подход демонстрирует отличные практические результаты, сравнимые с тщательно настроенными SOTA методами, при этом избавляя от необходимости дорогостоящего перебора гиперпараметров.
#YaICLR26
ML Underhood
Статьи такие подробные и крутые, что просто рассказать о них всех в одном посте невозможно. Вот продолжение — ещё три работы.
SGD with Adaptive Preconditioning: Unified Analysis and Momentum Acceleration
Статья Дмитрия Ковалева посвящена унифицированному теоретическому анализу стохастического градиентного метода с адаптивным предобуславливанием в предположении матричной гладкости и шума, включающий популярные алгоритмы оптимизации, такие как AdaGrad-Norm, AdaGrad и Shampoo. Также автор разработал анализ ускоренного по Нестерову варианта метода, который позволяет получить теоретическое обоснование эффективности алгоритма Adam.
Revisiting Global Text Conditioning in Diffusion Transformers
Диффузионные трансформеры обычно используют текст двумя способами: через аттеншн и через модуляцию с pooled-эмбеддингом. В последние годы второй вариант часто убирают, оставляя только первый. Авторы показывают, что в стандартном виде pooled-эмбеддинг почти не влияет на качество — аттеншна обычно достаточно.
Однако если использовать pooled-эмбеддинг иначе, как guidance для управляемого смещения генерации к нужным свойствам, он даёт заметный прирост. Подход простой, не требует обучения, почти не добавляет времени и работает для разных моделей, улучшая результаты в text-to-image/video и image editing. В авторах статьи — Никита Стародубцев, Илья Дробышевский и Дмитрий Баранчук, а также исследователи из Adobe Research.
Sign-SGD is the Golden Gate between Multi-Node to SingleNode Learning: Significant Boost via Parameter-Free Optimization
Совместная работа Филиппа Змушко и Егора Петрова из Yandex Research с коллегами из BRAIn Lab. Претрейн больших моделей — крайне трудоёмкая задача, особенно в части подбора гиперпараметров. На практике шаг обучения часто выбирают эвристически через перебор, так как теоретически оптимальные значения требуют знания глобальных констант целевой функции (гладкости, липшицевости и тд), которые часто невозможно вычислить в реальных прикладных задач.
Авторы работы предложили новый parameter-free метод оптимизации, основанный на Sign-SGD. Решение (в частности алгоритм ALIAS) позволяет автоматически адаптировать шаг обучения в процессе оптимизации. Подход демонстрирует отличные практические результаты, сравнимые с тщательно настроенными SOTA методами, при этом избавляя от необходимости дорогостоящего перебора гиперпараметров.
#YaICLR26
ML Underhood
❤16🔥12👍7
ML-ранжирование маршрутов в Яндекс Картах
С недавних пор ранжированием маршрутов на Картах занимается ML‑модель, обученная на реальном поведении пользователей. Она учитывает не только время в пути, но и то, по каким маршрутам водители доезжают до конца, не сходя с дистанции.
Как именно модель понимает, какой маршрут предлагать пользователям первым, подробно рассказал на Хабре Илья Хохлов, руководитель службы разработки сервисов маршрутизации. А мы собрали интересные тезисы из статьи.
Почему важен порядок показа маршрутов
Порядок показа во многом определяет дальнейшее поведение пользователя. Чаще всего человек просто нажимает «Поехали» — и едет по первому предложенному пути.
Долгое время этот порядок формировался сортировкой по ETA (Estimated time of arrival), из‑за чего удобные и предсказуемые маршруты (которые пользователи чаще выбирают интуитивно) не оказывались на первом месте, а иногда вовсе выпадали из топ-3.
Обучение на выборах пользователей
Сначала команда пыталась обучать ранжирование на кейсах, когда пользователь осознанно выбирал не первый маршрут. Но таких случаев было слишком мало — на практике чаще выбирают именно первый маршрут, а уже позже отклоняются от него. Обучить ML‑модель ранжирования на этом количестве данных не получилось.
Таргет для обучения модели — реальное поведение
Тогда попробовали учитывать то, насколько реальный трек поездки совпадает с первым маршрутом. Это стало таргетом для обучения ML‑модели ранжирования: чем выше совпадение, тем более удачным считается маршрут.
Как правило, более простой маршрут имеет меньше сходов, даже если поездка по нему чуть дольше. С другой стороны, маршрут может формально выигрывать по времени, но, скажем, включать сложный манёвр. И без хорошего знания местности можно пропустить нужный поворот.
Эффект от нового подхода хорошо был заметен на маршрутах через центр города — с более сложной дорожной обстановкой. Их доля снизилась в выдаче на 3%. Также стало меньше маршрутов, проходящих через зоны с проблемным GPS.
Выбор функции потерь
Сначала попробовали применить функцию YetiRank, которая оптимизирует позиции самых релевантных объектов. На старте был заметный эффект, но подход не учитывал, что при выборе одного маршрута остальные перестают существовать для пользователя — он не строит рейтинг маршрутов.
Поэтому от классического ранжирования перешли к задаче выбора, используя функцию потерь на основе Softmax с one‑hot‑таргетом.
Для каждой поездки модель получает набор альтернативных маршрутов и учится распределять между ними вероятности выбора. One‑hot‑таргет указывает, какой маршрут в итоге выбрали, а Softmax позволяет напрямую оптимизировать вероятность этого выбора относительно остальных вариантов. В результате модель учится не просто упорядочивать маршруты, а предсказывать, какой из них с наибольшей вероятностью будет выбран в реальной поездке.
Что показал AB-эксперимент
— Число сходов снизилось в среднем на 2,19%;
— Доля хороших поездок без сходов с маршрута выросла на 2,16%;
— Базовое поведение пользователей при этом не изменилось: около 92% поездок по-прежнему начинаются с первого предложенного маршрута;
— Эффект зависит от региона, и там, где явные проблемы с GPS, он выражен сильнее — например, в Северной Осетии доля хороших поездок выросла на 8%;
— В ряде регионов уменьшаются сходы с выигрышем по времени — например, в Узбекистане — на 8,5%, в Казахстане — на 6,6%.
Новые предложенные маршруты — уже в Картах и Навигаторе, а детали и примеры — в полной хабростатье.
ML Underhood
С недавних пор ранжированием маршрутов на Картах занимается ML‑модель, обученная на реальном поведении пользователей. Она учитывает не только время в пути, но и то, по каким маршрутам водители доезжают до конца, не сходя с дистанции.
Как именно модель понимает, какой маршрут предлагать пользователям первым, подробно рассказал на Хабре Илья Хохлов, руководитель службы разработки сервисов маршрутизации. А мы собрали интересные тезисы из статьи.
Почему важен порядок показа маршрутов
Порядок показа во многом определяет дальнейшее поведение пользователя. Чаще всего человек просто нажимает «Поехали» — и едет по первому предложенному пути.
Долгое время этот порядок формировался сортировкой по ETA (Estimated time of arrival), из‑за чего удобные и предсказуемые маршруты (которые пользователи чаще выбирают интуитивно) не оказывались на первом месте, а иногда вовсе выпадали из топ-3.
Обучение на выборах пользователей
Сначала команда пыталась обучать ранжирование на кейсах, когда пользователь осознанно выбирал не первый маршрут. Но таких случаев было слишком мало — на практике чаще выбирают именно первый маршрут, а уже позже отклоняются от него. Обучить ML‑модель ранжирования на этом количестве данных не получилось.
Таргет для обучения модели — реальное поведение
Тогда попробовали учитывать то, насколько реальный трек поездки совпадает с первым маршрутом. Это стало таргетом для обучения ML‑модели ранжирования: чем выше совпадение, тем более удачным считается маршрут.
Как правило, более простой маршрут имеет меньше сходов, даже если поездка по нему чуть дольше. С другой стороны, маршрут может формально выигрывать по времени, но, скажем, включать сложный манёвр. И без хорошего знания местности можно пропустить нужный поворот.
Эффект от нового подхода хорошо был заметен на маршрутах через центр города — с более сложной дорожной обстановкой. Их доля снизилась в выдаче на 3%. Также стало меньше маршрутов, проходящих через зоны с проблемным GPS.
Выбор функции потерь
Сначала попробовали применить функцию YetiRank, которая оптимизирует позиции самых релевантных объектов. На старте был заметный эффект, но подход не учитывал, что при выборе одного маршрута остальные перестают существовать для пользователя — он не строит рейтинг маршрутов.
Поэтому от классического ранжирования перешли к задаче выбора, используя функцию потерь на основе Softmax с one‑hot‑таргетом.
Для каждой поездки модель получает набор альтернативных маршрутов и учится распределять между ними вероятности выбора. One‑hot‑таргет указывает, какой маршрут в итоге выбрали, а Softmax позволяет напрямую оптимизировать вероятность этого выбора относительно остальных вариантов. В результате модель учится не просто упорядочивать маршруты, а предсказывать, какой из них с наибольшей вероятностью будет выбран в реальной поездке.
Что показал AB-эксперимент
— Число сходов снизилось в среднем на 2,19%;
— Доля хороших поездок без сходов с маршрута выросла на 2,16%;
— Базовое поведение пользователей при этом не изменилось: около 92% поездок по-прежнему начинаются с первого предложенного маршрута;
— Эффект зависит от региона, и там, где явные проблемы с GPS, он выражен сильнее — например, в Северной Осетии доля хороших поездок выросла на 8%;
— В ряде регионов уменьшаются сходы с выигрышем по времени — например, в Узбекистане — на 8,5%, в Казахстане — на 6,6%.
Новые предложенные маршруты — уже в Картах и Навигаторе, а детали и примеры — в полной хабростатье.
ML Underhood
❤17👍11🔥8
This media is not supported in your browser
VIEW IN TELEGRAM
Выкатили тестирование нового ИИ-агента для Android
Возможно, вы уже видели новости об этом в телеграм-каналах — подтверждаем: начались тесты нового ИИ-агента Яндекса. Он умеет выполнять многошаговые действия на смартфоне с Android по голосовой команде.
Например, агент может отправлять сообщения в мессенджерах без ручного ввода, находить информацию на устройстве, устанавливать приложения и переводить текст с экрана на разные языки. Для выполнения задачи достаточно голосовой команды, например: «Напиши Саше в Телеграме, что нужно купить молоко» или «Найди в Google Play приложение Яндекс Переводчик и установи его».
Алексей Цветков, руководитель службы продуктовой разработки R&D, рассказал подробнее, как агент выполняет задачу пользователя.
Записаться на тестирование можно в бета-версии поискового приложения «Яндекс — с Алисой AI» или через форму.
ML Underhood
Возможно, вы уже видели новости об этом в телеграм-каналах — подтверждаем: начались тесты нового ИИ-агента Яндекса. Он умеет выполнять многошаговые действия на смартфоне с Android по голосовой команде.
Например, агент может отправлять сообщения в мессенджерах без ручного ввода, находить информацию на устройстве, устанавливать приложения и переводить текст с экрана на разные языки. Для выполнения задачи достаточно голосовой команды, например: «Напиши Саше в Телеграме, что нужно купить молоко» или «Найди в Google Play приложение Яндекс Переводчик и установи его».
Алексей Цветков, руководитель службы продуктовой разработки R&D, рассказал подробнее, как агент выполняет задачу пользователя.
Пользователь задаёт запрос, скажем: «Найди товар на Яндекс Маркете и положи в корзину».
LLM переводит просьбу пользователя в цепочку атомарных действий на телефоне:
- получи список приложений;
- найди Яндекс Маркет;
- открой Яндекс Маркет;
- и так далее, пока задача не будет решена.
Агент построен на базе Android Assistant API и для принятия решения использует текстовое описание интерфейса — такое же API используют приложения для слабовидящих.
На стороне Android-клиента реализован MCP-интерфейс, который позволяет девайсу от имени пользователя выполнять простейшие команды: кликни сюда, свайпни здесь и так далее.
Задача модели — конвертировать сложносоставную команду в цепочку взаимосвязанных атомарных команд, опираясь на промежуточное состояние интерфейса.
Надеемся, что широкий тест поможет найти то, о чём мы ещё не догадались подумать, и быстрее превратить прототип в понятный и полезный продукт.
Записаться на тестирование можно в бета-версии поискового приложения «Яндекс — с Алисой AI» или через форму.
ML Underhood
❤24🔥19👍11😱1
Как выжать максимум из decoder attention на GPU
Генерация токенов в LLM часто упирается не в слабое железо, а в то, что вычисления организованы неоптимально. Андрей Шукшов (Яндекс R&D) рассказал на Хабре, почему так происходит, и показал способ насытить память GPU в режиме декодирования.
GPU и CPU: throughput vs latency
CPU оптимизированы для задач с низкой задержкой и сложной логикой. GPU делают ставку на параллелизм: тысячи более простых ядер выполняют одинаковые операции одновременно. Задержка DRAM скрывается за счёт большого числа потоков и высокой пропускной способности памяти. Это выглядит идеальным для LLM, в которых нужно одновременно выполнять триллионы однотипных операций. Главное тут — постоянно держать видеокарту полностью загруженной.
Как работает параллелизм на GPU
Казалось бы, CUDA даёт удобную модель с множеством независимых потоков, но на практике GPU работает варпами по 32 потока с одной инструкцией на всех. При расхождении веток варп последовательно исполняет обе, из-за чего часть потоков простаивает и теряется производительность.
SM внутри GPU
Streaming Multiprocessor (SM) — основная рабочая единица GPU. На видеокарте их больше сотни, и между ними распределяется вся работа. Внутри SM находятся CUDA Cores, Tensor Cores и быстрая Shared Memory. Чтобы всё работало, нужно давать достаточно параллельных задач и активно использовать быструю память, иначе SM будут простаивать или упираться в доступ к DRAM.
Декодер — худший сценарий для GPU
В режиме генерации модель выдаёт текст слово за словом. Каждый новый токен — это один вектор, который нужно умножить на весь накопленный KV-кэш предыдущих токенов. То, что в обучении выглядит как плотное умножение матрицы на матрицу (GEMM), в декодере превращается в умножение вектора на матрицу (GEMV). А это уже memory-bound-сценарий: вычислений мало, чтения из памяти много.
Аттеншн при этом состоит из трёх последовательных шагов:
1) Q @ Kᵀ;
2) Softmax;
3) умножение на V.
Если выполнять их как три отдельных кернела, результаты каждый раз записываются в глобальную память и снова читаются обратно. Для memory-bound-задачи это критично: мы трижды гоняем данные через DRAM и теряем пропускную способность.
Всё из-за софтмакса
Кажется логичным объединить всё в один кернел и не писать промежуточные результаты в память. Но софтмакс требует редукции по всей строке, потому что для подсчёта знаменателя, нужно увидеть все элементы. Это плохо сочетается с тайлингом, который используется для GEMM на уровне SM. Получается, софтмакс мешает в лоб зафьюзить все три операции.
Online Softmax и fused kernel
Решение — Online Softmax, с которым софтмакс можно считать итеративно. Данные обрабатываются частями, и софтмакс встраивается внутрь одного fused kernel`а.
Теперь тайлы K и V загружаются из DRAM в Shared Memory, внутри SM считается часть Q @ Kᵀ, на лету обновляется Online Softmax и сразу же домножается на V. Всё происходит в одном кернеле, без лишних обращений к глобальной памяти. Вместо трёх поездок «на склад» достаточно одной.
Результаты
Fused kernel даёт ускорение минимум в 1,5 раза по сравнению с тремя стандартными вызовами.
Главная метрика для memory-bound задач — утилизация пропускной способности памяти. В эксперименте она доходит до 85–91% от теоретического пика. Это значит, что алгоритм практически полностью насыщает шину памяти и упирается в физический предел железа.
Полное описание эксперимента, разбор архитектуры SM с деталями и замерами, а также выводы от автора — в хабростатье.
ML Underhood
Генерация токенов в LLM часто упирается не в слабое железо, а в то, что вычисления организованы неоптимально. Андрей Шукшов (Яндекс R&D) рассказал на Хабре, почему так происходит, и показал способ насытить память GPU в режиме декодирования.
GPU и CPU: throughput vs latency
CPU оптимизированы для задач с низкой задержкой и сложной логикой. GPU делают ставку на параллелизм: тысячи более простых ядер выполняют одинаковые операции одновременно. Задержка DRAM скрывается за счёт большого числа потоков и высокой пропускной способности памяти. Это выглядит идеальным для LLM, в которых нужно одновременно выполнять триллионы однотипных операций. Главное тут — постоянно держать видеокарту полностью загруженной.
Как работает параллелизм на GPU
Казалось бы, CUDA даёт удобную модель с множеством независимых потоков, но на практике GPU работает варпами по 32 потока с одной инструкцией на всех. При расхождении веток варп последовательно исполняет обе, из-за чего часть потоков простаивает и теряется производительность.
SM внутри GPU
Streaming Multiprocessor (SM) — основная рабочая единица GPU. На видеокарте их больше сотни, и между ними распределяется вся работа. Внутри SM находятся CUDA Cores, Tensor Cores и быстрая Shared Memory. Чтобы всё работало, нужно давать достаточно параллельных задач и активно использовать быструю память, иначе SM будут простаивать или упираться в доступ к DRAM.
Декодер — худший сценарий для GPU
В режиме генерации модель выдаёт текст слово за словом. Каждый новый токен — это один вектор, который нужно умножить на весь накопленный KV-кэш предыдущих токенов. То, что в обучении выглядит как плотное умножение матрицы на матрицу (GEMM), в декодере превращается в умножение вектора на матрицу (GEMV). А это уже memory-bound-сценарий: вычислений мало, чтения из памяти много.
Аттеншн при этом состоит из трёх последовательных шагов:
1) Q @ Kᵀ;
2) Softmax;
3) умножение на V.
Если выполнять их как три отдельных кернела, результаты каждый раз записываются в глобальную память и снова читаются обратно. Для memory-bound-задачи это критично: мы трижды гоняем данные через DRAM и теряем пропускную способность.
Всё из-за софтмакса
Кажется логичным объединить всё в один кернел и не писать промежуточные результаты в память. Но софтмакс требует редукции по всей строке, потому что для подсчёта знаменателя, нужно увидеть все элементы. Это плохо сочетается с тайлингом, который используется для GEMM на уровне SM. Получается, софтмакс мешает в лоб зафьюзить все три операции.
Online Softmax и fused kernel
Решение — Online Softmax, с которым софтмакс можно считать итеративно. Данные обрабатываются частями, и софтмакс встраивается внутрь одного fused kernel`а.
Теперь тайлы K и V загружаются из DRAM в Shared Memory, внутри SM считается часть Q @ Kᵀ, на лету обновляется Online Softmax и сразу же домножается на V. Всё происходит в одном кернеле, без лишних обращений к глобальной памяти. Вместо трёх поездок «на склад» достаточно одной.
Результаты
Fused kernel даёт ускорение минимум в 1,5 раза по сравнению с тремя стандартными вызовами.
Главная метрика для memory-bound задач — утилизация пропускной способности памяти. В эксперименте она доходит до 85–91% от теоретического пика. Это значит, что алгоритм практически полностью насыщает шину памяти и упирается в физический предел железа.
Полное описание эксперимента, разбор архитектуры SM с деталями и замерами, а также выводы от автора — в хабростатье.
ML Underhood
🔥16❤9👍9🥰1👾1
На днях команда Openpilot 0.11 анонсировала запуск первого робо-агента для автономного транспорта, обученного только на симуляциях.
О потенциальных плюсах, минусах и вопросах к подходу в канале об ML в автономном транспорте рассказывает наш коллега Кирилл Федянин.
О потенциальных плюсах, минусах и вопросах к подходу в канале об ML в автономном транспорте рассказывает наш коллега Кирилл Федянин.
🔥3❤2👍1
Forwarded from 404 Driver Not Found
This media is not supported in your browser
VIEW IN TELEGRAM
Openpilot 0.11 — первый робо-агент, обученный только на симуляциях
Команда Comma.ai опубликовала интересный пост, где утверждает, что впервые в истории индустрии выпустила на дороги робо-агент, полностью обученный в вымышленной нейросетями симуляции.
Немного контекста: в Comma.ai разрабатывают систему помощи водителю, совместимую со многими моделями автомобилей. Система работает на втором уровне автономности — умный лейн-кипинг в широком спектре сценариев. Эта задача гораздо проще, чем полностью автономное вождение, что позволяет Comma.ai экспериментировать.
В то время как Waymo и британская команда Wayve интегрируют модели мира в свои пайплайны, Comma.ai идёт ещё дальше и отказывается от всего, кроме модели мира. Похожую идею предлагали учёные из Беркли в классической для робототехники статье DayDreamer — интересно, что этот подход удалось адаптировать для автономного вождения.
Вот что предлагают создатели Openpilot 0.11:
Шаг 1. Собрать 40 тысяч часов интересных видео, записанных флотом автономного транспорта и разбить их на сцены по 10 секунд с частотой 5 Гц.
Шаг 2. Обучить на этом датасете двухголовую модель мира:
🔴 первая голова предсказывает по видеоконтексту следующее действие эго-агента,
🔴 вторая — генерирует следующий кадр по видеоконтексту и только что полученному следующему действию.
Потом к контексту добавляется сгенерированный кадр, и процесс повторяется.
Секретный ингредиент — подавать на вход модели не только две секунды истории, но и последнюю секунду в эпизоде. Так ей понадобится предсказывать только промежуточную траекторию — это значительно улучшает сходимость. В итоге получается достаточно реалистичный симулятор вождения, который генерирует следующий кадр по двум секундам видео и действию эго.
Шаг 3. Обучить в полученном симуляторе небольшую модель-водителя, которая должна сходиться в финальное состояние по одному лишь видео, не видя последний кадр. Щедро насыпать шум на всех стадиях для устойчивости.
Openpilot 0.11 обучали on-policy — модель много едет по сгенерированной ей самой траектории, что выгодно отличает подход от обычного imitation learning.
При этом награды или штрафы не задавались явно — по опыту reinforcement learning, конструирование наград иногда всё только портит. Авторы усвоили горький урок: для того чтобы всё сошлось, достаточно увеличить количество данных и размер модели.
Единственная проблема, которая остаётся, — модель-водитель может научиться ломать симуляцию непредсказуемыми способами. Авторы утверждают, что это решается за счёт гипотезы большого мира: одновременно увеличивать и модель мира, и размеры водителя так, чтобы мир всегда был на порядок больше.
В парадигме Level 2 получается хороший результат — агент держит линию и расстояние до других, объезжает запаркованные авто. Но вопрос, будет ли это скейлиться на более сложные задачи, остаётся открытым.
Разбор подготовил❣️ Кирилл Федянин
404 driver not found
Команда Comma.ai опубликовала интересный пост, где утверждает, что впервые в истории индустрии выпустила на дороги робо-агент, полностью обученный в вымышленной нейросетями симуляции.
Немного контекста: в Comma.ai разрабатывают систему помощи водителю, совместимую со многими моделями автомобилей. Система работает на втором уровне автономности — умный лейн-кипинг в широком спектре сценариев. Эта задача гораздо проще, чем полностью автономное вождение, что позволяет Comma.ai экспериментировать.
В то время как Waymo и британская команда Wayve интегрируют модели мира в свои пайплайны, Comma.ai идёт ещё дальше и отказывается от всего, кроме модели мира. Похожую идею предлагали учёные из Беркли в классической для робототехники статье DayDreamer — интересно, что этот подход удалось адаптировать для автономного вождения.
Вот что предлагают создатели Openpilot 0.11:
Шаг 1. Собрать 40 тысяч часов интересных видео, записанных флотом автономного транспорта и разбить их на сцены по 10 секунд с частотой 5 Гц.
Шаг 2. Обучить на этом датасете двухголовую модель мира:
Потом к контексту добавляется сгенерированный кадр, и процесс повторяется.
Секретный ингредиент — подавать на вход модели не только две секунды истории, но и последнюю секунду в эпизоде. Так ей понадобится предсказывать только промежуточную траекторию — это значительно улучшает сходимость. В итоге получается достаточно реалистичный симулятор вождения, который генерирует следующий кадр по двум секундам видео и действию эго.
Шаг 3. Обучить в полученном симуляторе небольшую модель-водителя, которая должна сходиться в финальное состояние по одному лишь видео, не видя последний кадр. Щедро насыпать шум на всех стадиях для устойчивости.
Openpilot 0.11 обучали on-policy — модель много едет по сгенерированной ей самой траектории, что выгодно отличает подход от обычного imitation learning.
При этом награды или штрафы не задавались явно — по опыту reinforcement learning, конструирование наград иногда всё только портит. Авторы усвоили горький урок: для того чтобы всё сошлось, достаточно увеличить количество данных и размер модели.
Единственная проблема, которая остаётся, — модель-водитель может научиться ломать симуляцию непредсказуемыми способами. Авторы утверждают, что это решается за счёт гипотезы большого мира: одновременно увеличивать и модель мира, и размеры водителя так, чтобы мир всегда был на порядок больше.
В парадигме Level 2 получается хороший результат — агент держит линию и расстояние до других, объезжает запаркованные авто. Но вопрос, будет ли это скейлиться на более сложные задачи, остаётся открытым.
Разбор подготовил
404 driver not found
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥9❤5❤🔥3👍1🫡1
Is Evaluation Awareness Just Format Sensitivity? Limitations of Probe-Based Evidence Under Controlled Prompt Structure
Мы уже писали тут и тут о работах Yandex Research, принятых на ICLR 2026. Но это ещё не всё. На воркшоп ICBINB в рамках ICLR 2026 также приняли статью Вилианы Девбуновой, разработчика из службы технологий голосового ввода. Вилиана рассказала, как нашим исследователям удалось поставить под сомнение и критически переосмыслить устоявшееся представление о evaluation awareness в больших языковых моделях.
До ICLR осталось совсем немного времени. Ну а мы, как всегда, будем в по горячим следам рассказывать о самых интересных работах и событиях конференции.
#YaICLR26
ML Underhood
Мы уже писали тут и тут о работах 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
❤15❤🔥6🔥6👍2😍2😁1
Как ML помогает бороться с борщевиком
ML-разработчики Школы анализа данных вместе с экспертами Центра технологий для общества Яндекса и движением «СтопБорщевик» запустили ИИ‑инструмент для борьбы с борщевиком. Подробно о технологии читайте на Хабре, а здесь мы кратко расскажем о главном.
Борщевик Сосновского — растение крайне живучее и плодовитое, способное быстро занимать большие территории. Очаги распространения борщевика фиксируют с воздуха — их хорошо видно во время цветения, — а затем картографируют. Это помогает находить новые области заражения и следить за ликвидацией.
Однако обводить борщевик на снимках вручную — процесс дорогой и долгий. А вот модель справится с этим в 50 раз быстрее.
Для обучения использовали 55 спутниковых снимков, что дало датасет в 10 тысяч изображений. Разметка проходила в два этапа: на первом выделяли по контуру области с борщевиком, а на втором — считали вегетативный индекс и подбирали для него порог: если значение было выше, область закрашивалась, если ниже — нет.
Данных было немного, поэтому вместо тяжёлых сегментационных сетей вроде U-Net использовали табличный ML: извлекли признаки из изображений и обучили градиентный бустинг. В итоге модель решает простую задачу — есть на участке борщевик или нет.
Итоговый подход получает на вход GeoTIFF-файл — растровое изображение с геоданными — и нормализует его, чтобы избавиться от бликов, глубоких теней и артефактов. Потом изображение разбивается на тайлы 256 × 256 пикселей и из каждого тайла извлекаются признаки, по которым модель определяет, есть ли перед ней борщевик. А далее идёт векторизация, итогом которой становится вычисление площади полигона, захваченного растением. Всё это передаётся на вход работы CatBoost-а.
С помощью модели уже удалось выявить очаги заражения площадью 421 гектар в 17 регионах европейской части России. Москву и область проанализировали полностью, а к лету планируют задействовать сервис для мониторинга 100 тысяч квадратных километров в Тверской и Ярославской областях.
Напоминаем, что узнать все тонкости работы технологии вы можете на Хабре. А если тоже хотите работать над подобными полезными проектами, то можно подать заявку в Школу анализа данных Яндекса. Набор на обучение открыт до 3 мая.
ML Underhood
ML-разработчики Школы анализа данных вместе с экспертами Центра технологий для общества Яндекса и движением «СтопБорщевик» запустили ИИ‑инструмент для борьбы с борщевиком. Подробно о технологии читайте на Хабре, а здесь мы кратко расскажем о главном.
Борщевик Сосновского — растение крайне живучее и плодовитое, способное быстро занимать большие территории. Очаги распространения борщевика фиксируют с воздуха — их хорошо видно во время цветения, — а затем картографируют. Это помогает находить новые области заражения и следить за ликвидацией.
Однако обводить борщевик на снимках вручную — процесс дорогой и долгий. А вот модель справится с этим в 50 раз быстрее.
Для обучения использовали 55 спутниковых снимков, что дало датасет в 10 тысяч изображений. Разметка проходила в два этапа: на первом выделяли по контуру области с борщевиком, а на втором — считали вегетативный индекс и подбирали для него порог: если значение было выше, область закрашивалась, если ниже — нет.
Данных было немного, поэтому вместо тяжёлых сегментационных сетей вроде U-Net использовали табличный ML: извлекли признаки из изображений и обучили градиентный бустинг. В итоге модель решает простую задачу — есть на участке борщевик или нет.
Итоговый подход получает на вход GeoTIFF-файл — растровое изображение с геоданными — и нормализует его, чтобы избавиться от бликов, глубоких теней и артефактов. Потом изображение разбивается на тайлы 256 × 256 пикселей и из каждого тайла извлекаются признаки, по которым модель определяет, есть ли перед ней борщевик. А далее идёт векторизация, итогом которой становится вычисление площади полигона, захваченного растением. Всё это передаётся на вход работы CatBoost-а.
С помощью модели уже удалось выявить очаги заражения площадью 421 гектар в 17 регионах европейской части России. Москву и область проанализировали полностью, а к лету планируют задействовать сервис для мониторинга 100 тысяч квадратных километров в Тверской и Ярославской областях.
Напоминаем, что узнать все тонкости работы технологии вы можете на Хабре. А если тоже хотите работать над подобными полезными проектами, то можно подать заявку в Школу анализа данных Яндекса. Набор на обучение открыт до 3 мая.
ML Underhood
🔥32❤16👍6😁5🕊1🖕1
На прошлой неделе мы запустили агент «Исследовать» в Алисе AI, а сегодня делимся техническими деталями
Это DeepResearch-агент, который может проанализировать большой объём данных и выдать полноценный разбор темы. За три месяца тестирования «Исследовать» использовали более 280 тысяч раз. Техлид агента Прохор Гладких рассказал о нём подробнее.
А работа началась год назад — в апреле 2025-го. Первая версия представляла собой классический пайплайн: поиск и генерация. Однако запросы в поиск генерировали с помощью тяжёлой модели и сразу несколько, а ответы получали с помощью ризонера. Так в Алисе появился режим «рассуждать + поиск».
Первый прототип непосредственно агента «Исследовать» был аналогом CodeAgent, собранным из smolagents. Такой подход позволил добиться неплохих результатов на SimpleQA и Frames.
Вторая итерация агента уже была полностью реализована на классическом function calling.
Удалось побить метрики CodeAgent и полностью отказаться от написания кода для вызова тулов. Всего в «Исследовать» 13 подагентов и 9 тулов, среди которых, например, CodeSandbox для запуска сгенерированного агентом кода.
Попробовать агент «Исследовать» можно на сайте alice.yandex.ru, в приложениях Алиса AI, Яндекс с Алисой AI и в Яндекс Браузере.
ML Underhood
Это 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
👍16❤9🔥5
Долгое бодрствование агентов — как мы построили платформу 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
Агент «Исследовать», о котором мы писали ранее, должен быть устойчивым к непредвиденным ситуациям. Собственно, исследование — процесс комплексный, требующий проанализировать несколько источников, вызвать разные инструменты и запустить модели. Если где-то что-то упадёт, то всё придется начинать сначала. Чтобы этого не происходило, в Яндексе использовали платформу 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
❤10🔥9👏5❤🔥2👍2🤝2🤮1