Оптимизация затрат на модель ценообразования без сервера в Поиск с использованием ИИ Azure

Note

Поиск с использованием ИИ Azure доступна через портал Azure, REST API и Azure SDKs. Он также лежит в основе Foundry IQ — управляемого слоя знаний, который преобразует корпоративный контент в многократно используемые базы знаний с учетом разрешений доступа для агентов на портале Microsoft Foundry.

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

  • Выделенный: фиксированные цены, измеряемые единицами поиска (SUS). Вы выбираете уровень обслуживания, и с вас взимается почасовая плата на основе выделенных единиц.

  • Бессерверные (предварительная версия): цены на основе потребления, измеряемые единицами вычислений в час (CU/hr) и за ГБ в месяц для индексированного хранилища.

Important

Уровень Serverless Developer в настоящее время доступен в предварительной версии. Эта предварительная версия предоставляется без соглашения об уровне обслуживания и не рекомендуется для использования в производственной среде. Некоторые функции могут не поддерживаться или их возможности могут быть ограничены. Для получения дополнительной информации см. Дополнительные условия использования для предварительных версий Microsoft Azure.

Выставление счетов за уровень "Бессерверный разработчик" начинается 13 сентября 2026 г. Плата за использование в эту дату или после нее появится в счете Azure. Плата за использование не взимается до 13 сентября 2026 г. Serverless Developer — это платный тариф после начала биллинга. Уровень "Бессерверный разработчик" не поддерживает миграцию на другие ценовые категории и некоторые функции, доступные на других уровнях, не поддерживаются во время общедоступной предварительной версии. Ограничения служб, поддерживаемые функции и сведения о ценах могут изменяться до общедоступной доступности.

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

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

Как определяется стоимость в бессерверной модели

Модели ценообразования Dedicated и Serverless по-разному учитывают работу в службе поиска. Выделенные сервисы обрабатывают запросы, выполняют индексацию и обработку результатов на уже приобретенной вами выделенной мощности. Бессерверные службы измеряют вычислительные ресурсы, память и операции ввода-вывода, которые эти операции используют и преобразуют их в единицы вычислений (ЦС). В результате оптимизация производительности напрямую влияет на бессерверные затраты.

Бессерверные затраты привязаны к выполнению рабочей нагрузки:

  • Запросы и индексирование используют вычисления, измеряемые в единицах вычислений в час (CU/h).
  • Активные индексы используют вычислительные ресурсы на основе использования ресурсов и времени их активности.
  • Индекс остается активным в течение 10 минут после последнего запроса или запроса индексирования, прежде чем он неактивен.
  • Неактивные индексы не имеют минимальной или зарезервированной платы за вычисления. Потребление вычислительных ресурсов для неактивных индексов снижается до нуля. Минимальная плата за вычисления не взимается, если индекс неактивен.
  • Стоимость хранения рассчитывается отдельно, исходя из размера индекса на диске, и начисляется независимо от того, используется индекс или нет.
  • Агентный поиск требует вычислительных ресурсов на выполнение поисковых запросов и оркестрацию, выполняемую внутри службы поиска.

Плата за хранение останавливается только при удалении индекса.

Как размер индекса влияет на использование вычислительных ресурсов

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

  • Общий размер индекса: общее пространство, которое занимает индекс на диске, включая текст, метаданные и векторы.
  • Размер векторного индекса: память, используемая векторным индексом. Память является более ресурсоемкой, чем диск, поэтому размер векторного индекса имеет более высокий вес при преобразовании в ЦС.

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

Чтобы уменьшить использование вычислений с активным индексом, определите, какой ресурс создает более высокий объем cu. Затем уменьшите общий размер индекса, размер векторного индекса или оба. Индексированные хранилища по-прежнему составляют отдельную плату за ГБ в месяц.

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

Important

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

Общие сведения об единицах вычислений (ЦС)

Единица вычислений (CU) представляет измеряемые системные ресурсы, необходимые для выполнения операций поиска и индексирования в бессерверной модели. Стоимость CU определяется прежде всего уровнем использования ЦП, памяти и ввода-вывода, а во вторую очередь — размером индекса и размером полезной нагрузки документов; при этом использование тарифицируется в Compute Unit per hour (CU/h).

Масштабирование затрат вычислений с помощью:

  • Сложность запросов
  • Размер индекса (ГБ) и структура
  • Размер данных документа (КБ)
  • Количество полей и полученных результатов

