Повышение точности рекомендательных систем с помощью LLM-модулей на Python.

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

Делиться

Одна из моих любимых поговорок в американской культуре звучит так:

«Нельзя и рыбку съесть, и на стуле посидеть».

Я нахожу эту фразу чрезвычайно поэтичной, но в то же время очень практичной и полезной. Смысл этого высказывания прост: всё, чего вы достигаете, достигается ценой компромисса, поскольку у всего есть своя цена.

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

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

Рассмотрите компромисс между вычислительными ресурсами и объемом памяти в следующих случаях:

Предварительно вычислить расстояние между двумя городами и сохранить его в наборе данных вполне логично, а вот вычислять его во время полета — нет. Это связано с тем, что предполагается, что набор данных не потребует частого обслуживания (города не перемещаются постоянно), и было бы глупо вычислять расстояние между Нью-Йорком и Сан-Франциско каждую долю секунды. [Случай А]

Однако было бы столь же глупо (и, вероятно, невозможно) для чат-бота запоминать все возможные вопросы, которые может задать человек, и получать ответ на каждый заданный вопрос. Это связано с тем, что характер проблемы гораздо более динамичен и требует вычислений «на лету». [Вариант B]

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

Можно ли обойтись без вычислительного времени и без памяти? Вряд ли, потому что нельзя и рыбку съесть, и на стуле посидеть 🙂

Но давайте рассмотрим менее очевидный и более «модный» пример. Поговорим о больших языковых моделях (LLM).

LLM — это самые мощные модели ИИ, которыми мы располагаем, и они обучены на всех доступных в мире знаниях. Они также огромны . На самом деле, они настолько велики, что мы редко используем их внутри компании и обычно вызываем через API. Однако вызов API = токены = стоимость.

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

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

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

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

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

Давайте начнём!

1. Проектирование системы

Обсуждаемая нами формулировка, касающаяся торта, в инженерной практике также известна как треугольник «Точность-Масштаб-Время»:

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

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

Другими словами, дизайн выглядит так:

1. Быстрый и простой поиск позволит найти K ближайших ресторанов (на основе правил, высокая полнота, низкая точность).
2. Медленная, но очень интеллектуальная модель обработки больших языковых данных поможет нам выбрать из K лучших вариантов, исходя из запроса. (На основе ИИ, высокая точность)

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

Хватит болтать. Давайте начнём программировать!

2. Сценарий

2.1 Настройка

Я проделала за вас всю грязную работу за кулисами 🙂

Весь код написан в объектно-ориентированном стиле (ООП), с использованием скриптов и конвейера, который позаботится обо всем процессе. Папка на GitHub находится здесь, а для генерации остального кода вы можете клонировать её и использовать этот блок импорта:

2.2 Генерация данных

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

Это задача класса RestaurantDataGenerator из файла datagenerator.py . Он создает воспроизводимую таблицу, содержащую примерно 10 000 ресторанов, расположенных в восьми городах (Нью-Йорк, Сан-Франциско, Чикаго, Остин, Сиэтл, Бостон, Майами и Денвер). Каждый ресторан получает:

– случайно подобранное имя

– город и координаты широты/долготы, выбранные в районе центра этого города (в пределах ~13 км),

– стиль кухни (итальянская, японская, мексиканская, тайская, французская и т. д.),

– диетический профиль (всеядный/вегетарианец/веган)

– средний балл

– количество голосов

– ценовой диапазон (10 / 100 / 1000, средний размер билета на человека).

Этот генератор предназначен для однократного запуска. Генерация данных очень проста:

Этот единственный вызов записывает таблицу в data/restaurants.csv , которая выглядит следующим образом:

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

2.3. Отбор кандидатов

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

На этом этапе намеренно используется высокая полнота и низкая точность . Благодаря такому подходу мы можем обработать всю таблицу (10 000 ресторанов) без единого вызова API и затрат на токены. Конечно, мы не делаем ничего особенно умного или замысловатого, но мы фактически фильтруем все данные, которые не являются подходящими для пользователя. Уже одно это имеет большое значение.

Например, давайте попробуем отправить реальный запрос к поисковой системе:

«Недорогие веганские тако с оживленной атмосферой» в нескольких городах

Вот результат:

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

Давайте начнём подготовку к программе LLM!

2.4 Отбор кандидатов

