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

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

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

Самое интересное в таких задачах начинается не на этапе «как добавить медиаленту», а на этапе ограничений и деградаций. В статье я разберу именно эту сторону задачи на примере приложения Яндекс Еды: как мы проектировали медиаленту, какие архитектурные решения не сработали, какие баги всплыли только на реальных данных, как мы строили observability для дебага и какие компромиссы в итоге оказались эффективнее красивой реализации.

Отладка корутин в Android — задача, с которой сталкивается каждый разработчик, использующий Kotlin. На один экран могут приходиться десятки вызовов launch и async, но стандартные инструменты показывают потоки, а не корутины. В итоге, когда одна из корутин зависает, разработчик оказывается в тупике: отладчик показывает живой поток, но не показывает, какая корутина на нём выполнялась, в каком suspend‑вызове она остановилась и кто её запустил. Приходится искать причину вслепую — расставлять логи и пытаться воспроизвести проблему вручную. 

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

Чтение сериализованных данных — это инфраструктурный налог, который платит каждый сервис при получении информации из внешних источников, например по сети или с диска. В индустрии для схематизированных данных стандартом де‑факто стал Protobuf, и чаще всего этот налог выражается в существенных затратах CPU на его парсинг. В продвинутых случаях парсинг пытаются заменить на значительно более дешёвую, но при этом куда менее удобную работу с zero‑copy представлением FlatBuffers.

Мы открыли исходники YaFF (Yet Another Flat Format) — формата, который убирает этот налог, не заставляя отказываться от Protobuf. На масштабе Яндекса это особенно важно, потому что менять такие базовые вещи, как формат, дорого и больно. Поэтому YaFF изначально спроектирован как альтернативный wire format для существующих экосистем Protobuf (и в перспективе FlatBuffers). Это позволяет дёшево и бесшовно встраиваться в существующие проекты, не переписывая десятки тысяч строк кода.

Как это работает на практике, мы покажем на примере Яндекс Рекламы: в рекомендательной системе, где каждый из сотен тысяч запросов обрабатывает десятки тысяч объектов, нужно особое внимание к представлению данных. Благодаря YaFF мы смогли постепенно, шаг за шагом, оптимизировать систему и без дорогих рефакторингов сэкономить 10–20% CPU в масштабах крупных рантаймов.

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

Для этого мы сравнили два способа «подружить» ИИ‑агента с внутренними API — MCP и CLI + Skill. Взяли гипотезу из внешних исследований, собрали бенчмарк на 14 сценариях и двух моделях, прогнали больше 400 запросов на реальных внутренних инструментах. И в какой‑то момент всё, что работало, сломалось — и это оказалось самым интересным. Пришлось разбираться почему.

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

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

Yandex Smart Web Security — это сервис для защиты сайтов и приложений от DDoS‑, веб‑атак и ботов, который разрабатывают несколько команд Яндекса: Yandex Cloud, Yandex Infrastructure и команда Антиробота. Недавно мы добавили новую функциональность по работе с роботами: пользователям облачной платформы она даёт возможность самостоятельно настраивать правила для выделения роботного трафика буквально с помощью пары бегунков. Мы делаем фокус на простых инструментах управления. Но за этими, казалось бы, небольшими улучшениями интерфейса, стояла большая инженерная работа.

В конце апреля в Рио‑де‑Жанейро прошла ICLR-2026 (International Conference on Learning Representations) — одна из главных конференций по искусственному интеллекту и машинному обучению.

Конкурс и сито рецензирования (peer review) оказались жёсткими: было подано ~ 19 000 заявок, принято более 5000 статей, уровень одобрения (Acceptance Rate) составил ~26%.

Команда Яндекса прошла этот отбор, представив на конференции свои результаты: шесть статей вошли в основную программу (Main Track), одна работа была презентована на воркшопе ICBINB (I Can't Believe It's Not Better) — известной площадке для разбора подходов, которые по всем законам логики должны были «взлететь», но столкнулись с неочевидными фундаментальными ограничениями.

Меня зовут Мария Никифорова, я старший разработчик службы качества претрейна. Вместе с Дарьей Шатько, руководителем ML в Yandex Crowd, и другими коллегами мы побывали на конференции и в статье расскажем, как конференция начиналась уже в аэропорту, какие главные инсайты были в статьях и какие постеры оказались самыми запоминающимися.

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

Крошечный аккумулятор, мало памяти, чип с жёсткими ограничениями по тактовой частоте, да ещё и с кое‑какими неожиданным сюрпризами на уровне SDK. Всё это потребовало переосмыслить с нуля архитектуру споттера (компонента, который распознаёт обращение «Алиса» прямо на устройстве). 

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

На связи Денис из команды платформы данных в Yandex Cloud. Мы занимаемся разработкой системы SPQR, которая помогает легко реализовать горизонтальное масштабирование PostgreSQL с помощью шардирования. И это не теоретическая задача на два шарда и десять таблиц. Необходимо сделать систему, которая в пределе хранит петабайты данных и выдерживает сотни тысяч запросов в секунду. 

В прошлой статье мы показывали SPQR со стороны пользователя: как выбрать ключ шардирования, как разложить таблицы на распределённые (distributed) и справочные (reference), как создать распределения и определить диапазоны ключей, а затем перевезти монолит на несколько шардов. Эта статья будет про инженерный путь: архитектуру, компромиссы и грабли, которые встретились по дороге.

Привет, я Павел Семенищев, сетевой инженер в Yandex Infrastructure. В команде Network Operations Center (NOC) мы отвечаем не только за магистральные и дата‑центровые сети, но и за офисные, а также сети складов и дарксторов Яндекс Лавки. А это ОЧЕНЬ много удалённых точек присутствия, и при проблемах с Wi‑Fi на каждую сетевика не отправишь.

