Skip to main content
Failproof AI Observability cerca i guasti che non avete mai scritto una regola per rilevare e vi consegna una lista ordinata per priorità e supportata da prove di esattamente cosa correggere. È come avere un analista che setaccia i vostri log ogni notte e vi lascia la lista breve sulla scrivania al mattino.
Un tour di due minuti: da un’esecuzione programmata a una correzione su cui potete agire. La pagina Audits: processi ricorrenti che scansionano le vostre sessioni per modelli di guasto, ciascuno con una pianificazione e una sensibilità Ogni audit è un processo ricorrente che analizza le vostre sessioni e redige raccomandazioni ordinate per priorità e supportate da prove.

​
Smettete di indovinare cosa correggere dopo

Gli avvisi catturano i problemi che già sapete di dover monitorare. Gli audit catturano quelli che non sapete. Secondo una pianificazione che voi decidete, un audit legge tutte le vostre sessioni di agent e cerca i modelli che meritano di essere corretti, così potete dedicare il vostro tempo ad agire sui risultati invece di scorrere i log sperando di individuarli da soli. Una singola esecuzione va alla ricerca dei modi di guasto che effettivamente interrompono gli agent in produzione:
  • Cluster di errori: lo stesso guasto che si ripete con una causa radice condivisa.
  • Deviazione rispetto a una linea di base: comportamento che scivola silenziosamente via da una finestra nota come funzionante.
  • Guasto dell’obiettivo nei transcript: esecuzioni che tecnicamente si sono completate ma non hanno mai fatto il lavoro.
  • Uso errato dello strumento: lo strumento sbagliato, argomenti non validi o loop che consumano chiamate.
  • Compromessi tra qualità e costo: dove state pagando più del dovuto per output che potreste ottenere a minor costo.
  • Lacune di copertura: comportamento che nessun eval o avviso sta monitorando.
Voi decidete quanto rigorosamente cerca con una singola impostazione di sensibilità (bassa, media o alta), così un agent di staging rumoroso e uno di produzione bloccato possono essere sintonizzati ognuno sul segnale che volete.

​
Ogni raccomandazione viene con le prove

Non dovete mai accettare un risultato sulla base della fiducia. Ogni raccomandazione cita le sessioni esatte da cui proviene e l’SQL che l’ha fatta emergere, così potete aprire le prove e confermare il problema con un click invece di decifrare un’affermazione. Questo è anche ciò che mantiene gli audit onesti. Il server verifica che ogni sessione citata effettivamente esista e scarta qualsiasi raccomandazione le cui prove non resistono, così l’audit indaga ma non inventa mai. Quello che finisce sulla vostra lista è reale, riproducibile e ordinato per priorità in base a quanto importa, con i risultati più importanti in alto.

​
Trasformate una correzione in una guardrail

Correggere un problema è solo metà della vittoria. L’altra metà è assicurarsi che non possa tornare silenziosamente. Ogni risultato comporta un collegamento con un click che redige un avviso di ricorrenza, precompilato con un trigger di partenza ragionevole che potete sintonizzare. Chiudete il risultato, attivate l’avviso, e la prossima volta che quel modello riappare ricevete una notifica invece di riscoprirlo in un audit futuro.

​
Dove trovarlo

Gli audit si trovano nel dashboard su /<org-slug>/audits (barra laterale per analyze a audits). La visualizzazione di esecuzioni e risultati richiede audits:read; la creazione, la modifica e il triage degli audit richiedono audits:write. Impostate l’ambito e la cadenza di un audit, quindi fate clic su Run now quando volete risultati immediati invece di aspettare il prossimo passaggio programmato.

​
Correlati

  • Alerts: ricevete una notifica nel momento in cui una soglia che già conoscete viene superata.
  • Evaluations: assegnate un punteggio a ogni esecuzione così le regressioni di qualità emergono da sole.
  • Error tracking: raggruppate e monitorate gli errori che i vostri agent generano.
  • Incidents: tracciate un problema che un audit fa emergere fino alla sua correzione.