зеркало из
https://github.com/iharh/notes.git
synced 2025-10-31 05:36:08 +02:00
24 строки
5.4 KiB
Plaintext
24 строки
5.4 KiB
Plaintext
https://t.me/rybakalexey/314
|
|
*****
|
|
Ликбез: RAG, или генерация с дополнением
|
|
|
|
Признаюсь честно, сначала я не понимал, зачем нужен RAG так массово, почему СУБД бросились реализовывать векторный поиск, и вообще на этом делается неслабый маркетинговый упор. Возможно, вы и сами не очень в теме RAG, и тогда этот пост для вас. Постараюсь очень простыми словами написать, что такое RAG, или генерация c дополнением.
|
|
|
|
Начнем с конца: зачем важен контекст промта. Нравится нам это или нет, но LLM уже полноценно заменяют нам поиск. Уже гугл для большинства запросов первым сниппетом в результатах ставит справку из своего AI. Людям удобнее и приятнее читать ответы LLM на вопросы, где нужно обьяснить, где нет четкого ответа. Но LLM строит свои ответы на ранее проиндексированных документах, и этот множество как правило очень широкое. Поэтому если нам нужно построить какую-то поисковую или агентную систему, например, для организации, на основе только какого-то кусочка знаний, в LLM нужно передать этот кусочек, или контекст, поскольку иначе LLM нам что-то ответит на основе всех-всех проиндексированных документов и ценность этого знания будет минимальной.
|
|
|
|
Например, у нас есть специфический закрытый софт, на который есть подробная документация (не смейтесь, верьте в хорошее). И есть много пользователей, которые постоянно что-то спрашивают. Читать документацию им лень, да и документация большая, там гигантское оглавление, поди найди отавет на свой вопрос, поэтому проще спросить, и oncall админы, вам лучи добра и глубочайшего сочувствия.
|
|
|
|
А теперь представьте, что LLM может взять часть документации и получить её как контекст запроса. В первом приближении это выглядит так: к запросу юзера добавляется что-то вроде в ответе на вопрос используй этот и только этот контекст, и сюда же в запрос добавляется документация целиком. То есть мы говорим машине: вот документ, о котором ты ничего не знаешь, вот запрос пользователя, напиши ответ, основывающийся только на этой документации. Это супер-удобно, быстро делать, пользователям счастье.
|
|
|
|
Но документация может быть огромна, контекст широкий, и гонять такие запросы в LLM - дорого и долго ждать. Поэтому нужно передавать только релевантные куски документации. А как определить, какие куски релевантны? Нужно разбить документацию на куски, найти по запросу юзера наиболее близкие по смыску участки документации, и передать в качестве контекста только их. Как определить близкие по смыслу кучки? И тут приходит на помощь другая фича LLM, построение смыслового вектора, или “эмбеддинга”: куски документации при индексации получают от LLM смысловые вектора, а затем они сохраняются в корпоративную СУБД, кусочек доки и эмбеддинг.
|
|
|
|
И вся RAG-генерация (или ещё говорят RAG-пайплайн) выглядит так
|
|
- при индексации: разбить доку на куски, получить эмбеддинги, сохранить в корпоративной субд
|
|
- по запросу юзера найти близкие по смыслу кусочки доки, используя эмбеддинги
|
|
- расширить запрос юзера контекстом (кусками доки) и отправит запрос в LLM
|
|
- показать юзеру результат
|
|
|
|
Вот и всё!
|
|
🔥 если хорошо обьяснил
|
|
👍 еcли всё уже знал про RAG 🙂
|