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

Сейчас индустрия переходит к семантическому профилированию. Большие языковые модели (LLM) позволяют архитектуре понимать контент на уровне смыслов, извлекая данные из текстовых описаний, отзывов и характеристик. Если раньше для рекомендаций нужен был массив данных о покупках, то теперь логика меняется.

Допустим, клиент выбирает большую 4-местную кемпинговую палатку (Фактор А) и одновременно добавляет в корзину два детских спальных мешка (Фактор Б). LLM не просто ищет товары с тегом «кемпинг» . Она сопоставляет эти данные со своими знаниями о мире и делает логический вывод (Вывод В): планируется семейный выезд на природу с маленькими детьми. На основе этого синтеза система рекомендует не банальный фонарик, а мощный фумигатор повышенной безопасности для закрытых тентов или портативный подогреватель детского питания, работающий от прикуривателя.

Где потолок?

За последние десять лет двухступенчатый конвейер retrieval-ranking стал стандартом индустрии рекомендаций: сначала быстрый алгоритм генерирует сотни кандидатов из каталога, а затем тяжелая модель ранжирует этот шорт-лист, предсказывая вероятность клика. Этот подход работает отлично, но имеет пределы. Команды разработки постоянно сталкиваются с тремя фундаментальными проблемами:

1. Холодный старт. Стандартные подходы полностью зависят от активности аудитории. При загрузке в онлайн-кинотеатр нового фильма алгоритмы чистой коллаборативной фильтрации сталкиваются с проблемой «нулевого вектора» (отсутствием строки или столбца взаимодействий в матрице). Система не может рассчитать близость нового объекта к интересам пользователей, из-за чего новинки могут неделями оставаться мертвым грузом на дне каталога.
2. Проблема «усредненного товара». В классических системах и покупатель, и товар — это лишь векторы в пространстве. Когда пользователь вводит сложный запрос (например, «мощный игровой ноутбук, который не перегревается и выглядит строго для офиса»), классический алгоритм пытается найти точку где-то посередине между мощностью и дизайном. В итоге вектор запроса смещается в зону универсальных домашних ноутбуков, которые не тянут игры и выглядят дешево. В этом случае система усредняет координаты, теряя специфические требования. LLM же не усредняет, а рассуждает: она видит каждое условие как отдельный логический фильтр и ищет товар, который удовлетворяет всем критериям одновременно.
3. Гибкость без переписывания кода. В традиционной архитектуре признаки товара жестко заданы инженерами (цена, бренд, категория). Если бизнес хочет внедрить новый критерий, например «экологичность материалов», начинается долгий процесс: нужно нанять людей для разметки тысяч товаров, изменить структуру базы данных и переобучить модель. Это занимает месяцы. В LLM-архитектуре этот признак уже существует бесплатно. Модель может извлечь информацию об экологичности напрямую из описаний или отзывов в момент запроса. Не нужно менять код или переучивать систему, достаточно просто попросить модель учитывать этот параметр.

Уровни интеграции LLM: архитектура LLMERS

Интеграция LLM в рекомендательные системы требует разделения контуров вычислений. Важно разделять архитектуры: если классические трансформеры в RecSys (например, модели класса BERT4Rec) оптимизированы под обработку последовательностей action_id и ID товаров, то большие генеративные языковые модели работают с сырым текстом и смыслами. Если заставить тяжелую авторегрессионную LLM обрабатывать каждый клик пользователя в реальном времени, серверная инфраструктура рухнет из-за огромных задержек ответа (latency).

Ключевые паттерны интеграции (на примере e-commerce):

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

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

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

• Дистилляция знаний. Тяжелая модель (учитель) размечает тысячи сложных сценариев выбора в офлайне, логически аргументируя связи. На этих идеальных данных тренируют легковесную нейросеть (ученика). В онлайне работает только быстрый ученик, отдавая ответы за миллисекунды, но сохраняя смысловую точность большой системы.

• Zero-shot ранжирование. На самом последнем этапе шорт-лист из 20 релевантных кандидатов передается в промпт для LLM, которая пересортирует их с учетом последних действий пользователя. Это дает высочайшую точность смыслов, но применяется точечно из-за высоких задержек.

Защита от галлюцинаций: мощь паттернов RAG

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

Для жесткого контроля трансформеров инженеры применяют пайплайны Retrieval-Augmented Generation (RAG). Механизм работает в три этапа:

1. Семантический поиск. База данных (векторное хранилище) отбирает топ реальных продуктов из каталога на основе текущего запроса клиента.
2. Формирование контекста. Система автоматически собирает системный промпт, оборачивая в него строгие факты (точные артикулы, цены, характеристики) о найденных товарах.
3. Аналитическая генерация. LLM выдает финальный результат или текстовую консультацию строго в рамках переданного узкого списка товаров, теряя возможность выдумать что-то новое.

Дальнейшее развитие безопасности — Graph RAG, где агент сверяет персональную историю с глобальным математическим графом знаний. Это дает нейросети четкую картину связей каталога, исключая любые слепые догадки.

Шаг к агентным системам будущего

Мы наблюдаем важнейший эволюционный переход: статические алгоритмы уступают место агентным рекомендательным системам (Agentic Workflows). Классическая модель просто получает данные и отдает результат. Агент же способен вести диалог, логически рассуждать и вызывать сторонние инструменты по API.

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

LLM-агент работает иначе: он превращает строку поиска во вдумчивого аналитика. Используя метод пошагового рассуждения (Chain-of-Thought), нейросеть перед выдачей результата формирует скрытый внутренний логический монолог:

