Empieza por definir qué significa hacerlo bien
La calidad depende de la tarea. Un resumen debe conservar las ideas necesarias; una clasificación debe asignar la categoría adecuada; un agente debe ejecutar acciones autorizadas y detenerse cuando corresponde. «La respuesta suena bien» no explica qué parte del trabajo se está comprobando.
Separa los criterios que puedan fallar de forma distinta. Por ejemplo, una respuesta puede tener buen formato y contener información incorrecta. Una tarea también puede resolverse correctamente, pero con un tiempo o un coste incompatibles con su uso. Registrar estas dimensiones por separado facilita interpretar los resultados.
Ejemplo didáctico: clasificar solicitudes comerciales
Un equipo prepara una colección ficticia de mensajes: preguntas sobre precios, problemas de acceso, mensajes vacíos y consultas que mezclan varios asuntos. Antes de probar el modelo, acuerda qué categoría corresponde a cada caso y cuándo debe pedirse revisión.
Después compara las respuestas con ese criterio. Si el sistema confunde una incidencia con una oportunidad comercial, el equipo revisa ese fallo concreto. No basta con celebrar los mensajes bien clasificados. El ejemplo explica un método de prueba; no atribuye un porcentaje de acierto a una herramienta.
Cómo elegir los casos
Los casos deben parecerse al trabajo que quieres resolver e incluir situaciones difíciles. Añade variaciones de longitud, lenguaje, información incompleta y condiciones que cambien la respuesta. Si utilizas datos reales, prepara una versión adecuada al entorno de prueba y limita la información personal innecesaria.
Conserva algunos casos para comprobar la solución después de ajustar instrucciones o componentes. Si eliges cada cambio únicamente para resolver los mismos ejemplos, puedes mejorar esas pruebas y seguir fallando ante situaciones nuevas. Documenta qué colección se utilizó en cada comparación.
Qué puedes medir y quién revisa
Algunos criterios admiten validación directa: campos presentes, formato válido o uso de categorías permitidas. Otros requieren juicio, como comprobar si una explicación responde realmente a la pregunta. En esos casos conviene acordar una pauta de revisión con ejemplos de resultados aceptables e inaceptables.
Otro modelo puede ayudar a puntuar, pero su criterio también necesita comprobarse. Contrasta una muestra con revisión humana y examina los desacuerdos. No conviertas una puntuación automática en una decisión definitiva sin entender qué está midiendo.
Una evaluación no garantiza todos los casos futuros
El resultado solo describe las condiciones y casos probados. Cambiar el modelo, los documentos, el prompt o una herramienta puede alterar el comportamiento. Repite las comprobaciones afectadas y registra la versión del sistema que produjo cada resultado.
La evaluación previa se complementa con seguimiento durante el uso. Los fallos reales pueden convertirse en nuevos casos de prueba, para evitar repetirlos. El objetivo no es acumular un panel de cifras, sino disponer de evidencia suficiente para decidir qué se puede utilizar y qué necesita corrección.
Fuentes y documentación
Documentación del proveedor o del organismo citado. Los ejemplos de esta ficha son didácticos; no describen resultados de clientes.