Сегодня один из основных use cases для больших языковых моделей - поиск информации и questions answering по базе знаний. Для решения этой задачи используется технология Retrieval-Augmented Generation (или просто RAG), которая объединяет LLM и векторный поиск. RAG позволяет добавлять к промпту LLM фрагменты документации, содержащие ответ на вопросы пользователя - так LLM не галлюцинирует ответ, а опирается на внешние источники информации. В таком подходе уже не нужно переобучать LLM, чтобы синтезировать ответ с опорой на актуальные данные (напомню, GPT-4 обучена на данных, собранных до декабря 2023).
Хотя подход RAG впервые был предложен в 2020 году, по-настоящему популярным он стал только с распространением LLM. Сегодня 4 из 5 проектов по Generative AI включают в себя разработку и настройку RAG-поисковика. Приложения типа Chat to Your PDF, боты клиентской поддержки, внутренние чат-боты для сотрудников компании, ИИ-тьюторы и ассистенты - все эти продукты основаны на RAG в том или ином виде. Появление мультимодальных LLM сделало возможным сценарии типа “Chat with Videos/Audios/Images…”, AI-ассистенты для программистов тоже основаны на технологии RAG.
Использование RAG не только снижает уровень галлюцинаций языковых моделей, но и повышает объяснимость ответов и управляемость генерации - ответ синтезируется строго на основе контента из базы знаний, и все шаги процесса можно проследить.
В общем случае, RAG-система работает так:
1. База знаний нарезается на фрагменты (chunks), для каждого чанка рассчитывается отдельной нейронкой векторное представление (aka эмбеддинг), эмбеддинги индексируются и складываются в векторную базу данных.
2. Когда пользователь задает вопрос в чате, для него рассчитывается эмбеддинг и сопоставляется с эмбеддингами чанков в базе. Благодаря магии deep learning, ближайшие в пространстве эмбеддингов чанки и содержат ответ на заданный вопрос.
3. Наиболее релевантные чанки подаются на вход LLM, которая и генерирует ответ на вопрос.
Для RAG пайплайнов можно использовать как проприетарные, так и опен-сорсные LLM. И хотя наилучшее качество ответов обеспечат GPT-4 или Claude, многие задачи требуют использования локальных opensource моделей (Llama, Mistral, Qwen etc) - к примеру, если компания работает с чувствительными финансовыми или медицинскими данными. Для разработки RAG приложений обычно используются опенсорсные python фреймворки LlangChain или LlamaIndex - хотя у каждого из них хватает особенностей, и часто приходится перевозить проекты на самописные фреймворки.
Хотя в теории процесс RAG кажется относительно простым, на практике редко удается добиться нужного качества ответов с первого раза. В процессе есть куча подводных камней, поэтому в пайплайн часто приходится добавлять дополнительные этапы - от хитрых стратегий нарезки документов на чанки или переформулирования вопроса до ИИ-агентов, которые декомпозируют запрос пользователя и планируют генерацию ответа по нескольким индексам. Обзор основных техник Advanced RAG я сделаю в следующих постах.
Ссылки:
Обзор сабжа на Хабре
Обзор сабжа на arXiv
RAG vs finetuning
Vanilla vs advanced RAG (картинку взял тут)
#rag #llm #generativeai
Хотя подход RAG впервые был предложен в 2020 году, по-настоящему популярным он стал только с распространением LLM. Сегодня 4 из 5 проектов по Generative AI включают в себя разработку и настройку RAG-поисковика. Приложения типа Chat to Your PDF, боты клиентской поддержки, внутренние чат-боты для сотрудников компании, ИИ-тьюторы и ассистенты - все эти продукты основаны на RAG в том или ином виде. Появление мультимодальных LLM сделало возможным сценарии типа “Chat with Videos/Audios/Images…”, AI-ассистенты для программистов тоже основаны на технологии RAG.
Использование RAG не только снижает уровень галлюцинаций языковых моделей, но и повышает объяснимость ответов и управляемость генерации - ответ синтезируется строго на основе контента из базы знаний, и все шаги процесса можно проследить.
В общем случае, RAG-система работает так:
1. База знаний нарезается на фрагменты (chunks), для каждого чанка рассчитывается отдельной нейронкой векторное представление (aka эмбеддинг), эмбеддинги индексируются и складываются в векторную базу данных.
2. Когда пользователь задает вопрос в чате, для него рассчитывается эмбеддинг и сопоставляется с эмбеддингами чанков в базе. Благодаря магии deep learning, ближайшие в пространстве эмбеддингов чанки и содержат ответ на заданный вопрос.
3. Наиболее релевантные чанки подаются на вход LLM, которая и генерирует ответ на вопрос.
Для RAG пайплайнов можно использовать как проприетарные, так и опен-сорсные LLM. И хотя наилучшее качество ответов обеспечат GPT-4 или Claude, многие задачи требуют использования локальных opensource моделей (Llama, Mistral, Qwen etc) - к примеру, если компания работает с чувствительными финансовыми или медицинскими данными. Для разработки RAG приложений обычно используются опенсорсные python фреймворки LlangChain или LlamaIndex - хотя у каждого из них хватает особенностей, и часто приходится перевозить проекты на самописные фреймворки.
Хотя в теории процесс RAG кажется относительно простым, на практике редко удается добиться нужного качества ответов с первого раза. В процессе есть куча подводных камней, поэтому в пайплайн часто приходится добавлять дополнительные этапы - от хитрых стратегий нарезки документов на чанки или переформулирования вопроса до ИИ-агентов, которые декомпозируют запрос пользователя и планируют генерацию ответа по нескольким индексам. Обзор основных техник Advanced RAG я сделаю в следующих постах.
Ссылки:
Обзор сабжа на Хабре
Обзор сабжа на arXiv
RAG vs finetuning
Vanilla vs advanced RAG (картинку взял тут)
#rag #llm #generativeai