Evaluar un modelo de IA exige convertir una impresión subjetiva en criterios observables. Una respuesta que parece natural puede omitir un requisito, inventar una fuente o devolver un formato que rompe la aplicación. La prueba debe reflejar el uso real, no solo ejemplos elegidos para una demostración.
Definir qué significa responder bien
Separa exactitud, cobertura, formato, tono, seguridad y tiempo de respuesta. Un clasificador puede necesitar precisión y recall; un asistente documental puede necesitar citas y abstención cuando falta información. No uses una única puntuación para tareas distintas.
Construir un conjunto de evaluación
Incluye consultas normales, casos límite, preguntas ambiguas, idiomas reales y entradas que no deben responderse. Conserva una referencia revisada y evita que los ejemplos de prueba se mezclen con los datos de entrenamiento o con el prompt de producción.
Evaluación automática y revisión humana
Las métricas automáticas ayudan a comparar versiones, pero no capturan todos los errores de significado. La revisión humana aporta contexto y puede etiquetar gravedad, aunque necesita criterios comunes para no depender de una opinión aislada.
Errores que importan más
Una respuesta incorrecta sobre una preferencia puede tener poco impacto; un importe, una condición contractual o un cambio de cuenta requiere otro umbral. Clasifica severidad y define si el sistema debe bloquear, pedir revisión o continuar.
Comparar versiones sin engañarse
Fija modelo, temperatura u opciones equivalentes, contexto, herramientas y conjunto de casos. Registra resultados, coste y latencia. Si solo cambia el prompt, conserva los demás parámetros para atribuir el efecto.
Evaluar en producción
Usa muestras anonimizadas, feedback y señales de derivación sin almacenar información innecesaria. Busca regresiones después de cambiar el modelo o la fuente de datos. La evaluación es un proceso continuo porque cambia la aplicación y cambia el comportamiento del entorno.
Qué decisión permite la métrica
Una prueba útil termina en una acción: publicar, limitar el alcance, añadir revisión o volver a una versión anterior. No tiene sentido optimizar una puntuación que no se relaciona con el riesgo o la experiencia que debe protegerse.
Etiquetas y criterios compartidos
Define qué se considera correcto, parcialmente correcto, incompleto o peligroso. Explica a quienes revisan cómo puntuar fuentes, formato, tono y omisiones. Un criterio diferente entre revisores hace que la métrica sea difícil de comparar.
Pruebas de regresión
Guarda casos que hayan causado problemas y ejecútalos después de modificar modelo, prompt, recuperación o herramientas. Incluye preguntas que deben rechazarse y acciones que requieren aprobación. La regresión debe detectar tanto respuestas peores como cambios que aumenten coste o latencia.
Datos reales con precaución
Las muestras de producción deben anonimizarse y limitarse al propósito de evaluación. No conviertas los logs en un segundo dataset sin revisar retención y permisos. Para datos sensibles, usa ejemplos sintéticos que conserven la dificultad técnica sin exponer información.
Decisiones a partir de resultados
Una evaluación puede decidir que una función se publique solo para un tipo de consulta, que se añada revisión o que se mantenga una regla determinista. La puntuación no sustituye al análisis del riesgo. Documenta el umbral y quién puede cambiarlo.
Diseñar casos que separen versiones
Incluye entradas normales, ambiguas, largas, mal formadas y fuera de alcance. Añade casos que requieran una fuente, una derivación o un rechazo. Una colección de preguntas fáciles no permite distinguir dos modelos ni detectar fallos importantes.
Revisión y acuerdos
Los revisores deben conocer el criterio de exactitud, cobertura y seguridad. Guarda el motivo de una puntuación y no solo el número final. Para tareas de alto impacto, un resultado automático debe pasar por una revisión proporcional.
Coste de una mejora
Compara calidad con latencia, tokens, coste y porcentaje de intervención. Una versión que mejora un punto de calidad y multiplica el coste puede no ser adecuada para todas las consultas. Documenta el alcance en el que sí aporta valor.
Más allá de una nota media
Una media puede ocultar un fallo grave en una categoría pequeña. Segmenta resultados por idioma, tipo de consulta, severidad y necesidad de fuente. Un sistema puede ser útil para borradores y no estar preparado para respuestas públicas.
Convertir resultados en límites
Usa los resultados para decidir alcance, revisión y fallback. La evaluación debe cerrar con una acción operativa y una fecha para repetirla.
Un ciclo que se pueda repetir
Guarda el conjunto, la versión del modelo, el prompt, el contexto y los parámetros. Repite después de cualquier cambio relevante y conserva los resultados. Sin ese control, una comparación no explica por qué una respuesta ha mejorado o empeorado.
La calidad debe relacionarse con el uso que se autoriza.
Segmentar antes de concluir
Separa resultados por tipo de consulta, idioma, severidad y necesidad de fuente. Una media puede ocultar un fallo grave en una categoría pequeña. Una versión puede ser adecuada para borradores y no para respuestas públicas.
Acción posterior a la medición
Si el resultado no alcanza el umbral, limita alcance, añade revisión, cambia la fuente o vuelve a una versión anterior. La métrica solo es útil cuando cambia una decisión operativa.
La prueba debe conservar los casos que causaron errores y repetirse después de cambiar modelo, prompt, recuperación o herramientas. Sin una referencia versionada, una mejora no se puede atribuir.