Бывает так, что ревьюер посмотрел пул-реквест, тесты зелёные, компиляция прошла успешно, а в коде всё равно остался баг, который проявится только в продакшене. Вручную такие дефекты найти достаточно сложно, поэтому мы решили попробовать подключить дополнительные «руки».

Такими руками стал NeuroReview — автоматический ревьюер пул-реквестов, который работает в продакшене и находит часть дефектов до человеческого ревью или мержа. Мы используем его только на внутреннем коде, подключение добровольное. Сейчас каждый день через него проходит примерно 4 тысячи пул-реквестов — около 40% от всех созданных разработчиками в Аркадии, монорепозитории Яндекса. 

Если вы когда‑либо строили пайплайны для обработки потоков данных в реальном времени со строгими требованиями, то наверняка знаете, сколько инфраструктурных заморочек в этом деле. Например, обеспечивать относительно низкие end‑to‑end‑задержки в штатном режиме относительно несложно. Но что, если они нужны и в высоких перцентилях, в том числе при сбоях или плановом обслуживании одного из используемых дата‑центров целиком? Как правильно партиционировать поток данных, обрабатывающие его процессы и их долгосрочное состояние, если нагрузка постоянно меняется? Как гарантировать exactly‑once, то есть отсутствие потерь и дублей даже при сбоях оборудования и в краевых случаях? Как понять, обработали ли мы все данные на тот или иной момент? 

С такими вопросами мы столкнулись при разработке высоконагруженных рекомендательных систем. Для этих задач мы создали YTsaurus Flow — фреймворк потоковой обработки данных с сохранением состояния между событиями и гарантиями exactly‑once по умолчанию. Это совместный проект команд Yandex Infrastructure и Яндекс Рекламы для обработки потоков данных в реальном времени. И сегодня мы открываем его исходный код под лицензией Apache® 2.0.

Flow — часть YTsaurus, платформы хранения и обработки данных, которую мы выложили на GitHub в марте 2023 года. Flow использует хранилище, очереди и общий механизм транзакций платформы, чтобы брать на себя управление состоянием и восстановление обработки после сбоев. Разработчик пайплайна при этом сосредоточивается на прикладной логике.

В статье разберём, зачем мы разработали собственный движок, как устроены его пайплайны и за счёт чего обеспечивается exactly‑once. А на примере реального сервиса покажем, как переход на Flow помог сократить задержку поставки данных для дообучения моделей с десятка‑другого часов примерно до двух.

Во многих сферах безопасности есть негласный закон: хотите безопаснее — станет менее удобно.

Привет, Хабр! Меня зовут Руслан Сабиргалиев, руковожу группой аналитиков‑разработчиков отдела доверия и надёжности Яндекса. Вместе с командами Yandex Cloud и Yandex Infrastructure мы развиваем Yandex Smart Web Security (SWS) и Yandex SmartCaptcha. Эти сервисы защищают сайты и API клиентов от нежелательной автоматизации, DDoS‑атак и попыток эксплуатации уязвимостей. Этой же технологией мы бережём и сервисы самого Яндекса.

В прошлой статье я рассказывал, как устроен bot score — параметр для оценки «роботности» трафика, который помогает нам защищать приложения от вредоносных ботов. Но он не исключает «серой зоны», при которой мы покажем капчу легитиному пользователю (а этого никто не любит). Сегодня — о том, что мы сделали, чтобы не ограничиваться одним параметром. Расскажу на нашем примере, как технологии и внимательный анализ боли людей, а также защищаемых сервисов помогают поспорить с этим негласным законом. Мы добавили две проверки, которые человек почти не замечает, выстроили из них систему интерактивных «челленджей» и дали клиентам три режима защиты. В итоге сдвинулся сам компромисс между удобством и безопасностью.

Привет, Хабр! Меня зовут Александр Зевайкин, и мы с командой делаем YDB (СУБД Яндекса). Год назад я рассказывал на Хабре, как мы запустили векторный поиск, а весной — как он используется в Нейроюристе для поиска по миллионам юридических документов.

В релизе 26.3 к векторному поиску добавились полнотекстовый поиск с ранжированием и гибридный поиск, который объединяет оба вида поиска в одном SQL-запросе. Кроме того, мы доработали фильтруемый векторный индекс.

