Optimización de los costos del modelo de precios sin servidor en Búsqueda de Azure AI

Note

Búsqueda de Azure AI está disponible a través del portal de Azure, las API REST y los SDK de Azure. También respalda Foundry IQ, la capa de conocimiento administrada que transforma el contenido empresarial en bases de conocimiento reutilizables y compatibles con permisos para agentes en el portal de Microsoft Foundry.

Búsqueda de Azure AI admite dos modelos de precios, cada uno diseñado para diferentes patrones de carga de trabajo:

  • Dedicado: Precios fijos medidos por unidades de búsqueda (SU). Seleccione un nivel de servicio y se le facturará cada hora en función de las unidades aprovisionadas.

  • Sin servidor (versión preliminar): precios basados en el consumo medidos por unidades de proceso por hora (CU/hr) y por GB/mes para el almacenamiento indexado.

Importante

El nivel Desarrollador sin servidor está actualmente en versión preliminar. Esta versión preliminar se ofrece sin contrato de nivel de servicio y no es aconsejable usarla en las cargas de trabajo de producción. Es posible que algunas características no se admitan o que tengan funcionalidades restringidas. Para más información, consulte Términos de uso complementarios para las versiones preliminares de Microsoft Azure.

La facturación del nivel Desarrollador sin servidor aún no está habilitada durante la versión preliminar. Los costos estimados del uso están disponibles en el portal de Azure y la telemetría, pero ese uso no aparecerá en la factura de Azure durante este período inicial. Microsoft proporcionará al menos 30 días de aviso antes de que comience la facturación. El aplazamiento de la facturación durante esta versión preliminar es temporal. El desarrollador sin servidor es un nivel de pago y será responsable de los cargos acumulados una vez que comience la facturación.

El nivel Desarrollador sin servidor no admite la migración a ni desde otros planes de tarifa y algunas características disponibles en otros niveles no se admiten durante la versión preliminar pública. Los límites de servicio, las características admitidas y los detalles de precios pueden cambiar antes de la disponibilidad general.

La versión preliminar solo está disponible actualmente en centro-oeste de EE. UU., Norte de Suiza y Este de Japón.

Para obtener más información sobre las diferencias entre el modelo de precios y el nivel de servicio, consulte Elegir un modelo de precios y un plan de servicio.

Cómo se determina el costo en el modelo sin servidor

En el modelo sin servidor, la optimización del rendimiento afecta directamente al costo. El costo está directamente vinculado a la ejecución de la carga de trabajo:

  • Las consultas y la indexación consumen proceso, medidos en unidades de proceso por hora (CU/h).
  • El almacenamiento se factura por separado en función del tamaño del índice en el disco.
  • Cuando el servicio está inactivo sin consultas activas ni indexación, el uso de proceso es cero. No hay ningún cargo de capacidad reservada o mínima.

El modelo de precios sin servidor es más rentable para las cargas de trabajo con tráfico variable, intermitente o impredecible, donde la capacidad aprovisionada estaría infrautilizada.

Importante

Los cargos por Unidad de proceso por hora (CU/h) no incluyen clasificación semántica, recuperación de agentes, extracción de imágenes ni ejecución de aptitudes. Estas funcionalidades se facturan por separado.

Comprender las unidades de cómputo (CU)

Una unidad de proceso (CU) representa los recursos del sistema medidos necesarios para realizar operaciones de búsqueda e indexación en el modelo sin servidor. El coste de la CU viene determinado principalmente por la utilización de CPU, memoria y E/S y, en segundo lugar, por el tamaño del índice y el tamaño de la carga útil del documento; el uso se factura en unidades de cómputo por hora (CU/h).

Escalas de coste de proceso con:

  • Complejidad de las consultas
  • Tamaño de índice (GB) y estructura
  • Tamaño de carga del documento (KB)
  • Número de campos y resultados recuperados

Las distintas operaciones tienen perfiles de costo diferentes:

  • Consulta: de bajo coste. Recuperar un único documento por su identificador es la operación más eficaz.
  • Búsqueda de palabras clave: bajo costo. La búsqueda de texto usa índices invertidos, que están optimizados para velocidad y bajo uso de proceso.
  • Búsqueda de vectores: alto costo. Las consultas vectoriales son costosas de cálculo porque requieren cálculos de similitud en incrustaciones de alta dimensión. En comparación con la búsqueda por palabras clave, consumen significativamente más capacidad de cómputo.
  • Búsqueda híbrida: combina el coste de la búsqueda por palabras clave y de vectores, ya que ambos procesos se ejecutan para cada consulta, además de una pequeña sobrecarga adicional de la fusión recíproca de rangos (RRF) para combinar los resultados.

