Cómo montar un pipeline de evaluación de LLMs con datos propios (y dejar de fiarte de los benchmarks)

Q: ¿Sirven de algo los benchmarks oficiales de LLMs?

Sirven para comparar modelos en tareas genéricas y controladas, no para predecir el rendimiento en tu negocio. En tres evaluaciones de Domina IA (restaurante, bots de atención y backend de leads) los leaderboards no anticiparon quién cumplía reglas, latencia o coste real. Úsalos como filtro grueso; decide con un pipeline propio y métricas de dominio.

Q: ¿Qué necesito para montar un pipeline de evaluación de LLMs con datos propios?

Una tarea con reglas de negocio claras, un repo plantilla idéntico por modelo (README, contrato de API y run.sh), tests ocultos deterministas que comprueban el estado vía API, sandbox sin internet al generar, y métricas de tokens, tiempo, coste y estabilidad en varias tandas. En bots, añade adversarios y daño económico en euros.

Q: ¿Por qué un validador determinista delante del LLM no siempre es más seguro?

Porque el router también puede fallar con lenguaje ambiguo. En evaluaciones de Domina IA, un híbrido determinista+LLM causó el mayor daño económico (323k€) al malinterpretar frases y autorizar ventas. El enfoque robusto fue LLM más validador de cada tool-call, pero solo tras pruebas exhaustivas con clientes adversarios, no por fe en la arquitectura.

Q: ¿Qué métricas importan además de la precisión del modelo?

Tokens, tiempo de ejecución, coste total y, por conversación, €/conv cruzado con tasa de resolución. En filtrado, tasa de detección y falsos positivos (hasta 28 de 390 leads válidos perdidos). En producción, latencia (p95; 1016 ms puede ser inaceptable) y estabilidad entre tandas. Dos modelos “perfectos” pueden diferir hasta 3,8× en coste.

Por qué los benchmarks no te salvan el negocio

Si eliges un modelo mirando un leaderboard, estás comprando un coche por su puntuación en el banco de pruebas del fabricante. Suena técnico. No te dice si arranca un lunes con lluvia y el maletero lleno.

En Domina IA lo hemos comprobado tres veces. Encargamos un sistema de restaurante a dos de los modelos más caros del momento. Montamos arquitecturas de bots de atención al cliente en La Pecera. Enfrentamos a seis LLMs a un backend de leads de verdad. En los tres casos, los benchmarks oficiales no predecían el rendimiento real. Un modelo que brilla en el paper se desmorona con una queja de cliente en lenguaje natural, con una reserva que choca contra el aforo o con un lead ambiguo que parece spam.

Seamos justos: los benchmarks no son inútiles. Sirven para comparar modelos en tareas genéricas, controladas y a menudo saturadas, y dan una foto rápida del progreso relativo entre versiones. Sin ellos, el campo iría a ciegas. El problema es otro: no te dan una predicción fiable de cómo se comportará tu sistema con tus reglas de negocio. Para eso hace falta un pipeline de evaluación propio.

Esta guía es el método que usamos. No es un tutorial de una herramienta concreta. Es el procedimiento operativo para montar tu propia pista de pruebas: tarea realista, condiciones iguales, tests que el modelo no puede fingir, y métricas que duelen (tokens, latencia, euros). Cuando termines, podrás abrir un repo, meter tres modelos y saber cuál se come el trabajo de verdad.

Qué es un pipeline de evaluación con datos propios (y para qué sirve)

Un pipeline de evaluación con datos propios es un entorno cerrado donde varios LLMs resuelven la misma tarea de negocio bajo las mismas reglas, se miden con los mismos tests y se comparan con las mismas métricas de coste y estabilidad.

No es un dataset de Hugging Face con preguntas tipo examen. Es un simulacro de producción:

Un brief en lenguaje natural, como te lo pasaría un cliente.
Un contrato de API congelado.
Tests que miran el estado real del sistema, no la prosa del modelo.
Fases que meten bugs, features nuevas y carga.
En bots, clientes adversarios y daño económico medido en euros.

La promesa es simple: al cerrar la guía sabes qué construir, en qué orden y qué medir para no volverte a casar con un modelo porque “sale primero en el ranking”.

Requisitos antes de tocar nada

No necesitas un cluster de GPUs. Necesitas disciplina de producto y algo de backend.

