Обсуждать абстрактно "как правильно делать 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
Раз мы недавно обсуждали 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