Всесторонний взгляд на реализацию «реальной» системы рекомендаций на основе контента

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

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

  • производительность,
  • доступность,
  • готовность данных и
  • Общая стоимость,

каждая из которых требует должного рассмотрения.

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

Требования к проекту

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

Другие ключевые требования:

  • Измеримая производительность модели и ценность для бизнеса
  • Задержка менее 500 миллисекунд.
  • Высокая доступность и масштабируемость с уровнем соглашения об уровне обслуживания (SLA) 99,9 %, что означает не более 1,44 минуты простоя в день.
  • Использование автоматизации для извлечения данных и модельного жизненного цикла сборки-развертывания-монитора.
  • Комплексный мониторинг моделей и API для использования в непрерывных улучшениях.
  • Совокупная стоимость владения (TCO) также была важным фактором, особенно повторяющиеся расходы на хостинг.

Шаг 1: Исследовательский анализ данных

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

Как только данные были извлечены, исследовательский анализ данных показал, что корпус был ограничен по размеру и содержал около 6800 пресс-релизов и 700 тематических статей. В данных также отсутствовали согласованные метаданные или теги между наборами данных, чтобы помочь в создании кандидатов. Что еще более важно, дальнейший анализ не выявил пользовательских данных или истории явных/неявных отзывов посетителей, на которых можно основывать рекомендации.

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

Шаг 2: Разработка рекомендательной модели

Для получения рекомендаций каждый пресс-релиз и рекомендуемая статья должны были предоставить максимально похожий контент в корпусе в ответ на запросы API. Чтобы выбрать лучший метод неконтролируемой обработки естественного языка (NLP), необходимо было оценить несколько алгоритмов, которые могут преобразовывать текст в векторы признаков. SentenceBERT, Doc2Vec, FastText и TF-IDF были выбраны для оценки того, какой алгоритм был наиболее эффективным для варианта использования и корпуса.

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

Без размеченных данных и стандартных метрик оценки, на которые можно было бы положиться, метрика точности, которая рассчитывала процент документов, которые сами получили наивысший балл в матрице косинусного сходства, использовалась как способ оценки общей точности модели. Метрика также использовалась для выполнения случайной перекрестной проверки для настройки гиперпараметров и этапов предварительной обработки перед окончательным сравнением. Общие результаты были хорошими для общей системы рекомендаций, но TF-IDF показала несколько лучшие рекомендации по сравнению с другими моделями.

Чтобы подтвердить первоначальные выводы, каждая модель была проверена путем сравнения широкой выборки рекомендаций с наблюдениями, подтверждающими, что TF-IDF обеспечивает хорошую точность и является лучшим выбором для проекта.

В отличие от других методов NLP, которые вычисляют встраивание слов и предложений, TF-IDF обеспечивает прямое извлечение признаков, придавая важность менее частым терминам. TF-IDF также обеспечивает более быстрое и менее ресурсоемкое создание моделей, а реализация достаточно проста, чтобы ее можно было легко объяснить заинтересованным сторонам.

Рекомендации по повторному ранжированию

Чтобы еще больше улучшить рекомендации, показатели сходства ранжируются заново, включая функции популярности и свежести. Использование популярности — это хороший способ повысить количество рекомендаций, и в этом случае оценки популярности основаны на показателях просмотров страниц, извлеченных из Google Analytics, а актуальность — на основе возраста документа. Обе оценки нормализуются, а затем усредняются по важности, прежде чем объединяются в окончательный балл.

Чтобы обеспечить предоставление рекомендаций только самого высокого качества, рекомендации API были ограничены тремя наивысшими баллами для каждого документа. Рекомендации также ограничиваются контентом, который посетитель недавно не просматривал. Новым посетителям, которые еще не взаимодействовали с контентом ленты новостей, предлагается сочетание самого популярного контента в ленте новостей.

Будущее состояние

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

Шаг 3. Персонализация рекомендаций

Наличие истории посетителей новостной ленты имеет решающее значение для того, чтобы API мог предоставлять персонализированные рекомендации по веб-сайту. Из-за характера сайта посетители не аутентифицируются и не отслеживаются таким образом, чтобы это было полезно в данном случае. Google Analytics используется для отслеживания общей активности веб-сайта, но не позволяет извлекать полные данные на уровне пользователя. Чтобы избежать ненужной сложности, был выбран подход, основанный на файлах cookie браузера, для отслеживания недавних выборов посетителей в ленте новостей.

