Esecuzioni gestite

Un'esecuzione gestita esegue la vostra suite sui worker di Oloproof invece che sulla vostra macchina, e la seguite dalla pagina Jobs o dal vostro terminale. Vi serve solo oloproof login; nessuna connessione a un database e nessun runner vostro.

Che cosa eseguirà un worker

Un worker chiama il vostro sistema via HTTP. Dichiaratelo con http: in oloproof.yaml (Riferimento della configurazione):

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

Un worker rifiuta:

• Un sistema callable: o rag:, prima che il job entri in coda. È il vostro codice, e i worker di Oloproof non eseguono codice dei clienti; eseguitelo sulla vostra macchina (oloproof run) e inviate l'esecuzione, oppure su un runner che gestite voi.
• Un file di risposte recorded:. Resta sulla vostra macchina; eseguitelo in locale con oloproof run.
• Un indirizzo che non è sull'internet pubblica: localhost, un nome a etichetta singola, un indirizzo privato, link-local o di metadati cloud. Ogni chiamata viene controllata mentre avviene, così un caso del genere termina in errore invece di raggiungerlo; un worker può raggiungere solo ciò che chiunque su internet può raggiungere.
• I casi di attacco generati, a meno che oloproof.yaml dichiari adversarial: {sandboxed: true} (Generare attacchi). --allow-adversarial copre solo un'esecuzione locale.

Avviarne una

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

run --cloud invia i casi della vostra suite al workspace (un'esecuzione gestita non può eseguire casi che non ha), poi mette il job in coda e indica dove seguirlo. Una suite che il workspace ha già per intero non viene inviata di nuovo.

Il worker controlla ogni caso rispetto al suo digest prima di conservare la suite, e rifiuta quella che non corrisponde. Perciò run --cloud calcola i digest dei casi senza chiave, come fa il worker, anche in un progetto che usa digest con chiave per trattenere il contenuto (egress:, Risultati ed esecuzione): i casi vengono comunque inviati per intero, quindi una chiave non nasconderebbe nulla. La suite dell'esecuzione gestita è quindi una suite diversa da quella che registra un'esecuzione locale dello stesso progetto. Un progetto il cui workspace contiene già evidenze con chiave (da un push) viene rifiutato: eseguitelo con oloproof run e fate il push dell'esecuzione.

--max-runtime è la scadenza del job in secondi, fino a un giorno, o il limite del vostro piano se è inferiore. Un budget: in oloproof.yaml vale su un worker come in locale.

Chi può avviarne una: un Owner, Admin o Member del workspace. Un Reviewer non può.

Seguirla

La pagina Jobs del progetto mostra i casi di ogni job man mano che arrivano: quanti sono stati eseguiti e giudicati, un conteggio di superati e falliti per controllo, e gli ultimi casi. Il conteggio è un totale parziale, non un risultato. Le decisioni si prendono una volta salvata l'intera esecuzione, e la sua pagina allora le mostra.

Nel terminale:

oloproof job JOB_ID --follow

stampa gli stessi conteggi ogni pochi secondi, poi il gate dell'esecuzione, ed esce con il codice di uscita del gate, così una pipeline può attendere un'esecuzione gestita come una locale (Esecuzione in CI). Senza --follow, job riferisce una volta; un job ancora in corso esce con 2, perché non è ancora una decisione. --cancel ferma subito un job in coda, e uno in corso prima della sua chiamata successiva, conservando i casi completati.

Chiavi per un giudice

Un giudice o un sistema che chiama un fornitore di modelli ha bisogno della sua chiave sul worker. Salvatela una volta:

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

La chiave viene letta dall'ambiente o dallo standard input, mai dalla riga di comando. Viene cifrata dal worker e può leggerla solo un worker che esegue i job di questo workspace; nessuno può rileggerla, e credentials list mostra solo i nomi. L'api_key_env: OPENAI_API_KEY di un valutatore la trova allora. Un job gestito non legge nessun'altra variabile d'ambiente. Solo un Owner o un Admin può salvare una chiave.

Che cosa questo non può dirvi

• Se il vostro sistema si comporta allo stesso modo dalla rete di Oloproof e dalla vostra. Un worker chiama il vostro endpoint dall'internet pubblica; limiti di frequenza, regioni e liste di autorizzazione che lo trattano diversamente cambiano ciò che misura.
• Nulla sul codice che un worker non ha eseguito. Un'esecuzione gestita misura l'endpoint che avete indicato, non il codice che c'è dietro.

Ogni altro limite di Che cosa una valutazione non può dirvi vale anche qui.