kAIros
Начать такую проверку мы рекомендуем с имеющегося поиска или зрелого готового решения. Возможно, задача закроется без собственной разработки. Если потребуется другой подход, у компании уже будут конкретные требования: какие ответы нужны, что необходимо обновлять и в каких случаях поиск должен остановиться и направить человека к ответственному.
Какие вопросы сотрудников должен закрывать поиск
Для первого сценария лучше выбрать один процесс, в котором есть документы и человек, способный подтвердить правильность ответа. Например, можно начать с вопросов о внутреннем согласовании. Руководителю процесса предстоит объяснить, где опубликован действующий порядок, кому он доступен и что сотрудник должен сделать после прочтения.
Здесь полезно различать две задачи. Если сотруднику достаточно найти нужный регламент и прочитать короткий раздел, стоит сначала проверить обычный поиск. Генерацию ответа имеет смысл рассматривать, когда нужен связный ответ по найденным фрагментам. Сравнивать варианты следует на одном вопросе: удалось ли получить достаточно информации для следующего рабочего действия и проверить её по документу?
Один из способов устроить генерацию по документам называется RAG. Система извлекает подходящее содержимое, а модель использует его для составления ответа. Microsoft описывает этот подход как привязку ответов к собственным данным организации и отдельно рассматривает подготовку содержимого и контроль доступа. Само название подхода ещё не объясняет, какие документы попадут в ответ конкретному сотруднику. Это предстоит проверить в выбранном решении.
Представим вымышленную ситуацию, не кейс kAIros. Во внутреннем регламенте сказано: исключение из стандартного порядка может согласовать руководитель подразделения после письменного обоснования. Сотрудник спрашивает: «Кто может разрешить исключение?» Пригодный ответ должен назвать руководителя и сохранить условие об обосновании. Если следующий вопрос звучит «Значит, мне уже можно отступить от порядка?», поиск не должен превращать описание процедуры в разрешение.
В этом сценарии поиск помогает узнать опубликованное правило. Решение по конкретному исключению остаётся за человеком, которому компания дала такие полномочия. Эту границу стоит определить до проверки системы, чтобы затем не принимать удобную формулировку за выполненное согласование.
На какой документ опирается ответ
Ответ с источником удобнее проверять, когда можно открыть именно тот фрагмент, из которого он составлен. Такой механизм, например, описан в Amazon Bedrock: ответ сопровождается ссылками на исходные данные, а сноска позволяет посмотреть отрывок, относящийся к соответствующей части ответа.
При приёмке стоит пройти эту связь вручную. В вымышленном примере ответ «Исключение согласует руководитель подразделения» выглядит правдоподобно и даже ссылается на нужный регламент. Но он неполон: условие о письменном обосновании исчезло. Если сотрудник будет действовать по этому ответу, он пропустит предусмотренный шаг. Ссылка помогает обнаружить расхождение, однако сама по себе его не устраняет.
Поэтому владелец процесса должен заранее отметить, что нельзя потерять при пересказе: кто принимает решение, при каких условиях и какие действия требуются до него. Дословное совпадение с документом необязательно. Существенно, чтобы ответ не менял порядок действий и не расширял разрешение.
Следующий вопрос — почему именно этот документ считается действующим. Для проверки полезно видеть его статус, область применения и ответственного. Дата изменения файла сама по себе не должна становиться правилом выбора: компания должна определить, какая редакция действует для нужного подразделения или ситуации. Если такого решения нет, сначала нужно разрешить противоречие в документах. Поручать поиску выбирать корпоративное правило по убедительности текста не стоит.
Это не означает, что до начала работы нужно привести в идеальный порядок весь архив. Для первого сценария можно ограничить набор документов. Но внутри этого набора должно быть понятно, на какие положения разрешено опираться и кто исправит их, если обнаружится ошибка.
Что произойдёт после изменения регламента
Первая демонстрация отвечает на вопрос о документах, подключённых в этот момент. Для рабочего использования нужно отдельно проверить, что произойдёт после их изменения. Обновление текста в исходном хранилище и появление нового ответа в поиске следует включить в один приёмочный сценарий.
Это существенная часть устройства конкретных продуктов. Например, документация Amazon Bedrock требует синхронизировать источник после добавления, изменения или удаления файлов. Она также предупреждает, что для описанных вариантов хранилища новые данные могут стать доступны для запросов не сразу после завершения синхронизации. Из этого нельзя выводить срок обновления любого AI-поиска. Для выбранного решения нужно выяснить его собственный порядок и проверить результат запросом.
В нашем вымышленном регламенте можно изменить согласующего, затем повторить тот же вопрос. Проверка должна показать не только появление новой редакции, но и прекращение использования отменённой как действующей. Отдельно стоит отменить документ без замены: в этом случае поиск не должен продолжать выдавать прежнее правило только потому, что больше ничего не нашлось.
Допустимую задержку обновления определяет компания с учётом процесса, а исполнитель согласует и реализует технический механизм. Нужно также решить, как поступать в промежутке: можно ли пользоваться ответами, требуется ли временно закрыть этот сценарий и кто узнает о сбое обновления. Универсальный срок здесь был бы произвольным — требования к справочной инструкции и к правилу, по которому принимают значимое решение, могут различаться.
Если в базе остались противоречащие друг другу документы, для первого сценария разумно требовать явного сообщения о недостатке оснований для однозначного ответа. У системы должен быть согласованный способ направить сотрудника к владельцу процесса. Выяснить, какое правило действительно, предстоит компании; обеспечить предусмотренное поведение поиска — исполнителю.
Кто сможет увидеть документы через AI
Права нужно проверять на содержимом ответа. Если сотрудник не вправе читать документ, недостаточно скрыть от него ссылку, оставив пересказ закрытого текста. Поэтому в условия приёмки следует включить весь путь: какие фрагменты использованы для генерации, что показано в ответе и цитате, куда ведёт ссылка на источник.
В документации Azure AI Search описаны разные механизмы контроля доступа к документам. В частности, фильтры могут исключать документы по идентификатору пользователя или группы. Для описанных встроенных механизмов проверка использует метаданные прав, синхронизированные с поисковым индексом; изменения в источнике отражаются в результатах после соответствующего обновления этих метаданных. Некоторые возможности отмечены как предварительные версии (preview). Это основание уточнить поддерживаемый механизм и его ограничения, а не считать, что любой AI-поиск автоматически перенесёт все права из исходной базы.
Практическую проверку стоит провести под разными ролями. Пользователь с доступом должен получить разрешённую информацию. Пользователь без доступа — не получить её ни в готовом ответе, ни в цитате. Затем у первого пользователя нужно отозвать право и повторить запрос по согласованному порядку обновления доступа. Проверка только под учётной записью администратора не отвечает на вопрос, что увидит обычный сотрудник.
До такого испытания следует согласовать безопасный тестовый набор и условия подключения. Не стоит начинать с передачи всего внутреннего архива в неизвестную среду ради эффектной демонстрации. Проверку прав можно спланировать на специально подготовленных документах, а подключение реальных данных рассматривать отдельно, с ответственными за их использование.
Как принять первый сценарий и когда остановиться
Для первого испытания нужен небольшой набор вопросов, по которым владелец процесса заранее определил ожидаемый смысл ответа. В него стоит включить ситуации, где правильным результатом будет признание недостатка оснований. Иначе поведение поиска при недостатке оснований останется непроверенным.
Ниже — предлагаемые условия приёмки, а не результаты проведённых испытаний. Формулировки нужно уточнить под выбранный процесс и решение.
| Ситуация | Что считать пригодным результатом |
|---|---|
| В действующем документе есть явное правило | Ответ сохраняет существенные условия и позволяет открыть подтверждающий фрагмент. |
| Сотрудник спрашивает об исключении | Поиск объясняет опубликованный порядок и полномочия, не выдавая согласование от имени руководителя. |
| Правило изменено или отменено | После согласованного обновления ответ учитывает изменение; отменённая редакция не выдаётся за действующую. |
| Документы противоречат друг другу | Поиск сообщает о противоречии и направляет к ответственному, не выбирая правило без согласованного основания. |
| В доступных документах нет ответа | Система прямо сообщает, что оснований недостаточно, и не додумывает корпоративное правило. |
| У сотрудника нет доступа или доступ отозван | В предусмотренных условиях проверки закрытое содержимое не появляется в ответе и цитатах; переход к источнику также учитывает права. |
При испытании полезно сохранять вопрос, роль пользователя, версию документов, ответ и найденное расхождение. Это позволит обсуждать конкретную ошибку: потерянное условие, старую редакцию, закрытый фрагмент или неподтверждённый вывод. Одна оценка «ответ хороший» не объясняет, что именно готово к работе.
Результат проверки может привести к разным решениям. Если обычный поиск уже позволяет находить нужное правило, генерацию можно не добавлять. Если компания не определила действующий документ или владельца процесса, работу над этим сценарием стоит приостановить до решения вопроса. Если готовое решение проходит согласованные проверки, собственной разработки может не потребоваться. Обсуждать её имеет смысл, когда понятны конкретные ограничения и можно сравнить необходимый результат, удобство, полную стоимость и поддержку.
Успешное испытание ограниченного сценария не доказывает пригодность поиска для всего архива. Оно даёт основание решить, можно ли использовать его в проверенных границах и что проверять следующим. Ошибки и ограничения нужно сохранить, а при существенном изменении документов, прав или поведения системы — повторить соответствующие испытания.
Компания отвечает за содержание правил, назначение ответственных, предоставление прав и управленческие решения. Исполнитель отвечает за согласованный технический и функциональный результат, включая предусмотренные договорённостями обновление, контроль доступа и поведение при недостатке данных. Обучение и помощь при запуске также остаются его обязательствами, если входят в согласованный объём. Такое разделение позволяет обсуждать неисправность системы, не перекладывая её на сотрудников, и не требовать от разработчика определить внутреннюю политику компании.
Если компания рассматривает AI-поиск, следующий полезный шаг — выбрать вопрос, из-за которого сотрудникам уже приходится обращаться за разъяснениями, и описать пригодный ответ. Обсудить задачу можно на этом конкретном сценарии: какие документы нужны, кто ими управляет и что потребуется проверить до запуска.
Источники
- Microsoft Learn: Retrieval-augmented generation in Azure AI Search — принцип RAG, подготовка содержимого и контроль доступа.
- Microsoft Learn: Document-level access control in Azure AI Search — механизмы прав на документы, синхронизация метаданных и ограничения отдельных возможностей.
- Amazon Bedrock: Query a knowledge base and generate responses based off the retrieved data — связь ответа с цитируемыми фрагментами источников.
- Amazon Bedrock: Sync your data with your Amazon Bedrock knowledge base — обновление данных после изменений в источнике.
Документация описывает механизмы конкретных продуктов, не подтверждает качество их работы в любой компании. Ситуация с исключением из регламента вымышлена; условия приёмки предложены для проверки, а не представлены как проведённый тест.