Una tarea de negocio real (o un recorte fiel): reservas, filtrado de leads, atención al cliente, tickets. Con reglas inequívocas.
Acceso a los modelos que quieres comparar (API o local).
Un entorno de ejecución aislable: Docker o un sandbox sin internet durante la evaluación.
Capacidad de escribir tests automatizados contra una API (Python + pytest o el stack que uses).
Un presupuesto de tokens y un techo de coste por tanda de pruebas.
Alguien que conozca las reglas del negocio lo bastante como para detectar trampas y ambigüedades.

Si no tienes “datos propios”, no inventes un benchmark genérico y lo llames tuyo. Define reglas de negocio concretas aunque el dominio sea sintético. El valor está en la inequívocidad de las reglas, no en que el dataset sea de tu empresa del año pasado.

Paso 1: Define una tarea realista con reglas de negocio que no se puedan retorcer

Empieza por el brief. Escríbelo como lo escribiría un cliente: en lenguaje natural, con límites claros y sin contarle al modelo lo que vendrá después.

Ejemplo de dominio que funciona: un sistema de reservas de restaurante con límite de aforo y lista de espera. Las reglas tienen que ser inequívocas:

Capacidad máxima por franja.
Qué pasa si se supera.
Cómo se gestiona la lista de espera.
Qué endpoints existen y qué devuelven.

No reveles las fases futuras. Si el modelo sabe que luego vendrán quejas de clientes, precios dinámicos y 200 peticiones simultáneas, se sobreajusta al guion. Tú quieres medir adaptabilidad, no memorización del enunciado.

Checklist del brief:

Problema en 5–10 frases, sin jerga de ML.
Reglas de negocio numeradas y sin “depende”.
Criterios de aceptación observables (no “buena UX”).
Nada de spoilers de fases 2, 3 y 4.

Si la regla se puede interpretar de tres formas, el modelo elegirá la más cómoda. Tú no estás midiendo creatividad; estás midiendo cumplimiento.

Paso 2: Monta un “folio en blanco” idéntico para cada modelo

Aquí es donde la mayoría de comparativas se van a la mierda: cada modelo arranca con un prompt distinto, un repo distinto o un humano ayudando “un poquito”. Resultado: no mides el modelo, mides el favoritismo del experimentador.

Crea un repositorio plantilla y clónalo una vez por modelo. Contenido mínimo:

README.md, descripción de la tarea y del entorno.
api.md, contrato de endpoints y formatos congelados. Nombres, verbos, payloads, códigos de error. Sin “puedes improvisar”.
run.sh, punto de entrada único. Cómo se levanta el sistema y cómo se invoca.

Todos los modelos reciben el mismo material. Misma vara. Si uno necesita más contexto, que lo pida dentro de las reglas; no le regales un scaffold distinto.

Por qué importa: en nuestras pruebas de backend y de encargo de producto, la igualdad de condiciones fue lo que permitió comparar filosofía de solución (monolito vs capas, memoria vs persistencia) sin que el resultado se contaminara por el “setup mágico” del humano.

Paso 3: Tests ocultos, deterministas y sin internet

El modelo no puede “aprobar” escribiendo un texto bonito. Tiene que dejar el sistema en un estado correcto.

Implementa tests que se ejecutan después de cortar el acceso a internet. El código se genera offline; solo después se evalúa. Sandbox aislado: sin consultar Stack Overflow, sin mirar soluciones ajenas, sin trucos.

Los tests no miran el README del modelo. Llaman a la API y comprueban el estado real:

¿Se registró la reserva?
¿Se respetó el aforo?
¿La lista de espera está ordenada como mandan las reglas?
¿Un endpoint prohíbe lo que debería prohibir?

Características de estos tests:

Deterministas: misma entrada → mismo veredicto.
Ocultos durante la generación: el modelo no ve los casos de prueba.
Orientados a estado, no a estilo de respuesta.

Si el modelo “explica” perfectamente cómo haría la reserva pero la API no guarda nada, suspende. Fin del debate.

Paso 4: Mide eficiencia, no solo “correcto / incorrecto”

Dos modelos pueden sacar puntuación perfecta en corrección y separarse por un abismo de coste. En nuestras evaluaciones, modelos con la misma nota de acierto llegaron a diferir hasta 3,8× en coste total.

Métricas mínimas por ejecución:

Métrica	Qué te dice
Tokens consumidos	Cuánto “piensa” y escribe
Tiempo de ejecución	Si es usable en un flujo real
Coste total (€)	Lo que te cuesta esa victoria en el papel
Corrección (tests)	Si cumple las reglas

Sin estas tres columnas de eficiencia, el ranking es un concurso de belleza. Con ellas, empiezas a ver candidatos baratos que fallan poco y caros que brillan… a precio de joyería.

