Как DoorDash, Instacart и Uber Eats интегрировали LLM в поисковую выдачу тремя разными способами

За последние несколько лет три крупнейшие компании по доставке еды перестроили свои поисковые системы вокруг больших языковых моделей. DoorDash, Instacart и Uber Eats решали одну и ту же задачу: пытались понять намерение пользователя, когда он вводит запрос в строку поиска. Они также опирались примерно на одну и ту же исследовательскую базу. И всё же архитектуры, которые они внедрили, заметно отличаются друг от друга.

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

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

В конечном итоге DoorDash, Instacart и Uber Eats ответили на этот вопрос по-разному. При этом конкретная языковая модель, выбранная каждой компанией, имела второстепенное значение. Определяющим фактором стала уже существующая инфраструктура.

В этой статье мы рассмотрим разные решения этих компаний, постараемся понять причины их выбора и выявим общий закономерный подход.

Примечание: статья основана на сведениях, опубликованных в открытых источниках. Список источников приведён в конце. Сообщите в комментариях, если заметите неточности.

Проблема

Введите в приложении доставки еды запрос «что-нибудь полезное для дождливого вечера» и посмотрите на результаты. Сегодня ответ, скорее всего, окажется где-то между полезным и впечатляющим.

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

Та же проблема проявляется в нескольких распространённых сценариях поиска еды.

Например:

• Синонимы. «Газировка» и «безалкогольный напиток» могут обозначать один и тот же товар, но поисковая система по ключевым словам воспринимает их как разные элементы.
• Опечатки. Запрос Mozzarela должен находить моцареллу, но несовпадение в написании нарушает поиск.
• Сокращения. Запрос Gf pizza, означающий безглютеновую пиццу, требует, чтобы система распознала сокращение как синоним полного выражения.
• Смешение языков. Испанское слово pan означает хлеб, а английское pan — сковороду. Поэтому многоязычная строка поиска должна уметь определять значение слова по контексту.
• Неоднозначность значения. Слово Apple может обозначать и фрукт, и компанию. Написание одинаковое, но значение зависит от контекста.

Каждый такой случай — потенциальная точка, в которой намерение пользователя перестаёт совпадать со словами, используемыми в каталоге.

Под этими проблемами скрываются ещё две, более сложные.

• Длинный хвост запросов. Платформы доставки продуктов и еды получают огромное количество уникальных запросов. Любой специализированной модели, обучаемой на данных о конверсиях, сложно работать с запросами, которые появляются всего несколько раз. Редкие запросы по определению имеют мало обучающих примеров.
• Проблема ограничений. Запрос вроде «веганский сэндвич с курицей» содержит строгое ограничение. Поиск по сходству может вернуть обычный сэндвич с курицей, который нарушает это условие, поскольку значение сходства всё равно будет высоким. К этой же категории относятся диетические ограничения, аллергены и фильтры количества.

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

DoorDash

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

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

Сам процесс поиска при этом остался основанным на ключевых словах и графе знаний.

Рассмотрим запрос small no-milk vanilla ice cream. Языковая модель разбивает его на три части.

• small — характеристика количества или размера
• no-milk — диетическая характеристика, которая сопоставляется с нормализованной меткой dairy-free, то есть «без молочных продуктов»
• vanilla ice cream дополнительно разделяется на тип блюда — ice cream, то есть мороженое, — и вкус — vanilla, то есть ваниль

Затем каждая часть связывается с определённым полем графа знаний. Диетическое предпочтение становится строгим фильтром, поэтому в результаты попадают только товары без молочных продуктов. Вкус используется как мягкое предпочтение при ранжировании. Тип блюда сужает множество кандидатов.

Схема приведена ниже:

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

Генерация с дополненной выборкой (retrieval-augmented generation, RAG) используется здесь не как средство генерации, а как механизм ограничения. Для каждой части запроса поиск приближённых ближайших соседей извлекает 100 наиболее близких понятий из существующей таксономии графа. После этого языковой модели предлагается выбрать ответ только из этого списка, а не придумывать новые метки. Это интересное переосмысление стандартного подхода RAG. Обычно он добавляет контекст генератору. Здесь же он полностью определяет допустимое пространство ответов. Поэтому система может выдавать только те понятия, которые остальная архитектура уже умеет обрабатывать.

Измеренный результат — примерно 30% увеличение частоты показа каруселей с популярными блюдами. При этом архитектура рантайма остаётся преимущественно классической.

