RnD ML Team

Common questions

How many subscribers?

Subscribers: 4.1K. Median views per post: 1.7K. Views per subscriber: 41.1%. Measured on October 1, 2026.

How often are posts published?

Posts in the last 30 days: 21 — that is almost every day. Measured on October 1, 2026.

Does this channel have a Telegram tick?

No Telegram tick.

Who runs this channel page in the catalog?

Nobody yet. If this is your channel, claim the page: you will be able to reply to reviews and see its stats.

Latest posts

Posts are in Russian — that is what the channel publishes.

• yesterday43419 forwards12 reactions1 commentOpen in Telegram
  🔎 Агент SMITH для поиска: маленькая модель ищет, большая — отвечает На AI RnD Day Артём Снегирёв рассказал, как команда обучала SMITH — отдельного агента для многошагового поиска. 📌 TLDR Вместо того чтобы заставлять дорогую LLM читать всю поисковую выдачу, ребята из команды Артема предложили другой подход и поручили поиск небольшой модели. SMITH уточняет запросы, обращается к векторному индексу и возвращает ID нужных документов, а ответ пользователю пишет другая LLM, которую можно выбирать под свои нужды и которая не мешает поиску. Агента обучали сначала на примерах поисковых цепочек, затем добавили щепотку RL. При этом выяснилось: агент часто находит нужный документ, но не включает его в итоговый набор. Ниже представлены технические детали... ⚙️ Что внутри Архитектура на базе родного GigaChat3-10B-A1.8B, контекст 32K токенов (хотя модель поддерживает 256K). Инструмент search возвращает top-10 документов за вызов. Затем эмбеддер на базе Qwen3-8B строит векторные представления, размер чанка — 512. Цикл выглядит так: определить, чего не хватает → сформировать подзапрос → прочитать выдачу → продолжить поиск или остановиться. Обычно хватает 4–6 итераций. 🧪 Как учили искать Для SFT использовали 8K траекторий, отфильтрованных по длине контекста и качеству поиска. Траектория — это вся последовательность запросов, найденных документов и финального отбора для выдачи результата. Многошаговые вопросы собирали подстановками. Вместо вопроса "В каком году Беринг прибыл к Каме?" было усложнение "В каком году руководитель Второй Камчатской экспедиции прибыл к реке, на которой стоит Пермь?". То есть теперь нужно раскрыть две сущности, а затем найти дату. Это сложно 😳 Отдельно попробовали обучать агента на "идеальных" поисковых траекториях: брали готовое разбиение вопроса на подзапросы, каждый превращали в отдельный вызов поиска и гарантировали нужный документ в выдаче. Но результат оказался на 3,3 п. п. ниже, чем при обучении на базовом наборе траекторий. То есть более аккуратная демонстрация не обязательно лучше готовит агента к реальному поиску. Почему так вышло? Возможное объяснение — в таких примерах нет ситуаций, где нужно исправить неудачный запрос или продолжить поиск после неполной выдачи. Отдельно этот момент пока не изучали. ✂️ Что убрали из агента Все замеры сделаны на бенче HotpotQA (Multi-hop Question Answering). Метрика nDCG@10 оценивает релевантность и порядок первых десяти документов. Отказ от блока рассуждений сократил контекст на 10%, но снизил метрику на 1,1 пункта. Среднее число поисковых вызовов выросло с 4,4 до 4,9. Зато замена ответа с цитатами на простой список doc_id подняла nDCG@10 с 79,6 до 83,2. Для модели оставили только отбор документов. Снизились ли при этом галлюцинации, отдельно не проверяли. А удаление повторяющихся документов из контекста не оправдало ожиданий: контекст стал короче на 13%, но метрика упала на 1,9 пункта. В итоге дубликаты заменялись заглушками. 📈 Что добавило обучение с подкреплением Использовали GRPO: восемь поисковых траекторий на запрос, награда по метрике recall@30, доля эталонных релевантных документов, попавших в первые 30 результатов. На двухшаговых задачах MuSiQue переход от SFT к SFT → RL поднял nDCG@10 с 83,1 до 87,5 и сократил среднее число вызовов с 4,8 до 3,5. На трёхшаговых задачах выигрыш скромнее: 75,4 → 77,0. При этом метрика при идеальном отборе уже найденных документов выросла с 86,4 до 92,3. То есть видно, что агент стал приносить больше полезного, но значительную часть терял на финальном отборе. 🔚 Выводы Поиск можно выделить в отдельную небольшую модель, не поручая ей ещё и написание ответа. Но важно оценивать всю цепочку действий поиска: какие документы удалось найти, какие попали к генератору и сколько вызовов на это ушло. Больше найденного не всегда означает лучший итоговый контекст. Отдельно отметим, что наработки команды можно посмотреть в опенсорсе по ссылкам: 🤗 HF 🖥 Github 🔗 Более подробно — в презентации Артёма (в комментариях файлом) и в записи выступления (тайминг: 2:05:00). #RAG #agents #search #conference #paperwatch

  More
  
