Ограничения служб в службе "Поиск ИИ Azure"

Максимальные ограничения на хранилище, рабочие нагрузки и количество индексов и других объектов зависят от того, создаете ли вы поиск AI Azure на бесплатном, базовом, стандартном или оптимизированном для хранилища уровне тарифных планов.

• Бесплатная услуга — это мультитенантная общая служба, предоставляемая с подпиской Azure.

• Базовый предоставляет выделенные вычислительные ресурсы для производственных рабочих нагрузок в меньшем масштабе.

• Стандартный работает на выделенных машинах с увеличенной емкостью хранилища и вычислительной мощностью на всех уровнях. Уровни стандарта обозначены как: S1, S2, S3 и S3 HD. S3 High Density (S3 HD) предназначен для многотенантности и большого количества небольших индексов (3000 индексов на сервис). S3 HD не предоставляет функцию индексатора и прием данных должен использовать API, которые помещают данные из источника в индекс.

• Хранение оптимизировано выполняется на выделенных машинах с большим общим объемом хранилища, пропускной способностью для хранения и памятью, чем у Стандартного. Эта ценовая категория предназначена для больших и медленно меняющихся индексов. Оптимизация хранения представлена в двух уровнях: L1 и L2.

Ограничения подписки

Вы можете создать несколько платных служб поиска (базового и более высокого уровня), до максимального количества, разрешенного для каждого уровня в каждом регионе. Например, можно создать до 16 служб на уровне "Базовый" и еще 16 служб на уровне S1 в пределах одной подписки и региона. Затем можно создать дополнительные 16 базовых служб в другом регионе, чтобы общее количество составило 32 базовых служб в рамках той же подписки. Дополнительные сведения о уровнях см. в разделе "Выбор уровня (или SKU) для поиска ИИ Azure".

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

¹ Вы можете использовать бесплатную службу поиска для каждой подписки Azure. Уровень "Бесплатный" основан на инфраструктуре, общей для других клиентов. Так как оборудование не выделено, масштабирование не поддерживается, а хранилище ограничено 50 МБ. Бесплатная служба поиска может быть удалена после длительных периодов бездействия, чтобы освободить место для дополнительных служб.

² Единицы поиска (ЕП) — это оплачиваемые единицы, выделяемые в виде реплик или секций. Вам нужно и то, и другое. Дополнительные сведения о сочетаниях SU см. в статье "Оценка емкости службы поиска" и управление ими.

Ограничения сервисов

В следующей таблице рассматриваются SLA, число разделов и число реплик на уровне сервиса.

¹ Базовый уровень поддерживает три секции и три реплики, в общей сложности девять единиц поиска (SU) в новых службах поиска, созданных после 3 апреля 2024 года. Старые базовые службы ограничены одним разделом и тремя репликами.

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

Соглашения об уровне обслуживания применяются к оплачиваемым службам с двумя или более репликами для рабочих нагрузок запросов или тремя или более репликами для рабочих нагрузок запросов и индексирования. При применении соглашения об уровне обслуживания количество разделов не учитывается. Дополнительные сведения см. в статье Надежность в службе Azure AI Search.

Бесплатные службы не имеют фиксированных разделов или реплик и делят ресурсы с другими подписчиками.

Хранилище секций (ГБ)

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

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

¹ Хранилище с большей емкостью для уровней "Базовый", "S1", "S2", "S3" в этих регионах. Америки: Южная Бразилия, Центральная Канада, Восточная Канада, Восток США, Восток США 2, Центр США, Север Центральных США, Южный Центр США, Запад США, Запад США 2, Запад США 3, Запад Центральных США. Европа: Центральная Франция. Италия Северная Европа, Северная Европа, Восточная Норвегия, Центральная Польша, Северная Швейцария, Центральная Швеция, Южная Великобритания, Западная Часть Великобритании. Ближний Восток: Север ОАЭ. Африка: Северная Африка. Азиатско-Тихоокеанский регион: Восточная Австралия, Юго-Восточная Австралия, Центральная Индия, Jio India West, Восточная Азия, Восточная Азия, Восточная Япония, Западная Япония, Центральная Корея, Южная Корея.

² накопители большей емкости для L1 и L2. Больше регионов обеспечивают более высокую емкость на каждом оплачиваемом уровне. Европа: Северная Германия, Западная Германия, Западная Швейцария. Azure Government: Техас, Аризона, Вирджиния. Африка: Северная Африка. Азиатско-Тихоокеанский регион: Китай Северная 3, Восточная Китай 3.

³ Доступны варианты хранилищ с большей емкостью в Западной Европе.

Ограничения индексов

¹ Службы категории "Базовый", созданные до декабря 2017 г., имеют более низкие ограничения индексов (5 вместо 15). Базовый уровень — это единственный уровень с более низким ограничением в 100 полей на индекс.

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

