Nota
L'accés a aquesta pàgina requereix autorització. Podeu provar d'iniciar la sessió o de canviar els directoris.
L'accés a aquesta pàgina requereix autorització. Podeu provar de canviar els directoris.
Importante
El optimizador de agentes está actualmente en versión preliminar. Esta versión preliminar se ofrece sin acuerdo de nivel de servicio y no se recomienda para 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.
El optimizador de agentes evalúa tu agente frente a un conjunto de datos —una colección de tareas— evaluado por evaluadores. Puede generar ambos automáticamente desde la CLI o crear un conjunto de datos manualmente para el control total.
Ambas partes son esenciales para una buena optimización: el conjunto de datos define lo que se va a probar y los evaluadores definen cómo juzgar cada respuesta. Los evaluadores débiles producen puntuaciones ruidosas que conducen a una optimización deficiente, por lo que invierte en evaluadores sólidos tanto como tareas representativas.
La creación de estos recursos es el segundo paso del flujo de trabajo de optimización, después de que el optimizador del agente esté listo. El optimizador los usa para puntuar tu línea base y clasificar a los candidatos.
Prerrequisitos
- Un proyecto de Foundry con un agente hospedado implementado
- La extensión de la CLI
azure.ai.agentsinstalada (consulte Inicio rápido: Optimizar un agente alojado)
Generación de un conjunto de datos y evaluadores (recomendado)
La forma más rápida de crear recursos de evaluación es con azd ai agent eval generate. El comando detecta automáticamente el agente y genera todo lo que necesita el optimizador:
azd ai agent eval generate
De forma predeterminada, genera:
- Un conjunto de datos semilla de tareas ajustadas al dominio de tu agente.
-
Evaluadores que puntúan las respuestas: un evaluador integrado (como
builtin.task_adherence) más un evaluador de rubric personalizado adaptado al agente. - Un
eval.yamlejecutable que los conecta.
Para el asistente interactivo, las marcas no interactivas y los detalles sobre los artefactos generados, consulte Inicializar recursos de evaluación.
Después de la generación, azd ai agent optimize detecta eval.yamlautomáticamente :
azd ai agent optimize
Para personalizar los recursos generados, consulte Personalización de evaluadores y Creación de un conjunto de datos personalizado. Para cambiar las opciones de ejecución, edite eval.yaml; consulte Configuración de la ejecución de optimización.
Personalización de evaluadores (avanzados)
Los evaluadores puntúan cada respuesta del agente. El optimizador admite dos tipos:
-
Evaluadores integrados, como
builtin.task_adherence, que puntúa cada criterio de nivel de tarea como aprobado o no. -
Evaluadores de rúbrica personalizados, que puntúan las respuestas en varias dimensiones de calidad adaptadas a su agente.
azd ai agent eval generatecrea uno automáticamente como un archivo editablerubric_dimensions.json.
Para la mayoría de los agentes, el evaluador de rúbricas generado ofrece las puntuaciones más relevantes porque está adaptado a tu dominio. Edite el elemento generado rubric_dimensions.json para refinar las dimensiones y, a continuación, ejecute azd ai agent eval update para registrar los cambios como una nueva versión. Para más información sobre la generación, edición y control de versiones de evaluadores, consulte Inicializar recursos de evaluación.
Para conectar evaluadores a la configuración de ejecución, consulte Configuración de la ejecución de optimización.
Creación de un conjunto de datos personalizado (avanzado)
Cree un conjunto de datos personalizado cuando necesite un control preciso sobre escenarios de prueba o tenga datos de producción para usarlos directamente. El enfoque recomendado es seguir iterando a partir del conjunto de datos base que azd ai agent eval generate genera: refínelo hasta convertirlo en un conjunto de datos local o haga referencia a otro conjunto de datos ya registrado en su proyecto de Foundry.
Elección de un origen de conjunto de datos
Un conjunto de datos puede provenir de cualquiera de dos orígenes:
-
Conjunto de datos de Foundry — un conjunto de datos ya registrado en tu proyecto de Foundry. Haga referencia a él en
eval.yamlpornameyversion. -
Conjunto de datos local : un archivo JSONL que crea y mantiene en el proyecto. Haga referencia a él en
eval.yamlporlocal_uri.
Ambos orígenes usan el mismo esquema de tareas descrito en la sección siguiente. Para el cableado eval.yaml, consulte Configurar la ejecución de optimización.
Esquema del conjunto de datos
Un conjunto de datos usa formato JSONL (líneas JSON). Cada línea es un objeto JSON que representa una sola tarea de evaluación, un escenario individual. Una tarea tiene un prompt (query) y, opcionalmente, instrucciones a nivel de tarea criteria.
{"name": "task_1", "query": "Your prompt here"}
{"name": "task_2", "query": "Another prompt", "ground_truth": "Expected answer"}
| Campo | Obligatorio | Description |
|---|---|---|
name |
Sí | Identificador de tarea único (por ejemplo, "greeting", "math_test"). |
query |
Sí | Mensaje enviado al agente. |
ground_truth |
No | Respuesta esperada, usada por evaluadores que admiten una referencia. |
criteria |
No | Comprobaciones de nivel de tarea opcionales. Consulte Agregar criterios de nivel de tarea. |
Al usar un conjunto de datos local, valide la sintaxis JSONL antes de ejecutar la optimización:
python -c "import json; [json.loads(l) for l in open('eval.jsonl')]"
Agregar criterios de nivel de tarea
Los criterios son opcionales. Los evaluadores que configure en eval.yaml se aplican a todas las tareas del conjunto de datos. Añada criteria para cada tarea solo si una tarea concreta requiere comprobaciones adicionales a las de esos evaluadores compartidos. Cuando una tarea tiene criteria, estos se puntúan y se agregan junto con los evaluadores compartidos para generar la puntuación general de la tarea.
| Campo | Obligatorio | Description |
|---|---|---|
criteria[].name |
Sí | Nombre corto para el criterio (por ejemplo, "is_polite"). |
criteria[].instruction |
Sí | Lo que comprueba el evaluador. Sea específico y comprobable. |
El siguiente conjunto de datos de soporte al cliente muestra tareas con criterios de nivel de tarea:
{"name": "refund_policy", "query": "What is your refund policy?", "criteria": [{"name": "mentions_30_days", "instruction": "Response must mention the 30-day refund window"}, {"name": "polite_tone", "instruction": "Response must be professional and empathetic"}]}
{"name": "order_status", "query": "Where is my order #12345?", "criteria": [{"name": "asks_for_details", "instruction": "Agent should ask for email or order details to look up the order"}, {"name": "no_hallucination", "instruction": "Agent must NOT make up a fake order status"}]}
{"name": "out_of_scope", "query": "Can you help me fix my car?", "criteria": [{"name": "polite_decline", "instruction": "Agent should politely explain this is outside its scope"}, {"name": "redirect", "instruction": "Agent should suggest contacting an appropriate service"}]}
Sugerencias para escribir buenos conjuntos de datos
Incluir casos perimetrales
Pruebe más allá de la ruta feliz. Inclusión:
- Solicitudes fuera del ámbito : las entradas que el agente debe rechazar o redirigir
- Consultas ambiguas : tareas en las que el agente debe pedir aclaración
- Entradas adversarias — Intentos de inducir al agente a comportarse de forma incorrecta
- Tareas de varios pasos : solicitudes complejas que requieren razonamiento estructurado
Directrices de tamaño
| Tamaño del conjunto de datos | Compromiso |
|---|---|
| De 3 a 5 tareas | Iteración rápida, señal limitada |
| 5–10 tareas | Buen equilibrio de velocidad y cobertura |
| 10–20 tareas | Evaluación completa, ejecuciones más largas |
| Más de 20 tareas | Exhaustiva pero lenta: considere la posibilidad de realizar la validación final. |
Los conjuntos de datos más grandes proporcionan una cobertura más amplia, pero tardan más tiempo en evaluarse.
Proporcionar la verdad básica cuando sea útil
El ground_truth campo proporciona a los evaluadores una respuesta de referencia con la que comparar. No es necesario; los evaluadores también pueden juzgar las respuestas basándose únicamente en sus instrucciones y en cualquier criterio a nivel de tarea.
{"name": "geography_fact", "query": "What is the largest city in France by population?", "ground_truth": "Paris", "criteria": [{"name": "correct_answer", "instruction": "Response must state that Paris is the largest city in France by population"}]}
Escribe instrucciones como usuarios reales
Use mensajes reales de los usuarios si es posible. Los avisos reales capturan el vocabulario y el contexto a los que se enfrenta el agente en producción, lo que también le ayuda a escribir criterios realistas de nivel de tarea.
Ser específico en criterios
Los criterios imprecisos conducen a una puntuación incoherente. Hacer que cada criterio sea específico y comprobable.
Malo:
{"name": "good_answer", "instruction": "The response should be good"}
Bien:
{"name": "mentions_30_days", "instruction": "Response must explicitly mention the 30-day refund window"}
Solución de problemas
| Problema | Causa | Corregir |
|---|---|---|
dataset not found |
Ruta de acceso incorrecta en eval.yaml |
Para dataset.local_uri, use una ruta de acceso relativa a la ubicación del archivo de configuración. Para un conjunto de datos de Foundry, verifique dataset.name y dataset.version. |
invalid JSON on line N |
JSONL con formato incorrecto | Compruebe que cada línea es JSON válido. Compruebe si hay comas finales. |
| Las puntuaciones son incoherentes entre ejecuciones | Criterios imprecisos | Hacer que los criterios sean específicos y se puedan probar. |