• 2 days ago2.7K37 forwards13 reactions2 commentsOpen in Telegram
  🔎 Модель говорит по-русски. А понимает? Пять новых линеек бенчмарков На AI RnD Day наша уважаемая Алёна Феногенова представила 5 линеек русскоязычных тестов для оценки современных моделей. 📌 TLDR Один общий балл в метрике плохо описывает модель для реального применения. Алена рассказала про 5 новых бенчмарков! 1️⃣ LIBRA проверяет работу с длинным контекстом, 2️⃣ MERA Reason — математические рассуждения, 3️⃣ MERA Text 2.0 — языковые, культурные и прикладные навыки, бенчмарки MERA разработаны совместно с Альянсом ИИ. 4️⃣ RUMBA оценивает память между сессиями, а 5️⃣ harness-bench-fast — работу в агентной обвязке: правильно выбрать тул в текстовой задаче и успешно выполнить действие в среде — не одно и то же. Результат зависит от всей связки — модель × обвязка × промпт × окружение. 📚 LIBRA Mini: поместилось в контекст ≠ прочитано Из 18 задач полной LIBRA выбрали шесть сложных и показательных. Диапазон — от 4K до 512K токенов, запуск через lm-evaluation-harness. Здесь мало найти одну фразу: нужно связать факты из разных частей текста, ответить по нескольким статьям Wikipedia, определить человека по теме диалога или посчитать уникальные абзацы среди повторов. Причем, у Qwen3-30B-A3B-Instruct-2507 итоговая оценка падает с 62,2 на 4K до 39,8 на 64K и 12,6 на 128K. Поэтому полезно смотреть не только на максимальное окно модели, но и на то, как меняется качество внутри него. 🧮 MERA Reason Линейка объединяет Luzitania — 251 олимпиадную задачу, TMath — 310 задач с акцентом на комбинаторику, теорию чисел и геометрию, ruAIME — 724 задачи с проверкой точного совпадения ответа. А также MMReD: 128 шагов среды, вход около 8,7K токенов и рассуждение около 20K. Проверяется работа с длинной последовательностью шагов. Все тесты публичные. ⚙️ MERA Text 2.0: где модели ещё различаются В новой версии 12 датасетов и около 8700 запросов — в 4,3 раза меньше прежнего объёма. Четыре группы: человеческая коммуникация, русскоязычный культурный контекст, базовые агентные навыки и рассуждение. Тесты приватные, результаты публикуются на лидерборде. Особенно полезен Agentic-раздел: соблюсти 3–6 формальных требований в одном запросе, преобразовать YAML/CSV/XML целиком, выбрать инструмент из каталога на 14–22 тула. Именно он лучше всего разделяет сильные модели и следующий эшелон. Но это ещё текстовая проверка навыков, не полноценный запуск агента. А понимание регионализмов, мемов и фольклора слабее связано с общим уровнем модели: высокий результат на других задачах его не гарантирует. 🧠 RUMBA: помнить нужно не всё подряд В наборе 85 диалогов и 1543 вопроса. Проверяется извлечение фактов, рассуждение по истории и умение признать отсутствие информации. Есть и временная составляющая: если пользователь сначала любил розы, потом кактусы, а теперь лилии, ответить «розы» — ошибка, хотя такой факт в истории был. Сравниваются два режима: весь диалог во входе и внешняя память/RAG. Простой RAG получает 68,89 по русскоязычной оценке LLM-судьи, memOS — 66,82, mem0 — 53,21. Сложнее — не обязательно лучше. Это сравнение показанных систем, не универсальный рейтинг подходов. 🛠 harness-bench-fast Около 391 кейса на файлы, CLI, инструменты, инструкции, память, программирование и отладку. Результат проверяет код, без LLM-судьи. Заявлен локальный прогон примерно за 30 минут без Docker и без интернета для тестовой среды; есть поддержка Harbor и повторных запусков с pass@K. Бенчмарк команды @robofuture Кости Крестникова, который также выступал на конференции. 🔚 Выводы Для выбора модели нужен профиль ограничений: где теряется контекст, устаревает память или ломается выполнение инструкций. А если внедряем агента, измерять стоит всю систему — хороший балл отдельной LLM ещё не обещает надёжной работы её обвязки. 🔗 Более подробно — в презентации Алены (в комментариях файлом) и в записи выступления (тайминг: 6:29:30). 🔗 Тесты и лидерборды • LIBRA Mini • MERA Reason • MERA Text 2.0 • RUMBA • harness-bench-fast #benchmarks #evaluation #llm #agents #conference #paperwatch

  More
  