³ Верхний предел существует для элементов, так как при наличии большого количества из них значительно увеличивается хранилище, необходимое для индекса. Элемент сложной коллекции определяется как член этой коллекции. Допустим, например, что у нас есть документ "Гостиница" со сложной коллекцией "Номера", тогда каждый номер в коллекции "Номера" считается элементом. Во время индексирования подсистема индексирования может безопасно обрабатывать не более 3000 элементов в документе в целом. Это ограничение появилось в api-version=2019-05-06 и применяется только к сложным коллекциям, а не к коллекциям строк или к сложным полям.

⁴ Для большинства уровней максимальный размер индекса — это общее доступное хранилище в службе поиска. Для служб S2, S3 и S3 HD с несколькими разделами, что означает больше пространства для хранения, максимально допустимый размер одного индекса указан в таблице. Применяется к службам поиска, созданным после 3 апреля 2024 г.

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

Ограничения документов

Максимальное количество документов на индекс:

• 24 миллиарда на Basic, S1, S2, S3
• 2 миллиарда на S3 HD
• 288 млрд на L1
• 576 млрд на L2

Максимальный размер каждого документа составляет около 16 мегабайт. Размер документа фактически является ограничением на размер полезных данных запроса API индексирования, что составляет 16 мегабайт. Полезная нагрузка может быть представлена как единым документом, так и пакетом документов. Для пакета с одним документом максимальный размер документа составляет 16 МБ данных JSON.

Размер документа применяется к индексации в режиме push, когда документы отправляются в службу поиска. Если вы используете индексатор для индексирования в режиме извлечения, исходные файлы могут иметь любой размер файла, при условии ограничений индексатора. Для индексатора блобов ограничения размера файла больше для более высоких уровней доступа. Например, ограничение S1 составляет 128 мегабайт, ограничение S2 — 256 мегабайт и т. д.

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

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

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

Ограничения векторов зависят от:

• Дата создания службы
• Регион

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

В этой таблице показано, как изменение квоты векторов в ГБ происходит с течением времени. Квота установлена на раздел, поэтому при масштабировании новой службы уровня "Стандартный" (S1) до 6 разделов общая квота вектора будет равна 35, умноженным на 6.

¹ Начальные ограничения векторов во время ранней предварительной версии.

² Ограничения вектора в течение более позднего предварительного периода. Три региона не имели более высоких ограничений: Западная Германия, Западная Индия, Центральная Катар.

³ Более высокая векторная квота, исходя из более крупных разделов, для поддерживаемых уровней и регионов.

⁴ Более высокая векторная квота для дополнительных уровней и регионов на основе обновлений размера раздела.

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

Ограничения индексатора

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

¹ Максимальное время выполнения индексатора для служб уровня "Бесплатный" составляет 3 минуты для источников больших двоичных объектов или 1 минуту для прочих источников данных. Вызов индексатора каждые 180 секунд. Для индексирования, использующего службы ИИ Azure, бесплатные услуги ограничены 20 бесплатными транзакциями на индексатор в день. Транзакция определяется как документ, который успешно проходит через конвейер обогащения. (Совет: можно сбросить индексатор, чтобы сбросить его счетчик).

² Службы категории "Базовый", созданные до декабря 2017 г., имеют более низкие ограничения для индексов (5 вместо 15), источников данных и наборов навыков.

³ службы HD С3 не включают поддержку индексатора.

⁴ До 30 навыков на набор квалификационных навыков.

⁵ Относительно максимальной продолжительности 2 или 24 часа для индексаторов: 2-часовое ограничение является наиболее распространенным, и его следует планировать. Он относится к индексаторам, работающим в общедоступной среде, используемой для разгрузки вычислительно интенсивной обработки и для оставления больше ресурсов для запросов. Ограничение в 24 часа применяется, если индексатор настроен для запуска в частной среде, используя только инфраструктуру, выделенную службе поиска. Обратите внимание, что некоторые старые индексаторы не могут работать в общедоступной среде, и эти индексаторы всегда имеют 24-часовой диапазон обработки. Если у вас есть незапланированные индексаторы, которые выполняются непрерывно в течение 24 часов, можно предположить, что эти индексаторы не могут быть перенесены в более новую инфраструктуру. Как правило, для заданий индексирования, которые не могут завершиться в течение двух часов, установите индексатор на 5-минутный интервал, чтобы он мог быстро продолжить с того места, где остановился. На бесплатном уровне максимальное время работы составляет 3–10 минут для индексаторов с наборами навыков.

⁶ Максимальное количество символов основано на единицах кода Юникода, в частности UTF-16.

Ограничения ресурсов общих приватных ссылок

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

