Контент по тегу

vLLM, LoRA и GPU-кластеры: техническая анатомия обогащения поисковой выдачи Авито мультимодальными моделями

Статьи backend machine learning
Привет всем! Меня зовут Кирилл Нетреба, я Backend-ML-инженер в Авито. В этой статье я разберу, как мы научили платформу отыскивать нужные пользователю объявления, даже если в них нет соответствующего запросу текста. Мы препарируем связку из Qwen2.5-VL, фреймворка vLLM и LoRA-адаптеров, а также заглянем в бэкенд-инфраструктуру, которая переваривает миллионы обновлений в сутки без деградации latency.
Это история о том, как в эпоху, когда традиционный полнотекстовый поиск бессилен перед лаконичностью пользователей, ему на помощь приходит машина, обученная на изображениях и языке.

Что внутри:

• Задача
• Как устроен поиск в Авито
• Решение
• Тюнинг модели A-Vision: LoRA вместо Full fine-tuning
• Итоги

Задача

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

Если человек пишет в поисковой строке Авито «кресло виды Лондона», то, несмотря на то, что в объявлении всего два слова «кресло-мешок», надо чтобы такое объявление, на картинке которого изображены виды Лондона, нашлось

Так стало необходимо увеличить число результатов поисковой выдачи по запросам пользователей, даже если в объявлениях напрямую текстом не прописано то, что они ищут.
Раньше по такому запросу это объявление не нашлось бы, потому что нужен полный кворум: все слова, которые есть в поисковом запросе, должны быть в текстовом описании объявления. Текстовое описание формируется в основном за счет заголовка и описания (title+description) и слова «Лондон» в нём не было.

Поиск по словам

Сейчас текстовое описание формируется с учетом еще одной колонки с описательным текстом, который генерируется при помощи LLM.

Поиск по словам + смысловое описание

Масштаб задачи диктует жёсткие требования к пропускной способности. При 230+ млн активных объявлений и 20 млн ежедневных событий (создание/апдейт), любая синхронная обработка привела бы к коллапсу системы.

Как устроен поиск в Авито

Упрощенно, работу поиска можно представить как взаимодействие двух сервисов (назовем их A и B), шины данных (data-bus), базы данных и поискового движка. Когда на Авито появляется новое объявление, сервис А получает из data-bus сообщение о его создании. Сервис кладёт информацию об этом в базу данных, так называемый Golden storage, и отправляет сообщение в шину данных для сервиса B. Сервис В берет сразу батч сообщение из очереди, обогащает их данными и раскладывает по шардам сфинкс — специальной базе данных, оптимизированной под быстрый поиск. Когда объявление уже лежит в сфинксах, оно может попасть в поисковую выдачу. До этого — нет.

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

Решение

Backend-история
После того как объявление создано, информация об этом попадает в data-bus — шину данных. Далее в работу включаются три наших компонента:
  1. Worker create/update: Эти воркеры читают соответствующие топики data-bus и выполняют первичную фильтрацию сообщений о создании или изменении объявлений. Если объявление или его изменение подходит по критериям, оно перекладывается во внутреннюю, изолированную от других сервисов очередь QaaS. Критерии фильтрации — наличие/изменение названия или фотографий в объявлении, принадлежность к той категории товаров, на которой раскатана фича с llm-описанием.
  2. QaaS (Queue as a Service): Чтобы изолировать GPU-инференс от колебаний нагрузки в основном поиске, мы используем изолированный слой очередей. Это позволяет гибко масштабировать количество воркеров в зависимости от размера очереди.
  3. Worker LLM: Этот воркер выполняет самую тяжёлая работу. Сервис забирает пачку объявлений, генерит к картинкам текстовые описания, записывает их в Redis с некоторым TTL и отправляет в data-bus сообщение с ID объявлений, для которых готовы llm-описания.
Сервис А, а котором говорили выше, подписан на сообщения от llm-воркера. Он читает ID, с ним идет в ручку API-сервиса, который отдает llm-описанйи для переданных айдишников. Всё.
Однако, позже мы заметили, что некоторые объявления остаются в поисковом индексе без LLM-описания. Чтобы не заниматься детальным инжинирингом, почему так происходит, для простоты и надежности мы внедрили паттерн cron+job. Раз в сутки мы запрашиваем у сфинкса объявления без llm-описаний и кладем их в QaaS. За час-полтора для всех них будут сгенерированы llm-описания.
Под капотом A-Vision: дообучение и мультимодальный стек
Для обогащения поисковой выдачи мы выбрали опенсорсную модель Qwen2.5-VL-7B-Instruct и дообучили её на дата-сетах с Авито. Так появилась наша модель A-Vision.

A-Vision (на основе qwen2.5-7B)

Бенчмарк Bert Score сравнивает эталонный исходный текст с текстом, который сгенерирован LLM-моделью, не слово в слово, а семантически.

Слова могут и различаться, но контекст и семантика будут близки. Bert Score может их сравнить.

Бенчмарк MMMU-RU проверяет LLM-модель по научным темам: математика, биология, информатика и так далее.

Бенчмарк RealWorldQA оценивает способность понимания реального мира в пространственном аспекте.

Этот параметр самый интересный, потому что в Авито мы размещаем товары из реального мира, и этот бенчмарк их понимает.

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

