Cómo diseñar una evaluación propia de IA: del caso de uso a un umbral de despliegue verificable

Los benchmarks públicos son una señal inicial, no una decisión de despliegue

Una tabla de benchmarks responde, en el mejor de los casos, a una pregunta acotada: cómo rindió un modelo bajo un protocolo concreto, con un conjunto de tareas, una versión y unas reglas de puntuación determinadas. No responde por sí sola si un asistente será útil, seguro, suficientemente rápido o asumible en coste dentro de un proceso real. La diferencia es importante porque un producto no está formado únicamente por un modelo. Incluye instrucciones, herramientas, recuperación de documentos, formatos de salida, controles de acceso, interfaz, personas supervisoras y procedimientos de excepción.

Los benchmarks pueden ayudar a reducir el número de candidatos y a formular hipótesis. Por ejemplo, una prueba pública orientada a programación puede ser relevante si el trabajo se parece a resolver incidencias de software; una prueba de terminal puede aportar información cuando el agente debe operar en terminales y entornos reales; y otra centrada en interfaces puede ser más cercana cuando la tarea exige usar interfaces gráficas. Sin embargo, la similitud aparente no elimina la necesidad de probar el flujo propio, con las restricciones y los datos que realmente encontrará el sistema.

La literatura práctica sobre benchmarks de modelos advierte limitaciones como la contaminación de datos, diferencias de configuración y resultados que no capturan la latencia ni la integración de herramientas. Esas limitaciones no invalidan las pruebas públicas: delimitan el tipo de inferencia que permiten. El análisis recomendable es usar sus resultados como contexto externo y reservar la decisión de producto para una evaluación local, repetible y documentada.

Para explorar esa diferencia conviene incluir, dentro del clúster editorial, el recurso «Qué pueden aportar —y qué no— los benchmarks públicos». Esta guía debe enlazar también desde la página matriz de aprendizaje, en el bloque «Guías para implementar y verificar», y recibir un enlace de descubrimiento con el módulo «Antes de elegir un modelo: evalúalo con tu caso de uso». La publicación debe condicionarse a que esos destinos y su navegación queden implementados o planificados en el mismo clúster.

Traducir el problema a una hipótesis evaluable

El punto de partida no debería ser «qué modelo obtiene más puntos», sino una descripción verificable de la tarea. Identifique quién usa el sistema, qué entrada entrega, qué resultado necesita, qué acciones posteriores dependen de ese resultado y qué sucede cuando el sistema falla. Una clasificación equivocada de una consulta comercial puede requerir corrección; una respuesta que atribuye falsamente una afirmación a un documento interno puede inducir una decisión errónea; una acción externa no autorizada puede tener consecuencias más graves. La métrica y el umbral deben reflejar esa diferencia.

Una hipótesis útil tiene forma condicional: para un segmento de usuarios y tareas definido, el sistema produce un resultado que satisface criterios explícitos con un nivel de calidad, tiempo y coste compatibles con el proceso, sin superar un presupuesto de errores. Este enunciado obliga a decidir qué significa «satisface». En una extracción estructurada puede significar campos válidos y correctos. En un resumen puede requerir cobertura de los puntos relevantes, ausencia de invenciones y atribución a las fuentes disponibles. En un agente puede ser completar una tarea sin violar permisos ni necesitar más intervención humana de la prevista.

Microsoft describe, para la priorización de casos de uso, un marco que combina viabilidad empresarial, experiencia y conveniencia, y viabilidad tecnológica. Es un marco de priorización, no una prueba de calidad de un modelo; aun así, sirve para evitar una omisión frecuente: evaluar la capacidad técnica sin comprobar que el caso dispone de proceso, propietario, datos, experiencia de usuario y beneficio operativo plausibles.

Delimitar y versionar el sistema completo

La reproducibilidad exige declarar qué se comparó. Registre el proveedor y la versión o identificador del modelo cuando estén disponibles, la fecha de ejecución, los parámetros de generación, la plantilla de instrucciones, el mensaje de sistema, las herramientas disponibles, sus versiones, el esquema de salida, el índice de recuperación, la versión de los documentos y las reglas de permisos. Añada la lógica de reintentos, validación, fallback y escalado humano. Si no puede reconstruirse esta configuración, una diferencia de resultado entre dos ejecuciones será difícil de interpretar.

No todos los componentes cambian con la misma frecuencia. Un proveedor puede actualizar un servicio, los documentos internos pueden cambiar cada día y un equipo puede modificar una instrucción para resolver un fallo. El registro no evita esos cambios, pero permite saber qué cambió antes de atribuir una mejora o regresión al modelo. Es especialmente importante no comparar una alternativa con recuperación actualizada contra otra con un índice anterior, ni atribuir a una variante de modelo un resultado producido por un prompt diferente.

