Opik LLM Osservabilità: controlla i punteggi dei thread prima del verde

Opik può dirti molto su un agente multi turno, ma una traccia visibile o un punteggio elevato nella conversazione non sono ancora un verdetto sulla salute. L'impostazione predefinita ragionevole è utilizzare Opik per prove di tracciamento e valutazione, quindi richiedere quattro fatti aggiuntivi prima di mostrare il verde: i turni previsti sono finiti sotto l'identità di un thread, il thread era idoneo per il punteggio, il punteggio è stato prodotto dopo l'ultima attività e il risultato richiesto esiste a destinazione. Questa distinzione è più importante quando manca un punteggio o sembra rassicurante. "Nessun punteggio" può significare che la conversazione è ancora attiva, la regola di campionamento l'ha esclusa, il punteggio è in sospeso o il punteggio è in fase di stallo. Un punteggio pari a 0.94 può appartenere alla versione precedente di un thread. Anche un nuovo 0.94 può coesistere con un file mancante, un messaggio non inviato o un aggiornamento non riuscito. Questa guida crea una ricevuta priva di contenuto e ripropone dieci casi a fronte di essa. È stato confrontato con Opik 2.2.12 al commit del repository c54a6a9 il 29 luglio 2026. Non richiede richieste, risposte, credenziali o identificatori del cliente. Prova il thread prima di giudicare il punteggio Opik raggruppa le tracce correlate con uno thread id definito dall'utente. Suo documentazione della conversazione appuntata dice che l'identificatore deve essere univoco all'interno di un progetto. Ciò offre agli operatori un confine importante: una conversazione non è “qualunque riga sembri correlata” nella dashboard. Prima di leggere qualsiasi risultato del valutatore a livello di thread, registrare: lo spazio di lavoro e il progetto che si prevede riceveranno le tracce; un hash opaco o una rappresentazione non sensibile dell'ID del thread previsto; gli ID thread distinti osservati per le svolte previste; l'ora dell'ultima attività di tracciamento; il tempo di raccolta o di query utilizzato per stabilire la visibilità. Un ID osservato che corrisponde all'ID previsto supera il cancello di identità. Zero ID è un problema di telemetria. Due ID per una conversazione prevista rappresentano una frammentazione, anche se entrambi i frammenti hanno intervalli validi individualmente. Anche il riutilizzo dello stesso ID di facile visualizzazione in un progetto diverso costituisce un ambito di prova diverso. Non cominciare colpendo il valutatore quando manca una traccia. Opik guida alla configurazione SDK appuntato batch di documenti nei controlli TypeScript SDK e espliciti client.flush() e flushAll() . Uno svuotamento completato è un'utile prova di consegna, ma non dimostra ancora che il raccoglitore abbia accettato il batch o che la query stia leggendo il progetto previsto. Confermare la visibilità dopo il confine livellato. Questo ordine previene un errore diagnostico comune: Tratta il tempo di recupero e il campionamento come idoneità, non come fallimento La valutazione online a livello di thread è intenzionalmente asincrona. Opik documenta un tempo di recupero predefinito di 15 minuti dopo l'ultima attività prima che venga assegnato il punteggio a un thread. Il valore può essere modificato nelle impostazioni dell'area di lavoro o tramite l'impostazione dell'ambiente self hosted documentato. Lo stesso documentazione appuntata spiega che il ritardo ha lo scopo di consentire che l'intera conversazione si risolva. Pertanto, now last activity at < configured cooldown è attivo , non in ritardo. L'agente potrebbe essere in funzione, in attesa del turno di un utente legittimo o semplicemente all'interno della finestra di osservazione. Il cercapersone al quinto minuto quando la policy registrata è di 15 minuti produce un incidente. Il campionamento crea un secondo percorso di non guasto. Una regola online Opik ha una frequenza di campionamento esplicita insieme al modello, al prompt, alla mappatura delle variabili e alla definizione del punteggio. Se una ricevuta dice che un thread non è stato selezionato, lo stato corretto è coverage excluded . Non è scoring overdue . Per i thread selezionati, aggiungi un periodo di tolleranza del punteggio separato dopo il raffreddamento. Questo periodo di grazia è il tuo SLO operativo, non una garanzia Opik: Tra quei tempi, mantieni il verdetto scoring pending . Dopo overdue at , controlla i log delle regole, le credenziali del valutatore, la disponibilità del modello, i limiti di velocità e lo stato della coda. Ciò crea un confine di avviso pulito senza confondere un'attività legittima con un valutatore non riuscito. La ricevuta deve preservare la politica che ha prodotto la decisione. Memorizza il tempo di attesa effettivamente configurato, la versione della regola, la decisione di campionamento, il nome del valutatore e il periodo di grazia con la classificazione. Se il tempo di recupero cambia da 15 a 30 minuti, gli eventi storici dovrebbero rimanere spiegabili anziché acquisire silenziosamente un nuovo significato. Un punteggio visibile può ancora essere obsoleto La nuova attività modifica la versione delle prove. Opik documentazione del thread di conversazione afferma che l'aggiunta di una traccia preserva i punteggi di feedback esistenti, riavvia il tempo di recupero ed esegue nuovamente la valutazione online dopo il nuovo tempo di recupero. La conservazione è utile per la continuità, ma crea un temporaneo rischio di verde stantio. Usa questa regola: Se il punteggio visibile è antecedente al turno più recente, classificalo come score stale indipendentemente dal suo valore. Attendi la riesecuzione o valuta esplicitamente l'ultima revisione del thread. Non calcolare la media del vecchio punteggio in verde e non cancellarlo; conservarlo come prova di uno stato precedente del thread. La freschezza è necessaria ma non sufficiente. Opik memorizza i risultati della valutazione online come punteggi di feedback e le sue regole di thread possono giudicare un'intera conversazione. IL documentazione delle regole appuntate descrive anche la coerenza della conversazione, la frustrazione dell'utente e le metriche personalizzate, incluso l'accesso al percorso di esecuzione quando il modello selezionato supporta la chiamata dello strumento. Questi sono i risultati della valutazione. Rispondono alla domanda codificata nella metrica. Non dimostrano automaticamente l’esistenza di un effetto collaterale esterno o di un risultato finale. Supponiamo che un agente dell'assistenza riceva un punteggio elevato di pertinenza e coerenza dopo aver affermato di aver aggiornato un ticket. Le prove del thread possono supportare che "la conversazione era coerente" e forse "è apparsa la chiamata allo strumento previsto". Solo il sistema di ticket può dimostrare che il ticket previsto ora contiene la modifica delimitata prevista. Il gate finale deve interrogare quella destinazione utilizzando una chiave di correlazione non sensibile e confrontare il risultato con una regola di accettazione deterministica. Ciò produce tre decisioni distinte: nuovo punteggio sotto la soglia: quality alert ; nuovo punteggio accettabile senza ricevuta di destinazione: outcome unverified ; nuovo punteggio accettabile più una ricevuta di destinazione corrispondente: verified . L'ordine è intenzionale. Una ricevuta di destinazione non rende sana una conversazione mediocre e un buon punteggio di conversazione non crea il risultato di destinazione. Riprodurre l’audit dei dieci stati L'apparecchio opik thread score audit.mjs in dotazione non contiene contenuti di conversazione. Ogni caso fornisce solo visibilità, identità prevista e osservata, ultima attività, selezione del campionamento, punteggio e tempo del punteggio e una ricevuta di destinazione booleana. La policy di esempio utilizza il tempo di recupero predefinito documentato di 900 secondi, un limite di punteggio di 300 secondi scelto localmente e una soglia dimostrativa di 0.7 . La precedenza dello stato è più semplice da applicare come elenco decisionale sicuro per i dispositivi mobili: 1. telemetry missing : la traccia prevista non è visibile. Controlla lo svuotamento, il raccoglitore, il progetto e l'aggiornamento delle query. 2. thread fragmented : gli ID osservati non equivalgono a un ID previsto. Riparare la propagazione prima di giudicare. 3. active : l'ultima attività è in cooldown. Lascia stare. 4. coverage excluded : il thread idoneo non è stato campionato. Copertura record; non paginare. 5. scoring pending : il thread selezionato è idoneo ma è in grazia. Conserva sconosciuto e aspetta. 6. scoring overdue : il thread selezionato è fuori grazia senza punteggio. Ispezionare il percorso del valutatore. 7. score stale : il tempo del punteggio è precedente all'ultima attività. Valutare l'ultima revisione. 8. quality alert : un nuovo punteggio è inferiore alla soglia scelta. Esaminare le prove con autorità limitata. 9. outcome unverified : il punteggio è fresco e accettabile, ma non c'è ricevuta di destinazione. Verificare il risultato reale. 10. verified : identità, tempismo, punteggio e risultato passano tutti. Conserva le ricevute. Esegui l'artefatto dalla sua directory: Il replay fisso restituisce dieci diversi stati attesi ed esce diverso da zero se qualsiasi caso cambia inaspettatamente. Vale la pena confrontare due casi: Il primo ha un punteggio di 0.94 , ma il punteggio è antecedente all'ultima traccia. Il secondo ha un 0.91 nuovo, ma nessuna ricevuta di destinazione. Solo il terzo ha un thread stabile, una valutazione corrente completata, un punteggio accettabile e risultati verificati. Adatta l'apparecchiatura sostituendo le ricevute sintetiche con un'esportazione a contenuto ridotto al minimo dal tuo ambiente. Identificatori hash se l'uguaglianza è tutto ciò di cui hai bisogno. Mantieni il testo immediato, le risposte, i payload degli strumenti, i segreti e i percorsi locali assoluti fuori dal flusso di integrità. Imposta la tolleranza del punteggio e la soglia di qualità dalla latenza del tuo valutatore e dai dati di calibrazione; nessuno dei due valori viene fornito come predefinito Opik universale. Utilizzare una regola operativa calma Per l’osservabilità di Opik LLM, la regola pratica è: Non interpretare il punteggio di un thread finché le tracce previste non formano un thread corrente e la politica di punteggio non indica che il thread era idoneo. Non cancellare la corsa finché il punteggio non è più recente dell'ultima attività e il risultato richiesto non viene verificato in modo indipendente. Questa regola preserva l'attesa legittima, rende visibile il campionamento e impedisce sia gli allarmi di punteggio mancante che gli stati verdi di punteggio obsoleto. Inoltre, mantiene onesto il confine: Opik fornisce preziose prove di tracciabilità e valutazione; la tua destinazione fornisce la ricevuta dell'esito. L'audit ha dei limiti. Non verifica la calibrazione del valutatore, la qualità dei prompt, la correttezza semantica, la completezza del provider o la disponibilità di una distribuzione Opik live. Una macchina a stati priva di contenuto non può decidere se 0.7 è la soglia giusta per il tuo compito. Calibra i giudici rispetto alle etichette deterministiche e umane, registra l'incertezza e mantieni un percorso di revisione umana per le decisioni consequenziali. Sidewisp è attualmente in anteprima privata. Il suo livello di integrità pianificato ha lo scopo di mettere prove, freschezza, stati di attesa e risultati verificati in una visualizzazione operatore, ma questo articolo non implica che un adattatore Opik o un motore di monitoraggio della produzione venga spedito oggi. Fonti primarie Conversazione Opik e documentazione sull'identità del thread, fissata al commit rivisto Opik regole di valutazione online, fissate al commit revisionato Configurazione Opik SDK e controlli di flush, aggiunti al commit rivisto