Устранение неполадок в хранении и несоответствиях метрик в поиске ИИ Azure

Note

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

В этой статье приводятся ответы на распространенные вопросы о метриках хранилища, которые отображаются несогласованными на портале Azure, REST API и пакетах SDK Azure.

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

Сведения о том, как собираются и сообщаются метрики, см. в статье Monitor Поиск с использованием ИИ Azure.

Почему хранилище не изменяется немедленно при удалении или обновлении документов?

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

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

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

Дополнительные сведения см. в разделе "Удаление документов в индексе поиска " и "Накладные расходы" при удалении или обновлении документов в индексе.

Почему значения портала и API отличаются в один и тот же момент времени?

Портал Azure и REST API могут сообщать о различных значениях, так как они имеют разные частоты обновления. Specifically:

  • Вкладка "Использование " на странице обзора портала периодически обновляется каждые несколько минут.
  • GET Service Statistics возвращает счетчики уровня обслуживания, в том числе storageSize, vectorIndexSizeи documentCount.
  • Get Index Statistics возвращает счетчики для каждого индекса.

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

Дополнительные сведения о поверхностях мониторинга см. в статье Monitor Поиск с использованием ИИ Azure.

Почему перестроенный индекс превышает старый индекс с аналогичным содержимым?

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

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

  • Изменения схемы, такие как добавление полей, анализаторов или конфигураций векторов.
  • Модели приема и обновления, влияющие на долю удаленных документов.
  • Параметры оптимизации векторов, такие как квантизация или сокращение хранилища.

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

Почему общий объем хранилища не совпадает с размером векторного индекса?

storageSize и vectorIndexSize измеряют различные вещи:

  • storageSize — это общий объем дисков индекса, включая содержимое всех типов данных, таких как текст, метаданные и векторы.
  • vectorIndexSize — это ограничение размера векторного индекса, загруженного в память. Векторные поля, использующие исчерпывающий алгоритм KNN, не потребляют квоту векторного индекса и показывают ноль для vectorIndexSize. Дополнительные сведения см. в разделе "Размер и ограничения векторного индекса".

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

Как правильно сравнить метрики?

Чтобы определить, является ли несоответствие реальным или артефактом времени, зафиксировать значения из одной поверхности в согласованном окне времени UTC:

  1. Вызовите статистику службы GET и статистику индекса GET в одном и том же пятиминутном окне.
  2. Повторите выборку по фиксированной частотой, например каждые 20–30 минут.
  3. Сравните по крайней мере три последовательные окна перед выводом о том, что значения не конвергентно.
  4. Оцените storageSize отдельно от vectorIndexSize, потому что они отслеживают различные физические структуры.

Когда ожидается несоответствие и фактический дефект?

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

Ожидаемое расхождение

  • Недавно вы выполнили тяжелое индексирование, обновления или удаления, и значения по-прежнему сходятся.
  • Значения портала и API отличаются, но разрыв сужается в ходе повторных выборок.
  • storageSize и vectorIndexSize не совпадают, что так и предусмотрено, так как они измеряют разные вещи.

Возможный дефект

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

Что следует включить в запрос на поддержку?

Включите следующие сведения в запрос на поддержку:

  • Метки времени UTC для каждого портала и примера API.
  • Необработанные ответы JSON из статистики службы GET и GET Index Statistics.
  • Приблизительный объем загрузки, обновления и удаления данных в течение периода наблюдения.
  • Описание влияния на работу, например задержку масштабирования, блок квоты или неправильные отчеты о емкости.

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

  • Last updated on