Обнаружение изменений и удалений с помощью индексаторов для службы хранения Azure в Поиск с использованием ИИ Azure

Замечание

Поиск с использованием ИИ Azure доступна через портал Azure, REST API и Azure SDKs. Он также лежит в основе Foundry IQ — управляемого слоя знаний, который преобразует корпоративный контент в многократно используемые базы знаний с учетом разрешений доступа для агентов на портале Microsoft Foundry.

Important

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

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

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

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

Хотя обнаружение изменений считается само собой разумеющимся, обнаружение удаления – нет. Индексатор не отслеживает удаление объектов в источниках данных. Чтобы избежать появления бесхозных документов поиска, можно реализовать стратегию "мягкого удаления", которая сначала приводит к удалению документов поиска, а физическое удаление в служба хранилища Azure выполняется следующим шагом.

Существует два способа реализации стратегии мягкого удаления:

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

Предпосылки

  • Используйте индексатор хранилища Azure для хранилища Blob, хранилища таблиц, файлового хранилища или Data Lake Storage 2-го поколения

  • Используйте согласованные ключи документов и структуру файлов. Изменение ключей документов или имен каталогов и путей (применяется к ADLS 2-го поколения) нарушает внутренние данные отслеживания, используемые индексаторами, чтобы узнать, какое содержимое индексировано, и когда он был последним индексирован.

Замечание

ADLS 2-го поколения позволяет переименовать каталоги. При переименовании каталога временные метки для блобов в этом каталоге не обновляются. В результате индексатор не будет переиндексировать эти блобы. Если вам нужно, чтобы блобы в каталоге были переиндексированы после переименования каталога, так как у них теперь есть новые URL-адреса, необходимо обновить LastModified метку времени для всех блобов в каталоге, чтобы индексатор знал повторно их индексировать при следующем запуске. Виртуальные каталоги в хранилище BLOB-объектов Azure не могут быть изменены, поэтому у них нет этой проблемы.

Обратимое удаление собственного BLOB-объекта

Для этого подхода к обнаружению удаления служба поиска ИИ Azure зависит от функции обратимого удаления большого двоичного объекта в Хранилище BLOB-объектов Azure, чтобы определить, перешли ли большие двоичные объекты в обратимое удаленное состояние. При обнаружении BLOB-объектов в этом состоянии индексатор поиска использует эту информацию для удаления соответствующего документа из индекса.

Требования к встроенному мягкому удалению

  • BLOB-объекты должны находиться в контейнере хранилища BLOB-объектов Azure, включая контейнер для BLOB-объектов ADLS Gen2. Политика мягкого удаления собственных BLOB-объектов, присущая службе "Поиск ИИ Azure", не поддерживается для файлов Azure.

  • Включение мягкого удаления для BLOB-объектов.

  • Ключи документов в индексе должны быть сопоставлены с BLOB-свойством или метаданными BLOB, такими как "metadata_storage_path".

  • Вы можете использовать REST API или конфигурацию источника данных индексатора в портале Azure для настройки поддержки обратимого удаления.

  • Версионирование BLOB-объектов не должно быть включено в учетной записи хранения. В противном случае встроенное мягкое удаление не поддерживается по замыслу.

Настройка встроенного мягкого удаления

В хранилище BLOB-объектов, при включении мягкого удаления в соответствии с требованиями, установите политику хранения на более длительный срок, чем расписание интервалов индексатора. Если возникает проблема с индексатором или если у вас много документов для индексирования, у индексатора будет достаточно времени, чтобы постепенно обработать мягко удаленные двоичные объекты. Индексаторы поиска Azure AI удаляют документ из индекса только в том случае, если они обрабатывают большой двоичный объект, находящийся в состоянии мягкого удаления.

В службе "Поиск ИИ Azure" задайте собственную политику обнаружения обратимого удаления BLOB-объектов в источнике данных. Это можно сделать на портале Azure или с помощью REST API. В следующих инструкциях объясняется, как задать политику обнаружения удаления в портале Azure или с помощью REST API.

  1. Перейдите в службу поиска в портал Azure.

  2. На странице обзора службы поиска Azure AI перейдите в Новый источник данных, визуальный редактор для определения источника данных.

    На следующем снимке экрана показано, где можно найти эту функцию в портал Azure.

    Снимок экрана: конфигурация источника данных в мастере импорта данных.

  3. На форме нового источника данных заполните обязательные поля, установите флажок «Отслеживать удаления» и выберите «Обратимое удаление собственного объекта BLOB». Затем нажмите кнопку "Сохранить", чтобы включить функцию создания источника данных.

    Скриншот мягкого удаления родного источника данных портала.

Переиндексировать неудаленные двоичные объекты с помощью наличных политик мягкого удаления.

При восстановлении мягко удаленного BLOB-объекта в хранилище, индексатор не обязательно переиндексирует его. Это связано с тем, что индексатор использует метку времени объекта BLOB LastModified, чтобы определить необходимость индексации. Если мягко удаленный большой двоичный объект восстановлен, его LastModified метка времени не обновляется, поэтому, если индексатор уже обработал большие двоичные объекты с более новыми LastModified метками времени, он не будет переиндексировать восстановленный большой двоичный объект.

Чтобы убедиться, что неудаленный BLOB переиндексирован, обновите его метку времени LastModified. Один из способов сделать это — повторно сохранить метаданные объекта BLOB. Вам не нужно изменять метаданные, но повторное сохранение метаданных обновляет метку времени большого двоичного объекта LastModified, чтобы индексатор знал, что его нужно учитывать.

Стратегия обратимого удаления с помощью пользовательских метаданных

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

Эта функция общедоступна.

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

  1. В службу хранения Azure добавьте в файл произвольную пару ключ-значение в метаданных, чтобы указать, что файл помечен для удаления. Например, можно присвоить свойству IsDeleted значение false. Если вы хотите удалить файл, измените его на true.

  2. В поиске ИИ Azure измените определение источника данных, чтобы включить свойство dataDeletionDetectionPolicy. Например, следующая политика считает, что файл удаляется, если он имеет свойство IsDeleted метаданных со значением true:

    PUT https://[service name].search.windows.net/datasources/file-datasource?api-version=2026-04-01
{
    "name" : "file-datasource",
    "type" : "azurefile",
    "credentials" : { "connectionString" : "<your storage connection string>" },
    "container" : { "name" : "my-share", "query" : null },
    "dataDeletionDetectionPolicy" : {
        "@odata.type" :"#Microsoft.Azure.Search.SoftDeleteColumnDeletionDetectionPolicy",
        "softDeleteColumnName" : "IsDeleted",
        "softDeleteMarkerValue" : "true"
    }
}

  3. Запустите индексатор. После обработки файла и удаления документа из индекса поиска можно удалить физический файл в службе хранилища Azure.

Переиндексировать неудаленные блобы и файлы

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

  1. Измените "softDeleteMarkerValue" : "false" для блоба или файла в службе хранилища Azure.

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

  3. Запустите индексатор.

Ограничения

При использовании сценариев индексирования один ко многим не применяется ни встроенное обратимое удаление, ни обратимое удаление с использованием пользовательских метаданных. Чтобы удалить запись документа, необходимо отправить запрос на удаление в индекс с помощью операции удаления REST API.

Дальнейшие шаги

  • Last updated on