Когда у нас миллионы объявлений, которые надо разом прогреть для АБ-тестов, и тысячи объявлений, которые пользователи ежечасно создают или меняют, их все надо быстро обрабатывать. Языковая модель A-Vision и токенизатор сократили время генерации в два раза.

Тюнинг модели A-Vision: LoRA вместо Full fine-tuning

Для повышения качества обученную модель A-Vision надо адаптировать под разные категории товаров, например, мебель или одежда.
Адаптацию можно провести разными способами:
1. Retrain all parameters — полностью адаптировать каждую модель под отдельную категорию товаров.
Когда у модели несколько миллиардов параметров, и все их надо дотюнить, подправить, это очень долго и затратно. Мы на такое не пошли.
2. Transfer learning — это способ, когда замораживают часть слоёв нейронной сети, а другую – тюнят
Здесь тоже используется довольно большое количество весов, тоже затратно по времени. От такого способа мы тоже отказались.
3. Parameter efficient fine-tuning — это способ, когда не трогают исходную модель, замораживая все её слои, а добавляют необходимые параметры и тюнят их. К этому способу относятся Low-Rank Adaptation (LoRA).
Мы в тюнинге своей модели используем именно LoRA. Благодаря этим модулям надо добавлять всего 0,1-1% параметров, что в 100-1000 раз меньше, чем при использовании других способов.
Через LoRA-адаптеры мы добавляем уже не млрд параметров, а на порядок меньший объём. Мы выбрали этот способ, потому что он намного быстрее, и здесь мы вообще не трогаем исходную модель.
Тюнингом модели с помощью LoRA-адаптеров занимаются наши дата-сайентисты. Они доучивают модель на конкретных объявлениях из конкретной категории.
Фреймворк vLLM в помощь

Для повышения скорости и эффективности инференса LLM мы решили использовать специальный фреймворк. Фреймворк — это готовый программный каркас, который позволяет:

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

Среди всех мы выбрали инновационный опенсорсный фреймворк vLLM.

Инновации в vLLM:

1. Paged attention — механизм управления памятью для KV‑кэша в LLM: кэш делится на небольшие блоки и размещается в памяти не подряд, а через таблицу соответствия (block table). Это снижает фрагментацию, ускоряет выделение и освобождение памяти и упрощает одновременную обработку запросов с разной длиной контекста.

2. Continuous batching – это динамическое объединение входящих запросов в батчи "на лету", когда новые запросы могут присоединяться к уже выполняющемуся батчу, а завершённые — освобождать место для следующих. Это позволяет эффективно использовать GPU и минимизировать задержки, особенно при работе с последовательностями разной длины.

В отличие от статического батчинга, где батч формируется заранее и все запросы в нём обрабатываются одновременно (и только после завершения всего батча начинается следующий), continuous batching обеспечивает постоянную загрузку GPU и более высокую пропускную способность за счёт гибкого управления запросами.

3. Prefix caсhing – это механизм, при котором vLLM сохраняет вычисленный KV-кэш для уже обработанных префиксов и повторно использует его для новых запросов с тем же префиксом, чтобы не пересчитывать одинаковые части и ускорять инференс.

Continuous batching, который по сути просто непрерывный ребатчинг, был ключевым моментом, почему мы выбрали фреймворк vLLM.
Внедрение мультимодального обогащения решило проблему «пустых» описаний. Теперь, если на фото есть брендовое платье с характерным принтом, оно найдётся по запросу, даже если продавец описал его только словом «платье».

Инференс тяжёлой мультимодальной LLM в продакшене — это всегда компромисс между качеством генерируемого описания, скоростью ответа и доступными ресурсами GPU. Использование vLLM и LoRA позволило нам найти точку равновесия, где технология приносит реальный профит бизнесу, не превращаясь в чёрную дыру для бюджета на инфраструктуру.

Две наших новых главных фичи: своя обученная LLM-модель на основе A-Vision, которая хорошо генерирует текстовое описание на русском языке так, как надо для поисковых запросов, и backend-инфраструктура для её использования.

Backend-инфраструктура команды распределена по трём дата-центрам: всего доступна 21 нода, и каждая нода — это один GPU NVIDIA A100 80 GB.

Несмотря на такой запас ресурсов, в текущем продакшене нам достаточно по одной GPU-карте в каждом ДЦ: этого хватает, чтобы стабильно обрабатывать текущий поток объявлений в 1500 объявлений в минуту. В каждом объявлении прогоняем текст промпта и не менее трёх картинок (если их там много).

Состояние очередей сервиса

В итоге с помощью нашего решения пользователи Авито находят значительно большее количество объявлений по своему запросу.

Новые возможности

Сейчас сервис поиска по картинкам раскатан не на всех категориях объявлений. Где-то он даже не нужен. В Авто и Недвижимости его нет, а в мебели, личных вещах, одежде есть.

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

В конце скажу, что в Авито всегда был и остаётся важным текстовый поиск. Останется ли он в том же виде в будущем — вопрос.

Сейчас мы генерируем из картинки именно текст, потому что текущая поисковая инфраструктура в основном про текст, и в неё естественно встраивать текстовое обогащение. К тому же генерируемый текст проще быстро проверить глазами и отладить, чем работать с «чёрным ящиком» эмбеддингов.

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