Ликбез: RAG, или генерация с дополнением

Признаюсь честно, сначала я не понимал, зачем нужен RAG так массово, почему СУБД бросились реализовывать векторный поиск, и вообще на этом делается неслабый маркетинговый упор. Возможно, вы и сами не очень в теме RAG, и тогда этот пост для вас. Постараюсь очень простыми словами написать, что такое RAG, или генерация c дополнением.

Начнем с конца: зачем важен контекст промта. Нравится нам это или нет, но LLM уже полноценно заменяют нам поиск. Уже гугл для большинства запросов первым сниппетом в результатах ставит справку из своего AI. Людям удобнее и приятнее читать ответы LLM на вопросы, где нужно обьяснить, где нет четкого ответа. Но LLM строит свои ответы на ранее проиндексированных документах, и этот множество как правило очень широкое. Поэтому если нам нужно построить какую-то поисковую или агентную систему, например, для организации, на основе только какого-то кусочка знаний, в LLM нужно передать этот кусочек, или контекст, поскольку иначе LLM нам что-то ответит на основе всех-всех проиндексированных документов и ценность этого знания будет минимальной.

Например, у нас есть специфический закрытый софт, на который есть подробная документация (не смейтесь, верьте в хорошее). И есть много пользователей, которые постоянно что-то спрашивают. Читать документацию им лень, да и документация большая, там гигантское оглавление, поди найди отавет на свой вопрос, поэтому проще спросить, и oncall админы, вам лучи добра и глубочайшего сочувствия.

А теперь представьте, что LLM может взять часть документации и получить её как контекст запроса. В первом приближении это выглядит так: к запросу юзера добавляется что-то вроде в ответе на вопрос используй этот и только этот контекст, и сюда же в запрос добавляется документация целиком. То есть мы говорим машине: вот документ, о котором ты ничего не знаешь, вот запрос пользователя, напиши ответ, основывающийся только на этой документации. Это супер-удобно, быстро делать, пользователям счастье.

Но документация может быть огромна, контекст широкий, и гонять такие запросы в LLM - дорого и долго ждать. Поэтому нужно передавать только релевантные куски документации. А как определить, какие куски релевантны? Нужно разбить документацию на куски, найти по запросу юзера наиболее близкие по смыску участки документации, и передать в качестве контекста только их. Как определить близкие по смыслу кучки? И тут приходит на помощь другая фича LLM, построение смыслового вектора, или “эмбеддинга”: куски документации при индексации получают от LLM смысловые вектора, а затем они сохраняются в корпоративную СУБД, кусочек доки и эмбеддинг.

И вся RAG-генерация (или ещё говорят RAG-пайплайн) выглядит так
- при индексации: разбить доку на куски, получить эмбеддинги, сохранить в корпоративной субд
- по запросу юзера найти близкие по смыслу кусочки доки, используя эмбеддинги
- расширить запрос юзера контекстом (кусками доки) и отправит запрос в LLM
- показать юзеру результат

Вот и всё!
🔥 если хорошо обьяснил
👍 еcли всё уже знал про RAG 🙂

——
🤩 запуски Devhands: Redis и Valkey (7 окт), PostgreSQL 17 (16 окт), Производительность и масштабируемость (22 окт), Performance review (14 окт)