Как проверить ИИ-поиск по документам компании: источник, версия и права доступа
Протокол пилота ИИ-поиска по внутренним документам: проверьте действующую версию, источник ответа и доступ двух ролей. Когда остановить тест.
Если сотрудник спрашивает, по какому правилу согласовать возврат, одного уверенного ответа мало. Нужно, чтобы он мог открыть действующий документ, доступный его роли, и увидеть место, на котором основан вывод. Начните пилот с небольшого набора разрешённых файлов: назначьте владельца версий, составьте вопросы с известными ответами и задайте их от имени сотрудников с разными правами. Если поиск показывает закрытый фрагмент, ссылается на старую версию или сочиняет ответ без опоры, пилот нужно остановить и исправить причину.
Это руководство для операционного руководителя, который выбирает способ поиска по внутренним инструкциям. Ниже — заполняемый протокол проверки, а не обещание, что какая-либо система автоматически соблюдёт права и всегда найдёт верный ответ.
Сначала приведите в порядок небольшой корпус документов
Выберите один процесс, например согласование возвратов. Соберите только те инструкции, которые нужны для него и разрешены для теста. Для каждого файла запишите владельца, действующую версию, дату вступления в силу, место хранения и роли с доступом. Старый регламент оставьте в учебном наборе отдельно: так можно проверить, не выдаёт ли поиск утратившее силу правило за действующее. Если даже владелец процесса не может назвать актуальную версию, сначала решите этот вопрос без ИИ.
Администратор источников или ИТ-специалист должен проверить, под чьей учётной записью система читает файлы и как применяет права. У разных механизмов правила различаются. Например, документация Microsoft описывает для синхронизируемых Copilot connectors индексируемые элементы с содержимым, метаданными и списком контроля доступа (ACL), фильтрацию результатов по разрешениям и периодическую синхронизацию изменений. Это свойства указанного механизма, а не гарантия для любого ИИ-поиска. Microsoft Learn: Copilot connectors overview, проверено 06.10.2026. Для источников SharePoint и OneDrive в declarative agent Microsoft отдельно пишет о поиске по файлам, доступным пользователю; для загруженных внутрь агента файлов описаны иные ограничения. Поэтому нельзя переносить поведение одного типа источника на другой. Microsoft Learn: Add knowledge sources, проверено 06.10.2026.
Для учебного прогона создайте вымышленные документы без персональных и коммерчески закрытых данных. В реальном пилоте состав набора и условия обработки корпоративных файлов согласуют владелец процесса и ответственные за доступ. Не копируйте настоящие закрытые документы в тестовую среду только ради удобства эксперимента.
Заполните эталон до первого запроса
В протоколе одна строка — один вопрос от одной роли. Заполните эталон до того, как увидите ответ системы: иначе неудобный результат легко принять за правильный. Если вопрос допускает несколько толкований, запишите их в эталоне или уточните вопрос до теста.
| Вопрос и роль | Эталон: документ, версия, нужный фрагмент | Разрешено увидеть | Запрещено увидеть | Результат поиска: фрагмент, ссылка, ответ или отказ | Вердикт, причина и исправление |
|---|---|---|---|---|---|
[вопрос]; [роль/учётная запись] | [название]; [версия/дата]; [пункт] | [документ или безопасный отказ] | [закрытый файл/старое правило/выдуманный вывод] | [дословный фрагмент или его отсутствие]; [ссылка]; [формулировка ответа] | [принято/исправить/остановить]; [что изменить и кто отвечает] |
[тот же вопрос]; [другая роль] | [название]; [версия/дата]; [пункт] | [что доступно именно этой роли] | [что скрыто от неё] | [фрагмент]; [ссылка]; [ответ или отказ] | [вердикт]; [владелец исправления] |
[вопрос после отзыва доступа или смены версии]; [роль] | [новый эталон и время изменения] | [ожидаемый результат после цикла обновления] | [снятый документ или отозванный фрагмент] | [время проверки]; [фрагмент]; [ссылка]; [ответ/отказ] | [вердикт]; [исправление] |
Перед началом согласуйте с ИТ-специалистом, когда изменения в источнике должны попасть в поиск. Для синхронизируемых коннекторов Microsoft описывает периодическую проверку изменений и настройку частоты синхронизации; мгновенное обновление из этого не следует. Microsoft Learn: Copilot connectors overview, проверено 06.10.2026. Записывайте время изменения прав или версии и время повторного запроса. Если механизм обновления конкретного решения неизвестен, этот пункт нельзя считать пройденным.
Проверьте не только удачный ответ
В учебный набор включите действующий и старый регламент по одному вопросу; файл для всей команды и файл с ограниченным доступом; вопрос, на который в корпусе нет ответа; похожий термин в документах разных отделов. Затем отдельно измените версию документа или отзовите доступ и повторите запрос после цикла обновления, предусмотренного для выбранной системы. Проверяйте и текст ответа, и найденные фрагменты, и доступность ссылки под той же учётной записью. Ссылка на файл сама по себе не подтверждает, что вывод верен: человеку нужно сопоставить формулировку ответа с конкретным пунктом и статусом версии.
Учебный пример, не результат испытания сервиса. В наборе есть «Возвраты v2» для всей команды с правилом «заявку передать руководителю сервиса» и старый «Возвраты v1» с другим маршрутом. Есть и «Исключения по возвратам v2», доступные только руководителю. Операционный руководитель заранее записывает в протокол: на вопрос «Кому передать обычную заявку?» сотруднику сервиса разрешён ответ на основе документа «Возвраты v2» со ссылкой на нужный пункт; ссылаться на v1 нельзя. На вопрос об исключении сотруднику сервиса нельзя показывать закрытый файл или пересказывать его содержание. Для руководителя тот же вопрос проверяется отдельно: ожидается разрешённый фрагмент из «Исключения по возвратам v2». Если система сообщает сотруднику закрытое правило даже без ссылки, это провал проверки доступа. Если она не находит нужный документ, это другая ошибка: проверьте состав корпуса, индексацию и формулировку запроса, прежде чем менять ответ вручную.
Добавьте вопрос «Как оформить случай, который ни один регламент не описывает?». Эталон здесь — сообщение об отсутствии подтверждённого ответа и передача владельцу процесса. Складный ответ без опоры на документ не должен считаться успешным поиском. Если в документах двух отделов встречается похожий термин, система должна указать, к какому отделу относится найденное правило, либо попросить уточнение. Порог приемлемых пропусков и время ответа руководитель устанавливает для собственного процесса до испытания; универсальной цифры для разных корпусов нет.
Решите, продолжать ли пилот
После каждого запроса владелец процесса открывает источник и ставит вердикт в протоколе. ИТ-специалист разбирает ошибки доступа, подключения и обновления. Сотрудник, отвечающий за регламенты, исправляет устаревшие или противоречивые документы. Нельзя выдавать проблему качества корпуса за «ошибку модели», а ошибку в правах — исправлять одной лишь правкой подсказки.
Заранее задайте жёсткие условия остановки: показ закрытого фрагмента другой роли, ответ без подтверждённой опоры, ссылка на снятую версию как на действующую. Исправление проверяют повтором того же случая и соседних сценариев. Для менее опасных ошибок — например, поиск не нашёл разрешённый файл — определите допустимый уровень на собственном наборе, сколько времени уходит на ручную проверку и кто принимает решение о продолжении. Один удачный ответ не показывает, что система готова к работе со всем архивом.
Возможно, ИИ для выбранной задачи не нужен. Реестр действующих документов, понятные названия файлов, права на папки и обычный поиск могут решить проблему, если сотрудникам достаточно открыть нужный файл. Официальная документация Google Drive, например, описывает поиск по файлам и папкам с фильтрами и авторизованным запросом; это пример обычного поиска, а не предложение определённого сервиса для вашей компании. Google Developers: Search for files and folders, проверено 06.10.2026. Сравните оба варианта на одинаковых вопросах: время до открытия действующего документа, ошибки версии, ошибки доступа и труд на поддержку корпуса.
Следующий шаг — взять один процесс и заполнить первые строки протокола до выбора инструмента. Если затем захотите расширить проверку помощника за пределы поиска, используйте методику «Как проверить ИИ-помощника на 10 сценариях».