Быстрый ответ Алисы AI — это самый массовый генеративный продукт Яндекса и первое соприкосновение с Алисой для пользователей Поиска. 

Даже в час пиковой нагрузки пользователь должен получить лаконичный ответ за считаные секунды. Для этого мы, команда Alice AI Search, адаптируем весь пайплайн быстрых ответов — от собственного претрейна с кастомной архитектурой до онлайн‑rl‑обучения на поведенческие сигналы пользователей.

В статье разберём, как устроен генеративный ответ в Поиске, и расскажем про основные улучшения июньского релиза: как мы ускорили ответы за счёт коротких инфоконтекстов, зачем совместили Encoder‑Decoder с разреженной MoE‑архитектурой и как обучение на реальных пользовательских сигналах повлияло на качество и использование продукта.

Кроме того, мы выложили в открытый доступ обученную с нуля модель Alice AI‑T5-35B‑A0.6B Base с тем ограничением, что внешним пользователям доступен инференс через Hugging Face Transformers, а оптимизированный production‑инференс пока доступен только внутри Яндекса.

Представьте: ночной алерт, приложение отдаёт пятисотки, но само оно живо. Понятно, что дальше начнётся знакомое — вкладки с графиками, поиски в логах и попытки понять, кто и что изменил. Сколько на это обычно уходит времени? А что, если вместе с вами в инциденте будет разбираться ИИ-агент?

Привет! Я Антон Воронцов, CRE в Yandex Cloud. В конце июля я в очередной раз листал свежие репозитории на GitHub, чтобы посмотреть, что происходит в моих смежных дисциплинах: SRE, автоматизациях и, понятное дело, ИИ. Вдруг я наткнулся на один интересный репозиторий, который активно рос: количество звёзд, коммиты и заинтересованные люди из разных стран — всё это про OpenSRE.

Эта статья о том, как я впервые контрибьютил во внешний проект, что стало самым сложным и как вообще работает этот инструмент. 

Всем привет, меня зовут Миша, и я бэкенд‑разработчик в платформе Яндекс Еды. Я уже рассказывал, как мы анализировали наш PHP‑монолит и вынесли из него процессинг заказов, и с тех пор роль этого легаси заметно уменьшилась. Заодно туда стали писать гораздо меньше нового кода, релизы стали реже, и он спокойненько себе работал, не привлекая лишнего внимания. 

Так оно бы и продолжалось, но тут случилась повышенная нагрузка и необходимость зарезервировать побольше мощностей для беспроблемной обработки повышенного спроса. Монолит справился на отлично, но самое интересное случилось потом: возвращая выделение ресурсов к прежним значениям, я случайно обратил внимание, что RPS в пиковые вечерние часы как‑то подозрительно совпадает с количеством ядер CPU, выделенных на весь монолит.

Количество выделенных ядер, конечно, ещё ничего не означает, поэтому я полез смотреть реальное потребление процессорного времени, сложив CPU usage по всем подам. С помощью нехитрой арифметики я обнаружил, что 100% загрузки одного ядра приходятся на 2,5 RPS. Какое‑то время я находился в состоянии глубокого изумления, после чего решил, что это никуда не годится, и отправился в увлекательное приключение на 20 минут. 

Немного спойлеров: дело оказалось далеко не только в PHP. 

На устройствах под управлением ОС Android можно выбрать ассистента по умолчанию — почти так же, как браузер. Один раз выбираете в настройках — и дальше открываете его системным жестом поверх любого приложения. Удобно.

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

Меня зовут Ваня, я руководитель команды Android-разработки SDK Алисы и техлид проекта дефолтного ассистента. Сегодня мы с вами разберёмся, где проходят эти границы, на примере Алисы AI.

Когда мы запускали IDM, задача казалась понятной: избавиться от хаоса в компании. Не было единого места, где можно узнать, у кого какие права, кто их выдал и почему. 

IDM стал таким местом — и почти сразу мы уперлись в проблему. Очередь на подключение к IDM начала превышать количество уже подключённых систем, а фич-реквесты от команд копились быстрее, чем мы успевали их разобрать. Инструмент против хаоса сам стал источником хаоса.

Ещё недавно Алиса отвечала на текст и на картинку будто двумя разными голосами. Под капотом и правда жили две генеративные модели: текстовая LLM и визуальная VLM, а между ними — стена из непрозрачного роутинга, разных форматов ответов и разной вёрстки. 

Почти год мы сводили их в одну омнимодель — такую, которая воспринимает текст и изображения как единое целое, без переключений за кадром. Получилось не всё и не сразу, но путь вышел поучительным, и в этой статье я хочу поделиться тем, что мы поняли про обучение таких моделей. Попутно — несколько неочевидных поворотов: почему за два года до этого та же затея разваливалась, что изменила MoE‑архитектура, почему омнипретрейн пришлось собирать с конца и почему один вид RL переезжает на большую модель легко, а другой рассыпается прямо на глазах.

