Недавно я получил статус Major Contributor в проекте PostgreSQL. Это довольно радостное для меня событие и интересное, поэтому коллеги попросили написать статью об этом. А чтобы я не сомневался — заботливо составили список достижений за меня. Получилось замечательно, но публиковать от своего имени статью вида «как я крут» я не хочу. Я совсем не против про это говорить, и из каждого утюга вещаю про разные технологии, сделанные моей командой или вот прям вообще мной. Но только в контексте «как использовать эти технологии», либо в узком кругу или личной беседе. 

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

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

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

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

Меня зовут Михаил Пожидаев, я работаю доцентом теоретической информатики в Томском государственном университете. Читаю такие предметы как обработка естественного языка, ОС UNIX, анализ социальных сетей и введение в программную инженерию. В этой статье расскажу о своём опыте создания программных продуктов, которые должны казаться странными и нелогичными в привычных обстоятельствах, но обстоятельства нестандартны.

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

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

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

Меня зовут Игорь Зверев, я руководитель группы разработки автонавигации в Яндекс Картах. Сегодня я расскажу, как мы подошли к решению этой задачи: что изменили в процессе разработки, как создали и используем систему RAM‑классов для выпуска требовательных функций и какие технические выводы сделали на этом пути.

Представьте, что у вас есть карта города, способная «рассказывать истории» про людей, дороги, дожди и события — прямо сейчас, вживую. С помощью платформы Atlas анализ города превращается в чтение интерактивной хроники, а не в просмотр сухой статистики.

Привет! Меня зовут Аня, я руковожу службой аналитических платформ в Яндексе. Сегодня я расскажу про один из наших инструментов — SaaS‑платформу Atlas. Ей пользуются аналитики из Яндекс Такси, Доставки, Лавки и других сервисов Яндекса. Atlas помогает визуализировать данные, быстро находить и проверять гипотезы, а ещё — оперативно делиться инсайтами. Под катом — подробности о том, как работает платформа и с какими кейсами она помогает справляться, а также как вы можете попробовать её в деле. 

Меня зовут Владимир Аксёнов, я раб��таю в Yandex Infrastructure и руковожу IT‑поддержкой в том самом дата‑центре Яндекса, который стал первой площадкой в собственности компании. Это определило его судьбу первопроходца: именно здесь мы тестируем множество технологий, которые затем распространяются на другие дата‑центры.

За 13 лет на этой площадке мы наблюдали радикальные изменения форм‑фактора сетевого и серверного оборудования, что повлекло за собой серьёзные метаморфозы во всём дата‑центре. Мы прошли путь от стандартной 19-дюймовой стойки до четвёртого поколения стоек собственного дизайна, а от холодных коридоров с доохлаждением — пришли к энергоэффективному фрикулингу. 

В этой статье покажу, как за это время поменялось IT‑оборудование, как это повлияло на облик дата‑центров, и что интересного ждём в наших дата‑центрах в 2026 году.

Всем привет! Меня зовут Олег Смоляков, в Яндексе я больше 15 лет занимался разработкой, а теперь отвечаю за улучшение процесса найма разработчиков.

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

TLDR: мы решили обновить процесс найма, вместо порой хаотичных собеседований в каждом отдельном сервисе внедряем единую систему оценки по профессии и уровню (например, «Senior C++ Developer»), кандидат, успешно прошедший оценку навыков, теперь сможет претендовать на аналогичные вакансии в любом из 90+ сервисов компании, а всё это вместе делает процесс найма прозрачным, понятным, без дублирования технических интервью и в целом эффективным для всех участников.

А теперь подробнее о том, почему мы на это пошли и как всё устроено.

Прежде чем прис��упить к готовке настоящей Системы управления информационной безопасности (СУИБ) по ISO/IEC 27001:2022, важно осознать масштаб: у нас в хозяйстве Яндекс 360 множество сервисов с уникальным вкусом и историей, каждый из которых требует бережного подхода и особой организации защиты.

Стандартизация для нас — способ не «пересолить» сложность и хаос: и мы выбрали ISO как универсальное мерило баланса. Наш главный секрет: процессы изначально проектируются по стандарту ISO, а по мере расширения области действия сертификации новые сервисы — Диск, Мессенджер, Телемост, Календарь — поступают на общий дегустационный стол сертификации и достойно занимают своё место в большом ИБ‑меню.

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

