Producto · Evals y sandbox
Donde se mide y se filtra la calidad del agente
Evals es la superficie donde la calidad de la salida del agente, las regresiones y la deriva se puntúan — y donde se puede filtrar una release antes de que salga. El framework, los scorecards y la consola existen y están cableados, al igual que la parte que les da peso sobre tráfico real: la fuente de sesiones que sustenta el sampling y la fuente de historial ordenado que sustenta la repetición de sesiones en el sandbox. Ambos adaptadores están siempre cableados dentro del proceso, sin configuración del operador. Lo que la repetición NO hace es inventar entradas: si una sesión no tiene una secuencia reconstruible en su historial, el replay se declara degradado y no se fabrican entradas.
Qué hace
Un framework para la calidad del agente
Monitorización de calidad de salida, test de regresión y un sandbox aislado — el sitio donde se puntúa el comportamiento del agente antes y después de un cambio.
Scorecards y monitorización de calidad de salida
Puntúa la salida del agente contra los checks que defines y observa la calidad a lo largo del tiempo. El framework, los scorecards y la consola están cableados; lo que miden se vuelve real en cuanto se conecta una fuente de sesiones.
Test de regresión y A/B de prompts
Reejecuta una suite contra un cambio para detectar regresiones antes de que salgan, y compara variantes de prompt A frente a B sobre las mismas entradas — para que un cambio se juzgue por evidencia, no por intuición.
Detección de deriva
Detecta cuándo la salida del agente se desvía de su baseline esperada con el tiempo, para que la erosión de calidad se muestre en lugar de descubrirse en producción.
Sandbox aislado
Un entorno de prueba aislado para comparación pre y post-deploy, con repetición de sesiones. Ambos están cableados: el entorno y la fuente de historial ordenado a partir de la cual la repetición reconstruye una sesión.
Qué es real
El framework, la consola, el sampling en vivo y la repetición ordenada están todos cableados
Esta superficie es la más llena de costuras del producto, así que somos tajantes al respecto — la honestidad es la característica, no una disculpa:
- Live: el framework de evals, los scorecards, la consola, las ejecuciones de regresión, el A/B de prompts y la detección de deriva están construidos y cableados, y el sandbox es un entorno aislado para comparación pre/post-deploy.
- Live, con un límite declarado: el sampling de evals lee, mediante la fuente de sesiones cableada, sesiones reales cuya antigüedad no supera una cota configurable, y la repetición del sandbox reconstruye desde su historial la secuencia ordenada de acciones de una sesión. El límite aparece cuando no hay nada que leer: una sesión sin una secuencia reconstruible en su historial produce una repetición degradada de cero pasos, y una secuencia que supera la cota admitida para la repetición se rechaza por completo en lugar de repetirse parcialmente. Ninguno de los dos casos se rellena con entradas inventadas.
- Postura: el motor adaptativo de red-teaming es post-v1. Para v1 documentamos la postura con controles compensatorios en lugar de sobrevender un motor que aún no está aquí.
Evals y sandbox — preguntas
¿Puedo ejecutar evals contra mi tráfico real de agente hoy?
Sí. La fuente de sesiones que sustenta el sampling está siempre cableada dentro del proceso, sin configuración del operador, por lo que las ejecuciones de monitorización muestrean sesiones reales en vez de datos sembrados — con una antigüedad máxima configurable, lo que mantiene las muestras recientes y acotadas. Las capturas de esta página siguen mostrando datos de ejemplo sembrados, porque son capturas, no un tenant live.
¿Funciona la repetición de sesiones en el sandbox?
Sí, y es determinista: la repetición reconstruye desde el historial la secuencia ordenada de acciones de herramientas y MCP de la sesión y la reejecuta contra los mocks que proporcionas, de modo que la misma sesión y los mismos mocks siempre producen las mismas salidas. Se declaran dos límites en lugar de ocultarlos: una sesión sin una secuencia reconstruible en su historial se declara degradada con cero pasos, y una secuencia que supera la cota admitida para la repetición se rechaza por completo en lugar de repetirse parcialmente.
¿Hay un motor automatizado de red-teaming?
No en v1. El motor adaptativo de red-teaming es post-v1. Para v1 documentamos la postura de seguridad con controles compensatorios en lugar de insinuar un motor adaptativo que aún no está construido.
Entonces, ¿qué es usable ahora mismo?
El framework y la consola de evals — scorecards, ejecuciones de regresión, A/B de prompts y detección de deriva —, más el sandbox aislado para comparación pre/post-deploy, la fuente de sesiones cableada que muestrea sesiones reales y la repetición ordenada reconstruida desde el historial de sesiones. Aquí se miden la calidad del agente y sus regresiones, y se someten a gate. Lo único que sigue siendo post-v1 es el motor adaptativo de red-teaming, y esta página lo declara donde corresponde.
Mira dónde se filtra la calidad del agente
Despliega Olivares en tu propia infraestructura y explora el framework de evals y el sandbox — scorecards, test de regresión, comparación pre y post-deploy, sampling de sesiones en vivo y repetición ordenada reconstruida desde el historial de sesiones.