Меня зовут Алексей Григорьев, я представляю большую команду разработки омнимодели Яндекса. Вместе с моим коллегой Данилой Кашиным я расскажу про все технические грабли не со стороны наблюдателя, а как их непосредственный собиратель. Но рассказывать я буду с акцентом не на красивом замысле, а на самой болезненной части — алайнменте.

Разворачивать новый кластер базы данных каждую неделю — так себе удовольствие, особенно когда обслуживание десятков кластеров съедает время дежурных. Когда кластеров стало много, локальные аномалии стало сложнее замечать на общих дашбордах.

С этой проблемой мы столкнулись в Яндекс Трекере: за год количество активных организаций и кластеров выросло вдвое, а нагрузка на сервис поднялась всего на 13%. Получилось парадоксально: потребление ресурсов и сложность эксплуатации росли вместе с числом организаций, хотя реальная нагрузка увеличивалась значительно медленнее.

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

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

Мы разработали PereStruct — модульный пайплайн для разбора исторических газет. Он объединяет детектор вёрстки на базе YOLO, Yandex Vision OCR, коррекцию ошибок с помощью моделей Yandex AI Studio и отдельную модель семантической сборки статей. Вместе с кодом мы публикуем размеченный датасет и бенчмарк, чтобы другие команды могли изучать подход и ставить эксперименты на исторических документах.

За 15 лет WebPKI — экосистема доверия между сайтами и пользователями — сильно выросла. Появились технологии, которые делают это доверие более прозрачным и проверяемым, изменились подходы к управлению, а многие процессы стали автоматическими: выпуск и обновление сертификатов, публичный аудит через Certificate Transparency и другие механизмы. 

И, конечно, в истории WebPKI были серьёзные инциденты безопасности, которые показали: правила доверия должны быть публичными, прозрачными и проверяемыми.

Однако один вопрос не решается автоматически: кому браузер должен доверять и на каких условиях. Каждый вендор определяет это сам. Поэтому мы открываем Yandex Browser Root Certificate Program — публичную программу добавления корневых сертификатов в хранилище Яндекс Браузера. В ней описаны требования к участникам, аудит и понятная процедура подачи заявки.

Под катом рассказываем, какие требования нужно выполнить и как в Браузере устроены WebPKI и связанные с ними контроли безопасности.

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

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

Почта — массовый продукт, которым пользуются самые разные люди, и поэтому он должен быть максимально доступен. Нам важно, чтобы приложение Яндекс Почты было удобно каждому, в том числе людям с особенностями зрения. 

На телефонах с Android за доступность для людей с особенностями зрения отвечает TalkBack — функция озвучивания экрана, которая зачитывает текст, роль и состояние всех размеченных элементов на экране и позволяет с ними взаимодействовать. Если разметка сломается, приложением будет пользоваться сильно сложнее или вообще невозможно.

Зачем тратить сутки на перелёты, мчаться на другой конец света и жить неделю в режиме нон‑стоп на одной из главных ML‑конференций планеты, когда пейпер уже на arXiv, код — на GitHub, а краткие выжимки из выступлений — мгновенно в соцсетях?

Меня зовут Карина Романова, я разработчик в Яндексе и занимаюсь LLM‑агентами в Алисе. В июле мы с командой прилетели в Сеул на ICML 2026, и я ответила себе на вопрос «зачем?». Для нас офлайн‑конференции — это единственный способ за несколько дней прочувствовать реальный фокус сообщества, встретиться с авторами работ и узнать детали, которых нет в опубликованных текстах.

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

Представьте ситуацию: вы выкатываете новую фичу, а бэкендер спрашивает вас: «Слушай, а почему вместо событий — пустой объект?». Вы в шоке: «Как так — пустой объект? У меня же TypeScript, всё типизировано, такого не могло быть!». Спойлер — могло. 

Меня зовут Денис Платонов, я старший разработчик интерфейсов в Телемосте и я отвечаю за on-premise развёртывание веб-клиента Телемоста в инфраструктуре заказчика. В этой статье я расскажу о том, как безобидный на первый взгляд Omit превратил наш аккуратный тип событий в пустой объект. Заодно разберём, как работает дистрибутивность типов в TypeScript и поделимся, чему нас научил этот кейс.

Первыми проблему на проде видят пользователи — а значит, вы уже теряете деньги или репутацию. Поэтому откатываться нужно быстро, а на наших масштабах — очень быстро: в RuntimeCloud, внутреннем облаке Яндекса, работает миллион контейнеров на ста с лишним тысячах серверов.