La congelación no implica inmovilizar el producto. Durante una ronda de evaluación, significa fijar una configuración candidata y un conjunto de prueba antes de observar los resultados. Al terminar, se puede proponer una nueva versión, pero debe volver a evaluarse contra la misma referencia o contra una referencia explícitamente actualizada. Esta disciplina reduce el riesgo de elegir retrospectivamente el prompt que tuvo suerte en el test.

Construir un conjunto de evaluación representativo y separado

Un conjunto de evaluación debe representar decisiones y condiciones de operación, no solo ejemplos fáciles o memorables. Empiece por muestrear tareas históricas, observando segmentos relevantes: idioma, longitud, tipo de documento, canal de entrada, nivel de ambigüedad, casos frecuentes y casos de alto impacto. Después añada casos difíciles deliberados: instrucciones contradictorias, información incompleta, documentos desactualizados, entradas malformadas, solicitudes fuera de alcance y situaciones en las que el resultado correcto es abstenerse o pedir aclaración.

Separe al menos dos particiones: desarrollo y prueba. La de desarrollo sirve para diseñar prompts, reglas, herramientas y rúbricas. La de prueba se reserva para una comparación final o para hitos definidos. La razón metodológica es sencilla: si se ajusta el sistema repetidamente tras ver los resultados de los mismos casos, esas observaciones dejan de medir generalización y pasan a formar parte del desarrollo. Una tercera partición de validación puede ser útil en proyectos con suficientes datos, pero no es un requisito universal; lo importante es documentar el uso de cada caso.

Los datos privados introducen obligaciones prácticas adicionales. Minimice los datos personales y secretos incluidos en la evaluación, aplique controles de acceso y evite transportar contenido sensible a entornos no autorizados. La presente guía no determina por sí misma la licitud de un tratamiento ni los requisitos contractuales de proveedores. Antes de incorporar documentos privados, conviene usar el recurso previsto «Ejemplo de matriz de evaluación para documentos sensibles» y validar las condiciones aplicables con las funciones jurídica, de seguridad y de protección de datos.

Los casos sintéticos pueden ampliar cobertura cuando faltan ejemplos, pero no sustituyen sin más a la realidad operativa. Deben etiquetarse como sintéticos, revisarse y mantenerse separados en los informes. Si solo funcionan los casos creados para la demostración, la evaluación no aporta evidencia suficiente sobre el comportamiento en producción.

Elegir métricas que correspondan a la tarea y al riesgo

No existe una métrica única para sistemas generativos. La coincidencia literal puede ser razonable si la salida es una etiqueta cerrada o un valor exacto, pero suele ser insuficiente para resúmenes, respuestas abiertas o planes de acción. En esos casos, una rúbrica humana puede valorar aspectos separados: corrección factual, cobertura, claridad, cumplimiento de instrucciones, uso adecuado de fuentes y reconocimiento de incertidumbre. La evaluación automatizada puede complementar ese trabajo con validadores de esquema, reglas de negocio, comprobación de campos obligatorios y pruebas de seguridad; no debería ocultar qué propiedades no puede verificar.

Para recuperación aumentada con fuentes, mida por separado la recuperación y la generación. Entre otras señales, puede revisar si se recuperó evidencia pertinente, si las afirmaciones importantes están respaldadas por la evidencia disponible, si las citas o referencias corresponden al contenido y si el sistema se abstiene cuando la evidencia no alcanza. Una respuesta fluida no demuestra fidelidad. El recurso previsto «Cómo evaluar fidelidad, cobertura y citas en sistemas RAG» puede profundizar en esos criterios.

En salidas estructuradas, mida la validez del esquema, la presencia de campos, la exactitud semántica de cada campo y la recuperación ante un error. Un JSON formalmente válido puede seguir clasificando mal; una clasificación correcta puede resultar inutilizable si falta un campo requerido. Para diseñar esas pruebas, queda previsto el recurso «Cómo medir validez de esquema y recuperación ante errores».

Añada métricas operativas: latencia por percentiles y por segmento, coste por tarea completada, frecuencia de reintentos, tasa de fallback, intervención humana y éxito de extremo a extremo. Informe distribuciones además de promedios cuando sea posible, porque una media puede ocultar colas de latencia o segmentos con resultados sistemáticamente peores. Los umbrales no se deducen de una cifra universal: dependen del proceso, el volumen, el daño y la capacidad de supervisión.

Diseñar la rúbrica y controlar el desacuerdo humano

