Я возглавлял Dynamic Product Ads в Twitter, где мы сопоставили миллионы пользователей со сотнями миллионов продуктов электронной коммерции в режиме реального времени. Выход был лучшими 5-6 продуктами, которые каждый пользователь с наибольшей вероятностью купит. Система использовала продукты и пользовательские встраивания с классическими моделями ML, чтобы обслуживать персонализированные объявления в масштабе Twitter. Это было несколько лет назад.Но теперь все говорят о ИИ и больших языковых моделях, как будто они будут революционизировать все.Итак, я думал, если бы я сегодня построил динамические рекламные объявления о продуктах, я бы использовал LLM?И, что еще важнее, что бы не изменилось вообще, и почему? Ответ: Я бы использовал LLM для около 20% системы, специально для создания встраиваний, и оставить все остальное таким же. Наш оригинальный подход Проблема под рукой: рекомендовать продукты пользователю, на который они, скорее всего, нажмут и куплют, в то время как они быстро прокручивают свою временную линию. Были миллионы продуктов для выбора и рекламодателей. Кроме того, были миллионы пользователей, прокручивающих в одно и то же время. Системе пришлось делать прогнозы для миллионов пользователей в пределах подмиллисекундной задержки. Трубопроводу Ad Serving пришлось бы завершить прогноз менее чем за 50 миллисекунд, максимум. Встроенные продукты Мы использовали метаданные каждого продукта, такие как название, описание, категория, цена и т. д., и кодировали их в 128-мерном плотном векторном пространстве. Пользователь Embeddings Пользователи были представлены векторами на основе сигналов, таких как их участие в платформе, информация о профиле и прошлые покупки. Модель сочетания Во время вывода мы использовали бы двухэтапный подход. Во-первых, мы бы запустили быстрый приблизительный поиск ближайших соседей, чтобы получить продукты-кандидаты, чьи встраивания были близки к пользовательским встраиваниям. Затем, мы бы использовали дерево решения с повышением градиента, чтобы оценить этих кандидатов, включая дополнительные функции, такие как недавние, ценовые сигналы и контекст, как время суток. Модель и ANN (приблизительный ближайший сосед) были объяснимыми, дебютируемыми и, самое главное, достаточно быстрыми для масштаба Twitter. Как бы я подходил к этому сегодня? Если бы я сегодня строил эту систему, вот что я бы на самом деле изменил. Лучшие встраивания продуктов с LLM Encoders Современные модели больших языков замечательно хорошо понимают семантический смысл и контекст. Вместо того, чтобы собрать описания продуктов (большинство из которых были довольно плохими для начала), я бы использовал кодер на основе LLM для создания встраиваний продуктов. Это важно, потому что продукт под названием «беговая обувь» будет семантически близок к «беговым снегоуборщикам», даже если они не разделяют точные слова. Управляйте этим без усилий. all-MiniLM-L6-v2 Мы когда-то имели вход в каталог продуктов Nike под названием «Air Max 270 React», что наши вставки 2022 года не могли соответствовать пользователям, ищущим «полотенцевые беговые ботинки» или «атлетические кроссовки», потому что не было перекрытия ключевых слов. Улучшенные методы холодного старта LLM также сделает обработку холодного старта немного лучше. Когда новый продукт появляется в каталоге, LLM может извлекать богатые сигналы из описаний продуктов, обзоров и изображений, чтобы генерировать разумное первоначальное встраивание. Аналогичным образом, для новых пользователей с редкой историей участия, современные кодекторы могут лучше понять информацию о своем профиле и первоначальные твиты (если они есть), чтобы создать значимые представления. Итак, где LLM вписываются в реальную архитектуру? Гибридный подход Я бы все еще использовал классический ML для фактического хранения и обслуживания слоев. Архитектура выглядела бы так: 
 
 
 
 
 
 
 
 
 Feature 
 LLM or Classic 
 
 
 
 LLM-based encoder to generate user and product embeddings 
 LLM 
 
 
 
 Match embeddings to generate candidate products per user 
 Classic 
 
 
 
 Final scoring and ranking 
 Classic LLM-кодер для создания встраиваний пользователей и продуктов LLM Соответствующие встраивания для создания кандидатурных продуктов на каждого пользователя Классика Окончательный рейтинг и рейтинг Классика Почему я бы использовал классические модели для оценки?Причинами являются задержка, стоимость и объяснимость. LLM не могут предсказать продукты для миллионов пользователей менее чем за 10 миллисекунд. Они являются оверкилом для объединения численных функций и принятия решения о ранжировании. Классические модели делали бы это в микросекундах. В масштабе Twitter разница между 1 мс и 10 мс времени вывода переводится в миллионы долларов в инфраструктурных затратах и измеримых падениях в участии пользователей. Запуск LLM вывод для каждого запроса прогноза будет стоить 50-100 раз больше, чем наш классический подход. А как насчет создания Ad Copy? Существует много шуток в Интернете о том, как использовать LLM для создания персонализированной копии рекламы в полете или рассуждать о намерениях пользователей в реальном времени. Создание рекламной копии с помощью LLM вводит неприемлемые риски, такие как галлюцинации о характеристиках продуктов, несовместимое брендирование и трудно пересматриваемый контент в этом масштабе. Системе нужно было бы показывать миллионы рекламных вариаций в день, и не было бы способа пересмотреть их за точность и безопасность бренда. Один галлюцинированный претензии о продукте, как "неводоустойчивый", когда он не является, или "с одобрением FDA", когда он не является, создаст юридическую ответственность. Что не меняется? Независимо от того, использует ли система встраивания с 2022 года или LLM с 2026 года, фундаментальная задача остается прежней: вывод о том, что кто-то хочет от шумных сигналов. Кто-то, кто твитттёт о бегущей обуви, может быть марафонским бегуном для своей следующей пары, или случайным наблюдателем, который только что смотрел гонку по телевизору. Эта проблема нуждается в хороших данных для решения, продуманной технике и многом эксперименте. Understanding user intent в масштабе, каждая миллисекунда имеет значение. Пользователи откажутся от опыта, который чувствует себя медленным. Системы рекламы не могут замедлить загрузку временной линии. Я видел, что несколько систем инфраструктуры ML разрушаются в A / B тестах, потому что они добавили 100 мс задержки к хорошо оливковой системе. Модель может быть лучше, но требование задержки уступает всем. Latency requirements Проблемы, такие как холодное начало для новых продуктов или пользователей, и проблемы с качеством данных, когда в каталогах отсутствуют или неправильные описания продуктов, все еще существуют. Last-mile problems Команда, которая может выполнять 10 экспериментов в неделю с более простой моделью, будет постоянно превосходить команду, выполняющую 1 эксперимент в неделю с очень сложной моделью. Способность быстро тестировать, измерять результаты и повторять является более ценной, чем маргинальные улучшения в качестве модели. Когда мы запустили Динамические рекламные объявления, мы проводили 3-4 эксперимента в неделю. Мы тестировали различные размеры встраивания, различные алгоритмы ANN и различные особенности в модели оценки. Большинство экспериментов потерпели неудачу. Но те, которые работали, сложились. Эта скорость имела большее значение, чем выбор «идеальной» архитектуры модели. Iteration speed Настоящий вопрос: где находится бутылка? Честно говоря, большая часть дискуссии «как вы бы построили его сегодня с современным ИИ» не имеет смысла.Вопрос не должен быть тем, что возможно с новой технологией. Для нас проблема никогда не была связана с качеством встраиваний.Это было о понимании намерений пользователей, решении проблем с качеством данных в каталогах продуктов и управлении проблемами холодного старта, а также создании систем, которые могли бы справиться с масштабом.Современный ИИ действительно помогает с некоторыми из них, и есть реальная ценность в использовании ИИ. Если бы я построил эту систему сегодня, я бы потратил 20% своих усилий на «использование LLM для создания лучших встраиваний» и 80% на те же проблемы масштаба, качества данных, экспериментов и понимания намерений пользователей. Непопулярное мнение Технологическая индустрия любит революционные повествования. Несколько лет назад вокруг блокчейна и Web3 происходил аналогичный шум. Но правда в том, что большинство производственных систем ML работают, масштабируются и зарабатывают деньги. Революционный подход к использованию LLM привел бы к улучшению на 5%, но был бы в 10 раз медленнее и в 100 раз дороже. Современный ИИ по-настоящему ценен, когда применяется с умом к барьерам в бутылках, а не как замена для всей системы, которая уже работает.

This story contains new, firsthand information uncovered by the writer.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

Read My Stories

Этот звук создан на языке оригинала истории!

Буду ли я использовать LLMs для восстановления динамических рекламных продуктов Twitter? да и нет!

About Author

КОММЕНТАРИИ

БИРКИ

ЭТА СТАТЬЯ БЫЛА ПРЕДСТАВЛЕНА В

Related Stories

Плавание по водам: разработка RAG-приложений промышленного уровня с использованием озер данных

Хотите выиграть конкурс HackerNoon? Вот что рекомендуют победители конкурса #crypto-api

Цифровые кочевники слушают: что нужно знать о новой визе DTV в Таиланде

Раскрытие силы ИИ. Систематический обзор передовых методов: Краткое содержание и введение

Плавание по водам: разработка RAG-приложений промышленного уровня с использованием озер данных

Хотите выиграть конкурс HackerNoon? Вот что рекомендуют победители конкурса #crypto-api

Цифровые кочевники слушают: что нужно знать о новой визе DTV в Таиланде

Раскрытие силы ИИ. Систематический обзор передовых методов: Краткое содержание и введение

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps