Руководство по устранению неполадок индексатора для поиска ИИ Azure

Мақала
09/01/2024

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

Примечание.

Если у вас есть ошибка поиска ИИ Azure, см . статью "Устранение распространенных ошибок и предупреждений индексатора".

Устранение неполадок подключений к ограниченным ресурсам

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

Правила брандмауэра

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

The remote server returned an error: (403) Forbidden
This request is not authorized to perform this operation
Credentials provided in the connection string are invalid or have expired

Есть 2 варианта разрешить индексаторам доступ к этим ресурсам в таком случае. Они указаны ниже.

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

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

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

Правила группы безопасности сети (NSG)

Когда индексатор обращается к данным управляемого экземпляра SQL или когда виртуальная машина Azure используется в качестве URI веб-службы для пользовательского навыка, группа безопасности сети определяет, разрешены ли запросы.

Для внешних ресурсов, размещенных в виртуальной сети, настройте правила Входящего NSG для тега AzureCognitiveSearch службы.

Дополнительные сведения о подключении к виртуальной машине см. в статье "Настройка подключения к SQL Server" на виртуальной машине Azure.

Ошибки сети.

Как правило, сетевые ошибки являются универсальными. Ниже перечислены некоторые распространенные ошибки.

A network-related or instance-specific error occurred while establishing a connection to the server
The server was not found or was not accessible
Verify that the instance name is correct and that the source is configured to allow remote connections

При получении любого из этих ошибок:

Убедитесь, что источник доступен, пытаясь подключиться к нему напрямую, а не через службу поиска.
Проверьте ресурс в портал Azure для любых текущих ошибок или сбоев
Проверка всех сетевых сбоев в состоянии Azure
Убедитесь, что вы используете общедоступный DNS для разрешения имен, а не azure Частная зона DNS

База данных SQL Azure бессерверное индексирование (код ошибки 40613)

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

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

Политики условного доступа Microsoft Entra

При создании индексатора SharePoint Online необходимо выполнить вход в приложение Microsoft Entra после предоставления кода устройства. Если вы получаете сообщение, которое говорится "Your sign-in was successful but your admin requires the device requesting access to be managed", индексатор, вероятно, заблокирован из библиотеки документов SharePoint политикой условного доступа .

Чтобы обновить политику и разрешить индексатору доступ к библиотеке документов:

Откройте портал Azure и найдите условный доступ Microsoft Entra.
В меню слева выберите Политики. Если у вас нет доступа к просмотру этой страницы, необходимо либо найти кого-то, кто имеет доступ, либо получить доступ.
Определите, какая политика блокирует доступ индексатора SharePoint Online к библиотеке документов. Политика, которая может блокировать индексатор, включает учетную запись пользователя, используемую для проверки подлинности во время этапа создания индексатора в разделе "Пользователи и группы ". Политика также может иметь Условия, которые:
- ограничивают платформы Windows;
- ограничивают мобильные приложения и настольные клиенты;
- имеют параметр Состояние устройства со значением Да.
Убедившись, какая политика блокирует индексатор, сделайте исключение для индексатора. Начните с получения IP-адреса службы поиска.

Сначала получите полное доменное имя службы поиска. Полное доменное имя выглядит следующим образом <your-search-service-name>.search.windows.net. Полное доменное имя можно найти в портал Azure.

Теперь, когда у вас есть полное доменное имя, получите IP-адрес службы поиска, выполнив nslookup полное доменное имя (или а ping). В следующем примере вы добавите "150.0.0.1" в правило входящего трафика в брандмауэре служба хранилища Azure. Индексатор службы поиска может получить доступ к учетной записи службы хранилища Azure в течение 15 минут после обновления параметров брандмауэра.
```
nslookup contoso.search.windows.net
Server:  server.example.org
Address:  10.50.10.50

Non-authoritative answer:
Name:    <name>
Address:  150.0.0.1
Aliases:  contoso.search.windows.net
```
Получите диапазоны IP-адресов для среды выполнения индексатора в вашем регионе.

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

Диапазоны IP-адресов для тега AzureCognitiveSearch службы можно получить с помощью API обнаружения или скачиваемого JSON-файла.

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

