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

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

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

Меня зовут Дима Кирпа, я разработчик из команды ML Laboratory в Yandex Infrastructure. Четыре года я делаю внутренний поиск по корпоративному интранету Яндекса. Сегодня предлагаю ненадолго отложить судорожный тюнинг промптов и температуры LLM и окинуть внутренние корпоративные знания более широким взглядом. На примере опыта Яндекса я разберу процесс LLM‑изации интранета компании с самых азов. На время мы вернёмся в ламповый мир старого доброго фича‑инжиниринга, неспешно пройдёмся от настроек ранжирования к настройкам поискового контекста для LLM и увидим, как фичи поиска плавно перетекают в фичи генеративки. Напоследок убедимся, что всё не зря и наши разработки реально приносят пользу компании.

Я расскажу, как устроен бэкенд и ранжирование внутреннего поиска Яндекса, как на базе внутреннего поиска мы построили генеративную Q&A‑систему AI Chat. Покажу обоснования разных внедрений в виде чисел из реальных A/B‑экспериментов. Никакого хайпа, только факты. Цель статьи — доказать, что поиск — это база для корпоративных процессов обмена знаниями, а модель роста от поиска к агенту — самая эффективная.

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

Для контроля за метриками в системе Monium существует механизм алертов. Проблема в том, что для многих рядов сложно заранее определить разрешённые пороги. А для некоторых рядов сделать это попросту невозможно. В результате контролировать такие временные ряды было довольно нетривиальной задачей.

Мы в команде ML Research в Городских сервисах Яндекса давно поняли, что руками такие системы не масштабируются. Нужна автоматика, которая сама фиксирует нормальное поведение метрики и засекает отклонения. Звучит как задача для тяжёлого ML, однако на бенчмарках мы доказали, что простая авторегрессия обгоняет сложные модели.

Давайте вместе пройдём путь от «Почему пороги не работают?» до рабочей системы детекции аномалий в общеяндексовой системе Monium и наблюдения за 800+ городами в Яндекс Такси с бенчмарками и конкретными цифрами.

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

В одном обновлении сходятся около 10 000 коммитов апстрима и примерно 1500 наших изменений. В процесс вовлекаются десятки разработчиков, а суммарные трудозатраты команды на один цикл составляют несколько человеко‑месяцев.

Мы хотели сократить объём этой рутинной работы и освободить время команды для развития браузера. Для этого автоматизировали две самые трудоёмкие части процесса: разрешение конфликтов и починку компиляции.

Речь не про сценарий «вставить одну ошибку в чат и получить фикс». Здесь мы имеем дело с регулярным обновлением большого форка: тысячи проблем нужно разбирать пакетно, с учётом контекста апстрима и наших изменений.

В этой статье расскажем, как встроили LLM‑агента в процесс перехода на новые версии Chromium и что из этого получилось.

Навигация во Flutter — это постоянные компромиссы. Сначала кажется всё просто: push и pop. А потом проект растёт, появляются табы, вложенные модули, диплинки — и выясняется, что каждый следующий экран открывается по‑разному, а pop() в одном месте ведёт себя не так, как в другом. 

Navigator 1.0 прост и понятен, но при масштабировании рассыпается. Navigator 2.0 даёт полный контроль, но требует столько бойлерплейта, что проще изобрести свой фреймворк. Сообщество это поняло — и появились пакеты поверх Navigator 2.0. go_router упрощает жизнь, но недавно перешёл в режим поддержки: только баг‑фиксы, никаких новых фич. auto_route даёт type‑safety, но тянет за собой кодогенерацию.

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

Так появился yx_navigation — новый пакет в нашей экосистеме архитектурных решений для Flutter, после yx_scope (DI) и yx_state (управление состоянием). Дальше расскажу, с какими трудностями мы столкнулись, какие требования сформулировали, как устроен yx_navigation сегодня и как именно он решает проблемы крупных приложений.

Представьте: вы теряете контроль над SCCM — одним из самых критичных инструментов управления инфраструктурой. А точкой входа становится обычное подключение к MSSQL, где он хранит свои данные. Злоумышленник перехватывает NTLM-аутентификацию и перенаправляет её на нужный сервер — так работает NTLM relay. Мы в команде Security Engineering решили не ждать эксплуатации этой уязвимости.

Меня зовут Булат Гафуров, я инженер по информационной безопасности в Яндексе. В этой статье я расскажу, почему стандартного решения оказалось недостаточно и как мы добавили поддержку механизма EPA в популярные библиотеки, чтобы переключить защиту на стороне MSSQL в режим Require, не лишив Linux- и Windows-сервисы доступа к данным.

В современном развитии рекомендательных систем и алгоритмов принятия решений особое место занимают Feature Store — хранилища признаков, позволяющие быстро и централизованно управлять данными. В городских сервисах Яндекса для таких задач мы создали собственное решение под названием Avalon. Оно служит универсальным каталогом признаков, которым легко пользоваться разработчикам и аналитикам вне зависимости от того, что им нужно хранить — бинарные индикаторы или сложные метрики вроде количества поездок у водителя.

