AI-поиск по документам компании: как внедрить RAG и не раскрыть данные

Сотрудники тратят время на поиск актуальных регламентов, условий договоров, инструкций и ответов на вопросы клиентов. Документы находятся в разных папках, CRM и корпоративных базах знаний; даже найденный файл приходится проверять на актуальность. AI-поиск по документам компании способен сократить этот путь, но только если в проект заложены проверяемые источники, разграничение доступа и контроль ошибок. Просто загрузить PDF в чат недостаточно.

Какие задачи решает AI-поиск по корпоративной базе знаний

Обычный поиск показывает документы, где встречаются ключевые слова. RAG (retrieval-augmented generation, генерация с использованием найденных данных) сначала находит релевантные фрагменты, а затем передаёт их языковой модели для подготовки ответа. Хороший интерфейс показывает ссылки на документы и конкретные основания ответа. Это не гарантирует абсолютную точность, но позволяет человеку проверить результат.

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

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

Как устроена архитектура RAG: от документа до ответа

Подключение источников и подготовка данных

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

Затем строится поисковый индекс. Он может использовать поиск по словам, векторные представления смысла либо гибридный подход. Microsoft в руководстве по RAG рассматривает эти варианты и повторное ранжирование найденных фрагментов.

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

Поиск с учётом прав и генерация ответа

Когда сотрудник задаёт вопрос, сервер определяет его роль, отбирает только разрешённые документы, ищет релевантные фрагменты и передаёт их модели. Модель составляет ответ, а приложение показывает ссылки на первоисточники. В Amazon Bedrock Knowledge Bases описана выдача ответов с цитированием исходных фрагментов — полезный ориентир для требований к продукту.

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

Почему гибридный поиск часто практичнее одного векторного

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

Безопасность: доступ к документам важнее промпта

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

• Аутентификация: пользователь входит через корпоративную учётную запись, а роли проверяются на сервере.
• Фильтрация до передачи модели: сотрудник продаж не должен получать фрагменты закрытых HR-документов даже через косвенный вопрос.
• Актуальные разрешения: смена должности, отзыв доступа и удаление файла должны отражаться в поиске.
• Минимизация данных: не отправляйте модели весь архив, если для ответа достаточно нескольких разрешённых фрагментов.
• Контроль поставщика: до интеграции внешнего AI-провайдера проверьте условия обработки, хранения и передачи корпоративных данных.
• Аудит: фиксируйте технические события и ошибки, но не превращайте журналы в ещё одно хранилище секретов.

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

Стоимость AI-поиска: что входит в смету

Обоснованную цену нельзя назвать без изучения источников и требований. На бюджет влияют количество и качество документов, сложность извлечения текста, число интеграций, система ролей, частота обновления индекса, интерфейс, требования к размещению и мониторингу.

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

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

Что включить в ТЗ и как принимать результат

Хорошее ТЗ описывает не абстрактный «умный чат», а конкретные входные данные и проверяемое поведение системы.

1. Источники: список хранилищ, форматы файлов, правила синхронизации и ответственные владельцы.
2. Права: роли, группы, правила отзыва доступа, требования к журналированию.
3. Ответы: ссылки на первоисточники, версия документа, поведение при отсутствии данных или конфликте версий.
4. Поиск: точные идентификаторы, русскоязычные запросы, опечатки, составные вопросы.
5. Эксплуатация: резервное копирование, восстановление, мониторинг и порядок исправления ошибок.
6. Приёмка: набор реальных вопросов с заранее известными ответами и разрешёнными источниками.

Как проверить пилот на практике

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

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

Порядок внедрения без остановки работы компании

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

Итог: корпоративный AI-поиск полезен не потому, что отвечает красивым текстом, а потому, что помогает быстрее находить подтверждённую информацию в пределах полномочий сотрудника. AVEXIUM может спроектировать пилот RAG, подключить корпоративные источники, настроить права и определить измеримые критерии приёмки.