Рекомендации

Обзор движков рекомендаций AACsearch — похожие, also-viewed, frequently-bought-together, trending, персонализированные и GraphRAG. Какой движок куда поставить.

В AACsearch встроено семь движков рекомендаций на том же индексированном корпусе, что и поиск. Они спроектированы так, чтобы их можно было поставить на карточку товара, корзину, главную или empty-state без отдельной ML-инфраструктуры.

Движок	Что подаёшь на вход	Куда ставить	Код-путь
Похожие товары	ID одного товара/документа	Карточка товара	`GET /recommendations/similar`
Also viewed	ID одного товара	Карточка «Также смотрели»	`GET /recommendations/also-viewed`
Часто покупают вместе	ID одного товара	Корзина, «Завершите образ»	`GET /recommendations/frequently-bought-together`
Trending	Опц. категория/сегмент	Главная, пустые результаты	`GET /recommendations/trending`
Персонализированные	`userId` (сессия или логин)	Главная для залогиненных, push-email	`GET /recommendations/personalized`
GraphRAG-рекомендации	Один node + KnowledgeSpace	Навигация по графу знаний	`GET /knowledge/graphrag/recommendations`
User segments	Правила сегмента	Когортный таргетинг	`GET /recommendations/user-segments`

Какой движок выбрать

Шаги принятия решения:

Знаешь текущий товар → Similar для taste-match, Frequently bought together для корзинного attach, Also viewed для навигации.
Знаешь пользователя (логин или сессия) → Personalized.
Не знаешь ни того, ни другого (anonymous, пустая корзина, голая главная) → Trending.
Внутри knowledge graph (RAG/agentic, не e-commerce) → GraphRAG.

Движки комбинируются — типичная карусель «Рекомендовано вам» в дашборде делает Personalized → Trending, чтобы у нового посетителя без истории всё равно был контент.

Tenancy и scope

Каждый запрос рекомендации требует:

Bearer-токен, привязанный к одной организации (та же auth, что у POST /search).
indexId или collectionName, чтобы движок знал, по какому корпусу скорить.

Рекомендации никогда не выходят за индекс/организацию. Tenant-фильтр компилируется на уровне SQL WHERE (Invariant 4), не только на API-гейте.

Латентность

Движок	p95 чтения (Pro)	Заметки
Similar	80 мс	Vector search по embedding товара; быстро.
Also viewed	50 мс	Прекомпьют по co-occurrence просмотров.
Frequently bought together	60 мс	Прекомпьют по co-occurrence корзин.
Trending	40 мс	Чтение из прекомпьютнутого ведра (час/день).
Personalized	120 мс	Vector + filter; медленнее из-за per-user re-ranking.
Personalized from analytics	200 мс	Идёт по recent-event'ам пользователя — больше I/O.
GraphRAG	150 мс	Обход графа + LLM-шаг (кэшируется).

Эти цифры укладываются в read-SLO из Производительность и масштабирование. В рамках — рекомендация встаёт в тот же multi_search round-trip, что и остальная страница.

Стоимость по квоте

Каждый вызов рекомендации = один Search Unit в месячной квоте (maxSearchesPerMonth). Та же цена, что и POST /search. См. Тарифы → Search Units.

Настройки

Тюнеры (выбор модели, окно decay, состав сегментов):

GET /recommendations/personalization-config / PATCH …config
Дашборд → Search → Recommendations → Settings

Дефолты sensible. Трогать конфиг стоит только когда знаешь, какой именно рычаг крутишь — у каждой опции есть inline-ссылка на доку.

Cold start. Persona-движкам нужно ≥ 5 событий пользователя чтобы обыгрывать Trending. Если для нового пользователя результаты выглядят однообразно — это правильное поведение, движок в cold-start. Фоллбэк — Trending, дашборд показывает это явно.

Телеметрия

Каждый surface рекомендаций логирует:

recommendation_shown — engine, request id, возвращённые ID
recommendation_clicked — на какой ID кликнули (питает «uplift»-чарты)
recommendation_converted — покупка/конверсия атрибутированы обратно

События идут по тому же analytics-event-bus, что и поиск (SearchUsageEvent), поэтому ретеншн исторических данных тот же, что у search-аналитики.