RAG — это схема, в которой языковая модель получает найденные фрагменты корпоративных документов. Она помогает отвечать по регламентам и инструкциям со ссылками на источники. Но RAG не гарантирует истинность: качество зависит от данных, поиска, прав доступа и проверки ответа. Поэтому начинать стоит с ограниченного сценария и измеримых критериев.
Что происходит между вопросом и ответом
Классическая цепочка состоит из двух процессов. Сначала система индексирует материалы: извлекает текст, делит его на фрагменты, добавляет метаданные и строит поисковый индекс. Затем при вопросе пользователя находит подходящие фрагменты и передаёт их языковой модели как контекст. Исходная работа о Retrieval-Augmented Generation описывает соединение параметрической модели с внешней непараметрической памятью [1]. Современные платформы реализуют эту идею через семантический или гибридный поиск, фильтры и управляемые хранилища [2][3].
Практический смысл не в самом векторном индексе, а в управляемом пути от источника к цитате:
- документ принят и распознан;
- его владелец, версия и уровень доступа сохранены;
- фрагменты попали в индекс без потери структуры;
- поиск отобрал материалы, доступные конкретному пользователю;
- модель получила вопрос, выдержки и правила ответа;
- пользователь увидел источники и может открыть оригинал;
- оценка ответа и обратная связь попали в журнал качества.
Если хотя бы один шаг непрозрачен, команда не сможет объяснить, почему система дала неверный ответ.
Вывод автора — непроверенный до анализа материалов проекта. Для первого пилота лучше выбрать один тип документов и одну роль пользователей. Это делает причины ошибок наблюдаемыми и снижает цену изменения индексации.
Планируете корпоративный поиск с ИИ? Обсудите с Paladin Engineering предпроектное обследование: сценарии, источники, права доступа и набор контрольных вопросов до выбора модели и платформы.
RAG не чинит плохую базу знаний автоматически
Внутренние хранилища содержат дубликаты, устаревшие редакции и сканы без текста. Модель не знает, какой регламент действует, если версия не указана. Поэтому корпус нужно инвентаризировать, выбрать канонические источники и проверить качество извлечения.
Особенно осторожно следует работать с таблицами и инструкциями: механическое деление может отделить условие от действия. Microsoft рекомендует учитывать структуру, разбиение, метаданные и качество поиска как отдельные этапы [3].
Как выбирать фрагменты для индекса
Универсального размера чанка нет. Слишком короткий фрагмент теряет контекст, слишком длинный приносит лишний шум и занимает контекстное окно. Начальную стратегию выбирают по типу материалов:
| Материал | Базовый подход | Что проверить |
|---|---|---|
| Регламенты и инструкции | Деление по заголовкам и шагам | Сохранились ли условия и исключения |
| FAQ и карточки услуг | Одна смысловая пара вопрос–ответ | Не смешаны ли разные продукты |
| Договоры и политики | Разделы с номером, версией и датой | Видит ли пользователь только разрешённые документы |
| Таблицы и каталоги | Структурированное представление или специализированный парсер | Не потеряны ли заголовки, единицы и связи строк |
| Переписка и тикеты | Фильтрация, очистка и группировка по кейсу | Исключены ли персональные и лишние данные |
После разбиения полезно хранить не только текст, но и document_id, заголовок, раздел, версию, владельца, дату действия, язык и список доступа. Эти поля позволяют фильтровать поиск и строить понятные ссылки на первоисточник.
Поиск: векторный, ключевой или гибридный
Семантический поиск хорошо находит близкие по смыслу формулировки, но может хуже работать с артикулами, кодами ошибок и точными названиями. Ключевой поиск, наоборот, силён в точных совпадениях. В корпоративной системе часто полезна гибридная выдача с последующим reranking — повторной оценкой кандидатов.
Качество оценивают отдельно от генерации. Для контрольного вопроса сначала проверяют, попал ли нужный фрагмент в верхнюю часть выдачи. Если нет, изменение промпта модели проблему не исправит. Причина может быть в разбиении, метаданных, формулировке запроса, фильтре доступа или алгоритме ранжирования.
Права доступа должны применяться до генерации
Самая опасная ошибка — сначала найти документы всей компании, а потом попросить модель «не раскрывать лишнее». Модель уже получила закрытые данные. Контроль доступа должен фильтровать кандидатов до того, как их содержимое попадёт в контекст.
Минимальные меры:
- единая корпоративная аутентификация и проверка роли пользователя;
- наследование прав от исходной системы или явная матрица доступа;
- фильтрация в поиске по разрешённым документам;
- запрет индексации секретов и избыточных персональных данных;
- шифрование при передаче и хранении в соответствии с требованиями проекта;
- журналирование административных операций и изменений корпуса;
- сценарий удаления документа из индекса и кэшей;
- тесты, в которых пользователь одной группы пытается получить материал другой.
Инструкции внутри документов тоже нельзя считать доверенными. Фраза в загруженном файле может попытаться изменить поведение модели — это один из вариантов prompt injection. Защита строится не одной формулировкой системного промпта, а сочетанием минимальных прав, разделения данных и команд, фильтрации действий и проверки критических ответов. NIST в профиле рисков генеративного ИИ предлагает управлять рисками по жизненному циклу системы, а не сводить их к точности модели [4].
Как отвечать, когда данных недостаточно
Хорошая RAG-система умеет не отвечать. В инструкции модели нужно отделить найденный контекст от вопроса и задать правило не отвечать без подтверждающего контекста и проверять корректность отказа на тестах. В интерфейсе стоит показывать название документа, раздел, дату версии и ссылку. Для спорных процессов полезен текст вроде: «В доступных источниках нет однозначного ответа; обратитесь к владельцу регламента».
Цитата сама по себе не доказывает корректность: она должна действительно поддерживать утверждение. Для кадровых, юридических, финансовых и производственно-критических решений нужен человеческий контроль, определённый владельцем процесса.
Вывод автора — непроверенный до согласования с владельцем риска. Автоматический ответ лучше позиционировать как навигацию по знаниям, а не как окончательное решение, пока на реальных кейсах не подтверждены качество и границы применения.
Как провести измеримый пилот
Выберите один процесс, группу пользователей и владельца результата. Соберите контрольные вопросы, включая неоднозначные и не имеющие ответа; подготовьте ограниченный корпус и правила доступа. Сначала измерьте качество поиска, затем добавьте генерацию, ссылки и корректный отказ. Финальную проверку проводят эксперты на независимой выборке.
Метрики разделяют: для поиска — наличие нужного источника в верхних результатах; для ответа — подтверждаемость, полнота и корректный отказ; для продукта — экономия времени и доля успешных сессий. Пороги устанавливает владелец процесса, универсальная цифра будет ложной гарантией.
Как Paladin Engineering может помочь
Мы можем собрать RAG-пилот как управляемую информационную систему: подключить источники, подготовить pipeline индексации, реализовать поиск и интерфейс, встроить корпоративную авторизацию, журналирование и мониторинг качества. На старте фиксируем контрольный набор вопросов и ограничения. После пилота передаём карту ошибок и решение о следующем этапе, а не только демонстрацию удачных ответов.
Смежные направления: интеграция информационных систем, разработка корпоративных порталов и AI-решения для бизнеса.
Хотите проверить RAG на своих документах без большого внедрения? Подготовьте один набор материалов и примеры реальных вопросов. Мы предложим границы пилота, критерии приёмки и список рисков, которые нужно закрыть до промышленного запуска.
FAQ
Чем RAG отличается от обучения модели на документах?
RAG извлекает фрагменты во время запроса и передаёт их модели как контекст. Это обычно упрощает обновление знаний и показ источников. Дообучение решает другие задачи — например, стиль или устойчивый формат поведения — и не заменяет актуальный поиск.
Можно ли загрузить в RAG весь корпоративный диск?
Технически источников может быть много, но начинать так рискованно. Смешиваются права, версии и качество документов, а причины ошибки трудно обнаружить. Лучше расширять проверенный корпус поэтапно.
Исключает ли RAG галлюцинации?
Нет. Модель может неверно интерпретировать найденный текст, объединить несовместимые фрагменты или ответить при недостатке данных. Нужны правила отказа, цитаты, оценка и человеческий контроль для критичных решений.
Нужно ли использовать только векторный поиск?
Нет. Точные коды и названия часто лучше находятся ключевым поиском. Гибридная схема объединяет методы, а reranking помогает упорядочить кандидатов.
Как не показать сотруднику закрытый документ?
Права должны применяться при поиске до передачи текста модели. Проверка только в интерфейсе или после генерации не защищает содержимое.
Как понять, что пилот успешен?
Заранее утвердить контрольные вопросы, метрики поиска и ответа, допустимые ошибки и бизнес-эффект. Успех — не красивая демонстрация, а воспроизводимый результат на независимой выборке.
Источники
- Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks: https://arxiv.org/abs/2005.11401 (дата обращения: 20.07.2026).
- OpenAI Platform Documentation, Retrieval: https://platform.openai.com/docs/guides/retrieval (дата обращения: 20.07.2026).
- Microsoft Learn, Advanced RAG techniques: https://learn.microsoft.com/en-us/azure/developer/ai/advanced-retrieval-augmented-generation (дата обращения: 20.07.2026).
- NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence (дата обращения: 20.07.2026).
Комментарии