• 3 days ago73920 forwards13 reactions1 commentOpen in Telegram
  🎬 Как дать VLM понять длинное видео и не потерять смысл 5 минут видео при одном кадре в секунду — это 300 кадров. Если кодировать каждый в 280 визуальных токенов, получаем 84K. При 30 fps — уже 2,52 млн токенов! Снизить частоту кадров можно, но вместе с ними легко выбросить короткое событие, о котором спрашивает пользователь. На AI RnD Day Никита Сидоров рассказал, как команда обходила эту проблему: от прореживания визуальных токенов до просмотра видео через инструменты и/или агентную систему. А DeepMind недавно выпустил хороший репорт со схожей идеей, мы писали об этом ранее. 📌 TLDR Не обязательно отправлять весь ролик в VLM одним запросом. Можно удалять избыточные токены внутри кадров, научить модель запрашивать нужные временные фрагменты или распределить просмотр между агентами. В экспериментах команды tool-call режим сократил потребление контекста почти в 6 раз относительно бейзлайна. Агентная система оказалась точнее, особенно в подсчёте объектов и действий, но использовала в 7,3 раза больше токенов, чем tool-call. Это разные компромиссы между полнотой просмотра, качеством и стоимостью. ✂️ Убирать токены, а не целые кадры Первый вариант — прунинг визуальных токенов без дообучения модели. Подход DivPrune оставляет максимально непохожие друг на друга токены: вместо множества похожих оставляем разнообразие. HiPrune использует внимание разных слоёв визуального энкодера. Из средних слоёв выбираются object-centric anchors, рядом сохраняются буферные токены для локального окружения, а из глубоких слоёв — register-токены для глобального контекста. Остальные токены удаляются перед LLM. В показанных экспериментах HiPrune сократил потребление контекста на 36%, DivPrune — на 27%. А качество на бенчмарках даже слегка подросло. 🔎 Дать модели инструмент "посмотреть сюда" Следующий шаг — считать видео средой, к которой можно обращаться повторно. Модель обучают вызывать crop_video: передать путь к ролику и границы временного интервала, получить визуальные токены фрагмента и продолжить рассуждение. Если данных недостаточно — запросить ещё один участок. Вместо одного фиксированного семплирования получается цикл: рассуждение → выбор интервала → просмотр → следующий запрос или ответ. Но у него своя точка отказа: модель может ошибиться в вызове инструмента. А если просмотренные фрагменты всё равно заполняют контекст? Их содержание записывается в структурированную память: span, place, subjects, actions, details (время, место, участники, действия и детали). Затем ненужные фрагменты удаляются из контекста. Так не приходится держать всю визуальную историю одновременно, хотя сохранность деталей зависит уже и от качества этих записей. По результатам команды, такой режим потреблял в 5,8 раз меньше контекста, с небольшим преимуществом по качеству: +1,2 п.п. относительно бейзлана! 🧩 Внимательно смотрим видео Агентная схема устроена иначе. Видео делится на фрагменты (например, по 15 сек). Captioner-ы описывают фрагменты, Caption Inspector-ы анализируют описания, а главная модель собирает ответ на вопрос пользователя. Вместо выборочного просмотра обрабатываются все фрагменты, но между уровнями передаются уже текстовые описания и результат. Такая агентная система дала +3,6 п.п. по качеству, а на задачах подсчёта объектов и действий +20 п.п. Важно: выигрыш именно на отдельном классе задач, а не на всём тесте. Обратная сторона — расход токенов: в 7,3 раза больше, чем у tool-call, и он растёт с длиной видео. 🔚 Выводы Уменьшать fps — не единственный способ сэкономить (и жертвовать качеством): можно сокращать представление кадров или учить модель выбирать, какие фрагменты смотреть. Для поиска локального события полезен выборочный просмотр, а для подсчёта по всему ролику — полный проход с агентами, если бюджет это позволяет. 🔗 Более подробно — в презентации Никиты (в комментариях файлом) и в записи выступления (тайминг: 2:36:30). #vlm #video #agents #multimodal #conference #paperwatch

  More
  
