Как создать базовую систему рекомендаций без машинного обучения

Рекомендательные системы стали неотъемлемой и незаменимой частью нашей жизни. Эти интеллектуальные алгоритмы играют решающую роль в формировании нашего онлайн-опыта, влияя на контент, который мы потребляем, продукты, которые мы покупаем, и услуги, которые мы изучаем. Независимо от того, транслируем ли мы контент на таких платформах, как Netflix , находим новую музыку на Spotify или делаем покупки в Интернете, системы рекомендаций незаметно работают над персонализацией и улучшением нашего взаимодействия.

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

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

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

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

Постановка задачи с инженерной точки зрения

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

На высоком уровне у нас были следующие требования с инженерной точки зрения:

1. Система должна иметь возможность улавливать интересы пользователя в виде ключевых слов. Система также должна иметь возможность классифицировать уровень интереса пользователя по конкретным ключевым словам.

   
   

2. Система должна быть способна уловить интерес пользователя к другим пользователям. Он должен иметь возможность классифицировать уровень интереса пользователя к контенту, созданному другим пользователем.

   
   

3. Система должна уметь генерировать качественные рекомендации, исходя из интересов пользователя.

   
   

4. Система должна быть в состоянии гарантировать, что рекомендации, которые уже просмотрены/отклонены пользователем, не появятся снова в течение X дней.

   
   

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

   
   

6. Система должна быть быстрой. Задержка P99 менее 150 миллисекунд.

   
   

7. Все остальные нефункциональные требования, такие как высокая доступность, масштабируемость, безопасность, надежность, ремонтопригодность и т. д., должны быть выполнены.

   
   

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

Решение - Высокоуровневая работа рекомендательного механизма.

Я обсужу решения проблемы одно за другим, а затем опишу общую работу всей системы.

Наша первая проблема — уловить интересы пользователя и определить уровень его интереса с помощью конкретного интереса.

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

Как вы можете видеть на изображении выше, мы храним много информации, такой как количество взаимодействий (лайков, комментариев, репостов) и давность этих взаимодействий (когда они происходили в последний раз) в качестве данных об отношениях между двумя пользователями, а также между пользователь и интерес. Мы даже сохраняем отношения между двумя разными ключевыми словами, представляющими интерес. я использовал Амазонка Нептун , управляемая база данных графов от AWS, для хранения этого социального графа. Вы можете использовать любую другую графовую базу данных, например Neo4j, JanusGraph, ArrangoDB и т. д.

Эти ключевые слова, представляющие интерес, преимущественно состоят из существительных. Существует система, которая разбивает содержимое сообщения на эти ключевые слова (существительные). Он работает на платформе AWS Comprehend; сервис обработки естественного языка (NLP), который использует машинное обучение для разбиения текста на сущности, ключевые фразы и т. д. Опять же, вы можете использовать любые управляемые сервисы NLP (несколько доступных) для достижения того же. Вам не нужно изучать или развертывать модели машинного обучения! Если вы уже разбираетесь в машинном обучении, можете пойти проверить модели НЛП с открытым исходным кодом, а также на Huggingface .

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

Следующая диаграмма представляет собой упрощенное представление того, как работает система.

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

Поясню пошагово:

Шаг 1. Преобразование содержимого публикации в векторные вложения

Чтобы сгенерировать эти рекомендации, сначала нам нужно преобразовать содержимое сообщения во что-то, называемое - Векторные вложения . В связи с недавним ростом брендинга LLM, OpenAI (создателей ChatGPT) и Векторные базы данных Векторные вложения становятся повседневным термином. Я не буду вдаваться в подробности, что это такое и как они работают, но настоятельно рекомендую прочитать о них больше. Но при создании подходящих кандидатов для ленты также необходимо учитывать такие вещи, как конфиденциальность и модерация контента (удаление ненормативной лексики, оскорблений, сексуального контента, преследования, фильтрация заблокированных пользователей и т. д.).

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

Шаг 2. Запросите интерес пользователя

А вот здесь все становится интереснее. Вы хотели бы разработать запросы на основе конкретных потребностей вашего бизнеса. Например, при запросе интересов мы придаем большее значение давности взаимодействия, чем количеству взаимодействий с определенным ключевым словом или пользователем. Мы также запускаем несколько параллельных запросов, чтобы найти различные типы интересов пользователя — ключевое слово или другого пользователя. Поскольку мы создаем несколько каналов для одного пользователя, мы также запускаем некоторые запросы, продвигающие определенную тему в соответствии с тенденцией (например, вы увидите много сообщений, связанных с Рождеством, рядом с Рождеством или сообщений, связанных с землетрясением, если землетрясение произошло). Излишне говорить, что эта тема появится в результатах запроса только в том случае, если пользователь проявил к ним некоторый интерес в своем путешествии.

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

Шаг 3. Выполните поиск ANN на основе найденных интересов.