Те, кто имел дело с покупкой и продажей недвижимости, знает, что просмотры — очень хлопотное занятие. Неудивительно, что для экономии времени появляются предложения посмотреть квартиру онлайн или с помощью 3D‑тура. О таких виртуальных экскурсиях мы сегодня и поговорим.

В сентябре Яндекс Недвижимость рассказала о 3D‑турах для новостроек. С момента начала тестирования в июле на сервисе было сгенерировано более четверти миллиона виртуальных экскурсий по строящимся квартирам. Чтобы это стало возможным, мы обучили нейросеть анализировать планировки и превращать их в трёхмерные визуализации. Но чтобы это стало возможным, нужно было проделать боль��ую и кропотливую работу, чтобы нейросеть понимала, где отрисовывать окно или класть плитку на пол.

Меня зовут Катя Шибанова, я работаю архитектором краудсорсинговых решений (CSA) в службе разметки данных Yandex Crowd Solutions. Недавно к нам обратились коллеги из Яндекс Недвижимости: нужно было помочь с разметкой для обучения модели компьютерного зрения, которую используют для создания 3D‑туров. Об этом интересном проекте и будет мой рассказ. Я расскажу, чем опасны миллиметровые зазоры между полигонами в разметке, почему помимо типов помещений (кухня, спальня, санузел и тому подобное) нужно размечать структурно важные элементы — двери, окна, несущие стены, а также почему приоритизация геометрической согласованности важнее «средней» точности по пикселям.

Всем привет! Меня зовут Денис Кузнеделев, я работаю в команде Yandex Research. Моё основное направление деятельности на данный момент — задача сжатия и ускорения больших языковых и картиночных моделей. Затраты на обучение, инференс и деплой LLM стали одной из ключевых инфраструктурных проблем индустрии: дефицит вычислительных ресурсов, нехватка видеопамяти и высокие требования языковых моделей к вычислительным ресурсам препятствуют масштабированию решений. 

Сегодня я расскажу о методе неравномерного сжатия нейронных сетей EvoPress, который мы предложили совместно с коллегами из ETH Zurich и представили в июле этого года на одной из ведущих конференций по машинному обучению — ICML.

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

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

Для ускорения сходимости широко применяются методы с механизмом импульса (momentum): классический метод Поляка — Heavy Ball (HB) — и метод Нестерова (ускоренный градиент). Оба эти метода используют идею накапливать «инерцию» градиента, благодаря чему могут двигаться по направлению оптимума быстрее обычного градиентного спуска. 

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

Всем привет! Меня зовут Степан Трифонов, я аналитик‑разработчик в Яндекс Пэй. Недавно мы с коллегами, Леонидом Левиным и Савелием Чежеговым, опубликовали научную статью Incorporating Preconditioning into Accelerated Approaches: Theoretical Guarantees and Practical Improvement, где ввели предобусловленные версии классических ускоренных методов — Preconditioned Heavy Ball (PHB) и Preconditioned Nesterov (PN) — и доказали для них оценки сходимости при весьма общих допущениях на предобусловливающую матрицу. Также мы провели численные эксперименты, которые продемонстрировали практический выигрыш новых алгоритмов по сравнению с обычными (непредобусловленными) методами HB и Нестерова.

Всем привет! Меня зовут Илья Кара́псин, я работаю над производительностью Яндекс Браузера. Задачи моей команды включают не только работу над самим браузером, но и прямое улучшение используемых в нём опенсорс‑решений, например Chromium и применяемых в нём проектов (Blink, V8, Catapult), в том числе и компиляторов (LLVM Clang). Другими словами, мы вносим вклад в сообщество. При этом поиск и создание улучшений для сторонних опенсорс‑проектов может стать прямой рабочей задачей даже в ходе стажировки.

К слову, моя работа в Браузере как раз с неё и началась. При отборе положительно сказалось наличие у меня pet‑проектов: отдельного внимания заслужил проект, использующий озвучку и SFX (сноска: сокращение от англ. sound effects — звуковые эффекты) из Heroes of Might and Magic V. Так удивительно совпало, что мой будущий руководитель ранее работал в Nival Interactive как раз над этой игрой.

