EN·ES·PT
Consultor de evaluación de LLM

La suite de evaluación que decide si su modelo llega a producción.

Un servicio de evaluación de LLM no es un informe: es un sistema en funcionamiento. Yo construyo el golden dataset, la rúbrica de puntuación y el gate de CI que califica cada cambio de modelo o de prompt frente a él, y luego bloquea el merge cuando la calidad registra una regresión. Puede ver cómo una versión funcional de ese juez califica una respuesta en vivo, ahora mismo, antes de hablar conmigo.

Demo del juez en vivo: eval.html → Califique la respuesta de su IA → ISTQB CT-AI + Test Automation Engineer
Ver · el ángulo de la evaluación en ~45s
4
dimensiones de puntuación por respuesta
2
señales: LLM como juez + verificaciones deterministas
1
gate de CI que puede bloquear un merge
100%
cobertura de citas en el build de RAG*

*El dashboard de investigación con RAG cita el 100% de sus afirmaciones por construcción — no hay ninguna ruta de código que genere una frase sin cita. Verificado en case-studies.html. Cualquier otra cifra de esta página es una consecuencia del diseño del método, no un promedio de clientes.

La rúbrica · lo que puntúa la demo en vivo

Cuatro dimensiones, cada una con aquello que detecta y su puntuación.

Cada respuesta que ve el juez se califica en los mismos cuatro ejes. Dos son deterministas (aprueban o no); dos usan un LLM como juez con una rúbrica explícita, de modo que la puntuación es explicable, no una corazonada. Esta es la rúbrica exacta que hay detrás de la demo en vivo.

Rúbrica de evaluación — dimensión × fallo detectado × método de puntuación
Dimensión Qué detecta Cómo se puntúa
Grounding Respuestas que se desvían de la fuente de verdad — afirmaciones que el contexto proporcionado no respalda en realidad. LLM como juez contra la fuente suministrada, más una verificación determinista de citas: cada afirmación debe rastrearse hasta un pasaje.
Alucinación Invención con confianza — hechos fabricados, cifras falsas o citas a fuentes que nunca se dieron. Determinista: un diff afirmación-vs-contexto expone declaraciones sin respaldo; el juez califica la gravedad.
Seguridad e inyección Cumplimiento de prompt-injection, instrucciones del sistema filtradas y salida insegura o fuera de política. Determinista: verificaciones de patrones y de rechazo sobre entradas adversarias; un fallo aquí puede bloquear la salida por completo.
Calidad de respuesta Respuestas técnicamente fundamentadas pero inútiles — fuera de intención, incompletas, o que ignoran la pregunta real. LLM como juez sobre relevancia, completitud y franqueza, puntuado según una rúbrica escrita.
▸ pegue la respuesta de su IA y vea cómo se califica la demo ejecuta esta rúbrica sobre entrada real, en vivo
La metodología · golden set → juez → gate

Cómo se detecta una regresión antes de que llegue a producción.

Un cambio de modelo o de prompt entra en CI. Se ejecuta contra un golden set curado de casos representativos. Cada salida se puntúa con el juez LLM y con las verificaciones deterministas. Si alguna dimensión cae por debajo de su piso, el gate bloquea el merge — el cambio nunca llega a los usuarios. Si todo pasa, llega a producción.

Flujo del gate de evaluación de LLM Un cambio y su golden set alimentan una etapa de evaluación que combina un juez LLM y verificaciones deterministas, produciendo puntuaciones que llegan a un gate de CI; los cambios que pasan llegan a producción, los que fallan quedan bloqueados. Modelo / prompt cambio → CI Golden set casos curados EVALUAR LLM como juez + verificaciones deterministas GATE puntuación ≥ piso? SHIP ✓ todos los pisos cumplidos BLOQUEADO ✕ regresión
El gate es el entregable. Sin él, las evaluaciones son un dashboard que nadie lee; con él, un mal cambio físicamente no puede hacer merge.
La prueba · este gate ya bloqueó una versión

Una historia rojo → verde con pruebas que puedo enseñarle.

En mi propia plataforma de QA, nexural-qa-os, el gate hizo exactamente lo que se supone que hace un gate: detectó 15 CVE altas/críticas y bloqueó su propia versión. Ese mismo día se parchearon los problemas y el sistema se puso en verde — 3.759 pruebas superadas, 13 de 13 gates en verde. La evidencia son dos ejecuciones capturadas, antes y después.

Antes — versión bloqueada
  • 15 CVE altas/críticas detectadas
  • El gate se negó a aprobar el build
  • No se envió nada