Supervisar el uso de cómputo

La supervisión del consumo de proceso le ayuda a identificar operaciones costosas, optimizar los patrones de consulta y calcular los costos. El costo de unidad de proceso (CU) de cada solicitud se devuelve en el x-ms-request-charge encabezado de respuesta HTTP como un número de punto flotante. Use este encabezado para identificar operaciones costosas y optimizar los patrones de consulta. Puede realizar un seguimiento del costo de CU de cada solicitud inspeccionando los encabezados de respuesta HTTP y los eventos de operación en Azure Monitor. Para obtener más instrucciones sobre los tipos de datos de supervisión disponibles y métodos para analizar esos datos, consulte Supervisión de Búsqueda de Azure AI.

  • Encabezado: x-ms-request-charge: <value>
  • Valor: Un número de coma flotante que representa las CU consumidas.

Ejemplo:

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

En este ejemplo, la solicitud consumió 12.45 unidades de proceso. Puede usar este valor para identificar operaciones de alto costo y comparar el costo relativo de diferentes patrones de consulta.

Para revisar el consumo de proceso histórico de un servicio de búsqueda sin servidor, use las métricas de Azure Monitor en el portal de Azure:

  1. Vaya al servicio de búsqueda.
  2. Seleccione Métricas.
  3. Seleccione + Agregar métrica.
  4. En la lista de métricas, seleccione Uso de unidades de proceso.
  5. Use el gráfico para analizar las tendencias de uso e identificar períodos de mayor consumo de proceso.

La supervisión del uso agregado le ayuda a comprender los costos generales del servicio e identificar las cargas de trabajo que consumen la mayoría de los recursos de proceso. Para obtener descripciones de las métricas de supervisión disponibles, consulte Referencia de datos de supervisión. Puede utilizar los registros de Azure Monitor para realizar un seguimiento del uso total de CU a lo largo del tiempo y correlacionarlo con el volumen de consultas y los cambios en la carga de trabajo.

Captura de pantalla del panel de supervisión de métricas para unidades de proceso sin servidor en el Azure Portal.

Configura alertas para el uso de computación

Puede crear una regla de alerta para recibir una notificación cuando el consumo de proceso alcance un umbral especificado en el portal de Azure.

  1. Vaya a Alertas en el servicio de búsqueda.
  2. Seleccione + Crear regla de alertas.
  3. En Condición, seleccione Uso de unidades de proceso como la señal.
  4. Defina la lógica de alertas. Por ejemplo, se desencadena cuando el uso total es mayor que un valor especificado.
  5. Configure Acciones, como notificaciones de correo electrónico, SMS o webhook.
  6. Complete los pasos restantes y seleccione Revisar y crear.

Las alertas le ayudan a responder proactivamente a picos de uso inesperados y a administrar los costos.

Captura de pantalla de la creación de una regla de alertas en el Azure Portal.

Cálculo de los costos sin servidor

La calculadora de precios de Azure y la guía de planificación de capacidad basada en unidades de búsqueda (SU) no se aplican a los servicios que usan el modelo de precios sin servidor.

Para calcular los costos sin servidor:

  1. Datos de ejemplo representativos del índice.
  2. Ejecute cargas de trabajo típicas de indexación y consulta.
  3. Registre el x-ms-request-charge valor devuelto para cada operación.
  4. Use las métricas de Azure Monitor para medir el uso agregado a lo largo del tiempo.
  5. Extrapolar los costos en función del tráfico de producción esperado.

Dado que la misma solicitud ejecutada con los mismos datos generalmente genera un consumo de proceso similar, las cargas de trabajo representativas pueden proporcionar una base confiable para la estimación de costos.

El uso sin servidor se mide continuamente y se agrega para la facturación. Se hace un seguimiento del consumo de cómputo durante cada minuto y solo se registra cuando se utilizan recursos de cómputo.

