LLM Monitoring: cosa misurare oltre la latenza, gli errori e i token

Il monitoraggio di LLM dovrebbe iniziare con la salute delle chiamate del modello: latenza, errori, volume delle richieste, token e qualità delle uscite. Questa è la regola predefinita ragionevole per una funzione di chat, un pipeline di recupero o un wrapper API. Una volta che la stessa applicazione può pianificare, chiamare strumenti, aspettare l'approvazione, riprendere più tardi, o dichiarare un compito completo, aggiungere un secondo libro maggiore per la salute operativa. I due registri rispondono a domande diverse. Il primo chiede: Il servizio modello si comporta normalmente? Il secondo chiede: L'agente ha fatto progressi utili e ha prodotto il risultato atteso? Unisciti a loro con un run id ; non trasformare un grafico verde di latenza in una affermazione che il lavoro è sano. Inizia con lo strato di monitoraggio LLM predefinito Un primo dashboard utile non ha bisogno di dozzine di pannelli. È necessario avere prove sufficienti per separare il fallimento del fornitore, il fallimento dell'applicazione, la deriva dei costi e la deriva della qualità delle produzioni. Segnale Domanda che risponde Praticato primo allarme Cosa non può dimostrare Rate di errore delle richieste Le chiamate di modello falliscono? Rate su una finestra, suddivisa per fornitore e modello Se le chiamate di successo hanno avanzato il compito P50/p95 latenza Il tempo di risposta è diminuito? Confrontare operazioni e modelli simili Se una corsa lenta alla fine consegnato Token di input/output Il contesto o la generazione sono cresciuti? Cambiamento rispetto a una linea di base specifica per il compito Se i token extra sono stati utili Capacità di trasmissione Il carico sta cambiando? Richieste al minuto più simultanea Se una corsa programmata è stata mancata Punteggio di qualità La produzione del campione ha soddisfatto una rubrica? Valutatore di versione più calibrazione umana Se esiste un file, un biglietto o una distribuzione Copertura delle tracce Un operatore può ricostruire l'esecuzione? Tracce mancanti o incomplete per tempo di esecuzione Se il risultato previsto è presente Questa linea di base corrisponde all'intenzione di ricerca attuale. Langfuse descrive il monitoraggio attorno alla latenza, al throughput e ai tassi di errore, con tracce per i percorsi di esecuzione e la valutazione per la qualità dell'uscita. Splunk e Dynatrace espandono l'insieme a risorse, sicurezza, costi, feedback e segnali di applicazione. Si tratta di visioni utili di un'applicazione LLM; nessuna dovrebbe essere scartata semplicemente perché esiste uno strato agente. Le convenzioni semantiche GenAI di OpenTelemetry rendono la separazione visibile nella stessa strumentazione. La specifica di sviluppo definisce gen ai.client.token.usage e gen ai.client.operation.duration , quindi separando gli strumenti di flusso di lavoro e gli agenti come gen ai.invoke agent.duration , il conteggio delle chiamate di inferenza e il conteggio delle chiamate degli strumenti. L'evoluzione è importante qui: fissare la versione che si implemente e aspettarsi che i nomi cambiino. L'implementazione pulita è un libro dei modelli di chiamata con chiave run id , operation , provider , model e timestamp. Aggregalo per gli avvisi a livello di servizio, ma conserva un percorso di ritorno alla corsa individuale. Un token spike senza identificatore di corsa è una bolletta; un token spike attaccato a una corsa bloccata è un indizio di incidente. Aggiungere un libro maggiore di attività quando l'applicazione diventa un agente Una funzione supportata da LLM attraversa il confine operativo quando possiede un lavoro nel tempo. Può chiamare un database, scrivere un rapporto, aprire una richiesta di pull, aspettare una persona o svegliarsi in orario. A quel punto, le risposte modelli di successo sono solo eventi intermedi. L'OpenAI Agents SDK illustra quanto possano diventare ricchi questi eventi. Il suo tracciamento incorporato registra generazioni, chiamate di strumento di funzione, consegne, corridoi di guardia e esecuzione dell'agente. Questa è una preziosa prova di debug. La stessa documentazione osserva inoltre che gli intervalli di generazione e di funzione possono contenere input e output sensibili, il che è un motivo per rendere la cattura del contenuto una scelta esplicita piuttosto che un prerequisito di monitoraggio. Un libro dei compiti sanitari può rimanere più piccolo della traccia. Per ogni corsa, registrazione: expected outcome : un predicato come report exists and parses , non la frase finire il compito; outcome verified : true , false o unavailable , con versione verificatrice; progress delta : un cambiamento di conteggio o di digestione specifico per un'attività su una finestra dichiarata; waiting on : una dipendenza denominata come human approval o null ; last heartbeat at e last progress at , poiché attività e progresso sono orologi diversi; declared complete : quanto segnalato nel corso del periodo di esecuzione; collector freshness : quando questi fatti sono stati osservati per l'ultima volta. Questo libro più grande non ripete deliberatamente ogni istante, compimento o intervallo. Conserva il minimo di prove necessarie per decidere se la corsa sta funzionando, aspettando, bloccata, irraggiungibile o completa. Le tracce grezzi restano disponibili per l'indagine quando la politica lo consente. L'importante scelta di modellazione è la prova tri stato. Se un collezionista non riesce a verificare il consegnabile, registra outcome verified: "unavailable" . Non convertire le prove mancanti in true , e non chiamare una corsa sconosciuta fallita semplicemente perché il suo segnale è assente. Riproduci il divario con sei corse Il dispositivo di accompagnamento contiene sei corse sintetiche. L'allarme del libro maggiore LLM quando gli errori delle richieste sono almeno del 20%, la latenza p95 supera i 5.000 ms o l'uso dei token supera i 20.000. Il libro più grande della salute delle attività verifica l'esplicita attesa, il completamento dichiarato rispetto a un risultato deterministico e la freschezza del progresso. Eseguire l' audit con Node.js 20 o più recente: Il risultato esatto è: Il disaccordo è il risultato, non un difetto in entrambi i registri. L'errore del fornitore richiede un'indagine sul modello di servizio, anche se l'agente sta ancora facendo progressi. La corsa lenta è completata con un risultato verificato, quindi si tratta di un problema di prestazioni piuttosto che di un incidente di mancato lavoro. L'attesa di approvazione e il fallimento sembrano normali per il monitor LLM perché le loro chiamate erano rapide, economiche e di successo. Solo il contratto di attività espone ciò che richiede attenzione. I numeri sono un controesempio, non un punto di riferimento. Sei registrazioni sintetiche non possono stabilire soglie di allarme universali. Sostituisci i tagli con le linee di base del tuo runtime, e sostituisci progress delta con prove legate al lavoro effettivo. Trasformare il contratto di attività in avvisi Inizia con un flusso di lavoro di alto valore. Scrivi il suo predicato di completamento prima di aggiungere un'altra scheda. Un lavoro di ricerca potrebbe richiedere un file Markdown, almeno due fonti accessibili e un registro di prove valido per schema. Un lavoro di codifica potrebbe richiedere un patch pulito e un comando di prova di nome. Un agente di supporto potrebbe richiedere un biglietto creato o una registrazione dell'escalation. Poi valutate i segnali in un ordine che preservi il significato: 1. Se il tempo di corsa o il collezionista è obsoleto, segna che la corsa non è raggiungibile o incerta. 2. Se waiting on è esplicito, indirizzare la dipendenza invece di riavviare la corsa. 3. Se il tempo di esecuzione dichiara il completamento, valuta il predicato di risultato. 4. Se la corsa è attiva ma progress delta rimane zero oltre la sua finestra, segnala bloccata. 5. Se non si applica alcuna e il progresso utile è fresco, lascialo funzionare. Questo ordine impedisce tre interventi rumorosi. Un'attesa legittima di approvazione non è un stallo. Un comando che esce da zero non è automaticamente un compito completato. Una traccia occupata con strumenti ripetuti non è un progresso se l'artefatto rilevante non cambia mai. Avviso sulla prossima azione sicura, non solo il sintomo. Un avviso di errore del fornitore va al proprietario dell'applicazione con modello, operazione, classe di errore e collegamento tracciabile. Un'attesa di approvazione va alla persona che può decidere, con la portata esatta richiesta. Un avviso di risultato mancante indica il predicato fallito. Un ciclo di ripetizione raccomanda una pausa o un'indagine limitata; non dovrebbe autorizzare una correzione irreversibile. Mantenere la connessione utile senza raccogliere tutto Utilizzare una run id opaca su entrambi i registri. Non inserire nel documento il testo del cliente, segreti, percorsi assoluti o carichi utili di strumenti. Un utile registro di correlazione può contenere: Tenere diverse le regole di conservazione e di accesso se i rischi dei dati differiscono. La latenza aggregata e gli istogrammi di token possono richiedere una conservazione più lunga rispetto agli intervalli di portata del prompt. La prova del risultato può spesso essere un digesto, un numero, un codice di stato o un risultato di schema piuttosto che l'artefatto stesso. Quando un operatore fori in una traccia, mostrare la sua freschezza e il limite di campionamento in modo che l'assenza non sia confusa con la prova. C'è anche un limite per la valutazione automatizzata. I controlli deterministici sono preferibili per i file, lo stato HTTP, le righe di database, i test e i campi strutturati. Se il risultato previsto è qualitativo, un'evaluatore di versione può aiutare, ma il suo punteggio è una prova con incertezzanon una verità fondata. Calibralo contro la revisione umana e conserva uno stato unavailable . Dove si inserisce Sidewisp La direzione del prodotto di Sidewisp è il secondo libro maggiore: una visione della salute intorno ai tempi di esecuzione degli agenti esistenti, con prove, freschezza, priorità di emissione e confini espliciti di approvazione. Non è destinato a sostituire il runtime, il gateway modello o il sistema di tracciamento grezzo. Questa e' la direzione, non un'affermazione di monitoraggio spedito. Sidewisp è attualmente in anteprima privata. Il sito pubblico e il sistema di articoli sono in diretta, mentre la raccolta dell'agente di produzione sanità, gli adattatori di runtime e l'esecuzione del recupero non sono generalmente spediti. Unisciti all'anteprima privata se questo limite modello chiamata risultato corrisponde al problema operativo che devi risolvere. Fonti primarie OpenTelemetry GenAI metriche convenzioni semantiche nomi di metriche dello stato di sviluppo per le operazioni di client, flusso di lavoro, agente e strumento. Guida di tracciamento SDK OpenAI Agents tipi di eventi tracciati, comportamento di esportazione e controlli dei dati sensibili. Langfuse: Cos'è la osservabilità e il monitoraggio di LLM? un punto di riferimento della stessa intenzione per latenza, throughput, errori, tracciamento e valutazione.