Разные операции имеют разные профили затрат:

  • Поиск: низкая стоимость. Извлечение одного документа по его идентификатору является наиболее эффективной операцией.
  • Поиск ключевых слов: низкая стоимость. Поиск текста использует инвертированные индексы, оптимизированные для скорости и низкой производительности вычислений.
  • Векторный поиск: высокая стоимость. Векторные запросы требуют больших вычислительных ресурсов, поскольку требуют вычисления сходства по высокоразмерным эмбеддингам. По сравнению с поиском ключевых слов они используют значительно больше вычислительных ресурсов.
  • Гибридный поиск: включает затраты на поиск по ключевым словам и векторный поиск, поскольку для каждого запроса выполняются оба конвейера, а также небольшие дополнительные накладные расходы на Reciprocal Rank Fusion (RRF) для объединения результатов.

Мониторинг использования вычислений

Мониторинг потребления вычислительных ресурсов помогает выявлять дорогостоящие операции, оптимизировать шаблоны запросов и оценивать затраты. Стоимость единиц вычислений (CU) каждого запроса возвращается в заголовке x-ms-azs-compute-units-consumed ответа HTTP в виде числа с плавающей запятой. Используйте этот заголовок для выявления дорогостоящих операций и оптимизации шаблонов запросов. Вы можете отслеживать стоимость CU каждого запроса, изучая заголовки HTTP-ответов и события операций в Azure Monitor. Дополнительные сведения о типах доступных данных мониторинга и методах для анализа этих данных см. в разделе "Мониторинг Поиск с использованием ИИ Azure".

  • Заголовок: x-ms-azs-compute-units-consumed: <value>
  • Значение: число с плавающей запятой, представляющее используемые ЦС.

Пример:

Status: 200 OK
Content-Type: application/json
x-ms-azs-compute-units-consumed: 12.45

В этом примере запрос использовал 12,45 вычислительных единиц. Это значение можно использовать для определения высокопроизводительных операций и сравнения относительной стоимости различных шаблонов запросов.

Чтобы проверить использование исторических вычислений для службы поиска без сервера, используйте метрики Azure Monitor на портале Azure:

  1. Перейдите к своей службе поиска
  2. Выберите Метрики.
  3. Выберите +Добавить метрику.
  4. В списке метрик выберите использование единиц вычислений.
  5. Используйте диаграмму для анализа тенденций использования и определения периодов увеличения потребления вычислительных ресурсов.

Мониторинг статистического использования помогает понять общие затраты на обслуживание и определить рабочие нагрузки, которые потребляют большинство вычислительных ресурсов. Описание доступных метрик мониторинга см. в справочнике по данным мониторинга. Журналы Azure Monitor можно использовать для отслеживания совокупного использования CU с течением времени и сопоставления его с объёмом запросов и изменениями рабочей нагрузки.

Снимок экрана: панель мониторинга метрик для бессерверных единиц вычислений в портал Azure.

Настройте оповещения об использовании вычислительных ресурсов

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

  1. Перейдите к оповещениям в службе поиска.
  2. Выберите и создайте правило генерации оповещений.
  3. В разделе "Условие" выберите использование единиц вычислений в качестве сигнала.
  4. Определите логику оповещения. Например, триггер, когда общее использование больше указанного значения.
  5. Настройте Действия, такие как уведомления по электронной почте, SMS или вебхуку.
  6. Выполните оставшиеся действия и нажмите кнопку "Проверить и создать".

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

Снимок экрана: создание правила генерации оповещений в портал Azure.

Оценка затрат для режима "Без сервера"

Калькулятор цен Azure и руководство по планированию емкости на основе единиц поиска (SU) не применяются к службам, использующим бессерверную модель ценообразования.

Чтобы оценить бессерверные затраты:

  1. Индексировать репрезентативные выборочные данные.
  2. Выполните типичные задачи индексирования и запросов.
  3. Запишите значение, x-ms-azs-compute-units-consumed возвращаемое для каждой операции.
  4. Используйте метрики Azure Monitor для измерения совокупного использования с течением времени.
  5. Экстраполировать затраты на основе ожидаемого рабочего трафика.

Перейдите на вкладку "Масштабирование и затраты" на портале Azure, чтобы просмотреть текущее использование и оценить затраты.

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

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

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

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

Выставление счетов основано на статистическом использовании вычислений, а не на отдельных запросах. Использование измеряется в течение одной минуты и округляется до ближайшего 0,25 CU в минуту. Эти одноминутные интервалы использования суммируются за час для определения тарифицируемого объёма CU/час. Внутри системы использование агрегируется из милливычислительных единиц (mCU) в вычислительные единицы (CU), а затем преобразуется в почасовое использование, указываемое для выставления счетов.

