Размер и ограничения векторного индекса

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

В структуре физических данных индекса поиска включены:

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

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

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

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

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

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

• Не все алгоритмы используют квоту размера векторного индекса. Квоты векторов устанавливаются на основе требований к памяти для поиска по алгоритму приближенного ближайшего соседа (ANN). Векторные поля, созданные с помощью алгоритма иерархического навигационного малого мира (HNSW), должны находиться в памяти во время выполнения запроса вследствие характера случайных переходов на основе графов. Векторные поля с помощью исчерпывающего алгоритма K-Ближайших соседей (KNN) загружаются в память динамически страницами во время выполнения запроса, поэтому не используют векторную квоту.

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

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

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

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

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

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

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

GET {{baseUrl}}/servicestats?api-version=2025-09-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=2025-09-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.

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

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

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

• Векторный поиск в поиске ИИ Azure
• Выбор подхода для оптимизации хранилища векторов и обработки
• Устранение неполадок с несоответствиями хранилища и метрик