Cómo evaluamos un modelo nuevo antes de ponerlo frente a un cliente: el juez, 120 turnos y el enrutador

¿Por qué no basta el benchmark del proveedor?

Porque mide otra cosa. Terminal-Bench dice qué tan bien un modelo opera una terminal; no dice si va a inventar un plazo de entrega cuando un cliente de Toluca pregunte por su pedido a las 11 de la noche. Nuestro asistente Nemi atiende ventas, soporte, logística y el portal de administración; lo que necesitamos saber de un modelo nuevo es si responde, si no inventa y si respeta las reglas, en nuestras conversaciones. Eso no lo mide nadie más que nosotros.

Septiembre de 2026 trajo dos candidatos: Claude Fable 5.1 (1 de septiembre) y GPT-6 Astra (4 de septiembre). Este es el método con el que decidimos, con sus números reales y con el error que casi lo invalida.

El juez: una calificación por turno, en producción

Cada respuesta del asistente pasa por un segundo modelo que la califica con tres criterios binarios: ¿respondió lo que se preguntó?, ¿inventó algo?, ¿rompió una regla? La nota se deriva sola: cero problemas es 5, uno es 2, dos o más es 1. La nota y el motivo se guardan en columnas propias de la tabla de mensajes. Al 14 de agosto de 2026, el juez calificaba el 100% de los turnos desde que se corrigió; había 911 turnos de asistente acumulados.

Esa frase "desde que se corrigió" tiene historia. Medimos 2 calificaciones en 30 días sobre 277 turnos y parecía que el juez llevaba apagado desde el 2 de agosto. No lo estaba: calificaba, 217 buenas y 58 malas, pero escribía el veredicto en el mismo campo que un cron de aprendizaje reescribía cada seis horas. 275 de 277 pisados. El proveedor respondía bien, el compilado estaba en su sitio y no había un solo aviso de fallo en 14 días. Dos procesos escribiendo el mismo campo no producen un error, producen silencio. Se resolvió con columnas propias, y el histórico no se rellenó: inferir una nota sería fabricar la evidencia que la calibración existe para contrastar.

La calibración: 120 turnos reales etiquetados por una persona

Un juez sin calibrar es una opinión. Armamos una muestra estratificada de 120 turnos reales de producción, excluyendo el sitio de pruebas:

Canal	Turnos	Por qué ese peso
Ventas (sitio público)	60	Es donde más conversaciones hay y donde inventar cuesta más
Soporte (portal con sesión)	25	Datos de tickets reales con permisos por persona
Administración interna	15	Cifras de ventas y cartera; incluye respuestas previas a las herramientas, a propósito
Arquitectura de software	10	Preguntas técnicas largas
Landings	10	Contexto mínimo, tentación máxima de rellenar

La persona etiqueta los mismos tres criterios. Después se corre el juez sobre esos mismos 120 identificadores y se calcula kappa por criterio y por grupo. El umbral es 0.60: por arriba, el juez queda calibrado y habilita el enrutador y las métricas; por abajo, el reporte de discrepancias dice dónde ajustar el prompt del juez, y se vuelve a medir contra la misma muestra sin re-etiquetar. Al cierre de esta nota las etiquetas humanas siguen pendientes, así que el juez opera sin certificado. Lo decimos porque es la parte del método que más se salta la gente.

Las tres métricas y el orden de despliegue

1. Tasa de respuestas correctas según el juez (y, cuando esté calibrado, según kappa).
2. Costo por turno resuelto: no costo por token. Un modelo barato que necesita dos turnos para lo que otro resuelve en uno es más caro.
3. Latencia p95: en un chat de soporte, una respuesta brillante a los nueve segundos pierde contra una buena a los dos.

Y el orden: una semana en sombra (el candidato responde en paralelo sin que el usuario lo vea), luego 10% de tráfico real, luego 50%. Nunca se cambian modelo e instrucciones al mismo tiempo.

El enrutador: por qué el modelo caro no atiende el mostrador

El asistente usa tres niveles. El nivel 1 resuelve la mayoría de los turnos con un modelo de volumen; escala al nivel 2 cuando hay una señal (la pregunta sale del guion, hay que cruzar ERP con CRM, el usuario pide un análisis); el nivel 3 es el modelo de frontera, con tope de gasto. Fable 5.1 y GPT-6 Astra compiten por el nivel 3, no por el 1. Con Sonnet 5 a $3/$15 desde el 1 de septiembre y Fable 5.1 a $10/$50, la diferencia por conversación es de tres a cuatro veces; en el nivel 3 con lectura de caché a $0.25, Fable 5.1 puede resultar más barato que su antecesor en turnos largos con herramientas. Eso es lo que vamos a medir en las dos semanas que siguen, con nivel de esfuerzo Medium.

La lección que no era de modelos

Cuando montamos las herramientas de administración, descubrimos que el chat interno anterior no consultaba el ERP: leía documentos vectoriales y reconstruía cifras partiendo texto. En producción había 1,160 facturas indexadas contra 3,155 reales y 2,168 productos contra 8,724. Ningún modelo, por bueno que sea, arregla una fuente incompleta. Las herramientas nuevas van contra las tablas vivas, excluyen las 247 facturas canceladas por $3.27 millones que un SQL generado se habría llevado, y separan facturado de cobrado. La IA redacta; la IA no es la fuente. Evaluar un modelo antes de arreglar la fuente es evaluar quién miente con más elegancia.

Qué publicaremos

Los tres números de Fable 5.1 contra Opus 5 en el nivel 3 sobre los 120 turnos, y los de GPT-6 Astra en cuanto OpenAI publique precio y acceso por API. Si el kappa del juez no llega a 0.60, también lo publicamos. Un método de evaluación que solo reporta cuando gana no es un método.