Зачем нужны оба вида поиска, хорошо видно на примере. Страховой юрист ищет «выплаты по полису 7702-345678 при переносе рейса». Номер полиса нужно найти слово в слово, а описание случая — понять по смыслу. Полнотекстовый поиск справляется с первой половиной задачи и не справляется со второй, векторный — наоборот.

Прежде чем перейти к статье, я хочу пригласить вас на вебинар «Быстро находите нужное с YDB», который проведу в прямом эфире 15 октября. На нём я покажу рецепт, как за час собрать приложение для поиска сразу по документам, тикетам, карточкам и диалогам. Готовый поиск я подключу к ИИ-ассистенту с помощью RAG, и мы вместе со зрителями посмотрим, как меняется качество ответа. Регистрируйтесь и добавляйте в календарь — всё, что я покажу на вебинаре, доступно в рамках бесплатного тарифа и можно будет сразу попробовать самим.

А под катом в этой статье я отвечу на шесть вопросов о гибридном поиске:

1. Почему одного вида поиска недостаточно и чем два вида дополняют друг друга.

2. Что теряет бизнес, когда поиск работает отдельно от СУБД, и как оба индекса стали таблицами YDB.

3. Как сделать инвертированный индекс в виде распределённой таблицы и что добавляет к нему ранжирование по BM25.

4. Что происходит с каждым индексом при записи и как индекс объединяется с фильтрацией.

5. Как две выдачи объединяются внутри одного плана запроса.

6. Чем гибридный поиск помогает рекомендательным системам и чем измеряют результат.

Представьте, что ваш запрос в Greenplum внезапно завис. Есть план выполнения, но что именно сейчас происходит, непонятно. Перекос данных? Spill на диск? В итоге вы перезапускаете запрос наугад: инструментов для живого наблюдения попросту нет. 

Всем привет! Я Алексей Рожок, разработчик ClickHouse в Yandex Cloud. Летом 2026 года я стажировался в Greenplum/Cloudberry и реализовывал проект, который помогает увидеть весь путь запроса. В статье покажу, как достучаться до процессов на всех хостах кластера и почему сбор метрик пришлось вынести с координатора в отдельный сервис YAGPCC. 

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

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

Меня зовут Айдар Сабиров, я занимаюсь информационной безопасностью в Яндексе. Порой нам приходится решать самые необычные задачи, в которых техническая часть оказывается лишь половиной решения. Вторая половина — договориться между компаниями и превратить непонятные формулы в работающий отраслевой процесс. Это как раз такой случай. 

В этой статье я расскажу Хабру, как мы вместе с другими участниками рынка искали более надёжную конструкцию и пришли к схеме на основе Oblivious Pseudorandom Function (OPRF), предотвращающей отслеживание пользователя по его номеру.

«LLM‑содержащие продукты» — это далеко не только вызов модели. Чтобы её ответ оказался полезным, нужно правильно распознать интент, найти подходящую информацию, отобрать нужные фрагменты и уместить их в контекстное окно. Кроме того, сами механизмы поиска и отбора данных приходится постоянно настраивать.

Всё становится ещё сложнее по мере прихода к итеративным сценариям. Бизнес‑логика, которая готовит входные данные для LLM и обрабатывает её ответы, всё сильнее и сильнее срастается с самой моделью.

На примере LLM‑ответов в поисковой выдаче Яндекса расскажу, как мы ускорили такие эксперименты, научились работать с бизнес‑логикой как с ML‑артефактом и зачем нам для этого понадобились ещё один DSL и представление вычислений в виде графа.

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

Для чат‑бота такая задержка может быть приемлемой. Для голосового ассистента, робота, игрового агента или системы, которая следит за непрерывным видеопотоком, это превращается в фундаментальное ограничение. Интерактивный агент должен получать новые данные прямо во время вычислений, корректировать план без полного перезапуска, выдавать полезные промежуточные действия и координировать процессы, которые идут с разной скоростью: восприятие, рассуждение, речь, работу с инструментами.

Меня зовут Георгий Якушев. Я исследователь Yandex Research, преподаватель и выпускник ШАД. Мы изучаем, какую часть этой интерактивности можно реализовать на уровне инференса, не меняя весов уже обученной модели. В этой статье я расскажу, почему полезно перестать воспринимать KV‑кеш только как способ ускорить генерацию и начать рассматривать его как активное состояние агента.