Una rúbrica convierte juicios generales en decisiones observables. En vez de pedir «¿es buena la respuesta?», defina dimensiones, escalas y ejemplos. Para el asistente de feedback, una dimensión de fidelidad podría distinguir entre: toda afirmación relevante respaldada por el texto; pequeñas inferencias aceptables señaladas; afirmaciones no respaldadas; y atribuciones claramente falsas. Otra dimensión puede evaluar si la categoría y la prioridad siguen las definiciones operativas del equipo.

Algunos controles pueden automatizarse de forma determinista: parseo de un esquema, límites de longitud, campos prohibidos, coincidencia con una lista de permisos o presencia de referencias requeridas. Otros exigen interpretación. Un evaluador basado en otro modelo puede agilizar el cribado, pero debe calibrarse frente a anotaciones humanas en una muestra representativa y sus errores deben analizarse. No conviene tratarlo como árbitro independiente ni usarlo para sustituir la revisión humana de consecuencias altas.

Para medir acuerdo, dos evaluadores pueden compararse mediante porcentaje de coincidencia en criterios simples o mediante una medida de acuerdo que tenga en cuenta la coincidencia esperable por azar, como kappa, siempre que la escala y la distribución lo permitan. No hay un nivel universal de desacuerdo que invalide una evaluación. Como regla operativa, revise la rúbrica si el desacuerdo afecta a casos que decidirían el despliegue, si se concentra en una dimensión crítica o si los evaluadores interpretan el criterio de forma incompatible. Documente la revisión y, si cambia las reglas, reevalúe los casos afectados.

Comparar de forma justa y decidir con umbrales explícitos

Defina los umbrales antes de ejecutar la comparación final. Establezca bloqueadores absolutos, mínimos por segmento y objetivos operativos. Un bloqueador puede ser una salida que revele información no autorizada, una acción ejecutada sin confirmación requerida, una violación de un permiso o una afirmación crítica sin respaldo en un contexto donde el sistema se presenta como basado en fuentes. Un mínimo por segmento evita que un resultado agregado aceptable esconda un comportamiento inaceptable para un idioma, un tipo de documento o un grupo de usuarios.

Una decisión puede tener tres salidas: desplegar con controles, iterar o descartar. Desplegar con controles es apropiado solo si los bloqueadores están a cero dentro de la cobertura evaluada, se cumplen los mínimos acordados y existe una supervisión compatible con el riesgo residual. Iterar requiere identificar qué cambiará y cómo se medirá de nuevo. Descartar puede ser la conclusión responsable si no existe una configuración que alcance el umbral dentro de los límites de coste, latencia o seguridad.

En agentes que ejecutan acciones externas, la evaluación debe probar explícitamente permisos, confirmaciones, alcance y reversibilidad. No basta con que la tarea termine con éxito. El recurso previsto «Pruebas de permisos, confirmaciones y reversibilidad antes de dar acciones al agente» debe cubrir este tipo de validación. La guía no fija requisitos regulatorios concretos del AI Act europeo: las fuentes verificadas aportadas no son texto normativo primario suficiente para determinar artículos, fechas u obligaciones aplicables. Esa revisión debe hacerse con fuentes jurídicas vigentes y asesoramiento especializado.

Monitorizar después del despliegue y conservar el registro de decisión

El despliegue no convierte la evaluación en un trámite cerrado. Cambian las entradas de usuarios, los documentos recuperados, los modelos de proveedores, las herramientas y los patrones de abuso. Instrumente trazas con la minimización de datos apropiada para enlazar una salida con su configuración, recuperación, herramientas, tiempo de respuesta, coste, validaciones, fallback e intervención humana. El recurso previsto «Cómo instrumentar trazas, latencia y coste por tarea» puede servir como continuación operativa.

Defina señales de alerta: aumento de errores de esquema, caída de éxito por segmento, crecimiento de abstenciones o reintentos, retrasos en percentiles altos, incremento de coste por tarea, reclamaciones revisadas y eventos de permisos. Muestree resultados de producción para evaluación humana, con procedimientos que respeten los controles de datos aplicables. Programe reevaluaciones tras cambios relevantes y también de forma periódica, incluso si no se declara ningún cambio, porque una dependencia externa puede variar.

La plantilla final debe reunir una ficha de evaluación, la matriz de resultados y un registro de decisión. La ficha incluye objetivo, segmentos, riesgos, configuración versionada, procedencia de datos y métricas. La matriz muestra resultados agregados y por segmento, junto con casos críticos. El registro explica qué evidencia se revisó, qué umbrales se aplicaron, qué limitaciones permanecen, quién aprobó la decisión y cuándo debe repetirse la prueba. Como navegación de cierre, añada «Siguiente paso» hacia una plantilla descargable o un artículo hermano de observabilidad. No debe publicarse este cierre como enlace activo si el destino no existe o no está planificado dentro del clúster.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.