Поиск по документам с ИИ: RAG, права доступа и качество ответов

Раздел

RAG и базы знаний

Сложность

средняя

Обновлено

2026-05-19

Короткий ответ

Поиск по документам с ИИ нужен, когда сотрудник не должен вспоминать, где лежит регламент, договор, инструкция или переписка. Он задает вопрос обычным языком, а система находит фрагменты, собирает ответ и показывает источники. Хороший поиск не выглядит как чат “по всей компании”. Он знает, какие документы актуальны, кому их можно показывать и когда нужно честно отказаться.

Главный риск - загрузить все файлы в индекс и считать задачу решенной. Если в корпусе старые версии договоров, дубли, закрытые документы и сканы без нормального распознавания, ИИ только ускорит хаос. Начинать нужно с одного домена: поддержка, юридические документы, инструкции продукта, HR-регламенты или база проектной документации.

Где поиск дает эффект

ИИ-поиск подходит для задач, где человек тратит время на сбор контекста:

• найти актуальный пункт регламента;
• ответить клиенту по базе знаний;
• сравнить условия в договоре и приложении;
• найти похожий тикет или инцидент;
• понять, какая инструкция относится к версии продукта;
• собрать выдержку по внутренней политике;
• проверить, есть ли документ с нужным статусом.

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

Корпус и источники

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

Минимальные метаданные:

Без метаданных поиск не сможет объяснить, почему выбран именно этот источник. Для пользователя это выглядит как магия, а для бизнеса - как отсутствие контроля.

RAG и генерация ответа

RAG-подход работает так: система ищет релевантные фрагменты, передает их модели и просит сформировать ответ по найденным источникам. Это лучше, чем просить модель “знать” ваши документы заранее, потому что документы меняются.

Но RAG не гарантирует правду автоматически. Нужно проверять три слоя:

• поиск нашел правильный фрагмент;
• модель использовала именно найденный фрагмент;
• ответ не добавил факты, которых нет в источнике.

Если источник не найден, система должна сказать, что данных нет. Ответ “похоже, по правилам…” опасен, если речь о договоре, деньгах, безопасности или обещании клиенту.

Права доступа

Права должны применяться до генерации ответа. Нельзя сначала найти закрытый документ, передать его модели, а потом попросить модель “не показывать лишнего”. Пользователь должен искать только в том корпусе, который ему разрешен.

Безопасная схема:

1. Пользователь проходит авторизацию.
2. Система определяет его группы и роли.
3. Поиск фильтрует документы по правам.
4. Модель получает только разрешенные фрагменты.
5. Ответ показывает источники и пишет действие в журнал.

Для пилота можно начать с общедоступной базы знаний. Для юридических, финансовых и HR-документов права нужно проектировать сразу.

Качество поиска

Тестировать нужно не красивые демо-вопросы, а реальные формулировки сотрудников. Соберите 100-200 вопросов из поддержки, Slack/Telegram, почты, таск-трекера или встреч. Для каждого вопроса укажите правильный источник и критерий ответа.

Проверяйте:

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

Отдельно добавьте провокационные вопросы: старые условия, несуществующие правила, просьбы показать закрытый документ. Они показывают, насколько система умеет останавливаться.

План внедрения

1. Выберите один корпус документов.
2. Назначьте владельца корпуса.
3. Удалите дубли и архивные материалы.
4. Добавьте метаданные и права доступа.
5. Настройте индексацию и поиск.
6. Соберите тестовый набор вопросов.
7. Запустите режим помощника для сотрудников.
8. Считайте ошибки, отказы, ручные правки и клики по источникам.
9. Расширяйте корпус только после стабильного качества.

Первый запуск должен быть скучным: один домен, понятные источники, контролируемые права. Это лучше, чем впечатляющий чат, который отвечает по старым документам.

Метрики

Не оценивайте только лайками под ответом. Пользователь может поставить лайк понятному, но неверному ответу. Для корпоративного поиска важнее источник и проверяемость.

Чеклист

• Корпус ограничен и очищен.
• У документов есть владелец и дата обновления.
• Права применяются до поиска и генерации.
• Ответ показывает источник.
• Есть тестовый набор реальных вопросов.
• Система умеет отказаться.
• Ошибки попадают владельцу корпуса.
• Расширение делается после измеримого качества.

FAQ

Можно ли искать сразу по всем документам?

Технически можно, но для первого запуска это плохая идея. Сначала один корпус и понятные права, потом расширение.

Чем это отличается от обычного поиска?

Обычный поиск возвращает документы. ИИ-поиск собирает ответ по найденным фрагментам и показывает источники. Поэтому ему нужны дополнительные проверки.

Что делать со сканами и PDF?

Сначала проверить качество распознавания, таблиц, заголовков и версий. Плохой OCR превращает хороший документ в плохой источник.

Что читать дальше?

Начните с общего хаба RAG система и сценария ИИ для поддержки клиентов. Если нужно понять, с какого корпуса документов начать пилот, посмотрите услуги Woghan.