А в этой статье я расскажу о том, как обычное сокращение полных файловых путей в логах до имени файла (например, path/to/filename → filename) может повлиять на размер исполняемых файлов и производительность Браузера, а также внести вклад в проект LLVM Clang.

Gray failure, то есть серый, или частичный отказ, — довольно коварная ситуация, когда система демонстрирует квазирабочее состояние. С одной стороны, по проверкам состояния мы наблюдаем работоспособность ресурса, но когда отправляем на него реальную нагрузку — ничего не работает.

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

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

• какая работа по предотвращению серых отказов была проделана на нашей стороне за счёт слаженной работы всей команды;

• какие настройки стоит взять на вооружение пользователям Yandex Cloud и какие рекомендации могут быть полезны всем ответственным за Disaster Recovery;

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

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

Привет! Меня зовут Дарья Шатько, я руководитель ML-группы �� Yandex Crowd. В этой статье я расскажу, как мы с моим коллегой Антоном Удаловым внедряли большие языковые модели в контроль качества клиентской поддержки. А именно — почему регулярки и BERT не взлетели, как мы собрали репрезентативный golden‑датасет, как победили лимит контекста, снизили ложные срабатывания через многоступенчатый LLM‑flow и в итоге покрыли проверками абсолютно все диалоги поддержки.

При создании интерфейса важно проверить, как он реально выглядит. Часто это проверяют все участники процесса — от разработчиков до менеджеров. И для автоматизации и упрощения процесса визуального тестирования приложения есть специальный инструмент — golden‑тесты. Это методология тестирования, в которой текущий UI сравнивается с предварительно сгенерированным «золотым» эталоном. Если вы уже слышали про скриншот‑тесты — это примерно то же самое, но есть нюансы.

Меня зовут Даниил Липаткин, я тимлид в команде разработки курьерского приложения Яндекс Доставки. В этой статье:

— Мы познакомимся с методологией, рассмотрим её преимущества и недостатки, а также когда её стоит и не стоит применять.

— Напишем базовый Golden‑тест на примере стандартных инструментов библиотеки flutter_test.

— Рассмотрим пакет alchemist, который решает проблему платформозависимости flutter_test.

— Получим прикладные рекомендации по применению тестов и настройке IDE и CI.

Сегодня на Yandex Neuro Scale 2025 наша ML‑команда представила обновлённую AI Studio — платформу с большим набором инструментов для разработки ИИ‑агентов в единой end‑to‑end‑среде. Среди новинок — визуальный конструктор агентов, поддержка популярных API и реализация протокола MСP, механизмы AI search.

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

Вместе с коллегами из команды разработки Анастасией Каримовой и Дмитрием Рыбалко покажем, как это устроено под капотом:

— какие особенности эксплуатации нам нужно было учесть, чтобы найти баланс между производительностью и качеством;

— как мы сталкивались с особенностями опенсорс‑инструментов для ML и учились справляться с этим разными способами;

— как мы упростили создание голосовых агентов и заодно уменьшили latency запросов.

Привет! Меня зовут Геннадий Денисов, я руковожу одной из команд разработки мобильного Яндекс Браузера для Android. Недавно в рамках одного проекта мы интегрировали С++‑код в мобильное приложение Браузера. В этой статье я поделюсь основными нюансами работы с Java Native Interface (JNI), инструментами для упрощения разработки и подробностями нашего подхода.

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

Меня зовут Владимир Быстрицкий, я руковожу группой AI-картографирования. В этой статье расскажу о процессе детектирования дорожных знаков в картопроизводстве Яндекса: с чего всё началось, как развивалось, какие технологии использовались. Ну и попробую ответить на самый, на мой взгляд, главный вопрос в любой ML-задаче: как собрать датасет и не разориться?

Привет! Меня зовут Олег Безушко, и наша команда отвечает за эксплуатацию видеоконференцсвязи (ВКС) в Яндексе. Мои коллеги уже писали, как мы управляем переговорками с помощью инструмента Room Passport, а сегодня я расскажу, что происходит «на земле»: чем живут инженеры ВКС и как справляются с огромным объёмом задач силами очень компактной команды.

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