¹ Обогащение с помощью ИИ и анализ изображений требуют большой объем вычислительных ресурсов и потребляют непропорциональные объемы доступных вычислительных мощностей. По этой причине частные подключения отключены на более низких уровнях, чтобы обеспечить производительность и стабильность самой службы поиска. В службах "Базовые" частные подключения к ресурсу нескольких служб ИИ Azure не поддерживаются для сохранения стабильности службы. Для уровня S1 убедитесь, что служба была создана с более высокими ограничениями после 3 апреля 2024 года.

² Частные подключения к модели внедрения поддерживаются в службах поиска "Базовый" и "S1 с высокой емкостью", созданных после 3 апреля 2024 г. с более высокими ограничениями для хранения и вычислительной обработки.

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

Ограничения синонимов

Максимальное количество карт синонимов варьируется в зависимости от уровня тарифа. Каждое правило может иметь до 20 расширений, которые представляют собой эквивалентные термины. Например, ассоциации со словом "кот" с "киска", "кошачий" и "Felis" (род кошек) будут учитываться как 3 расширения.

Ограничения индексного псевдонима

Максимальное число псевдонимов индекса зависит от уровня и даты создания службы. Во всех уровнях услуг, если служба была создана после октября 2022 года, максимальное количество псевдонимов в два раза превышает максимально допустимое количество индексов. Если служба была создана до октября 2022 года, ограничение — это допустимое количество индексов.

¹ Базовые службы, созданные до декабря 2017 года, имеют более низкие ограничения (5 вместо 15) для индексов

Ограничения по данным (обогащение с помощью ИИ)

Конвейер обогащения на базе искусственного интеллекта, который вызывает ресурс Языка искусственного интеллекта Azure для распознавания сущностей, связывания сущностей, извлечения ключевых фраз, анализа тональности, обнаружения языка и обнаружения персональных данных, зависит от ограничений данных. Максимальный размер записи должен составлять 50 000 знаков по измерениям String.Length. Если вам нужно разбить данные перед отправкой в анализатор тональности, воспользуйтесь навыком разделения текста.

Ограничения пропускной способности

Запросы API регулируются, когда система приближается к пиковой загрузке. Управление пропускной способностью работает по-разному для разных API. API запросов (поиск, предложения и автозавершение) и API индексирования регулируются динамически в зависимости от нагрузки на службу. API индекса и API операций службы имеют ограничения на частоту статических запросов.

Статические ограничения на запросы для операций, связанных с индексом.

• Список индексов (GET /indexes): 3 запроса в секунду на единицу поиска
• Get Index (GET /indexes/myindex): 10 в секунду на единицу поиска
• Создание индекса (POST /indexes): 12 в минуту на единицу поиска
• Создание или обновление индекса (PUT /indexes/myindex): 6 в секунду на единицу поиска
• Удаление индекса (DELETE /indexes/myindex): 12 в минуту на единицу поиска

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

• Статистика службы (GET/servicestats): 4 в секунду на единицу поиска

Ограничения на управление семантическим ранжированием

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

Общий объем запросов семантического ранга в секунду зависит от следующих факторов:

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

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

Ограничения запросов к API

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

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

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

За исключением отмеченных, следующие запросы API применяются ко всем программируемым интерфейсам, включая пакеты SDK Azure.

Общие сведения:

• Поддерживаемый максимальный предел полезных данных составляет 16 МБ для индексирования и запроса через REST API и SDK.
• Максимальная длина URL-адреса 8 КБ (применяется только к REST API).

Api индексирования:

• Максимально поддерживается 1000 документов на одну партию загрузок индекса, слияний или удалений.

API запросов:

• Максимум 10 полей в векторном запросе
• Не более 32 полей в предложении $orderby.
• Максимум 100 000 символов в предложении поиска.
• Максимальное количество условий в поиске составляет 3000.
• Максимальная квота на запросы с подстановочными знаками и регулярными выражениями, применяемая Lucene. Он ограничивает количество шаблонов, вариантов или совпадений до 1000 экземпляров. Это ограничение применяется, чтобы избежать перегрузки двигателя.

Условия поиска:

• Поддерживаемый максимальный размер термина поиска составляет 32 766 байт (32 КБ минус 2 байта) в кодировке UTF-8. Применяется к поиску ключевых слов и свойству текста векторного поиска.
• Поддерживаемый максимальный размер термина поиска составляет 1000 символов для поиска по префиксу и поиска по регулярным выражениям.

Ограничения ответов API

• Не более 1000 документов, возвращаемых на страницу результатов поиска
• Максимум 100 предложений на один запрос API предложений.

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

Ограничения ключей API

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

• Максимум 2 ключа администратора на одну службу.
• Максимум 50 ключей запросов на одну службу.