Что такое RAG и проблему какую он решает
Языковые модели обучены на данных, которые заканчиваются в определённый момент времени. GPT-4, например, знает о мире только до апреля 2024 года. Если вы зададите ей вопрос о событии из июня или попросите найти информацию из вашей корпоративной базы знаний, она либо придумает ответ, либо признается, что не знает. Это называют галлюцинациями нейросетей.
RAG (Retrieval-Augmented Generation, или генерация с дополнением из внешних источников) решает эту проблему радикально просто. Вместо того чтобы полагаться только на знания, заложенные в весах модели, система сначала ищет нужную информацию в вашем хранилище данных, а потом передаёт её модели вместе с вопросом. Модель работает с фактами, которые вы ей дали, а не со своей памятью.
Результат впечатляет: ответы становятся точнее, система может работать с актуальными данными, а галлюцинации если и возникают, то с гораздо меньшей вероятностью. Это объясняет, почему RAG стал стандартом для корпоративных ИИ-систем. Компании используют его для чат-ботов, которые знают о продуктах больше, чем менеджеры, для аналитических систем, которые находят нужные документы из тысяч файлов, для консультантов, которые отвечают на вопросы сотрудников на основе внутренней базы знаний.
Этапы работы RAG-системы
RAG работает как конвейер с чётко определёнными этапами. На каждом этапе происходит преобразование информации, и качество на каждом из них влияет на финальный результат. Понимание этого потока критично, потому что ошибки на одном этапе не всегда видны на следующем, а проблемы накапливаются.
Индексация: превращение документов в базу знаний
Всё начинается задолго до того, как пользователь задаст вопрос. Ваши документы, статьи, справочники, письма, базы данных — всё это нужно подготовить и переложить в формат, с которым может работать система.
На этом этапе происходит несколько действий одновременно.
Сначала документы разбиваются на небольшие части. Если вы добавляете в систему 200-страничный отчет, его нельзя передать модели целиком. Контекст моделей ограничен, а длинный текст плохо обрабатывается. Поэтому документ режется на фрагменты, обычно от 256 до 1024 токенов (примерно 200–800 слов). Этот процесс называют чанкованием.
Затем каждый фрагмент преобразуется в векторное представление — последовательность чисел, которые кодируют смысл текста. Это делает специальная модель, которая называется embedding-моделью. Она берёт текст "Новый продукт компании выпущен в 2025 году" и превращает его в набор из нескольких сотен чисел, которые отражают смысл этого предложения.
Векторное представление — это не просто кодирование слов в числа. Это кодирование смысла. Два семантически похожих текста получат близкие векторы, даже если они написаны разными словами. Это база, на которой строится весь поиск.
Эти векторы загружаются в специальную базу данных, которая называется векторной БД. Её основная функция — найти вектор, наиболее похожий на вектор вашего запроса, быстро. В обычной базе данных вы выполняете запрос типа "найди все записи, где дата больше 2025", а в векторной БД вы выполняете запрос типа "найди десять фрагментов, которые наиболее близки к смыслу этого запроса".
Примеры векторных баз данных: Pinecone, Weaviate, Milvus, FAISS. Они спроектированы так, чтобы быстро находить похожие векторы среди миллионов других. Это тоже критично для производительности системы.
На этом этапе важно понимать одно: качество индексации определяет, вообще ли система найдёт нужную информацию. Если вы неправильно разбили документы на части, или выбрали плохую embedding-модель, или перегрузили векторную БД, то на следующих этапах ничего уже не спасёт. Система будет как человек, который ищет ответ в закрытой библиотеке.
Поиск: извлечение релевантных фрагментов
Пользователь задаёт вопрос: "Какие условия работы в нашей компании для молодых специалистов?"
На этом этапе происходит следующее. Вопрос пользователя преобразуется в вектор той же embedding-моделью, которая использовалась при индексации. Получается набор чисел, который кодирует смысл этого вопроса.
Затем система ищет в векторной БД фрагменты, векторы которых максимально близки к вектору вопроса. Близость вычисляется через специальные метрики, например косинусное сходство. Система находит, например, 10 или 50 наиболее похожих фрагментов.
Это отличается от классического текстового поиска, где вы ищете точное совпадение слова или фразы. Здесь поиск идёт по смыслу. Если в базе есть текст "Программа для молодежи включает стажировку и наставничество", система найдёт его даже если вы спросили иначе, потому что смыслы совпадают.
Преимущество очевидно, но есть нюанс. Иногда система находит фрагменты, которые формально похожи по смыслу, но не совсем релевантны вопросу. Например, на вопрос "Сколько отпуска положено молодым сотрудникам?" система может выдать фрагмент о пенсионном возрасте, потому что оба текста об условиях работы. Это называют ложными срабатываниями. На этот случай существует следующий этап.
Переранжирование: уточнение результатов
На предыдущем этапе система нашла примерно релевантные фрагменты. Теперь нужно отсортировать их по реальной релевантности вопросу.
Переранжирующая модель (reranker) берёт каждый из найденных фрагментов и вопрос и выдаёт оценку того, насколько хорошо этот фрагмент отвечает на вопрос. Оценка выставляется числом, например от 0 до 1.
Система сортирует фрагменты по этим оценкам и оставляет только лучшие. Если на первом этапе найдено 50 фрагментов, на этом этапе может остаться 3–5.
Переранжирование часто недооценивается компаниями, которые внедряют RAG. Они считают, что основная работа уже сделана на этапе поиска, но на практике переранжирование поднимает качество ответов на 30–50%. Это отдельное вложение в качество, которое даёт результат.
Модели для переранжирования часто используют другой подход, чем embedding-модели. Они работают с полным контекстом и могут лучше понять, действительно ли фрагмент отвечает на вопрос. Существуют специализированные модели: например, bge-reranker или rank-zephyr.
На этом этапе система уже имеет несколько высокорелевантных фрагментов. Это материал, который будет передан языковой модели. Но перед этим нужно этот материал правильно подготовить.
Формирование промпта с контекстом
Языковая модель получит не просто вопрос пользователя, а сложную конструкцию, которая называют промптом. Промпт состоит из нескольких частей.
Во-первых, в нём есть инструкция для модели. Что-то вроде: "Ты ассистент, который отвечает на вопросы на основе предоставленной информации. Если ты не знаешь ответ, скажи об этом, не придумывай."
Во-вторых, в промпте есть контекст — отобранные фрагменты из базы знаний. Они обычно обрамляются тегами, чтобы модель понимала, где начинается контекст и где он заканчивается.
В-третьих, в промпте есть сам вопрос пользователя.
Порядок расположения этих элементов не случаен. Исследования показывают, что модели лучше обрабатывают информацию, если важная часть находится либо в начале, либо в конце промпта. Информация в середине может быть пропущена. Это явление называют эффектом позиции. Поэтому часто контекст помещают в конец, прямо перед вопросом.
Также важно, сколько контекста вы добавляете. Слишком много информации может запутать модель, слишком мало — оставить её без нужных фактов. Обычно находят баланс: 3–7 релевантных фрагментов для большинства задач.
На этом этапе происходит подготовка текста, проверка длины, упорядочивание — ничего сложного, но всё это напрямую влияет на качество ответа.
Генерация ответа и контроль качества
Теперь языковая модель получает готовый промпт и начинает генерировать ответ. Модель видит контекст с фактами и вопрос, поэтому она работает из позиции знания, а не из памяти.
Этап генерации — это то, что видит пользователь. Модель выдаёт текст, структурированный и понятный. Но перед тем как показать ответ пользователю, RAG-система часто добавляет контроль качества.
Контроль может быть простым: проверка, использовала ли модель предоставленный контекст или снова начала галлюцинировать. Или более сложным: оценка логичности ответа, проверка соответствия источникам, проверка на противоречия внутри ответа.
Если контроль выявляет проблемы, система может повторно запустить процесс поиска с другими параметрами или вернуть модель к повторной генерации с дополнительными инструкциями.
Простой контроль — это проверка наличия ссылок на источники. RAG-система может отследить, из каких фрагментов модель взяла информацию, и показать пользователю, где найти оригинальный документ. Это повышает доверие к ответу и позволяет пользователю проверить информацию самостоятельно.
Архитектура и компоненты RAG
RAG-система — это не монолит, а набор компонентов, которые работают вместе. Понимание каждого компонента помогает понять, где искать проблемы и где есть место для оптимизации.
Источники данных и предобработка
RAG-система питается данными. Источники могут быть самыми разными. Компания может использовать pdf-документы, статьи из Confluence, письма из почты, базы данных, сайты конкурентов, социальные сети, внутренние базы знаний.
Каждый источник требует предобработки. Pdf может быть отсканированным и содержать таблицы — его нужно парсить специальными инструментами. Текст из веб-сайта может содержать html-теги — их нужно удалить. Письма содержат шумовые данные — подписи, форматирование, которые не несут смысловой нагрузки.
На этом этапе могут быть потеряны данные или введены ошибки. Если предобработка сделана плохо, система будет искать в мусоре вместо информации. Например, если pdf не распарсился корректно, таблица может превратиться в поток беспорядочного текста, и система не сможет найти в ней числовые данные.
Правильная предобработка требует понимания источников и часто требует ручной работы или написания специализированных парсеров.
Embedding-модели и векторная база данных
Embedding-модель — это сердце поиска. От её качества зависит, будет ли система вообще находить релевантные документы. Embedding-модель преобразует текст в числовое представление, которое кодирует его смысл.
Выбор embedding-модели критичен. Разные модели обучены на разных данных и работают с разной точностью для разных языков и областей. Модель, которая хороша для английского научного текста, может плохо работать с русским юридическим текстом.
Примеры популярных embedding-моделей: OpenAI text-embedding-3-small, Mistral Embed, multilingual-e5-large, BGE (BAAI General Embedding). Для русского языка часто используют BGE-m3, которая хорошо работает с многоязычными текстами.
Размер embedding-вектора тоже важен. Больший размер может улучшить качество, но требует больше памяти и вычислений. Обычно используют векторы размером 768 или 1536 чисел.
После того как созданы все векторы, они загружаются в векторную базу данных. Векторная БД оптимизирована для быстрого поиска похожих векторов. Классическая sql-база данных не подойдёт — она слишком медленная для этой задачи. Векторные БД используют специальные структуры данных (например, иерархические навигационные сети) для ускорения поиска.
Популярные векторные БД: Pinecone (облачный сервис), Weaviate (самохостируемая или облачная), Milvus (самохостируемая), FAISS (открытая библиотека для локального использования), Qdrant.
Ретривер и механизм поиска
Ретривер — это компонент, который берёт вопрос пользователя и извлекает из базы знаний релевантные фрагменты. На практике это функция, которая преобразует вопрос в вектор и ищет в векторной БД похожие векторы.
Ретривер может быть устроен по-разному. Самый простой — это семантический поиск, который работает только с векторами. Более сложный — гибридный поиск, который комбинирует векторный поиск с текстовым поиском по ключевым словам. Текстовый поиск хорош для поиска конкретных терминов (например, "апельсин"), а векторный хорош для поиска по смыслу (например, "цитрусовый фрукт").
Ретривер может быть многоступенчатым. Например, сначала система проводит текстовый поиск по ключевым словам, потом векторный поиск по оставшимся результатам, потом переранжирование.
Параметры ретривера тоже важны. Сколько фрагментов искать? Какой порог релевантности использовать? На каком расстоянии считать два вектора похожими? Все эти параметры влияют на результат.
Языковая модель (LLM)
Языковая модель — это компонент, который генерирует финальный ответ. Это может быть GPT-4, Claude, Llama, Mistral или любая другая большая языковая модель. Модель получает промпт с контекстом и вопросом и выдаёт текст.
Выбор модели влияет на качество ответа больше, чем может казаться. Разные модели имеют разные сильные стороны. Некоторые лучше работают с длинными контекстами, некоторые лучше структурируют ответы, некоторые меньше галлюцинируют.
Для корпоративного использования часто выбирают между облачными моделями (OpenAI, Anthropic, Google) и самохостируемыми (Llama, Mistral, Qwen). Облачные модели обычно качественнее, но требуют отправки данных на внешние серверы. Самохостируемые модели безопаснее для конфиденциальной информации, но требуют собственную инфраструктуру.
Размер модели тоже имеет значение. Большие модели (70+ миллиардов параметров) генерируют ответы получше, но медленнее и дороже. Маленькие модели (7–13 миллиардов параметров) быстрее, дешевле, но часто ошибаются. Для RAG часто выбирают компромисс: модели среднего размера, которые достаточно хороши, но не требуют огромных вычислительных ресурсов.
Параметры генерации модели тоже регулируются. Температура (от 0 до 1) влияет на креативность ответа. При температуре 0 модель выбирает наиболее вероятный ответ, при температуре 1 — более случайный. Для RAG обычно используют низкую температуру, потому что нужна предсказуемость.
Оркестрация и переранжирование
Оркестрация — это управление потоком данных между компонентами. Система должна знать, в каком порядке запускать каждый компонент, как передавать результаты одного в другой, как обрабатывать ошибки, как кэшировать результаты для ускорения.
На практике оркестрация часто реализуется через фреймворки. Вместо того чтобы писать весь код с нуля, разработчики используют готовые решения: LangChain, LlamaIndex (бывший GPT Index), Haystack. Эти фреймворки предоставляют готовые компоненты и управляют их взаимодействием.
Переранжирование — это отдельный компонент, который мы уже упоминали. Он берёт найденные при поиске фрагменты и переранжирует их по релевантности. Переранжирующая модель часто обучена специально на парах вопрос-документ, поэтому она лучше понимает релевантность, чем embedding-модель.
Переранжирование может быть одноступенчатым или многоступенчатым. Например, первое переранжирование отсеивает явно нерелевантные документы, второе уточняет порядок оставшихся. Это увеличивает качество, но требует дополнительных вычислений.
Векторный и гибридный поиск
Существует несколько стратегий поиска в RAG-системах. Каждая подходит для разных типов данных и запросов.
Векторный поиск работает только с семантикой. Вопрос и документы преобразуются в векторы, и система находит наиболее близкие векторы. Это отлично работает, когда нужно найти что-то по смыслу, даже если формулировка отличается. Например, "Как оформить отпуск?" и "Какой процесс оформления отпуска?" будут найдены по одним и тем же документам.
Но у векторного поиска есть ограничения. Если вопрос содержит конкретный термин, который должен быть в документе, векторный поиск может его не найти. Например, "Каков размер компенсации в Москве?" может не найти документ, где написано "Москва: 50 000 рублей", потому что векторное представление не захватывает точные совпадения.
Текстовый поиск ищет документы по точному совпадению слов или фраз. Это быстро и надёжно для точных терминов, но не работает с перефразировками. "Сумма компенсации" и "размер выплаты" для текстового поиска — разные вещи, хотя смысл один.
Гибридный поиск комбинирует оба подхода. Система одновременно проводит векторный поиск (по смыслу) и текстовый поиск (по ключевым словам), потом объединяет результаты и ранжирует их. Результат часто лучше, чем при использовании одного подхода.
На практике гибридный поиск даёт результаты на 20–40% точнее, чем чистый векторный или чистый текстовый поиск. Это особенно заметно на данных, которые смешивают точные данные (цифры, названия, даты) и описательный текст (статьи, объяснения, справочники).
Существуют и более продвинутые подходы. Например, графовый поиск, где документы связаны между собой в граф, и система может следовать по связям. Или поиск с переписыванием запроса, где система преобразует вопрос пользователя в несколько вспомогательных вопросов, которые могут помочь найти лучший контекст.
Чем RAG отличается от LLM и файнтюнинга
Эти три подхода часто путают, потому что все они используют языковые модели и направлены на то, чтобы модель давала лучшие ответы. Но механизм работы совершенно разный.
Базовая языковая модель (LLM) — это модель, которая обучена на большом корпусе текстов и может генерировать текст. У неё нет доступа к внешним данным. Она отвечает только из того, что знает. Если вы спросите GPT-4, какой курс доллара был вчера, она не сможет ответить, потому что её знания заканчиваются в апреле 2024.
RAG добавляет к модели способность искать и использовать внешние данные. Система ищет нужную информацию из ваших документов и передаёт её модели. Модель работает с этой информацией и генерирует ответ. RAG не изменяет модель, он изменяет входные данные для модели.
Файнтюнинг (fine-tuning) — это переобучение модели на специализированных данных. Вы берёте уже обученную модель и ещё немного обучаете её на данных, специфичных для вашей задачи. Это меняет сами веса модели, её внутреннее представление знаний.
Вот таблица, которая показывает различия:
| Аспект | LLM | RAG | Файнтюнинг |
|---|---|---|---|
| Доступ к новым данным | Нет | Да, через поиск | Во время обучения |
| Скорость внедрения | Мгновенная | Недели | Месяцы |
| Стоимость | API платежи | API + сервисы поиска | GPU для обучения |
| Контроль точности | Низкий | Высокий через поиск | Высокий через данные |
| Галлюцинации | Частые | Редкие | Зависит от данных |
| Актуальность данных | Статичная | Динамичная | Статичная |
На практике эти подходы часто комбинируют. Можно взять модель, провести файнтюнинг на специализированных данных, а потом добавить RAG для доступа к актуальным внешним данным. Это даёт лучший результат, чем любой подход по отдельности.
Для большинства компаний RAG — это первый выбор, потому что он быстрее внедряется, дешевле и проще обновляется. Файнтюнинг имеет смысл, если у вас очень специализированная задача и много данных для обучения.
Типы RAG по решаемым задачам
RAG-системы разрабатываются по-разному в зависимости от того, какую задачу нужно решить и как организованы данные.
По способу поиска
Мы уже говорили о векторном, текстовом и гибридном поиске. Это основная классификация. Но существуют и более специализированные подходы.
- Семантический поиск — поиск только по смыслу. Используется, когда данные в основном описательные: статьи, документы, описания.
- BM25 поиск — традиционный текстовый поиск, часто используется как основа для гибридного поиска.
- Лексический поиск — поиск с учётом морфологии и синонимии. Важен для русского языка, где слова могут иметь разные окончания.
- Переписывание запроса — система переформулирует вопрос пользователя в несколько вспомогательных вопросов для более полного поиска.
- Многошаговый поиск — система ищет поэтапно, используя результаты одного поиска для уточнения следующего.
По представлению знаний
Разные способы организации данных требуют разных подходов к RAG.
- Плоское хранилище — документы просто загружены в векторную БД без дополнительной структуры. Простое, но менее точное.
- Граф знаний — документы связаны между собой в граф (например, "документ A связан с документом B"). Позволяет следить по связям и находить контекст глубже.
- Иерархическое хранилище — документы организованы в структуру: категория → подкатегория → документ. Позволяет первым поиском найти нужную категорию, потом искать внутри.
- Гибридное хранилище — комбинация векторных данных и структурированной информации (таблицы, метаданные). Позволяет быстрее находить точные данные.
По логике обработки запроса
Как система обрабатывает вопрос пользователя:
- Одноступенчатая RAG — вопрос сразу ищется в базе знаний, результаты передаются модели. Быстро, но менее точно.
- Многоступенчатая RAG — система может делать несколько поисков, переранжировать результаты, собирать контекст из разных источников. Медленнее, но точнее.
- Адаптивная RAG — система сама решает, нужен ли ей поиск для этого вопроса. Если вопрос общий (например, "Привет, как дела?"), она отвечает из своего знания. Если специфичный, она ищет в базе.
- Агентная RAG — система может принимать решения о том, какие инструменты использовать (поиск, калькулятор, запрос к API) для ответа на вопрос.
По модели развёртывания
Где и как работает RAG-система:
- Облачная RAG — система работает на серверах облачного провайдера (AWS, Google Cloud, Azure). Масштабируемо, но данные за пределами компании.
- Локальная RAG — всё работает на сервере компании. Безопаснее для конфиденциальных данных, но требует собственной инфраструктуры.
- Гибридная RAG — часть компонентов в облаке, часть локально. Например, embedding-модель может быть локальной, а LLM облачной.
- Edge RAG — система работает на локальной машине пользователя. Полная приватность, но ограничена производительностью.
Практическое применение RAG
RAG используется в реальных компаниях для решения разных задач. Понимание, где и как его применяют, помогает представить, подойдёт ли он для вашей ситуации.
Корпоративные базы знаний
Компании накапливают огромное количество информации: документы, политики, процессы, FAQ, архивные письма. Раньше сотрудники искали нужное часами, перелопачивая папки и письма в почте. Теперь они просто спрашивают чат-бота.
RAG-система индексирует всю корпоративную базу знаний и позволяет находить информацию через естественный язык. "Как оформить отпуск?" — система найдёт в политике отпусков нужную информацию и объяснит. "Какой бюджет выделен на обучение для разработчиков?" — система найдёт в документах HR.
Результат: сотрудники работают быстрее, HR разгружается от повторяющихся вопросов, информация в компании становится более доступной. Даже у новых сотрудников, которые не знают, где искать информацию, теперь есть помощник.
Сложность: нужно убедиться, что информация в базе знаний актуальна и полна. Если система найдёт устаревшую политику, это будет хуже, чем если вообще ничего не найдёт.
Чат-боты и ИИ-консультанты
Это наиболее очевидное применение RAG. Чат-бот получает вопрос пользователя, ищет в базе знаний релевантную информацию и отвечает. Чат-боты работают в поддержке клиентов, на сайтах компаний, в мессенджерах.
RAG позволяет чат-боту быть информированным о продуктах компании, текущих акциях, политике возврата, способах доставки. Пользователь спрашивает "Могу ли я вернуть товар через месяц после покупки?", и чат-бот ищет информацию в политике возврата, находит "Возврат возможен в течение 30 дней", и отвечает точно.
На практике качество таких чат-ботов зависит от качества базы знаний. Если база содержит противоречивую или неполную информацию, чат-бот будет выдавать неправильные ответы. Компаниям часто приходится переделывать всю базу знаний, прежде чем запускать чат-бот.
Юридические и финансовые сценарии
В юридических и финансовых компаниях много документов, нормативных актов, прецедентов, которые нужно анализировать. RAG здесь особенно полезна.
Юридическая фирма может индексировать свою базу прецедентов и использовать RAG для поиска похожих судебных решений. Финансовая компания может индексировать финансовые отчёты, законодательные акты, аналитические материалы и быстро находить релевантную информацию для аналитики.
Риск: ошибка в юридическом или финансовом контексте может быть критичной. Система может найти похожий случай, но контекст может быть важен, и автоматический ответ может быть неправильным. Поэтому в этих сценариях RAG часто используется как помощник, а не как автономное решение. Эксперт проверяет рекомендации системы.
Поддержка клиентов
Служба поддержки часто отвечает на одни и те же вопросы: "Как установить приложение?", "Почему не работает функция X?", "Как активировать лицензию?". RAG может автоматизировать эту работу.
Компания индексирует FAQ, документацию, туториалы. Когда клиент пишет в поддержку, система сначала пытается ответить автоматически через RAG. Если уверенность высокая, отправляет ответ. Если низкая, перенаправляет к человеку.
Результат: 60–80% стандартных вопросов решается автоматически, сложные попадают к квалифицированному специалисту. Клиент получает ответ быстро, служба поддержки сосредоточивается на сложных задачах.
Как внедрить RAG: ключевые шаги
Теория — одно, практика — совсем другое. Внедрение RAG-системы в компании требует системного подхода и понимания того, где ошибаются большинство.
Подготовка данных
Это самый критичный и часто недооценённый этап. Данные — это топливо RAG-системы. Плохие данные приводят к плохим ответам, никакие алгоритмы это не исправят.
Подготовка начинается с аудита: какие данные у вас есть, где они хранятся, в каком состоянии. Обычно картина удручающая. Документы в разных форматах (PDF, Word, Google Docs), разной версификации, с ошибками, противоречиями, устаревшей информацией. Кто-то их писал давно, никто не поддерживал.
Следующий шаг — чистка и нормализация. Удалить дубликаты, исправить формат, убрать шумовые данные (подписи, форматирование, теги разметки). Удалить персональные данные, если нужно. Проверить актуальность информации — выбросить устаревшие документы или отметить их как архивные.
Затем — структурирование. Добавить метаданные: дата создания, автор, категория, версия, статус. Это поможет системе лучше понимать контекст документов и ранжировать результаты.
На этом этапе часто требуется ручная работа. Автоматизация может помочь, но контроль качества — ручной. Для большой компании это может занять недели или месяцы.
Выбор компонентов: embeddings, векторная БД, LLM
После того как данные готовы, нужно выбрать компоненты системы. Выбор должен быть обоснованным, исходя из ваших требований.
Для embedding-модели вопрос: облачная или локальная, какого размера, на каких языках. Если данные на русском, нужна модель, хорошо обученная на русском. Если данные смешанные (русский и английский), нужна многоязычная модель. Если данные очень специализированные (например, медицинская терминология), может понадобиться специализированная модель.
Для векторной БД: облачный сервис (Pinecone, Weaviate Cloud) или самохостируемый (Milvus, Qdrant, FAISS). Облачные проще запустить, не требуют администрирования, но дороже и требуют отправки данных на внешние серверы. Самохостируемые требуют инфраструктуры, но дешевле и безопаснее.
Для LLM: облачные API (OpenAI, Anthropic, Google) или самохостируемые модели (Llama, Mistral, Qwen). Облачные обычно качественнее, самохостируемые безопаснее для конфиденциальных данных. Цена может быть фактором: облачные API платят за каждый запрос, самохостируемые требуют единовременных инвестиций в серверы.
Часто компании начинают с облачными решениями (быстрее запустить), потом постепенно переходят на самохостируемые, если требования к приватности или масштабам растут.
Чанкование документов
Чанкование — это разбиение документов на небольшие части. Выбор размера чанка влияет на качество поиска.
Слишком маленькие чанки (100 токенов) — система может потерять контекст. "Сумма компенсации" может быть в одном чанке, а "в Москве" — в другом, и они не будут связаны.
Слишком большие чанки (2000 токенов) — система найдёт много шума вместе с нужной информацией. Пользователь попросил "размер премии", а система вернула весь раздел с информацией о зарплате, премиях, бонусах.
Обычно выбирают 512–1024 токенов с перекрытием (overlap). Перекрытие — это когда соседние чанки имеют общую часть, чтобы не потерять контекст на границах.
На практике размер может быть разным для разных типов документов. Для справочных материалов хорошо работает 512, для аналитических отчётов может быть 1024 или больше.
Частые ошибки при внедрении
Компании часто допускают одни и те же ошибки. Зная о них, вы можете избежать проблем.
- Игнорирование качества данных. Компания загружает в систему документы в беспорядке, с ошибками, и удивляется, почему система выдаёт мусор. На самом деле, система работает правильно, но с плохим входом.
- Выбор модели без тестирования. "Все используют GPT-4, значит и мы будем использовать." Но GPT-4 может быть избыточной для простых задач и дорогой. Нужно протестировать несколько вариантов на ваших данных.
- Отсутствие переранжирования. Компания думает, что поиск — это достаточно, но переранжирование может дать 30–50% улучшения качества. Это отдельное вложение, которое окупается.
- Неправильный выбор размера чанков. Компания выбирает слишком большие или слишком маленькие чанки и потом удивляется плохому качеству поиска. Размер нужно выбирать исходя из типа данных.
- Отсутствие контроля качества. Система запущена, но никто не мониторит качество ответов. Со временем качество деградирует (данные устаревают, модель дрейфует), но никто об этом не знает.
- Игнорирование приватности. Компания использует облачные сервисы и отправляет конфиденциальные данные на серверы провайдера. Потом обнаруживает, что это нарушает политику компании или регуляции.
- Переоценка возможностей. Компания думает, что RAG решит все проблемы, но RAG — это инструмент для определённых задач. Для других задач подходят другие подходы.
Оценка качества RAG
После внедрения нужно оценивать качество. Иначе вы не будете знать, работает ли система, и где её улучшать.
Есть несколько метрик для оценки качества RAG.
Recall — доля релевантных документов, которые система нашла из всех релевантных документов в базе. Если в базе есть 10 документов, релевантных вопросу, а система нашла 8, recall = 0.8. Высокий recall означает, что система не пропускает важные документы.
Precision — доля релевантных документов из всех найденных. Если система нашла 10 документов, из которых 8 релевантны, precision = 0.8. Высокий precision означает, что система не выдаёт много мусора.
MRR (Mean Reciprocal Rank) — средняя позиция первого релевантного документа. Если релевантный документ на позиции 2, MRR = 0.5. Если на позиции 1, MRR = 1. Чем выше, тем лучше система ранжирует результаты.
NDCG (Normalized Discounted Cumulative Gain) — метрика, которая учитывает релевантность документов и их позицию в результатах. Документы в начале списка имеют больший вес. Это более сложная метрика, но она лучше отражает восприятие пользователя.
На практике часто используют комбинацию метрик. Также важна оценка качества финальных ответов, а не только поиска. Ответ может быть построен на релевантных документах, но быть неправильным или неполным из-за ошибки языковой модели.
Для оценки качества ответов используют:
- Ручную оценку эксперта (дорого, но точно).
- А/B тестирование (сравнение двух версий системы в реальной эксплуатации).
- Автоматические метрики вроде BLEU или ROUGE (дёшево, но не всегда точно).
- Обратную связь от пользователей (нравятся ли им ответы, помогли ли они).
Качество RAG-системы улучшается итеративно. Первая версия редко бывает идеальной. Нужно собирать данные о том, какие запросы не работают, какие документы система не находит, и постепенно улучшать систему.
Преимущества и ограничения RAG
RAG — мощный инструмент, но не панацея. Важно понимать, что он даёт и что он не может дать.
Преимущества RAG:
- Точность и релевантность. Система работает с фактами, которые вы ей дали, а не со своей памятью.
- Актуальность. Вы можете добавлять новые документы в базу, и система сразу начнёт их использовать.
- Прозрачность. Система может показать, из каких документов она взяла информацию для ответа.
- Контроль. Вы контролируете, какие данные система видит, и можете исключить неправильную информацию.
- Затраты. RAG дешевле, чем переобучение модели, и быстрее внедряется.
- Снижение галлюцинаций. Система меньше выдумывает, потому что опирается на факты.
Ограничения RAG:
- Зависимость от качества данных. Если в базе нет правильной информации, система не может её найти.
- Поиск может быть неточным. Система может не найти релевантный документ или найти нерелевантный.
- Языковая модель может ошибиться. Даже если система найдёт правильный контекст, модель может неправильно его интерпретировать.
- Производительность. Процесс поиска требует времени. На сложные запросы система может ответить медленнее, чем базовая LLM.
- Стоимость. Если вы используете облачные сервисы, каждый поиск и генерация ответа требует деньги.
- Контекстные ограничения. Если контекст слишком большой, модель может потеряться и выдать неправильный ответ.
- RAG не решает все задачи. Для рассуждений, творчества, обобщения информации из множества источников иногда нужны другие подходы.
Локальная RAG-система
Локальная RAG-система работает полностью на сервере компании или даже на локальной машине. Это отличается от облачной, где компоненты разбросаны по разным сервисам.
Преимущества локальной RAG:
- Приватность. Данные не уходят на внешние серверы, остаются в полном контроле компании.
- Регуляция. Компания может соответствовать требованиям типа GDPR, где данные должны оставаться в определённом регионе.
- Стоимость. Нет платежей за API, только единовременная инвестиция в инфраструктуру.
- Скорость. Нет задержек на передачу данных на внешние серверы.
- Контроль. Компания может настраивать все параметры без ограничений провайдера.
Недостатки локальной RAG:
- Сложность. Нужно администрировать серверы, следить за обновлениями, решать проблемы.
- Инфраструктура. Нужны мощные серверы, особенно если используете большие модели.
- Экспертиза. Нужны люди, которые понимают, как это всё работает и как поддерживать.
- Масштабируемость. Если нагрузка растёт, нужно добавлять серверы, что требует инвестиций.
На практике компании часто начинают с облачной RAG, потом переходят на гибридную (часть облачная, часть локальная), потом полностью локальную по мере роста требований к приватности и масштабам.
Инструменты для локальной RAG: Ollama (простой способ запустить локальную модель), LocalAI (локальный API совместимый с OpenAI), Llamaindex (фреймворк для RAG), Haystack (фреймворк для поиска и RAG).
Когда RAG не подходит
RAG — отличный инструмент, но он не универсален. Есть задачи, где RAG не подходит или неэффективен.
RAG не подходит, когда:
- Задача требует рассуждений и анализа. RAG хорош для поиска и передачи информации, но не для глубокого анализа или логических выводов. Если нужно "проанализируйте эту ситуацию и дайте рекомендацию", RAG может помочь, но потребуется больше обработки.
- Нет хорошей базы данных. Если у вас нет надёжных данных для индексирования, RAG не поможет. Мусор в, мусор из.
- Задача требует работы с числами и расчётами. Языковые модели плохо работают с математикой. Если нужно выполнить сложный расчёт, лучше использовать инструменты или API, которые могут это сделать.
- Нужна реальная инновация или творчество. RAG работает с существующими данными. Если нужно придумать что-то новое, RAG не поможет.
- Требуется очень низкая латентность. Процесс поиска требует времени. Если ответ нужен за миллисекунды, RAG может быть слишком медленным.
- Данные очень динамичные и быстро меняются. Если вам нужны ответы в реальном времени на основе данных, которые обновляются каждую секунду, RAG может отстать.
- Задача требует знаний, которых нет в вашей базе. RAG может найти только то, что там есть. Если информация отсутствует, система не поможет.
В этих случаях лучше использовать другие подходы: файнтюнинг, если нужна специализация; инструменты и API для интеграции функционала; агентные системы, которые могут принимать решения и использовать несколько инструментов; классические методы поиска и анализа для специальных случаев.
Частые вопросы о RAG
Можно ли использовать RAG без языковой модели?
Технически да, но это будет не совсем RAG. Вы можете использовать поиск и возвращать найденные документы пользователю. Но основная идея RAG — использовать модель для генерации ответа на основе найденного контекста. Без модели это просто поиск.
Какая модель лучше всего подходит для RAG?
Для большинства задач хороши модели среднего размера (13–70 миллиардов параметров), которые достаточно умные, но быстрые. GPT-4 работает хорошо, но дорого. Llama 2 70B, Mistral Large, Claude работают хорошо по соотношению качества и цены. Для конфиденциальных данных — локальные модели вроде Llama или Mistral.
Сколько времени занимает внедрение RAG?
Для простого прототипа — несколько дней. Для производственной системы с хорошей базой знаний — недели или месяцы, в зависимости от объёма данных и сложности требований. Большая часть времени уходит на подготовку данных, а не на саму систему.
Сколько стоит RAG?
Зависит от выбранных компонентов. Облачная RAG может стоить от нескольких сотен рублей в месяц для маленьких объёмов до десятков тысяч для больших. Локальная RAG требует инвестиций в серверы, но потом стоит меньше в операции.
Есть ли риски безопасности в RAG?
Да. Если использовать облачные сервисы, данные отправляются на внешние серверы. Если базу знаний может редактировать кто угодно, злоумышленник может добавить вредоносные данные, которые система будет передавать пользователям. Нужны правильные контроли доступа и аудит.
Может ли RAG полностью исключить галлюцинации?
Нет, но может их значительно снизить. Модель может ошибиться даже в интерпретации правильного контекста. Полностью исключить галлюцинации нельзя, но RAG снижает их с 30–50% до 5–10% на хорошо подготовленных данных.
RAG — это не будущее, это настоящее. Компании уже используют его для реальной работы. Если вы только планируете внедрение, лучше начать с небольшого пилота, научиться на своих ошибках, потом расширяться. Главное — помнить, что система только так хороша, как хороши ваши данные и как правильно вы выстроили процесс.
RAG изменит то, как компании работают с информацией. Вместо поиска по ключевым словам и листания результатов люди будут задавать вопросы и получать готовые ответы. Это не исключит необходимость в экспертах, но поднимет производительность всех остальных. Компании, которые рано поймут это и внедрят RAG правильно, получат конкурентное преимущество. Те, кто будет ждать, отстанут.
