Monitorare la deriva della produzione LLM senza raccogliere tutto

Cosa copre la ricerca e la documentazione

ProxyDrift, una prestampa dell'agosto 2026, studia come confrontare il traffico in tempo reale con i set di test utilizzando riepiloghi strutturati delle interazioni. Questi riepiloghi rappresentano l'accesso diretto alle interazioni grezze. La documentazione di LangSmith descrive il punteggio delle esecuzioni dal vivo e l'aggiunta di esempi ai set di test offline. Questi sono approcci diversi. Né dimostra che una configurazione di monitoraggio protegga la privacy o copra ogni tipo di richiesta dell’utente.

Prova: Rilevamento e recupero della deriva dei dati che preservano la privacy per applicazioni LLM su larga scala tramite rappresentazioni proxy [1]Valutazione LangSmith [2]

Osserva tre tipi di cambiamento

La deriva dell'input significa che le richieste sono cambiate. Gli utenti possono richiedere attività diverse, utilizzare nuove lingue o inviare documenti più lunghi. La deriva dei risultati significa che i risultati sono cambiati, ad esempio più errori o risposte più lente. La deriva della misurazione significa che il processo di punteggio è cambiato. Un nuovo giudice, una guida al punteggio o una regola di campionamento possono spostare i numeri. Registrare queste modifiche separatamente.

Un tasso di fallimento più elevato può significare che i compiti successivi sono più difficili. Ciò non significa sempre che il modello sia più debole. Una media invariata può anche nascondere un problema se le richieste più facili bilanciano quelle più difficili. Confronta i gruppi importanti per il tuo prodotto, ad esempio la lingua o il tipo di attività. Mostra il numero di esempi dietro ogni punteggio.

Tenere un registro di monitoraggio mirato

Rubrex consiglia di iniziare con la decisione che ciascun avviso dovrebbe supportare. Per indagare sul timeout di uno strumento, potrebbero essere necessari il nome dello strumento, l'ora, il tipo di errore e la versione del software. Potrebbe non essere necessario il messaggio utente completo. Per verificare se una risposta è vera, potresti aver bisogno del documento originale. Concordare chi può accedere a tali dati e quando devono essere eliminati.

Le etichette e le rappresentazioni basate sui numeri, come gli incorporamenti, possono comunque contenere informazioni sensibili. Controlla se rivelano dettagli privati ​​o possono essere collegati a una persona. Mantieni i dati utente in tempo reale fuori dagli esempi pubblici. Utilizza esempi fittizi o rimuovi dettagli sensibili quando spieghi un errore. I dati che sono stati trasformati non sono automaticamente sicuri da condividere.

Esempio: i documenti scansionati causano nuovi errori

Supponiamo che un assistente agli acquisti inizi a ricevere documenti scansionati dopo il lancio di una nuova integrazione. Il modello non è cambiato, ma il sistema ora fatica a estrarre il testo. Il vecchio set di test utilizza testo digitale pulito. Passa comunque, anche se gli utenti reali vedono più fallimenti.

Innanzitutto, conferma dove l'estrazione fallisce utilizzando gli esempi che puoi rivedere. Aggiungi i documenti scansionati a un gruppo di test separato, con testo di riferimento controllato. Quindi testa la fase di estrazione e la risposta finale. Una modifica tempestiva potrebbe non correggere il testo sorgente mancante. Verificare se i nuovi test rilevano il vero problema prima di fare affidamento su di essi come segnale di avvertimento.

Assegna ad ogni avviso un passaggio successivo

Nominare un proprietario per ogni segnalazione. Spiega perché la sua soglia è importante e cosa dovrebbe controllare prima il proprietario. Esamina i falsi allarmi e gli incidenti non rilevati dall'avviso. Quando un vero fallimento diventa un caso di test, registra da dove proviene, cosa dovrebbe accadere e quale versione del set di test lo contiene. Prendi nota dei cambiamenti nelle regole del traffico e del punteggio quando confronti i risultati vecchi e nuovi.

• Registrare le versioni dell'applicazione, del set di test, del giudice e del campionamento.
• Confronta la qualità all'interno di ciascun gruppo di lavoro e in generale.
• Esaminare un ampio campione insieme ai casi che attivano avvisi.
• Verifica regole di accesso e cancellazione dei dati grezzi e delle etichette derivate.

Rendi utile la dashboard durante un incidente

Il monitoraggio mostra come i segnali selezionati cambiano nel tempo. L'osservabilità ti aiuta a ricondurre un segnale a una richiesta, un'impostazione di sistema o una dipendenza. La valutazione verifica se il risultato ha soddisfatto le esigenze dell’utente. Rubrex consiglia di collegare questi record con un ID corsa. Conserva solo i dati necessari per l'indagine, secondo le regole sui dati concordate del prodotto.

Prova a seguire un avviso dall'inizio alla fine. Il team riesce a trovare i casi interessati e la versione del software? Qualcuno può trasformare il fallimento in un test che un altro ingegnere può eseguire nuovamente? Mostra i conteggi dei campioni, i risultati mancanti, gli errori gravi e le definizioni dei punteggi accanto a ciascuna tendenza. Dopo una correzione, eseguire nuovamente il test e verificare se il risultato è migliorato. Una dashboard è utile quando aiuta qualcuno a decidere cosa fare dopo.

Domande comuni