USRW 2026: Call for Papers — дедлайн продлён до 27 июля 🔎 Это тот самый Unified Search and Recommendation Workshop, который я недавно упоминал в посте про мои воркшопы на RecSys. Теперь можно наконец рассказать подробнее: мы опубликовали программу и открыли приём статей. Для меня это первый опыт организации отдельного воркшопа — и особенно приятно, что он посвящён теме, вокруг которой, собственно, и строится этот канал. Главная идея USRW проста: поиск и рекомендации слишком долго развивались как разные дисциплины, хотя обе решают одну и ту же задачу — помогают человеку найти нужный контент. С появлением LLM, generative retrieval и агентных систем граница между query-driven search и feed-driven recommendation становится всё менее естественной. Но «объединить» не значит просто объявить поиск и рекомендации одной и той же задачей. Мы хотим разобраться, что действительно можно сделать общим — данные, представления, генерацию кандидатов, ранжирование, интерфейсы и протоколы оценки, — а где различия в сигналах, UX, задержке, стоимости и управляемости остаются принципиальными. В программе: 🎤 Mounia Lalmas (Senior Director of Research, Spotify) — «Building AI-Driven Experiences at Scale: When Search and Recommendation Become One Conversation» 🎤 Harrie Oosterhuis (Associate Professor, University of Amsterdam / Amazon Scholar Amazon Music) — «Learning to Rank Everything, Everywhere and All at Once» 🧭 Dive Deep tutorial, который мы проведём вместе с Gustavo Penha. Поговорим об общих корнях поиска и рекомендаций, слоях их возможного объединения, semantic IDs, generative retrieval, языковых интерфейсах, агентах и реальных production-компромиссах. В Call for Papers ждём работы про: • единые модели поиска и рекомендаций; • общие представления пользователей и объектов; • моделирование поведения между search- и feed-сценариями; • LLM для понимания запросов и намерений; • generative retrieval, semantic IDs, RAG и agentic discovery; • смешанные поисково-рекомендательные интерфейсы; • общую инфраструктуру и методы оценки; • эффективность, устойчивость и безопасность; • индустриальные кейсы, датасеты и benchmarks. Формат: 4–9 страниц без списка литературы, ACM SIGCONF, двойное слепое рецензирование. Воркшоп неархивный: принятая статья будет размещена на сайте USRW, но авторы сохраняют право впоследствии отправить её расширенную версию в конференцию или журнал. Также выберем лучшую работу для Best Paper Award. ⏰ Дедлайн подачи: 27 июля 2026 года, 23:59 AoE 📍 Воркшоп: 2 октября 2026 года, Миннеаполис, ACM RecSys 2026 🔗 Сайт, полный CFP и подача статьи: https://usrw-workshop.github.io/2026/ Организуем USRW вместе с Sean MacAvaney (University of Glasgow), Gustavo Penha (Spotify), Léa Briand (Deezer) и Clémence Vast (Deezer). Если у вас есть работа на стыке поиска и рекомендаций — от новой модели до индустриального кейса или benchmark, — буду очень рад увидеть её на USRW. И буду благодарен, если перешлёте этот анонс коллегам, которым тема может быть близка 🙌

Asynchronous Reasoning: Training-Free Interactive Thinking LLMs Сегодня поговорим о статье, в написании которой принимали участие инженеры Яндекса. Публикация посвящена асинхронному ризонингу, а в её основе лежит метод, описанный в работе Hogwild! Inference: Parallel LLM Generation via Concurrent Attention, поэтому сперва — кратко о ней. Это тоже статья от Yandex Research, а также от HSE и IST Austria. Авторы поставили перед собой задачу ускорить инференс с помощью параллельной генерации. Для этого ввели понятие Cash Blocks. Есть блок common cash, где находится общий промпт (например, решить какое-либо уравнение), и есть блоки «рабочих» (workers) — других потоков генерации той же LLM, которые выполняют задачу, синхронизируясь через KV-кэш. В статье эти блоки называются Алиса и Боб. Для генерации токена Алисы нужно, чтобы блоки стояли в порядке common-Bob-Alice, а для Боба — common-Alice-Bob. Так каждый «рабочий» может генерировать свои токены, «видя» чужие генерации, и они могут в реальном времени общаться между собой. Для генерации нового токена блоки KV-кэша упорядочиваются по-разному для каждого «рабочего». Сдвиг осуществляется не над всем блоком, а над query-токенами, что снижает вычислительные издержки. Это суть метода, а подробнее о Hogwild! мы писали в этом посте. Идея асинхронного ризонинга немного иная. В Hogwild! разбивали большую цепочку ризонинга на параллельные фрагменты для обработки двумя «рабочими», чтобы добиться некоторого ускорения. При этом Алиса и Боб — почти симметричны, лишь немного отличаются промптами. Однако сами кэш-блоки в теории могут отличаться: один, например, может быть обёрнут в ризонинг-токены, а другой нет. Также не обязательно генерировать по одному токену для каждого «рабочего» за форвард, как это сделано в Hogwild! Из этих предпосылок и рождается идея AsyncReasoning. Суть такова: есть также два потока одной LLM — writer и thinker. Первый генерирует выходные токены, а второй — ризонинг-токены. Благодаря этому появляется возможность генерировать ответ раньше, чем завершился ризонинг. С точки зрения thinker, токены writer — это предыдущий шаг генерации, а writer «живёт» в рамках одной непрерывной генерации. Чтобы сделать этот сетап более интерактивным, — скажем, в случаях, когда thinker надо подольше подумать — используют переключение режимов (mode switching). По сути, это отдельный view, от которого модели задаётся вопрос «Достаточно ли моих текущих измышлений, чтобы написать следующий параграф или формулу?» (Wait, are my current thoughts enough to write the next paragraph or formula?) В зависимости от ответа — да или нет — writer либо включается, либо ждёт дальше. Вопрос задаётся каждые 20 шагов. Замеры в основном проводились на математических датасетах. Кроме того, замеряли delay — суммарную длительность пауз, которые происходят при переводе ответа модели в звук. Благодаря mode switching writer генерирует токены не на каждом форварде, а перевод ответа в звуковое представление позволяет лучше зафиксировать те самые паузы между генерациями. Также измерялось time to first token. Как показали эксперименты, ещё AsyncReasoning помогает повысить безопасность модели. Разбор подготовил ❣ Георгий Якушев Душный NLP

Маленький каминг-аут Последние месяцы я работаю в новом стартапе, его делает Саша. Вчера мой друг Кирилл выпустил с ней подкаст, можете послушать замечательных людей! Что за стартап? Конечно же, AI stealth neolab, которая занимается фундаментальными LLM исследованиями. До недавнего времени это был настолько стелс режим, что мы даже о существовании компании особо не рассказывали. Сейчас мы все еще немного скрываемся, поэтому много подробностей рассказать не могу. Что я там делаю? Я понемногу сдвигаюсь от продуктовых ролей и перехожу больше в решение разных бизнесовых вопросиков. Я всегда работал в B2B стартапах, поэтому помимо чистой продуктовой работы была большая часть, связанная с продажами, Customer Success, Partnerships и другими темками. Ну а сейчас я прыгнул в этот бассейн с головой. Надеюсь, что через некоторое время смогу рассказать вам что-нибудь еще.

Для того чтобы погонять Fable 5, пришлось вернуть подписку на Клода. В целом чувствуется, что модель сильнее Opus 4.8 (это проявляется в мелких деталях, подробнее писал в ИИ-лаборатории нашего клуба), но глобально ничего не меняется. Но вот что меня поразило, так это мои ощущения от использования Claude Code: как же я отвык от human in the loop, сидеть и постоянно контролировать - это не мое. У меня сейчас для работы сделано два оркестратора. Один реализует проектный SDLC, второй - общего назначения. Они связаны друг с другом и могут обмениваться заданиями и статусом выполнения, в общем агенте есть общий чат куда прилетают отчеты о выполнении. Развиваю проекты инкрементами, которые выглядят примерно так:

$soerdev add spec "Новая фича"
$soerdev refine spec
$soerdev plan
$soerdev run

Это реализация цикла Human ON the loop. Логика такая: добавляем драфт спеки, обсуждаем детали, фиксируем план, запускаем цикл до выполнения критериев останова. В работу не вмешиваюсь, но вижу в чате и телеграм боте что происходит. И знаете что? Это реально удобно! Теоретически что-то подобное можно настроить и в CLI-агентах, но все равно придется допиливать харнес для отправки сообщений в телеграм, делать свой аналог гейтов, делать скилы и промпты. А так все зашито в оркестратор soerdev.

Открытые модели догнали фронтир – и это плохая новость для Anthropic Хорошая статья и правильные мысли. Пострадает от китайцев в первую очередь Антропик. Вот почему: – Главная статья расходов после обучения – инференс, то есть использование видеокарт и электричество – Три стратегии: арендовать дата-центры (Anthropic, Moonshot, Knowledge Atlas), строить свои (Meta, Alibaba) или владеть и генерацией, и дата-центрами (SpaceX) – Чем больше стека ты контролируешь, тем больше переменных затрат превращаются в фиксированные – и тем быстрее растет маржа с ростом использования – Если инфраструктуры нет, твои затраты масштабируются вместе с выручкой – маржа не растет Почему Anthropic в уязвимой позиции – Компания без собственной инфраструктуры выживает только за счет спроса на модели: нужно быть либо лучшей, либо дешевой и «достаточно хорошей» – Fable 5 – лидер по качеству, но почти в 3 раза дороже конкурентов в пересчете на выполненную задачу (данные Artificial Analysis) – Ставка на продукты-«харнесы» (Claude Code, Cowork) рискованна: барьер входа в этот сегмент почти нулевой. – У OpenAI, наоборот, модели немного слабее, но есть более понятные защиты вокруг: консьюмерский продукт, голос, железо и готовность инвестировать в собственные дата-центры В 2025-м открытая модель догнала фронтир один раз – сейчас это делают сразу несколько лабораторий (GLM 5.2, Kimi K3, Qwen 3.8). Это уже устойчивый паттерн: догоняют, конкурируют и, возможно, скоро начнут обгонять – особенно с учетом цены Вывод автора: model-only компании (Anthropic, Moonshot, Knowledge Atlas) стратегически проигрывают тем, кто владеет инфраструктурой и дистрибуцией – OpenAI, Alibaba, Meta, Google, SpaceX. Текст хороший, но с одной слепой зоной: автор сводит защищаемость к инфраструктуре и недооценивает энтерпрайз-инерцию. Компании, которые уже встроили Claude в свои процессы, комплаенс и безопасность, не мигрируют на открытую модель из-за 3-кратной разницы в цене инференса – стоимость переключения выше. Но часто задают вопрос: «а можно то же самое на open-source в нашем контуре?» Раньше честный ответ был «нет». Приходилось либо мириться с "глупостью" опенсорса, либо анонимизировать данные. После Kimi K3 и Qwen 3.8 он все чаще будет «да, и возможно даже дешевле» (если конечно у вас есть деньги на серверную стойку). https://www.emergingtrajectories.com/lh/frontier-lab-economics/

Почему стоит держаться подальше от OpenCode Интересный обзор от инженера Luke Wren. Автора бесит и качество работы, и безопасность. 1. Тратит ваши деньги впустую Когда агент общается с LLM, провайдеры (Anthropic, OpenAI) умеют кешировать уже отправленный контекст: повторно те же токены стоят в разы дешевле. Но кеш работает только если начало разговора не меняется ни на символ. OpenCode ломает это постоянно: перечитывает одни и те же файлы заново, вставляет в промпт текущую дату (изменилась минута – кеш умер), выкидывает куски контекста без необходимости. Итог – вы платите полную цену за токены, которые могли стоить копейки. Вторая беда – обрезка контекста. Если прервать агента на полпути, он может «забыть» важное – например, спеку проекта, которую вы ему скормили. Дальше он работает, не помня, что вообще нужно было сделать. Плюс мелочи: с подагентами нельзя пообщаться, когда они тупят, интерфейс в терминале жрёт память, ломает многострочный ввод и не поддерживает базовые шорткаты редактирования. 2. Это дыра в безопасности AI-агент выполняет команды на вашем компьютере. Чтобы он не натворил дел, ему нужны ограничения – «вот это можно, вот это спрашивай у пользователя». Вопрос в том, как эти ограничения устроены. OpenCode проверяет команды по тексту: смотрит на строку, которую агент хочет выполнить, и решает, опасная она или нет. Например, можно запретить команды git. Проблема: shell – это полноценный язык программирования, и одну и ту же команду можно записать бесконечным числом способов. Автор показывает десять обходов, вот пара для понимания: – echo 'git clean -fdx' | bash – формально это команда echo, «безобидная». Но она передаёт запрещённый git прямо в shell, и тот выполняется – python3 -c 'import subprocess; subprocess.run(["git", "checkout", "."])' – формально это python, а не git. Фильтр пропускает То есть запрет работает только против агента, который не пытается его обойти. А LLM может обойти его даже случайно, просто потому что так «удобнее» написать команду. Дальше хуже. Кнопка «Always» (разрешить навсегда) запоминает разрешение слишком широко: один раз одобрили безобидный echo hello – и теперь агент может выполнить echo 1 > /sys/class/gpio/gpio21/value. Это уже запись в системный файл. Перенаправление вывода (>) вообще не проверяется. И на десерт: у OpenCode уже был CVE – уязвимость, при которой можно выполнять произвольные команды на машине пользователя. Показательно, как закрыли issue об этом: его закрыл бот для «протухших» тикетов. Не человек, разобравшийся в проблеме, – бот, который чистит старые обращения. Автор говорит: фильтровать команды по тексту – бесполезно в принципе, это "и так сойдет", а не безопасность. Настоящая изоляция делается средствами операционной системы: Landlock в Linux, Seatbelt в macOS – механизмы, которые физически не дают процессу трогать файлы за пределами разрешённых. Тогда неважно, как хитро записана команда, – ОС просто не даст ей навредить. Стоит прочитать целиком, если пользуетесь, особенно раздел с обходами правил безопасности. https://wren.wtf/shower-thoughts/stop-using-opencode/