• 4 days ago94512 forwards19 reactions1 commentOpen in Telegram
  🧠 Модель выбирает правду или просто то, что проще выучить? Спросите LLM, правда ли, что человек использует только 10% мозга. Для некоторых моделей ответ скорее всего будет утвердительным. Хотя в претрейне они видели и этот факт, и опровержения. Откуда выбор, если претрейн противоречит сам себе? На AI RnD Day Константин Крестников, лидер GigaChain и автор канала @robofuture, рассказал, как проверял свою гипотезу: "модель тянется к истине потому, что истиной дешевле объяснять окружающий мир". Также у Кости приняли в основной трек NeurIPS 2026 статью "Truth as a Compression Artifact in Language Model Training" 🌿, на которой построено его выступление! Поздравляем! 🎉 📌 TLDR Чтобы не гадать по ответам готовых ассистентов, он собрал синтетические учебники по математике, где сам задавал верные и ложные правила, и обучал на этом модели. Случайные ошибки модель действительно вымывает: верное решение получает больше вероятности даже при 10% правильных примеров в корпусе. Но стоит сделать ошибку согласованной или вычислимой из условия — предпочтение исчезает. Таким образом, обучение убирает не ложь, а непредсказуемость. Оговорка: окончательного подтверждения гипотезы пока нет, исследования продолжаются. 🧪 Эксперименты Четыре типа математических задач: • цепочки арифметики • разложение на множители • линейные уравнения • производные многочленов Все решения проверяются программно, поэтому для каждой задачи точно известно, где правда. Половина решений верные, половина — с ошибкой в одном шаге. Далее добавляется контролируемая вариация ошибок: 1. Случайная — сдвиг числа на случайную величину, около 18 вариантов на задачу. 2. Ложное правило, например: a × b = a × (b − 1). 3. Выучиваемая ошибка — снова сдвиг, но какой именно, решает последняя цифра числа в условии по фиксированной таблице. 4. Несколько ложных правил до 10 штук, а выбор случайный и не угадывается по условию. Метрика на новых задачах — доля вероятности, которую модель отдаёт верному решению против ложных. 📊 Что получилось Случайные ошибки проигрывают. Против всей системы ошибок правда vs случайность получает 55% vs 45%. Согласованную математику проще выучить, чем запоминать разброс. А если есть одно ложное правило — то будет примерно 50/50 на всех размерах моделей. Модель не отличает согласованную ложь от правды. Выучиваемая ошибка получает 57% vs 43%. А если правило выбора усложнить, картина возвращается к случайной. Значит, дело именно в предсказуемости. 🔬 Ищем зависимости Длина ответа. Костя отдельно проверил влияние длины ответа модели. Вероятность текста зависит не только от содержания, но и от количества токенов, поэтому более короткая запись может получить преимущество. Поэтому основные сравнения проводили для решений с одинаковой длиной выхода. Умение считать. Может быть, модель делит вероятность между правильным и ошибочным решениями примерно поровну просто потому, что плохо умеет решать такие задачи? Для проверки модели тех же размеров обучили только на правильных примерах. Тогда при сравнении верного решения с набором ошибочных на него приходилось 96–99% их суммарной вероятности. На реальном тексте (20K абзацев Википедии) случайная подмена сущностей проигрывает оригинальному тексту в 70–71% случаев, а четкая замена France → Japan по всему корпусу — метрика на уровне 46–49%, то есть явного преимущества исходного текста не обнаружено. 🔚 Выводы Модели предпочитали закономерность случайному шуму, но устойчивое неверное правило усваивали наряду с правильным. Поэтому хорошее предсказание текста само по себе не гарантирует истинности ответа. Следующий шаг исследований — проверить, помогут ли независимые наблюдения, противоречащие ложному правилу. 🔗 Более подробно — в презентации (в комментариях файлом и в канале @robofuture) и в записи выступления (тайминг: 5:02:26). 📖 Статья на arXiv 🖥 Репозиторий на GitHub 🗒 Презентация #llm #interpretability #conference #paperwatch

  More
  
• 5 days ago3.3K56 forwards68 reactions7 commentsOpen in Telegram
  ⚡ Как ускорить LLM на длинном контексте На AI RnD Day Никита Арсенин разобрал альтернативы классическому механизму внимания и показал результаты экспериментов команды. Он рассказал, как современные LLM избавляются от главного ограничения обычного attention — квадратичной зависимости стоимости от длины контекста, и почему в новых моделях всё чаще появляются гибрные подходы. 📌 TLDR Ускорять внимание можно двумя способами: выбирать из контекста только нужные токены или сжимать историю в состояние фиксированного размера. Первый подход сокращает дорогую агрегацию, второй убирает растущий KV-кеш. Но у обоих есть ограничения по доступу к деталям, поэтому их комбинируют с полным вниманием. В экспериментах команды sparse attention дал ускорение генерации в 4,8 раза на длинном контексте, а гибрид GDN + Attention Residuals — отдельно +6,2 п. п. на MMLU. 🔎 Sparse attention: сначала найти, потом прочитать В классическом трансформере query сравнивается со всеми keys, затем модель агрегирует соответствующие values. А в показанной схеме разреженного внимания дешёвый индексатор просматривает контекст и выбирает top-k позиций. Дорогая агрегация выполняется только по ним. Для последовательности длины L её стоимость снижается с квадратичной O(L²) до O(Lk). Но поиск не бесплатный: в этой схеме индексатор всё ещё даёт квадратичный член. Выигрыш в том, что он заметно дешевле полного внимания. 🧠 Linear attention Отдельные key/value всех прошлых токенов не хранятся. Они последовательно обновляют матрицу состояния S. В простейшей схеме со слайда: Sₜ = Sₜ₋₁ + vₜkₜᵀ При фиксированных размерностях состояния память и стоимость одного рекуррентного шага не растут с длиной контекста: O(1) вместо O(L). Суммарная работа механизма внимания для L шагов становится O(L), а не O(L²). Обратная сторона медали — история сжата. Нельзя просто обратиться к отдельному старому KV, как в full attention. Поэтому гибрид может чередовать, например, три линейных блока с одним полным: большую часть слоёв сделать дешевле, но оставить доступ ко всем позициям контекста. 🛠 Инфраструктура Наивные реализации DSA и линейного внимания поверх LLaMA-3.1-8B-Instruct показали ускорение в 2,6–3,75 раза на длинном контексте. А при сравнении PyTorch-реализации Gated DeltaNet с FlashAttention-3 линейное внимание стало быстрее лишь примерно на 200K токенов. Наша команда не ограничилась заменой слоя: адаптировала cuDNN-ядра для DSA/NSA, написала Triton-ядра для DSA и DSA + sliding window attention, оптимизировала линейные механизмы и Attention Residuals. Последние меняют смешивание выходов по глубине сети, а не отбор токенов контекста. 📊 Что получилось Модель с разреженным вниманием MSA справилась с генерацией примерно за 1,9 секунды, а базовый вариант с обычным вниманием MQA — за 9,2 секунды. Ускорение — в 4,8 раза. В отдельном эксперименте гибрид GDN + Attention Residuals обошёл full-attention baseline на 6,2 п. п. по усреднённому MMLU после примерно 110В обучающих токенов. Важно отметить, что это результаты конкретных конфигураций, а не гарантия для любой LLM. 🔗 Более подробно — в презентации Никиты (в комментариях файлом) и в записи выступления (тайминг: 1:07:00). #llm #attention #conference #paperwatch

  More
  