Al calcular los costos, use los valores de cargo de solicitud para comprender el costo de las operaciones individuales y las métricas de Azure Monitor para comprender los patrones generales de consumo de servicios.

La facturación se basa en el uso de proceso agregado en lugar de en solicitudes individuales. El uso se mide en intervalos de un minuto y se redondea hasta los 0,25 CU más cercanos por minuto. Estos intervalos de uso de un minuto se acumulan durante una hora para determinar la cantidad facturable de CU/hora. Internamente, el uso se agrega desde milésimas de unidad de cómputo (mCU) hasta unidades de cómputo (CU) y se convierte en el uso por hora que se informa para la facturación.

Diferentes operaciones consumen distintas cantidades de capacidad de cómputo. En general:

  • Las búsquedas de palabras clave suelen usar los recursos de proceso mínimos.
  • Las búsquedas vectoriales suelen usar más recursos de proceso que las búsquedas de palabras clave.
  • Las búsquedas híbridas combinan la ejecución de palabra clave y búsqueda vectorial, por lo que suelen usar más recursos de proceso que cualquier técnica por sí sola.

El consumo de proceso real depende de factores como la complejidad de las consultas, el tamaño del índice, el volumen de datos, la configuración de vectores y el número de resultados devueltos. La supervisión de los cargos de solicitud y las métricas de uso agregado pueden ayudarle a identificar las oportunidades de optimización y predecir mejor los costos de producción.

Reducción de los costos de proceso a través de la optimización

Las consultas eficaces y el diseño de índices reducen el consumo de proceso y reducen los costos.

Optimización del esquema

El esquema del índice determina los costes básicos de cómputo y almacenamiento:

  • Limite los atributos del campo: habilite solo los atributos (de búsqueda, filtrables, de facetas y ordenables) cuando sea necesario. Cada atributo aumenta el tamaño del índice y el costo de indexación.
  • Simplificar tipos complejos: Asigne estructuras JSON anidadas a campos o colecciones sencillos siempre que sea posible.
  • Establezca retrievable=false para los campos usados solo para filtrar o solo para ordenar: si un campo se usa para filtrar u ordenar, pero no es necesario devolverlo en los resultados, manténgalo indexado y establezca retrievable=false para reducir el almacenamiento en disco y el coste de almacenamiento por GB al mes.
  • Use campos solo recuperables siempre que sea posible: por ejemplo, los campos usados solo para mostrar (como direcciones URL de imagen) no deben ser buscables.
  • Reducir dimensiones vectoriales: los vectores dimensionales superiores aumentan el costo de almacenamiento y consulta. Use modelos de inserción o cuantificación más pequeños cuando corresponda.
  • Minimizar el tamaño de carga del documento antes de la indexación: los documentos más grandes cuestan más para indexar. Quite campos innecesarios, recorte texto largo y seccione HTML antes de enviar documentos al índice.

Optimización de solicitudes de indexación

La forma de enviar datos al índice afecta tanto al costo como al rendimiento:

  • Use lotes más grandes cuando sea posible: la indexación por lotes reduce la sobrecarga por solicitud mediante la amortización de los costos de red y procesamiento en más documentos. En general, los lotes de hasta ~1000 documentos o ~16 MB son más eficientes en cuanto a CU que muchas solicitudes pequeñas. Sin embargo, el tamaño óptimo del lote depende de la carga de trabajo. Pruebe a equilibrar el rendimiento, la latencia y la confiabilidad.

  • Indexar solo datos nuevos o modificados: evite la reindexación completa cuando sea posible. El envío de solo adiciones y actualizaciones reduce el número de documentos procesados, lo que reduce el costo de proceso y mejora la velocidad de ingesta.

  • Usar la detección de cambios para la indexación incremental: detecte lo que ha cambiado antes de volver a procesar el contenido. La indexación incremental evita reprocesar documentos que no han cambiado y mantiene bajos los costes de reprocesamiento.

  • Omitir la extracción de imágenes a menos que lo necesite: la extracción de imágenes agrega un trabajo de procesamiento adicional y puede convertirse en un controlador de costos independiente. Encienda solo para documentos o flujos de trabajo que realmente necesiten contenido de imagen.

  • Dirija las habilidades a los campos y documentos pertinentes: limite las habilidades de enriquecimiento a los campos o documentos específicos que necesiten. Evite ejecutar aptitudes sobre contenido que no necesite enriquecimiento, especialmente cuando los resultados no se usan en fases descendentes.

  • Tenga en cuenta el crecimiento del tamaño del índice: siempre que sea posible, cree índices más pequeños. A medida que crece un índice, los costos de indexación aumentan porque se deben almacenar y mantener más datos, y las operaciones requieren más proceso. Para conjuntos de datos muy grandes, considere la posibilidad de crear particiones de datos entre varios índices para ayudar a administrar el rendimiento y los costos. Aunque los costos aumentan con el tamaño del índice, el aumento es sublineal. Los índices más grandes cuestan más por operación, pero no proporcionalmente más.

