En esta página
Una respuesta sobre un pedido devuelto parece lista para enviar: es gramatical, amable y breve. En este ejemplo ilustrativo, un sistema automatizado le da la puntuación máxima. El asistente también comunica al cliente que ya se ha emitido un reembolso, aunque nadie haya comprobado el sistema de pagos.
El error no está en una frase débil. Está en una definición débil de lo que significa hacerlo bien.
En una demostración de evaluación, un equipo crea puntuaciones para un agente que redacta documentación de software. El momento interesante llega cuando quien conoce el trabajo explica qué significa calidad y una herramienta convierte esa descripción en criterios. Más adelante, una puntuación baja plantea la duda correcta: quizá hay que corregir el agente o quizá hay que corregir la evaluación.
La rúbrica es una teoría sobre la tarea. Pon a prueba esa teoría.
Empieza por el error que invalida el resultado
Los equipos suelen empezar por dimensiones fáciles de puntuar: claridad, tono, estructura, exhaustividad. Son útiles. Rara vez bastan.
En la respuesta ilustrativa sobre un reembolso, «nunca afirmes que se ha completado un reembolso sin un comprobante de pago» debe tener prioridad sobre la calidad de la prosa. En una sincronización de datos, «no asignes el correo de facturación al correo de la persona propietaria de la cuenta» importa más que lo bien que se lea la explicación del mapa de campos.
Pide a la persona experta en el dominio tres tipos de caso: uno claramente bueno, otro claramente incorrecto y uno sobre el que personas informadas podrían discrepar. Conserva los registros de origen y el motivo de cada valoración. Si un caso depende de una regla que puede cambiar, guarda la versión de la regla junto con la etiqueta.
La primera revisión puede ser pequeña. No puede ser imprecisa.
- Responsable de la tarea
casos buenos, malos y dudosos
- Comprobaciones exactas identidad · permiso · destino
el código verifica los datos
- Rúbrica semántica
el evaluador interpreta solo lo necesario
- Revisión de desacuerdos
corrige etiquetas y criterios
| Comprobación | Quién debe hacerse cargo | Motivo |
|---|---|---|
| Existe el permiso obligatorio | El código y los registros autorizados | Es un dato exacto y de consecuencias importantes |
| El ID de destino coincide con la identidad de origen | El código y un registro de prueba | Un modelo no debe adivinar un identificador |
| La respuesta contesta la pregunta del cliente | Rúbrica revisada por una persona, posiblemente un evaluador de modelos | El significado exige interpretación |
| El tono se adapta a la situación | Rúbrica revisada por una persona, posiblemente un evaluador de modelos | Puede haber más de una forma aceptable |
Nuestra guía para implementar IA en flujos de trabajo existentes también sitúa las decisiones automatizadas dentro de un proceso con controles. El código conserva los valores originales y comprueba las restricciones después de que un modelo elija entre opciones. La confianza del modelo no se convierte en un permiso.
Una puntuación hereda los puntos ciegos de su rúbrica
La objeción es razonable: «Una persona no puede revisar cada ejecución de un agente. Necesitamos un evaluador que pueda escalar». De acuerdo. La pregunta es qué se está ampliando.
Si la rúbrica premia una respuesta pulida y nunca comprueba si realmente se reembolsó el pedido, la automatización ampliará esa omisión. Un número con dos decimales parece preciso. Aun así, puede medir lo que no toca.
La documentación de Google Cloud sobre evaluación de jueces describe una comprobación práctica: prepara casos con valoraciones humanas, ejecuta la métrica basada en el modelo y compara sus puntuaciones con esas valoraciones. El objetivo no es afirmar que la opinión de una persona sea infalible. Es proporcionar una referencia externa al modelo antes de dar peso a su puntuación.
Examina los desacuerdos, no solo la coincidencia media. Si el evaluador aprueba una respuesta que una persona responsable de soporte rechazó, pregunta qué criterio ausente lo explica. Si dos expertos discrepan, conserva ambas valoraciones y busca la regla que interpretan de forma distinta. No ocultes la diferencia calculando un promedio.
El muestreo importa tanto como la redacción de los criterios. Una colección de éxitos rutinarios puede hacer que el evaluador parezca fiable y dejar sin probar los casos difíciles. Incluye registros incompletos, instrucciones contradictorias y situaciones en las que la respuesta correcta sea detenerse y preguntar. Mantén otro conjunto de casos que quienes redactan la rúbrica no hayan usado para ajustarla. Así, una mejora en ejemplos conocidos también tendrá que funcionar en otros casos. Cuando cambie la regla del negocio, actualiza las etiquetas y los resultados esperados; un conjunto de pruebas congelado puede premiar la política de ayer.
Mantén el resultado unido a la evaluación
Una rúbrica para un agente de sincronización debe seguir el resultado del cliente. ¿Cambió el contacto correcto? ¿Se respetó el consentimiento? ¿Se puede volver a procesar un registro fallido sin repetir una acción de consecuencias importantes?
La guía del conector de Brevo explica por qué una llamada a la API correcta puede coexistir con un atributo ausente. Una evaluación que solo compruebe si el agente llamó al endpoint no detectará el resultado. Otra que solo examine el destino podría pasar por alto una ruta prohibida que acabó casualmente con el valor correcto. Cuando el proceso conlleva riesgos, ambas cosas importan.
Empieza con una tarea acotada y algunos modos de fallo. Etiqueta los casos con la persona responsable de la tarea. Deja las comprobaciones exactas en el código y usa un modelo evaluador solo cuando el lenguaje o el criterio necesiten interpretación. Repite las mismas pruebas después de cambiar un prompt, un modelo o una herramienta. Anota qué revelan sobre la rúbrica los fallos posteriores.
El coste es dedicar tiempo experto al principio. La ventaja es que cada puntuación posterior tiene un significado que alguien puede defender.
Un panel puede mostrar una puntuación. Solo la rúbrica explica qué has contado.
Preguntas frecuentes
¿Quién debe definir los criterios de evaluación de un agente de IA?
Quienes conocen la tarea y sus consecuencias deben definir qué resultados son aceptables y qué errores los invalidan. El equipo de ingeniería puede convertir esos criterios en comprobaciones repetibles y evaluar si un modelo evaluador coincide con las valoraciones humanas.
¿Una puntuación alta del evaluador demuestra que el agente funciona?
No. Una puntuación mide la coincidencia con una rúbrica en los casos probados. Una rúbrica débil, casos poco representativos o un evaluador mal calibrado pueden dar una nota alta a un resultado perjudicial.
¿Qué debería comprobar el código en lugar de un evaluador de modelos?
Siempre que sea posible, el código debe comprobar los permisos exactos, los identificadores de registros, las llamadas a herramientas obligatorias y el estado de destino. Un evaluador de modelos sirve para cualidades semánticas que las reglas exactas no pueden resolver.