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

Ставим агентов на поток. Кейс компании DoorDash

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

Про что платформа

DoorDash — крупнейшая компания по доставке еды в США. У них накоплена масса полезных знаний о их бизнесе: корпоративная вики, таски в джире, множество SQL-таблиц, регламентов и прочих разных вкусностей корпоративных гигантов.

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

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

Каких агентов можно создавать

- LLM-workflow. Агент работает по строгому протоколу. Используется, когда нужна высокая надежность и есть этот самый протокол.

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

- мультиагент через планировщика. Самый простой и рабочий вариант мультиагентной системы. Главный агент независимые подзадачи раздает субагентам, а потом собирает ответ. Классический пример от Anthropic.

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

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

Техническое устройство

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

- RAG-платформа, через которую вы добавляете информацию

- Поддержка SQL

- Система оценки качества агента

- Валидация ответа и Guardrails

И много чего еще. После небольшого инструктажа обычный человек, используя эти кубики, сможет собрать реально полезного агента. Да, там не будет последних трюков из контекст-инжениринга. Да, LLM там обычные, а не дообученные под эту задачу. Но мы получим 80% результата за 20% сил.

Главный секрет успеха платформы — как надежно и удобно работает система оценки качества. Если получилось — дальше собирать Лего одно удовольствие. Если нет — всегда будут получаться жигули.

Моя вера в будущее

Я верю, что только так мы сможем масштабировать AI. Многие со мной согласны. Компании валом побежали делать платформы для создания агентов. Даже OpenAI, которые ранее верили только в один мега-мозг.

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

#llm_cases