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

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

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

• Выделенный: фиксированные цены, измеряемые единицами поиска (SUS). Параметры уровня служб включают: "Базовый", "Стандартный" (S1-S3, включая S3 HD), "Оптимизировано для хранения" (L1-L2) и уровень "Бесплатный" с ограниченными возможностями службы поиска.
• Бессерверные (предварительная версия): цены на основе потребления, измеряемые единицами вычислений в час (CU/hr) и за ГБ в месяц для индексированного хранилища. Текущий уровень предварительной версии: бессерверный разработчик. Ограничения определяются лимитами для каждого индекса, количеством объектов для каждого сервиса и поведением механизма ограничения пропускной способности в Serverless.

Дополнительные сведения см. в разделе "Выбор модели ценообразования" и уровня служб.

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

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

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

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

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

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

В выделенной модели ценообразования запланируйте емкость путем умножения реплик по секциям (единицам поиска).

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

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

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

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

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

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

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

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

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

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

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

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

При индексировании документов с помощью векторных полей поиск Azure ИИ создает внутренние индексы векторов с помощью предоставленных вами параметров алгоритма.

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

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

Рекомендации по управлению и максимизации векторного хранилища см. в разделе "Размер индекса вектора" и их сохранение в пределах ограничений.

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

• Дата создания службы
• Регион
• Выбранная модель ценообразования и уровень служб

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

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

• Максимальный размер индекса вектора на индекс (бессерверный): 300 МБ
  • Этот размер представляет примерно 30% общего хранилища индексов, в соответствии с соотношением векторов к хранилищу, используемым на выделенных уровнях служб.
  • Этот размер является жестким ограничением для каждого индекса. Попытки превысить это ограничение при индексировании завершаются сбоем.

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

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

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

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

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

Служба применяет квоту размера векторного индекса:

• Выделено: На каждый раздел в службе поиска
• Бессерверный режим: на индекс

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

• Удаление векторных документов
• Уменьшение размера вектора или размерности
• (Только для выделенных) Горизонтальное масштабирование разделов

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

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

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

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

³ Поддержка индексатора S3 HD доступна в предварительной версии, требует REST API версии 2025-11-01-preview или более поздней и подчиняется ежедневной квоте уровня службы в шесть часов суммарного времени выполнения, общей для всех индексаторов. Индексаторы S3 HD работают только в общедоступной среде исполнения и не поддерживают общие ресурсы Private Link. В предварительной версии поддержка индексатора S3 HD оптимальна для небольших рабочих нагрузок (размер индекса — около 1 ГБ) без навыков или с минимальным набором навыков. Дополнительные сведения см. в статье Выполнение индексатора в Serverless и S3 HD.

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

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

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

⁷ При использовании delimitedText режима синтаксического анализа для CSV-файлов применяется ограничение размера буфера в 10 МБ на строку файла.

⁸ При использовании delimitedText режима синтаксического анализа для CSV-файлов ограничение "максимальный размер извлеченного содержимого" не применяется.

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

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

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

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

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

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

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

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

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

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

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

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

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

Источники знаний для каждой базы знаний

Ограничения на базы знаний для источников знаний зависят от версии API, используемой для создания или обновления базы знаний. В 2026-05-01-preview все процессы извлечения и рассуждения используют одни и те же ограничения источников знаний. Более ранние предварительные версии API имеют более низкие лимиты для low и medium усилий рассуждения.

² В более ранних предварительных версиях API параметр minimal reasoning effort поддерживает больше источников знаний, чем low или medium, поскольку он обходит этап планирования запросов на основе LLM.

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

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

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

Эти ограничения применяются как к выделенным, так и бессерверным моделям ценообразования.

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

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

В модели ценообразования Dedicated ограничение основано на количестве единиц поиска (реплики × разделы).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

API запросов:

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

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

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

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

• Каждая страница результатов поиска возвращает до 1000 документов.
• Каждый запрос API предложения возвращает до 100 предложений.

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

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

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

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