RAG в LLM

Продолжаем тему языковых моделей. Первый пост был по различию базовых и инструктивных LLM. Сегодня рассмотрем понятие RAG.

RAG (Retrieval Augmented Generation) - это подход, который позволяет использовать Большие языковые модели (LLM) для ответов на вопросы пользователей по приватным источникам информации.

Рассмотрим самый базовый вариант RAG:

▶️ Подготовка данных
- Собираем документы
- Разбиваем весь корпус документов на чанки (небольшие кусочки текста). Разбивать можно разными способами, например по предложениям (по символу-разделителю точке), или более хитро по иерархии на большие чанки и внутри них чанки поменьше (сабчанки)
- Каждый чанк кодируем энкодером в вектор. Это нужно, чтобы сравнивать вектор чанка с вектором вопроса пользователя. В качестве энкодера удобно взять уже обученный HuggingFaceEmbeddings
- Пишем все закодированные чанки в векторную БД. Одна из топовых векторных БД Pinecone, заточена специально под хранение эмбеддингов для LLM приложений

▶️ Ответ на вопрос
- Пользователь формулирует вопрос
- С помощью энкодера из первого пункта кодируем текст вопроса в вектор
- Отбираем из всего списка чанков векторной БД топ-N наиболее близких вектору вопроса. Близость векторов меряем косинусным расстоянием
- Все найиденные N чанков и вопрос (и то, и другое уже в виде текста) передаем в LLM и просим ее, учитывая контекст (из чанков), ответить на вопрос пользователя

Идея о RAG возникла из-за трех ограничений:
- Невозможности впихнуть в LLM весь желаемый контекcт
- LLM ничего не знает об информации, которой не было в обучающих данных. Это касается любой приватной или узко-направленной инфы
- Альтернативой RAG может быть дообучение LLM на своих данных, но это крайне нерационально и дорого

Таким образом легким движением руки мы можем без дообучения LLM и энкодера написать свой простой Q&A сервис или чат-бота под свою доменную область. Дальше можно пробовать улучшать сервис, например тюнингом энкодера, иерархией чанков или правками в промпт

#llm