• Анализ аудитории. В запросе указаны дети. Значит, в приоритете повышенная защита от насекомых, плотное дно и хорошая вентиляция.

• Анализ формата. Задача — поход на выходные. Это классический кемпинг, куда, скорее всего, поедут на машине. Следовательно, вес палатки не критичен и можно пожертвовать легкостью ради большого тамбура и высокого потолка.

• Анализ локации. В Карелии высокая влажность и вероятность дождей. Требуется двухслойная конструкция с высоким показателем водонепроницаемости тента (от 4000 мм в.ст.).

• Формирование фильтров. Ищем: кемпинговая палатка, 3-4 места, двухслойная, водостойкая, с москитными сетками.

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

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

Персонализация и миф одного запроса

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

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

Новые метрики: почему точности мало

Традиционно качество измеряли метриками конверсии (CTR, Conversion Rate) и угадывания конкретного клика (Hit Rate). Но семантический подход требует перехода к концепции Beyond Accuracy. Оптимизация только под вероятность клика приводит к информационному пузырю и система может назойливо предлагать детективы целый месяц после одной покупки.

Новые классы метрик эффективно лечат эту болезнь:

• Контролируемая серендипность. Оценивает внезапные приятные сюрпризы. Если любителю детективов предложить аудиокнигу про историю джаза (похожую по нуарной атмосфере), он будет искренне доволен. Классика не смогла бы проложить такой маршрут.
• Внутрисписочное сходство (разнообразие). Оценивает способность собрать подборку из фильмов абсолютно разных жанров, каждый из которых при этом точно попадает во вкус зрителя.
• Объяснимость рекомендаций. Способность нейросети генерировать короткие тексты-подсказки (например, «Я советую вам этот курс, так как вы недавно искали статьи по Python»). Это повышает прозрачность и снижает барьер недоверия.
• Калибровка. Жесткая проверка честности системы. Выдача обязана соответствовать реальным долговременным интересам пользователя, не скатываясь в дешевый кликбейт.
• Покрытие каталога. Показывает глубину поиска. Семантический векторный движок обязан эффективно поднимать хорошие товары из самого длинного «хвоста» базы.

Инженерные барьеры и безопасность данных

Внедрение умных технологий всегда несет риски. Команды разработки регулярно решают сложнейшие инфраструктурные ребусы:

1. Время задержки сервера (Latency). Пользователь ждет результат миллисекунды, а гигантские трансформеры думают секундами. Инженерам приходится агрессивно кешировать результаты, батчить запросы и выносить максимум расчетов в офлайн-процессы.
2. Приватность и дообучение. Логи пользователей нельзя отправлять во внешнее облако. Приходится разворачивать локальные открытые модели внутри закрытого контура компании. Для экономии ресурсов видеокарт применяют методы адаптеров (PEFT): базовые веса замораживаются, и тренируются только крошечные слои, что позволяет быстро адаптировать нейросеть под специфику магазина.
3. Проблема выравнивания (Alignment). Базово LLM учится просто предсказывать следующее слово. Но продуктовой команде нужно растить бизнес-метрики (например, время удержания в приложении). С помощью обучения с подкреплением (RLHF) поведение модели подстраивают под реальные бизнес-цели компании.

Если на практике: мультимодальная языковая модель

Пример такого технического внедрения — мультимодальная языковая модель (MMLM) команды AI VK. Она сравнивает контент по смыслу и тематике, объясняет комментарии, описывает интересы пользователя к конкретным сценам и учитывает эмоциональный тон материалов. Нейросеть обучена более чем на трех миллионах русскоязычных материалов и может анализировать видео, изображения, тексты и аудио. С ней рекомендательные алгоритмы быстрее показывают новый контент в продуктах VK без необходимости получения первых пользовательских реакций.

Чек-лист: когда стоит внедрять технологию

Решение о трансформации должно иметь четкий финансовый расчет. Оцените ваш продукт перед внедрением LLM.

Дайте зеленый свет экспериментам, если:

• Ваш продукт содержит огромное количество сложного текста или медиа (маркетплейсы, образовательные площадки).
• У вас постоянный огромный поток новых товаров (семантика блестяще решит проблему холодного старта).
• Продукт находится в нише сложного выбора (покупка электроники, бронирование туров).
• Есть острая потребность объяснять логику рекомендаций пользователю живым языком.

Включите красный свет, если:

• Сценарии потребления просты и рутинны (заказ бумажных полотенец, покупка кабеля по известному артикулу).
• Намерение пользователя прозрачно и не требует глубокого анализа.
• У вас жесткие аппаратные ограничения на обработку онлайн-запросов (вы просто сожжете бюджет на аренду GPU без выгоды для бизнеса).

В соцсети появилась новая функция Your Algorithm, которая позволяет напрямую указать, какой контент вы хотите видеть чаще, а какой — реже.

Полного ручного управления лентой пока нет. Но это все еще самый заметный шаг *Instagram в сторону пользовательского контроля за рекомендациями.

Функцию тестировали несколько месяцев. О ее появлении еще осенью прошлого года говорил глава *Instagram Адам Моссери. Теперь настройка начала распространяться на пользователей в разных странах.

С чего все начинается: Reels

На первом этапе Your Algorithm работает только с Reels. Именно короткие видео стали основной точкой входа для алгоритмических рекомендаций, поэтому *Instagram и начал с них.

Чтобы открыть настройки, нужно:

• открыть любое видео в Reels;
• нажать на новую кнопку с иконкой линий и сердечек;
• перейти в раздел Your Algorithm.

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

Можно добавить свои темы

