Чтобы проверить удаление документа из базы ИИ-бота, недостаточно увидеть, что файл исчез из списка. Нужно проверить, что отозванный источник больше не находится поиском и не попадает в новый ответ. Прежний разговор проверяют отдельно: в нём уже мог сохраниться текст документа. После следующей синхронизации проверку повторяют, чтобы файл не вернулся из подключённого источника.
Ниже порядок приёмки для руководителя и исполнителя. Это документальный разбор и учебный сценарий, а не результат испытания конкретного бота. Он касается исключения источника из ответов. Удаление резервных копий, журналов и данных у поставщика требует отдельной проверки.
Почему удалённый файл ещё может влиять на ответ
У бота могут быть разные места хранения: исходная папка, поисковый индекс с фрагментами документов и история разговора. Индекс здесь означает подготовленную базу, по которой бот ищет подходящий текст. Удаление в одном месте не подтверждает изменение остальных.
Например, справка Yandex AI Studio отдельно предупреждает: файл, удалённый из поискового индекса, остаётся в хранилище файлов. Это два разных действия. Названия кнопок и порядок удаления уточняйте для своего сервиса.
Есть и обратный случай: удаление оригинала не убрало поисковую копию. В документации Azure AI Search описаны документы, оставшиеся в индексе без исходников. Для некоторых подключений удаление нужно обнаружить до физического удаления оригинала. Поэтому не начинайте с массовой очистки папок: сначала согласуйте с исполнителем маршрут для одного файла.
Если база ещё не собрана, начните с подготовки документов для ИИ-ассистента. Здесь задача уже другая: принять отзыв конкретного источника в работающей системе.
Что зафиксировать до удаления
Попросите исполнителя назвать точный файл, его версию и все базы, куда он подключён. Одинаковое имя у двух файлов не означает, что это один объект. Если документ разбит на фрагменты, нужна связь каждого фрагмента с исходником.
Для безопасной пробы используйте отдельную тестовую базу без клиентов, персональных данных и действующих коммерческих условий. Не загружайте вымышленные правила в рабочий бот. Подготовьте два учебных документа:
- «Учебная доставка»: «Для учебного заказа ЛИПА-47 доступен только самовывоз». Это отзываемый источник.
- «Учебная оплата»: «Учебный заказ ОЛЬХА-83 оплачивается после подтверждения». Это контрольный источник, который остаётся.
Названия заказов и условия вымышлены. До удаления задайте отдельные вопросы про получение ЛИПА-47 и оплату ОЛЬХА-83. Сохраните ответы, найденные фрагменты и их идентификаторы, если сервис их показывает. Если бот и до удаления не использовал первый файл, эта проба не покажет, что изменилось после отзыва: сначала разберите исходную ошибку.
Заранее запишите ожидаемый результат. В новом разговоре бот не должен утверждать условие самовывоза как действующее правило из отозванного источника. Контрольное условие оплаты должно оставаться доступным. Одного совпавшего слова «самовывоз» недостаточно, чтобы доказать использование файла: нужен контекст ответа и доступный след поиска.
Как проверить поиск и новый разговор
Согласуйте удаление только учебного источника и дождитесь завершения нужной операции. У разных систем это может быть отдельное удаление из индекса или обновление через подключённый источник. Например, Amazon Bedrock требует синхронизировать источник после удаления файлов. Сохраните итог операции и ошибки по документам, а не только сообщение «запрос отправлен».
Затем проверьте результат по порядку:
- Проверьте запись и её фрагменты. Попросите исполнителя показать отсутствие конкретного источника и связанных фрагментов в доступном списке или по идентификаторам. В Azure AI Search для удалённой записи предусмотрена проверка повторным чтением по ключу. Сверяйте именно документ: ошибка доступа или неверное имя индекса не подтверждают удаление.
- Выполните поиск без генерации ответа, если сервис это позволяет. Используйте прежний вопрос и несколько других формулировок той же задачи. Сохраните найденные фрагменты и ошибки. Пустая выдача одного запроса сама по себе не доказывает, что все копии удалены.
- Начните действительно новый разговор через тот же канал бота. Не прикладывайте старый документ и не подсказывайте его условие в вопросе. Спросите, как получить учебный заказ ЛИПА-47. Сверьте ответ и доступный журнал поиска. Если в оставшихся материалах ответа нет, бот не должен представлять прежнее условие как подтверждённое.
- Проверьте оставшийся документ. Спросите про оплату ОЛЬХА-83. Если пропали оба ответа, возможно, отключена вся база. Это ещё не успешный отзыв одного источника.
Не ограничивайтесь фразой бота «я забыл файл». Отсутствие ссылки тоже не доказывает, что текст не использовался. Если сервис скрывает поиск и переданные модели фрагменты, фиксируйте границу: ответы проверены, внутреннее исключение источника не подтверждено.
Зачем проверять прежний разговор и синхронизацию
Вернитесь к диалогу, в котором бот уже отвечал по отзываемому документу. Его прошлый ответ остаётся частью разговора, если приложение продолжает передавать эту историю модели. Поэтому повтор старого условия в этом диалоге ещё не доказывает, что поиск снова нашёл удалённый файл. Попросите исполнителя проверить состав переданного контекста: историю, сохранённые сводки и найденные фрагменты.
Для устаревших коммерческих условий заранее определите поведение старых диалогов: например, бот должен перепроверить правило по действующему источнику или передать вопрос сотруднику. Новый чат сам по себе не исправляет ответы в уже открытых разговорах клиентов. Выбранное поведение нужно отдельно испытать в вашем приложении.
Наконец, дождитесь следующего штатного обновления базы или запустите согласованную тестовую синхронизацию. В инструкции Amazon Bedrock есть конкретное предупреждение: документ, удалённый напрямую из базы, остаётся в подключённом S3-хранилище и может вернуться при синхронизации. Проверьте подключённый источник и повторите поиск и оба контрольных вопроса после обновления.
С каким результатом принимать работу
Учебная проба проверяет сам способ, но не подтверждает отзыв вашего рабочего документа. Перед приёмкой повторите применимые проверки для реального отзываемого источника в согласованной среде: по его идентификаторам, известным вопросам и оставшемуся контрольному материалу. Не копируйте закрытый текст в общедоступный журнал.
Сохраните короткий акт проверки: файл и версия, связанные базы, время операции, её статус, результаты поиска, ответы нового и прежнего диалогов, результат после синхронизации. Приложите полные ответы, включая неудачные повторы. Учебный набор не даёт процента надёжности всего бота.
Принимать отзыв источника можно в пределах проверенного: нужная запись и её фрагменты исключены доступными средствами, новые ответы не опираются на отозванное правило, контрольный материал работает, после обновления источник не вернулся. Поведение прежних диалогов соответствует отдельно согласованному правилу.
Если старый фрагмент снова найден, отзыв не завершён. Если бот повторяет условие, но след поиска недоступен, причина неизвестна: проверьте другие копии, историю и сохранённые ответы с исполнителем. Не называйте это доказанным «обучением модели на вашем файле». Эта проверка не устанавливает ни использование данных для обучения, ни полное стирание у поставщика.