Наш Feature Store — Avalon — возник в момент, когда понадобилось масштабируемое и производительное хранилище с низкой задержкой, в котором можно структурировать признаки по иерархии «каталог/файл», получать быстрый доступ к ним из рантайма, автоматически отслеживать актуальность данных и контролировать жизненный цикл каждого признака. Роль СУБД для системы выполняет YDB, что позволяет достичь высокой отказоустойчивости и горизонтального масштабирования.

Всем привет! Меня зовут Паша, я руковожу группой разработки технологий эффективности Такси. В этой статье я расскажу, как мы проектировали и строили Avalon, какие вызовы пришлось решать команде по мере роста нагрузок и аудитории, почему прежние подходы перестали соответствовать задачам современного продуктового анализа и как в результате получился удобный и надёжный Feature Store для множества бизнес-сценариев.

Всем привет! Меня зовут Илья Григорьев, я старший бэкенд-разработчик в команде Телемоста. В этой статье я разберу наш опыт разработки двух фич последнего года — ИИ-конспект с Алисой Про и облачной записи на Диск. Покажу, как мы проектировали их архитектуру, почему не всё получилось с первого раза, с какими системными и техническими ограничениями столкнулись при работе с медиаданными и как в итоге выстроили пайплайн их обработки и анализа.

Всем привет! Меня зовут Андрей, я финалист ICPC (Международной студенческой олимпиады по программированию), разработчик Техплатформы Городских сервисов Яндекса. Эта статья — концентрат неочевидных (а порой и контринтуитивных) советов по подготовке к соревнованиям. Годами я тренировался, набивал шишки на контестах и набирался мудрости у топовых тренеров, чтобы собрать этот опыт в одном месте.

Миграция большого iOS-проекта с Objective-C на Swift кажется понятной задачей ровно до тех пор, пока не начинаешь считать объём. В нашем случае это были 10 тысяч файлов, сотни тысяч строк кода и постоянная необходимость не останавливать развитие продукта. Ручной подход работал слишком медленно, поэтому мы начали автоматизировать миграцию с помощью LLM — и в итоге превратили её из бесконечного техдолга в воспроизводимый процесс.

Из этой статьи вы узнаете, как мы пять лет закрывали этот техдолг и за это время переписали лишь половину. И как в итоге пришли к решению на базе LLM, которое помогло завершить работу кратно быстрее и высвободило время разработчиков для более интересных задач, чем рефакторинг кода.

Меня зовут Андрей Сикерин, я руковожу одной из групп iOS-разработки Яндекс Браузера. Вместе со мной статью писала Елизавета Мазулова, разработчица из нашей же команды. Она создала систему промптов для миграции, ревью, рефакторинга и автоматизации тестирования. Вместе мы расскажем, как устроен весь процесс изнутри: от выбора порядка миграции модулей до контроля качества через тесты.

Все промпты, конфигурационные шаблоны и вспомогательные скрипты выложили в открытый доступ — забирайте и адаптируйте под свой проект. Мы уже проверили, что подход работает не только у нас: взяли открытый репозиторий приложения Wikipedia для iOS и без существенных изменений промптов мигрировали один из его пакетов и поделились результатом с сообществом в виде открытого PR.

Меня зовут Алексей Щекалёв, я работаю в команде машинного обучения Яндекс Лавки. Как думаете, что общего между пакетом молока, айфоном, дрелью и лабубу? Похоже на начало анекдота, но для нас это серьёзный технический вопрос. Ответ на него определяет, найдут ли пользователи то, что ищут, или разочарованно закроют приложение.

Мы столкнулись с этим вопросом в 2025 году, когда наш отлаженный поиск по продуктовому каталогу сломался о новую модель продаж. Тяжёлые модели понимали новые товары, но работали слишком медленно для рантайма, а быстрые не справлялись. Переобучать весь стек на каждый новый ассортимент было бы слишком дорого и долго. Казалось, что компромисс «качество vs скорость» неразрешим, но мы нашли третий путь.

Каждый из нас если не сталкивался, то хотя бы видел, как в современном офисе разбираются с мелкими, но важными вопросами вроде восстановления доступа или замены сломанной мышки. Обычно такие задачи требуют времени, объяснений и терпения, и важно, чтобы всё не превратилось в лишний стресс и непродуктивные простои. Мы в Яндексе поставили перед собой очень простую цель: сделать так, чтобы каждый сотрудник мог быстро и легко решить свой вопрос, не отвлекаясь от работы и не тратя силы на бюрократию или ожидания в очередях. 

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

Умные колонки, ТВ, камеры и другие устройства с ИИ-ассистентом сегодня — это уже не просто бытовая электроника повседневной жизни. С точки зрения безопасности это распределённая система, в которой граница доверия проходит через несколько уровней — от аппаратных механизмов до серверной логики, поэтому и подход к защите должен быть разносторонний.