Если предложенных вариантов недостаточно, темы можно ввести вручную через кнопку Add. Это полезно, если вы хотите сместить ленту в сторону конкретных интересов. Например, меньше лайфстайла и больше профессионального контента.

Выбранные темы отображаются прямо в интерфейсе Reels — внизу экрана, над именем пользователя. Это скорее индикатор для вас, чем кнопка управления, но он показывает, что настройки действительно применяются.

Что будет дальше

*Meta заявляет, что выбранные темы со временем начнут влиять не только на Reels, но и на основную ленту и вкладку Explore. Сейчас эффект ограничен, но логика алгоритма постепенно станет единой для всего *Instagram.

Функция пока доступна лишь на английском языке, но географически распространяется широко — почти во всех регионах, где работает *Instagram.

*Компания Meta и ее продукты признаны экстремистскими, их деятельность запрещена на территории РФ

Зачем вообще делать что-то своё?

Я знаю, что вы можете подумать: «Почему бы просто не использовать Elasticsearch?» или «А что насчёт Algolia?» Это вполне рабочие решения, но у них есть нюансы. Нужно разбираться с их API, поддерживать инфраструктуру под них и учитывать все тонкости их работы.

Но иногда хочется чего-то более простого — такого, что:

• работает прямо с вашей текущей базой данных;
• не требует сторонних сервисов;
• легко понять и отладить;
• действительно выдаёт релевантные результаты.

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

Основная идея

Концепция проста: разбить текст на токены, сохранить их, а затем при поиске сопоставлять токены запроса с токенами в индексе.

Процесс выглядит так:

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

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

Строительный блок 1: схема базы данных

Для начала нам нужны всего две таблицы: index_tokens и index_entries.

index_tokens

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

Важно: один и тот же токен может встречаться несколько раз с разными весами — по одному для каждого токенизатора.

Почему так?

Потому что разные токенизаторы создают один и тот же токен, но с разным весом.

Например, токен parser:

• WordTokenizer → вес 20
• PrefixTokenizer → вес 5

Чтобы итоговый механизм оценки релевантности работал правильно, нужны отдельные записи.

Ограничение уникальности в этой таблице — (name, weight).

То есть имя токена может повторяться, но вес — нет.

index_entries

Эта таблица связывает:

• токен
• документ
• конкретное поле документа

…и хранит итоговый вес, который нужен для процедуры ранжирования.

Структура таблицы index_entries

Что такое weight?

Это итоговый вычисленный вес токена для конкретного поля конкретного документа.

Формула:

Он уже включает всё, что понадобится позже при начислении очков.

Какие индексы добавляем?

Чтобы поиск работал быстро:

• (document_type, document_id) — для быстрого получения документов
• token_id — чтобы быстро находить все документы по токену
• (document_type, field_id) — для поиска по конкретному полю
• weight — для фильтрации по весам

Почему именно такая схема?

Потому что она:

• простая
• эффективно ложится на реляционные БД
• использует сильные стороны SQL
• позволяет масштабировать алгоритм без усложнений

Блок 2: токенизация

Что такое токенизация?

Это процесс разбивки текста на более мелкие части — токены, удобные для поиска.

Например, слово «parser» можно разбить разными способами:

• Как одно целое: ["parser"]
• На префиксы: ["par", "pars", "parse", "parser"]
• На n-граммы (последовательности символов): ["par", "ars", "rse", "ser"]

Зачем несколько токенизаторов?

Разные задачи требуют разных подходов к поиску:

• Один токенизатор для точных совпадений
• Другой — для частичных совпадений
• Третий — для учёта опечаток

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

Общий интерфейс токенизатора

Все токенизаторы реализуют простой интерфейс:

Простой и расширяемый контракт.

Токенизатор слов (WordTokenizer)

Разбивает текст на отдельные слова. Слово «parser» превращается в

Этот метод отлично подходит для точных совпадений.

Вес: 20 — высокий, для точных совпадений.

Префиксный токенизатор (PrefixTokenizer)

Создаёт префиксы слов, например:

→

(минимальная длина префикса — 4).

Это полезно для поиска по частям слова и автодополнения.

Вес: 5 — средний, для частичных совпадений.

Зачем минимальная длина?

Чтобы избежать слишком большого количества коротких токенов — префиксы короче 4 символов обычно слишком распространены и малоэффективны.

Токенизатор n-грамм (NGramsTokenizer)

Создаёт последовательности символов фиксированной длины (обычно 3).

Например,

→

.

Это помогает улавливать опечатки и частичные совпадения.

Вес: 1 — низкий, но улавливает редкие случаи и опечатки.

Почему длина 3?

Это компромисс между слишком большим количеством совпадений и пропущенными вариантами из-за опечаток.

Блок 3: Система весов

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

1. Вес поля — например, заголовок, основное содержание или ключевые слова. Разные части документа могут иметь разный приоритет.
2. Вес токенизатора — каждый тип токенизатора (слово, префикс, n-грамма) имеет свой вес. Эти веса хранятся в таблице index_tokens.
3. Вес документа — итоговый вес для конкретного токена в конкретном документе. Хранится в index_entries и рассчитывается по формуле:

Как рассчитывается итоговый вес?

Во время индексации для каждого токена мы считаем вес так:

Например:

• Вес поля заголовка: 10
• Вес токенизатора слов: 20
• Длина токена «parser»: 6

Тогда итоговый вес:

Почему используется ceil(sqrt())?

• Более длинные токены обычно более специфичны и важны — например, «parser» конкретнее, чем «par».
• Но мы не хотим, чтобы очень длинные токены имели слишком большой вес — 100-символьный токен не должен давать вес в 100 раз больше, чем короткий.
• Функция квадратного корня даёт убывающую доходность — вес растёт с длиной, но не линейно.
• ceil() округляет результат вверх, чтобы сохранить веса целыми числами.

Настройка весов под свои задачи

Вы можете гибко настраивать веса под свои нужды:

• Увеличить вес поля — например, если заголовки для вас важнее всего.
• Изменить вес токенизатора — повысить для точных совпадений (слов), понизить для менее важных (n-граммы).
• Изменить формулу для длины токена — вместо ceil(sqrt()) можно использовать логарифм или линейную функцию, чтобы по-другому влиять на вес длинных токенов.

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

Блок 4: Служба индексирования

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

Интерфейс для документов

Чтобы документ мог индексироваться, он должен реализовать интерфейс

с тремя методами:

• getDocumentId() — возвращает уникальный идентификатор документа.
• getDocumentType() — возвращает тип документа (например, статья, пост, комментарий).
• getIndexableFields() — возвращает поля документа, которые нужно индексировать, вместе с их весами.

Пример реализации для статьи:

Когда индексируем?

• При создании или обновлении документа (например, через события).
• По командам в консоли — например, app:index-document или app:reindex-documents.
• Через задачи cron для массовой переиндексации.

Как работает индексирование — шаг за шагом

1. Получаем данные документа: его тип, ID и поля с весами.
2. Удаляем старый индекс для этого документа. Это важно, чтобы избежать дублирования данных.
3. Для каждого поля запускаем все токенизаторы, которые разбивают текст на токены.
4. Для каждого токена:Находим или создаём его в таблице токенов (чтобы не хранить одинаковые токены несколько раз).Рассчитываем итоговый вес по формуле:вес_поля × вес_токенизатора × ceil(квадратный_корень_из_длины_токена) Добавляем информацию в пакет для массовой вставки.Вставляем все новые записи в базу данных одним запросом — так быстрее и эффективнее.
5. Находим или создаём его в таблице токенов (чтобы не хранить одинаковые токены несколько раз).
6. Рассчитываем итоговый вес по формуле:вес_поля × вес_токенизатора × ceil(квадратный_корень_из_длины_токена) Добавляем информацию в пакет для массовой вставки.Вставляем все новые записи в базу данных одним запросом — так быстрее и эффективнее.

Зачем искать или создавать токены?

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

1. Ключевые моментыСтарый индекс удаляется перед созданием нового — это упрощает обновление.Используется пакетная вставка для производительности.Токены ищутся или создаются, чтобы избежать дубликатов.Итоговый вес считается динамически при индексации.
2. Ключевые моментыСтарый индекс удаляется перед созданием нового — это упрощает обновление.Используется пакетная вставка для производительности.Токены ищутся или создаются, чтобы избежать дубликатов.Итоговый вес считается динамически при индексации.
3. Старый индекс удаляется перед созданием нового — это упрощает обновление.
4. Используется пакетная вставка для производительности.
5. Токены ищутся или создаются, чтобы избежать дубликатов.
6. Итоговый вес считается динамически при индексации.

Блок 5: Служба поиска

Поисковый сервис принимает строку запроса, разбивает её на токены, ищет эти токены в индексах и возвращает список документов, отсортированных по релевантности.

Как это работает — шаг за шагом

1. Токенизация запроса

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

Пример:

• Индексация создала токены: par, pars, parse, parser (префиксный токенизатор).
• Поиск тоже использует префиксный и обычный токенизатор — так мы найдём не только точное слово parser, но и все его варианты.

Если запрос пустой (нет токенов), возвращаем пустой результат.

1. Уникальные токены

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

1. Сортировка токенов

Токены сортируются по длине — сначала самые длинные. Это важно, потому что более длинные токены — более конкретные и дают более точные совпадения.

1. Ограничение количества токенов

Если пользователь отправит очень длинный запрос, мы ограничиваем число токенов (например, максимум 300), чтобы избежать нагрузок на систему.

1. Выполнение поискового SQL-запроса

Далее строится и выполняется оптимизированный SQL-запрос, который:

• Ищет документы, где встречаются эти токены.
• Считает оценку релевантности для каждого документа.
• Сортирует результаты по убыванию оценки.
• Возвращает ограниченное число результатов (например, топ-10).

Как считается оценка релевантности?

Оценка складывается из нескольких факторов:

• Базовый балл — сумма весов всех найденных токенов в документе.
• Разнообразие токенов — документы с большим количеством разных токенов получают бонус (логарифмическая шкала, чтобы не давать слишком большой перевес).
• Качество совпадений — чем выше средний вес токенов, тем лучше (например, совпадение в заголовке важнее, чем в теле текста).
• Штраф за длину документа — чтобы длинные документы не имели слишком большое преимущество.

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

Почему нужен подзапрос с весом токенов?

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

Пример возвращаемого результата

Поиск возвращает список таких объектов — ID документа и его релевантность.

Как получить сами документы?

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

