Генерация с дополнением извлечённой информацией (Retrieval-Augmented Generation, RAG) — это архитектура, которую чаще всего используют промышленные ИИ-приложения, когда нужно отвечать на вопросы на основе частных или часто обновляемых данных. В этом руководстве мы разберём, что такое RAG, когда он побеждает тонкую настройку (и когда нет), как работает каждый этап конвейера и какие ошибки сбивают команды с пути между прототипом и продакшеном. К концу статьи у вас будет конкретная мысленная модель каждой движущейся части, а также умение заранее определить, в каком месте система с наибольшей вероятностью сломается.
Что на самом деле представляет собой генерация с дополнением извлечённой информацией
Если говорить просто, RAG разбивает обработку запроса на две фазы: извлечь релевантный контекст из внешнего хранилища знаний, а затем сгенерировать ответ с помощью LLM, опираясь на этот контекст. LLM не нужно запоминать ваши проприетарные данные — она читает их в момент инференса, точно так же, как аналитик открывает документ, прежде чем написать отчёт. Термин ввели Lewis et al. (2020) и показали, что такой подход существенно снижает уровень галлюцинаций в задачах, требующих интенсивной работы со знаниями.
Почему это важно для частных данных
Универсальная LLM ничего не знает о ваших внутренних контрактах, о вашем каталоге товаров по состоянию на прошлый вторник или о тикетах вашей службы поддержки. Тонкая настройка (fine-tuning) может частично внедрить эти знания, но модель всё равно галлюцинирует на фактах, которые редко встречались в обучении, и её нужно дообучать заново при каждом изменении данных. RAG обходит обе проблемы, сохраняя знания во внешнем хранилище и поддерживая их в актуальном состоянии.
Основной цикл
Пользователь отправляет запрос. Ваша система превращает этот запрос в вектор эмбеддинга и ищет в векторном хранилище top-k наиболее семантически похожих чанков. Эти чанки подставляются в промпт вместе с исходным запросом. LLM формирует ответ, опираясь на извлечённый текст. Вот и весь цикл — любая сложность промышленной системы представляет собой уточнение одного из этих четырёх шагов.
RAG или тонкая настройка: как выбрать подходящий инструмент
Это вопрос, над которым команды чаще всего ломают голову, и честный ответ таков: они решают разные задачи. Тонкая настройка меняет то, как модель рассуждает и отвечает — её стиль, профессиональную лексику, формат вывода. RAG меняет то, какие факты доступны модели в момент инференса. Они не взаимозаменяемы; многие зрелые системы используют оба подхода.
Когда побеждает RAG
Используйте RAG, когда ваша база знаний часто меняется (еженедельные обновления продуктов, новые юридические документы, развивающаяся база поддержки). Используйте его, когда вам нужны цитаты — RAG может возвращать исходные чанки вместе с ответом, делая систему проверяемой. Используйте его, когда объём данных большой и разнородный: векторное хранилище масштабируется до миллионов документов гораздо дешевле, чем повторные сеансы тонкой настройки. Такие инструменты, как IngestAI, созданы именно для такого сценария, позволяя корпоративным командам подключать RAG-конвейеры к существующим репозиториям документов без необходимости строить инфраструктуру с нуля.
Когда побеждает тонкая настройка
Тонкая настройка лучше, когда нужно, чтобы модель надёжно придерживалась определённой выходной схемы, бегло говорила на техническом диалекте или следовала предметно-специфическим шаблонам рассуждений. Ассистент медицинского кодирования, который должен выдавать коды ICD-10 в точном структурированном формате, выиграет от тонкой настройки. Бот поддержки клиентов, которому нужно отвечать на вопросы из 50 000-страничной базы знаний, обновляемой ежедневно, — нет, это задача для RAG.
Собираем RAG-конвейер: этап за этапом
Большинство отказов промышленных RAG-систем — это отказы конвейера, а не модели. Посредственная LLM с хорошо извлечённым контекстом бьёт передовую LLM, которой скормили мусорные чанки. Вкладывайте инженерное время в извлечение.
Чанкинг: недооценённый фундамент
Чанкинг — это способ разбить исходные документы на фрагменты, достаточно маленькие, чтобы осмысленно встраиваться в эмбеддинг, но достаточно большие, чтобы нести связный контекст. Чанкинг фиксированного размера (например, 512 токенов с перекрытием 50 токенов) — отправная точка, но он плохо работает на стыках разделов. Семантический чанкинг — разбиение по абзацам, по структуре заголовков или с определением границ предложений — лучше сохраняет смысл. Для структурированных документов, таких как PDF и электронные таблицы, стоит рассмотреть инструменты вроде Anara, который обеспечивает мультиформатный приём документов с учётом вёрстки. Практическое правило: размер чанка должен примерно соответствовать гранулярности самостоятельного факта или аргумента в вашем корпусе.
Эмбеддинги: превращаем текст в поиск
Модель эмбеддингов превращает каждый чанк (и каждый запрос) в плотный вектор. Семантическое сходство между запросом и чанком становится вычислением расстояния в этом векторном пространстве. Лидерборд MTEB — стандартный источник для сравнения моделей эмбеддингов на бенчмарках извлечения. OpenAI text-embedding-3-large, Cohere Embed v3 и модели с открытыми весами вроде bge-large-en-v1.5 — все показывают хорошие результаты в зависимости от ваших ограничений по задержке и стоимости. Важно: используйте одну и ту же модель эмбеддингов при индексировании и при обработке запросов — несоответствие молча ломает поиск.
Векторные хранилища: где живёт индекс
Векторное хранилище хранит ваши эмбеддинги и быстро обслуживает запросы приблизительного поиска ближайших соседей (ANN). Pinecone, Weaviate, Qdrant, pgvector и ChromaDB — самые распространённые варианты. Для небольших корпусов — до нескольких сотен тысяч чанков — часто достаточно pgvector на существующем инстансе Postgres, и это позволяет избежать операционных накладных расходов. В больших масштабах выделенные векторные базы данных с индексами HNSW и поддержкой фильтрации оправдывают свою сложность. Всегда храните исходный текст чанка рядом с эмбеддингом — он вам понадобится для сборки финального промпта.
Реранжирование: переоценка извлечённого набора
ANN-поиск возвращает кандидатов быстро, но неточно. Реранкер — обычно модель-кросс-энкодер вроде Cohere Rerank или файнтюненная разновидность BERT — тщательнее оценивает каждый извлечённый чанк относительно запроса и переупорядочивает набор. Этот двухэтапный подход (быстрое ANN-извлечение и медленное кросс-энкодерное реранжирование) стабильно превосходит одноэтапное извлечение в продакшене. Прирост качества особенно заметен на длинных и нюансированных запросах. Реранжирование добавляет задержку (обычно 30–100 мс), но улучшение качества оправдывает это для большинства клиентских приложений.
Синтез ответа LLM: превращаем контекст в ответы
Финальный этап — построение промпта и генерация. Передайте top-k реранжированных чанков как контекст, добавьте запрос пользователя и явные инструкции о том, как действовать в случае, если контекста недостаточно — «если ответа нет в предоставленных документах, так и скажи» — это не опционально, это несущая конструкция. Длина промпта имеет значение: если вы впихнёте 20 чанков в контекстное окно на 128k, LLM всё равно может пропустить факты, зарытые в середине, из-за эффекта lost-in-the-middle, описанного в работе Liu et al. (2023). Три–пять высокорелевантных чанков часто оказываются лучше, чем двадцать слаборелевантных.
Распространённые подводные камни, которые убивают промышленный RAG
Прототип RAG собрать легко. Промышленный RAG — это место, где предположения рушатся. Вот типичные режимы отказа, которые повторяются снова и снова.
Несоответствие запроса и документа
Эмбеддинги обучаются на определённом распределении текста. Если ваши документы высокотехничные, а пользователи задают разговорные вопросы (или наоборот), пространство эмбеддингов может плохо перекрывать разрыв. HyDE (Hypothetical Document Embeddings) — сначала сгенерировать гипотетический ответ, затем встроить его — это одно из средств. Расширение запроса с помощью LLM, которая переформулирует вопрос в несколько вариантов, — другое. Оба подхода добавляют задержку и сложность, поэтому сначала замерьте, действительно ли извлечение — ваше узкое место, прежде чем добавлять любое из этих решений.
Устаревшие индексы
Документы обновляются. Если ваш конвейер индексирования не отслеживает версии документов и не перевстраивает изменившиеся чанки, векторное хранилище расходится с источником истины. Заложите обнаружение изменений на уровне документов (сравнение хешей, вебхуки или запланированные диффы) в конвейер с самого первого дня. Надстраивать это после запуска — мучительно. Именно здесь инструменты управления документами на основе ИИ, такие как те, что мы собрали в обзоре лучших ИИ-инструментов для управления документами, могут взять на себя приём и версионирование как сервис, а не как собственную разработку.
Игнорирование оценки извлечения
Команды оценивают свою RAG-систему целиком (выглядит ли финальный ответ правильным?), никогда не измеряя качество извлечения отдельно. Это делает отладку невозможной. Соберите набор для оценки извлечения: вопросы с известными релевантными чанками. Измерьте recall@k и средний обратный ранг до запуска. Если качество извлечения низкое, никакая инженерия промптов на этапе синтеза это не исправит.
Слишком мелкий и слишком крупный чанкинг
Слишком маленькие чанки отрезают окружающий контекст, который придаёт факту смысл. Слишком большие размывают сигнал эмбеддинга и раздувают промпт. Универсального правильного размера чанка не существует — он зависит от структуры ваших документов. Проводите офлайн-эксперименты на вашем реальном корпусе, а не копируйте значения по умолчанию из туториала, написанного для другого набора данных.
Безопасность и утечка данных
В мультитенантных системах запрос пользователя должен извлекать только те документы, к которым у него есть доступ. Метаданные-фильтры векторного хранилища — стандартный механизм: каждый чанк должен нести тег арендатора или разрешения, а каждый запрос — содержать условие фильтрации. Если не обеспечить это на уровне извлечения, атака с инъекцией промпта или вредоносный запрос могут вытащить чужие частные данные. Это не гипотетический крайний случай — это задокументированный класс атак. Если вы строите промышленные приложения со встроенным ИИ и нуждаетесь в надёжных паттернах контроля доступа, обзор Retool AI рассказывает, как корпоративные платформы приложений управляют разрешениями вокруг ИИ-компонентов.
Сквозная оценка RAG-системы
Оценка — это область, в которой большинство команд недоинвестируют. Полезный фреймворк разбивает качество на три составляющие: точность извлечения (нашли ли мы правильные чанки?), точность ответа (опирается ли сгенерированный ответ на извлечённый контекст, а не галлюцинирует?) и релевантность ответа (действительно ли он отвечает на вопрос пользователя?). Фреймворки вроде RAGAS дают автоматические метрики для всех трёх. Человеческая оценка по-прежнему необходима, чтобы ловить режимы отказа, которые автоматические метрики пропускают, — особенно тон, полноту и крайние случаи в технических предметных областях.
Создаём эталонный тестовый набор
Начните с 50–100 пар «вопрос-ответ», покрывающих ваши основные сценарии использования. Включите состязательные примеры: вопросы, ответы на которые отсутствуют в корпусе (система должна воздержаться), вопросы, охватывающие несколько документов (система должна синтезировать), и неоднозначные запросы. Тестовый набор такого размера ловит большинство регрессий без большого бюджета на разметку. Расширяйте его со временем за счёт реальных пользовательских запросов, помеченных для проверки. Инструменты для ведения заметок и управления знаниями — см. наш обзор лучших ИИ-инструментов для заметок и знаний — помогают командам организовывать и аннотировать оценочные наборы данных без создания собственного внутреннего инструмента.
Архитектурные паттерны, которые стоит знать
Помимо базового конвейера, в серьёзных промышленных системах стали стандартными несколько паттернов.
Гибридный поиск
Чисто векторный поиск пропускает точные совпадения по ключевым словам, с которыми хорошо справляется BM25 (разреженное извлечение). Гибридный поиск запускает оба подхода параллельно и объединяет результаты с помощью reciprocal rank fusion. Комбинация стабильно превосходит каждый из подходов по отдельности, особенно на предметно-специфических запросах с названиями продуктов, кодами или именами собственными.
Агентный RAG
В агентных схемах LLM решает, нужно ли извлечение, какие запросы отправлять и достаточно ли извлечённого контекста или требуется дополнительный шаг извлечения. Это справляется с многошаговыми вопросами вроде «что наш контракт говорил о штрафных оговорках и как это соотносится с отраслевым стандартом?», на которые одношаговое извлечение не может ответить чисто. Цена — задержка и сложность. Агентный RAG стоит вкладывать в задачи, требующие интенсивного рассуждения; для простых вопросов-ответов это избыточно.
Кеширование
Семантическое кеширование сохраняет недавние пары «запрос-ответ» и возвращает кешированные результаты для семантически похожих входящих запросов. Это резко снижает задержку и стоимость в высоконагруженных системах, где многие пользователи задают эквивалентные вопросы. Реализуйте его как слой перед конвейером извлечения, а не после — нужно пропускать весь конвейер при попадании в кеш.
Генерация с дополнением извлечённой информацией прошла путь от исследовательского любопытства до обязательного стандарта для любого ИИ-приложения, которому нужно надёжно работать с частными или динамичными данными. Конвейер поддаётся изучению, инструменты зрелые, режимы отказов хорошо задокументированы — а значит, бо́льшая часть тяжёлой работы теперь связана с инженерной дисциплиной, а не с исследовательскими новинками. Сделайте чанкинг правильно, оценивайте извлечение независимо, обеспечьте контроль доступа на уровне векторного слоя — и вы избежите ошибок, которые отправляют большинство команд обратно к чертёжной доске после запуска.