Векторные базы данных преимущественно используются для выполнения определенного типа поиска, называемого Приблизительный поиск ближайшего соседа (АННА). Опять же, то, как вы классифицируете различные интересы и выполняете ли вы один большой поиск ИНС или параллельный поиск различий, должно полностью основываться на вашем сценарии использования и бизнес-требованиях. Я рекомендую выполнять поиск не только по когортам, а затем упорядочивать результаты (мы обсудим это позже в этом блоге), чтобы обеспечить наилучшее удобство для конечных пользователей. В данном случае поиск ANN находит на платформе другие публикации, которые схожи (ближе) с интересами пользователя.

Шаг 4. Сохраните результаты в базе данных кэша с упорядочиванием.

Кэшируйте базу данных, потому что одна из проблем, которую нам нужно решить, — это скорость. Мы использовали отсортированные наборы Redis для хранения уникальных идентификаторов сообщений конкретного пользователя. Мы использовали отсортированные наборы Redis, поскольку порядок публикаций в ленте пользователя имеет решающее значение. Кроме того, еще одна проблема, которую вам придется решить, заключается в том, что « система должна иметь логику , гарантирующую, что сообщения от одних и тех же авторов не группируются на одной странице». Чтобы избежать повторения контента от одного и того же автора, мы написали простой алгоритм, который гарантирует, что если сообщение определенного автора вставлено в любую позицию в ленте определенного пользователя (отсортированный набор), мы не вставим другое сообщение от того же автора. для десяти последовательных позиций (у нас размер страницы равен 10 при подаче канала конечному пользователю, поэтому мы сохранили его статическим, чтобы избежать сложности).

Чтобы определить порядок конкретной рекомендации пользователя, мы учли следующие факторы:

1. Сила связи с конкретным интересом (или другим пользователем) для этого пользователя : она определяется арифметической формулой, которая берет различные точки данных из социального графика. Все это — данные о взаимодействии, такие как временная отметка последних лайков, количество созданных лайков, последний комментарий и т. д. Поведение пользователей является показателем их интереса к чему-либо.

   
   

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

   
   

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

Как работает система

Как вы можете видеть на диаграмме выше, система намеренно сделана очень простой. Ниже показано, как работает система:

1. Когда пользователь А создает публикацию, почтовая служба после сохранения этой публикации запускает в очередь событие публикации/подписки, которое принимается фоновой службой, предназначенной для генерации кандидатов. Мы используем Google Публикация/Подписка для функции публикации/подписки.

   
   

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

   
   

3. Всякий раз, когда пользователь взаимодействует (например, комментирует, делится и т. д.) после обновления нашей основной базы данных NoSQL, пост-сервис запускает событие публикации/подписки для службы механизма рекомендаций.

   
   

4. Эта служба рекомендаций обновляет базу данных графов, а затем обновляет рекомендуемый канал пользователя практически в реальном времени, выполняя поиск ANN и обновляя базу данных Redis. Таким образом, чем больше пользователей взаимодействуют, тем лучше становится лента. Существуют проверки, гарантирующие, что рекомендации не ориентированы на определенный список ключевых слов . Эти проверки выполняются во время запроса к базе данных Graph. Эта служба также асинхронно обновляет оценку вовлеченности. Оценки вовлеченности также пересчитываются для пользователей, просматривающих публикацию.

   
   

5. Поскольку все вышеперечисленные шаги выполняются асинхронно, эти вычисления не влияют на работу конечного пользователя.

   
   

6. В конечном итоге фид доставляется конечному пользователю через службу фидов. Поскольку этот сервис просто выполняет поиск в Redis и нашей основной базе данных NoSQL ( ДианмоДБ ), его задержка P99 составляет менее 110 миллисекунд. Обе эти базы данных возвращают результаты запроса с задержкой в несколько миллисекунд независимо от масштаба.

Используемые инструменты и технологии

1. Некоторые сервисы написаны на Язык программирования Go , в то время как другие были написаны на NodeJS (с машинописным текстом).

   
   

2. Мы используем AstraDB от Datastax в качестве нашей векторной базы данных. Мы пришли к этому решению после оценки нескольких других баз данных, таких как шишка, мильвус и плетение . Помимо отличных возможностей запроса и индексирования векторных и других типов данных, он предлагает удобный для кармана бессерверный тарифный план. Он работает поверх движка Cassandra, который мы используем в качестве базы данных в ряде других функций нашей платформы, и предоставляет интерфейс запросов CQL, который очень удобен для разработчиков. Я настоятельно рекомендую попробовать его для случаев использования векторной графики.

   
   

3. Мы используем Google паблик/подписка для нашей асинхронной связи, потому что в нашем нынешнем масштабе (всего несколько тысяч пользователей, несколько тысяч активных пользователей в день) это очень рентабельно. Я запускал его в масштабе нескольких тысяч пользователей с тысячами событий в секунду. Он работает хорошо, его легко использовать и расширять.

   
   

4. Редис - Скорость, простота и мощная структура данных. Я не думаю, что мне нужно обсуждать, почему Redis в 2024 году.

   
   

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

Проблемы, которые предстоит решить в будущем

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

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

   
   

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

   
   

3. В настоящее время мы не занимаемся какой-либо тонкой настройкой наших моделей внедрения. Нам нужно будет сделать это в ближайшем будущем.

Конечная заметка

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