Как я поддерживаю актуальность базы знаний AI-помощника

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

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

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

Сначала определяю, какая версия действует

Мне нужен утверждённый источник и человек, который отвечает за его содержание. Папка с названиями «финал», «финал новый» и «последняя версия» плохо подходит для такого соглашения.

Для каждого важного документа я предлагаю записать:

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

Дата загрузки и дата вступления правила в силу могут различаться. Новую инструкцию можно подготовить заранее. А старый документ можно пересохранить сегодня, не сделав его снова действующим. Поэтому правило «берите самый свежий файл» я считаю недостаточным.

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

Разделяю документ и его поисковую копию

Для быстрого поиска система может создавать отдельное представление документа: извлечённый текст, фрагменты и поисковый индекс. Индекс — подготовленный набор записей, по которому ищут подходящие сведения. Между изменением оригинала и обновлением этих записей есть отдельная техническая работа.

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

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

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

Проверяю замену, удаление и перенос отдельно

Обновление текста — только один вид изменения. Документ могут отозвать целиком, перенести в другую папку, разделить на несколько инструкций или оставить в архиве для истории.

Для каждого случая нужен понятный результат:

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

Это различие есть и в конкретных инструментах. Например, документация Azure AI Search об изменении и удалении источников отдельно описывает обнаружение изменений и удалений: удаление файла в хранилище само по себе не гарантирует очистку поискового индекса. Конкретный механизм зависит от источника и способа индексирования. Для меня практический вывод — проверять отзыв документа отдельным сценарием.

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

Проверяю права вместе с содержанием

У документа может измениться круг читателей, даже если сам текст остался прежним. Я включаю такие изменения в порядок обновления базы знаний.

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

В обзоре доступа к документам Azure AI Search контроль разрешений рассматривается на пути от загрузки до выполнения запроса. Это пример технического подхода, а не утверждение, что любой помощник автоматически наследует права корпоративных папок. Способ реализации нужно проверить в конкретной системе.

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

Принимаю обновление через вопросы сотрудников

Сообщения «обработка завершена» мне недостаточно. После изменения источников я предлагаю задать вопросы, на которые это изменение должно повлиять, и несколько прежних вопросов, ответы на которые должны сохраниться.

Для условной инструкции технической поддержки проверка может выглядеть так:

Ожидаемый результат определяет владелец содержания. Я дополнительно проверяю открытие ссылки, найденную версию источника и то, что помощник не смешал условия из разных документов.

Общий подход к такой проверке описан в статье о контрольной выборке для AI-пилота. Здесь я применяю его к изменению документов: беру конкретное правило и смотрю, действительно ли оно дошло до ответов.

Договариваюсь о задержке и реакции на сбой

Для разных источников допустимая задержка обновления может быть разной. Её стоит согласовать с владельцем процесса исходя из последствий устаревшего ответа. Общее обещание «всё всегда актуально» не объясняет, как поступить, когда обработка остановилась.

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

Если новая инструкция уже действует, а помощник её ещё не использует, нужен временный порядок: например, сотрудник открывает утверждённый источник напрямую. Решение ограничить затронутый сценарий принимается по его риску. Подробный разбор сбоев я вынес в материал о работе с ошибками AI-помощника.

Оставляю запись, по которой можно восстановить изменение

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

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

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

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