В JSON-файле, предполагая, что служба поиска находится в западной части США, список IP-адресов для среды выполнения мультитенантного индексатора приведен ниже.
```
    {
      "name": "AzureCognitiveSearch.WestCentralUS",
      "id": "AzureCognitiveSearch.WestCentralUS",
      "properties": {
        "changeNumber": 1,
        "region": "westcentralus",
        "platform": "Azure",
        "systemService": "AzureCognitiveSearch",
        "addressPrefixes": [
          "52.150.139.0/26",
          "52.253.133.74/32"
        ]
      }
    }
```
Вернитесь на страницу условного доступа на портале Azure и щелкните Именованные расположения в меню слева, а затем выберите Расположение в диапазонах IP-адресов. Присвойте новому именованному расположению имя и добавьте диапазоны IP-адресов для сред выполнения индексатора и службы поиска, собранные в последних двух шагах. 1
- Для IP-адреса службы поиска может потребоваться добавить "/32" в конец IP-адреса, так как он принимает только допустимые диапазоны IP-адресов.
- Помните, что для диапазонов IP-адресов среды выполнения индексатора нужно добавить только диапазоны IP-адресов для региона, в котором находится служба поиска.
Исключите новое именованное расположение из политики:
1. В меню слева выберите Политики.
2. Выберите политику, блокирующую индексатор.
3. Выберите Условия.
4. Выберите Расположения.
5. Выберите Исключить и добавьте новое именованное расположение.
6. Выберите Сохранить для сохранения изменений.
Подождите несколько минут, чтобы политика обновилась и применила новые правила политики.
Повторите попытку создать индексатор:
1. Отправьте запрос изменения для созданного объекта источника данных.
2. Повторно отправьте запрос на создание индексатора. Используйте новый код для входа, а затем отправьте другой запрос на создание индексатора.

Индексирование неподдерживаемых типов документов

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

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

PUT https://[service name].search.windows.net/indexers/[indexer name]?api-version=2024-07-01
Content-Type: application/json
api-key: [admin key]

{
  ... other parts of indexer definition
  "parameters" : { "configuration" : { "failOnUnsupportedContentType" : false, "failOnUnprocessableDocument" : false } }
}

Отсутствие документов

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

Нужный документ обновлен уже после выполнения индексатора. Если индексатор находится в расписании, он в конечном итоге повторно запускается и выбирает документ.
Время ожидания индексатора истекло до момента приема документа. Существует максимальное время обработки, после которого документы не обрабатываются. Состояние индексатора можно проверить на портале или путем вызова метода Get Indexer Status (REST API) (Получение состояния индексатора (REST API)).
Сопоставления полей или обогащение с помощью ИИ изменили документ, и его артикуляция в поисковом индексе отличается от ожидаемой.
Значения элемента Отслеживание изменений являются ошибочными или отсутствуют необходимые компоненты. Если значение высокого водяного знака — это дата, заданная в будущем времени, все документы, имеющие более раннюю дату, пропускаются индексатором. Вы можете определить состояние отслеживания изменений индексатора с помощью полей InitialTrackingState и FinalTrackingState в состоянии индексатора. Индексаторы для Sql Azure и MySQL должны иметь индекс в столбце высокой водяной отметки исходной таблицы, или запросы, используемые индексатором, могут истекает.

Совет

Если документы отсутствуют, проверьте используемый запрос, чтобы убедиться, что соответствующий документ не исключается. Чтобы запросить конкретный документ, используйте REST API поиска по документу.

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

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

Документ содержит только отсканированные изображения. Большие двоичные объекты в формате PDF, в которых есть только нетекстовое содержимое, например отсканированные изображения (JPG), не дают никаких результатов в стандартном конвейере индексирования BLOB-объектов. Если у вас есть содержимое изображения с текстовыми элементами, вы можете использовать анализ изображений или OCR для поиска и извлечения текста.
Индексатор больших двоичных объектов индексирует только метаданные. Чтобы извлечь содержимое, индексатор больших двоичных объектов должен быть настроен на извлечение содержимого и метаданных:

PUT https://[service name].search.windows.net/indexers/[indexer name]?api-version=2024-07-01
Content-Type: application/json
api-key: [admin key]

{
  ... other parts of indexer definition
  "parameters" : { "configuration" : { "dataToExtract" : "contentAndMetadata" } }
}

Отсутствует содержимое из Azure Cosmos DB

Поиск ИИ Azure имеет неявную зависимость от индексирования Azure Cosmos DB. Если вы отключите автоматическое индексирование в Azure Cosmos DB, поиск ИИ Azure возвращает успешное состояние, но не сможет индексировать содержимое контейнера. Процессы проверки параметров и включения индексирования описаны в статье Управление индексированием в Azure Cosmos DB.

Несоответствие количества документов между источником данных и индексом

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

