RAG: что это простыми словами и как работает поиск для ИИ

RAG — короткий ответ

RAG расшифровывается как retrieval-augmented generation: «генерация с дополнением из поиска». Это архитектура приложения, а не особая модель. Приложение получает вопрос, находит относящиеся к нему материалы и кладёт найденные фрагменты в запрос к языковой модели. Затем модель составляет ответ, опираясь на эти фрагменты. Так можно отвечать по внутренним документам, которых не было в обучении модели.

В схеме есть два независимых места для ошибки. Поиск может не найти нужный документ или выбрать старую редакцию. Генерация может исказить даже правильный фрагмент: перепутать условие, округлить число или добавить вывод, которого там нет. Поэтому «ответ со ссылкой» означает только то, что система показала ссылку; пользователь должен открыть фрагмент и проверить, подтверждает ли он фразу.

Для аналитика RAG особенно полезен при поиске определений метрик, владельцев таблиц, истории изменений, описаний полей и правил отчётности. Для суммы заказов за месяц нужен запрос к базе с заданной формулой. Документ может подсказать формулу, но не заменить выполнение запроса на актуальных строках.

Как работает RAG шаг за шагом

До первого вопроса документы собирают из разрешённых источников: базы знаний, договоров, инструкций, описаний витрин. Их разбивают на пригодные для поиска фрагменты и связывают с метаданными — названием, ссылкой, датой версии и правами. Для короткой статьи достаточно нескольких абзацев, для длинного регламента важна граница: условие в одном разделе нельзя отрывать от исключения в следующем.

Когда приходит вопрос, поисковый слой выбирает фрагменты. Это может быть полнотекстовый поиск по словам, поиск по смысловому представлению текста или их сочетание. Затем приложение передаёт вопрос и отобранные фрагменты модели. В хорошей реализации ответ содержит указание на конкретный документ и место в нём, а при отсутствии подходящего материала система разрешает сказать «не нашёл оснований».

После ответа у аналитика остаётся отдельная проверка: совпадают ли формулировка, дата и область действия со спецификацией. Если вопрос был не об определении, а о текущем значении метрики, добавляется вычисление в базе. Простая цепочка «нашёл определение → написал SQL → выполнил → сверил» надёжнее попытки добыть число из текста документа.

Пример: словарь метрик продуктовой команды

Представьте три карточки словаря. Карточка «Активность, черновик» определяет активного пользователя как вошедшего в приложение. Действующая карточка «Активность, версия 2» требует ещё одно целевое событие. Третья карточка описывает рекламную активность за другой период. Вопрос менеджера короткий, поэтому поиск легко поднимет первую карточку — текст буквально совпадает со словом «активный».

Здесь нужны не более убедительные формулировки модели, а фильтр по статусу и версии документа. Ответ должен назвать действующее правило, период, исключения и адрес карточки. Если найден только черновик, система должна обозначить его как черновик и не объявлять корпоративным стандартом. Простой поиск по точному названию может сработать лучше сложного семантического слоя, если метрики имеют устойчивые имена и коды.

Теперь менеджер спрашивает: «Сколько активных пользователей было вчера?» RAG даёт определение и, возможно, имя витрины; реальное количество появляется только после чтения данных с правильной временной зоной и фильтром событий. Число, написанное рядом с определением в старой презентации, не становится значением за вчера. Это ключевая граница между поиском знаний и аналитическим расчётом.

Нужна ли векторная база

Не всегда. Для небольшой коллекции документов можно начать с обычного полнотекстового поиска: он хорошо ловит точные названия полей, коды ошибок и номера регламентов. Векторный поиск помогает, когда вопрос и документ описывают одно и то же разными словами. Например, пользователь спрашивает про «первую полезную сессию», а регламент говорит об «активации после регистрации». Но сходство формулировок не гарантирует, что найденный фрагмент верен по дате и правам.

Гибридный поиск запускает текстовую и векторную части, затем объединяет кандидатов. Microsoft описывает такой механизм в Azure AI Search. Для аналитика практическое решение проще технологического спора: соберите типовые вопросы, посмотрите, находит ли поиск действующий первоисточник, и только после этого выбирайте индекс. Иногда проблема в плохих названиях документов и дубликатах, а не в отсутствии embeddings.

Минимальный прототип может искать в утверждённых документах и отдавать несколько фрагментов с ссылками. Масштабирование появляется, когда документов становится много, версии меняются часто, а права отличаются по командам. Название технологии хранения не заменяет правил публикации, снятия с действия и удаления документов из индекса.

Чем RAG отличается от поиска, длинного промпта и дообучения

Поиск возвращает документы или фрагменты. RAG добавляет к этому сформулированный моделью ответ. Это удобно, если надо сопоставить несколько разделов и изложить правило простыми словами. Но поисковую выдачу всё равно стоит показывать: когда решение зависит от точной формулировки договора, сверка с первоисточником важнее гладкого пересказа.

Вставить документы целиком в промпт можно для разовой задачи с малым, заранее известным набором. Когда источников много и они обновляются, поиск выбирает релевантное на каждый вопрос. Дообучение меняет поведение модели на примерах; оно не служит надёжным механизмом обновления меняющихся фактов. RAG подаёт материал во время запроса, поэтому новую утверждённую версию можно включить в индекс без переобучения базовой модели.

Доступ к SQL или API решает другую задачу: получить текущие строки и вычислить результат. В рабочих системах эти способы часто соседствуют. Агент ищет описание поля в RAG, строит запрос к базе с ограниченными правами и объясняет полученную таблицу. Проверять нужно и извлечённый документ, и запрос, и интерпретацию.

Почему найденный источник не делает ответ истинным

Первый сбой — промах поиска. В базе знаний есть действующая инструкция, но её название неожиданное, а индекс поднял презентацию двухлетней давности. Модель аккуратно цитирует найденное и всё же отвечает неверно. Последствие — команда использует старую формулу в отчёте. Лечится это тестом на реальные вопросы и управлением версиями, а не просьбой модели «будь точной».

Второй сбой — потерянный контекст. Поиск вернул абзац «оплата считается по дате создания заказа», а следующий абзац содержит исключение для отмен. Если фрагмент обрезан, модель может описать неполную формулу. Третий — ложная ссылка: указанная карточка существует, но фраза ответа в ней не подтверждается. Открывайте источник по конкретному утверждению, а не оценивайте одно только наличие ссылки.

Четвёртый сбой — права доступа. Индекс создан из документов нескольких команд и по ошибке отдаёт закрытый финансовый регламент любому сотруднику. Проверка доступа должна выполняться до передачи фрагмента модели и при показе ссылки. Пятый — содержимое документа само может быть вредоносной инструкцией для модели; найденный текст остаётся данными, а не новой командой системы.

Как проверить небольшой RAG-пилот

Соберите вопросы, на которые в действующих документах действительно есть ответ: определения метрик, владельцы витрин, даты вступления правил. Рядом для каждого вопроса сохраните правильный документ и фрагмент. Добавьте вопросы без ответа, старые версии и документы другой команды. Нельзя оценивать систему только на удобных примерах, где название вопроса совпадает с заголовком.

Сначала смотрите, поднял ли поиск нужный материал. Если нет, переписывание промпта не поможет: модель не видела факт. Затем проверяйте ответ по строкам: каждая существенная фраза подтверждается найденным фрагментом? Последний шаг — пользовательская задача: помог ли ответ принять верное решение или написать правильный запрос. Эти три проверки разделяют ошибку поиска, генерации и использования.

Подробные меры качества поиска, включая Recall@k, MRR, groundedness и abstain, уже разобраны в отдельном материале. Для первой итерации достаточно таблицы вопросов, эталонных источников и явной пометки «не нашёл». Если система не умеет признать отсутствие основания, пилот может выглядеть успешным лишь потому, что на каждый вопрос выдаёт красивый ответ.

Проверка версий: что делать при противоречии

Допустим, поиск нашёл два документа: свежий «Словарь метрик» и старый «План релиза». В обоих есть определение активации, но числитель различается. Система не должна скрывать конфликт за одним гладким ответом. Покажите пользователю оба фрагмента, даты и статус редакций. Если только один документ утверждён владельцем метрики, ответ опирается на него и помечает старый как исторический.

Если статус не указан, честный ответ — «в источниках два определения; актуальное не установлено». Такой отказ лучше, чем произвольный выбор по позиции в поисковой выдаче. Владелец метрики должен решить конфликт, а после этого индекс следует обновить или снять старую страницу с поиска. Иначе следующему пользователю модель снова предложит тот же спор.

Этот случай проверяйте отдельным тестом пилота. В наборе вопросов заранее отметьте ожидаемую версию и признак, по которому её можно узнать: дата действия, утверждение владельца или ссылка из текущего каталога. После смены правила запустите тот же вопрос повторно. Если система продолжает давать старый ответ, проблема в индексе или фильтрах, а не в тоне формулировки модели.

Чек-лист перед ответом из документов

Проверьте, какую задачу решаете: объяснить правило, найти документ или посчитать свежую метрику. Для первых двух достаточно поиска и цитирования; для последней нужен расчёт. Зафиксируйте редакцию источника и период действия. Если документы противоречат друг другу, не просите модель выбрать «наиболее вероятный» — уточните владельца правила.

Убедитесь, что поиск соблюдает доступ пользователя и не передаёт закрытый фрагмент в модель. Откройте цитату: она должна подтверждать именно то предложение, возле которого стоит. Для важного решения сохраните вопрос, найденный фрагмент, дату версии и ответ. При отсутствии документа предпочтите «не найдено», а не собранное из памяти модели объяснение.

• Задача — знание из документа или вычисление из данных?
• Найден действующий документ с правильными правами?
• Показан конкретный фрагмент, который подтверждает ответ?
• Учтены исключения, период действия и конфликтующие версии?
• Есть честный ответ на вопрос без источника?

Частые вопросы

Что такое RAG простыми словами? Это схема «найти материал → дать его модели → составить ответ». Она помогает отвечать по внешней базе знаний, но не гарантирует, что поиск и пересказ окажутся верными.

RAG и ChatGPT — одно и то же? Нет. ChatGPT — продукт для взаимодействия с моделями, а RAG — архитектурный приём. Его можно встроить в разные приложения и модели.

Можно ли сделать RAG без векторной базы? Да. Поиск может быть текстовым, семантическим, векторным или гибридным. Выбор зависит от документов и вопросов, а не от модного названия хранилища.

Убирает ли RAG галлюцинации? Он даёт модели опору в найденном тексте, но не отменяет ошибок поиска, устаревших документов и неверной интерпретации.

Что делать дальше

Для проверки идеи не нужен сразу большой каталог документов. Возьмите утверждённый словарь метрик одной команды, несколько конфликтующих редакций и десять настоящих вопросов коллег. Если система находит действующий источник, честно отказывается при его отсутствии и помогает написать верный запрос, расширяйте коллекцию. Если нет — исправляйте документы и поиск до подключения новых инструментов.

Параллельно проверьте, какой ответ нужен менеджеру: определение или значение метрики. Если второе, переходите от RAG к запросу, который можно выполнить и сверить. Наш эксперимент по анализу данных показывает, почему число, произнесённое моделью без вычисления, нельзя сразу ставить в отчёт.