• 6 days ago1.1K24 forwards32 reactions2 commentsOpen in Telegram
  🧠 Reasoning без километров текста: визуальные черновики и рекурсия Продолжаем технические разборы. Чтобы LLM лучше решала задачи, можно дать ей больше токенов на размышление. Но обязательно ли каждый промежуточный шаг превращать в текстовый ответ модели? На AI RnD Day наша Инесса Фёдорова рассказала об экспериментах с альтернативами длинным Chain of Thought: визуальными цепочками, маленькими рекурсивными моделями и зацикленными LLM. 📌 TLDR Модель может рисовать промежуточные состояния. В одной из работ прошлого года был интересный подход Sketch-of-Thoughts, который в чем-то похож на эту идею. Идея заменить обычный CoT на короткие структурированные “скетчи”. А в экспериментах с LoopLM удалось получить сопоставимое качество при одинаковом компьюте, но с втрое меньшим числом параметров. 🎨 Вместо описания картинки — новая картинка Для навигации, перемещения объектов и визуальных игр естественный черновик — последовательность состояний среды. Зачем описывать весь маршрут словами, если можно его нарисовать и проверить? Мы собрали более 300K мультимодальных цепочек и дообучили Bagel-7B-MoT. Внутри цепочки чередуются текстовое рассуждение, визуализация, рефлексия и ответ. Визуальные шаги генерировали инструментами, средой или диффузионными моделями, затем проверяли согласованность текста и изображений. Главная сложность — качество траекторий: текст может говорить одно, а картинка показывать другое. По наблюдениям команды, визуальные reasoner’ы к таким проблемам чувствительнее текстовых. ⚙️ STARM: рассуждать в скрытом состоянии Про эту работу мы уже писали в канале. STARM — наш открытый фреймворк для рекурсивных моделей, способных к многошаговым рассуждениям В рекурсивной модели промежуточное состояние проходит через вычислительный модуль повторно. Вместо новых слов — новые итерации обработки, а адаптивная остановка определяет, когда пора выдавать ответ. Модель на всего лишь 13М (!!) параметров обошла аналоги 🌿 и LLM на рассмотренных в работе бенчмарках. Но важно отметить, что это алгоритмические задачи, а не универсальная замена LLM, о чем Инесса честно говорит в докладе. 🔁 А если зациклить языковую модель? В LoopLM один набор слоёв применяется несколько раз, а exit gate отвечает за ранний выход. Команда воспроизвела результаты и получила сопоставимое качество при одинаковом компьюте с моделью, у которой в три раза меньше параметров. Здесь обучение пришлось стабилизировать, а вместо двух стадий претрейна обошлись одной. Мягкий старт, перемешивание данных и распределение 5% лосса по всем шагам сгладили обучение. А вот с адаптивностью вышла загвоздка: из-за структуры лосса модель выбирала выход на втором или третьем шаге, а не гибко подбирала глубину вычислений. 🛠 Можно не учить с нуля? Просто зациклить готовую модель не получилось: она предпочитала привычный "нулевой" шаг. Тогда добавили обучаемое смешивание выхода предыдущего шага с исходным входом: w × previous_output + (1 − w) × input. Вес w позволяет дозировать обновление. После этого модель начала использовать дополнительные шаги. В этих экспериментах самое интересное — не сам цикл, а то, как заставить модель им пользоваться. Возможность "подумать ещё" бесполезна, если обучение не делает следующий шаг полезным. 🔗 Более подробно — в презентации Инессы (оставим в комментариях файлом) и в записи выступления (тайминг 7:00:30). Важно отметить, что работа доступна в opensource! ♥ 🖥 GitHub 📄 Хабр #reasoning #llm #paperwatch #conference

  More
  