2 пачки новых оптимизаций и SOTA. Много разных направлений, в основном все вокруг контекста / окна контекста / работы с деградацией / работы с мульти агентскими системами фрактальными (оркестраторами и общим контекстом), 3х уровневый слой памяти и оптимизация структуры/алгоритмов. + всякие другие оптимизации / симбионты склеянные из открытых источников. Можете скормить своим LLM/AI/агентам картинки - что-то могут выцепить и улучшить. Собираю дальше архитектуры/blueprints/расширения/модули для AI IDE и собираю на коленке через opensource свой кастомный AI IDE с полный контролем окна контекста и всех уровней памяти. -> какие-то вещи похожие есть в Hermes, но не то.

Нейродайджест за неделю (#123) LLM - Fable 5 — Anthropic оставляет топовую модель в подписках Max и Team Premium. Пользователям Pro и Team разово выдадут $100 кредитов. - Kimi K3 — Moonshot выпустили новый претрейн на 2,8 трлн параметров, обгоняющий Opus 4.8. Доступен в API, веса откроют до 27 июля. - T-Search — экономный агентнвй ретривер на базе Qwen3.6. MoE-модель умещается на одной GPU и обходит открытые гиганты вроде Qwen3.5-397B. - GigaChat Audio — опенсорс мультиязычный стек для распознавания речи GigaAM Multilingual и audio-native LLM с окном контекста до 2 часов. Генеративные модели - Слив Suno — Масштабная утечка исходников подтвердила использование миллионов треков с YouTube Music и других площадок для обучения генератора. - MIRA — World model с мультиплеером от kyutai и Epic Games. Это нейронная версия Rocket League, поддерживающая 4 игроков или бесконечную игру самой с собой. Прочее - Клавиатура для вайбкодинга — OpenAI выпустили девайс в магазине мерча за $230. В комплекте кнопка «принять изменения», регулятор ризонинга и кастомные кейкапы. > Читать дайджест #122 #дайджест @ai_newz

Сможете ли вы найти пять ошибок в Python-коде, который вызывает LLM Вызов языковой модели давно стал обычной строчкой. Импортировали клиент, отдали промпт, забрали ответ. С обычными ненадёжными зависимостями питонист управляется отлично, ставит таймаут, вешает retry, помнит про идемпотентность. А вызов модели попадает в код так, будто это локальная функция, без оглядки на то, что она платная, медленная и недетерминированная. Дальше всё вылезает по очереди. asyncio.gather запускает десять тысяч корутин разом, провайдер отвечает лавиной отказов, и неудачные запросы тоже съедают лимит. Таймаут срабатывает на клиенте, а модель дописывает ответ до конца, и токены считают все, так что за одну использованную генерацию можно заплатить как за четыре. А тест на равенство строк зеленеет ровно до дня, когда один и тот же промпт с нулевой температурой вдруг отдаёт разные ответы. Разберём пять мест, где поход по сети мстит за отношение к нему как к локальному вызову.

⚡️ Создатель XLNet, который вернулся в Китай и построил Moonshot AI На GTC 2026 выступил Ян Чжилинь, 34-летний основатель и CEO Moonshot AI, компании, стоящей за моделями Kimi. Его путь начинался в Университете Цинхуа. Затем Ян получил PhD в Carnegie Mellon, стажировался в Google Brain и Meta AI, работал с Куоком Ле и Джейсоном Уэстоном. Его исследования пересекались с работами Йошуа Бенжио и Яна Лекуна. Широкую известность ему принесли Transformer-XL и XLNet. Обе работы пытались решить одну из ключевых проблем языковых моделей: потерю информации из далёкого контекста. Статью про XLNet впоследствии процитировали более 10 000 раз. После учёбы Ян мог продолжить карьеру в американском Big Tech, но вернулся в Китай. Он участвовал в развитии крупных китайских ИИ-проектов, основал Recurrent AI, а в 2023 году запустил Moonshot AI в Пекине. Исследования длинного контекста стали основой продуктов компании: - Kimi K2 получила MoE-архитектуру на 1 трлн параметров - Kimi K3 добавила нативное зрение, контекст на 1 млн токенов и 16 активных экспертов - компания сделала ставку на программирование, агентов и работу с большими объёмами информации Moonshot AI привлекла инвестиции Alibaba, Tencent и других крупных компаний. За несколько лет стартап превратился в одного из заметных участников китайской гонки frontier-моделей. Ян объяснял возвращение просто: он боялся всю жизнь сожалеть, если не попробует создать собственную компанию. Опыт, полученный в глобальной исследовательской среде, может быстро превратиться в технологическое преимущество целой страны. Его полное интервью можно посмотреть здесь: https://www.youtube.com/watch?v=CwePo4847ho @ai_machinelearning_big_data #Moonshot #kimi