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

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

Примечание.

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

Совет

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

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

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

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

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

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

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

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

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

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

Проверка даты создания службы

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

1. В портал Azure откройте группу ресурсов, содержащую службу поиска.

2. В левой области в разделе "Параметры" выберите "Развертывания".

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

4. Выберите развертывание. Если у вас несколько, щелкните, чтобы узнать, разрешено ли оно в службе поиска.

   

5. Разверните раздел сведений о развертывании. Вы увидите дату создания и создания.

   

6. Теперь, когда вы знаете возраст службы поиска, просмотрите ограничения квоты вектора на основе создания службы: ограничения размера векторного индекса.

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

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

Портал

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

На следующем снимки экрана используется более старая служба поиска "Стандартный" (S1), настроенная для одной секции и одной реплики.

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

Снимок экрана показывает, что индексы (vector и nonvector) используют почти 460 мегабайт доступного дискового хранилища. Векторные индексы используют почти 93 мегабайт памяти на уровне обслуживания.

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

Примечание.

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

REST

REST API плоскости данных (все новые API предоставляют статистику использования векторов):

• Get Service Statistics возвращает квоту и использование для службы поиска.
• Get Index Statistics возвращает использование для заданного индекса.

Данные об использовании и квоте отображаются в байтах.

Ниже приведена статистика службы GET:

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

Ответ содержит метрики для storageSize, которые не различают векторные и невекторные индексы. Статистика vectorIndexSize показывает использование и квоту на уровне обслуживания.

{
    "@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, чтобы получить физический размер индекса на диске, а также размер в памяти полей векторов.

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

Ответ включает сведения об использовании на уровне индекса. Этот пример основан на индексе, созданном в кратком руководстве по интегрированной векторизации, который блокирует и векторизирует PDF-файлы плана работоспособности. Каждый блок вносит свой вклад documentCount.

{
    "@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)

Тип данных EDM	Размер типа данных
Collection(Edm.Single)	4 байта
Collection(Edm.Half)	2 байта
Collection(Edm.Int16)	2 байта
Collection(Edm.SByte)	1 байт

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

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

Для алгоритма HNSW объем памяти составляет от 1 до 20 %.

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

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

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

Измерения	Параметр HNSW (m)	Процент накладных расходов
96	4	20%
200	4	%8
768	4	2%
1536	4	1%
3072	4	0,5 %

Эти результаты демонстрируют связь между измерениями, параметром 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 floats/doc = 1536 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

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

Большая часть этой статьи содержит сведения о размере векторов в памяти. Если вы хотите узнать о размере вектора на диске, потребление диска для векторных данных примерно в три раза больше размера векторного индекса в памяти. Например, если ваше vectorIndexSize использование составляет 100 мегабайт (10 миллионов байт storageSize ), для размещения векторных индексов вы использовали бы по крайней мере 300 мегабайт квот.