Después — mismo día, en verde
  • 3.759 pruebas superadas
  • 13 / 13 gates en verde
  • Parcheado, re-ejecutado, enviado
Por qué le importa a usted

Un gate solo se gana la confianza el día en que detiene su propia versión. Este lo hizo — y guardé las capturas en lugar de solo afirmarlo.

▸ la ejecución bloqueada ▸ la ejecución en verde dos ejecuciones capturadas · antes y después · el mismo día
Prueba adyacente · la misma disciplina, en otros contextos

El rigor de evaluación es una faceta de cómo pruebo.

Suites deterministas

Una suite pública de regresión SDET: 37/37 specs, 0 flakes, 15,3s. Verde significa verde.

ver el repositorio ↗
Flakiness bajo control (fintech)

HighStrike (un puesto previo a tiempo completo, autodeclarado): tasa de flakiness reducida del 10% a menos del 1% en más de 500 pruebas sobre flujos de trading en vivo.

Escala (Fortune 50)

The Home Depot: un framework de Selenium para más de 2.300 tiendas; regresión reducida de 4h a 75min.

▸ los casos de estudio completos y sí — este sitio ejecuta su propia QA: más de 100 verificaciones, limpio en axe
Relacionado · más sobre pruebas de IA
Contratar a un ingeniero de QA de IA →Evaluación de RAG →Pruebas de agentes de IA →Reducir la inestabilidad de las pruebas →

¿Le preocupa una función de IA específica?

Califíquela en vivo en 30 segundos, o reserve una llamada y definiremos el golden set, la rúbrica y el gate que la protege.

Reservar una llamada → ▶ probar el juez en vivo el servicio completo →
preguntas frecuentes

Preguntas, respondidas.

¿Qué es, concretamente, una evaluación de LLM?
Una forma repetible de puntuar la salida de su modelo — precisión, fidelidad, seguridad — frente a casos de referencia validados, de modo que un cambio de prompt o de modelo que empeore las cosas se detecte antes de que llegue a producción.
¿Cuántos casos de prueba se necesitan para empezar?
Normalmente de 50 a 200 casos representativos — suficiente señal para poner un gate — que se amplían a medida que aparecen modos de fallo reales en producción.
¿Pueden poner un gate en nuestro CI según los resultados de la evaluación?
Sí. La evaluación se ejecuta en CI y bloquea el merge si un umbral registra una regresión (cobertura de citas, tasa de alucinación, resistencia a inyección). En rojo antes de producción, no después.
¿Qué frameworks y modelos utiliza?
Agnóstico del proveedor — Promptfoo, DeepEval y Pytest contra una interfaz estándar de chat-completions, usando sus modelos y sus cuentas siempre que sea posible.
¿Qué tan grande debe ser el golden dataset para que sea útil?
Unas pocas docenas de casos bien elegidos superan a cientos de casos aleatorios. Empiece con los modos de fallo que de verdad le hacen daño — prompts reales de usuarios, casos límite, incidentes pasados — y haga crecer el conjunto a medida que aparecen nuevos fallos.
¿La puntuación con LLM como juez es lo bastante fiable para poner un gate?
No por sí sola. Los prompts del juez se validan con casos etiquetados por humanos, y el gate se apoya en verificaciones deterministas — coincidencia exacta, presencia de citas, esquema, detección de rechazo — siempre que la respuesta lo permita, reservando el juez para los casos genuinamente subjetivos.
¿Cómo encaja el gate de evaluación en el CI que ya ejecuto?
Se ejecuta como una verificación más en su pipeline existente — un paso en GitHub Actions o lo que use — que aprueba o falla el build. No hay que adoptar una plataforma nueva; la evaluación vive junto a sus pruebas unitarias y bloquea el merge con la misma X roja.
¿Qué le pasa al gate cuando cambio de modelo o edito un prompt?
Para eso existe exactamente. Cualquier cambio de modelo o edición de prompt vuelve a ejecutar la suite completa, y un cambio que registre una regresión en grounding, seguridad o calidad de respuesta pone el build en rojo antes de que llegue a los usuarios.
¿Lo construye en mi repositorio o en una herramienta aparte?
En su repositorio. La suite, el golden set y la configuración de CI se versionan junto a su código, así que usted lo posee, lo ejecuta y lo amplía sin depender de mí ni de un dashboard alojado.
¿Cuánto tarda en estar activo el primer gate de calidad?
El primer gate en funcionamiento — un golden set pequeño conectado a CI y bloqueando sobre un umbral real — llega pronto, y la suite gana profundidad a partir de ahí. Verá un build ponerse en rojo ante un mal cambio antes de que termine el trabajo, no una diapositiva sobre ello.