Para obtener más instrucciones, consulte Tips para mejorar el rendimiento en Búsqueda de Azure AI.

Optimización de las consultas

El diseño de consultas es un controlador principal del costo variable:

  • Utiliza $select para limitar los campos devueltos: Esto reduce el tamaño de la carga útil y los recursos de procesamiento necesarios para la serialización.

    GET /docs?search=test&$select=id,title,url
    
  • Use searchFields para limitar dónde se busca el texto: limite la coincidencia en tiempo de consulta a los campos que importan para el escenario. Cada campo adicional habilitado para búsqueda aumenta la carga de consulta y puede aumentar las CU/h.

  • Utilice de manera preferente consultas de coincidencia exactas o palabras clave simples: las consultas aproximadas, con comodín, regex y de prefijo pueden forzar análisis de índice amplios y consumir significativamente más CU/h. Úselos solo cuando necesite un comportamiento de coincidencia parcial y elija consultas exactas de coincidencias o palabras clave más sencillas siempre que sea posible.

  • Utiliza consultas por identificador en lugar de búsquedas cuando sea posible: recuperar un documento por ID es más eficiente que ejecutar una consulta de búsqueda. Si conoce el identificador del documento, realice una consulta por identificador en lugar de una consulta de búsqueda. Las búsquedas son más eficaces porque recuperan un documento directamente mediante clave, mientras que las consultas de búsqueda invocan la canalización de consulta completa (análisis, recorrido de índice, puntuación y clasificación), lo que aumenta el costo de proceso.

  • Evite la paginación profunda ($skip):los valores grandes $skip aumentan el proceso porque el motor debe procesar y clasificar todos los resultados anteriores (por ejemplo, $skip=5000 requiere la puntuación de al menos 5000 documentos que no se devuelven). Esto desperdicia recursos de computación (CUs) y aumenta el coste. En su lugar, use filtros para restringir los resultados y limitar el número devuelto con $top. Ajusta el tamaño de $top para que se adapte a la visualización de tu interfaz de usuario. Por ejemplo, $top=10 cuesta menos que $top=50 porque se puntuan y devuelven menos resultados. Solicite solo tantos resultados como necesite la aplicación y evite patrones que requieran que el motor procese un gran número de resultados sin usar.

  • Minimizar el recuento de facetas y el ámbito de faceta: solicite solo las facetas que se muestran en la interfaz de usuario y mantenga cada valor de faceta count tan bajo como práctico. Las facetas requieren agregaciones por consulta y los recuentos elevados aumentan el costo de proceso.

  • Uso search.in para el filtrado: al filtrar por una lista de identificadores o valores, use la search.in función en lugar de varias or condiciones (por ejemplo, id eq '1' or id eq '2'). Este enfoque es más eficaz y reduce la sobrecarga de proceso. También debe evitar marcar campos de cardinalidad alta (aquellos con un gran número de valores únicos, como identificadores únicos o descripciones de texto libre) como filtrables o facetables, a menos que sea necesario, ya que esto aumenta el tamaño del índice y el costo de la consulta.

Optimización de las solicitudes administrativas

Además de las operaciones de consulta e indexación, Búsqueda de Azure AI incluye operaciones administrativas de nivel de objeto y de nivel de servicio (como recuperar esquemas de índice o estadísticas de servicio). Estas solicitudes tienen un costo plano por solicitud. Aunque cada solicitud tiene un coste bajo, las llamadas repetidas o innecesarias pueden acumularse con el tiempo y aumentar el uso total de recursos de cómputo.

  • Evite las solicitudes administrativas excesivas: almacene en caché los metadatos, como los esquemas de índice, en el cliente en lugar de recuperarlos repetidamente. Por ejemplo, capturar el esquema de índice antes de que cada operación de escritura introduzca costos innecesarios. En el modelo sin servidor, este patrón aumenta directamente los cargos de proceso, mientras que en los servicios dedicados, el impacto suele ocultarse mediante la facturación por hora fija.

