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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример:

Status: 200 OK
Content-Type: application/json
x-ms-request-charge: 12.45

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Используйте $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), чтобы снизить затраты.

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

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

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

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

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

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

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

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

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

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

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

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

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