Поделиться через

Индексирование больших наборов данных в поиске ИИ Azure

  • Статья

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

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

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

Мы рекомендуем использовать более новую службу поиска, созданную после 3 апреля 2024 г., для более высокого уровня хранилища на секцию.

Примечание.

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

Индексирование данных с помощью API push-уведомлений

Api push-интерфейсы , такие как REST API индекса документов или метод IndexDocuments (Azure SDK для .NET), являются наиболее распространенной формой индексирования в службе "Поиск ИИ Azure". Для решений, использующих API push-уведомлений, стратегия долгосрочного индексирования имеет один или оба из следующих компонентов:

  • Пакетные документы
  • Управление потоками

Пакетное несколько документов на запрос

Простой механизм индексирования большого количества данных заключается в отправке нескольких документов или записей в одном запросе. Если вся полезные данные составляет до 16 МБ, запрос может обрабатывать до 1000 документов в операции массовой отправки. Эти ограничения применяются к использованию REST API индекса документов или метода IndexDocuments в пакете SDK для .NET. Используя любой API, вы можете упаковыть 1000 документов в текст каждого запроса.

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

  • схема индекса;
  • размер данных.

Так как оптимальный размер пакета зависит от индекса и данных, лучше всего протестировать различные размеры пакетов, чтобы определить, какие результаты приводят к самым быстрым скоростям индексирования для вашего сценария. Пример кода для тестирования размеров пакетов с помощью пакета SDK для .NET см. в руководстве по оптимизации индексирования с помощью API push-уведомлений.

Управление потоками и стратегией повторных попыток

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

  1. Увеличьте число параллельных потоков в клиентском коде.

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

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

    • 207 Multi-Status: эта ошибка означает, что некоторые документы успешно выполнены, но по крайней мере один произошел сбой.

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

Пакет SDK для Azure .NET автоматически повторяет 503 и другие неудачные запросы, но необходимо реализовать собственную логику для повтора 207s. Также для реализации стратегии повторных попыток можно использовать средства с открытым кодом, например Polly.

Использование индексаторов и API извлечения

Индексаторы имеют несколько возможностей, полезных для длительных процессов:

  • Пакетные документы
  • Параллельное индексирование секционированных данных
  • Планирование и обнаружение изменений для индексирования только новых и измененных документов с течением времени

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

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

Проверка размера пакета индексатора

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

Размеры пакетов по умолчанию зависят от источника данных. База данных SQL Azure и Azure Cosmos DB имеют размер пакета по умолчанию в 1000. При индексировании же BLOB-объектов Azure размер пакета задается равным 10 документам с учетом того, что размер документа больше среднего.

Планирование индексаторов для длительных процессов

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

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

{
    "dataSourceName" : "hotels-ds",
    "targetIndexName" : "hotels-idx",
    "schedule" : { "interval" : "PT2H", "startTime" : "2024-01-01T00:00:00Z" }
}

Если в источнике данных больше нет новых или обновленных документов, журнал выполнения индексатора сообщает 0/0 о обработанных документах и не выполняется обработка.

Дополнительные сведения о настройке расписаний см. в разделе "Создание REST API индексатора" или " Планирование индексаторов" для поиска ИИ Azure.

Примечание.

Некоторые индексаторы, которые выполняются в старой архитектуре среды выполнения, имеют 24-часовое, а не 2-часовое максимальное окно обработки. Ограничение на два часа — для новых процессоров содержимого, работающих во внутренне управляемой мультитенантной среде. По возможности поиск Azure AI пытается выгрузить индексатор и обработку набора навыков в мультитенантную среду. Если индексатор не может быть перенесен, он выполняется в частной среде и может работать до 24 часов. Если вы запланируете индексатор, который отображает эти характеристики, предположим, 24-часовое окно обработки.

Параллельное выполнение индексаторов

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

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

Количество заданий индексирования, которые могут выполняться одновременно, зависит от текстового и навыков индексирования. Дополнительные сведения см. в разделе "Выполнение индексатора".

Если источник данных является контейнером Хранилище BLOB-объектов Azure или Azure Data Lake Storage 2-го поколения, перечисление большого количества больших двоичных объектов может занять много времени (даже часов), пока эта операция не завершится. В результате количество документов индексатора успешно выполнено, как представляется, не увеличивается в течение этого времени, и может показаться, что это не делает никаких прогрессов, когда это так. Если вы хотите ускорить обработку документов для большого количества больших двоичных объектов, рассмотрите возможность секционирования данных на несколько контейнеров и создание параллельных индексаторов, указывающих на один индекс.

  1. Войдите в портал Azure и проверьте количество единиц поиска, используемых службой поиска. Выберите "Масштаб параметров">, чтобы просмотреть число в верхней части страницы. Число индексаторов, выполняющихся параллельно, приблизительно равно количеству единиц поиска.

  2. Исходные данные секционирования между несколькими контейнерами или несколькими виртуальными папками в одном контейнере.

  3. Создайте несколько источников данных, по одному для каждой секции, в паре с собственным индексатором.

  4. Укажите один и тот же целевой индекс поиска в каждом индексаторе.

  5. Запланируйте индексаторы.

  6. Просмотрите состояние индексатора и журнал выполнения для подтверждения.

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

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

Хотя наборы из нескольких индексаторов и источников данных могут обслуживать один и тот же индекс, при запуске индексаторов следует соблюдать осторожность, так как они могут перезаписывать существующие значения в индексе. Если второй индексатор-источник данных предназначен для одних и того же документа и полей, все значения из первого запуска перезаписываются. Значения полей заменяются в полном объеме; Индексатор не может объединять значения из нескольких запусков в одном поле.

Индексирование больших данных в Spark

Если у вас есть архитектура больших данных и данные в кластере Spark, рекомендуется использовать SynapseML для загрузки и индексирования данных. В этом руководстве приведены шаги по вызову служб ИИ Azure для обогащения ИИ, но вы также можете использовать API AzureSearchWriter для индексирования текста.

Связанный контент