Skip to content
AccediInizia
Valutazione di sistemi di IA

Costruisci sulle prove.

Oloproof aiuta i team a valutare i sistemi di IA con test ripetibili, diagnostica e prove su cui basare le decisioni.

Gira nella tua CI. Le tue prove restano sulla tua macchina.

oloproof / compare · olotalk-docs-assistant
Riepilogo Confronto Diagnostica Prove
BASELINE
olotalk docs assistant · rerank disattivato
CANDIDATO
olotalk docs assistant · rerank attivato
DATASET
olotalk golden panel · 58 casi
METRICA BASELINE CANDIDATO Δ APPAIATA IC 95% STATO
page_hit_1 0.618 0.745 +6.2 [-36.3, +45.5] — Non conclusivo
page_hit_3 0.683 0.742 +3.7 [-73.9, +76.2] — Non conclusivo
answer_correct 0.685 0.760 +6.5 [-39.4, +48.4] — Non conclusivo
page_hit_1 osservato 55 / 58 51 / 58 −4 nell'intervallo ! Delimitato
page_hit_3 osservato 41 / 58 31 / 58 −10 nell'intervallo ! Delimitato
answer_correct osservato 54 / 58 50 / 58 −4 nell'intervallo ! Delimitato
PERCHÉ VALUTARE

Testare i prompt a mano non regge in produzione.

I team rilasciano modifiche a modelli e prompt ogni settimana. Controllare a campione una manciata di output in un playground non ti dice quasi nulla su cosa è cambiato, per chi, né se sia sicuro rilasciarlo.

Oloproof lo sostituisce con un registro misurato: gli stessi casi, gli stessi giudici, gli stessi seed, eseguiti a ogni modifica.

01
Regressioni silenziose

Una modifica al prompt corregge una classe di errori e ne rompe silenziosamente un'altra. Nessuno se ne accorge finché non se ne accorge un cliente.

02
Risultati non ripetibili

Su un sistema RAG in produzione, circa un caso osservato su nove ha cambiato verdetto tra misurazioni identiche.

03
Punteggi senza significato

Un harness in produzione ha conteggiato come zeri il suo 13,8% di HTTP 500, attribuendo i disservizi al modello. Una media non può reggere una decisione.

04
Nessun registro da mostrare

Quando il risk management, l'ufficio legale o un cliente chiedono cosa è stato testato, gli screenshot in una conversazione non sono una risposta.

CAPACITÀ PRINCIPALI

Quattro cose di cui ogni decisione di rilascio ha bisogno.

MISURARE
Valutazioni ripetibili

Dataset versionati, seed fissati e giudici dichiarativi. Ogni esecuzione si riproduce esattamente, anche mesi dopo.

CONFRONTARE
Baseline e candidato a confronto

Differenze con intervalli di confidenza e soglie, così uno spostamento di due punti non viene mai scambiato per un successo.

DIAGNOSTICARE
Modalità di errore, non medie

Errori raggruppati per segmento, intento e percorso degli strumenti, ciascuno collegato alle tracce esatte che lo sostengono.

DECIDERE
Registri su cui basare le decisioni

Una raccomandazione di rilascio con le prove allegate — esportabile per revisione, audit e clienti.

Diagnostica23 casi falliti, contesto di riferimento
Irrisolti: il contesto di riferimento non li ha chiariti11 casi
Errore di generazione: contesto giusto, risposta sbagliata7 casi
Mancato recupero: risposta raggiungibile, non recuperata5 casi
Rerank attivato meno disattivatoIntervallo al 95%, punti
hit@1
hit@3
corretta

Ogni intervallo attraversa la linea tratteggiata dello zero. Guardando solo le stime puntuali, il reranker sarebbe stato rilasciato.

PIATTAFORMA

Pensato per i team che devono giustificare il rilascio.

Suite di valutazione come codice

Definisci dataset, giudici e soglie nel controllo di versione. Rivedi le modifiche alla valutazione come rivedi il codice.

Giudici verificabili

Controlli programmatici, giudici LLM, classificatori addestrati che assegnano punteggi al testo sulla tua macchina ed etichette umane in un'unica pipeline. L'accordo di ogni giudice con le persone è misurato con un intervallo, e un giudice che non ha superato la sua soglia non può decidere un rilascio.

