Особенность в рекомендательных системах

Контекст
В последнее время основные статьи в рекомендательных системах связанны с применением нейронных сетей.

Выглядит это всегда примерно так для сценария u2i:
1) Есть айтем -> кодируем через nn.Embedding его фичи
2) История пользователя состоит из айтемов -> используем наработку из 1) + encoder/decoder (трансформеры, aka sasrec/bert4rec) для кодирования вектора юзера.
3) Обучаем на задачу близости вектора пользователя со следующим айтемом/множеством айтемов. Возможно доп задачи: sasrec учится на next-item для всей истории, которые в проде он никогда не увидит

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

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

Для решения этой проблемы активно используют:
a) random negative sampling
b) in-batch negative sampling
c) и LogQ сверху

На практике мне хватало a) и b) . Добавление c) при существующих a) и b) доп качество не давало

А что в классике
Изначально рекомендательные системы решались на основе матриц соовстречаемости - тык.
Как это выглядело:
1) Есть айтемы и истории пользователя -> строим матрицу как часто 1 айтем встречался с другим айтемом в этой истории
2) К каждому айтему в истории достаем наиболее часто встречающиеся айтемы используя матрицу соовстречаемости - кандидаты айтема.
3) Вместе с айтемом достаем и некий скор (достаем столбец) - меру соовстречаемости. И если для нескольких айтемов в истории совпали кандидаты, то можем сложить/перемножить скоры - и получить финальный скор для каждого кандидата. Потом отобрать топ K

Главная проблема в классике - как сформировать эту матрицу. Хорошее понимание данных и своего домена может помочь в этом. А применение этих методов может дать представление о том, как устроены данные. Примеры простых эвристик:
1) Поделить строчку на сумму в этой строке -> уберем байс популярности айтема (а нужно ли?) -> если ответ да, то будущий трансформер скорее всего не заведется без in-batch ns.
2) Добавить временную составляющую в историю -> учет трендов (а) -> получилось повысить скор - скорее всего трансформер еще выше сможет его выбить
3) Добавить дот продукт от контетных векторов с весом -> возможно колаборативной информации недостаточно и не все паттерны пользователи уже нашли -> скор вырос - в трансформер можно и нужно засунуть контентную часть

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

И когда уже сформирована интуиция как устроены данные, то можно попробовать хитрый трансформер с учетом полученных инсайдов в классике. У меня ходит кратно больше времени (3-4 дня vs 1 день на классику), чтобы завести трансформер. Это связанно с тем, что 1 такая моделька обучается от 3-4 часов , что гораздо медленнее чем матричные методы. Но зато удается выбить качество выше чем у классических алгоритмов.

В заключении
Но стоит ли оно того?

Велком в комменты: А вы часто сравниваете нейронночные методы с матричными в своих проектах? Пытаетесь выбить из классических методов максимум прежде чем тюнить нейронки? Какие другие аномалии замечали при тренировки нейроннок?

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

ease is all you need

про обе

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

а с другой стороны есть sota модели типа ease (elsa, sansa, ease + vae) или тот же tifu knn, которые стоят копейки и их очень тяжело выбить

при том что у них нет проблем с а и б

это смотря какой трансформер, если это просто sasrec/bert4rec, тогда скорее всего да. Но если это какой-нибудь контентный трансформер вообще без айдишников + в него можно прокинуть персонализированные скоры популярности user-item (прям к скору модели), тогда можно и автоэнкодер побить. Да и каталог побольше закрыть можно.

Ну конечно это все при отсутствии пункта б

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

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

от этого модель больше понимать не станет как мне кажется

точно так же ты можешь семантику и в классическую модель передать, даже тот же tfidf который точно так же зачастую бьет семантику трансформеров

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

https://arxiv.org/html/2409.04329v1
Я когда это писал ссылался на эту статью, просто прикидываясь User Personalized score (это не аутпуты модели, просто user-item статистика) можно подтянуть трансформер чаще рекомендовать не только глядя на последние N, а с учетом большей истории. Но на практике, это должно поднять не только utility, но и pop-bias. Модель усложнять не придется

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

А так, все супер ситуативно.
Мало данных или маленький каталог - классические алгоритмы хороши.
Огромный лог данных + каталог на миллион, скорее всего лучше взять трансформер

Делай легче, делай играюче, text-to-lora, кайфуй!

Зачем учить свою LoRA, когда можно взять инвайт и просто добавить воды описание задачи и получить адаптер без обучения. На самом деле за один forward pass и предварительным обучением гиперсети. Но на инфере действительно за один прямой проход. Sakana.ai снова удивляет.

Работает это при помощи того, что мы берем выходной эмб с модели cls emb для энкодера или last token emb для LLM.  Далее инитим гиперсеть случайно (по типу LoRA). После проносим через это опорный эмб с базовой модели и добиваемся, чтобы на выходе из мета-сети получить консистентые  отображения. Также используется принцип mutual learning, чтобы обмениваться с LoRA учителя градиентами, как по скрытым состояниям, так и по выходу вероятностей. Т.е. происходит и шеринг весов и дистилляция модели учителя.

Задача тут в том, чтобы получить сеть, которая может порождать LoRA веса схожие с весами учителя и не терять task specific. Скормлено в таком сетапе сотни известных и популярных адаптеров и связанных с ними задач. Авторы так же отмечают трансфер и на unseen задачи. Т.е. обещают свойства out of domain трансфера.

Интересное. Над пробнуть.

#llm #rag #petproject

Есть ли простое локальное AI решение для конфиденциальных данных? Чтобы поставить на свой комп и оно просто работало.
За последний год+ сталкивался с тремя самыми популярными приложениями (c UI) для работы с локальными LLM: OpenWebUI, Msty, AnythingLLM. Все три позволяют работать как с локальными моделями, так и с подключаться к “облачным”, все три не просто чат, но с доступом к локальным файлам и знаниям. Каждое классное по-своему, но для разных задач и типов пользователей. Разберем что к чему.

Msty - красота и простота
Msty сразу цепляет интерфейсом. Это просто красиво сделанное десктопное приложение с фокусом на приватность. Ставишь, выбираешь модель и файлы и сразу работаешь.

Киллер-фичи:
- Самый простой и интуитивно понятный: вот тут качаешь модель, вот тут загружаешь “знания”
- Коннектор к Obsidian (кто пользуется - оценят)
- Delve Mode - кликаешь на любой термин в ответе AI и он разворачивает тему в отдельном чате. Плюс визуализация этих "ветвлений" в виде графа
- Multiverse Chats - можешь запускать несколько моделей одновременно в одном окне. Удобно для сравнения ответов.
- Встроенная библиотека промптов.

Минусы: закрытый код, для себя бесплатно, но платная коммерческая лицензия, ограниченная кастомизация.

AnythingLLM - швейцарский нож для документов
Если нужно работать с документами и строить knowledge base - AnythingLLM ваш выбор. Open source, MIT лицензия, бесплатный для всех.

Сильные стороны:
- Крутой RAG из коробки - загружаешь PDFs, DOCX, даже целые кодовые базы, и AI отвечает на основе этих данных
- AI-агенты с no-code билдером - можешь настроить автоматизацию задач вроде парсинга сайтов
- Встроенный OCR - сканирует текст даже с картинок
- Есть и десктопная версия, и Docker для совместной работы
- Есть API
- Недавно завезли MCP

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

OpenWebUI - для гиков и разработчиков
Самое гибкое и расширяемое решение, симпатичное и функциональное. Если ты power user или разработчик - тебе сюда.

Что круто:
- Есть RAG, есть веб-поиск
- Есть даже интеграция с Google Drive (с заморочками, правда)
- Code Interpreter - модель может выполнять код прямо в чате для анализа данных
- Arena Mode для A/B тестирования разных моделей (как у Msty)
- Мощный OCR
- Гибкие права доступа
- Система функций и тулов - можешь подключать внешние API, создавать кастомные интеграции
- MCP и tool use
- API и целая экосистема вокруг

Но это веб-интерфейс, нужно разворачивать через Docker, и для новичков может быть сложновато. А еще потребуется установка ollama, ну в общем, если вы не знаете как работать с терминалом и докером, то будет сложно.
У них в роадмапе есть планы сделать это все в формате отдельного приложения и тогда OpenWebUI будет вне конкуренции.

Перед выбором определись с приоритетами:
- Просто нужно чтобы запустилось и работало - бери Msty
- Хочешь больше крутилок и нужны еще тулы и простые агенты - AnythingLLM
- OpenWebUI дает максимум гибкости, и он самый hackable

Не забывай про железо. Локальные модели жрут ресурсы. Приличные модели потребуют минимум 16GB RAM, лучше 32GB. И если есть нормальная видеокарта - модели будут работать в разы быстрее. Макбуки на M-чипах в этом плане показывают лучший баланс производительности.

Конечно же есть и другие альтернативы (поделитесь если пользовались сами)?

Интересна ли вообще тема локального AI "для себя"?

#llm #ml #systemdesign

Надеюсь, я не отбил у вас желание разбираться с LLM System Design. Если нет, то продолжаем.

Второй паттерн. Structured output

Вы выдаете желаемую JSON-схему ответа, LLM не может ее нарушить. Работает благодаря 2-м вещам:

1) Ваш формат конвертируется в грамматику. Генерация каждого следующего токена жестко ограничена этой грамматикой. Считайте, что работает регулярка на выходе модели.

2) Базовая модель дообучалась, чтобы понимать по схеме, что вообще от нее хотят.