Репозиторий гарантирует, что документы вернутся в том же порядке, что и результаты поиска (используется SQL-функция

Итог

В результате вы получаете мощную и гибкую поисковую систему, которая:

• Быстро находит релевантные документы через индексы в базе данных.
• Обрабатывает опечатки и частичные совпадения с помощью n-грамм и префиксных токенизаторов.
• Придаёт больше веса точным совпадениям (например, полным словам).
• Работает без внешних сервисов — только с базой данных.
• Легко отлаживается и настраивается за счёт прозрачного SQL и гибких весов.

Расширение системы

Добавление нового токенизатора

Чтобы добавить новый способ разбиения текста на токены (например, стемминг, лемматизацию, синонимы и т.д.), нужно:

• Реализовать интерфейс TokenizerInterface, например:

Зарегистрировать этот токенизатор в конфигурации сервиса — и он автоматически будет использоваться и для индексации, и для поиска.

Добавление нового типа документа

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

Изменение весов и формул

• Вес токенизаторов и полей легко настраивается через конфигурацию.
• Формулы подсчёта релевантности находятся в SQL-запросе — вы можете его изменить, чтобы подстроить оценивание под свои задачи.

Заключение

• Это простая и понятная поисковая система — нет сложных «черных ящиков» и магии.
• Она легко контролируется, настраивается и отлаживается.
• Подходит для большинства приложений, где не нужна гигантская инфраструктура типа Elasticsearch.
• Главное — вы полностью управляете системой, понимаете каждый её шаг и можете улучшать её под свои нужды.

Берите и делайте под себя — это ваш поиск, и он должен работать так, как вам нужно.

Почему старые модели больше не работают

Долгие годы рекомендательные системы состояли из десятков моделей, которые решали свои узкие задачи. На финальном этапе часто использовался градиентный бустинг — метод, при котором несколько слабых моделей, например, поведенческая (лайки и просмотры) и контентная (теги и описания), объединяются в одну, более точную и устойчивую. Такой подход плохо понимал контекст и динамику интересов пользователя. Например, если человек внезапно переключался с футбольных обзоров на кулинарные видео, система не могла быстро подстроиться. Сегодня это решается переходом к нейросетевым архитектурам, которые видят картину целиком.

Как данные превращаются в рекомендации

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

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

Главная задача эмбеддингов — отобрать подходящий контент из миллионов вариантов.

1. Всё начинается с отбора кандидатов. При помощи поиска ближайших соседей ANN (approximate nearest neighbor search), реализованного через FAISS или аналоги, за миллисекунды находятся тысячи кандидатов, которые хотя бы примерно соответствуют интересам пользователя.
2. После этого идёт этап предранжирования. Из тысячи кандидатов нужно выбрать пару сотен наиболее перспективных. Здесь уже работают алгоритмы градиентного бустинга, например, CatBoost или другие, выбор зависит от инфраструктуры. Они учитывают дополнительные признаки: насколько свежа публикация, насколько популярен автор, как часто пользователь взаимодействовал с похожим контентом.
3. Затем наступает финальное ранжирование. Применяются глубокие нейросети, включая нейросетевые версии коллаборативной фильтрации, которые учитывают интересы похожих пользователей. Они прогнозируют, что пользователь будет делать дальше: досмотрит ли видео, поставит ли лайк или репостнёт. Здесь каждому кандидату уделяется особое внимание, ведь нужно выдать самые релевантные.

Всё это работает на единой DataPlatform, которая собирает сигналы от пользователей и обучает модели. В VK для этого есть единая Discovery-платформа, которая собирает клики, лайки, поисковые запросы и обновляет эмбеддинги.

Нейросетевой зоопарк: что стоит под капотом

В финальном ранжировании работает целая экосистема нейросетей. Это и многослойные перцептроны (MLP), и более сложные — сверточные (CNN), рекуррентные (RNN) и трансформеры.

1. Трансформеры и большие языковые модели (LLM)

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

С помощью механизма self-attention он находит связи между элементами и понимает контекст. Это позволяет строить контекстные эмбеддинги — векторные представления, которые учитывают не только содержание, но и значение слов в конкретной ситуации. Так модель понимает, что в фразе «я ем Кафку» речь идёт о еде, а не о литературе.

В рекомендациях трансформеры анализируют действия пользователя как последовательность. Например, модель SASRec (Self-Attentive Sequential Recommendation), которая используется в VK, предсказывает, что может заинтересовать человека дальше, и уже даёт прирост точности на 2,5–3%.

Сильная сторона трансформеров — в умении распознавать связи между действиями пользователя, а не просто фиксировать каждое событие. Если человек будет стабильно взаимодействовать с определённым контентом, модель «поймёт», что это не случайность, и придаст этому интересу больший вес. При этом случайные действия, вроде одного нерелевантного клика, не исказят общую картину — механизм self-attention помогает отличать устойчивые паттерны от шумовых всплесков.

Трансформеры активно применяются в ранжировании, но изначально разрабатывались как универсальные архитектуры для работы с последовательностями. А вот LLM, например, T5 или GPT, обучены на текстах. Они более гибкие: их можно настраивать также через текст и встраивать в диалог. Но они пока медленнее, требуют больше ресурсов и уступают в производительности на больших потоках.

2. Мультимодальные модели

Прорывной подход в рекомендательных системах. Они обрабатывают сразу несколько форматов: текст, изображения, звук. Всё это кодируется в векторы и сводится в общее пространство — часто тоже с помощью трансформеров. Так система понимает не только ключевые слова, но и смысл контента в разных форматах. По такому принципу работает Zelda — семейство моделей и фреймворк, лежащий в основе рекомендаций VK.

Раньше всё сводилось к матрице «пользователь × объект», где система пыталась предсказать оценки. Это работало, пока человек смотрел однотипный контент. Если пользователь смотрит обзоры гаджетов, то старая модель начинает искать похожие видео — с теми же тегами. Но если видео не помечено как «техника», система может его пропустить. Когда интересы меняются, алгоритм не понимает, почему пользователь внезапно увлёкся музыкой или историей.

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

3. Диффузионные модели

Диффузионные модели восстанавливают «чистые» предпочтения пользователя, убирая шум вроде случайных кликов и скипов. Например, вы смотрите обзоры смартфонов и случайно кликаете на видео про косметику с маркетплейса. Вы быстро переключили обратно на видео про смартфоны, и нейросеть понимает, что произошло, и не рекомендует видео про косметику.

Диффузионные модели особенно полезны при работе с разреженными и шумными данными — например, для новых пользователей. Такие модели, как DiffRec, показывают до 10% прироста точности на сложных датасетах и постепенно начинают конкурировать с трансформерами.

Система рекомендаций продолжит меняться

Следующим этапом в развитии нейросетевых методов может стать переход к сквозным (end-to-end) архитектурам, когда одна большая нейросеть берёт на себя все функции сразу. Некоторые платформы, например, TikTok и YouTube, уже частично внедряют end-to-end пайплайны. Это снижает ошибки на промежуточных этапах и учитывает цели платформы — вовлечение и удержание.

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

Кратко про ML и векторизацию

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

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

Решение в лоб

Очевидной идеей кажется простое разбиение пользовательских текстов на слова (токены). В качестве рекомендаций будем выдавать тех людей, у которых совпало наибольшее количество слов: общие слова будут звучать в тексте, а значит людям интересны одни и те же темы. Чем больше совпадений, тем лучше! Можно наливать кофе)

