Vai al contenuto

Guide

Scegliere tra candidati

oloproof select sceglie, tra più versioni di un sistema, la migliore che soddisfa ogni requisito, e dice a parte se è davvero davanti alla successiva. Usatelo quando avete, per esempio, tre agenti, due prompt o quattro impostazioni di recupero, e un solo insieme di requisiti.

Perché non scegliere i numeri migliori

Scegliere il candidato più economico i cui numeri superano le soglie ha due problemi. Un 91% misurato contro una soglia del 90% è un punto sopra, dentro il rumore di mille casi. E quando guardate diversi candidati, quello che ha superato la soglia per fortuna è quello che scegliete. Perciò ogni candidato deve prima stabilire ogni regola da solo, con un livello di confidenza più severo perché se ne guardano diversi: con tre candidati e una policy al 95%, ciascuno viene deciso al 98.33% (1 - 0.05/3). Solo i candidati che superano ogni regola vengono classificati, e uno più economico non può mai scambiare una regola di sicurezza con il suo costo.

Dichiarare una selezione

Scrivete un file di selezione accanto al progetto e decidetelo sotto il release.yaml del progetto:

select:
  candidates:
    agent_a: run_01JC8Q2X7D
    agent_b: agent_b.yaml
    agent_c: agent_c.yaml
  objective:
    metric: cost_per_task
    direction: minimize

Un candidato è un id di run memorizzato, oppure un file di progetto che oloproof select esegue prima. Una run che può riutilizzare non costa nulla di nuovo. La policy può contenere solo regole di run, e l'arresto anticipato deve essere disattivato.

oloproof select select.yaml
oloproof select select.yaml --save

--save scrive anche la selezione per il workbench locale, sotto Candidates.

Leggere la risposta

Ci sono tre esiti:

  • Un candidato viene selezionato e il suo vantaggio sul secondo è stabilito: il confronto appaiato dei due sull'obiettivo è PASS.
  • Un candidato viene selezionato e il suo vantaggio non è stabilito: il secondo sarebbe stato una scelta altrettanto difendibile su queste evidenze.
  • Nessun candidato si qualifica: le regole di ogni candidato sono elencate con le loro risposte, così vedete cosa manca.

Il comando esce con 0 quando un candidato è selezionato e con 3 quando nessuno si qualifica.

Un esempio svolto

Tre agenti devono raggiungere un tasso di successo di almeno il 90% e un tasso di violazioni di al massimo l'1%; l'obiettivo è il costo per attività più basso.

AgenteSuccessoViolazioniCosto per attività
A94%0.5%$18
B91%0.1%$12
C96%2%$30

Ciascuno è deciso al 98.33%. Con 1,000 casi nessun agente si qualifica: il tasso di violazioni di A non è ancora dimostrato sotto l'1%, il 91% di B è troppo vicino al 90% per essere stabilito, e C supera il tetto delle violazioni. La risposta è "nessun candidato si qualifica", con ciò che manca a ciascuno. Con 3,000 casi A stabilisce entrambe le regole e viene selezionato. B costa meno, ma il suo successo non è ancora stabilito, quindi non viene mai classificato: scegliere B per i suoi numeri rilascerebbe un requisito che nessuno ha dimostrato.

Condividere una selezione

oloproof select select.yaml --save conserva la selezione per il workbench. oloproof push --selection ID la invia al workspace ospitato con l’esecuzione di ogni candidato, attraverso la policy di egress del progetto; ID è il nome della cartella sotto .oloproof/bundles/ o il digest della selezione. Prima di conservare la selezione, il workspace la rifà a partire dalle esecuzioni che possiede, sotto la policy con cui quelle esecuzioni sono state decise, e la conserva solo se il risultato è lo stesso: una il cui risultato o le cui frasi sono stati modificati, che nomina un’esecuzione che il progetto non possiede, o che il motore non fa a partire da quelle esecuzioni, viene rifiutata, e non viene salvato nulla. Decidete quindi le esecuzioni dei candidati sotto la policy della selezione prima di inviarle. La pagina Candidates del progetto la elenca, e la sua pagina la mostra esattamente come il workbench locale.

Un Owner o un Admin può ricavarne una pagina di evidenza dalla pagina della selezione: l’esito, il livello e, per ogni candidato, nome, id dell’esecuzione e regole al livello corretto, con l’etichetta "Reported by the developer", mai il contenuto di un caso.

Prossimi passi

  • Regole di confronto tratta il confronto appaiato che decide il vantaggio.
  • Gating tratta le regole a cui è tenuto ogni candidato.