Меня зовут Никита, и мне как инженеру по информационной безопасности Алисы и Умных Устройств Яндекса приходится быть по обе стороны баррикад: думать, как сделать устройства безопасными и знать, как их «ломать». Всегда нужно рассматривать потенциальные векторы атак и способы защиты от них. В этом во многом помогает наша программа «Охота за ошибками». А сегодня я расскажу о том, как смотреть на смарт-девайсы с точки зрения информационной безопасности, какие есть реальные риски и как их минимизировать.

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

Привет, меня зовут Рамиль Габдрахманов, я руковожу разработкой видеоплееров в Yandex Infrastructure. Нашу видеоплатформу используют многие сервисы Яндекса: Кинопоиск, Яндекс Маркет, Яндекс Музыка и другие — а компании вне Яндекса могут использовать её через Yandex Cloud Video. В день наш плеер воспроизводит 103 847 867 931 секунду видео.

Сегодня расскажу о том, как устроены ленты коротких видео у нас, что под капотом и какие оптимизации мы применяем.

Привет! На связи Антон Полухин из Техплатформы Городских сервисов Яндекса. После большого релиза 🐙 userver прошло почти два года. За это время мы обзавелись большим количеством внешних пользователей — международных и российских. При этом и количество внутренних пользователей подросло: в Городских сервисах Яндекса появились стни новых сервисов на userver. Функциональность Такси, Еды, Лавки, Доставки, а также Маркета, Финтеха, Фантеха, Электро и Техплатформы обогатилась новыми возможностями и новыми пользователями. А значит, фреймворк стал ещё надёжнее и оттестированнее.

Мы не сидели сложа руки, и за два года реализовали, оптимизировали и добавили все обещанные в прошлой статье фичи, а также многое другое.

Представьте ситуацию: вы работаете в огромном проекте, где количество модулей давно перевалило за тысячу. Вы решаете обновиться до свежего Xcode 26.2, ожидая прироста производительности, но вместо заветного «Build Succeeded» получаете молчаливое падение: SWBBuildService quit unexpectedly.

Всем привет, меня зовут Алексей Севко, я ведущий разработчик программного обеспечения из команды Delivery & Performance Яндекс Go. В этой статье я расскажу почти детективную историю о том, как:

— Искать иголку в стоге сена: когда падает закрытый бинарник Xcode.

— Стать контрибьютором swift-build: почему иногда проще переписать системный поиск макросов в swift-build, чем ждать фикса от Apple.

— Использовать свою версию билд-системы: как мы внедрили инфраструктуру прозрачной подмены компонентов Xcode через XCBBUILDSERVICE_PATH, чтобы не ждать релиза Xcode со Swift 6.3 и работать стабильно уже сегодня.

Если ваш проект тоже перерос стандартные инструменты Apple или вам просто интересно, как превратить рекурсию в итерацию и не сойти с ума от 45-минутных дебаг-сессий, — добро пожаловать под кат!

Всем привет! Меня зовут Булат Гафуров, я security-инженер в Яндексе. Сегодня я хочу подробно разобрать, как устроено Privileges — опенсорсное приложение для macOS, которое предназначено для быстрого и удобного управления правами администратора. Мы выясним, как взаимодействуют его компоненты, через что происходит обмен сообщениями и на чём строится доверие между процессами. А главное — разберёмся, почему вредоносным скриптам теперь станет сложнее повысить привилегии.

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

Техплатформа — это инфраструктурная платформа для всех городских сервисов Яндекса: Такси, Еды, Лавки, Доставки, а также для различных шеринговых сервисов — каршеринга, зарядных станций, самокатов и других.

Один из ключевых сервисов нашей команды — ProcaaS (Processing as a Service). Он предназначен для асинхронного выполнения динамических сценариев. Подробнее о самом сервисе, его архитектуре и роли в сетке микросервисов Такси мы рассказывали в предыдущей статье. В этом материале я хочу поделиться опытом решения одной непростой и при этом очень интересной технической задачи, с которой мы столкнулись в рамках развития ProcaaS, а именно — рассказать, как мы написали свой транслятор кода.

Привет, это Андрей Мелихов, ведущий разработчик интерфейсов в Yandex Cloud. Я работаю в команде DataLens — BI‑системы для визуализации больших наборов данных на дашбордах и графиках. 

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

Агент «Исследовать» в Алисе AI может работать до 20 минут. За это время он успевает обойти десятки сайтов, запустить модели, вызвать инструменты — и сделать всё это параллельно на нескольких хостах. И если в середине цепочки что-то упадёт (а практика показывает, что если может упасть — когда-нибудь упадёт: релизы, сети, «луна не в той фазе»), агент должен уметь продолжить работу с того же места, а не начать всё заново, сжигая часы и LLM-токены. Ещё год назад никакой инфраструктуры для этого у нас не было.

Меня зовут Алексей Логинов, я ведущий разработчик в команде, которая отвечает за инфраструктуру нашего ассистента. В этой статье я покажу, какой путь мы прошли от наивного SDK до полноценной платформы Agent Transport System (ATS) — и как при этом упирались в различные ограничения и преодолевали их.