Но такая рекомендательная система получится не очень умной, поскольку она не учитывает общий контекст запроса, синонимы и какие-то опечатки.

Задачу решать все-таки надо, придется обратиться за помощью к ML’щикам. Они предлагают хранить не обычные тексты, а числовые представления или по простому вектора, чтобы их понимали программы. Оказывается, практически любые объекты можно превращать в вектор: слова, предложения, картинки или даже звуки. Такой процесс называется векторизацией.

Превратить объект в вектор — это задача машинного обучения. Есть разные подходы и уже обученные модели, которые на вход получают объекты, а на выходе дают вектор. Например, Bag of Words, TF-IDF, Word2Vec и другие. Для простоты понимания можно воспринимать этот процесс как некоторую математическую магию.

МЛщики, конечно, могут много всего интересного придумать, но бэкендерам надо разбираться, как это все хранить в памяти, поэтому вспомнить, что такое вектор все-таки придется. Нам же нужно с ними работать!

Назад в школу

Вектор — это элемент векторного пространства со своими свойствами и операциями.

У каждого вектора есть координаты и бла бла бла. Не очень понятно, как это использовать на практике.

На самом деле вектор — это просто массив чисел, а массивы мы уже умеем обрабатывать и хранить в памяти. Самое главное свойство для нашей задачи заключается в том, что между 2-мя векторами можно искать расстояние. Интуитивно это означает, что примерно похожие друг на друга вектора, находятся на близком расстоянии. По сути математические метрики и формулы описывают наше интуитивное представление.

Примеры метрик:

1) Евклидово расстояние (L2-норма). Расстояние в обычном его понимании.

Формула:

Пример: есть два вектора

Евклидово расстояние между ними:

2) Манхэттенское расстояние (L1-норма)

Формула:

Пример: для тех же векторов манхэттенское расстояние

3) Косинусное сходство. Технически это не истинная метрика расстояния, а мера сходства.

Формула для косинусного сходства:

Здесь

Для нахождения расстояния используем:

Пример:

Косинусное расстояние будет:

Такое маленькое расстояние указывает на то, что векторы весьма похожи.

Продвинутое решение

На такой математической идее и работает наш сервис: Мы превращаем описание пользователей в различные вектора, между которыми можно искать расстояние, а по полученным расстояниям делаем сортировку и выдаем рекомендации.

У этого решения есть принципиальные проблемы:

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

Эти проблемы хочется как-то решить и тут на помощь приходят они…

Векторные базы данных

Оказывается, есть векторные базы данных (ВБД). Это NoSQL решения, которые предназначены для хранения, индексирования и поиска похожих векторов.

Следовательно, с их помощью можно строить:

• Различные рекомендательные системы. Например, рекомендовать похожие товары в интернет магазине на основе свойств исходных товаров.
• Поисковые системы — искать наиболее похожие разделы по смысловой нагрузке текста.
• Делать различный анализ изображений и видео. Например, искать похожие картинки или находить оригинал изображения.

Устройство

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

Запись

1. На вход backend-приложения поступает какой-то объект (пусть это будет текст, как в нашем сервисе)
2. Этот объект нужно превратить в вектор при помощи обученного векторизатора.
3. Полученный вектор и метаданные исходного объекта можно сохранить на диск.

Чтение

1. К нам приходит приложение с новым объектом и запросом сделать для него рекомендацию.
2. Нужно проделать весь процесс обработки: векторизовать объект запроса той же моделью, получить вектор той же размерности.
3. Уже по сгенерированному вектору можно найти другой, наиболее близкий вектор. На этом этапе можно сделать предварительную фильтрацию по метаданным (Например, искать соседей только с длинной текста больше n).

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

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

Индексирование

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

Ускорить поиск можно несколькими способами: либо уменьшить размерность векторов, либо сузить область поиска. Рассмотрим парочку алгоритмов индексирования, попытаемся понять в чем заключается идея и почему поиск становится быстрее.

Уменьшение размерности, при помощи случайной проекции

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

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

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

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

Хэширование с учетом местоположения

Locality-sensitive hashing (LSH) — это метод индексации, который чем-то похож на устройство обычной хэш мапы. Идея заключается в следующем: отобразим вектора в бакеты похожести, используя набор функций хеширования. Проще всего рассмотреть на примере:

