RAG: как на самом деле работает retrieval-augmented generation
Прежде чем строить чат-бот над своими документами, стоит разобраться, что именно делает RAG, чего он не делает, и где возникают проблемы.
После запуска GPT-4 самый частый вопрос, который я начал слышать: «Можно ли заставить его отвечать по нашим внутренним документам?» Короткий ответ - да. Длинный ответ - для этого есть конкретный архитектурный паттерн, и если пропустить любой из его шагов, результат выглядит убедительно на демо и ломается в продакшне.
Этот паттерн называется RAG - retrieval-augmented generation, то есть генерация с поиском по базе знаний.
Что скрывается за названием
Идея простая. Языковая модель сама по себе знает только то, на чём обучалась. У неё нет доступа к вашим договорам, внутренней вики, истории поддержки. RAG решает это добавлением шага поиска до того, как модель генерирует ответ.
Схема выглядит так: пользователь задаёт вопрос, система ищет в документах наиболее релевантные фрагменты, эти фрагменты вставляются в промпт рядом с вопросом, и только после этого модель формирует ответ. Модель не «читает вашу базу» - она каждый раз читает небольшой кусок извлечённого контекста.
Три компонента, которые нужно построить
Пайплайн индексации. Документы нужно разбить на куски, преобразовать в векторные эмбеддинги и сохранить в векторную базу. Это разовый процесс, который повторяется при обновлении документов. Стратегия разбивки важнее, чем кажется: слишком длинные куски теряют точность, слишком короткие - контекст.
Шаг поиска. Когда приходит вопрос, он конвертируется в вектор той же моделью, и база возвращает наиболее похожие фрагменты. Качество поиска определяет качество итогового ответа. Хорошая модель не спасёт плохой поиск.
Шаг генерации. Найденные фрагменты и вопрос объединяются в промпт. Модель синтезирует ответ из того, что ей дали. Если нужная информация не была найдена, модель либо скажет, что не знает (хорошо), либо сгенерирует что-то правдоподобное на вид (плохо).
Где проваливаются проекты
Самая частая ошибка - считать поиск решённой задачей и тратить всё инженерное усилие на интеграцию с моделью. На практике улучшение поиска - лучшая нарезка, лучшие эмбеддинги, переранжирование - даёт намного больше, чем смена версии модели.
Вторая частая ошибка - игнорировать пайплайн документов. Если исходные документы противоречивы, плохо структурированы или полны устаревшей информации, RAG будет находить и уверенно предъявлять эту устаревшую информацию.
Третья - пропускать оценку качества. Несколько примеров вручную не считается. Нужен небольшой, но представительный тестовый набор, метрика полноты поиска и способ ловить деградацию при изменениях в пайплайне.
Практическая отправная точка
Если вы рассматриваете RAG для внутреннего сценария, вот вопросы, которые стоит прояснить до написания кода:
- Что за документы - их формат, частота обновления, кто за них отвечает?
- Как выглядит «хороший ответ» и кто будет его оценивать?
- Что делать, если ответа в документах нет?
Ответить на эти три вопроса заранее - значит сэкономить много времени на возврат к началу.