Optimiza los costes de vectores

Las cargas de trabajo vectoriales suelen ser el componente de mayor costo en la búsqueda del modelo de precios sin servidor porque afectan tanto a las unidades de proceso (consultas e indexación) como al almacenamiento (tamaño de vector en disco). Para reducir el costo, optimice cómo se almacenan los vectores y cómo se consultan.

Optimización del almacenamiento de vectores y el esquema

Los campos vectoriales pueden aumentar significativamente el tamaño del índice y el costo de indexación. Use las técnicas siguientes para reducir la sobrecarga de almacenamiento:

  • Usar compresión para reducir el tamaño del vector: aplique la cuantificación para reducir la superficie de almacenamiento con un impacto mínimo de relevancia. Por ejemplo, la cuantificación escalar puede reducir el almacenamiento de vectores hasta 4× con un impacto mínimo en la calidad de la búsqueda.

  • Deshabilite el almacenamiento de vectores cuando no sea necesario: establezca stored=false en los campos vectoriales si solo necesita vectores para la búsqueda, no para la recuperación. Esto evita almacenar los vectores originales en el índice, lo que reduce el costo de almacenamiento sin afectar al comportamiento de las consultas.

  • Use dimensiones de inserción más pequeñas cuando sea posible: los vectores dimensionales superiores aumentan el costo de almacenamiento y consulta. Para cargas de trabajo no críticas, use modelos de inserción más pequeños (por ejemplo, 384 o 768 dimensiones en lugar de 1536) para reducir el costo.

Optimización de la ejecución de consultas vectoriales

Las consultas vectoriales consumen muchos procesos porque requieren cálculos de similitud en estructuras de datos de alta dimensión.

  • Use la búsqueda híbrida de forma selectiva: las consultas híbridas ejecutan tanto la palabra clave como la recuperación de vectores. Use solo cuando sea necesario para la relevancia.

  • Aplicar filtros antes de las consultas vectoriales: restrinja el conjunto candidato antes de la búsqueda vectorial para reducir la cantidad de datos procesados. Consulte Funcionamiento del filtrado en consultas vectoriales.

Reducir los costos al minimizar el uso

El modelo sin servidor solo cobra por los recursos consumidos. Cuando no hay solicitudes, el uso de cómputo disminuye en consecuencia.

Para minimizar los costos de uso:

  • Ejecute consultas solo cuando sea necesario.
  • Evite solicitudes redundantes o excesivamente frecuentes.
  • Supervise el uso y ajuste las cargas de trabajo en función de la demanda.

Tip

La misma consulta puede tener diferentes perfiles de latencia y de CU según si el servicio está caliente o frío. Después de un período sin tráfico de lectura o escritura, el uso de proceso en el modelo de precios sin servidor cae a cero. La siguiente solicitud podría tener una latencia mayor y consumir más CU mientras las rutas de datos se estabilizan. Los índices más grandes suelen tardar más en calentarse que los índices más pequeños, por lo que los efectos del arranque en frío suelen ser más evidentes en los servicios de mayor tamaño.

Optimización de los costos de almacenamiento

El almacenamiento se factura por GB/mes en función del tamaño del índice en disco, que puede superar el tamaño de los datos sin procesar. Para reducir los costos de almacenamiento:

  • Quite los índices sin usar.
  • Minimice los campos almacenados.
  • Diseñe esquemas teniendo en cuenta la sobrecarga de almacenamiento.
  • Use proveedores de sugerencias de forma selectiva porque pueden aumentar drásticamente el tamaño del almacenamiento.

Para conocer las técnicas específicas de vectores (compresión, eliminación y configuración de almacenamiento), consulte Optimización para el almacenamiento y el procesamiento de vectores.

Para obtener más instrucciones sobre los inconvenientes de rendimiento de almacenamiento y consultas, consulte Tips para mejorar el rendimiento en Búsqueda de Azure AI.