Para conversaciones (bots), baja la métrica a €/conversación y cruza con tasa de resolución. Un modelo barato por token puede salir caro por conversación si resuelve menos casos. En La Pecera, GPT-5.5 llegó a costar 9,4× más por conversación que MiniMax + validador, con peor resolución. Barato por token no es barato de negocio.

Paso 5: Obliga a documentar decisiones en un DECISIONS.md

Cada modelo (o el agente que genera el código) debe dejar un DECISIONS.md con:

Lenguaje y framework elegidos.
Arquitectura (monolito, capas, servicios).
Almacenamiento (memoria vs persistente).
Trade-offs conscientes.

Esto no es postureo de “documentación ágil”. Es una ventana a la madurez arquitectónica. Cuando comparas salidas, no solo ves si pasó los tests: ves cómo piensa el modelo cuando tiene que construir algo que mañana alguien mantendrá.

En la práctica, este archivo te ahorra discusiones de café. No es “me gusta más el estilo de A”. Es “A eligió persistencia y B se inventó un estado en RAM que se evapora al reiniciar”.

Paso 6: Fases incrementales sobre el mismo código

Una v1 que aprueba tests es el principio, no el final. El pipeline de verdad mete presión en el tiempo:

v1, implementa el brief original.
Corrección de bugs, introduce quejas de clientes en lenguaje natural. “Me cobraste dos veces”, “reservé para 4 y me pusiste en lista de espera”. El modelo debe parchear sin reescribir el universo.
Nuevas features con datos de producción, precios, sugerencias, reglas extra. Mide si el diseño aguanta el crecimiento.
Carga, por ejemplo, 200 peticiones simultáneas. Observa regresiones, timeouts y estados corruptos.

En cada fase mides:

¿Siguen pasando los tests de fases anteriores? (regresiones)
¿Cuántos tokens y cuánto tiempo costó adaptarse?
¿Se rompió algo que antes funcionaba?

Un modelo que “gana” la v1 y se deshace en la fase de quejas es un mal candidato para producción, por muy bonito que salga el demo del viernes.

Caso especial A: bots de atención y el dinero que se va por el desagüe

Si evalúas un bot de atención al cliente, la satisfacción del usuario es una métrica incompleta. Puedes tener conversaciones “agradables” que regalan reembolsos o cierran ventas no autorizadas.

Lo que hacemos (y te conviene copiar):

Simula clientes adversarios con perfiles concretos: hacker, regateador, manipulador.
Mide el daño económico en euros por acciones no autorizadas (ventas, reembolsos, descuentos).
Complementa con: % de conversaciones sin incidentes de seguridad o errores económicos, afirmaciones falsas (precios inventados) y tasa de resolución de casos difíciles.

Dato duro: un bot sin alucinaciones de precios todavía puede generar más de 173k€ en daños por malinterpretar ambigüedad. La alucinación no es el único enemigo; la ambigüedad bien resuelta en la dirección equivocada también te hunde.

Arquitectura que en nuestras pruebas se comportó como la más robusta: un LLM para entender el lenguaje natural + un validador determinista de reglas que revisa cada tool-call antes de ejecutarla. Ese enfoque llegó a 0€ de daño con alta resolución de casos complejos.

Cuidado con el atajo mental “híbrido = más seguro”. No des por sentado que pegar un router determinista delante del LLM te salva. En las mismas evaluaciones, un híbrido determinista+LLM generó el mayor daño (323k€) porque el router malinterpretó frases ambiguas y disparó al LLM a ejecutar ventas. El componente “seguro” era el que abría la puerta.

Si montas validadores, pruébalos con los mismos adversarios que al LLM. Sin eso, el híbrido es fe en capa de ifs.

Caso especial B: filtrado de leads y la trampa de los falsos positivos

En tareas de filtrado (spam, calificación de leads), no basta con “detecta basura”.

Método:

Inyecta un conjunto conocido de datos basura y válidos.
Mide tasa de detección.
Mide, con la misma obsesión, los falsos positivos: leads buenos que el modelo tira a la basura.

Un modelo agresivo puede lucir precisión de cazador de spam y, a la vez, perder hasta 28 de 390 leads válidos. En un equipo de ventas eso no es un matiz de F1-score: es pipeline comercial con agujeros.

Define además un objetivo de latencia realista (ejemplo: p95 < 300 ms) y pon el sistema bajo carga. Hay modelos que mantienen buena precisión y fallan el requisito de tiempo. En producción, 1016 ms de latencia es inaceptable para un flujo de ventas que espera respuesta casi al momento. Alta precisión lenta es un lujo que el comercial no va a esperar.