Зеленый вектор отображается в зеленый сегмент 1-го бакета, а синий вектор — в синий сегмент 2-го бакета.

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

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

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

Иерархический навигационный маленький мир

Hierarchical Navigable Small World (HNSW) — на первый взгляд сложный и непонятный алгоритм, который требует построения графа поиска, однако он очень важен и полезен, поскольку используется практически во всех современных ВБД, обеспечивая хорошую точность и скорость.

На самом деле идея довольно просто объясняется при помощи LEGO человечков.

Представим, что наши вектора обозначают персонажей из фильма «Звездные войны».

1. Сгруппируем вектора в узлы (случайно или с помощью алгоритмов кластеризации). Объединим Йоду, Люка, и принцессу Лею в узел светлой стороны (зеленый узел). Героев темной стороны объединим в красный узел, а роботов и клонов — в 3й узел будущего графа. Получилось 3 узла: зеленый, красный и оранжевый.
2. Проанализируем вектор каждого узла и нарисуем серое ребро между двумя узлами, если они содержат в себе похожие вектора (т.е. расстояние между векторами меньше некоторой заданной константы). Например, Люк Скайуокер очень похож на своего отца Энакина Скайуокера, поэтому эти узлы мы можем связать ребром. Точно так же с роботом R2D2. Его хозяином был Энакин, поэтому они чем-то похожи. Соответственно, эти узлы так же свяжем ребром. Таким образом, мы построим граф поиска, в котором каждый узел имеет связь с другими наиболее похожими узлами.
3. Когда к нам приходит запрос, мы можем использовать этот граф для навигации, посещая только те узлы, которые содержат вектора, наиболее близкие к вектору запроса. Например, мы хотим выдать рекомендацию для Люка Скайвокера, но Йоду и Принцессу Лею мы ему уже рекомендовали, поэтому они нам не подходят. Мы пройдемся по ребру и найдем новую рекомендацию — его отца, Энакина Скайвокера.

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

Пробуем на практике

Вернемся к нашей задаче по рекомендации собеседников. Выберем конкретную базу данных и сравним ее с нашим решением, которое основано на подсчете расстояния между векторами.

Для проведения экспериментов, я руководствовался следующими критериями: хотелось взять OpenSource базу данных, которую можно было бы легко развернуть у себя, а наличие встроенных векторизаторов было весомым плюсом, поскольку я занимаюсь бэкендом и не претендую на экспертность в машинном обучении. На практике это означает, что не придется заморачиваться с преобразованием текстов в вектора и совмещением интерфейсов нашего решения и ВБД.

В таблице представлены самые популярные векторные базы данных (или расширения существующих БД, см. pgvector). Ранжирование по производительности и потреблению памяти представлено по местам. Это сделано так, потому что на разных датасетах базы данных ведут себя по-разному: где-то выигрывает одна, где-то другая, поэтому приводить конкретные цифры было бы не совсем честно. Если усреднять, то можно упорядочить их по местам, как представлено в табличке. С подробными результатами бенчмарков можно ознакомиться на https://ann-benchmarks.com/.

Именно для бенчмарка быстрее и проще всего было взять БД с готовым векторизатором, чтобы не писать кучу кода для совместимости. После сортировки по популярности и производительности мой выбор пал на векторную базу данных Weaviate, вдобавок к которой идет неплохая документация.

Бенчмарки

Настало время провести замеры. Оба решения были запущены локально в docker контейнерах, а замеры производились с помощью docker container stats.

Рассмотрим график используемой памяти от количества векторов.

По горизонтальной оси отложены тысячи векторов (т.е. шкала от 100 векторов до полумиллиона), а по вертикальной оси — используемая память в МБ.

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

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

Тут картина уже сильно меняется. Откровенно говоря, наше решение работает непростительно долго на больших объемах: Для выдачи всего 1 рекомендации тратится 77 секунд. И как видно из графика при росте объемов эта цифра будет только расти, а вот векторная база данных работает практически за константное время, с учетом погрешности. Чтобы лучше заметить разницу, посмотрим на эти же данные на логарифмической шкале:

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

У использования готовых инструментов есть еще одно большое преимущество: алгоритмы и структуры данных уже написаны за нас, поэтому нам не нужно реализовывать их повторно, исправлять баги и поддерживать собственное решение.

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

Итоги

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

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

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

1. Это NoSQL решение, поэтому нет строгой транзакционности (не выполняются требования ACID). С другой стороны, такой вид БД хорошо горизонтально масштабируется, но сделать это правильно не так просто, из чего вытекают следующие пункты:
2. Нужно разбираться с индексированием, шардированием (партиционированием) и другими неочевидными вещами.
3. Нужно поддерживать всю необходимую инфраструктуру, следить за ее работоспособностью.
4. Изучать новый инструмент и погружать в него всю команду. Это может быть весомым минусом, особенно если сроки ограничены.
5. Не все работает из коробки: Например, для нашей задачи ВБД не умеют каждый раз выдавать новые рекомендации, хотя это и можно реализовать при помощи аналога курсоров. В общем, все равно придется делать доработки.

В заключение, хотелось бы сказать, что векторные базы данных — интересный инструмент для своих проектов, который однозначно стоит попробовать. Его использование позволяет сильно сократить время на разработку, ведь не нужно заниматься написанием собственного решения, его поддержкой и исправлением ошибок. ВБД ускоряют время поиска и чуть более оптимально используют память. С другой стороны, это не волшебное решение всех проблем: нужно поддерживать необходимую инфраструктуру, обновлять и мониторить ее, поэтому выбор всегда остается за вами. Выбирайте с умом!

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