Различные операции используют разные объемы вычислений. Вообще:

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

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

Сокращение затрат на вычислительные ресурсы путем оптимизации

Эффективные запросы и проектирование индексов снижают потребление вычислительных ресурсов и снижают затраты.

Оптимизация схемы

Схема индекса определяет базовые затраты на вычисления и хранение:

  • Ограничение атрибутов поля: при необходимости включите только атрибуты (доступные для поиска, фильтруемые, фасетные, сортируемые). Каждый атрибут увеличивает размер индекса и стоимость индексирования.
  • Преобразуйте сложные типы в плоскую структуру: сопоставляйте вложенные структуры JSON с простыми полями или коллекциями, где это возможно.
  • Установите retrievable=false для полей, используемых только для фильтрации или только для сортировки: если поле используется для фильтрации или сортировки, но его не нужно возвращать в результатах, оставьте его индексируемым и установите retrievable=false, чтобы уменьшить объем дискового хранилища и стоимость хранения в расчете на ГБ в месяц.
  • Используйте поля, доступные только для извлечения, если это возможно: например, поля, используемые только для отображения (например, URL-адреса изображений), не должны находиться в поиске.
  • Уменьшение размеров векторов: векторы с более высокими размерами увеличивают затраты на хранение и запросы. При необходимости используйте более мелкие модели внедрения или квантизацию.
  • Сведите к минимуму объём данных документа перед индексированием: документы большего размера обходятся дороже при индексировании. Удалите ненужные поля, обрежьте длинный текст и удалите HTML-разметку перед отправкой документов в индекс.

Оптимизация запросов индексирования

Отправка данных в индекс влияет как на затраты, так и на пропускную способность:

  • По возможности используйте более крупные пакеты: пакетная индексация снижает накладные расходы на каждый запрос, распределяя затраты на сеть и обработку на большее количество документов. Как правило, пакеты до 1000 документов или ~16 МБ являются более эффективными, чем многие небольшие запросы. Однако оптимальный размер пакета зависит от рабочей нагрузки. Проверьте, чтобы сбалансировать пропускную способность, задержку и надежность.

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

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

  • Учет роста размера индекса: по возможности создайте меньшие индексы. По мере роста индекса затраты на индексирование увеличиваются, так как больше данных необходимо хранить и поддерживать, а операции требуют больше вычислительных ресурсов. Для очень больших наборов данных рекомендуется секционировать данные по нескольким индексам, чтобы помочь управлять производительностью и затратами. Хотя затраты растут с увеличением размера индекса, этот рост является сублинейным. Более крупные индексы обходятся дороже за операцию, но не пропорционально дороже.

Дополнительные рекомендации см. в Подсказки для повышения производительности в Поиск с использованием ИИ Azure.

Оптимизация операций индексатора

Использование вычислений бессерверного индексатора зависит от работы, выполняемой во время каждого запуска индексатора. Для строковых источников используйте количество документов, обработанных в качестве индикатора объема рабочей нагрузки. Для файловых источников, таких как Хранилище BLOB-объектов Azure и Azure Data Lake Storage 2-го поколения, отслеживайте объем обработанных исходных данных. Фактическое использование вычислительных ресурсов также зависит от полезных данных документа, структуры индекса, обогащения и другой обработки, выполняемой во время выполнения.

Чтобы уменьшить использование вычислительных ресурсов индексатора:

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

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

  • Уменьшите ненужный контент документа: удалите содержимое, которое не требуется индексировать, и исключите файлы или типы файлов, которые не требуются.

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

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

Оптимизация запросов

