Кстати, что такое RAG?
В последнее время напридумывали множество новых терминов, под которыми скрываются давно придуманные истории.
Собственно, RAG — Retrieval Augmented Generation. Если говорить простым языком, это попытка предоставить внешние знания, например документацию по какому-то продукту или весь уголовный кодекс РФ, напрямую в LLM. Зачем? Чтобы удерживать ее внимание в рамках нужной нам задачи. По сути, мы говорим: генерируй ответ только на основе предоставленной тебе информации.
Сразу представляется волшебный мир будущего:
Пользователь — Как мне правильно оформить декларацию для налогового вычета?
Сервис — Чтобы корректно оформить налоговую декларацию по форме 3-НДФЛ, вам нужно перечислить все ваши доходы от различных источников с указанием типов деятельности.
Любая базовая LLM модель скорее всего выкинет странный ответ, не только неправильный, но и возможно вредный. Вот поэтому надо ограничивать генерацию источниками информации
Есть разные подходы, как это делать:
– Взять уже обученную модель, для каждого входного запроса предварительно искать в нашем корпусе кусочки текста, похожие на запрос пользователя, и хитро подставлять их в конечный инпут модели;
– Дообучить базовую модель на нашем корпусе, надеясь, что она все запомнит и не будет галлюцинировать;
– Взять уже обученную модель, для пользовательского запроса искать похожие кусочки текста, потом той же моделью одним промптом просить перевести в единый укороченный контекст, затем подставить этот контекст в следующий промпт для получения финального ответа;
– Дообучить модель, используя промпты как в первом подходе.


В 99% случаев, когда вам продают RAG, это будет первый подход. По сути, зумеры прикрутили к промпту быстрый поиск ближайших соседей, и вот как раз для этого нужны векторные базы данных. Что-то похожее делали 10-20 лет назад разрабы из Гугла/Бинга/Яндекса/etc. Раньше сильно беспокоились за качество выдачи, за точность ответа, но в 2022 OpenAI показали нам, что на это можно забить, продукт важнее, чем неправильные ответы.