Компания обновила условия обслуживания, а внутренний AI-помощник продолжает цитировать старую инструкцию. На первый взгляд виновата модель. Но если она получила устаревший документ из поиска, замена модели может вообще ничего не исправить.
Это и есть главная архитектурная дилемма RAG: недостаточно подключить корпоративные знания к AI. Нужно отвечать за то, какие именно знания попали в ответ, кто имел право их получить и как проверить результат.
Модель не должна помнить весь архив
RAG, Retrieval-Augmented Generation, означает, что перед формированием ответа система ищет подходящую информацию во внешних источниках. Для корпоративного помощника это могут быть регламенты, договоры, карточки продуктов и внутренняя база знаний.
Обычно документы сначала подготавливают: разбивают на фрагменты, сохраняют сведения об источнике, версии и правах, создают поисковый индекс. Когда приходит вопрос, система отбирает релевантные фрагменты и передаёт их модели вместе с запросом.
Поиск может быть по словам, по смыслу или комбинированным. Векторный поиск полезен, когда формулировки различаются, но он не делает найденную информацию правильной автоматически. Если сотрудник спрашивает про действующий лимит, похожий по смыслу документ прошлого года не подходит, даже если алгоритм считает его отличным совпадением.
Преимущество перед переобучением модели — возможность изменять источники отдельно. Но это не мгновенная магия: после изменения документа нужно обновить индекс, убрать устаревшие фрагменты и проверить, что новая версия действительно участвует в поиске.
Ошибка может произойти ещё до ответа
Представим вопрос: «Какие условия возврата действуют для этого договора?» Система может ошибиться минимум в трёх разных местах.
- Найти не тот документ: например, публичную оферту вместо индивидуального соглашения.
- Найти правильный документ, но передать модели фрагмент без исключений или без даты вступления изменений в силу.
- Передать полный и правильный контекст, после чего модель неверно его интерпретирует.
У всех трёх ошибок одинаковый внешний симптом — неправильный ответ. Но исправляются они по-разному. В первом случае проверяем поиск и ранжирование, во втором — подготовку источников и контекст, в третьем — само построение ответа и его проверку.
Поэтому KPI «пользователи довольны чатом» не заменяет диагностику. Полезно иметь набор реальных вопросов с проверенными ответами и отдельно измерять, нашлись ли нужные источники и соответствует ли им итоговый текст. Подходы к таким оценкам описаны в документации Microsoft по оценке RAG.
Право прочитать документ проверяется до модели
Допустим, кадровая инструкция лежит в той же поисковой базе, что и общие правила компании. Сотрудник задаёт вопрос, поиск находит закрытый фрагмент, модель формулирует аккуратный ответ. Утечка уже произошла — независимо от того, насколько вежливо этот ответ написан.
Ограничивать нужно сам поиск: проверять права пользователя на каждый найденный фрагмент до передачи контекста модели. Если документ отозван или сотрудник потерял доступ, изменения должны доходить и до поискового индекса. Просьба в промпте «не раскрывай конфиденциальное» не заменяет контроль доступа.
Есть и другой риск. Текст документа — это данные, а не команда для модели. Если внутри встретится инструкция вроде «игнорируй предыдущие правила», система не должна считать её распоряжением пользователя или администратора. Принципы защиты всего контура, включая retrieval и индексы, разбирает OWASP RAG Security Cheat Sheet.
Кто отвечает за актуальность знаний
Хороший поиск не создаст порядка там, где нет владельца информации. Если три подразделения хранят три версии одной инструкции, AI не обязан угадать, какую из них организация считает действующей.
Поэтому до запуска стоит определить источник истины, владельца документов, правила версионирования и сроки обновления индекса. Также важно удалять производные копии после удаления оригинала и не оставлять в поиске материалы, которые уже недоступны в исходной системе.
Пользователю лучше показывать источник, дату и ссылку, по которой он действительно может открыть документ. При отсутствии надёжного основания ответ «в доступных материалах не нашёл» полезнее, чем убедительная догадка. Но и наличие ссылки не является гарантией: модель может сослаться на правильный файл, сделав неверный вывод.
Когда RAG лучше не строить
Не каждую задачу надо решать поиском по документам. Для небольшого набора неизменных правил достаточно передать модели проверенный контекст. Для точного остатка на складе или действующей цены надёжнее запросить структурированные данные через API, а не искать число в индексированной копии таблицы.
RAG оправдан, когда ответы действительно зависят от большого массива меняющихся неструктурированных знаний. Я бы начинал не с закупки векторной базы, а с нескольких десятков типовых вопросов, перечня разрешённых источников и критериев правильного ответа. После этого уже понятнее, какая архитектура нужна.
RAG не превращает хаотичный архив в достоверные знания. Он делает качество корпоративной информации, поиска и управления доступом частью качества AI-продукта.