Для быстрого сканирования параметров сети на местах я создал WiProber под Android и WiFi Prober под iOS — получился сетевой «комбайн» для инженера, который сначала был нашим внутренним инструментом, а теперь есть и в общем доступе. Под катом расскажу, что умеют эти приложения, и какие ограничения операционных систем удалось обойти при их создании.

Когда вы загружаете фотографии на Яндекс Диск, они не просто лежат в облаке: ML‑модели анализируют снимки, группируют их в альбомы и выбирают хайлайты для фотоленты в Яндекс Диске. Но чтобы улучшать такую систему, нужно уметь измерять качество её работы. И здесь начинается проблема: модель выбирает «красивые» и «удачные» кадры, а эстетика — вещь субъективная. Одному важны насыщенные цвета, другому — композиция, третьему — эмоции и лица в кадре. Если попросить асессоров ставить оценки от 1 до 10, мы быстро получим не объективную шкалу, а смесь личных вкусов, разной строгости и шума.

Поэтому мы подошли к задаче не как к обычной разметке, а как к исследованию. Вместо абсолютных оценок использовали шахматный подход. Каждая фотография стала «игроком», который соревнуется с другими по 16 признакам эстетики — цветам, фокусу, геометрии, эмоциональности и другим параметрам. Это позволило получить не просто рейтинг кадров, а инструмент для анализа того, какие визуальные признаки учитывают ML‑модели Диска.

Всем привет! Я Всеволод Мещеряков из службы разметки Yandex Crowd Solutions. Мы собираем и размечаем фото, видео, тексты — в общем, готовим данные, на которых учатся ML‑модели. В этой статье расскажу, как подход из мира шахмат помог нам связать субъективное восприятие фотографий с математическими оценками и сделать фотоленту Яндекс Диска ещё красивее.

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

Меня зовут Александра Атаман, я QA‑инженер в команде веба Яндекс Такси. В этой статье я расскажу, как мы оптимизировали процесс формирования регрессионного тестирования для ручного прогона, внедрив систему весов для тест‑кейсов. Этот подход помогает прицельно отбирать наиболее «опасные» сценарии: самые старые, забагованные или потенциально проблемные.

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

Острый коронарный синдром (ОКС) — наиболее рисковая форма ишемической болезни сердца. Пациенты, которые перенесли ОКС, попадают в группу крайне высокого риска последующих сердечно‑сосудистых осложнений. Смертность в этой категории больных составляет до 20% в течение 4 лет.

НМИЦ кардиологии им. ак. Е. И. Чазова Минздрава России при поддержке Центра технологий для общества Yandex Cloud запустил цифровой регистр пациентов, перенёсших ОКС. Для решения этой задачи мы обеспечили безопасную обработку более 13 тыс. медицинских документов с помощью больших языковых моделей и дали кардиологам максимум информации для исследований, мониторинга и предотвращения риска. 

Меня зовут Евгений Попов, в Yandex Cloud я руковожу проектами по направлению «Медицина». Сегодня я расскажу об этапах разработки решения и остановлюсь подробнее на нетривиальной задаче обезличивания данных.

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

Эта схема отлично работает на лёгких API‑запросах, но рассыпается, как только трафик становится тяжелее. В случае с Яндекс Диском речь идёт о массовой загрузке файлов. 

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

Год назад я рассказывал, как Яндекс Карты научились учитывать рельеф и лестницы при построении пешеходных маршрутов. Но альтернативные варианты по-прежнему выглядели для пользователя как просто «ещё один путь, только дольше» — и люди не раздумывая выбирали самый быстрый. Теперь у каждого альтернативного маршрута появилось имя и характер: например, «Быстрый», «Прогулочный», «Оживлённый» или «Без лестниц».

Простые категории посчитать несложно. А вот «Прогулочный» и «Оживлённый» — это субъективные характеристики: в хорошую погоду хочется пройти через парк или вдоль набережной, а в тёмное время — по освещённым улицам, подальше от дворов и промзон. Для этого с помощью LLM мы обучили легковесную модель, которую и применили в сервисе. Как именно — читайте в статье. Сам путь разработки оказался совсем не «Быстрым» и далеко не «Прогулочным» — с тупиками и неожиданными поворотами там, где их не ждали.

Развивать собственный технологический проект в одиночку или небольшой командой — это всегда вызов. Нужно не просто написать работающий код, но и продумать архитектуру, закрыть инфраструктурные боли, настроить CI/CD и при этом не выгореть. Тем ценнее видеть, как крутые разработки получают заслуженную поддержку, помогающую им выйти на новый уровень.

В этом году мы провели Yandex Open Source при поддержке платформы для разработчиков SourceCraft. А ещё мы увеличили призовой фонд с 12 до 18 победителей. Мы принимали заявки по трём трекам: обработка и хранение данных, разработка, искусственный интеллект. 

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

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

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

Меня зовут Даша Виноградова, я руковожу универсальными применениями компьютерного зрения в Яндексе. Вместе с Аней Сидоровой, главным разработчиком распознавания архивов, мы расскажем, как мы сделали шаг от распознавания текста к извлечению структуры и смысла из архивных документов: как мы перестраивали OCR‑пайплайн, почему нам не подошли универсальные VLM‑модели и как пытались разобраться, кто есть кто: отец, мать, жених или свидетель.

Всем привет! Меня зовут Миша, я разрабатываю платформу Яндекс Еды. В декабре я рассказывал, как Temporal без боли решает привычную проблему распределённой бизнес‑логики.

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

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

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

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

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

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

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

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

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

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

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