Удобно задавать через библиотеку Pydantic. Вы просто программируете классы, Pydantic генерирует нужный json. Пример, когда LLM извлекает поля научной статьи:

from pydantic import BaseModel

class ResearchPaperExtraction(BaseModel):
    title: str
    authors: list[str]
    keywords: Optional[list[str]]

response = client.responses.parse(
    model="gpt-4o-2024-08-06",
    input=[...], 
    text_format=ResearchPaperExtraction,
)

Optional объясняет, что keywords может быть не у каждой статьи.

Почему важно

- Убирает боль неверных форматов. При условии, что мы все идем к тулам и агентам (подробнее в 3 паттерне), это супер важно.

- Улучшает прозрачность. Все понятно, что модель нашла , а что найти не смогла (там будет None)

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

Structured Output и Reasoning

Никто не мешает вам совмещать Structured Output (SO) с рассуждающими моделями. Пусть они выводят свои рассуждения в отдельное (первое) поле:

class Step(BaseModel):
    explanation: str
    output: str

Есть статьи, которые говорят, что это ломает рассуждающие способности. Решение: пробуйте 2 раза. Сначала рассуждайте без SO, потом извлейкайте ответ с SO (более простой моделью, конечно)

Литература для изучения

- Документация от OpenAI
- Волшебный доклад про Pydantic
- Подробнее про двойной подход в SO + Reasoning
- Туториал по SO для Langchain

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

#llm_system_design

#llm #ml #systemdesign

10 паттернов разработки надежных LLM приложений.

Начинаю серию публикаций по LLM System Design.
Если осилите все 10 паттернов - сможете разрабатывать надежные LLM-приложения, которые не сломаются от наплыва счастливых пользователей.
Поехали.

Паттерн 1. LLM приложение это просто граф

Считайте, что вы разрабатываете обычный софт. Используете микросервисную архитектуру. Сервис 1 ждет ответа от Сервиса 2, если ответ = X, то идет в Сервис 3 и тд.

Только теперь у вас некоторые сервисы это не просто код. Может быть вызов LLM-классификатора, в зависимости от вердикта вызываться какой-то другой код. Или вызов LLM-суммаризатора, ответ которого запишется в NOSQL базу данных.

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

Перечислим часто используемые элементы в этом графе:

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

- Вызов LLM. Они могут соединяться различным образом: идти последовательно, параллельно, при выполнении условия и тд. Строго читать статью

- Внешние инструменты. Например, поисковый движок. Похоже на код, но инструменты не делают бизнес логики. Результат инструментов подается на вход в LLM. Разберем в "Паттерн 3. Все есть инструмент".

- Внешняя база знаний. Так делается RAG. Лучший способ заложить внешние знания в LLM. Подробнее обсудим в "Паттерн 4. Всегда используйте in context learning" и "Паттерн 5. Не переусложняйте RAG".

- Не-LLM модели. Обычно это берты/сверточные сети или бустинги над деревьями. Очень быстры и дешевы. Как правило, обучаются дистилляцией. Поговорим про это в "Паттерн 10. Дистилируйте."

- Guardrails. Модели, которая оценивает качество ответа. Если качество плохое, лучше такое никому не показывать. Обсудим в "Паттерн 8. Human-in-the-loop"

- Человек. У него нужно уточнить, когда непонятно, что делать дальше. У него нужно спросить, когда хотим сделать рискованное действие. Подробнее в "Паттерн 8. Human-in-the-loop"

- Автономные агенты. Редкий зверь, но будет чаще встречаться. Почему редкий. Обсудим в "Паттерн 9. Когда нужны автономные агенты."


Литература для изучения

- Строго mustread пост от Anthropic
- Подробная схема LLM-приложений от Chip Huyen
- Пост, почему надо разделять LLM и бизнес логику
- 500 реальных кейсов LLM-приложений
- Подробный гайд с большим числом деталей
- Принципы проектирования агентов (многое можно почерпнуть и для неагентов)


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

#llm_system_design

#llm #courses

Как-то я это пропустил; или просто недавно появилось: курс для самостоятельного знакомства с ИИ с отличным названием Introduction to AI Fluency; курс хорош тем, что это не очередной бессмысленный справочник по промтам, а пособие по структуре работы с ИИ, актуальное на 2025. Здесь и про делегирование ИИ, и про работу над реальными (хотя и модельными) проектами на каждом занятии.
Помимо содержательной стороны это еще и пример того, как можно сделать современный образовательный продукт, а не просто очередной видеокурс.
https://www.anthropic.com/ai-fluency/overview

#gan #petproject

Мам купи мне липсинк от Dreamina. Какой тебе липсинк, вон у нас есть липсинк дома. Тем временем липсинк дома☝️☝️.

Опенсорсный Sonic. Работает в ComfyUI. Не забудьте скачать модели, прежде чем использовать workflow.

#lipsync