Guide
Cosa funziona oggi
Cosa puoi valutare con Oloproof oggi, come ci arrivi (SDK Python, oloproof.yaml e la CLI, oppure il browser), e cosa non è costruito. È tratto dall'audit delle capacità dell'8 ottobre 2026, una revisione interna che ha verificato ogni riga rispetto al codice e ai suoi test anziché rispetto ai piani.
Come leggere questa pagina
"SDK" indica il pacchetto Python (import oloproof). "YAML" indica un progetto che esegui con oloproof run da oloproof.yaml. Non sono la stessa superficie: alcuni valutatori esistono solo in una delle due, e questa pagina dice quale. "Browser" indica il workbench ospitato, che mostra ciò che invii con oloproof push; non esegue valutazioni che non hai definito nel codice o in YAML.
Oloproof chiama il tuo sistema; non lo ospita, non lo isola e non lo reimposta. La tua applicazione gestisce il proprio stato, le proprie sessioni e gli effetti collaterali dei propri strumenti durante un'esecuzione.
Per tipo di sistema
| Il tuo sistema | Cosa funziona | Dove | Non costruito |
|---|---|---|---|
| Classificatore o output strutturato | Corrispondenza esatta, contains, regex, JSON schema, giudice a rubrica, giudice di probabilità, classificatore a modello; tassi di pass con intervalli | SDK e YAML; model_classifier, probability_judge e cascade solo in YAML | n/a |
| Generazione di testo, riassunti, estrazione | Gli stessi controlli sul testo libero, giudici a rubrica, accordo del giudice con le etichette umane, preferenza a coppie | SDK e YAML; la preferenza è il comando oloproof prefer | BLEU, ROUGE o similarità di embedding (scrivine uno con @evaluator) |
| RAG eseguito come scatola nera | Hit rate, recall, MRR, nDCG, validità delle citazioni, giudici di fondatezza e di supporto delle citazioni, da artefatti di recupero che il tuo sistema registra o restituisce | SDK e YAML | Diagnosi: diagnose richiede un sistema a stadi |
| RAG costruito a stadi | Tutto quanto sopra, cache per stadio, e oloproof diagnose con contesto gold, modifiche a top-k o al reranker accanto a un controllo | SDK @rag_system, YAML system.rag, CLI diagnose | Interventi oltre questi tre |
| Agente che usa strumenti | Limiti di passi, strumenti richiesti e vietati, ordine degli strumenti, cicli, vincoli, da una traiettoria registrata | SDK e YAML | Un controllo della qualità della traiettoria giudicato da un LLM |
| Sistema multi-agente | Instradamento, permessi sugli strumenti per agente, limiti di passaggio di consegne | SDK e YAML | n/a |
| Replay dell'agente | Rieseguire un caso da un checkpoint per etichettare un passo come necessario o no | Solo SDK (replay_case), per un sistema che supporta i checkpoint | Un comando CLI |
| Modello di classificazione binaria | Accuratezza, precisione, recall, Brier, log loss, ranking (AUC) | SDK e YAML predictive: | n/a |
| Modello multiclasse | Un blocco per classe (una contro le altre) | SDK e YAML | Medie macro o micro |
| Modello di regressione | Errore assoluto entro un target_range dichiarato | SDK e YAML | Errore quadratico, R quadro, errore illimitato |
| Conversazione a più turni | Se ogni turno previsto ha ricevuto risposta, e un giudice a rubrica sull'intera conversazione | Solo SDK (ConversationCompleted, ConversationJudge) | Tipi YAML, punteggi per turno, un simulatore di utente, replay della conversazione |
| Immagini, audio, video | Niente di nativo: un caso può portare un URL o un file codificato attraverso il tuo sistema, e @evaluator può controllare l'output | n/a | I giudici vedono solo testo JSON; nessun artefatto multimediale né rendering |
Un ripiego per le conversazioni a più turni: fai di ogni turno un caso e dai ai turni di una stessa conversazione lo stesso group_id, così l'analisi li tratta come un cluster (Cluster). Ogni turno è allora una chiamata separata, non un dialogo registrato.
Collegare il tuo sistema
- Callable Python: @system nell'SDK oppure system.callable: module:function in YAML. Riceve l'input del caso e restituisce un dizionario. Funzionano sia le funzioni sincrone sia quelle asincrone.
- HTTP: system.http con url, method, output_path, artifacts e timeout_s. L'input del caso viene inviato come corpo JSON e la risposta letta come JSON. Intestazioni e autenticazione non sono ancora configurabili; metti un endpoint che richiede una chiave dietro un callable che la aggiunge.
- Valutatori personalizzati: @evaluator nell'SDK. oloproof.yaml non può ancora nominarne uno.
Flussi di lavoro
| Flusso di lavoro | Cosa funziona | Non costruito |
|---|---|---|
| Confrontare due versioni | Superiorità appaiata, non inferiorità ed equivalenza; slice con controllo della molteplicità | n/a |
| CI | Codici di uscita di oloproof gate dal block_on della tua policy, approvazione, record firmati; un riepilogo per la pull request (--summary markdown) | n/a |
| Revisione umana | Etichette da un file o dal terminale; una coda di revisione nel browser con revisori assegnati su un workspace ospitato | Una coda di revisione nel browser su un progetto locale |
| Workbench nel browser | Esecuzioni, casi, confronti, diagnostica, valutatori, revisione e traffico, dopo oloproof push | Importazione di dataset, scrittura di giudici, pianificazioni, avvisi e postmortem (mostrati come pianificati) |
| Browser locale | n/a | Nessun comando della CLI serve il workbench in locale; è ospitato |
Cosa è stato testato, e come
Ogni famiglia qui sopra ha test automatici, eseguiti su fixture e provider simulati. Esecuzioni su sistemi reali con modelli reali sono registrate per RAG, un singolo agente e una conversazione a più turni; nessuna ancora per modelli predittivi o sistemi multi-agente. I metodi statistici che decidono i rilasci sono ammessi ciascuno dal proprio audit; una metrica senza un intervallo ammesso non decide una regola su un intervallo, e una regola che ne avrebbe bisogno restituisce MANUAL_REVIEW o INSUFFICIENT_EVIDENCE con il suo motivo.