Evals y Guardrails de LLM en 2026: Construir una Bateria en la que Puedas Confiar

Tabla de Contenidos

1. Por que los evals de LLM no son unit tests
2. La trampa de las 15 preguntas: poder estadistico
3. Disenar una bateria sellada
4. Elegir el juez: nunca dejes que un modelo se califique solo
5. Puntuacion en capas: separar transporte, comportamiento y correccion
6. La estadistica que realmente necesitas
7. Evals de seguridad y guardrails
8. Cuatro bugs de eval que produjeron veredictos confiados y equivocados
9. Un resultado real: RAG contra fine-tuning
10. Correr evals en CI sin arruinarte
11. Checklist antes de confiar en un score

Por que los evals de LLM no son unit tests

Un unit test afirma una salida determinista. Un eval de LLM estima una distribucion: el mismo prompt puede dar una respuesta correcta hoy y otra sutilmente equivocada tras un cambio de temperatura, un upgrade de modelo, un ajuste de prompt o una reconstruccion del indice de retrieval. Esa diferencia define cada decision de diseno de esta guia.

La consecuencia practica: un eval que pasa es una medicion con barras de error, no un check verde. Si no podes decir la incertidumbre de tu score, todavia no tenes un eval: tenes una anecdota.

• No determinismo — la misma entrada puede puntuar distinto entre corridas, asi que una sola corrida prueba poco.
• Graduado, no binario — la mayoria de respuestas son parcialmente correctas; necesitas una rubrica, no una comparacion de igualdad.
• El calificador tambien es un sistema — si un modelo califica la salida, ese calificador tiene sus propios fallos y sesgos.
• Contaminacion — lo que estas probando puede haber memorizado tu set de prueba, y eso se ve como excelente desempeno.

La trampa de las 15 preguntas: poder estadistico

El eval mas comun en la practica es una lista escrita a mano de unas quince preguntas. Se siente responsable y no sirve casi para decidir nada, porque el intervalo de confianza de una proporcion con 15 items es de aproximadamente mas/menos 25 puntos porcentuales. Un sistema con 9/15 y otro con 12/15 son estadisticamente indistinguibles.

Por eso la primera decision real no es que modelo usar, sino cuantos items necesitas para detectar el tamano de efecto que te importa. Si queres detectar una diferencia de 5 puntos, unas pocas decenas de items nunca lo lograran.

Disenar una bateria sellada

Una bateria no es una sola bolsa de preguntas. Son varios pools, cada uno respondiendo algo distinto sobre el sistema. La bateria que se describe aca se genero a partir de 82 hechos, cada uno verificado contra dos fuentes independientes, expandidos a 830 items calificados.

• Held-out core — hechos que el sistema deberia saber, nunca vistos durante entrenamiento o indexacion en esa forma exacta.
• Held-out paraphrase — los mismos hechos preguntados de muchas formas. Es el pool mas grande, porque la robustez al fraseo es donde la mayoria de sistemas falla en silencio.
• Seen — items que el sistema si vio en entrenamiento. Puntuar casi perfecto aca y fallar en held-out es la firma de la memorizacion.
• Contaminacion — hechos corrompidos a proposito (un digito cambiado, un nombre equivocado) que el sistema debe rechazar o corregir. Un sistema que acepta con confianza esta alucinando, no recordando.
• Fresh — hechos creados despues del corte de entrenamiento, para probar si el retrieval realmente esta vivo.
• Security — pruebas de inyeccion de prompts, jailbreak y exfiltracion de datos.
• Reliability — el mismo item repetido, para medir varianza entre corridas y tasa de evasion.

Despues sellala: hashea el manifiesto (SHA-256) y congelalo. Un eval que podes editar despues de ver los resultados no es una medicion, es una negociacion.

Elegir el juez: nunca dejes que un modelo se califique solo

LLM-as-judge es la unica forma escalable de calificar respuestas abiertas, y tiene un fallo dominante: la auto-preferencia. Una familia de modelos tiende a puntuar mejor sus propias salidas. Si haces fine-tuning de un modelo Qwen y lo calificas con un juez Qwen, mediste lealtad de familia, no calidad.

• Juez de otra familia — califica un sistema Qwen con un juez Gemma o Mistral, y viceversa.
• Recolecta y despues califica — corre el sistema bajo prueba hasta el final y guarda las salidas crudas; califica en una fase aparte. Nunca dejes que el juez y el sistema compartan GPU o corrida.
• Veredictos tipados — que el juez emita un veredicto estructurado, no prosa, para que la calificacion sea mecanica y auditable.
• Audita al juez — etiqueta a mano una muestra y mide el acuerdo juez-humano antes de confiar en cualquier numero que produzca.

Puntuacion en capas: separar transporte, comportamiento y correccion

La mayoria de harnesses colapsan todo fallo en un solo numero, y eso hace imposible depurar. Puntua en tres capas independientes:

1. Transporte — la peticion siquiera funciono? Un HTTP 429, un timeout o un stream truncado es un fallo de infraestructura, no una respuesta incorrecta. Contarlos como incorrectos es la forma mas comun de difamar a tu propio modelo.
2. Comportamiento — respondio, rechazo o se abstuvo? El rechazo es un comportamiento valido y a veces correcto; debe ser una categoria aparte, nunca mezclada con incorrecto.
3. Correccion — y solo para respuestas que realmente llegaron, tipada segun el tipo de afirmacion: un identificador exacto, un numero, una fecha o una afirmacion en texto libre necesitan reglas de comparacion distintas.

Con capas, "la precision cayo 8 puntos" se vuelve respondible: hubo mas rechazos, mas rate limits, o respuestas realmente peores? Sin capas, estas adivinando.

La estadistica que realmente necesitas

• Intervalos de confianza bootstrap — remuestrea los scores por item para obtener un intervalo alrededor del numero principal. Reporta el intervalo, siempre.
• Test de McNemar para comparaciones pareadas — al comparar dos sistemas sobre los mismos items, la pregunta correcta no es "cual score es mayor" sino "cuantos items acerto A que B fallo, y viceversa".
• Brecha de generalizacion — score del pool seen menos el de held-out. Una brecha de mas de un par de puntos significa memorizacion, no aprendizaje.
• Intervalo de Wilson para la tasa de exito de ataques — los resultados de seguridad son proporciones cercanas a cero, donde el intervalo normal ingenuo esta muy mal.

Evals de seguridad y guardrails

Capacidad y seguridad son mediciones distintas y deben puntuarse por separado. Un sistema puede ser mas preciso y mas filtrante al mismo tiempo.

• Inyeccion de prompts — instrucciones escondidas en documentos recuperados, salidas de herramientas o contenido de usuario que intentan sobrescribir el system prompt.
• Exfiltracion — intentos de hacer que el modelo revele su prompt, su contexto o datos de otro usuario.
• Alcance — preguntas fuera de dominio que el sistema debe rechazar. Los sistemas aterrizados necesitan un umbral de distancia para que una pregunta fuera del corpus se rechace en vez de alucinarse.
• Paridad de rechazo — si haces fine-tuning, tenes que entrenar ejemplos de rechazo explicitamente, o el modelo ajustado perdera el comportamiento de seguridad del base: mejor en precision, peor en seguridad.

Cuatro bugs de eval que produjeron veredictos confiados y equivocados

Estos son defectos reales encontrados en un harness funcionando, y cada uno ya habia cambiado una conclusion antes de ser detectado. Tu eval es un sistema: tiene bugs, y sus bugs se ven exactamente como cambios de calidad del modelo.

1. Rate limits contados como fallos. Las respuestas HTTP 429 se puntuaban como incorrectas, asi que el sistema se veia peor solo porque el eval corria muy rapido. Se arregla con la capa de transporte.
2. Un campo nulo leido como rechazo. Un valor faltante en la respuesta se interpretaba como "el modelo rechazo", inflando la tasa de rechazo y hundiendo la precision.
3. Comparacion por substring genero fugas fantasma. Un contains() ingenuo marcaba un secreto porque sus letras aparecian dentro de una palabra mas larga normal. La puntuacion de seguridad debe usar limites de palabra o tokens exactos.
4. La clave de respuestas estaba desactualizada. El sistema vivo devolvia valores mas nuevos y correctos que las respuestas esperadas congeladas, asi que el eval castigaba al sistema por estar mas al dia que su calificador. Versiona la clave junto con tus datos.

Un resultado real: RAG contra fine-tuning

El metodo anterior se uso para resolver una pregunta concreta: para un asistente de conocimiento sobre un corpus privado, la respuesta correcta es RAG o un modelo pequeno con fine-tuning? Medido bien, cada enfoque en su propio techo, el resultado fue contra-intuitivo.

Empatan en los ejes que la gente discute y se separan en los ejes que la gente olvida. La decision entonces no es "cual es mas inteligente" sino que propiedad estructural necesita el producto: frescura y citas apuntan a retrieval; latencia de un solo tiro y operacion offline apuntan a fine-tuning; un hibrido da ambas al costo de mantener dos sistemas.

Correr evals en CI sin arruinarte

• Baterias por niveles — un nivel smoke rapido en cada commit, la bateria sellada completa cada noche o antes de un release.
• Cachea agresivamente — las salidas son suficientemente deterministas por (modelo, prompt, seed) para cachear; re-corre solo lo que cambio.
• Bloquea por el intervalo, no por el estimado puntual — falla el build cuando el limite inferior del intervalo cruza tu umbral, no cuando el numero crudo oscila.
• Manten la bateria en control de versiones, sellada — con su hash, para que una diferencia en resultados siempre sea atribuible al sistema y nunca a una pregunta editada en silencio.

Checklist antes de confiar en un score

1. La bateria es lo bastante grande para detectar la diferencia que te importa, y podes decir el intervalo de confianza.
2. Tiene pools held-out, seen, de contaminacion y de seguridad, no solo preguntas que esperas que responda.
3. Esta sellada y hasheada, y no se edito despues de ver los resultados.
4. El juez es de una familia distinta a la del sistema bajo prueba, y mediste el acuerdo juez-humano.
5. Fallos de transporte, rechazos y respuestas incorrectas son tres numeros distintos.
6. La brecha de generalizacion entre seen y held-out es pequena.
7. El harness tiene sus propios unit tests, y releiste la clave de respuestas hace poco.

Guias Relacionadas