Размер векторного индекса и соблюдение ограничений

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

Ключевые моменты о квоте и размере векторного индекса

• Размер векторного индекса измеряется в байтах.

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

• Квоты векторов применяются в службе поиска в целом на секцию. При добавлении секций квота вектора также увеличивается. Квоты вектора на секцию выше в новых службах. Дополнительные сведения см. в разделе "Ограничения размера индекса вектора".

Как проверить размер и количество секций

Если вы не уверены, каковы ограничения службы поиска, ниже приведены два способа получения этих сведений:

• На портале Azure на странице обзора службы поиска вкладка "Свойства " и вкладка "Использование " отображают размер секции и хранилище, а также векторные квоты и размер векторного индекса.

• На портале Azure на странице масштабирования можно просмотреть количество и размер секций.

Ограничение вектора зависит от даты создания службы.

Получение размера векторного индекса

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

GET {{baseUrl}}/servicestats?api-version=2024-07-01  HTTP/1.1
    Content-Type: application/json
    api-key: {{apiKey}}

{
    "@odata.context": "https://my-demo.search.windows.net/$metadata#Microsoft.Azure.Search.V2023_11_01.ServiceStatistics",
    "counters": {
        "documentCount": {
            "usage": 15377,
            "quota": null
        },
        "indexesCount": {
            "usage": 13,
            "quota": 15
        },
        . . .
        "storageSize": {
            "usage": 39862913,
            "quota": 2147483648
        },
        . . .
        "vectorIndexSize": {
            "usage": 2685436,
            "quota": 1073741824
        }
    },
    "limits": {
        "maxFieldsPerIndex": 1000,
        "maxFieldNestingDepthPerIndex": 10,
        "maxComplexCollectionFieldsPerIndex": 40,
        "maxComplexObjectsInCollectionsPerDocument": 3000
    }
}

GET {{baseUrl}}/indexes/vector-healthplan-idx/stats?api-version=2024-07-01  HTTP/1.1
    Content-Type: application/json
    api-key: {{apiKey}}

{
    "@odata.context": "https://my-demo.search.windows.net/$metadata#Microsoft.Azure.Search.V2023_11_01.IndexStatistics",
    "documentCount": 147,
    "storageSize": 4592870,
    "vectorIndexSize": 915484
}

Факторы, влияющие на размер векторного индекса

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

• Необработанный размер данных
• Накладные расходы, связанные с выбранным алгоритмом
• Затраты на удаление или обновление документов в индексе

Необработанный размер данных

Каждый вектор обычно представляет собой массив чисел с плавающей запятой с одной точностью в поле типа Collection(Edm.Single).

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

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

raw size = (number of documents) * (dimensions of vector field) * (size of data type)

Затраты на память из выбранного алгоритма

Каждый приблизительный алгоритм ближайшего соседа (ANN) создает дополнительные структуры данных в памяти, чтобы обеспечить эффективный поиск. Эти структуры используют дополнительное пространство в памяти.

Для алгоритма HNSW объем памяти составляет от 1% до 20% для несжатых векторов float32 (Edm.Single).

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

Нагрузка на память увеличивается с большими значениями параметра mHNSW, который указывает количество двунаправленных ссылок, созданных для каждого нового вектора во время построения индекса. Это происходит потому, что каждая ссылка вносит приблизительно 8–10 байтов в документ, а общий объем затрат пропорционально масштабируется.m

В следующей таблице перечислены проценты накладных расходов, наблюдаемые во внутренних тестах для несжатых полей векторов :

Эти результаты демонстрируют связь между измерениями, параметром mHNSW и затратами на память для алгоритма HNSW.

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

Затраты на удаление или обновление документов в индексе

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

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

Это еще один фактор, влияющий на размер векторного индекса. К сожалению, у нас нет механизма для отображения текущего коэффициента удаленных документов.

Оценка общего размера данных в памяти

Учитывая ранее описанные факторы, чтобы оценить общий размер индекса вектора, используйте следующий расчет:

(raw_size) * (1 + algorithm_overhead (in percent)) * (1 + deleted_docs_ratio (in percent))

Например, чтобы вычислить raw_size, предположим, что вы используете популярную модель Azure OpenAI с text-embedding-ada-002 1536 измерениями. Это означает, что один документ будет использовать 1536 Edm.Single (с плавающей запятой) или 6144 байта, так как каждый из них Edm.Single составляет 4 байта. 1000 документов с одним, 1536-мерным векторным полем будут потреблять в общей сложности 1000 документов x 1536 чисел = 1 536 000 чисел или 6 144 000 байт.

Если у вас несколько векторных полей, необходимо выполнить это вычисление для каждого векторного поля в индексе и добавить их вместе. Например, 1000 документов с двумя 1536-размерными векторными полями, используют 1000 документов x 2 поля x 1536 floats/doc x 4 байт/float = 12 288 000 байт.

Чтобы получить размер векторного индекса, умножьте этот raw_size на накладные расходы алгоритма и коэффициент удаленных документов. Если накладные расходы вашего алгоритма для выбранных параметров HNSW составляют 10%, а коэффициент удалённых документов равен 10%, то мы получаем: 6.144 MB * (1 + 0.10) * (1 + 0.10) = 7.434 MB.

Влияние полей векторов на хранилище дисков

Большая часть этой статьи содержит сведения о размере векторов в памяти. Дополнительные сведения о затратах на хранение векторных индексов.