• Sep 242K39 forwards15 reactions2 commentsOpen in Telegram
  🧩 От слов к виджетам Сегодня UI обычно подстраивается под задачу: отдельный экран для покупки, карты, настройки или аналитика. Но с генеративными моделями появляется другой сценарий — интерфейс сам собирается под человека и конкретную задачу, в зависимости от рекомендаций и предпочтений пользователя. На AI RnD Day Ира Пионтковская рассказала, как может выглядеть такой подход и какие технические проблемы возникают на практике. 📌 TLDR LLM пишет код, браузер превращает его в интерфейс. Но кто проверит, что кнопки работают, график не врёт, а виджет отвечает на исходный запрос? Generative UI — это не просто "LLM рисует HTML". Модель должна сгенерировать работающий интерфейс, пользователь — взаимодействовать с ним, а система — понять, действительно ли UI решает задачу с приемлемым качеством. 💥 Красиво ≠ правильно У интерфейса как минимум три слоя проверки: внешний вид, поведение и смысл. Текст может читаться, кнопки — нажиматься, а задача всё равно останется нерешённой. Например, график расходов аккуратно сортирует дни недели по алфавиту. Визуально всё хорошо, а хронология потеряна. 🎙 Почему UI становится частью диалога В классическом интерфейсе пользователь говорит: "покажи шкафы глубиной до 40 см", а приложение показывает экран с результатами. В GenUI модель может создать сам интерфейс под текущую задачу: показать варианты, дать выбрать один, открыть план комнаты и позволить перетащить шкаф. Получается, что виджет становится частью реплики модели — примерно как жест или указание в разговоре. Это особенно интересно вместе с full-duplex voice: пользователь может сказать «этот сюда», модель — показать объект и место на экране, а пользователь — сразу изменить его положение. 🧠 Главная проблема — как проверить UI Сгенерированный HTML может выглядеть красиво, но при этом содержать смысловую или функциональную ошибку. Поэтому мы исследуем VLM-as-a-judge, которая получает запрос, код и скриншоты двух виджетов и должна определить, какой лучше решает задачу. На примере бенчмарка дефектов: берём корректный график и намеренно добавляем один дефект — обрезанный текст, наложение элементов, пропавший объект, подпись не по теме или противоречие с данными. Основной разброс появляется на задачах, где нужно обнаружить ошибку, а не просто прочитать изображение. Например, на обнаружении обрезанного текста Gemini 2.5 Pro дал 100% правильных ответов, GPT-5 — 92%, а Grok 4.20 — 31%. 🛠 Можно ли обучить самого судью? Да. Мы собрали пары из хороших и намеренно испорченных виджетов: перекрытия, блюр, зависания, подмена темы и другие дефекты. Затем дообучили Qwen3.6-35B-A3B. На тесте после DPO точность на повреждённых виджетах выросла с 66% до 100%, а среднее время ответа сократилось примерно с 820 до 25 секунд. 🤖 Следующий уровень — GUI-агент Визуальной проверки недостаточно. Интерфейс может выглядеть правильно, но кнопка не работать. Поэтому следующий шаг — дать GUI-агенту реальный сценарий: "Добавь дубовый шкаф в список покупок". Агент сам кликает по интерфейсу, выбирает нужный объект и проверяет состояние приложения. Если ожидаемый результат не достигнут, траекторию действий и ошибку можно вернуть генератору для исправления. Так появляется полноценный цикл: LLM генерирует UI → GUI-агент взаимодействует → проверяется состояние → ошибка возвращается генератору. 🔚 Выводы Generative UI — это следующий шаг после обычного chatbot-интерфейса: модель может не только отвечать, но и собирать форму взаимодействия под конкретную задачу. Но чтобы это работало в проде, одного сильного генератора недостаточно. Нужны проверяемые среды, модели-судьи и агенты, способные взаимодействовать с интерфейсом. В конечном счёте хочется прийти к системе, где каждой задаче — свой интерфейс, а его качество проверяется автоматически. А после доклада был задан очень хороший вопрос о недалеком будущем: "Будем ли мы жить в одном едином окне, в котором отражена вся наша жизнь?". Кажется, что все к этому идет! 🔗 Более подробно — в презентации Ирины (оставим в комментариях файлом) и в записи выступления (тайминг: 5:04:40). #genui #paperwatch #conference

  More
  
• Sep 221.2K8 forwards23 reactions1 commentOpen in Telegram
  🔎 Агенты-разведчики: ищем обучающие данные в хранилище без каталога Для претрейна речевых full-duplex моделей нужны сотни тысяч часов речи. Но найти подходящие данные — отдельная инженерная задача: датасеты раскиданы в S3-подобных хранилищах, у каждой команды свои наборы, а знания о них разбросаны по внутренним и внешним источникам, нужно постоянно все обновлять, в идеале без участия человека! В рамках AI RnD Day Максим Метальников рассказал, как мы решили эту задачу с помощью небольших AI-агентов, которые самостоятельно исследуют хранилище и собирают структурированную информацию о датасетах. 📌 TLDR В процессе бесконечного сбора речевых данных мы сделали агента-разведчика: он получает задачу, исследует доступное хранилище, скачивает небольшие сэмплы, анализирует аудио и метаданные, читает документацию и в конце формирует карточку датасета. Главная идея — разведка ≠ каталог. Нам не нужно описывать всё, что существует, и тратить время на лишнюю бюрократию. Нужно быстро найти данные, релевантные конкретной задаче. При этом агент работает локально, а данные о внутренних датасетах не уходят во внешние модели. ⚙️ Что внутри Важная часть архитектуры — self-contained tools. Тул — это буквально скрипт с docstring-шапкой. Функция discover_tools() собирает описания доступных инструментов и передаёт их агенту. Чтобы добавить новую возможность, достаточно положить ещё один файл в директорию. А выполнение унифицировано через один execute: модель сама может собирать shell-команды в последовательные пайплайны. 🔬 Как агент исследует датасет Разведка идёт примерно в таком порядке: 1. Листинг — что вообще лежит в хранилище: расширения, дерево каталогов, объём. 2. Семплирование — несколько файлов с начала, середины и конца датасета. 3. Анализ аудио — формат, sample rate, количество каналов, длительность. 4. Анализ метаданных — схема полей, транскрипты и другие доступные признаки. 5. Анализ документации — что написано о датасете в сопутствующих источниках. 6. Вердикт — насколько всё это релевантно исходной задаче. И здесь начинаются самые интересные проблемы. 💥 Проблема №1: слишком большие ответы тулов Если просто дать агенту s3-ls, то на большом датасете можно получить огромный список файлов. В одном из экспериментов тул вернул 128k объектов, ответ занял 65k токенов, а на выполнение ушло около 7 секунд. В результате агент умер раньше, чем успел что-либо понять. Вывод довольно важный: за размер результата отвечает тул, а не модель. Модель заранее не знает, сколько данных вернёт вызов. Поэтому бесполезно писать в system prompt "будь аккуратнее с большими ответами". ⏱ Проблема №2: бюджет на выполнение Даже если контекстное окно позволяет обработать большой ответ, у агента есть общий бюджет на время. Один неудачный вызов может съесть весь лимит. Более того, неоднозначное сообщение об ошибке может привести к повторению того же самого вызова. Поэтому статус выполнения тула становится фактически микропромптом. Например: "Do NOT repeat this command" или "Use a quick estimate, sample a few files". 🧩 Проблема №3: свободный формат результата Если просто попросить агента "опиши датасет", структура карточки начинает плавать. В одном запуске модель указывает параметры (domain, files, size и duration), в другом — что-то одно. Где-то может появиться информация, которой в реальности не было в источнике. Поэтому необходимые поля мы перенесли непосредственно в интерфейс тула write_card(). 🔚 Выводы Когда данных становится слишком много, проблема уже в том, как правильно дать модели доступ к внешнему миру. В результате агент превращается не просто в чат-бота, который умеет вызывать инструменты, а в полноценного разведчика — с ограниченным бюджетом, контролируемым поведением и структурированным результатом. И главное — такого агента можно переиспользовать другим командам для своих задач, не начиная исследование данных с нуля. 🔗 Более подробно — в презентации Максима (оставим в комментариях файлом) и в записи выступления (5:52:30 тайминг). #agents #speech #fullduplex #paperwatch #conference

  More
  
• Sep 211.3K29 forwards16 reactionsOpen in Telegram
  🎓 AI: Research in action AI-конференции продолжаются (и похоже не закончатся). Наши коллеги из Sber AI Lab зовут на закрытую конференцию «AI: Research in action». Формат: минимум 10 экспертных докладов, живые демо, возможность задать вопросы исследователям, которые строят этот самый AI. Рассмотрим, как устроены LLM и мультиагентные системы, а также обсудим применение ИИ для анализа поведения и прогнозирования в финансовом секторе. 🔬 О чём будет • Как устроены современные LLM и мультиагентные системы • ИИ для анализа поведения и прогнозирования в финансах • Результаты исследований 2025–2026, опубликованные на ACL, SIGIR, AAAI, IJCAI и других топовых конференциях • Путь от фундаментальной модели до продакшена Подробности 🗓 10 октября, 11:00 📍 Москва, Кутузовский 32к1 (update: корпус был изменен!) 💻 Очно или онлайн-трансляция 🔗 Программа и регистрация #conference #sber

  More
  
