RAG
Последнее время стал вытаскивать себя из кокона компьютерного зрения, активно изучая NLP, так как современный ML не терпит разделения на модальности. В частности посмотрел курс от ШАДа и Лены Войта, вау человек и такой же клевый курс, зацените, если вдруг кто искал материалы.
Retrieval Augmented Generation - метод, при котором к запросу пользователя программно добавляется какая-то информация и уже такой комбинированный запрос идет в языковую модель. Что это будет за информация - зависит от вашего приложения, чаще всего это какая-то база знаний или просто результат работы какой-то функции.
В чем плюсы и когда используют?
1. Постоянное изменение базы знаний. Невозможно дообучить модель на своих данных, чтобы она смогла ответить на вопрос "какая сейчас погода?".
2. Дообучать дорого. Альтернативой, конечно, является дообучение под вашу задачу, но почти всегда это долго, дорого, сложно и не факт, что что-то получится.
3. Факт-чекинг. Использование RAG это простой способ понизить галлюцинирование модели и повысить интерпретируемость выдаваемого результата. Это не серебряная пуля, но простой шаг в этом направлении.
Основной минус подхода: пространство "знаний" модели искусственно ограничено размерами базы данных.
Как работает и из чего состоит?
Основные шаги:
1. Взять базу знаний и разбить ее на маленькие части (chunks).
2. Превратить чанки в вектора (embeddings) и сложить в веторную БД.
3. Приходящий запрос пользователя превратить в эмбеддинг, вытащить из БД топ K самых похожих чанков по какой-то мере близости векторов.
4. Приклеить к запросу пользователя чанки и подать это в языковую модель, попросив ее давать ответ на вопрос на основе добавленных знаний.
Составляющие:
1. База знаний. Например, набор документов.
2. Векторная база данных. Для хранения эмбеддингов чанков.
3. Encoder. Модель, которая будет переводить подаваемый текст в эмбеддинг.
4. Generator. Модель, которая на основе входящего запроса будет генерировать текст.
3 и 4 пункт не обязательно делать самостоятельно, можно взять opensource или работать по API.
В каких местах можно улучшать:
1. Перефразировка запроса. Вопрос пользователя может быть задан не очень точно, можно попробовать его переделать, чтобы он отвечал требованиям построенной системы.
2. Классификация запроса. Необходимо балансировать между очень много знаний (есть целый бенчмарк посвященный этой проблеме) и очень мало знаний. А значит было бы круто иметь базу лаконичную, при этом достаточную. Можно добавить много источников данных и представить их в разной форме (таблицы, поисковик, текстовые документы). И реализовать механизм, который бы определял среди какого подмножества знаний искать и в какой форме они представлены.
3. Несколько методов создания эмбеддингов. Задача поиска релевантных чанков - основная в этой технике и завязана на качестве обучения encoder. Можно использовать несколько encoder-ов обученных по-разному. Популярный метод - это объединение sparse методов (многие любят BM25) и dense методов (encoder-ы).
4. Улучшение чанков. В качестве baseline, чанки содержат просто кусочек текста, но можно расширить их автономность. В целом: можно переписать исходные чанки и свести их в какое-то новое пространство.
5. Ранжирование чанков. Стоит добавить к задаче Reranker. Мы достаем из базы N близких чанков, а он оставляет уже из них лучше K.
6. Валидация ответов. Можно добавить модель, которая по паре вопрос-чанк будет говорить относится ли этот чанк к вопросу. Можно на пару вопрос-ответ спросить, а нет ли тут галлюцинаций и вообще является ли то, что было сгенерировано, ответом на вопрос. И таких валидаций можно придумать очень много, хотя, конечно, все это увеличивает время ожидания ответа.
7. Более хитрые знания. Работать с текстом и таблицами - понятно как. Но есть графики, картинки, видео, аудио. Потенциально все это также может составлять часть общей базы знаний.
Вот очень крутое видео обо всем этом от команды LangChain.
Пишите о чем хотелось бы еще почитать, ставьте огоньки и пересылайте своим друзьям и знакомым, добьем 100 до Нового Года?

@lechim_ai