![image](https://habrastorage.org/webt/uo/jc/rt/uojcrt65urd9u522mqykbogsapo.jpeg)
Собеседования по проектированию систем машинного обучения — самые сложные. Если нужно подготовиться к такому, книга создана специально для вас.
Также она поможет всем, кто интересуется проектированием систем МО, будь то новички или опытные инженеры.
Что внутри?
- О чем на самом деле спрашивают на собеседовании по System Design в МО и почему (инсайдерская информация!).
- 7 основных шагов для решения любой задачи МО, предлагаемой на собеседовании.
- 10 вопросов из реальных собеседований по System Design в МО с подробным разбором ответов.
- 211 диаграмм, которые наглядно объясняют, как работают различные системы.
Книга будет ценным источником информации для всех, кто интересуется проектированием систем МО, будь то новички или опытные инженеры. А если вам нужно подготовиться к собеседованию по МО, то эта книга написана специально для вас.
Чего нет в книге
Эта книга — не пособие по основам машинного обучения. Она написана для дата-сайентистов, инженеров данных и инженеров МО, которым нужна помощь, чтобы подготовиться к собеседованию по проектированию систем МО. Книга предназначена в первую очередь для инженеров МО в бизнесе и в меньшей степени для ученых в области МО в образовательных учреждениях или НИИ.
Поиск видео на Youtube
На платформах видеохостинга, таких как YouTube, количество видеороликов быстро возрастает до миллиардов. В этой главе мы спроектируем систему поиска видео, которая может эффективно работать с таким объемом контента. Как показано на рис. 4.1, пользователь вводит текст в поле поиска, а система выводит список видеороликов, которые лучше всего соответствуют этому запросу.
![image](https://habrastorage.org/webt/xr/gw/_l/xrgw_ls2ho67deto9tbs_qv2zc8.png)
Прояснение требований
Вот типичный диалог между соискателем и экспертом:
Соискатель: В поле поиска можно вводить только текст или пользователи могут искать по изображениям и видео?
Эксперт: Только текстовые запросы.
Соискатель: Контент на платформе представлен только в формате видео? Как насчет изображений или аудиофайлов?
Эксперт: На платформе размещается только видео.
Соискатель: Система поиска YouTube очень сложна. Можно ли предположить, что релевантность видео определяется исключительно его визуальным содержанием и сопутствующими текстовыми данными — например, названием и описанием?
Эксперт: Да, это справедливое допущение.
Соискатель: Доступны ли обучающие данные?
Эксперт: Да, будем считать, что доступны 10 миллионов пар типа ⟨видео, текстовый запрос⟩.
Соискатель: Должна ли система поиска поддерживать другие языки?
Эксперт: Для простоты будем считать, что поддерживается только один язык.
Соискатель: Сколько видеороликов доступно на платформе?
Эксперт: Один миллиард.
Соискатель: Нужно ли персонализировать результаты? Должны ли они ранжироваться по-разному для разных пользователей в зависимости от их предыдущих взаимодействий?
Эксперт: В отличие от рекомендательных систем, где персонализация абсолютно необходима, в поисковых системах персонализировать результаты не обязательно. Чтобы упростить задачу, будем считать, что персонализация не нужна.
Резюмируем описание проблемы. Требуется спроектировать систему поиска видео. На вход подается текстовый запрос, а на выходе отображается список видеороликов, которые соответствуют запросу. Чтобы найти релевантные ролики, мы будем использовать как их визуальное содержание, так и текстовые данные. Для обучения модели доступен датасет из 10 миллионов пар типа ⟨видео, текстовый запрос⟩.
Формулировка проблемы в виде задачи МО
Определение цели МО
Пользователи ожидают, что поисковые системы выдают релевантные и полезные результаты. Один из способов преобразовать эти ожидания в цель МО заключается в том, чтобы ранжировать видеоролики в зависимости от их релевантности текстовому запросу.
Определение входных и выходных данных системы
Как показано на рис. 4.2, система поиска принимает на вход текстовый запрос и выдает список видеороликов, отсортированных по релевантности этому запросу.
![image](https://habrastorage.org/webt/ru/v1/jh/ruv1jhkrmgejgq77a8q4uxs01fi.png)
Выбор категории МО
Чтобы установить релевантность между видео и текстовым запросом, мы будем использовать как визуальное содержание, так и текстовые данные видео. Общий обзор архитектуры представлен на рис. 4.3.
![image](https://habrastorage.org/webt/zk/0z/m2/zk0zm2jnmw5ao_5xzpmqtsmhuie.png)
Кратко рассмотрим каждый из этих компонентов.
Визуальный поиск
Этот компонент принимает на вход текстовый запрос и выдает список видеороликов. Результаты ранжируются по степени сходства между текстовым запросом и визуальным содержанием.
Для поиска видеороликов по их визуальному содержанию часто применяется обучение представлений. В этом методе текстовый запрос и видео кодируются по отдельности с помощью двух кодировщиков. Как показано на рис. 4.4, модель МО содержит кодировщик видео, который генерирует вектор эмбеддинга на основе содержания видео, а также текстовый кодировщик, генерирующий вектор эмбеддинга на основе текста. Метрика сходства между видео и текстом вычисляется через скалярное произведение их представлений.
![image](https://habrastorage.org/webt/n0/uy/sq/n0uysqvxzpkqsy5acgjpr7w0eu4.png)
Чтобы ранжировать видеоролики, которые визуально и семантически близки к текстовому запросу, мы вычисляем скалярное произведение между текстом и каждым видеороликом в пространстве эмбеддингов, а затем ранжируем видео на основании этой метрики сходства.
Текстовый поиск
На рис. 4.5 показано, как работает текстовый поиск, когда пользователь вводит текстовый запрос: «собаки играют на лужайке». В качестве результатов отображаются видеоролики, чьи названия, описания или теги наиболее похожи на текстовый запрос.
![image](https://habrastorage.org/webt/wy/4l/s4/wy4ls4eunnzgmlmjy8u8td-zbw0.png)
Стандартный метод создания текстового компонента поиска — обратный индекс, который позволяет эффективно проводить полнотекстовый поиск в базах данных. Поскольку обратная индексация не базируется на МО, она не требует затрат на обучение. Многие компании используют Elasticsearch — масштабируемый поисковый движок и хранилище документов. Чтобы подробнее узнать про Elasticsearch и глубже понять принципы его работы, обращайтесь к.
Подготовка данных
Инженерия данных
Поскольку у нас есть размеченный датасет для обучения и оценки модели, инженерия данных не требуется. В табл. 4.1 показано, как может выглядеть размеченный датасет.
![image](https://habrastorage.org/webt/n4/ov/x8/n4ovx8l8isrrljot0ck4arg4cg0.png)
Конструирование признаков
Почти все алгоритмы МО принимают только числовые входные значения. На этапе конструирования признаков все неструктурированные данные, такие как текст и видео, должны быть преобразованы в числовое представление. Посмотрим, как подготовить текстовые и видеоданные для модели.
Подготовка текстовых данных
Как показано на рис. 4.6, текст обычно преобразуется в числовой вектор за три шага: нормализация текста, лексический анализ (токенизация) и преобразование токенов (лексем) в идентификаторы.
![image](https://habrastorage.org/webt/jg/pf/ne/jgpfnegms9zw0x6rffrklan241k.png)
Рассмотрим каждый шаг подробнее.
Нормализация текста
Нормализация текста обеспечивает единообразие слов и предложений. Например, слова «собака», «собаке» и «СОБАКА!» обозначают одно и то же, но записываются по-разному. То же можно сказать и о предложениях. Для примера возьмем такие два предложения:
- «Человек гуляет с собакой по Петербургу!»
- «человек, гуляющий со своей собакой в Санкт-Петербурге».
- Приведение к нижнему регистру: все буквы переводятся в нижний регистр, потому что от этого не меняется смысл слов или предложений.
- Удаление знаков препинания: из текста удаляются все знаки препинания: точки, запятые, вопросительные и восклицательные знаки и т. д.
- Усечение пробелов: из текста удаляются начальные, конечные и сгруппированные пробельные символы.
- Нормализация NFKD (совместимая декомпозиция): комбинированные графемы раскладываются на комбинации простых графем.
- Удаление диакритики: из слов удаляются диакритические знаки: Màlaga → Malaga, Noël → Noel
- Лемматизация и выделение основ: для набора взаимосвязанных форм слова определяется каноническая форма: гуляет, гуляющий, гуляли → гулять.
Лексический анализ (токенизация) — процесс разбиения текста на меньшие единицы, называемые лексемами (токенами). В общем случае применяются три разновидности токенизации.
- По словам: текст разбивается на отдельные слова по заданным ограничителям. Например, фраза вида «У меня завтра собеседование» превращается в [«У», «меня», «завтра», «собеседование»].
- По подсловам.
- По символам.
Преобразование лексем в идентификаторы
После того как мы получили лексемы, их надо преобразовать в числовые значения (идентификаторы). Это можно сделать двумя способами:
- таблица сопоставления;
- хеширование.
![image](https://habrastorage.org/webt/52/p-/tu/52p-tu3splyl0hgd_dlywzrqxhm.png)
Хеширование. Этот метод вырабатывает идентификаторы с помощью хеш-функции, что позволяет обойтись без таблицы сопоставления и таким образом сэкономить память. На рис. 4.8 представлен пример преобразования слов в идентификаторы с помощью хеш-функции.
![image](https://habrastorage.org/webt/lu/dc/n0/ludcn0tyv1g2756h3endvdaftjy.png)
Сравним таблицу сопоставления с методом хеширования.
![image](https://habrastorage.org/webt/gu/it/qb/guitqbto_jyzk-1jyzpj8rcj-60.png)
Подготовка видеоданных
На рис. 4.9 показан типичный процесс предварительной обработки видеоматериала.
![image](https://habrastorage.org/webt/ue/ab/ep/ueabep0gg8djozo-ljihid_66t4.png)
Разработка модели
Выбор модели
Как упоминалось в разделе «Формулировка проблемы как задачи МО», текстовые запросы преобразуются в эмбеддинги кодировщиком текста, а видеоданные — кодировщиком видео. В этом разделе мы рассмотрим возможные архитектуры моделей для каждого кодировщика.
Кодировщик текста
Входные и выходные данные типичного кодировщика текста изображены на рис. 4.10.
![image](https://habrastorage.org/webt/m9/gk/su/m9gksuy-j4mztyhsmpmu7ak8pt4.png)
Кодировщик текста преобразует текст в векторное представление. Например, если два предложения имеют сходный смысл, то их эмбеддинги более похожи. Кодировщики текста создаются либо статистическими методами, либо на основе МО. Рассмотрим оба варианта.
Статистические методы
Эти методы преобразуют предложения в векторы эмбеддингов с помощью статистики. Два самых популярных статистических метода:
- мешок слов (BoW, Bag of Words);
- TF–IDF (Term Frequency — Inverse Document Frequency, «частота слова — обратная частота документа»).
![image](https://habrastorage.org/webt/2a/-_/j0/2a-_j0k-nhhaak2ieiqkzx5syfw.png)
Мешок слов — простой метод, который быстро вычисляет представления предложений, но у него есть ряд недостатков.
- Не учитывается порядок слов в предложении. Например, у предложений «утром деньги, вечером стулья» и «утром стулья, вечером деньги» в мешке слов будут одинаковые представления.
- Полученное представление не отражает семантического и контекстного смысла предложения. Например, у двух предложений с одинаковым смыслом, но разными словами будут совершенно разные представления.
- Вектор представления является разреженным. Его размерность равна общему количеству уникальных лексем. Обычно оно очень велико, так что каждое представление в основном заполнено нулями.
Поскольку TF–IDF назначает меньший вес часто встречающимся словам, представления этого метода обычно лучше, чем мешка слов. Однако здесь тоже есть свои ограничения:
- когда добавляется новое предложение, нужно выполнить нормализацию, чтобы заново вычислить частоты слов;
- порядок слов в предложении не учитывается;
- полученное представление не отражает семантический смысл предложения;
- представления получаются разреженными.
Методы на основе МО
В этих методах модель МО преобразует предложения в осмысленные эмбеддинги слов, так что расстояние между двумя эмбеддингами отражает семантическую близость соответствующих слов. Например, если два слова (скажем, «богатый» и «благосостояние») семантически близки, то их эмбеддинги располагаются близко в пространстве эмбеддингов. На рис. 4.12 представлена простая визуализация эмбеддингов слов в двухмерном пространстве эмбеддингов. Как видите, похожие слова группируются.
![image](https://habrastorage.org/webt/sq/cg/qu/sqcgquv0no8onx5knmqcg6e1gco.png)
Существуют три распространенных метода преобразования текста в эмбеддинги, основанных на МО:
- слой сопоставления эмбеддингов;
- Word2vec;
- архитектуры на базе Transformer.
В этом методе добавляется слой, который ставит в соответствие каждому идентификатору вектор эмбеддинга. Пример показан на рис. 4.13.
![image](https://habrastorage.org/webt/yz/vh/nx/yzvhnx5eoztw9rh2lhzca7yxvmm.png)
Слой сопоставления эмбеддингов — простое и эффективное решение, чтобы преобразовывать разреженные признаки (такие, как идентификаторы) в эмбеддинги фиксированной размерности. Примеры его использования еще встретятся в следующих главах.
Word2vec
Word2vec — семейство взаимосвязанных моделей, с помощью которых создаются эмбеддинги слов. Эти модели базируются на архитектуре неглубокой нейронной сети и используют совместное вхождение слов в локальном контексте, чтобы обучаться на эмбеддингах слов. В частности, модель учится предсказывать центральное слово по окружающим словам. После фазы обучения модель способна преобразовывать слова в содержательные эмбеддинги.
На Word2vec базируются две основные модели: CBOW (Continuous Bag of Words, «непрерывный мешок слов») Система PYMK в LinkedIn и Skip-gram. На рис. 4.14 изображена высокоуровневая схема работы CBOW. Если вам захочется больше узнать об этих моделях, обращайтесь к.
![image](https://habrastorage.org/webt/1z/d5/nl/1zd5nl3kmbehsfee3evvsuagsxg.png)
Хотя Word2vec и слой сопоставления эмбеддингов просты и эффективны, свежие архитектуры на базе Transformer показывают многообещающие результаты.
Модели на базе Transformer
Преобразовывая слова в эмбеддинги, эти модели учитывают контекст слов в предложении. В отличие от моделей Word2vec, они производят разные эмбеддинги для одного и того же слова в зависимости от контекста.
На рис. 4.15 показана модель на базе Transformer, которая принимает на вход предложение (набор слов) и генерирует эмбеддинг для каждого слова.
Эти модели чрезвычайно эффективно распознают контекст и вырабатывают содержательные эмбеддинги. Некоторые модели, включая BERT , GPT3 и BLOOM , продемонстрировали потенциал Transformer для разнообразных задач обработки естественного языка (NLP). В нашем случае для кодирования текста мы выберем архитектуру на базе Transformer — такую, как BERT.
На некоторых собеседованиях вам могут предложить рассмотреть модель на базе Transformer на более глубоком уровне. За дополнительной информацией обращайтесь к.
![image](https://habrastorage.org/webt/72/gu/7-/72gu7-cghfvtjnjzarireaqwyme.png)
Кодировщик видео
Существует два архитектурных решения для кодирования видеоданных:
- модели на уровне видео;
- модели на уровне кадра.
![image](https://habrastorage.org/webt/wn/r5/nk/wnr5nk-yaxzh8kjps0yv49nt-g0.png)
Модели на уровне кадра работают иначе. В этом случае эмбеддинг для видео вырабатывается в три шага (рис. 4.17):
- выполнить предварительную обработку видео и сформировать выборку кадров;
- запустить модель на выборочных кадрах и создать их эмбеддинги;
- агрегировать (например, усреднить) эмбеддинги кадров, чтобы получить эмбеддинг для видео.
![image](https://habrastorage.org/webt/i9/9y/c1/i99yc16jbt_4mrmo9voyvbtousc.png)
Так как эта модель действует на уровне кадров, она часто работает быстрее и требует меньших вычислительных затрат. Однако модели на уровне кадров обычно не понимают аспектов развития во времени, таких как действия и перемещения на видео. На практике модели на уровне кадра предпочтительнее во многих случаях, когда не стоит задача анализировать развитие во времени.
В данном случае мы воспользуемся моделью на уровне кадра (такой, как ViT), чтобы обеспечить два преимущества:
- сократить скорость обучения и обслуживания запросов;
- сократить объем вычислений.
Обучение модели
Чтобы обучить кодировщики текста и видео, мы применим метод контрастного обучения. Если вам захочется больше узнать об этом, обратитесь к разделу «Обучение модели» в главе 2.
На рис. 4.18 показано, как вычисляются потери в ходе обучения модели.
![image](https://habrastorage.org/webt/vj/fi/gw/vjfigwu994d2dxiv-qncrow9zgo.png)
Об авторе
Алекс Сюй — опытный разработчик программного обеспечения и предприниматель. Ранее он работал в таких компаниях, как Twitter, Apple, Zynga и Oracle. Алекс получил степень магистра наук в Университете Карнеги-Меллона. Его страсть — проектирование и реализация сложных систем.
Более подробно с книгой можно ознакомиться на сайте издательства:
» Оглавление
» Отрывок
По факту оплаты бумажной версии книги на e-mail высылается электронная книга.
Для Хаброжителей скидка 25% по купону — Интервью
p/s идет Распродажа «Старый Новый год» в издательстве «Питер»