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

Сегодня я расскажу про технологию, которая позволяет учить нейросети, объединяя через интернет вычислительные мощности энтузиастов из любой точки мира. В её основе лежит совместная научная работа Yandex Research, Hugging Face, студентов ШАД, ВШЭ и МФТИ, а также профессора Университета Торонто. Технология уже получила боевое крещение в ходе реального эксперимента, подробно описанного ниже. В конце статьи вы узнаете, как поставить такой эксперимент самостоятельно — модель и код доступны всем желающим.

Претрейн для всех, и пусть никто не уйдёт обиженным

За последние несколько лет во многих областях deep learning (например, в обработке естественного языка) стала популярной идея self-supervised learning. Оказалось, что для получения полезных в целевой задаче представлений не нужна большая размеченная выборка. Достаточно обучить модель на какой-то простой сигнал, построенный из неразмеченных данных, которых чаще всего в достатке. В частности, известные многим архитектуры BERT, GPT и языковая модель YaLM обучаются именно так.

Разработчик инфраструктуры качества поиска Яндекса Ильнур Хузиев ilnurKh взял простую задачу — скалярное произведение двух векторов — и попробовал выжать все соки производительности кода. Из доклада вы узнаете, как использовать возможности процессора, настройки компилятора (и даже попробовать превзойти его), какой была бы правильная постановка задачи, как выбирать приоритеты и архитектуру. Да, вопрос выбора абстракций может встать даже на примере настолько простой задачи.

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

Хеш-таблицы — это королевы структур данных. Нигде не сломано так много копий, как на оптимизации хеш-таблиц. В докладе я рассказал ещё об одной хеш-таблице, которая используется в ClickHouse. Вы увидите, что zero-cost abstractions в современном С++ оправдывают себя и как с помощью небольших трюков получить разнообразные структуры данных из общей кодовой базы. На основе общих строительных блоков можно построить быстроочищаемую хеш-таблицу, несколько видов LRU-кешей, lookup-таблицы без хешей, хеш-таблицы для строк и т. п. Я показал, как получить максимальную производительность на конкретных сценариях и не ошибиться при её тестировании. В моём докладе — самая мякотка низкоуровневых оптимизаций. В общем, то, что мы любим.

— Для начала мы обсудим, зачем нужны хеш-таблицы, где их можно использовать в базах данных и как сделать их оптимальными. Затем посмотрим бенчмарки различных хеш-таблиц в интернете и разбёремся, как делать их правильно. В конце посмотрим на C++-обертку над идеальной хеш-таблицей в ClickHouse.

В этой статье я расскажу о долгом путешествии, в котором простая идея выноса в JavaScript часто меняющихся фрагментов алгоритма постепенно выросла в универсальный фреймворк, позволяющий быстро создавать микросервисы и так же быстро их развивать. Сейчас он служит основой для множества микросервисов в Яндекс Go. Тут не будет много специфики Go. Вместо этого будет много разработки и решений технических задач (а не продуктовых). Ещё я, конечно, расскажу про возникшие в процессе трудности: если вам, например, интересно, как V8 уживается с корутинами или как мы оптимизировали работу с ним для производительности, то добро пожаловать под кат.

Что делать, если у вас завелись микросервисы, API стало слишком сложно пользоваться и на фронте все чаще мелькает undefined is not a function? На примере Яндекс.Погоды я показал, как мы эволюционировали из REST в GraphQL и почему это сделало жизнь разработчиков фронтенда и приложений мягкой и шелковистой.

— Меня зовут Всеволод Струкчинский, я ведущий разработчик Яндекс.Погоды. Доклад будет о том, как мы проектируем свой API, чтобы им было удобно пользоваться и мы от него не страдали.

Привет! Меня зовут Павел Анохин, я сооснователь и один из кураторов музея Яндекса. Хочу поделиться историей, связанной с нашим экспонатом — редкой платой с Лисп-процессором Symbolics. История эта уходит корнями в далёкое прошлое компьютерной эры — 70-е, времена огромных ЭВМ и первого бума интереса к искусственному интеллекту, продолжается в 80-е, когда Ричард Столлман воевал с компанией Symbolics за право открытого доступа к софту, и заканчивается в 90-х, когда ниша для применения Лисп-машин стала совсем узкой, а небольшие производители компьютеров пали под натиском крупных корпораций. Надеюсь, вам будет интересно узнать обо всём этом больше, а также посмотреть, как работает главный интерфейс Лисп-машины — Listener. Специально для статьи я записал видео с примерами создания несложных программ.


^{Лисп-плата из музея Яндекса}

Привет! Меня зовут Виктор Хомяков, в Яндексе я работаю над скоростью страниц поиска. Однажды мне в голову пришла идея обобщить свой опыт и систематизировать приёмы ускорения работы кода на JavaScript. То, что получилось в итоге, собрано в этом материале.

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

• Организационные
  　Культура разработки performance-first
  　Бюджет скорости
  　Performance mantras
• Те, что можно использовать независимо от языка и его реализации
  　Смена языка или фреймворка
  　Смена алгоритма
  　Оптимизация алгоритма
  　Вынос инвариантов на уровень выше
  　Boolean short circuit
  　Досрочный выход из цикла
  　Предвычисление
• Для языков/фреймворков, в которых нет ленивых вычислений и приёма copy-on-write
  　Shortcut fusion
  　Ленивое вычисление
  　Copy-on-write
  　Оверинжиниринг
• Зависящие от железа
  　Разворачивание мелких циклов
  　Предсказание ветвлений (Branch prediction)
  　Доступ к памяти: направление итерации
  　Доступ к памяти: [i][j] vs [j][i]
• Для языков со сборкой мусора
  　Мутабельность
  　Zero memory allocation или GC-free
• Специфичные для JavaScript
  　Антипаттерн: накопление строк в массиве
  　Антипаттерн: Lodash _.defaults
  　Idle Until Urgent
  　Даунгрейд кода: ES6 → ES5
• Примеры из код-ревью

Архитектура современных приложений часто позволяет передавать логику между клиентом и бэкендом. Главное — не зайти в этих экспериментах слишком далеко. Разработчик iOS-приложения Авто.ру Сергей Сергеев объяснил, как его команда пришла к backend driven UI не самым легким способом.

— Всем привет. Я iOS-разработчик, но история будет кроссплатформенная.

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

Меня зовут Андрей Малинин, я старший исследователь в Yandex Research. Сегодня я расскажу о проблеме, о наших датасетах, а также о конкурсе, который мы проводим в рамках международной конференции NeurIPS 2021 совместно с учеными из Оксфордского и Кембриджского университетов.

Чем больше процессов тестирования автоматизированы, тем эффективнее релизный пайплайн и тем быстрее пользователи получают новые возможности в сервисе. Руководитель Android-разработки Яндекс.Недвижимости Александр Рогов вспомнил, как эволюционировало UI-тестирование в его команде, как разработчики пришли к идее автоматизации, почему использовали фреймворк Espresso, с какими проблемами столкнулись и что в итоге получили.

— Начать хотелось бы с небольшого исторического экскурса.

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

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

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

Чем мы занимаемся

— Итак, давайте начинать. Наверняка все из вас каким-то образом связаны с IT и знают нормальный жизненный цикл или каждодневную работу разработчика. Он приносит основную ценность тем, что пишет код.

Привет! Сегодня мы поговорим с вами о том, как эволюционировала архитектура Яндекс.Афиши, а именно — как и почему мы перешли от REST на GraphQL к Node.js + Python, а потом в целях оптимизации избавились от Node.js + Python и переписали весь GraphQL на Java. Это история борьбы за производительность, скорость и удобство работы Афиши и некоторых других сервисов, которая может быть полезна тем, кто планирует оптимизировать ресурсы на своём проекте, ускорить работу запросов в БД, создать быстрый и поддерживаемый API Gateway с удобным языком запросов или разделить устаревший монолит на микросервисы.



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

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

На связи Антон Дворкович. Вы можете помнить меня по постам о тонкостях чувашского языка и технологиях машинного перевода. Почему сегодня я рассказываю о Клавиатуре? Потому что в её основе — технологии и опыт Яндекс.Переводчика. Именно они помогают пользователям меньше ошибаться и печатать быстрее.

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

Времена, когда для экземпляра базы данных выделялся отдельный компьютер, давно прошли. Сейчас повсюду управляемые решения, поднимающие необходимые процессы в виртуальных машинах. Для вычислений применяется еще более прогрессивный подход — «бессерверные вычисления», например AWS Lambda или Yandex Cloud Funtions. И уж совсем на острие прогресса находятся бессерверные БД. Руководитель отдела разработки систем хранения и обработки данных Yandex.Cloud Андрей Фомичёв Anfo рассказал о бессерверных решениях, которые еще до всеобщего хайпа стали популярны в Яндексе и по-прежнему используются для хранения и обработки данных.

— Всем привет. Если вы не очень знаете, что означает слово «мультиарендный» (multitenant) в названии доклада — ничего страшного, я расскажу поподробнее, и станет понятно.

Доклад будет из четырех разделов. Сначала я расскажу, что такое многопользовательские и multitenant-системы и чем они отличаются. Потом приведу примеры мультиарендных multitenant-систем в Яндексе: Yandex Database (YDB) и Yandex Query. Затем расскажу, как мы все эти системы реализовываем, какие в них особенности. В заключение подведу итоги доклада.

Привет, меня зовут Костя Кардаманов, я работаю в отделе технологий разработки Яндекса. Обычно такой же фразой я приветствую и кандидатов на собеседовании. А сегодня я хотел бы рассказать вам, как и зачем мы проводим интервью по дизайну систем с бэкенд-разработчиками. Сразу скажу: для фронтендеров, мобильных разработчиков и ML-инженеров подобный тип собеседований применим слабо, так что эти специальности мы здесь обсуждать не будем.

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

Что такое дизайн информационных систем

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

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

Яндекс Go разрабатывает платформу управления данными (DMP) как сервис для офлайн- и near real-time-обработки данных. Я постарался рассказать, какая мотивация нужна для создания собственного ETL-инструмента, как ETL и Data Warehouse превратить в DMP, какие проблемы возникают в процессе разработки и как мы их решаем.

— Меня зовут Владимир Верстов, я руковожу разработкой DMP в Яндекс Go — той частью, которая относится к платформе. Не контентной частью, а универсальными инструментами, которые мы переиспользуем, чтобы удобным образом выстроить внутри Такси, Еды и Лавки потоки данных и другие процессы, связанные с дата-инжинирингом. Чтобы сделать сущность, позволяющую дата-инженерам, аналитикам и разработчикам бэкенда коммуницировать на уровне данных и процессов.

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

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

— Всем привет. У меня доклад с интригующим названием в виде одного тега.

Только что мы представили новую версию поиска Y1. Она включает в себя комплекс технологических изменений. В том числе улучшения в ранжировании за счёт более глубокого применения трансформеров. Подробнее об этом направлении мой коллега Саша Готманов уже рассказывал в нашем блоге. В новой версии модель стала мощнее: количество параметров возросло в 4 раза. Но сегодня мы поговорим о других изменениях.

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

Сегодня мы поделимся опытом создания и внедрения технологии YaLM (Yet another Language Model), которая теперь готовит ответы для Поиска и Алисы. В этом мне помогут её создатели — Алексей Петров petrovlesha и Николай Зинов nzinov. Эта история основана на их докладе с Data Fest 2021 и описывает опыт внедрения модели в реальные продукты, поэтому будет полезна и другим специалистам в области NLP. Передаю слово Алексею и Николаю.