Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Nota:
Esta característica actualmente está en su versión preliminar pública. 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 sean compatibles o que tengan sus funcionalidades limitadas. Para más información, consulte Términos de uso complementarios para las versiones preliminares de Microsoft Azure.
¿Qué es la recuperación de agentes? En Búsqueda de Azure AI, la recuperación agentica es una nueva canalización de múltiples consultas diseñado para preguntas complejas planteadas por usuarios o agentes en aplicaciones inteligentes de chat y copilotas. Está diseñado para patrones de generación aumentada de recuperación (RAG) y flujos de trabajo de agente a agente.
Esto es lo que hace:
Usa un modelo de lenguaje grande (LLM) para dividir una consulta compleja en subconsultas más pequeñas y centradas para mejorar la cobertura sobre el contenido indexado. Las subconsultas pueden incluir el historial de chats para contexto adicional.
Ejecuta subconsultas en paralelo. Cada subconsulta se vuelve a clasificar semánticamente para promover las coincidencias más relevantes.
Combina los mejores resultados en una respuesta unificada que un LLM puede usar para generar respuestas con el contenido de su propiedad.
La respuesta es modular pero completa en la forma en que también incluye un plan de consulta y documentos de origen. Puede optar por usar solo los resultados de búsqueda como datos de base o invocar el LLM para formular una respuesta.
Esta canalización de alto rendimiento le ayuda a generar datos de base de alta calidad (o una respuesta) para la aplicación de chat, con la capacidad de responder rápidamente a preguntas complejas.
Desde el punto de vista de la programación, la recuperación de agentes se admite a través de un nuevo objeto de bases de conocimiento en la versión preliminar 2025-11-01 y en los paquetes preliminares de Azure SDK que proporcionan la característica. La respuesta de recuperación de una base de conocimiento está diseñada para el consumo descendente por parte de otros agentes y aplicaciones de chat.
Por qué utilizar la recuperación agente
Debe utilizar la recuperación agéntica cuando desee proporcionar a los agentes y las aplicaciones el contenido más relevante para responder a preguntas más difíciles, utilizando el contexto del chat y su contenido propietario.
El aspecto agéntica es un paso de razonamiento en el procesamiento de planeamiento de consultas que realiza un modelo de lenguaje grande (LLM) admitido que proporcione. LLM analiza todo el subproceso de chat para identificar la necesidad de información subyacente. En lugar de una sola consulta catch-all, LLM divide las preguntas compuestas en subconsultas centradas en función de: preguntas de usuario, historial de chat y parámetros en la solicitud. Las subconsultas tienen como destino los documentos indexados (texto sin formato y vectores) en Azure AI Search. Este enfoque híbrido garantiza que se muestren coincidencias de palabras clave y similitudes semánticas a la vez, lo que mejora considerablemente la recuperación.
El componente de recuperación es la capacidad de ejecutar subconsultas simultáneamente, combinar resultados, clasificar semánticamente los resultados y devolver una respuesta de tres partes que incluya datos de base para el próximo turno de conversación, datos de referencia para poder inspeccionar el contenido de origen y un plan de actividad que muestre los pasos de ejecución de consultas.
La expansión de consultas y la ejecución en paralelo, además de la respuesta de recuperación, son las funcionalidades clave de la recuperación agente que lo convierten en la mejor opción para las aplicaciones de IA generativa (RAG).
La recuperación agentica agrega latencia al procesamiento de consultas, pero lo compensa agregando estas funcionalidades:
- Lee en el historial de chat como entrada para la canalización de recuperación.
- Deconstruye una consulta compleja que contiene varias "preguntas" en partes de componentes. Por ejemplo: "encontrarme un hotel cerca de la playa, con transporte del aeropuerto, y eso está a poca distancia a pie de restaurantes vegetarianos".
- Reescribe una consulta original en varias subconsultas mediante mapas de sinónimos (opcional) y frases generadas por LLM.
- Corrige los errores ortográficos.
- Ejecuta todas las subconsultas simultáneamente.
- Genera un resultado unificado como una sola cadena. Como alternativa, puede extraer partes de la respuesta para su solución. Los metadatos sobre la ejecución de consultas y los datos de referencia se incluyen en la respuesta.
La recuperación agente invoca la canalización de procesamiento de consultas completa varias veces para cada subconsulta, pero lo hace en paralelo, conservando la eficiencia y el rendimiento necesarios para una experiencia de usuario razonable.
Nota:
Incluir un LLM en la planificación de consultas añade latencia a una cadena de consultas. Puede mitigar los efectos utilizando modelos más rápidos, como el gpt-4o-mini, y resumiendo los hilos de mensajes. Puede minimizar la latencia y los costos estableciendo propiedades que limitan el procesamiento de LLM. También puede excluir por completo el procesamiento de LLM para utilizar solo texto, búsqueda híbrida y su propia lógica de planificación de consultas.
Arquitectura y flujo de trabajo
La recuperación de agentes está diseñada para experiencias de búsqueda conversacional que usan un LLM para desglosar de forma inteligente consultas complejas. El sistema coordina varios servicios de Azure para ofrecer resultados de búsqueda completos.
Cómo funciona
El proceso de recuperación agente funciona de la siguiente manera:
Inicio del flujo de trabajo: la aplicación llama a una base de conocimiento con la acción de recuperación que proporciona una consulta y el historial de conversaciones.
Planeamiento de consultas: una base de conocimiento envía el historial de consultas y conversaciones a un LLM, que analiza el contexto y divide preguntas complejas en subconsultas centradas. Este paso se automatiza y no se puede personalizar.
Ejecución de consultas: la base de conocimiento envía las subconsultas a las fuentes de conocimiento. Todas las subconsultas se ejecutan simultáneamente y pueden ser palabra clave, vector y búsqueda híbrida. Cada subconsulta se somete a la reevaluación semántica para encontrar las coincidencias más relevantes. Las referencias se extraen y conservan con fines de cita.
Síntesis de resultados: el sistema combina todos los resultados en una respuesta unificada con tres partes: contenido combinado, referencias de origen y detalles de ejecución.
El índice de búsqueda determina la ejecución de consultas y las optimizaciones que se producen durante la ejecución de la consulta. En concreto, si el índice incluye campos de texto y vector que se pueden buscar, se ejecuta una consulta híbrida. Si el único campo que se puede buscar es un campo vectorial, solo se usa la búsqueda de vectores puros. La configuración semántica del índice, además de perfiles de puntuación opcionales, mapas de sinónimos, analizadores y normalizadores (si agrega filtros) se usan durante la ejecución de consultas. Debe tener valores predeterminados con nombre para una configuración semántica y un perfil de puntuación.
Componentes requeridos
| Componente | Service | Rol |
|---|---|---|
| LLM | Azure OpenAI | Crea subconsultas a partir del contexto de conversación y, posteriormente, usa datos de base para la generación de respuestas. |
| Knowledge Base | Azure AI Search | Organiza la canalización, se conecta a LLM y administra los parámetros de consulta. |
| Fuente de conocimiento | Azure AI Search | Encapsula el índice de búsqueda con propiedades relacionadas con el uso de la base de conocimiento |
| Índice de búsqueda | Azure AI Search | Almacena el contenido que se puede buscar (texto y vectores) con configuración semántica |
| Clasificador semántico | Azure AI Search | Componente necesario que vuelve a ordenar los resultados según la relevancia (reordenamiento L2) |
Requisitos de integración
La aplicación impulsa la canalización llamando a la base de conocimiento y controlando la respuesta. La canalización devuelve datos de puesta a tierra que se pasan a un LLM para la generación de respuestas en la interfaz de conversación. Para obtener más información sobre la implementación, consulte Tutorial: Compilación de una solución de recuperación agente de un extremo a otro.
Nota:
Solo se admiten modelos gpt-4o, gpt-4.1 y gpt-5 para el planeamiento de consultas. Puede usar cualquier modelo para la generación final de respuestas.
Cómo empezar
Para crear una solución de recuperación agente, puede usar Azure Portal, las API REST de versión preliminar más recientes o un paquete de Azure SDK de versión preliminar que proporciona la funcionalidad.
Actualmente, el portal solo admite la creación de índices de búsqueda y fuentes de conocimiento BLOB. Se deben crear otros tipos de orígenes de conocimiento mediante programación.
- Inicio rápido: Uso de la recuperación agente en Azure Portal
- Inicio rápido: Uso de la recuperación agente en Azure AI Search (C#, Java, JavaScript, Python, TypeScript, REST)
Disponibilidad y precios
La recuperación proactiva está disponible en regiones seleccionadas. Los orígenes de conocimiento y las bases de conocimiento también tienen límites máximos que varían según el nivel de servicio.
Tiene una dependencia de las características premium. Si deshabilita el clasificador semántico para el servicio de búsqueda, deshabilita efectivamente la recuperación de agentes.
| Planificación | Description |
|---|---|
| Gratuito | Un servicio de búsqueda de nivel gratuito proporciona 50 millones de tokens de razonamiento agente gratuitos al mes. En los niveles superiores, puede elegir entre el plan gratuito (valor predeterminado) y el plan estándar. |
| Estándar | El plan estándar funciona con pago por uso una vez que se consume la cuota gratuita mensual. Una vez que se haya usado la cuota gratuita, se le cobrará una tarifa adicional por cada millón de tokens de razonamiento agente adicionales. No se le notifica cuando se produce la transición. Para más información sobre los cargos por moneda, consulte la página de precios de Azure AI Search. |
La facturación basada en tokens para la planeación de consultas basada en LLM y la síntesis de respuestas (opcional) es de pago por uso en Azure OpenAI. Está basado en tokens tanto para los tokens de entrada como para los de salida. El modelo que usted asigna a la base de conocimiento es el que se cobra en función del uso de tokens. Por ejemplo, si usa gpt-4o, el costo de tokens aparece en la factura de gpt-4o.
La facturación basada en tokens para la recuperación de agentes es el número de tokens devueltos por cada subconsulta.
| Aspecto | Canalización de consulta única clásica | Canalización de varias consultas de recuperación agente |
|---|---|---|
| Unidad | Basado en consultas (1000 consultas) por unidad de moneda | Basado en tokens (1 millón de tokens por unidad de moneda) |
| Costo por unidad | Costo uniforme por consulta | Costo uniforme por token |
| Estimación de costos | Estimación del recuento de consultas | Estimación del uso de tokens |
| Nivel gratuito | 1000 consultas gratuitas | 50 millones de tokens gratuitos |
Ejemplo: estimación de costos
La recuperación de agentes tiene dos modelos de facturación: facturación de Azure OpenAI (planificación de consultas y, si está habilitada, síntesis de respuestas) y facturación de Búsqueda de Azure AI para la recuperación de agentes.
En este ejemplo de precios se omite la síntesis de respuestas, pero ayuda a ilustrar el proceso de estimación. Sus costos podrían ser más bajos. Para conocer el precio real de las transacciones, consulte Precios de Azure OpenAI.
Costos de facturación estimados para el planeamiento de consultas
Para calcular los costos del plan de consulta como pago por uso en Azure OpenAI, supongamos gpt-4o-mini:
- 15 céntimos por 1 millón de fichas de entrada.
- 60 centavos para 1 millón de tokens de salida.
- 2000 tokens de entrada para el tamaño medio de la conversación de chat.
- 350 tokens para el tamaño medio del plan de salida.
Costos estimados de facturación para la ejecución de consultas
Para calcular los recuentos de tokens de recuperación automática, comience teniendo una idea de cómo sería un documento promedio en el índice. Un cálculo aproximado, por ejemplo, sería:
- 10 000 fragmentos, donde cada fragmento es de uno a dos párrafos de un PDF.
- 500 tokens por fragmento.
- Cada subconsulta reordena hasta 50 fragmentos.
- En promedio, hay tres subconsultas por plan de consulta.
Cálculo del precio de ejecución
Supongamos que realizamos 2000 recuperaciones agente con tres subconsultas por plan. Esto nos proporciona aproximadamente 6000 consultas totales.
Rerankear 50 fragmentos por subconsulta, que son 300,000 fragmentos en total.
El fragmento medio es de 500 tokens, por lo que el número total de tokens para el reranking es de 150 millones.
Dado un precio hipotético de 0,022 por token, $3,30 es el costo total de reranking en dólares estadounidenses.
Pasar a los costos del plan de consulta: 2000 tokens de entrada multiplicados por 2000 recuperaciones agente equivalentes a 4 millones de tokens de entrada para un total de 60 centavos.
Calcule los costos de salida en función de un promedio de 350 tokens. Si multiplicamos 350 por 2000 recuperaciones agente, obtenemos 700 000 tokens de salida totales para un total de 42 centavos.
En conjunto, pagaría aproximadamente 3,30 USD por la recuperación de agentes en Búsqueda de Azure AI. Además, pagaría 60 centavos por los tokens de entrada en Azure OpenAI y 42 centavos por los tokens de salida en Azure OpenAI. En total, serían 1,02 USD para la planificación de consultas. El costo combinado de la ejecución completa es de 4,32 USD.
Sugerencias para controlar los costos
Revise el registro de actividad en la respuesta para averiguar qué consultas se emitieron a qué orígenes y parámetros se usaron. Puede volver a emitir esas consultas en los índices y usar un tokenizador público para calcular los tokens y compararlos con el uso notificado por la API. Sin embargo, no se garantiza una reconstrucción precisa de una consulta o respuesta. Entre los factores se incluyen el tipo de origen de conocimiento, como los datos web públicos o un origen de conocimiento remoto de SharePoint que está basado en una identidad de usuario, lo que puede afectar a la ejecución de consultas.
Reduzca el número de orígenes de conocimientos (índices); consolidar el contenido puede reducir el volumen de distribución ramificada y tokens.
Reduzca el esfuerzo de razonamiento para reducir el uso de LLM durante el planeamiento de consultas y la expansión de consultas (búsqueda iterativa).
Organice el contenido para que la información más relevante se pueda encontrar con menos fuentes y documentos (por ejemplo, resúmenes o tablas elaborados).