Индекс может отстать от реального количества документов, особенно на портале.
Индексатор имеет политику удаленного документа. Удаленные документы учитываются индексатором, если документы индексируются до их удаления.
Если столбец идентификатора в источнике данных не является уникальным. Это относится к источникам данных, которые имеют концепцию столбцов, таких как Azure Cosmos DB.
Если определение источника данных имеет другой запрос, отличный от используемого для оценки количества записей. Например, в базе данных вы запрашиваете количество записей базы данных, а в запросе определения источника данных вы можете выбрать только подмножество записей для индексирования.
Счетчики проверяются по разным интервалам для каждого компонента конвейера: источник данных, индексатор и индекс.
Источник данных содержит файл, сопоставленный со многими документами. Это условие может возникать при индексировании больших двоичных объектов и параметре parsingMode.jsonArray jsonLines

Документы обрабатываются несколько раз

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

Запросы индексатора по запросу выдаются в быстром последовательности
Топология источника данных включает несколько реплик и секций (один из таких примеров рассматривается здесь).
Источник данных — это база данных SQL Azure, а столбец, выбранный как "высокий водяной знак", имеет тип datetime2

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

Пример повторяющейся обработки документов с 30-секундным буфером

Условия, при которых документ обрабатывается дважды, объясняются на следующей временной шкале, которая отмечает каждое действие и действие счетчика. На следующей временной шкале показана проблема:

Временная шкала (чч:мм:сс)	Мероприятие	Индексатор с высокой водой	Комментарий
00:01:00	Запись `doc1` в источник данных с конечной согласованность	`null`	Метка времени документа — 00:01:00.
00:01:05	Запись `doc2` в источник данных с конечной согласованность	`null`	Метка времени документа — 00:01:05.
00:01:10	Запуск индексатора	`null`
00:01:11	Индексатор запрашивает все изменения до 00:01:10; реплика, в которую выполняется запрос индексатора, учитывается только ; извлекается только `doc2doc2` реплика.	`null`	Индексатор запрашивает все изменения перед запуском метки времени, но фактически получает подмножество. Это поведение требует периода буфера обратного просмотра.
00:01:12	Процессы `doc2` индексатора в первый раз	`null`
00:01:13	Индексатор заканчивается	00:01:10	Высокая водяной знак обновляется до начальной метки времени выполнения текущего индексатора.
00:01:20	Запуск индексатора	00:01:10
00:01:21	Индексатор запрашивает все изменения в диапазоне от 00:00:40 до 00:01:20; реплика, которую выполняет запрос индексатора, должна учитывать `doc1` оба и; извлекает и `doc2`извлекает `doc1doc2`	00:01:10	Индексатор запрашивает все изменения между текущей высокой водой минус 30 секунд буфера и начальной меткой времени текущего выполнения индексатора.
00:01:22	Процессы `doc1` индексатора в первый раз	00:01:10
00:01:23	Процессы `doc2` индексатора во второй раз	00:01:10
00:01:24	Индексатор заканчивается	00:01:20	Высокая водяной знак обновляется до начальной метки времени выполнения текущего индексатора.
00:01:32	Запуск индексатора	00:01:20
00:01:33	Индексатор запрашивает все изменения в диапазоне от 00:00:50 до 00:01:32; извлекает `doc1` и `doc2`	00:01:20	Индексатор запрашивает все изменения между текущей высокой водой минус 30 секунд буфера и начальной меткой времени текущего выполнения индексатора.
00:01:34	Процессы `doc1` индексатора во второй раз	00:01:20
00:01:35	Процессы `doc2` индексатора в третий раз	00:01:20
00:01:36	Индексатор заканчивается	00:01:32	Высокая водяной знак обновляется до начальной метки времени выполнения текущего индексатора.
00:01:40	Запуск индексатора	00:01:32
00:01:41	Индексатор запрашивает все изменения в диапазоне от 00:01:02 до 00:01:40; Извлекает `doc2`	00:01:32	Индексатор запрашивает все изменения между текущей высокой водой минус 30 секунд буфера и начальной меткой времени текущего выполнения индексатора.
00:01:42	Процессы `doc2` индексатора в четвертый раз	00:01:32
00:01:43	Индексатор заканчивается	00:01:40	Обратите внимание, что выполнение индексатора началось более 30 секунд после последней записи в источник данных, а также обработано `doc2`. Это ожидаемое поведение, так как если все выполнение индексатора до 00:01:35 устранено, это становится первым и единственным выполнением для обработки `doc1` и `doc2`.

На практике этот сценарий происходит только в том случае, если индексаторы по запросу вызываются вручную в течение нескольких минут для определенных источников данных. Это может привести к несоответствию чисел (например, индексатор обрабатывает 345 документов в соответствии со статистикой выполнения индексатора, но есть 340 документов в источнике данных и индексе) или потенциально увеличить выставление счетов, если вы выполняете одни и те же навыки для одного документа несколько раз. Запуск индексатора с помощью расписания является предпочтительной рекомендацией.

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

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

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

Индексирование документов с метками конфиденциальности

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

Бөлісу құралы: