Documentazione
Scrivi una suite. Usala come gate.
Oloproof decide i rilasci sugli intervalli di confidenza anziché sulle stime puntuali. Queste pagine spiegano come dichiarare cosa misurare, come trasformare una decisione in un codice di uscita e cosa deve superare un giudice LLM prima di poter fare da gate.
Guida rapidaInstalla il motore, genera un progetto e ottieni una prima esecuzione e una decisione di gate sulla tua macchina. Nulla ne esce a meno che tu non faccia push.Concetti fondamentaliOloproof misura un sistema di IA nel modo in cui uno studio misura qualsiasi cosa: gli stessi casi, gli stessi giudici, gli stessi seed, eseguiti a ogni modifica. Ciò che aggiunge a una suite di test è che ogni numero arriva con la propria incertezza, e una decisione di rilascio viene presa sull'intervallo anziché sulla stima.Scrivere una suiteUna suite è composta da due file e un dataset. oloproof init genera entrambi i file, e lo scaffold è commentato perché il primo percorso di onboarding ha perso quattro tentativi per una stringa mancante anziché per una funzionalità mancante.L'API PythonTutto ciò che fa la CLI lo fa anche la libreria. Usala quando la valutazione appartiene a uno script, a un notebook o a una suite di test anziché stare accanto a un file di configurazione.Recording what a system didA system's output is what an evaluator reads by default. Everything else it did — the prompt it built, the passages it retrieved, the tools it called, the tokens it spent — is recorded alongside the output as artifacts and usage, and every artifact is stored content-addressed with the execution that produced it.Avanzamento e concorrenzaUna suite su un modello reale richiede minuti, e la maggior parte di essi viene spesa ad aspettare il modello. Questa pagina spiega quante chiamate Oloproof tiene in corso contemporaneamente, che cosa ti mostra mentre sono in esecuzione e come scoprire quanto altro lavoro servirebbe per risolvere una regola che non ha deciso.Gating CIA gate compares measured evidence against a threshold you declared, and exits with a code your CI understands. The decision is made on the interval, not on the estimate.Esecuzione in CIGating in CI tratta la policy di rilascio e il significato di ciascun codice di uscita. Questa pagina riguarda la parte che avviene all'interno di un job di CI: come installarvi Oloproof, dove risiede l'evidenza mentre il job è in esecuzione, come leggere un risultato senza analizzare una tabella e come confrontare una pull request con il branch a cui è destinata.Comparing a candidate to a baselineThe workflow the rest of this product exists for: you changed something, and you want to know whether it helped. A comparison pairs two runs case by case and reports the difference with an interval, so a two-point move is never mistaken for a win.Regole di confrontoConfrontare un candidato con una baseline mostra il flusso di lavoro. Questa pagina è il riferimento per le regole con cui viene deciso un confronto: quali tipi esistono, che cosa chiede ciascuno, in che unità si misura un margine e che cosa sposta l'intervallo da cui vengono lette.Casi raggruppatiLa maggior parte dell'aritmetica degli intervalli presuppone che ogni caso sia indipendente da ogni altro. Tre turni di una stessa conversazione non lo sono: quando la conversazione va male, tendono ad andare male tutti e tre. Una suite che li tratta come indipendenti riporta un intervallo più stretto di quanto l'evidenza sostenga, e un gate può passare su di esso.SliceUn tasso globale può restare stabile mentre una parte della suite crolla. Una slice è una parte dichiarata della suite, misurata a sé, così il crollo diventa visibile. Le slice hanno due discipline, perché guardare molte parti di una suite è il modo in cui una valutazione trova rumore e lo chiama scoperta.JudgesAn LLM judge is one kind of evaluator, not all of them. Oloproof has three kinds — deterministic, LLM judge, and custom — and the rules on this page are about the second, because a model's verdict is the one that needs measuring against a human's.Valutazione RAGUna risposta generata con recupero può essere sbagliata per quattro ragioni diverse: il passaggio giusto non è mai stato recuperato, è stato recuperato ma classificato troppo in basso, è stato classificato abbastanza in alto ma poi scartato dal contesto, oppure ha raggiunto il modello e il modello ha sbagliato comunque. Un unico numero di accuratezza non può distinguerle. Oloproof esegue un sistema RAG come due stadi che può osservare, misura ciascuno e riesegue i casi falliti sotto modifiche controllate per scoprire quale ragione si applica.Agenti e strumentiOloproof non pilota un agente. Il tuo agente esegue il proprio ciclo, chiama i propri strumenti e registra ciò che è accaduto come artefatto agent_trajectory/v1. Ogni metrica sugli agenti viene letta da quel record, quindi il record è l'intera integrazione.Classificatori e regressoriUn modello predittivo viene valutato come qualsiasi altro sistema: una funzione richiamabile restituisce una previsione per ogni caso, e i valutatori la leggono. Ciò che cambia sono i denominatori. Accuratezza, recall e precisione sono tre tassi su tre insiemi di righe diversi, e un modello può sembrare buono su uno mentre fallisce la domanda che il business sta ponendo.NotificheUn'esecuzione che passa non notifica nessuno. Quando Oloproof invia una notifica significa che qualcosa richiede una decisione o sta per smettere di funzionare: un rilascio bloccato da un gate, un'esecuzione gestita terminata, una franchigia in esaurimento.ErroriLa distinzione per cui esiste questa pagina: un'esecuzione fallita e un'esecuzione andata in errore sono cose diverse, e presentare l'una come l'altra dice a uno sviluppatore che la sua modifica è sbagliata quando la verità è che l'infrastruttura di test è caduta.Riferimento della CLIOgni comando registrato da Oloproof, con ciò che fa. Ognuno accetta --help, che stampa il testo completo da cui provengono questi riepiloghi.