El Eval
El agregado central de Verica — qué pruebo, cómo lo califico y el historial de ejecuciones, todo en un solo lugar.
El eval es el agregado central de Verica. Reúne cuatro cosas en un solo lugar:
- Qué pruebo — una referencia a un golden set.
- Cómo lo califico — los criterios.
- El prompt actual — el punto de partida de la próxima ejecución.
- El historial de ejecuciones — cada una con su estado, pass rate y costo.
Por eso la navegación tiene solo tres secciones: Evals, Datasets y Configuración. Los criterios y los prompts no son secciones propias: viven dentro del eval.
Crear un eval
Hay dos caminos, y conviene elegir según de dónde vienes.
| Camino | Cuándo usarlo |
|---|---|
| Wizard de cuatro pasos | Todavía no tienes una mesa de trabajo, o quieres armar el eval directamente alrededor de un golden set existente. |
| Promover desde un dataset | Ya venías iterando datos, prompt y criterios en la mesa de trabajo y quieres formalizar ese estado exacto. |
El wizard
En Evals → Nuevo eval: cuatro pasos: nombre → datos → criterios → prompt. Al terminar queda listo para ejecutar.
Nombre
¿Qué quieres evaluar? El Nombre es obligatorio; la Descripción es opcional y sirve para dejar escrito qué comportamiento valida este eval.
Datos (golden set)
Dos opciones: Usar uno existente o Crear uno nuevo.
Si eliges uno existente, verás sus columnas como insignias, más una insignia output · se completa al ejecutar que recuerda que esa columna la llena la ejecución.
Si creas uno nuevo, puedes Importar CSV o JSONL o escribir los casos en la misma planilla que se usa en toda la aplicación. El golden set creado aquí queda en tu biblioteca, reusable por otros evals.
Criterios de corrección
Cómo se decide si cada respuesta pasa. El wizard siembra un criterio por defecto para que nunca llegues a un formulario vacío: que el output contenga el valor de la columna del golden set que elijas como esperada.
Puedes Agregar criterio las veces que haga falta, o usar el menú de presets RAG Evaluations: Faithfulness, Answer relevance, Context relevance y Context recall.
Prompt inicial
El Prompt de Usuario (obligatorio), las herramientas que el modelo puede llamar y un Prompt de Sistema opcional. Las columnas de entrada se insertan con {{ columna }}.
Si en el paso 2 importas la exportación JSONL de una corrida de OpenAI Evals, el wizard también precarga los pasos siguientes — criterios juez, prompt de usuario y prompt de sistema — y te avisa qué importó. Nunca sobreescribe algo que ya escribiste.
Promover desde un dataset
Promover, en la cabecera de la mesa de trabajo, pide solo un nombre. Lo que viaja:
- El golden set se comparte, no se copia: el eval referencia el mismo dataset.
- Una copia de cada criterio de la mesa de trabajo.
- Una copia del prompt del playground como versión 1, incluyendo el modelo y los parámetros de sampling con los que venías trabajando.
Promover copia, no mueve: el dataset conserva su mesa de trabajo y puedes promover otra vez, con ajustes en el medio, para obtener dos evals comparables.
La página del eval
Debajo del nombre está el enlace al golden set, con la cantidad de casos y la versión del snapshot. Hay dos pestañas.
Ejecuciones
Es donde se pasa el 90% del tiempo. La tabla lista Ejecución · Origen · Estado · Modelo · Pass rate · Costo · Lanzada.
Cada ejecución congela el prompt y el modelo que usó — el historial es tu iteración.
- Origen distingue las ejecuciones lanzadas desde la interfaz de las que llegaron desde CI.
- El botón Comparar ejecuciones aparece a partir de la segunda ejecución.
- Cuando CI reutiliza el veredicto de una ejecución anterior en lugar de volver a ejecutar, ese evento se intercala en la misma lista con la insignia reutilizada. Sin eso, una reutilización sería invisible en el historial. Los detalles están en Integración con CI.
Configuración
- La condición de gate para CI, con el pass rate de la última ejecución y el promedio de las últimas cinco al lado del umbral, para que el número tenga contexto.
- Prompt actual — v
{n}— se precarga al ejecutar; si lo editas ahí, se versiona solo. Muestra el prompt de sistema, la cadena de mensajes y las herramientas. - Criterios — editables en el lugar. Edita un criterio para corregirlo; se versiona solo y las ejecuciones anteriores conservan el suyo.
El prompt: modelo híbrido
Verica versiona los prompts, pero nunca te muestra el versionado como tal. El modelo es este:
- El eval guarda su prompt actual como punto de partida.
- Al ejecutar, ese prompt viene precargado y editable, junto con el último modelo y credencial.
- Si lo editas, se crea la versión nueva en silencio. Un aviso lo dice en lenguaje llano: "Editaste el prompt: esta ejecución crea y usa una versión nueva."
- Cada ejecución congela el prompt y el modelo que usó.
La consecuencia es la parte interesante: el historial de ejecuciones es el historial de iteración del prompt, y comparar el prompt v1 contra el v2 es simplemente poner dos ejecuciones lado a lado. Por eso la comparación vive dentro del eval y no como una función global.
Dos detalles que sorprenden si no se saben:
- Se versiona por contenido, no por el gesto de editar. Si abres el prompt, lo tocas y lo dejas igual que estaba, no se crea una versión nueva.
- El modelo y los parámetros de sampling no versionan el prompt. Viajan en la configuración de la ejecución. Probar el mismo prompt contra dos modelos no genera dos versiones.
Cada versión guarda la cadena completa de mensajes, el prompt de sistema, las herramientas, y el modelo y los parámetros con los que se escribió.
Los criterios se versionan con la misma lógica: al editar uno, se crea una versión nueva solo si alguna ejecución ya fijó la actual. Las ejecuciones pasadas conservan la suya.
Prompt gestionado desde el repositorio
Un eval puede marcar su prompt como gestionado desde git. En ese caso la interfaz lo muestra en solo lectura con un aviso: "Este prompt se gestiona desde tu repositorio ({ruta}). Edítalo allí; la UI lo muestra solo lectura." Se activa desde el panel de CI de la página del eval. Ver Integración con CI.
Variables del prompt
Las variables {{ }} se corresponden una a una con los nombres de columna del golden set. El autocompletado ofrece exactamente esas columnas, sin las columnas reservadas de anotación.
Los nombres de columna deben empezar por letra o _ y seguir con letras, números o _. Tres nombres están reservados y no pueden usarse como columna: output, item y sample.
Dentro de los criterios, además de las columnas puedes referenciar:
{{ output.text }}— la salida del modelo.{{ output.json.<ruta> }}— un campo cuando la salida es JSON.{{ output.tool_calls }}— las llamadas a herramientas.{{ trajectory }}— el árbol de spans, en jueces sobre trazas.
Una variable desconocida bloquea el lanzamiento, tanto en el prompt como en cualquier criterio. Es una validación previa, no un error a mitad de ejecución.
Modelo y credencial
Verica es BYOK: cada ejecución corre contra tu propia clave. Los proveedores soportados son OpenAI, Anthropic, Google y OpenAI-compatible (un endpoint compatible con la API de OpenAI: OpenRouter, vLLM, un modelo local en un túnel).
- Las credenciales son por proyecto: una credencial de otro proyecto se rechaza.
- El selector de modelos se alimenta de la tabla de precios de Verica. Un modelo sin precio se puede usar igual desde la interfaz — solo no se calcula el costo, y la página lo avisa.
- Los parámetros de sampling disponibles dependen del modelo: temperatura, máximo de tokens, top P, semilla, esfuerzo de razonamiento, verbosidad y algunas opciones específicas de cada proveedor. Verica filtra los que ese modelo no acepta.
Antes de lanzar, Verica valida en orden: golden set no vacío, al menos un criterio activo, presupuesto de almacenamiento y de gradings del plan, plantillas, coherencia entre tool_check y las herramientas del prompt, validez de la credencial y su proyecto, precio y proveedor del modelo, que el endpoint siga sirviendo ese modelo, y que cada juez tenga una credencial elegida explícitamente — no hay respaldo silencioso a "la credencial más nueva del proveedor".
Herramientas
Un eval puede definir herramientas simuladas que el modelo puede llamar: nombre, descripción y el JSON Schema de sus parámetros.
Nunca se ejecuta ninguna. Lo que se evalúa es la decisión del modelo: qué herramienta llamó y con qué argumentos. De eso se encarga el criterio tool_check.
Las herramientas se guardan con la versión del prompt, así que una ejecución reproduce exactamente las que vio. Además, la cadena de mensajes puede escenificar contexto de agente: un turno de asistente con llamadas a herramientas ya escritas y un turno tool con el resultado simulado — llamada → resultado → siguiente turno.
Si un criterio tool_check nombra una herramienta que el prompt no define, el eval no se crea y la ejecución no se lanza.
Siguientes pasos
- Ejecuciones y comparación — qué congela cada ejecución y cómo se comparan.
- Criterios y graders — la configuración de cada tipo.
- Integración con CI — disparar el eval desde tu pipeline.