• Sep 202.4KOpen in Telegram
  🎙 Full-duplex voice mode Наша команда ведет исследования в речевых технологиях, и одна из задач, которую мы решаем — это создание полнодуплексного голосового режима. Это такой класс моделей, которые могут одновременно слушать и говорить, не разбивая диалог на последовательные вызовы. В рамках прошедшей AI RnD Day наши ребята Артемий и Данило рассказали, как это всё устроено и куда движется мир. 📌 TLDR Классический голосовой ассистент — это каскад ASR → LLM → TTS + VAD. Пользователь говорит, VAD ждёт конец реплики, ASR переводит речь в текст, LLM думает, TTS озвучивает ответ. Задержка у такой системы складывается из нескольких компонент, а диалог с моделью не нативен. Full-duplex устроен иначе: модель может слушать пользователя, говорить, реагировать на перебивания и менять свою реплику прямо во время разговора. Главный вызов — сделать такую модель не только естественной, но и управляемой: задать ей роль, характер, голос и при этом не потерять качество основной LLM. А в самом продвинутом варианте добавить мультимодальность, ризонинг, тулколинг и прочий "обвес", включая опции для решения VLA-задач в роботах. 🤖 🧭 Откуда всё началось В 2022-2023 году появились GSLM и AudioLM — работы, показавшие, что речь можно моделировать непосредственно аудио-токенами, без обязательного промежуточного текста. В 2024 году Moshi от Kyutai сделал следующий шаг — открытая full-duplex модель, которая одновременно слушает и говорит, моделируя аудио пользователя и модели вместе с текстовым внутренним представлением. В начале 2026 появились подходы вроде PersonaPlex от NVIDIA 🖥 (надстройка над Moshi), где к full-duplex добавляется управляемость: текстовый prompt задаёт персонажа, а аудио-референс — голос. А дальше индустрия начала двигаться к более общему подходу: разделению реалтайм взаимодействия и мышления на части. Эту идею, в частности, развивает Thinking Machines, стартап Миры Мурати. ⚙️ Что не так с обычным Full-duplex Исходная модель действительно умеет разговаривать, но для продукта этого недостаточно: каждый запуск с новым голосом, персонаж и манера речи не фиксированы, нельзя задать бизнес-роль ассистента. И самое важное: модель "тупеет" при улучшении качества речи, и наоборот, а компромиссного варианта нет. . 🧠 Thinker + Duplex Talker Чтобы не заставлять одну модель делать всё сразу, мы перешли к тандемной архитектуре. Thinker — большая LLM, которая отвечает за содержание и сложный ризонинг. Duplex Talker — лёгкая RQ-трансформерная "говорилка", работающая в full-duplex режиме. Talker продолжает слушать и говорить в реалтайме, а Thinker своевременно подсказывает, что стоит сказать. Ключевой момент — обмен идёт в общем текстовом домене. Благодаря этому основную LLM можно менять независимо от голосового слоя. 💡 Как работают подсказки Мы не заставляем Thinker генерировать новый ответ на каждый аудиокадр. Для обучающих данных берём реплику пользователя и постепенно раскрываем её. На каждом этапе большая LLM предсказывает, что ответит второй участник диалога. Так формируется поток подсказок. Talker может начать отвечать раньше окончания фразы пользователя, а по мере появления нового контекста получать более точные подсказки. 📚 Как обучали Обучение проходило в несколько этапов: — text-to-text + TTS для связи текста и аудио — естественные и синтетические диалоги — system prompts и audio references — симуляция hint stream от большой LLM — синтетика, аугментации и дообучение под конкретные сценарии В датасетах смешиваются TTS, естественные разговоры, синтетические диалоги, фактологические данные, voice-референсы и примеры работы с подсказками. 🔚 Выводы Тандем Thinker + Duplex Talker позволяет разделить задачи и сохранить главное преимущество full-duplex-систем — realtime-взаимодействие без возврата к классическому каскаду. А в конечном счёте, он расширяется до нативной омнимодальности со всей мощью ризонинга, тулколинга и действий в среде. 🔗 Более подробно смотрите в презентации ребят (оставим в комментариях файлом) и в записи выступления (6:29 тайминг). #speech #voice #fullduplex #paperwatch

  More

The channel in numbers

Created

May 24, 2023

Photos

373

Videos

14

Files

3

Links

214

Telegram data as of October 1, 2026

Rankings and collections

• AI: what to readcollection

Contacts

Contact

@hukenovs

From the channel description

Reviews

No reviews yet. Yours would be the first.

Similar

More on this topic