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

Рекомендательные системы стали неотъемлемой и незаменимой частью нашей жизни. Эти интеллектуальные алгоритмы играют решающую роль в формировании нашего онлайн-опыта, влияя на контент, который мы потребляем, продукты, которые мы покупаем, и услуги, которые мы изучаем. Независимо от того, транслируем ли мы контент на таких платформах, как , находим новую музыку на или делаем покупки в Интернете, системы рекомендаций незаметно работают над персонализацией и улучшением нашего взаимодействия. Netflix Spotify Уникальным элементом этих рекомендательных систем является их способность понимать и прогнозировать наши предпочтения на основе исторического поведения и моделей пользователей. Анализируя наш прошлый выбор, эти системы подбирают индивидуальные предложения, экономя нам время и усилия, одновременно знакомя нас с контентом/продуктами, которые соответствуют нашим интересам. Это повышает удовлетворенность пользователей и способствует открытиям, знакомя нас с новыми и актуальными предложениями, с которыми иначе мы бы не столкнулись. На высоком уровне разработчики понимают, что эти алгоритмы основаны на системах машинного обучения и глубокого обучения (попеременно называемых нейронными сетями), но что, если я скажу вам, что есть способ создать механизм рекомендаций, не мучаясь при развертывании нейронных сетей? сеть или модель машинного обучения? Этот вопрос особенно актуален в контексте стартапов ранней и средней стадии, поскольку у них нет тонны структурированных данных для обучения своих моделей. И, как мы уже знаем, большинство моделей машинного обучения не дадут точных прогнозов без надлежащих обучающих данных. Недавно я создал и внедрил базовую систему рекомендаций для , что привело к росту наших ключевых показателей на 40 %. На момент написания этого блога система генерирует более 30 миллионов рекомендаций в месяц. Несмотря на то, что эта система рекомендаций была создана для социальной сети, вы можете применить базовую архитектуру к любому варианту использования, например, к рекомендациям по продуктам, рекомендациям по музыке, рекомендациям по контенту на текстовых и видео-платформах или к чему-либо еще. Начну с описания постановки задачи. голосовая социальная сеть Постановка задачи с инженерной точки зрения у меня было обширное и потому что мы создавали систему рекомендаций для продукта, которым уже ежедневно пользуются тысячи пользователей. Но чтобы этот блог был кратким и по существу, я буду писать только требования высокого уровня, а затем обсуждать их решение. Если вы создаете систему рекомендаций для своего продукта (простую или на основе нейронной сети) и где-то застряли, пожалуйста, свяжитесь со мной по телефону или и я буду более чем рад ответить на ваши вопросы. документ с требованиями к продукту документ с последующими техническими требованиями Твиттер Линкедин , На высоком уровне у нас были следующие требования с инженерной точки зрения: Система должна иметь возможность улавливать интересы пользователя в виде ключевых слов. Система также должна иметь возможность классифицировать уровень интереса пользователя по конкретным ключевым словам. Система должна быть способна уловить интерес пользователя к другим пользователям. Он должен иметь возможность классифицировать уровень интереса пользователя к контенту, созданному другим пользователем. Система должна уметь генерировать качественные рекомендации, исходя из интересов пользователя. Система должна быть в состоянии гарантировать, что рекомендации, которые уже просмотрены/отклонены пользователем, не появятся снова в течение X дней. , гарантирующая, что сообщения от одних и тех же авторов не будут группироваться на одной странице. Система должна сделать все возможное, чтобы гарантировать, что если пользователь просматривает десять сообщений (размер нашей страницы), все они должны быть от разных авторов. В системе должна быть логика Система должна быть быстрой. Задержка P99 менее 150 миллисекунд. Все остальные нефункциональные требования, такие как высокая доступность, масштабируемость, безопасность, надежность, ремонтопригодность и т. д., должны быть выполнены. Опять же, это сильно упрощенный список формулировок проблем. На самом деле документы состояли из более чем 3000 слов, поскольку они также охватывали множество крайних и крайних случаев, которые могут возникнуть при интеграции этого механизма рекомендаций в наши существующие системы. Перейдем к решению. Решение - Высокоуровневая работа рекомендательного механизма. Я обсужу решения проблемы одно за другим, а затем опишу общую работу всей системы. Наша первая проблема — уловить интересы пользователя и определить уровень его интереса с помощью конкретного интереса. Для этого мы создали нечто, называемое . Проще говоря, социальный граф хранит отношения и связи между различными объектами в социальной сети. Этими объектами могут быть разные пользователи или отношения пользователей с определенными интересами. Социальные графы — мощный способ понять и структурировать отношения внутри конкретной системы. Для краткости я не буду подробно объяснять социальный граф, но порекомендую вам погуглить и узнать о нем больше. Ниже приведена упрощенная версия социального графа, который я построил для нашей системы рекомендаций. социальный граф Как вы можете видеть на изображении выше, мы храним много информации, такой как количество взаимодействий (лайков, комментариев, репостов) и давность этих взаимодействий (когда они происходили в последний раз) в качестве данных об отношениях между двумя пользователями, а также между пользователь и интерес. Мы даже сохраняем отношения между двумя разными ключевыми словами, представляющими интерес. я использовал , управляемая база данных графов от AWS, для хранения этого социального графа. Вы можете использовать любую другую графовую базу данных, например и т. д. Амазонка Нептун Neo4j, JanusGraph, ArrangoDB Эти ключевые слова, представляющие интерес, преимущественно состоят из существительных. Существует система, которая разбивает содержимое сообщения на эти ключевые слова (существительные). Он работает на сервис обработки естественного языка (NLP), который использует машинное обучение для разбиения текста на сущности, ключевые фразы и т. д. Опять же, вы можете использовать любые управляемые сервисы NLP (несколько доступных) для достижения того же. Вам не нужно изучать или развертывать модели машинного обучения! Если вы уже разбираетесь в машинном обучении, можете пойти проверить . платформе AWS Comprehend; модели НЛП с открытым исходным кодом, а также на Huggingface Вторая наша проблема — генерация качественных рекомендаций на основе интересов пользователя. Следующая диаграмма представляет собой упрощенное представление того, как работает система. Хотя вышеописанное выглядит простым, на каждом этапе происходит гораздо больше, и эти вещи необходимо тщательно продумать, а затем запрограммировать, чтобы обеспечить оптимальную работу системы. Поясню пошагово: Шаг 1. Преобразование содержимого публикации в векторные вложения Чтобы сгенерировать эти рекомендации, сначала нам нужно преобразовать содержимое сообщения во что-то, называемое - . В связи с недавним ростом брендинга LLM, OpenAI (создателей ChatGPT) и Векторные вложения становятся повседневным термином. Я не буду вдаваться в подробности, что это такое и как они работают, но настоятельно рекомендую прочитать о них больше. Но при создании подходящих кандидатов для ленты также необходимо учитывать такие вещи, как конфиденциальность и модерация контента (удаление ненормативной лексики, оскорблений, сексуального контента, преследования, фильтрация заблокированных пользователей и т. д.). Векторные вложения Векторные базы данных Для создания векторных векторных представлений вы можете использовать любую известную модель внедрения, например , или любую модель внедрения текста , в зависимости от вашего варианта использования. Мы выбрали из-за его выгодной цены, производительности и простоты эксплуатации. модель внедрения OpenAI Amazon Titan с открытым исходным кодом Amazon Titan Шаг 2. Запросите интерес пользователя А вот здесь все становится интереснее. Вы хотели бы разработать запросы на основе конкретных потребностей вашего бизнеса. Например, при запросе интересов мы придаем большее значение давности взаимодействия, чем количеству взаимодействий с определенным ключевым словом или пользователем. Мы также запускаем несколько параллельных запросов, чтобы найти различные типы интересов пользователя — ключевое слово или другого пользователя. Поскольку мы создаем несколько каналов для одного пользователя, мы также запускаем некоторые запросы, продвигающие определенную тему в соответствии с тенденцией (например, вы увидите много сообщений, связанных с Рождеством, рядом с Рождеством или сообщений, связанных с землетрясением, если землетрясение произошло). Излишне говорить, что эта тема появится в результатах запроса только в том случае, если пользователь проявил к ним некоторый интерес в своем путешествии. Итак, выберите логику, которая соответствует вашему варианту использования в бизнесе, и поведение, которое вы хотите реализовать, и запустите несколько запросов, чтобы получить достаточно большой список всех интересов пользователя. Шаг 3. Выполните поиск ANN на основе найденных интересов. Векторные базы данных преимущественно используются для выполнения определенного типа поиска, называемого (АННА). Опять же, то, как вы классифицируете различные интересы и выполняете ли вы один большой поиск ИНС или параллельный поиск различий, должно полностью основываться на вашем сценарии использования и бизнес-требованиях. Я рекомендую выполнять поиск не только по когортам, а затем упорядочивать результаты (мы обсудим это позже в этом блоге), чтобы обеспечить наилучшее удобство для конечных пользователей. В данном случае поиск ANN находит на платформе другие публикации, которые схожи (ближе) с интересами пользователя. Приблизительный поиск ближайшего соседа Шаг 4. Сохраните результаты в базе данных кэша с упорядочиванием. Кэшируйте базу данных, потому что одна из проблем, которую нам нужно решить, — это скорость. Мы использовали для хранения уникальных идентификаторов сообщений конкретного пользователя. Мы использовали отсортированные наборы Redis, поскольку порядок публикаций в ленте пользователя имеет решающее значение. Кроме того, еще одна проблема, которую вам придется решить, заключается в том, что « , гарантирующую, что сообщения от одних и тех же авторов не группируются на одной странице». Чтобы избежать повторения контента от одного и того же автора, мы написали простой алгоритм, который гарантирует, что если сообщение определенного автора вставлено в любую позицию в ленте определенного пользователя (отсортированный набор), мы не вставим другое сообщение от того же автора. для десяти последовательных позиций (у нас размер страницы равен 10 при подаче канала конечному пользователю, поэтому мы сохранили его статическим, чтобы избежать сложности). отсортированные наборы Redis система должна иметь логику Чтобы определить порядок конкретной рекомендации пользователя, мы учли следующие факторы: : она определяется арифметической формулой, которая берет различные точки данных из социального графика. Все это — данные о взаимодействии, такие как временная отметка последних лайков, количество созданных лайков, последний комментарий и т. д. Поведение пользователей является показателем их интереса к чему-либо. Сила связи с конкретным интересом (или другим пользователем) для этого пользователя Чтобы определить это, мы создали алгоритм, который учитывает различные факторы, такие как вовлеченность, соотношение вовлеченности и количества показов, количество уникальных пользователей, которые взаимодействовали и т. д., для получения оценки вовлеченности. пост на уровне платформы. Популярность публикации на платформе. В некоторых лентах мы отдаем предпочтение популярности; в других мы отдаем приоритет социальному графу. Но в основном все они представляют собой здоровую смесь этих двух факторов. Как работает система Как вы можете видеть на диаграмме выше, система намеренно сделана очень простой. Ниже показано, как работает система: Когда пользователь А создает публикацию, почтовая служба после сохранения этой публикации запускает в очередь событие публикации/подписки, которое принимается фоновой службой, предназначенной для генерации кандидатов. Мы используем для функции публикации/подписки. Google Публикация/Подписка Эта фоновая служба получает эти данные асинхронно и выполняет функции, обсуждавшиеся ранее: проверки конфиденциальности, проверки модерации и генерацию ключевых слов, а затем генерирует векторные внедрения и сохраняет их в базе данных векторов. Мы используем (обсуждается позже). AstraDB в качестве нашей векторной базы данных Всякий раз, когда пользователь взаимодействует (например, комментирует, делится и т. д.) после обновления нашей основной базы данных NoSQL, пост-сервис запускает событие публикации/подписки для службы механизма рекомендаций. Эта служба рекомендаций обновляет базу данных графов, а затем обновляет рекомендуемый канал пользователя практически в реальном времени, выполняя поиск ANN и обновляя базу данных Redis. Таким образом, чем больше пользователей взаимодействуют, тем лучше становится лента. . Эти проверки выполняются во время запроса к базе данных Graph. Эта служба также асинхронно обновляет оценку вовлеченности. Оценки вовлеченности также пересчитываются для пользователей, просматривающих публикацию. Существуют проверки, гарантирующие, что рекомендации не ориентированы на определенный список ключевых слов Поскольку все вышеперечисленные шаги выполняются асинхронно, эти вычисления не влияют на работу конечного пользователя. В конечном итоге фид доставляется конечному пользователю через службу фидов. Поскольку этот сервис просто выполняет поиск в Redis и нашей основной базе данных NoSQL ( ), его задержка P99 составляет менее 110 миллисекунд. Обе эти базы данных возвращают результаты запроса с задержкой в несколько миллисекунд независимо от масштаба. ДианмоДБ Используемые инструменты и технологии Некоторые сервисы написаны на , в то время как другие были написаны на (с машинописным текстом). Язык программирования Go NodeJS Мы используем в качестве нашей векторной базы данных. Мы пришли к этому решению после оценки нескольких других баз данных, таких как и . Помимо отличных возможностей запроса и индексирования векторных и других типов данных, он предлагает удобный для кармана бессерверный тарифный план. Он работает поверх движка Cassandra, который мы используем в качестве базы данных в ряде других функций нашей платформы, и предоставляет интерфейс запросов CQL, который очень удобен для разработчиков. Я настоятельно рекомендую попробовать его для случаев использования векторной графики. AstraDB от Datastax шишка, мильвус плетение Мы используем для нашей асинхронной связи, потому что в нашем нынешнем масштабе (всего несколько тысяч пользователей, несколько тысяч активных пользователей в день) это очень рентабельно. Я запускал его в масштабе нескольких тысяч пользователей с тысячами событий в секунду. Он работает хорошо, его легко использовать и расширять. Google паблик/подписка - Скорость, простота и мощная структура данных. Я не думаю, что мне нужно обсуждать, почему Redis в 2024 году. Редис - Опять же, он хорошо масштабируем и прост в использовании, и мы запускаем его в бессерверном режиме, где, несмотря на сотни тысяч запросов в минуту, наш общий счет довольно низок. Он также предлагает очень мощные возможности индексации и задержку в несколько миллисекунд при чтении и записи. ДинамоДБ Проблемы, которые предстоит решить в будущем Как вы можете себе представить, эту же настройку можно настроить для создания базового механизма рекомендаций для любого варианта использования. Но поскольку у нас социальная сеть, нам потребуются некоторые изменения, чтобы сделать эту систему более эффективной. Алгоритмы машинного обучения/глубокого обучения потребуются на уровне социального графа, чтобы предсказать ключевые слова и пользователей, наиболее релевантные для пользователя. В настоящее время набор данных слишком мал, чтобы что-либо точно предсказать, поскольку это совершенно новый продукт. Однако по мере роста данных нам придется заменить текущие простые запросы и формулы результатами алгоритмов машинного обучения. Отношения между различными ключевыми словами и пользователями необходимо настроить и сделать более детализированными. Они сейчас находятся на очень высоком уровне. Но они должны быть глубже. Нам нужно будет изучить отношения второй и третьей степени на нашем графике, чтобы сначала уточнить рекомендации. В настоящее время мы не занимаемся какой-либо тонкой настройкой наших моделей внедрения. Нам нужно будет сделать это в ближайшем будущем. Конечная заметка Я надеюсь, что вы нашли этот блог полезным. Если у вас есть какие-либо вопросы, сомнения или предложения, пожалуйста, свяжитесь со мной по телефону , или . Поделитесь этой статьей со своими друзьями и коллегами. Твиттер Линкедин Инстаграм Также опубликовано . здесь