Теория (самый страшный зверь)

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

Метрика

Чаще всего для оценки расстояния используют косинусное сходство (Cosine Similarity).

Представление данных в форме вектора имеет ещё одно полезное свойство. Мы можем измерить близость двух векторов или угол между ними. Чем угол меньше, тем они ближе.

TF-IDF

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

TF — это частота слова в тексте – количество раз, когда слово появляется в документе, деленное на общее количество слов в документе (каждый документ имеет свою частоту терминов). Обратная частота данных IDF — это логарифм обратной частоты распространенности слова в корпусе. Распространенностью называется отношение числа текстов, в которых встретилось искомое слово, к общему числу текстов в корпусе.

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

Scikit-Learn предоставляет преобразователь под названием TfidfVectorizer в модуле feature_extraction.text для векторизации с оценками TF-IDF.

Проблемы

• Холодный запуск

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

• Разреженность

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

• Конфиденциальность

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

Типы рекомендательных систем

Popularity-based

Наиболее простая система выдает рекомендации на основе популярности (popularity-based recommender systems). Чем выше средний рейтинг фильма, купленного товара или статьи, тем вероятнее, что система будет рекомендовать именно их.

Сontent-based filtering

Вторым типом рекомендательных систем является, так называемая, фильтрация на основе содержания (content-based filtering). В данном случае алгоритм рекомендует товары или услуги, схожие с теми, которые пользователь приобретал ранее. Например, если вы посмотрели фильм «Матрица» с Киану Ривзом, то в дальнейшем система будет рекомендовать вам научную фантастику, а также другие фильмы с участием этого актера.

Collaborative filtering

Третий тип — коллаборативная система (collaborative filtering). Она основывается на сопоставлении пользователей и товаров (или услуг, новостей и т.д.). Математически и графически в данном случае мы работаем с матрицами предпочтений (user-item matrix).

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

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

Что такое User-item matrix?

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

В совместной фильтрации используются два подхода:

а) Совместная фильтрация ближайших соседей на основе пользователей (user-based)

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

User Profile:

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

b) Совместная фильтрация ближайших соседей на основе элементов (item-based)

Системы, основанные на предмете рекомендации (item-based), сравнивают непосредственно близость товаров или услуг. Причем что отличает эту систему, сходство определяется на основе предпочтений всех пользователей, которые оставили свои оценки.

Item Profile:

В Content-Based Recommender мы должны создать профиль для каждого элемента, который будет представлять важные характеристики этого элемента.

Например, если мы делаем фильм как объект, то его актеры, режиссер, год выпуска и жанр являются наиболее значимыми характеристиками фильма. Мы также можем добавить его рейтинг из IMDB (база данных фильмов в Интернете) в профиле товара.

На этом мы закончим с ознакомлением с системами и перейдем к самому интересному — коду.

Немного о данных

Датасет я создала свой собственный, содержащий в себе данные об аниме (японской анимации) с сайта MyAnimeList(MAL). Очевидно, ниже приведенный код может быть использован для других наборов данных.

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

Посмотрим, какие жанры и теги чаще всего встречаются.

Самые популярные жанры – школа, научная фантастика, экшен, комедия и романтика. Самый популярный тег – суперсилы.

Чаще всего высокие оценки у сененов (аниме, рассчитанные на юношей до 18-ти лет), но в целом результаты почти одинаковые.

Высокие оценки имеют аниме с рейтингами R-17 и PG-13, то есть большинство аниме рассчитано на подростков от 13 до 17 лет.

Аниме для детей имеют возрастной рейтинг для всех или для детей (до 13). Сёдзе (произведение для девушек до 18 лет) чаще всего имеет рейтинг для детей. Чем выше возрастное ограничение, тем увеличивается процент содержания сененов и сейненов (произведение для юношей до 18 и старше соответственно)

Выделим релевантные параметры для рекомендаций.

Рекомендательная система (Content Based)

Для меры сходства (Cosine similarity) выберем linear kernel (ядра являются мерами сходства, т.е. s(a, b) > s(a, c), если объекты a и b считаются “более похожими”, чем объекты a и c), так как это быстрее.

Теперь у нас есть матрица парного косинусного сходства (cosine similarity) для всех фильмов в нашем наборе данных. Следующим шагом будет написание функции, которая возвращает 30 наиболее похожих фильмов на основе оценки косинусного сходства.

Наконец, проверим, как работает наша модель

Теперь сравним полученный список рекомендаций с рекомендациями на популярных сайтах (на примере аниме “Vinland Saga”)

Самый популярный сайт на западе (MAL): Shingeki no Kyojin, Dororo, Kenpuu Denki Berserk, 91 Days, Golden Kamuy, Kingdom, Arslan Senki, Shingeki no Kyojin: The Final Season, Mushoku Tensei, Youjo Senki… – совпадает более чем на 70% с полученными результатами. Некоторые произведения не вошли, так как у них не были заполнены некоторые параметры или они вышли раньше 2000-х. Сайт, где рекомендации основываются полностью на отзывах пользователей (AnimePlanet): Shingeki no Kyojin, Berserk, Dororo, One Piece, Arslan Senki, Shoukoku no Altair, Akatsuki no Yona, Shingeki no Kyojin 3, Jormungand, Kingdom, Shigurui, Golden Kamuy 2, 91 Days, Kiseijuu… – похожие результаты как и выше. Можно сделать вывод, что система рекомендаций довольно хорошо работает – она показывает результаты, наиболее похожие на введенное аниме.

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

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

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

Источники

Посмотреть полную реализацию кода: