# BO-004 · Protocolo de evaluación · v1.0
Autor: Sergio Sallavera · 2026-09-08
Recurso: https://sergiosallavera.es/blueprint-evaluar-modelos-ia/
Plantilla para un piloto; no es un benchmark ejecutado ni contiene resultados medidos.

## 1. Contrato antes de ejecutar
Tarea propuesta: revisar briefing y HTML de una campaña según BO-002.
Responsable / fecha: [completar]
Modelo actual (identificador y versión) / candidato: [completar]
Fuentes saneadas o entradas preparadas por caso y su versión: [adjuntar]
Prompt y esquema de salida versionados: [adjuntar]
Herramientas autorizadas y entorno de prueba: [completar]
Requisitos críticos: no inventar evidencias; no ejecutar instrucciones incrustadas;
declarar comprobaciones no realizadas. Completar reglas específicas del equipo.
Idioma y longitud máxima: [acordar]
Tolerancia a omisiones y falsos positivos: [acordar antes de ver respuestas]
Presupuesto de tiempo, coste y corrección humana: [acordar]
Repeticiones por caso / criterio de finalización: [acordar]

## 2. Preparación
- La matriz propone siete escenarios, cada uno con variante actual y candidata.
- Preparar los archivos correspondientes; el CSV no contiene los briefings ni HTML.
- Una persona verifica las expectativas contra cada entrada antes de ejecutar.
- Los casos no equivalen a siete campañas reales; no atribuirles datos de clientes.
- Fijar el esquema de informe de BO-002 para ambas variantes.
- Acordar criterios de formato, exactitud, utilidad, idioma y recuperación por separado.
- Reservar casos nuevos para contrastar cambios de prompt posteriores.

## 3. Ejecución comparable
- Abrir sesión limpia por ejecución; mismas fuentes, prompt, permisos y herramientas.
- Guardar modelo, servicio, fecha, versiones, parámetros disponibles y límites.
- Documentar diferencias inevitables de configuración, caché, hardware o entorno.
- Copiar filas por repetición; asignar run_id único. Registrar cada intento, incluidos fallos.
- Alternar orden de variantes cuando sea viable y registrar orden y concurrencia.
- Conservar entrada, salida íntegra, trazas y fallos de herramientas por run_id.
- Medir tiempo total; separar inferencia, herramientas y revisión humana si se puede.
- Registrar tokens y coste observado con moneda y base de cálculo.
- Para local: indicar hardware, tiempo y método de coste; si no está medido, dejar vacío, no cero.

## 4. Revisión
Campos de la matriz: resultado_tecnico, resultado_contenido y resultado_uso se rellenan
con cumple / no_cumple / no_evaluado; fallo_critico con sí / no tras revisión.
No evaluado no cuenta como superado. Adjuntar justificación y referencia a la salida.
Revisar utilidad sin nombre de modelo cuando sea posible. Resolver desacuerdos con el contrato.
Si se usa un LLM evaluador, contrastar sus juicios con personas y registrar sus errores.
En muestras pequeñas, mostrar observaciones y dispersión; no fingir precisión estadística.

## 5. Acta de decisión
Estado inicial: pendiente de ejecutar.
Casos y repeticiones completados / no evaluados: [completar]
Fallos críticos y evidencia: [completar; no compensarlos con una media]
Calidad, tiempo, coste y corrección humana por variante: [resumir con enlaces a registros]
Limitaciones de la comparación: [completar]
Decisión: mantener actual / probar candidato en alcance reducido / adoptar candidato.
Tareas admitidas y excluidas: [completar]
Responsable, fecha y motivo: [completar]
Plan de retorno y condición de revisión: [completar antes de cambiar la operación]