Сегодня мы открываем веса нашей новой модели AliceAI‑Foundation-80B‑A3B‑Base под лицензией Apache 2.0. Модель прошла полный цикл обучения в Яндексе с нуля: мы не использовали веса сторонних опенсорс‑моделей. Её создание — ещё один шаг к нашей единой рассуждающей модели (ЕРМ), на базе которой будут развиваться агентские возможности Алисы AI.

В претрейн‑замерах новая модель обходит более крупные DeepSeek‑V4-Flash‑Base и Nemotron-3-Super на многих задачах — от фактологических и экспертных вопросов до математики и кода, — а на сложных задачах IMO AnswerBench и LiveCodeBench лидирует среди сравниваемых открытых претрейнов. Нашу предыдущую закрытую Alice AI LLM 235B она превосходит по фактологическим знаниям, математике, программированию и работе с длинным контекстом — при почти втрое меньшем общем числе параметров и примерно в семь раз меньшем числе активных.

Недавно наши коллеги открыли претрейн Alice AI Search (кстати, он тоже обучен без применения весов опенсорс‑моделей) и рассказали, как устроена модель быстрых ответов Алисы на Поиске. Сегодня мы подхватим у них эстафетную палочку и расскажем о большом обновлении датасета, который лежал в основе обучения обеих моделей.

Также продолжим историю из декабрьского техрепорта Alice AI LLM. Тогда обучение начиналось с весов Qwen3-235B‑A22B, но в этот раз мы обучали модель полностью с нуля. Благодаря накопленному командой опыту весь путь к релизу этой модели занял около полугода. За это время мы пересобрали корпус, перебрали архитектурные решения, подобрали гиперпараметры и добавили данные для рассуждений и агентских взаимодействий.

За итоговыми скорами стоит много экспериментов, и нам хочется рассказать о них подробно. Поэтому вместе с весами мы публикуем большой технический отчёт: от пайплайнов подготовки данных и протоколов оценки до стабилизации обучения и scaling laws. Для ключевых решений приводим абляционные эксперименты и разбираем подходы, от которых пришлось отказаться. Вклад обновлённого корпуса, архитектуры и гиперпараметров проверили в серии обучений с нуля — по 2 трлн токенов каждое.

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

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

Есть общепринятые столпы индустрии, без которых полноценный рассказ просто не сложится: Atari 2600, Famicom, NES, Sega Mega Drive, PlayStation и так далее. А есть консоли, о которых рассказать очень хочется, но не всегда получается в силу ограниченного времени экскурсии.

Иногда акцентировать внимание на одних экспонатах и обходить другие стороной приходится в зависимости от состава группы: например, семье с тремя маленькими детьми вряд ли будет интересен рассказ про PC Engine, а вот геймерам за 40 наверняка понравится более подробный рассказ про Dendy.

И когда обделяем вниманием приставку с длинным названием Panasonic FZ-10 R·E·A·L 3DO Interactive Multiplayer, становится как‑то особенно обидно. Этому устройству категорически не везло при жизни, и очень хочется воздать ему должное хотя бы сейчас — спустя 30 лет после того, как последняя 3DO сошла с конвейера.

Меня зовут Прохор, я лид команды агента «Исследовать» — это режим глубокого исследования в чате с Алисой AI.

Напомню, про что вообще речь, если никогда не пользовались Deep Research: это специальный режим работы, который строит уникальный план решения задачи пользователя, делает сотни поисков по вашему запросу, умеет ходить на сайты (даже с динамическим JavaScript‑контентом), писать и выполнять Python‑код (для сложных расчётов), работать со скачанными файлами и так далее. Всё это для того, чтобы дать лучший ответ на ваши сложные запросы, например: «Спланируй мне путешествие в Дагестан на две недели на машине с детьми».

За год агент прошёл путь от первого прототипа до продакшена — вместе с ним менялись качество ответов, скорость работы и потребление GPU. За продуктовую часть отвечал Руслан Илиев, продакт менеджер агента: он сформулировал продуктовые цели, определил набор инструментов и валидационный набор запросов, а затем вёл запуск от закрытого вейтлиста до 100% продакшена. Как мы к этому пришли — через выброшенный прототип, десятки слоёв обвязки и пару болезненных уроков, — расскажу по порядку. Добро пожаловать под кат!

Быстрый ответ Алисы 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 и связанные с ними контроли безопасности.