Проектирование запросов является основным драйвером переменной стоимости:

  • Используйте $select для ограничения возвращаемых полей: это уменьшает размер полезных данных и вычислительные ресурсы, необходимые для сериализации.

    GET /docs?search=test&$select=id,title,url

  • Используется searchFields для ограничения того, где выполняется поиск текста: ограничить соответствие времени запроса полям, которые имеют значение для сценария. Каждое дополнительное поле, доступное для поиска, увеличивает нагрузку при выполнении запросов и может повысить CU/h.

  • Предпочитайте точное совпадение или простые запросы по ключевым словам: нечёткие запросы, запросы с подстановочными знаками, запросы с регулярными выражениями и префиксные запросы могут приводить к широкому сканированию индекса и потреблять значительно больше CU/h. Используйте их только в том случае, если требуется частичное сопоставление и выбрать точное соответствие или более простые запросы ключевых слов, где это возможно.

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

  • Избегайте глубокой пагинации ($skip): большие значения $skip увеличивают вычислительную нагрузку, поскольку механизм должен обрабатывать и ранжировать все предшествующие результаты (например, $skip=5000 требует оценить релевантность как минимум 5000 документов, которые не возвращаются). Это приводит к неэффективному расходованию вычислительных ресурсов (CUs) и увеличивает затраты. Вместо этого используйте фильтры, чтобы сузить результаты и ограничить возвращаемое $topчисло. Подберите размер $top в соответствии с отображением в интерфейсе. Например, $top=10 стоит дешевле, чем $top=50, потому что оценивается и возвращается меньше результатов. Запрашивайте только столько результатов, сколько требуется приложению, и избегайте шаблонов, требующих обработки большого количества неиспользуемых результатов.

  • Сведите к минимуму количество фасетов и их объём: запрашивайте только те фасеты, которые отображаются в вашем интерфейсе, и поддерживайте каждое значение count фасета настолько низким, насколько это практически возможно. Фасеты требуют агрегаций для каждого запроса, а большое количество значений увеличивает вычислительные затраты.

  • Используется search.in для фильтрации: при фильтрации по списку идентификаторов или значений используйте search.in функцию вместо нескольких or условий (например, id eq '1' or id eq '2'). Этот подход является более эффективным и снижает затраты на вычислительные ресурсы. Кроме того, следует избегать маркировки полей высокой кратности (с большим количеством уникальных значений, таких как уникальные идентификаторы или описания свободного текста) в качестве фильтруемых или фасетных полей, если это не требуется, так как это увеличивает размер индекса и стоимость запроса.

Оптимизация административных запросов

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

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

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

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

Оптимизация хранилища векторов и схемы

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

  • Используйте сжатие для уменьшения векторного размера: применение квантизации для уменьшения объема памяти с минимальным влиянием на релевантность. Например, скалярная квантизация может уменьшить объем хранилища векторов до 4× с минимальным воздействием на качество поиска.

  • Отключите хранилище для векторов, если не требуется: задайте значение stored=false в полях векторов, если вам нужны только векторы для поиска, а не извлечение. Это позволяет избежать хранения исходных векторов в индексе, что снижает затраты на хранение, не влияя на поведение запросов.

  • Используйте меньшие размеры внедрения, если это возможно: векторы с более высокими размерами увеличивают затраты на хранение и запросы. Для некритичных нагрузок используйте меньшие модели эмбеддингов (например, с 384 или 768 размерностями вместо 1536), чтобы снизить затраты.

Оптимизация выполнения векторного запроса

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

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

  • Настройте maxTextRecallSize для гибридных запросов: задайте hybridSearch.maxTextRecallSize, чтобы управлять количеством текстовых результатов, ранжированных по BM25, доступных для Reciprocal Rank Fusion (RRF). Значение по умолчанию — 1000, а поддерживаемый диапазон — от 1 до 10 000. Снижение значения может уменьшить количество операций извлечения текста и результатов слияния, что может снизить использование ресурсов и задержку. Однако он может исключить соответствующие результаты ключевых слов, включая точные термины, идентификаторы и акронимы, которые могут пропустить векторный поиск. Протестируйте репрезентативные запросы и сравните релевантность, задержку и x-ms-azs-compute-units-consumed заголовок ответа перед выбором значения. Управление кандидатами векторов отдельно путем задания k для каждого векторного запроса.

  • Примените фильтры перед векторными запросами: сузите набор кандидатов перед векторным поиском, чтобы уменьшить объем обработанных данных. Узнайте , как работает фильтрация в векторных запросах.

Сокращение затрат путем минимизации использования

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

Чтобы свести к минимуму затраты на использование:

  • Выполнение запросов только при необходимости.
  • Избегайте избыточных или чрезмерно частых запросов.
  • Отслеживайте использование и настраивайте рабочие нагрузки на основе спроса.

Tip

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

Оптимизация затрат на хранение

Плата за хранение взимается за ГБ в месяц на основе размера индекса на диске, что может превышать размер необработанных данных. Чтобы сократить затраты на хранение, выполните приведенные далее действия.

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

Методы, относящиеся к векторам (сжатие, обрезка и параметры хранилища), см. в разделе "Оптимизация для хранения и обработки векторов".

Дополнительные рекомендации по повышению производительности хранилища и запросов см. в подсказках для повышения производительности в Поиск с использованием ИИ Azure.

  • Last updated on