Gate di regressione in CI

Fai fallire una pull request quando una metrica supera la sua soglia. Il gate indica quali casi si sono spostati e di quanto.

Prove a livello di traccia

Ogni punteggio rimanda a input, output, chiamate agli strumenti, contesto recuperato e motivazione del giudice. Niente è una scatola nera.

Budget di costo e latenza

La qualità non è mai l'unico asse. Monitora la spesa e la latenza di coda insieme alla correttezza, con le stesse soglie.

Prove per chi ha bisogno della decisione

Condividi l'esecuzione, la diagnostica e la raccomandazione senza alterare la decisione misurata che contengono.

COME FUNZIONA

Tre passi, poi procede da solo.

1
Definisci la suite

Porta i tuoi casi come file JSONL. Dichiara i giudici e le soglie che un rilascio deve superare.

2
Esegui a ogni modifica

Un comando in locale, lo stesso comando in CI. Le modifiche a prompt, modello, recupero e strumenti ricevono lo stesso trattamento.

3
Decidi con le prove

Leggi le differenze, apri le tracce che falliscono e mantieni le prove allegate alla decisione che hai preso.

~/olodemo · dopo oloproof init 
 oloproof run
Run run_01M3B0CCPA0JFQQ7HWRKYNWFJC [DECIDED/COMPLETE]
Gate: ALLOW (exit 0)

  Rule         Metric       State  Reasons
  label-floor  exact_label  PASS   lower_bound_meets_minimum

  Metric       Estimate  Interval          N
  exact_label  100.0%    [88.4%, 100.0%]   30 / 30 observed · 0 missing

Cache: execution 0 hit/30 miss; judgment 0 hit/30 miss

 oloproof run
Run run_01M3B0CXTTVPTBXAFK3WNGFX42 [DECIDED/COMPLETE]
Gate: ALLOW (exit 0)
Cache: execution 30 hit/0 miss; judgment 0 hit/30 miss
PROVE DA CONSEGNARE

Ogni numero risale a un caso.

Le esecuzioni sono immutabili e datate. Dataset, prompt, giudici e configurazione sono versionati insieme, così qualsiasi risultato può essere riprodotto o contestato.

Immutabili
esecuzioni, con lineage completo
Self-hosted
sulla tua infrastruttura, i tuoi dati restano tuoi
Delimitati
casi mancanti conteggiati, mai scartati

Guardando le stime puntuali, il reranker porta +12,7 punti di hit@1. Letto onestamente, questo panel non può dire se aiuta o peggiora.

Oloproof su un sistema RAG in produzione, 22 settembre 2026
Oloproof
Pacchetto di prove
oloproof export RUN_ID
run.jsonl'esecuzione, la sua suite, il sistema e i valutatori
cases.jsonlogni caso: input, output, giudizi, digest
diagnoses.jsonlinterventi e ciò che hanno recuperato
signoffs.jsonlchi ha rilasciato nonostante un gate bloccato, e perché
Un pacchetto di prove esportato: l'esecuzione e ogni caso dietro i suoi numeri, come file che conservi tu.
LA STESSA DISCIPLINA, APPLICATA QUI

Cosa questo non è, ancora.

Tutto quanto segue è vero nel giorno in cui lo leggi.

  1. 01

    Non esiste un deployment ospitato a cui puoi registrarti. L'accesso è su invito.

  2. 02

    Non ci sono prezzi. L'unità è un caso valutato; le tariffe non sono fissate.

  3. 03

    Non c'è alcun audit di sicurezza, nessun report SOC 2 e nessun DPA. Non ci sono clienti né casi di studio, quindi non se ne cita nessuno.

  4. 04

    Le notifiche sono solo via email: niente Slack, cercapersone o webhook. Non c'è un documento di report. Un'esecuzione si legge nel workbench o si esporta come pacchetto.

  5. 05

    La valutazione in produzione non è stata realizzata: le tracce vengono ricevute sulla tua macchina e niente valuta ancora il traffico di produzione.

  6. 06

    È stato eseguito dall'inizio alla fine su esattamente un sistema di terze parti in produzione. Sono le prove qui sopra, ed è un solo sistema.

Misura prima di rilasciare.

Porta un sistema e un dataset. Inizia con un'esecuzione locale e tieni le prove sulla tua macchina.