Paso 7: Estabilidad en varias tandas (o te estás mintiendo)

Ejecuta las mismas pruebas en múltiples tandas. Un resultado único es una anécdota.

Algunos modelos pasan en una corrida y fallan en la siguiente: fragilidad. En nuestras comparativas de backend de leads, Claude Opus 4-8 fue el único completamente estable entre tandas. Eso no lo convierte en “el mejor del mundo” para cualquier tarea; lo convierte en el más fiable en ese dominio y con esas métricas. No generalices el ganador fuera de contexto.

Regla práctica: si el ranking cambia cada vez que repites el experimento, no tienes un ranking. Tienes ruido con logotipos.

Cómo se ve el pipeline montado de punta a punta

Orden operativo recomendado:

Escribes el brief y las reglas de negocio.
Congelas api.md y preparas run.sh.
Escribes la batería de tests ocultos (estado + seguridad + latencia).
Clonas el folio en blanco N veces (un workspace por modelo).
Generas el código sin internet.
Levantas cada solución y lanzas tests + métricas de tokens/tiempo/coste.
Exiges DECISIONS.md.
Metes fase de bugs en lenguaje natural.
Metes features y datos de producción.
Lanzas carga y regresiones.
Si es bot, metes adversarios y calculas € de daño.
Repites tandas y miras estabilidad.

Salida mínima que deberías poder enseñar a un CTO sin sonrojo:

Tabla modelo × (tests OK, tokens, tiempo, €, regresiones, estabilidad).
En bots: € de daño y % de conversaciones limpias.
En filtrado: detección + falsos positivos + p95 de latencia.
Enlace al DECISIONS.md de cada candidato.

Errores comunes (dónde la caga todo el mundo)

Confiar en el leaderboard y “validar” después en producción. Eso no es evaluación; es ruleta con clientes reales. Primero el pipeline, luego el deploy.

Dar pistas distintas a cada modelo. Un tip “inofensivo” al favorito contamina el experimento.

Medir solo accuracy. Sin tokens, tiempo y euros, eliges el que mejor escribe el postmortem.

Tests que leen la respuesta en natural language y no el estado. El modelo es un artista del “sí, claro”. La API no miente igual de bien.

Olvidar regresiones en fases posteriores. Una v1 perfecta y una v2 que rompe reservas es un fracaso, aunque la v2 “tenga más features”.

Declarar seguro un híbrido sin adversarios. El router mal configurado puede ser peor que el LLM solo: en nuestras pruebas, el híbrido se llevó el récord de daño económico.

Una sola tanda. Si no repites, no sabes si es habilidad o suerte del sampling.

Objetivos de latencia de PowerPoint. Si el equipo de ventas necesita sub-300 ms al p95, 1016 ms no es “un poco lento”: es inviable.

Tips que marcan la diferencia

Congela el contrato de API antes de dejar que el modelo “proponga mejoras”. Si reescribe el contrato, ya no comparas implementaciones: comparas reescrituras del enunciado.
Separa generación y evaluación en el tiempo y en la red. Offline para generar; online solo si el propio sistema bajo prueba lo necesita de forma controlada.
Traduce métricas a dinero de negocio. 3,8× de coste entre dos “perfectos” es una decisión de presupuesto, no un detalle de MLOps.
En bots, prioriza daño y autorización sobre “tono amable”. El tono se ajusta; los reembolsos no autorizados no.
Documenta el dominio de la victoria. “Ganó en leads con p95 y falsos positivos” no es “es el mejor LLM del trimestre”.
Guarda los prompts del sistema y los briefs versionados. Si cambias el brief a mitad de comparativa, tiras a la basura la igualdad de condiciones.
Si quieres contexto de por qué los leaderboards se quedan cortos en producción, el desglose de qué miden y qué ocultan está en nuestro artículo sobre benchmarks de IA. Aquí el foco es otro: montar el tuyo.

Cierre sin romance

Montar este pipeline no es glamuroso. Es un folio en blanco, un contrato de API, tests que no se ven, un sandbox sin WiFi y una hoja de cálculo con tokens y euros. Es también la diferencia entre “el modelo mola en Twitter” y “este modelo no regala 173k€ ni tira 28 leads buenos”.

Los tres experimentos que hemos hecho en Domina IA, restaurante, bots y backend de leads, apuntan a la misma tesis editorial: el rendimiento real se mide con reglas de negocio, estado del sistema y dinero en juego, no con un porcentaje en un PDF. Construye la pista de pruebas. Luego elige el modelo. En ese orden.

Preguntas frecuentes

¿Sirven de algo los benchmarks oficiales de LLMs?