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

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

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

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

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

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

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

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

Обработка нескольких документов в одном запросе

Простой механизм индексирования большого количества данных заключается в отправке нескольких документов или записей в одном запросе. При условии, что весь полезный объем не превышает 16 МБ, запрос может обрабатывать до 1000 документов в операции массовой загрузки. Эти ограничения применяются независимо от того, используете ли вы REST API индекса документов либо метод IndexDocuments в .NET SDK. Используя любой 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. В отличие от этого, при индексировании Azure Blob и SharePoint (предварительная версия) размер пакета задается равным 10 документам с учетом большего среднего размера документов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Распределить исходные данные между несколькими контейнерами или несколькими виртуальными папками внутри одного контейнера.

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

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

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

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

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

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

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

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

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

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

• Руководство. Оптимизация индексирования с помощью API push-уведомлений
• Руководство. Индексирование больших данных из Apache Spark с помощью SynapseML и поиска ИИ Azure
• Советы по повышению производительности в поиске ИИ Azure
• Анализ производительности в поиске ИИ Azure
• Индексаторы в поиске ИИ Azure
• Мониторинг состояния индексатора и результатов поиска ИИ Azure