La evaluación automatizada de LLMs convierte un comportamiento esperado en una comprobación repetible. En un agente de producción, la unidad evaluada suele ser una conversación con herramientas y estado. Una respuesta fluida todavía puede usar el registro equivocado, inventar un precio u omitir una transferencia obligatoria. La evaluación debe revisar esos resultados.
Empieza con casos que representen decisiones
Escribe escenarios con estado inicial, turnos del usuario, operaciones esperadas y resultados inaceptables. Incluye tareas normales, límites de autorización, solicitudes ambiguas y fallos de dependencias. Versiona los casos junto a la configuración que evalúan.
Un caso de referencia expresa una expectativa, no una verdad inmutable. Si cambia la política del producto, revisa la expectativa junto con ella. Conserva un conjunto reservado para validación más amplia, de modo que ajustar la rúbrica no se vuelva memorizar las pruebas.
Usa comprobaciones deterministas cuando sea posible
Nombres de herramientas, campos obligatorios, importes exactos y operaciones prohibidas deben comprobarse directamente. Reserva el juicio de otro modelo para cualidades que requieren interpretación, como responder a la solicitud dentro de su contexto. Dale al juez el estado real del caso, incluida cualquier fecha simulada.
Caso ilustrativo:
el usuario pide la factura de otro cliente
esperado: acceso denegado; ningún registro protegido en la respuesta
comprobaciones: decisión de permisos + resultado real de herramienta
juez: explicación opcional; no controla el permiso
Calibra al juez con etiquetas humanas
Compara veredictos con ejemplos etiquetados, investiga desacuerdos y revisa la rúbrica. Mide aprobaciones y rechazos incorrectos por separado. Repetir juicios o votar puede reducir variación de muestreo; no elimina un error sistemático de la rúbrica. Conserva versiones del modelo y del criterio para investigar cambios de puntuación.
Mi caso público de educación describe la construcción de casos de referencia como código y del harness de evaluación que los ejecuta. Explica fallos concretos: un juez usando la fecha equivocada, defectos de formato inventados y estado compartido que contaminaba casos.
Aísla el estado y ajusta el control a la decisión
Cada caso necesita su propio usuario y estado inicial. Limpia los efectos y evita que un caso modifique el punto de partida de otro. Ejecuta un grupo pequeño de pruebas de humo en cambios frecuentes y una regresión más completa antes de promover. Registra qué candidato fue evaluado; un resultado verde de otra configuración no respalda el release.
Evalúa al evaluador
Introduce deliberadamente una llamada prohibida, un precio incorrecto o evidencia faltante y comprueba que la suite falle. Después restaura el comportamiento válido y verifica que pase. Busca veredictos inestables, huecos de cobertura y casos que aprueban porque la acción relevante nunca ocurrió.
Para elegir un ingeniero, pide casos fallidos, desacuerdos de calibración y cómo se impidió desplegar un candidato rechazado. El trabajo y la investigación siguientes permiten comenzar esa revisión.