Обсуждать абстрактно "как правильно делать LLM" очень тупо. Поэтому мы будем разбирать архитектуру на реальных примерах.

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

Архитектура Поиска по контенту LinkedIn

В соцсети много контента, надо по нему искать. Для RAGа, да и просто для души.

Метрики

Time Spent просмотра постов
Если пользователь листает выдачу поиска и ничего не читает, то скорее всего мы нашли фигню.

Релевантность
Часто просто крутить Time Spent плохая идея, сигнал шумный. Хорошая идея мешать его с чем-то более легко измеримым, например, релевантностью поста. Мерят с помощью GPT.

Архитектура

Индекс из миллиардов постов. Два метода генерации кандидатов:

1) Текстовое совпадение по словам
Вечная классика — обратный индекс, нашли посты со словами из запроса, никакой семантики.

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

Дальше тысячи кандидатов отправляются в ранкер.

Ранкер из 2-х этапов. Сначала тысячи ранжируются одной моделькой. Дальше сотни ранжируются моделькой побольше. Архитектура моделей одинаковая.

Модель ранкера это две FC сети. Первая предсказывает релевантность. У нее есть только эмбеддинги запроса и документа. Вторая предсказывает Time Spent. Туда помимо эмбеддингов подаются и обычные фичи (популярность поста, дружит ли пользователь с автором и тд).

Учатся модели на взвешенную сумму Time Spent + Релевантность.

Учатся на кучи исторических сессиях поиска.

Что тут важно почерпнуть

- Несколько таргетов. Часто хорошая идея. Особенно связка онлайн + оффлайн

- Классическая архитектура поиска. Несколько генераций кандидатов + несколько ранкеров.

- Разметка с помощью GPT. Если не очень сложная задача, работает быстро и хорошо

Что я бы поменял

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

1) Трансформеры-кроссэнкодеры на текстах, которые вы файнтюните

2) Бустинг над деревьями с обычными фичами

А лучше когда выход 1) пихаете в 2)

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

Итог

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

Что думаете по этой архитектуре поиска? Слабовато или наоборот перекрутили?

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

#llm_cases