Основной вывод: большая языковая модель DoorDash работает главным образом в фоновом режиме, пакетно и на периферии основной системы выполнения.

Instacart

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

С точки зрения обычного английского языка такой ответ вполне логичен. Проблема заключается в том, что реальные пользователи Instacart, вводя запрос protein, обычно ищут протеиновые батончики и порошковые белковые смеси. Общие знания модели о мире и фактическое поведение пользователей сервиса расходились. Эта небольшая ошибка указывает на главную проблему, которую Instacart предстояло решить.

Система, которую компания заменяла, была сложной.

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

Стратегия Instacart состоит из трёх уровней.

• Формирование контекста: Генерация с дополненной выборкой добавляет в запрос специфичный для Instacart контекст до того, как языковая модель получит пользовательский запрос. В этот контекст входят категории с наибольшей конверсией, исторические данные о конверсии, сведения из каталога.

• Защитная постобработка: Фильтры семантического сходства удаляют ответы языковой модели, которые слишком сильно отклоняются от исходного запроса.
• Дополнительное обучение: Для наиболее сложных задач команда дополнительно обучает Llama 3 8B на собственных данных Instacart. Благодаря этому знания о предметной области напрямую закрепляются в весах модели.

Схема приведена ниже:

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

Популярные запросы обрабатываются фоновым конвейером с дополнением поиском и кешированием. Он допускает большую задержку и использует тщательно подготовленный контекст. Редкие запросы поступают в работающую в реальном времени fine-tuned модель Llama 3 8B. Благодаря объединению адаптеров, графическим ускорителям H100 и автоматическому масштабированию задержка остаётся ниже 300 миллисекунд.

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

После внедрения решения доля запросов, для которых система могла сформировать альтернативную формулировку, выросла с 50% до более чем 95%. Точность превысила 90% для заменителей, более широких формулировок и синонимов. Модель реального времени улучшила качество поиска для 2% самых редких запросов — холодного хвоста. Глубина прокрутки уменьшилась на 6%, а количество жалоб на плохие результаты редких запросов сократилось вдвое.

Основной вывод: языковые модели Instacart работают на уровне понимания запроса. Часть результатов вычисляется заранее и кешируется, а часть обрабатывается в реальном времени дополнительно затюненой моделью. Последующие этапы поиска и ранжирования по-прежнему выполняются традиционными системами машинного обучения и информационного поиска. Языковая модель отвечает за предварительную интерпретацию, а классическая система — за последующую выдачу результатов.

Uber Eats

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

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

Компания выбрала классическую двухбашенную (two-tower) архитектуру. Кодировщик запроса и кодировщик документа создают векторы в общем пространстве, после чего совпадения определяются по степени сходства между ними.

Главная особенность заключается в содержимом каждой башни. Обе используют дополнительно обученную языковую модель Qwen в качестве основного слоя формирования векторных представлений. Башня запросов работает в реальном времени и преобразует каждый входящий запрос в вектор. Башня документов работает в фоновом режиме и заранее преобразует миллиарды документов в векторы, которые сохраняются в индексе HNSW. HNSW — это графовая структура, предназначенная для быстрого поиска по сходству в больших объёмах данных. Такое разделение делает систему экономически возможной. Запуск тяжёлой языковой модели для каждого документа во время обработки запроса был бы слишком дорогим. Предварительное вычисление векторов и последующий поиск по ним во время запроса — вполне практичный подход.

Дополнительное обучение (fine-tuning) модели имеет не меньшее значение, чем сама архитектура.

Изначально Qwen обладает общими знаниями о мире и поддерживает разные языки. Именно это помогает решить упомянутую ранее проблему со словом pan. Дополнительное обучение на собственных данных Uber о взаимодействиях между запросами и документами формирует пространство векторов таким образом, чтобы оно отражало реальные интересы пользователей Uber Eats. Базовая модель предоставляет общее понимание смысла, а дополнительное обучение добавляет правила, характерные для Uber Eats.

Работу системы в промышленном масштабе обеспечивает набор оптимизаций.

• Обучение матрёшечных представлений: Этот подход позволяет обучить одну модель, вектор которой можно сокращать до разной длины. В производственной системе Uber используются векторы размерностью 256 вместо полной размерности 1536. При этом потери полноты поиска составляют менее 0,3%.
• Скалярное квантование: Использование семибитных целых чисел вместо 32-разрядных чисел с плавающей точкой дополнительно сокращает задержку вдвое.
• Предварительная фильтрация: Фильтры по шестиугольным географическим областям, городу и типу выполнения заказа уменьшают количество кандидатов ещё до запуска поиска приближённых ближайших соседей.

