Ejecuciones gestionadas

Una ejecución gestionada ejecuta su suite en los workers de Oloproof en lugar de en su máquina, y usted la sigue desde la página Jobs o desde su terminal. Solo necesita oloproof login; ni conexión a una base de datos ni un runner propio.

Lo que un worker ejecutará

Un worker llama a su sistema por HTTP. Declárelo con http: en oloproof.yaml (Referencia de configuración):

system:
  name: support-bot
  version: v3
  http:
    url: https://support-bot.example.com/answer
    output_path: answer

Un worker rechaza:

• Un sistema callable: o rag:, antes de que el job entre en la cola. Es su código, y los workers de Oloproof no ejecutan código de clientes; ejecútelo en su propia máquina (oloproof run) y suba la ejecución, o en un runner que usted opere.
• Un archivo de respuestas recorded:. Se queda en su máquina; ejecútelo en local con oloproof run.
• Una dirección que no está en la internet pública: localhost, un nombre de una sola etiqueta, una dirección privada, link-local o de metadatos de la nube. Cada llamada se comprueba al hacerse, así que un caso así termina en error en lugar de alcanzarla; un worker solo puede alcanzar lo que cualquiera en internet puede alcanzar.
• Casos de ataque generados, salvo que oloproof.yaml declare adversarial: {sandboxed: true} (Generar ataques). --allow-adversarial solo cubre una ejecución local.

Lanzar una

oloproof login
oloproof run --cloud --max-runtime 900

run --cloud envía los casos de su suite al espacio de trabajo (una ejecución gestionada no puede ejecutar casos que no tiene), luego pone el job en cola e indica dónde seguirlo. Una suite que el espacio de trabajo ya tiene completa no se vuelve a enviar.

El worker comprueba cada caso contra su digest antes de conservar la suite, y rechaza la que no coincide. Por eso run --cloud calcula los digests de los casos sin clave, como hace el worker, incluso en un proyecto que usa digests con clave para retener contenido (egress:, Resultados y ejecución): los casos se envían completos de todos modos, así que ponerles clave no ocultaría nada. Por tanto, la suite de la ejecución gestionada es una suite distinta de la que registra una ejecución local del mismo proyecto. Un proyecto cuyo espacio de trabajo ya tiene evidencia con clave (de un push) se rechaza: ejecútelo con oloproof run y haga push de la ejecución.

--max-runtime es el plazo del job en segundos, hasta un día, o el límite de su plan si es menor. Un budget: en oloproof.yaml se aplica en un worker igual que en local.

Quién puede lanzar una: un Owner, Admin o Member del espacio de trabajo. Un Reviewer no puede.

Seguirla

La página Jobs del proyecto muestra los casos de cada job a medida que llegan: cuántos se han ejecutado y juzgado, un recuento de aprobados y fallados por comprobación, y los últimos casos. El recuento es un total provisional, no un resultado. Las decisiones se toman una vez guardada la ejecución completa, y su página las muestra entonces.

En la terminal:

oloproof job JOB_ID --follow

imprime los mismos recuentos cada pocos segundos, luego la puerta de la ejecución, y termina con el código de salida de la puerta, así que un pipeline puede esperar una ejecución gestionada como una local (Ejecución en CI). Sin --follow, job informa una vez; un job que sigue en curso termina con 2, porque aún no es una decisión. --cancel detiene de inmediato un job en cola, y uno en curso antes de su siguiente llamada, conservando los casos terminados.

Claves para un juez

Un juez o un sistema que llama a un proveedor de modelos necesita su clave en el worker. Guárdela una vez:

export OPENAI_API_KEY=...
oloproof credentials set OPENAI_API_KEY
oloproof credentials list

La clave se lee del entorno o de la entrada estándar, nunca de la línea de comandos. El worker la cifra y solo la puede leer un worker que ejecute los jobs de este espacio de trabajo; nadie puede volver a leerla, y credentials list muestra solo nombres. El api_key_env: OPENAI_API_KEY de un evaluador la encuentra entonces. Un job gestionado no lee ninguna otra variable de entorno. Solo un Owner o un Admin puede guardar una clave.

Lo que esto no puede decirle

• Si su sistema se comporta igual desde la red de Oloproof que desde la suya. Un worker llama a su endpoint desde la internet pública; los límites de tasa, las regiones y las listas de permitidos que lo tratan de otra forma cambian lo que mide.
• Nada sobre código que un worker no ejecutó. Una ejecución gestionada mide el endpoint que usted indicó, no el código que hay detrás.

Todos los demás límites de Lo que una evaluación no puede decirle se aplican también aquí.