Во времена tar-архивов откатывались со скоростью переключения symlink. В современном мире деплой умеет то, что раньше и не снилось, — он научился изоляции, декларативности и воспроизводимости. Только про быстрый откат многие забыли. 

Привет! На связи Антон Полухин из Техплатформы Городских сервисов Яндекса. Недавно в Брно состоялась встреча международного комитета по стандартизации языка программирования C++, в которой я принимал активное участие. В этот раз началась работа над C++29 и как раз о новинках и хочется рассказать.

Привет, Хабр! Меня зовут Степан Пестерников, мы с командой делаем Алису и активно используем СУБД Яндекса. Недавно коллеги из YDB провели большой рефакторинг в YDB Go SDK, где по умолчанию теперь используется новый Query Service.

Я воспользовался этим рефакторингом, чтобы уменьшить количество сетевых запросов от SDK к YDB. Клиентские SDK устанавливают к распределённой СУБД Яндекса gRPC-подключения, поверх которых отправляются низкоуровневые команды. Какие-то из этих команд можно объединять: например, команду начала транзакции и выполнения первого запроса.

В статье я покажу фрагменты кода и расскажу, как мы делали улучшения, которые вошли в релизы v3.126.0 и v3.126.5 Go SDK. Фрагменты кода получились небольшие, и на их примере удобно показать, как этими оптимизациями пользоваться.

Хороший мониторинг помогает быстро понять, что происходит с приложением и куда смотреть в первую очередь. Для этого не нужно пытаться измерить всё: базовый набор технических метрик покрывает большинство типовых проблем, а бизнес-метрики, SLO и анализ аномалий помогают заранее замечать нетипичные отклонения. В Календаре мы называем этот подход правилом 80/20.

Всем привет! Меня зовут Настя, я бэкенд-разработчик в Яндекс 360 и отвечаю за надёжность Календаря. В этой статье я покажу, какие метрики стоит взять за основу, как выбирать полезные алерты и чем дополнять базовый набор для оставшихся 20%.

В России около 70 тысяч детей и подростков страдают от ревматических патологий. Это группа заболеваний, при которых иммунная система даёт сбой и атакует собственные ткани — чаще всего суставы. Примерно раз в год ребёнку положена госпитализация в федеральный центр, чтобы проверить состояние и убедиться, что конкретный тип терапии работает. Однако, когда ребёнок возвращается в родной город, рядом может не быть ни одного врача, который знает, что делать с этой терапией.

На связи Юлия Шеянова, менеджер проектов в здравоохранении, Центр технологий для общества Yandex Cloud. В этой статье расскажу, как мы в Yandex Cloud вместе с Ассоциацией детских ревматологов (ASPiRRe) и студентом ИТМО сделали ИИ-агента для системы дистанционного мониторинга. 

Ниже — как он устроен и почему мы доверили модели только две узкие задачи, а все решения о рисках вынесли в детерминированные правила.

Исторически в Яндекс Картинках релевантность документа оценивалась по двум сигналам: насколько запросу подходит само изображение и насколько — текст, связанный с этим изображением. Такой подход позволяет учесть контент картинки и не провалиться на визуально трудноотличимых объектах, однако он же порождает проблему: в «серой зоне», когда текстовая релевантность не сонаправлена с картиночной, становится неочевидно, как именно агрегировать сигналы в финальный скор релевантности.

Привет! Я Константин Николаев, занимаюсь внедрением нейротехнологий в Поиске по картинкам. В этой статье я расскажу, как наша команда научила модели смотреть на картинку и читать текст документа одновременно: начали с тяжёлой мультимодальной VLM ради максимального качества, а затем дистиллировали её в набор лёгких моделей — по одной под каждую стадию пайплайна. Что из этого удалось довести до realtime‑поиска с десятками тысяч запросов в секунду и как совместный анализ двух модальностей добавил 5% релевантных картинок в топ выдачи — под катом.

На днях на Хабре вышла статья с разбором Яндекс Браузера и приложения Яндекс для Android. Автор сделал несколько выводов о работе приложений на основе анализа кода.

Часть наблюдений в статье действительно описывает существующие механизмы, однако их назначение интерпретируется неверно. Во многих случаях речь идёт не о специфике Яндекса, а о стандартных механизмах Android, Chromium, работе современных голосовых помощников или платёжных SDK.

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

Сразу оговоримся: автор не указал версии приложений, которые анализировал, поэтому в точности воспроизвести его опыт невозможно. Для разбора мы использовали актуальные версии Яндекс Браузера и приложения Яндекс из Google Play. Все описанные ниже механизмы можно проверить самостоятельно.