Каждый раз, когда посетитель нажимает на содержимое новостной ленты, в браузере посетителя обновляется файл cookie, отражающий последние просмотренные страницы. Затем эти идентификаторы передаются в API для предоставления персонализированных рекомендаций.

Шаг 4. Разработка архитектуры развертывания

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

Были рассмотрены различные варианты развертывания AWS, включая конечные точки SageMaker и Elastic Beanstalk. Конечные точки SageMaker могут сделать развертывание моделей относительно простым, но, по моему опыту, модели, созданные не в SageMaker, могут быть громоздкими для развертывания, а документация может отсутствовать, а иногда и быть устаревшей. С точки зрения затрат, в развертываниях SageMaker обычно используются экземпляры виртуальных серверов EC2, которые оплачиваются почасово даже в периоды низкого спроса. Не идеально подходит для ленты новостей, которая, как ожидается, будет менее востребована в будние дни и в выходные дни.

В другом варианте используется Elastic Beanstalk для развертывания API с автоматически масштабируемыми инстансами EC2 с балансировкой нагрузки для обеспечения высокой доступности. Каждый экземпляр будет запускать Flask, Django или FastAPI для обработки входящих запросов API. Хотя Elastic Beanstalk — эффективный способ развертывания приложений, он имеет схожие финансовые последствия; услуга бесплатна, но любые запущенные инстансы EC2 оплачиваются круглосуточно и без выходных, независимо от того, используются они полностью или нет.

Бессерверная лямбда

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

Наряду с экономией затрат, Lambda поддерживает масштабируемость и доступность. Функции Lambda автоматически масштабируются для обработки более 1000 одновременных исполнений в каждом регионе и работают в нескольких зонах доступности, что соответствует требованиям SLA на уровне 99,9 %.

ДинамоДБ

Для хранения модели был выбран нетрадиционный шаблон с использованием DynamoDB, базы данных AWS NoSQL. Каждый элемент в базе данных будет документом JSON, в основном содержащим уникальный идентификатор контента с тремя идентификаторами контента с наивысшей оценкой. Это привело к очень быстрому поиску через API со средним временем отклика в 250 миллисекунд.

Что касается масштабируемости и высокой доступности, DynamoDB автоматически масштабирует емкость и перераспределяет данные по мере роста размера таблицы. Данные также реплицируются между тремя объектами в регионе AWS, что обеспечивает SLA на уровне 99,99 %.

Как бы ни была эффективна DynamoDB, ее использование для хранения моделей машинного обучения во многих ситуациях может оказаться неэффективным. Для хранения и загрузки больших моделей в целях логического вывода бессерверную Lambda можно использовать с эластичной файловой системой AWS (EFS) для различных вариантов использования. Дополнительную информацию о шаблоне Lambda/EFS можно найти в разделе Ресурсы.

Рекомендации AWS Lambda

Бессерверные архитектуры обеспечивают множество преимуществ по сравнению со стандартной архитектурой EC2 с балансировкой нагрузки, но им также свойственна проблема холодного запуска. В зависимости от размера пакета развертывания и времени инициализации функции задержка выполнения обычно составляет 1 % вызовов. Сохранение легкости пакетов развертывания важно, но если это невозможно, можно включить подготовленный параллелизм, чтобы запрошенное количество сред выполнения было инициализировано и готово отвечать на входящие запросы.

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

Глобальные соображения

Для глобальных вариантов использования важно оценить использование сети доставки контента (CDN). В зависимости от того, сколько данных отправляется через API и насколько хорошо они могут быть кэшированы, CDN могут значительно улучшить время отклика на международном уровне. Что касается ленты новостей, рекомендации хорошо кэшируются, а местоположения AWS CloudFront Edge обеспечат посетителям по всему миру быструю и стабильную производительность при вызове API.

Шаг 5: MLOps и доработка стратегии развертывания

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

Автоматизированное построение моделей

Вновь созданный контент будет автоматически обрабатываться каждый час запланированными сборками модели. Обработка почти в реальном времени может быть достигнута, но не обязательна, поскольку контент новостной ленты публикуется не с высокой частотой. Сценарии Python, размещенные в экземпляре EC2, позволяют собирать данные из нескольких источников, создавать модели и отправлять результаты в DynamoDB. Интенсивное использование ведения журнала с оповещением об ошибках гарантирует, что любые сбои могут быть быстро просмотрены и устранены.

Безопасность

Безопасность была неотъемлемой частью общего дизайна и должна была соответствовать организационным политикам. Помимо защиты политики ресурсов по умолчанию между сервисами AWS, трафик к API необходимо было шифровать по протоколу TLS и фильтровать через внутреннюю инфраструктуру сетевой безопасности. В зависимости от потребностей проекта доступен широкий спектр мер безопасности, включая фильтрацию IP-адресов, пользовательскую аутентификацию с помощью токена-носителя и AWS Cognito для (федеративной) аутентификации с единым входом или социальным входом.

API-мониторинг

Непрерывный мониторинг приложений — еще один важный аспект развертывания API. AWS CloudWatch по умолчанию фиксирует метрики выполнения Lambda, но также будет использоваться для подробного ведения журналов, а также для срабатывания сигналов тревоги как для метрик трафика, так и для проверок работоспособности.

В ситуациях, требующих высокой непрерывности, сигналы тревоги CloudWatch могут быть интегрированы в существующую инфраструктуру службы поддержки организации для создания приоритетных заявок. Журналы также могут быть объединены в инструменты, такие как Splunk, для получения дополнительных преимуществ, которые они предоставляют.

Мониторинг дрейфа модели

Попав в производственную среду, модели нуждаются в постоянном мониторинге, чтобы подтвердить их работоспособность и ценность для бизнеса. Изменение и перенос данных — основная причина, по которой точность развернутых моделей со временем снижается. Для ленты новостей без помеченных данных или ярлыков «наземной истины», на которые можно было бы полагаться, был разработан индекс оценки распределения сходства путем вычисления среднего значения наивысшей (не родительской) оценки сходства для всех документов. Затем общий балл индексируется до базового уровня.

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

CI/CD и контроль версий

В зависимости от размера проекта может быть реализован конвейер непрерывной интеграции/непрерывной доставки для обеспечения автоматизации при сборке, тестировании и развертывании. Доступны различные варианты CI/CD, в том числе конвейеры AWS CodeDeploy и SAM. Для этого проекта PyCharm с подключаемыми модулями AWS Toolkit и GitLab позволяет управлять контролем версий и развертыванием в Lambda, а готовые сценарии сборки модели автоматически загружаются в инстанс EC2 перед каждым запланированным запуском.

Шаг 6: A/B-тестирование

Рекомендации являются оценочными прогнозами и не дают гарантий того, как аудитория сайта отреагирует на рекомендательную стратегию. После развертывания системы рекомендаций в рабочей среде будет проведено A/B-тестирование для оценки ее эффективности путем сравнения показателей сайта, таких как рейтинг кликов (CTR), страниц за сеанс и средняя продолжительность сеанса с рекомендациями и без них. Данные показателей, собранные в ходе эксперимента, помогут подтвердить (или опровергнуть) стратегию. В конце концов, A/B-тестирование также будет использоваться для сравнения текущих и будущих стратегий рекомендаций.

Заключение

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

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

Ресурсы

[1] AWS, Руководство разработчика AWS Lambda (2022), Amazon Web Services

[2] AWS, Руководство разработчика по AWS DynamoDB (2022), Amazon Web Services

[3] AW, Руководство разработчика AWS API Gateway (2022), Amazon Web Services

[4] AWS, Руководство разработчика по AWS CloudFront (2022 г.), Amazon Web Services

[5] AWS, Руководство разработчика по AWS CloudWatch (2022), Amazon Web Services

[6] Н. Джайн, А. Вайдьянатан, С. Дебнат и В. Кришнамурти, Развертывание нескольких моделей машинного обучения для логического вывода на AWS Lambda и Amazon EFS (2021), Predictive Hacks

[7] И. Нджанджи, Узнайте, как использовать сигналы тревоги Amazon CloudWatch для создания инцидента в ServiceNow (2018), Amazon Web Services

[8] Splunk, Как передавать журналы AWS CloudWatch в Splunk (2017), Splunk

[9] М. Мантош, Разработка и развертывание бессерверных API с использованием AWS Toolkit (2021), JetBrains