Показатели хорошо демонстрируют влияние этих решений на стоимость системы. Настройка параметра k в поиске приближённых ближайших соседей уменьшила задержку на 34%, а использование центрального процессора — на 17%, практически без влияния на полноту поиска. Квантование сократило задержку вдвое при полноте поиска выше 0,95. Обучение матрёшечных представлений уменьшило объём хранилища почти на 50%. Именно сочетание этих инженерных решений позволило дополнительно обученной языковой модели стать основой производственной поисковой системы масштаба Uber Eats.

Основной вывод: в Uber Eats языковая модель является самой моделью векторных представлений. Каждый запрос и каждый документ получают вектор, сформированный языковой моделью, а поиск на всех уровнях зависит от созданных ею представлений.

Глубина интеграции

Если расположить три компании на одной оси с названием «насколько глубоко языковая модель встроена в процесс выполнения», получится наглядная картина.

• Слева находится DoorDash. Языковая модель обогащает каталог в фоновом режиме и разбирает запросы, выдавая строго ограниченные результаты. При этом сама система выполнения остаётся преимущественно классической.
• В центре находится Instacart. Языковые модели отвечают за понимание запросов. Популярные запросы обрабатываются через фоновую генерацию с дополнением поиском, а редкие — с помощью дополнительно обученной Llama 3 8B. Последующий поиск остаётся традиционным.
• Справа находится Uber Eats. Дополнительно обученная Qwen служит основой формирования векторных представлений. Она запускается для каждого запроса, а созданные ею представления заранее встроены в каждый вектор документа.

Положение каждой компании на этой шкале в значительной степени определялось уже существующей инфраструктурой.

• У DoorDash уже был граф знаний, который эффективно использовался классической поисковой системой. Поэтому самым дешёвым способом получить улучшение стало обогащение графа и обучение запросов взаимодействию с ним.
• У Instacart существовал набор специализированных моделей понимания запросов, которые было сложно поддерживать. Поэтому наибольший выигрыш принесло их объединение в общую стратегию на основе языковых моделей.
• У Uber Eats уже работала двухбашенная инфраструктура векторных представлений для каждого направления. Поэтому естественным следующим шагом стала замена отдельных моделей на единую дополнительно обученную языковую модель, способную обслуживать все направления и языки.

Главный урок состоит в том, что перед вопросом «какую языковую модель выбрать для задачи» следует задать более важный вопрос:

В какой части существующей системы языковая модель действительно принесёт пользу?

Заключение

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

Поиск еды оказался хорошей областью для изучения этой темы, потому что он одновременно выявляет множество слабостей классического поиска по ключевым словам. В одной строке поиска встречаются субъективные запросы вроде «что-нибудь полезное для дождливого вечера», длинный хвост редких запросов, многоязычные каталоги, составные ограничения.

Каждый из трёх подходов представляет отдельную модель интеграции.

• DoorDash использует языковые модели в фоновом режиме для обогащения графа знаний, а классическая поисковая система продолжает управлять рантаймом.
• Instacart использует языковые модели на уровне понимания запросов. Дополнительно обученные небольшие модели обрабатывают редкие запросы непосредственно в критическом пути выполнения.
• Uber Eats дополнительно обучила Qwen и превратила её в основу двухбашенной системы векторного поиска. Поэтому каждый запрос и каждый документ получают векторное представление, созданное языковой моделью.

Положение каждой компании на этой шкале определяется существовавшей ранее инфраструктурой. Именно поэтому глубина интеграции важнее выбора конкретной модели.

Во всех трёх архитектурах сохраняются три универсальных компромисса.

• Гибридные системы стали стандартом. Классические поисковые механизмы, графы знаний и индексы приближённых ближайших соседей по-прежнему выполняют большую часть работы.
• Общие знания предварительно обученной модели — только отправная точка. Контекст предметной области всё равно необходимо добавить через генерацию с дополнением поиском, дополнительное обучение или оба подхода одновременно.
• Защитные ограничения являются обязательной частью любой производственной системы с языковой моделью. Ограниченные словари, фильтры сходства и контроль таксономии незаметно, но критически важным образом определяют, будут ли результаты соответствовать каталогу.

Источник