Ejecuciones y comparación
Ejecuta evaluaciones reproducibles, compáralas entre sí y entiende los totales.
Una ejecución (o run) es un experimento congelado: el eval corrido contra un estado exacto de los datos, el prompt y las reglas de calificación. Es la unidad que se compara.
Qué congela una ejecución
Al lanzarla, Verica fija cinco cosas y ya no las suelta:
| Se congela | Qué significa |
|---|---|
| El golden set | Una copia congelada del borrador del dataset. La ejecución queda pinneada a esa copia. |
| La versión del prompt | Incluyendo el prompt de sistema, la cadena de mensajes y las herramientas. |
| El modelo y el sampling | Proveedor, modelo, temperatura, máximo de tokens, esfuerzo de razonamiento, etc. |
| La credencial | Cuál se usó. |
| La configuración de cada criterio | Una copia literal. Editar el criterio después nunca cambia los resultados históricos. |
El borrador del dataset nunca se congela: lo que se congela es la copia. Y si el borrador no cambió desde el último snapshot, Verica reutiliza ese snapshot en lugar de duplicar los datos — dos ejecuciones seguidas sin ediciones comparten una sola copia.
Estados
| Estado | Qué significa |
|---|---|
| en cola | Encolada, todavía sin empezar. |
| ejecutando | En curso. |
| completada | Terminó y ningún caso falló. |
| parcial | Terminó, pero algunos casos fallaron. |
| fallida | Terminó y ningún caso llegó a buen puerto. |
| cancelada | Se canceló; los casos pendientes no se procesaron. |
Una ejecución en estado terminal nunca se vuelve a finalizar: sus totales y su veredicto de gate quedan congelados.
Reanudación y reintentos
Las ejecuciones son reanudables por diseño. Cada caso avanza por etapas y solo se re-encola lo que no llegó al final:
- Un caso ya generado pero sin calificar retoma en la calificación — la llamada de generación nunca se paga dos veces.
- Un caso ya completo se saltea.
- Cancelar mientras está en cola no revive nada después.
Cada caso admite hasta 3 intentos. Solo se reintenta lo que vale la pena reintentar: errores 429, errores del servidor del proveedor y timeouts. El backoff respeta el Retry-After que mande el proveedor; si no lo manda, crece exponencialmente hasta un tope de 60 segundos. Un error de configuración no consume reintentos: falla de una y lo dice.
Para las columnas Recuperadas (RAG) la distinción es la misma: un error HTTP o un timeout se reintenta; un endpoint inválido o una respuesta con la forma equivocada falla de inmediato, porque reintentarlo daría lo mismo.
Ritmo y límites
Verica limita el ritmo por credencial: unas 30 llamadas de generación cada 10 segundos. Al pasarse, el caso se pospone a la ventana siguiente sin consumir un intento. Desde fuera, una ejecución grande simplemente se acompasa sola: ni error, ni reintento quemado.
Los jueces no entran en ese límite; ante un 429 reintentan con backoff.
Los totales
| Métrica | Cómo se calcula |
|---|---|
| Pass rate | Calificaciones aprobadas sobre calificaciones resueltas. |
| Puntaje | Promedio de los puntajes numéricos. — si ningún criterio devuelve puntaje. |
| Costo | Generación + calificación, desglosados. |
| Tokens | Entrada, salida, cacheados, razonamiento y jueces. |
| Errores | Cantidad de casos que fallaron. |
Dos reglas del pass rate que conviene tener claras:
- Las calificaciones N/A salen del denominador por completo. La página lo dice: "
{n}N/A fuera del cálculo". - Las calificaciones con error se quedan en el denominador. Una ejecución degradada no debe verse más sana de lo que está.
Si todas las calificaciones fueron N/A, el pass rate es — y no hay gate.
Cómo leer el costo
La cifra grande no es el total: es el costo neto por caso, y está calculada de forma pesimista, sin descuento por caché. La razón es que en un eval los casos se disparan uno detrás de otro y aprovechan la caché del proveedor, mientras que en producción probablemente no. Ese número responde a "¿cuánto me cuesta un caso en producción?", donde además no hay jueces.
Debajo aparece el desglose real: neto {generación} + jueces {calificación} = total {total}, más el ahorro por caché si lo hubo. El total de la ejecución sí es el gasto real.
Todo esto es una estimación a partir de la tabla de precios de Verica y puede diferir de la facturación del proveedor. Si algún modelo no tiene precio configurado, su costo queda fuera del total y la página lo aclara.
La caché de prompts
Verica activa el cacheo de prompts cuando la ejecución tiene al menos 5 casos pendientes. Hay una trampa que vale la pena conocer: si tu prompt de sistema contiene variables {{ }}, cambia en cada caso y toda la ejecución pierde la caché. Si quieres el descuento, deja el sistema estable y mueve lo variable al mensaje de usuario.
Comparar ejecuciones
La comparación es siempre entre dos ejecuciones del mismo eval: A es la base, B el retador. No hay comparación entre evals ni entre proyectos — el eval ya es el contenedor del experimento.
Desde la página de una ejecución, Comparar con la anterior abre la vista con esa ejecución como B. Por defecto se comparan la última contra la anterior. Hace falta que el eval tenga al menos dos ejecuciones.
La página tiene cuatro partes:
Los dos resúmenes
Lado a lado: pass rate, costo por caso y cantidad de casos, con el modelo, la versión del prompt y los parámetros de sampling.
Lo que difiere entre las dos se tinta: rosa del lado A, verde del lado B. Del lado B, además, una flecha indica la dirección del cambio y el color indica si es una mejora — para el pass rate, más alto es mejor; para el costo, más bajo.
El diff del prompt
Aparece solo cuando las dos ejecuciones usan prompts distintos. Tiene vista de Texto y vista de Diff, separando prompt de sistema y prompt de usuario. Si el prompt es el mismo, lo dice.
Pass rate por criterio
Una tabla Criterio · A · B · Δ, con el delta en puntos porcentuales, verde si mejoró y rojo si empeoró.
Los criterios se emparejan por su identidad interna, no por su nombre, así que un criterio que renombraste o editaste sigue alineándose con su versión anterior. Cuando algo no encaja, se marca: config distinta, solo en A, solo en B.
Resultados por caso
La tabla completa, con el output de A y el de B lado a lado, y para cada criterio los dos veredictos.
Los casos que cambiaron de veredicto se resaltan en ámbar, y arriba aparece el conteo: "{n} casos cambiaron de veredicto en al menos un criterio". Si ninguno cambió, también lo dice.
Regenerar un caso, reevaluar una celda
Estas dos acciones viven en la mesa de trabajo del dataset, no en la página de una ejecución de eval. Son parte del bucle de iteración.
Regenerar la salida de este caso (el botón de play en la celda de output) vuelve a muestrear solo ese caso; los demás conservan su salida. Importante: guarda y usa el prompt actual, no el que estaba congelado en la última generación completa. Es una tirada nueva con lo que tienes ahora.
Reevaluar esta celda (el botón de play en una celda de criterio) vuelve a calificar solo esa celda, reutilizando la configuración ya fijada de ese criterio. Es el "volvé a tirar este veredicto", útil cuando un juez dio algo errático. Cuenta como exactamente una calificación contra el límite de tu plan.
Ninguna de las dos funciona sobre una ejecución cuyas salidas fueron purgadas por retención: primero hay que regenerar los outputs.
Evaluar, en cambio, recalifica todas las salidas existentes sin volver a muestrear. Corre en dos pasadas — primero los criterios locales, que llenan la planilla al instante, y después los jueces — así que la interfaz se completa progresivamente en lugar de quedarse en blanco.
Fijar y retención
Las salidas de las ejecuciones se purgan pasado el periodo de retención de tu plan. Fijar una ejecución la exime: "Las ejecuciones fijadas no se purgan pasado el periodo de retención de datos."
Purgar borra las salidas, no los resultados: los veredictos, puntajes y razonamientos se conservan siempre. Ver Planes y límites.
Siguientes pasos
- El Eval — cómo se versiona el prompt entre ejecuciones.
- Criterios y graders — qué produce cada veredicto.
- Integración con CI — ejecuciones disparadas desde el pipeline y el gate.