RAG простыми словами: как AI отвечает по вашим документам

RAG простыми словами: ответ, который начинается с ваших документов

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

Ключевое слово — выбранные. RAG не делает каждый файл компании автоматически истинным, актуальным и доступным любому сотруднику. Сначала система ищет небольшой набор разрешённых и релевантных фрагментов, затем модель использует их как evidence при подготовке ответа. Если evidence слабые, отсутствуют или недоступны, безопасный результат — сказать об этом или передать вопрос на review.

Широкий коммерческий запрос о выборе AI-специалиста относится к странице AI-специалист в Армении. Здесь задача уже: понять, подходит ли retrieval по документам для одного конкретного вопроса базы знаний.

Авторская RAG-4 trace: четыре проверки до ответа

Для оценки будущего RAG-ассистента используйте короткую trace:

вопрос → retrieval с учётом прав → evidence packet → ограниченный ответ
                    ↓                    ↓                  ↓
              нет доступа?          нет опоры?        citation / review

Это авторская RAG-4 trace. В ней четыре обязательные точки:

1. Вопрос — определить пользователя, задачу и тип требуемого ответа.
2. Retrieval — искать только в источниках, доступных этому пользователю, и по текущим индексированным версиям.
3. Evidence packet — сохранить рядом с ответом выбранные фрагменты, источник и версию.
4. Ограниченный ответ — отвечать по evidence, дать citation, если она нужна, и показать неопределённость вместо уверенного заполнения пробелов.

Модель здесь не является базой знаний. Она превращает permission-filtered evidence packet в понятное объяснение, черновик, сравнение или следующий шаг.

Как это работает без маркетингового сокращения

Представьте, что operations-менеджер спрашивает: «Какое согласование нужно до отправки договора поставщику?» Нужная информация может находиться в актуальной policy, юридическом шаблоне и инструкции workflow. Типичный RAG-путь выглядит так:

1. Подготовить набор источников. Разрешённые документы собираются, при необходимости очищаются, получают owner и разбиваются на удобные для поиска фрагменты. У каждого фрагмента остаются metadata: источник, дата, версия, тип документа и scope доступа.
2. Понять вопрос. Приложение определяет, что спросил человек, язык, организацию или tenant и применимые права. Это не декоративный контекст: он определяет, что поиск имеет право вернуть.
3. Найти кандидатов. Поиск подбирает фрагменты, близкие по смыслу и иногда по словам. До передачи модели система может отфильтровать тип документа, отдел, статус policy, язык или права доступа.
4. Собрать evidence. Формируется небольшой ранжированный пакет. Production-дизайн хранит source links и версии рядом с выбранным текстом, а не только во временном prompt.
5. Подготовить ограниченный response. Модель получает вопрос и evidence packet с инструкцией разделять подтверждённые утверждения, отсутствие данных и процедурную рекомендацию. Приложение может показать citation или прямые ссылки.
6. Направить outcome. Ответ показывается как draft, передаётся reviewer или отклоняется, если evidence нет, они противоречат друг другу, устарели или выходят за права пользователя.

Embeddings часто помогают поиску найти похожий смысл, даже когда в вопросе и документе разные слова. Но embeddings — помощник retrieval, а не гарантия правильности. Название policy легче найти, однако качество ответа всё равно зависит от источников, прав, ранжирования и окружения.

Один сквозной пример: контролируемый policy assistant

Допустим, компания хочет помощника для вопросов по внутренним policy. Пользователь спрашивает: «Может ли team lead согласовать продление договора с этим поставщиком?»

Ассистент не должен отвечать из общей памяти о том, как обычно устроены договоры. Ему нужно найти актуальную approval policy, возможное исключение для поставщика и scope роли пользователя. В evidence packet могут войти:

После этого модель может сказать: «По текущей policy выше указанного threshold нужно согласование finance. Я нашёл исключение для поставщика, но оно относится только к procurement owner. Откройте указанную policy или направьте кейс в procurement». Такой ответ полезен именно потому, что показывает evidence и границу. Он не делает вид, что сам согласовал договор.

Тот же pattern работает для ответов поддержки, onboarding, технических runbooks, sales enablement drafts и research assistants. Но набор источников, права, качество и цена ошибки каждый раз различаются.

Где RAG подходит — и где он не нужен

RAG — это pattern для вопросов, где ответ зависит от изменяемого и проверяемого набора информации. Это не обязательное улучшение каждого чат-бота или процесса.

Для детерминированной работы обычный код, структурированный запрос к базе или простой search screen могут оказаться точнее и дешевле. В значимых решениях RAG может подготовить evidence, но не должен незаметно получить authority над юридическими, финансовыми, кадровыми, access-control или медицинскими решениями.

Ограничения, которые assistant по документам сам не решит

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

Плохие источники остаются плохими. Дублирующийся, устаревший или противоречивый документ всё ещё может попасть в retrieval. Ingestion должен сохранять owner, versioning и маршрут исключения obsolete-файлов.

Поиск может пропустить лучший фрагмент. Вопрос может быть сформулирован неожиданно, документ — плохо разделён, а ranking — поднять слабый результат. Тестируйте реальные вопросы и трудные cases, а не один удачный demo.

Права доступа — задача приложения. Нельзя полагаться на то, что модель помнит, какой документ можно показывать сотруднику. Применяйте правила до retrieval и сохраняйте audit trail того, что стало доступно.

Citation не является сертификатом корректности. Она доказывает связь ответа с источником, но не то, что источник применим и актуален. Интерфейс должен позволять проверить источник и сообщить об ошибке.

Больше документов может ухудшить retrieval. Большая коллекция без metadata, ownership и правил freshness даёт больше способов вернуть нерелевантный контекст. Начните с одного ограниченного корпуса и известного набора вопросов.

Минимальная практическая проверка до большого build

Не начинайте с индексирования всего общего диска. Возьмите один набор документов и несколько репрезентативных вопросов. Этот gate подходит для discovery или prototype:

require(source.owner && source.version && source.accessRule);
require(testSet.normal && testSet.noAnswer && testSet.permissionDenied);
require(answer.showsEvidence || answer.routesToReview);
rag_ready = retrieval.logged && corrections.haveOwner && staleSource.canBeRemoved;

Проверьте минимум такие случаи:

• обычный вопрос с одним ясным актуальным источником;
• вопрос с двумя противоречивыми источниками;
• вопрос, на который в approved collection нет ответа;
• вопрос от пользователя, которому нельзя видеть нужный документ;
• недавно изменённый документ, который должен заменить старую версию.

Полезные сигналы — не общий процент «точности AI». Отслеживайте, был ли найден правильный источник, остался ли ответ внутри evidence, исправил ли его reviewer, был ли source актуален и дошёл ли пользователь до citation. До сравнения итераций зафиксируйте sample и известные ограничения.

Что решить до внедрения

Для обсуждения RAG-системы принесите небольшой evidence package, а не просьбу «обучить чат-бот на всех наших файлах»:

1. Одну группу пользователей и вопросы, на которые ей нужен ответ.
2. Один ограниченный набор документов с owner, путём обновления и правилами доступа.
3. Примеры допустимого ответа, no-answer response и escalation cases.
4. Действие после ответа: прочитать, подготовить draft, создать задачу review или спросить человека.
5. Человека, который отвечает за correction, refresh источников и incidents.

Такой scope позволяет проверить retrieval, citations, access boundaries и операционную ответственность до более широкого rollout базы знаний. RAG ценен, когда упрощает поиск и проверку evidence. Он не ценен, когда скрывает неуправляемые документы за беглым текстом.