Registro delle modifiche

oloproof 0.1.0a1 è pubblicato, quindi il percorso di riferimento comincia con pip install oloproof in un ambiente pulito e passa subito a oloproof init e oloproof run. Le versioni sono compilate e pubblicate da un commit con tag in CI, tramite la pubblicazione attendibile di PyPI, senza alcun token memorizzato.

Un'esecuzione o un confronto che si ferma in anticipo ora registra ogni controllo effettuato, e il workbench li ripercorre: l'intervallo valido in ogni momento che si restringe a ogni controllo rispetto a una soglia che non si sposta, e il controllo in cui ogni regola ha deciso. Disegna solo intervalli registrati dal motore. Un intervallo a campione fisso non viene mai animato come se fosse in tempo reale, perché osservarlo finché sembra buono ne annulla la garanzia.

⌘K o Ctrl+K elenca ogni destinazione che puoi vedere, e un id di esecuzione o un digest di confronto incollato la apre. g seguito da una lettera naviga, j e k scorrono le righe di una tabella, e ? elenca tutte le scorciatoie. Un caso si apre accanto alla sua esecuzione, con la sua catena delle prove e le persone che lo hanno etichettato. Ogni animazione si ferma con il movimento ridotto.

Il workbench ora serve oloproof.com, e il percorso di riferimento end-to-end è stato superato sul server: un revisore ha etichettato 80 casi estratti dal workspace, ha trovato 7 risposte sbagliate che il giudice aveva promosso, e il workspace ha deciso Superato sul suo campione verificato (91,2%, intervallo da 74,5% a 100,0%) dove l'esecuzione inviata da sola aveva prove insufficienti. L'accesso è su invito.

oloproof collect riceve OTLP/HTTP da un SDK OpenTelemetry standard, assembla gli span GenAI e OpenInference in trace indirizzate per contenuto e ne tiene il contenuto sulla tua macchina; un push segue la tua policy di uscita dei dati. oloproof traces promote trasforma una trace in un caso di test con la sua provenienza e rifiuta i duplicati.

Il tuo collector firma ogni ora un impegno su ogni trace che ha sigillato. Il workspace estrae poi un campione con la propria casualità e verifica ogni trace estratta rispetto all'impegno, così un campione non può essere selezionato ad arte trattenendo delle trace. oloproof traces evaluate giudica il campione sui suoi output registrati, il workspace lo decide secondo la valutazione fissata da un Owner, e una sequenza di confidenza segue ogni metrica attraverso i campioni nella pagina Production del progetto.

Un Owner o un Admin apre una coda e assegna i revisori, che etichettano da tastiera: superato o fallito, un punteggio su una scala dichiarata o una preferenza alla cieca tra due esecuzioni, ciascuna registrata per account. Il browser del revisore recupera il contenuto dei casi da oloproof collect dalla tua parte con un ticket firmato di cinque minuti, così il workspace non lo conserva mai.

Un'esecuzione può essere firmata da una chiave runner registrata da un Owner, oppure dal worker gestito. Un Owner fissa l'intera valutazione (suite, valutatori, metriche ed esecuzione di riferimento) e la sua policy di gate, e il workspace decide ogni versione del sistema alla sua prima esecuzione esattamente di quella valutazione, rispetto all'esecuzione fissata. Le etichette umane contano solo se vengono da etichettatori indipendenti, contati per account.

Un intervallo PPI corregge un giudice con un campione casuale di etichette umane, e la sua garanzia richiede un campione che nessuno abbia scelto. Il workspace ora estrae quel campione dopo che le prove dell'esecuzione vi sono state congelate, tiene il seed per sé e verifica l'intervallo corretto con il proprio motore. La pagina dell'esecuzione indica se il workspace ha verificato un intervallo; un campione estratto sulla tua macchina resta etichettato come in buona fede.

Una policy con early_stopping: true esegue i casi in batch con seed e ferma un'esecuzione, o una candidata e il suo riferimento in parallelo, non appena ogni regola ha deciso, registrandola come DECIDED_EARLY insieme ai casi che non le sono serviti. I tassi fermati usano un intervallo di scommessa valido in ogni momento, quindi guardare dopo ogni batch ne conserva la garanzia. Il tasso di promozione di un giudice può essere sottoposto a un gate su un intervallo PPI che combina il giudice con un campione casuale alla cieca di etichette umane, mostrato accanto agli intervalli del solo giudice e delle sole persone.

Quattro notifiche, ognuna una categoria che un membro può disattivare dall'email stessa: un job gestito è terminato o fallito, un'esecuzione o un confronto inviato il cui gate blocca un rilascio, l'utilizzo all'80% e al 100% della quota gratuita, e un membro che si è unito. Un'email di gate cita la decisione memorizzata e rimanda all'esecuzione, senza contenuto dei casi. Solo email: niente Slack, pager o webhook.

Accedi con un indirizzo email e una password oltre che con un provider, con indirizzi verificati e reimpostazioni. Una persona può eliminare il proprio account: l'utente e ogni workspace di cui era l'unico membro spariscono insieme, e il worker elimina le prove di quei workspace.

Un giudice può rispondere a una domanda tipizzata (sì o no, una scelta, un punteggio rispetto a livelli) con una probabilità per ogni risposta, letta dalle probabilità dei token di un modello locale in un solo passaggio in avanti. La sua calibrazione è misurata rispetto alle etichette umane e registrata nella sua voce di registro, e una cascata invia a un giudice più forte solo i casi su cui un giudice economico è incerto. Anche un classificatore addestrato può essere un valutatore, senza chiave e senza rete.

Etichetta i casi di un'esecuzione da un file o dal terminale, e prova un giudice in bozza su quelle etichette prima di adottarlo. Un giudice riporta il suo bias accanto alla sua concordanza, uno il cui bias supera un margine dichiarato è escluso dai gate, e una validazione smette di contare non appena cambia il modello che ha misurato. Sonde senza etichette verificano se un verdetto si sposta quando nulla di rilevante è cambiato, e i confronti a coppie vengono posti in entrambi gli ordini, così una risposta preferita solo per la sua posizione emerge senza che nessuno etichetti.

Una traiettoria registra quale agente ha compiuto ogni passo, e ogni passaggio di consegne. I valutatori giudicano l'instradamento (la richiesta ha raggiunto l'agente che doveva gestirla), i permessi degli strumenti (un agente ha chiamato uno strumento che non gli spettava) e gli agenti che si passano il controllo avanti e indietro invece di concludere, e i segmenti raggruppano i casi per percorso.

Una suite può misurare ogni caso più volte. Le repliche vengono aggregate per caso prima di qualsiasi intervallo, i confronti le appaiano come frazioni e l'esecuzione riporta quanti casi sono stati in disaccordo con se stessi. Un sistema può contrassegnare un errore come transitorio perché il runner lo riprovi: su un sistema RAG reale questo ha recuperato 18 casi mancanti su 22 e ristretto l'intervallo del 39%.