RAG для корпоративной базы знаний: как получать ответы по документам и управлять рисками
RAG — это схема, в которой языковая модель получает найденные фрагменты корпоративных документов. Она помогает отвечать по регламентам и инструкциям со ссылками на источники. Но RAG не гарантирует истинность: качество зависит от данных, поиска, прав доступа и проверки ответа. Поэтому начинать стоит с ограниченного сценария и измеримых критериев.
Что происходит между вопросом и ответом
Классическая цепочка состоит из двух процессов. Сначала система индексирует материалы: извлекает текст, делит его на фрагменты, добавляет метаданные и строит поисковый индекс. Затем при вопросе пользователя находит подходящие фрагменты и передаёт их языковой модели как контекст. Исходная работа о Retrieval-Augmented Generation описывает соединение параметрической модели с внешней непараметрической памятью [1]. Современные платформы реализуют эту идею через семантический или гибридный поиск, фильтры и управляемые хранилища [2][3].
Практический смысл не в самом векторном индексе, а в управляемом пути от источника к цитате:
1. документ принят и распознан;
2. его владелец, версия и уровень доступа сохранены;
3. фрагменты попали в индекс без потери структуры;
4. поиск отобрал материалы, доступные конкретному пользователю;
5. модель получила вопрос, выдержки и правила ответа;
6. пользователь увидел источники и может открыть оригинал;
7. оценка ответа и обратная связь попали в журнал качества.
Если хотя бы один шаг непрозрачен, команда не сможет объяснить, почему система дала неверный ответ.
Для первого пилота лучше выбрать один тип документов и одну роль пользователей. Это делает причины ошибок наблюдаемыми и снижает цену изменения индексации.
Планируете корпоративный поиск с ИИ? Обсудите с Paladin Engineering предпроектное обследование: сценарии, источники, права доступа и набор контрольных вопросов до выбора модели и платформы.
RAG не чинит плохую базу знаний автоматически
Внутренние хранилища содержат дубликаты, устаревшие редакции и сканы без текста. Модель не знает, какой регламент действует, если версия не указана. Поэтому корпус нужно инвентаризировать, выбрать канонические источники и проверить качество извлечения.
Особенно осторожно следует работать с таблицами и инструкциями: механическое деление может отделить условие от действия. Microsoft рекомендует учитывать структуру, разбиение, метаданные и качество поиска как отдельные этапы [3].
Как выбирать фрагменты для индекса
Универсального размера чанка нет. Слишком короткий фрагмент теряет контекст, слишком длинный приносит лишний шум и занимает контекстное окно. Начальную стратегию выбирают по типу материалов:
После разбиения полезно хранить не только текст, но и `document_id`, заголовок, раздел, версию, владельца, дату действия, язык и список доступа. Эти поля позволяют фильтровать поиск и строить понятные ссылки на первоисточник.
Поиск: векторный, ключевой или гибридный
Семантический поиск хорошо находит близкие по смыслу формулировки, но может хуже работать с артикулами, кодами ошибок и точными названиями. Ключевой поиск, наоборот, силён в точных совпадениях. В корпоративной системе часто полезна гибридная выдача с последующим reranking — повторной оценкой кандидатов.
Качество оценивают отдельно от генерации. Для контрольного вопроса сначала проверяют, попал ли нужный фрагмент в верхнюю часть выдачи. Если нет, изменение промпта модели проблему не исправит. Причина может быть в разбиении, метаданных, формулировке запроса, фильтре доступа или алгоритме ранжирования.
Права доступа должны применяться до генерации
Самая опасная ошибка — сначала найти документы всей компании, а потом попросить модель «не раскрывать лишнее». Модель уже получила закрытые данные. Контроль доступа должен фильтровать кандидатов до того, как их содержимое попадёт в контекст.
Минимальные меры:
- единая корпоративная аутентификация и проверка роли пользователя;
- наследование прав от исходной системы или явная матрица доступа;
- фильтрация в поиске по разрешённым документам;
- запрет индексации секретов и избыточных персональных данных;
- шифрование при передаче и хранении в соответствии с требованиями проекта;
- журналирование административных операций и изменений корпуса;
- сценарий удаления документа из индекса и кэшей;
- тесты, в которых пользователь одной группы пытается получить материал другой.
Инструкции внутри документов тоже нельзя считать доверенными. Фраза в загруженном файле может попытаться изменить поведение модели — это один из вариантов prompt injection. Защита строится не одной формулировкой системного промпта, а сочетанием минимальных прав, разделения данных и команд, фильтрации действий и проверки критических ответов. NIST в профиле рисков генеративного ИИ предлагает управлять рисками по жизненному циклу системы, а не сводить их к точности модели [4].
Как отвечать, когда данных недостаточно
Хорошая RAG-система умеет не отвечать. В инструкции модели нужно отделить найденный контекст от вопроса и задать правило не отвечать без подтверждающего контекста и проверять корректность отказа на тестах. В интерфейсе стоит показывать название документа, раздел, дату версии и ссылку. Для спорных процессов полезен текст вроде: «В доступных источниках нет однозначного ответа; обратитесь к владельцу регламента».
Как провести измеримый пилот
Выберите один процесс, группу пользователей и владельца результата. Соберите контрольные вопросы, включая неоднозначные и не имеющие ответа; подготовьте ограниченный корпус и правила доступа. Сначала измерьте качество поиска, затем добавьте генерацию, ссылки и корректный отказ. Финальную проверку проводят эксперты на независимой выборке.
Метрики разделяют: для поиска — наличие нужного источника в верхних результатах; для ответа — подтверждаемость, полнота и корректный отказ; для продукта — экономия времени и доля успешных сессий. Пороги устанавливает владелец процесса, универсальная цифра будет ложной гарантией.
Как Paladin Engineering может помочь
Мы можем собрать RAG-пилот как управляемую информационную систему: подключить источники, подготовить pipeline индексации, реализовать поиск и интерфейс, встроить корпоративную авторизацию, журналирование и мониторинг качества. На старте фиксируем контрольный набор вопросов и ограничения. После пилота передаём карту ошибок и решение о следующем этапе, а не только демонстрацию удачных ответов.
Хотите проверить RAG на своих документах без большого внедрения?
Подготовьте один набор материалов и примеры реальных вопросов. Мы предложим границы пилота, критерии приёмки и список рисков, которые нужно закрыть до промышленного запуска.