Это этап 2 , медленный, интеллектуальный, высокоточный заключительный этап воронки, управляемый LLM. Он строится непосредственно на основе списка из 50 ресторанов, полученного на этапе 2.3. LLM никогда не видит всю таблицу из 10 000 строк; он видит только небольшой, уже релевантный фрагмент, который ему предоставил фильтр расстояния.

Мы взаимодействуем с моделью через небольшой клиент OpenAI. Ключ считывается из OPENAI_API_KEY (сохраненного в окружении). Рекомендательная система, определенная как RestaurantRecommender , работает с запросом и городом через RestaurantRecommender.recommender(query,city) :

Стоит отметить несколько моментов:

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

• Структурированный вывод с использованием Pydantic. Мы никогда не обрабатываем текст в свободной форме. Модель вынуждена отвечать в формате модели Pydantic (через структурированные выходные данные OpenAI), поэтому гарантируется соответствие каждого ответа схеме.

Выходная схема содержит restaurant_id и name (из списка кандидатов), fit_score (значение от 0 до 100) и краткое reason . Ответ также сопровождается понятным summary . Например, при выполнении запроса для трех городов мы получаем:

Как видите, это намного лучше, чем исходные списки ресторанов, составленные на основе расстояния, из версии 2.3. Там ближайший ресторан в каждом городе выбирался практически случайным образом (корейский, ливанский, мексиканский, но вегетарианский). Здесь же модель переупорядочила те же 50 кандидатов в соответствии с нашими фактическими запросами: веганские и мексиканские заведения занимают верхние позиции с высокими fit_scores , и модель честно отмечает несоответствия, отмечая частичные совпадения и объясняя причину в reason . Именно такую точность обеспечивает нам LLM, применяемая к списку ресторанов, достаточно небольшому, чтобы оставаться экономически выгодной в больших масштабах.

3. Результаты

Давайте отступим назад и посмотрим, что в итоге принесла нам двухэтапная воронка продаж, используя один и тот же запрос в трех городах: «недорогие веганские тако в оживленной атмосфере».

• На первом этапе мы получаем список кандидатов. Отбор кандидатов по расстоянию из раздела 2.3 по своей сути отличался высокой полнотой и низкой точностью.
• На втором этапе определяются реальные рекомендации. Передача 50 кандидатов с первого этапа в программу LLM позволяет упорядочить их в соответствии с фактическими требованиями.

Вот окончательные результаты, полученные моделью для каждого города:

• Нью-Йорк: Golden Spoon (веганская кухня, 4,9) и Maison Fork (мексиканская кухня, бюджетный вариант) занимают лидирующие позиции с оценками по посадке 90 и 85 соответственно.
• Майами : Royal Tavern & Co. (веганская, мексиканская, недорогая кухня) лидирует с 85 очками.
• Бостон : Urban Spoon и Little House, оба бюджетных мексиканских ресторана, занимают первые два места с рейтингами 90 и 85.

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

4. Выводы

Спасибо, что уделили мне время, это очень много значит. ❤️ Вот что мы сделали вместе:

– Разработана двухэтапная воронка рекомендаций, которая является одновременно масштабируемой и интеллектуальной.

– Использовали недорогой фильтр по расстоянию на основе правил (этап 1), чтобы сократить число ресторанов с 10 000 до ближайших 50.

– Использовали систему переранжирования кандидатов на программу LLM (этап 2), чтобы отобрать из 50 лучших 5-10, честно указав оценку и обоснование для каждого.

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

7. Перед тем, как отправиться в путь!

Ещё раз спасибо за ваше время. Это очень много значит. Меня зовут Пьеро Пайалунга, а вот этот парень:

Я родом из Италии, имею докторскую степень Университета Цинциннати и работаю специалистом по анализу данных в компании The Trade Desk в Нью-Йорке. Я пишу об искусственном интеллекте, машинном обучении и меняющейся роли специалистов по анализу данных как здесь, на TDS, так и в LinkedIn. Если вам понравилась статья и вы хотите узнать больше о машинном обучении и следить за моими исследованиями, вы можете:

А. Подписывайтесь на меня в LinkedIn , где я публикую все свои истории.
Б. Подпишитесь на меня в GitHub , где вы сможете увидеть весь мой код.
C. По всем вопросам вы можете отправить мне электронное письмо по адресу piero.paialunga@hotmail.

Пьеро Пайалунга Посмотреть все работы Пьеро Пайалунга

Источник: towardsdatascience.com