DeepEval Framework (2026 Edition)

Ciao, sono Alex di DEV STORIES DOT EU. DeepEval Framework, episodio 1 di 18. La maggior parte dei team valuta i propri language model appena deployati leggendo manualmente uno spreadsheet di risposte. È un processo lento, fortemente biased e impossibile da scalare man mano che un'applicazione cresce. DeepEval è il framework di valutazione open source che sostituisce questo lavoro manuale, funzionando di fatto come il Pytest per gli LLM. Supponiamo che il tuo team stia deployando una nuova applicazione generativa. Devi assicurarti che si comporti correttamente prima di pusharla in produzione. Con DeepEval, scrivi i test esattamente come scrivi i classici unit test in Python. Crei un file chiamato test example dot py. All'interno di questo file, costruisci un test case. Questo oggetto test case contiene il prompt di input iniziale, l'output effettivo generato dalla tua applicazione e le eventuali risposte target attese. Quindi applichi una metrica di valutazione a questo test case. Invece di utilizzare uno standard equality check per verificare se la variabile A corrisponde perfettamente alla variabile B, utilizzi una funzione di assertion specializzata fornita dal framework. Esegui questo file dalla tua command line utilizzando il comando standard Pytest. Il framework esegue i test in parallelo, intercetta le assertion e riporta i pass e i fail direttamente nel tuo terminale. Ecco il punto chiave. I test deterministici standard non possono valutare la qualità o l'accuratezza del linguaggio umano. Se un utente chiede alla tua applicazione un riassunto di un documento, ci sono migliaia di modi corretti per scriverlo. I pattern regex e l'exact string matching qui sono inutili, perché non possono interpretare il significato semantico. DeepEval gestisce questa enorme variabilità utilizzando un concetto chiamato LLM-as-a-judge. Il framework utilizza un language model generalizzato e altamente capace per valutare gli output specifici della tua applicazione. Il judge model legge l'output della tua applicazione, lo confronta con i criteri rigorosi della metrica che hai selezionato e calcola uno score numerico. Ancora più importante, restituisce in output un risultato boolean che indica se lo score soddisfa la tua threshold predefinita, insieme a una reason in plain text che spiega esattamente perché ha assegnato quello score. Questo significa che un test fallito ti dà un contesto di debugging immediato. Quando progetti questi test case, devi scegliere tra due distinte modalità di valutazione. È facile confondere lo scope di queste modalità, quindi tracciamo una linea netta. La valutazione end-to-end guarda solo all'input iniziale e all'output finale. L'intera applicazione viene trattata come una black box. Fornisci un prompt, il sistema dà una risposta e il judge assegna uno score a quel testo finale. Ignora completamente come l'applicazione ha generato la risposta. La valutazione component-level è un approccio white-box. Invece di controllare solo la risposta finale, questa modalità traccia gli specifici step interni che la tua applicazione ha fatto per arrivarci. Se il tuo sistema cerca in un database per fare retrieve di documenti di contesto prima di generare il testo, un test component-level valuta quello specifico step di ricerca. Controlla se i documenti recuperati erano effettivamente rilevanti per il prompt dell'utente, in modo del tutto indipendente dalla risposta finale generata. Testi i meccanismi interni, non solo il prodotto finale. Puoi avere un sistema che passa un test end-to-end dando una risposta corretta, ma fallisce un test component-level perché ha preso quella risposta dal documento interno sbagliato. Valutare un language model non è più un esercizio di lettura soggettivo; è un pezzo rigido, automatizzato e ripetibile della tua pipeline di continuous integration. Grazie per aver ascoltato, happy coding a tutti!

Ciao, sono Alex di DEV STORIES DOT EU. DeepEval Framework, episodio 2 di 18. Non puoi misurare ciò che non hai definito. Se le tue valutazioni automatiche sembrano incoerenti, spesso il problema inizia prima ancora che la metrica venga eseguita. Probabilmente stai passando i componenti sbagliati del tuo prompt agli evaluation boundaries sbagliati. La soluzione è definire rigorosamente l'interazione con l'LLM usando il blueprint del test case LLM. Un test case LLM in DeepEval funge da unità atomica di valutazione. Ti obbliga a isolare una singola interazione specifica con il tuo sistema. Non passi log di conversazione completi o database grezzi a un evaluator. Al contrario, estrai esattamente cosa è entrato, cosa è uscito e quali dati di background sono stati coinvolti per un singolo turno. Le interazioni multi-turn hanno il loro blueprint specifico, ma il test case standard si concentra rigorosamente su una singola richiesta e risposta isolata. Ogni test case richiede due argomenti obbligatori. Il primo è l'input. Questa è la stringa esatta che un utente o un sistema ha inviato al modello. Il secondo è l'actual output. Questo è il testo che il tuo Large Language Model ha generato in risposta. Se non valuti nient'altro, devi fornire questi due parametri per misurare metriche di base come la toxicity o l'answer relevance. Prendi ad esempio un chatbot per l'assistenza clienti. L'input è un utente che chiede se può restituire un paio di scarpe usate dopo trentacinque giorni. L'actual output è il tuo modello che genera una risposta che nega il reso. Per valutare se quel rifiuto è effettivamente corretto, devi fornire una baseline truth. DeepEval ti offre due diversi parametri opzionali per questo. Questi sono l'expected output e il context. I developer li confondono costantemente. Il context è strettamente fattuale. Contiene la verità grezza e non formattata, come una stringa di testo della tua policy aziendale che stabilisce un limite rigoroso di trenta giorni per i rimborsi. L'expected output è molto più specifico. Detta il tono, la linguistica e la formattazione. Usi l'expected output quando vuoi che l'evaluator verifichi se il modello ha risposto con delle scuse cortesi e specifiche, anziché limitarsi a generare un rifiuto brusco. Il context fa da base per i fatti. L'expected output fa da base per lo stile e la formulazione esatta. Ecco il punto chiave. Il modo in cui costruisci il resto di questo test case cambia a seconda della tua architettura sottostante. Se stai valutando una pipeline di Retrieval-Augmented Generation, devi definire il retrieval context. Questo parametro accetta una lista di stringhe che rappresentano gli esatti chunk di documento che il tuo retriever ha estratto dal vector database. Non confonderlo con il parametro context standard. Il context è la verità ideale che inserisci in hardcode per il test. Il retrieval context è il dato reale che la tua pipeline ha effettivamente trovato in produzione. Gli evaluator confrontano i due per determinare se il tuo algoritmo di ricerca sta recuperando i documenti giusti. Se stai costruendo un agent anziché una pipeline standard, utilizzi il parametro tools called. Questo accetta una lista di oggetti o stringhe che rappresentano le funzioni specifiche che l'agent ha deciso di invocare durante questa interazione isolata, come ad esempio l'attivazione di un calcolatore di rimborsi interno. Fornire questo ti permette di valutare le decisioni di routing dell'agent insieme alla generazione del testo finale. L'affidabilità di una metrica automatizzata è interamente vincolata alla pulizia di questi parametri. Un evaluator non può mai penalizzare una hallucination se non fornisci il context fattuale rigoroso rispetto al quale controlla l'output. Grazie per l'ascolto, happy coding a tutti!

Ciao, sono Alex di DEV STORIES DOT EU. DeepEval Framework, episodio 3 di 18. Le metriche NLP tradizionali come BLEU e ROUGE sono pessime per valutare i moderni Large Language Models, ma fare il deploy di un essere umano per ogni singolo test run è impossibile. La soluzione per scalare la tua valutazione senza sacrificare la comprensione semantica è la potenza dell'LLM-as-a-Judge. Le metriche tradizionali cercano sovrapposizioni esatte di parole. Se il tuo modello restituisce in output un riassunto perfettamente accurato usando sinonimi diversi, una metrica basata sull'exact string matching gli assegnerà uno score basso perché non è in grado di capirne il significato. Usare un LLM come judge risolve questo problema. Legge l'output, elabora il context e valuta la semantica proprio come farebbe un revisore umano, ma a velocità di macchina. In DeepEval, una metrica valutata da un LLM esegue tre azioni specifiche. Primo, calcola uno score tra zero e uno. Zero è un fallimento totale, uno è perfetto. Secondo, confronta questo score con una threshold rigorosa che tu definisci. Se la tua threshold è zero virgola sette e il modello ottiene uno score di zero virgola sei, il test fallisce. Terzo, restituisce una reason. L'LLM valutatore genera una spiegazione testuale che descrive in dettaglio esattamente perché ha assegnato quello specifico score. Questo ti dice cosa è andato storto senza costringerti a leggere manualmente i raw log. DeepEval divide queste metriche in tre categorie. Le metriche RAG valutano le pipeline di Retrieval-Augmented Generation. Le metriche Agentic valutano gli agenti autonomi. Le custom metrics ti permettono di definire i tuoi criteri di valutazione da zero. Anche se i prompt sottostanti sono diversi, utilizzano tutte lo stesso meccanismo di judge. Quando scelgono una metrica, gli sviluppatori spesso confondono le metriche reference-based e quelle referenceless. Ecco il punto chiave. Le metriche reference-based richiedono una ground truth. Hanno bisogno di una risposta nota e corretta con cui fare il confronto, il che le rende molto efficaci durante le prime fasi di sviluppo e di testing. Le metriche referenceless non hanno bisogno di una ground truth. Valutano l'output basandosi esclusivamente sul context fornito o sul prompt di input stesso. Dato che non si basano su una risposta pre-scritta, le metriche referenceless sono esattamente ciò che usi per il monitoraggio live in produzione. È allettante attaccare una dozzina di metriche a ogni prompt per garantire la qualità. Non farlo. La regola generale è usare meno di cinque metriche per applicazione. Scegli le metriche che si allineano davvero con la tua specifica business logic. Far girare metriche inutili si traduce solo in test più lenti e costi di compute più alti. A proposito di costi, usare un modello commerciale flagship per fare da judge a migliaia di test run giornalieri diventa costoso in fretta. DeepEval ti permette di sostituire l'evaluator di default con modelli custom. Puoi configurare il framework per usare Azure OpenAI se la tua infrastruttura enterprise lo richiede. In alternativa, puoi fare il setup di un modello locale usando Ollama. Facendo girare un modello open-source capace in locale sul tuo hardware, crei un judge gratuito e imparziale. Ti basta inizializzare il tuo client Ollama locale e passare quell'oggetto model direttamente nella configurazione della metrica. DeepEval poi gestisce il resto, eseguendo l'intera evaluation pipeline senza chiamare API di billing esterne. Il vero valore di un LLM judge non è solo lo score numerico, ma il reasoning automatico che fornisce per aiutarti a fare debug di ogni singolo fallimento. Grazie per aver ascoltato, happy coding a tutti!

Ciao, sono Alex di DEV STORIES DOT EU. DeepEval Framework, episodio 4 di 18. Un conto è se la tua pipeline RAG risponde a una domanda. Un altro è se inventa con sicurezza dettagli che non esistono nei tuoi documenti di origine. Oggi vediamo come valutare i generator RAG, e in particolare come intercettare esattamente questi errori. Una pipeline di Retrieval-Augmented Generation ha due componenti distinti. Il retriever recupera i documenti rilevanti. Il generator prende quei documenti e scrive la risposta finale. Oggi ignoreremo il retriever. Diamo per scontato che il tuo sistema abbia già recuperato i documenti giusti. Il nostro focus è strettamente sul generator che sintetizza il testo. Per assicurarti che questo testo sia sia sicuro che utile, ti affidi a due metriche: Faithfulness e Answer Relevancy. La prima metrica è la Faithfulness. Questo è il tuo guardrail principale contro le allucinazioni. La Faithfulness misura se la risposta del generator, che DeepEval chiama actual output, può essere interamente giustificata dal retrieval context. Prendi uno scenario standard. Un utente chiede al tuo chatbot informazioni sul piano sanitario aziendale. Il retriever recupera il manuale delle risorse umane corretto. Il generator risponde che il piano copre le spese mediche, oculistiche e una copertura odontoiatrica completa. Tuttavia, il manuale delle risorse umane non menziona mai la copertura odontoiatrica. Il generator ha sintetizzato una bugia altamente plausibile e ben formattata. La metrica di Faithfulness intercetta esattamente questo comportamento. Isola le affermazioni fatte nell'actual output e le verifica pezzo per pezzo rispetto al retrieval context. Se il generator include fatti mancanti dal contesto, il punteggio di Faithfulness scende. Non importa se il fatto è casualmente vero nel mondo reale. Se non è esplicitamente supportato dal contesto fornito, la metrica lo segnala come un fallimento. Ora, il secondo elemento è la Answer Relevancy. Una risposta fedele non è necessariamente una risposta utile. Il generator potrebbe produrre un riassunto perfettamente accurato del manuale delle risorse umane che ignora completamente ciò che l'utente ha effettivamente chiesto. La Answer Relevancy misura quanto bene l'actual output risponda direttamente all'input originale. Valuta se la risposta è completa, concisa e priva di divagazioni inutili. Se l'utente chiede l'importo della franchigia, e il generator elenca la franchigia ma poi aggiunge tre paragrafi sulla storia dell'assicurazione sanitaria aziendale, il punteggio di Answer Relevancy diminuisce. Il sistema penalizza le informazioni evasive o ridondanti con la stessa severità di quelle mancanti. Per valutare queste metriche, costruisci un test case in DeepEval. Devi fornire tre variabili. Primo, l'input, che rappresenta il prompt dell'utente. Secondo, l'actual output, ovvero il testo prodotto dal tuo generator. Terzo, il retrieval context, che contiene il testo grezzo dei documenti che il tuo retriever ha passato al generator. Passi questo test case a entrambe le metriche. DeepEval valuta il testo e calcola un punteggio tra zero e uno per ciascuna. Definisci una soglia di superamento. Se una risposta ottiene zero virgola nove in Faithfulness ma zero virgola quattro in Answer Relevancy, sai che il generator è sicuro ma inutile. Se i punteggi sono invertiti, il tuo generator è utile ma sta attivamente allucinando. Ecco il punto chiave. Quando valuti i generator, devi separare sistematicamente la verità dal contesto. Un generator di successo non dice la verità assoluta; dice esattamente ciò che i documenti forniti gli permettono di dire, rispondendo solo a ciò che è stato chiesto, e niente di più. Grazie per aver ascoltato, happy coding a tutti!

Ciao, sono Alex di DEV STORIES DOT EU. DeepEval Framework, episodio 5 di 18. Se il tuo LLM fornisce risposte scadenti, potrebbe non essere colpa del modello. Il tuo retriever potrebbe semplicemente dargli in pasto spazzatura. Oggi parliamo di come valutare i retriever RAG, in particolare usando Contextual Precision, Contextual Recall e Contextual Relevancy. Immagina di fare una query su una grande knowledge base per un dettaglio molto specifico di una policy. Invece di estrarre l'unico paragrafo esatto che ti serve davvero, il tuo retriever recupera dieci pagine di testo vagamente correlato. L'LLM si perde nel rumore, i costi dei token salgono e la risposta finale ne risente. Per risolvere questo problema, devi misurare lo step di retrieval in modo completamente separato dallo step di generazione. La prima misurazione è la Contextual Relevancy. Questa metrica analizza i chunk di testo grezzi che il tuo retriever estrae dal database e calcola il rapporto tra frasi rilevanti e frasi totali. Se recuperi mille parole solo per catturare una frase utile, il tuo punteggio di relevancy crolla. Una relevancy alta significa che stai passando un context pulito e denso al prompt dell'LLM, senza sprecare token in informazioni di background irrilevanti. Poi c'è la Contextual Recall. Questa valuta se il tuo retriever ha trovato tutte le informazioni necessarie per rispondere alla query dell'utente. DeepEval la calcola prendendo l'expected output di una query ed estraendo da esso tutte le affermazioni fattuali. Poi scansiona il context recuperato per vedere se quelle specifiche affermazioni sono effettivamente presenti. Se un fatto cruciale necessario per la risposta manca nel context, il punteggio di recall scende. Una recall alta garantisce che l'LLM abbia effettivamente il materiale grezzo che gli serve per avere successo. Poi abbiamo la Contextual Precision. Spesso le persone confondono la precision con la recall. Recall significa che non ti sei perso nulla. Precision significa che non hai incluso fuffa. Nelle valutazioni RAG, la precision tiene molto conto del ranking. Verifica se i chunk di context altamente rilevanti compaiono in cima alla lista recuperata. Se l'unico paragrafo vitale è sepolto in decima posizione sotto nove chunk inutili, il tuo punteggio di precision è basso. I modelli linguistici in genere prestano più attenzione alla parte superiore del prompt, quindi l'ordine di retrieval cambia completamente il risultato. Ecco il punto chiave. C'è una tensione costante tra precision e recall. Se configuri il tuo retriever per restituire cinquanta chunk ogni volta, la tua recall sarà probabilmente perfetta perché hai gettato una rete enorme. Ma la tua precision e la tua relevancy crolleranno perché la maggior parte di quei cinquanta chunk è rumore. Al contrario, se limiti il retriever a un solo chunk, la tua relevancy sarà impeccabile, ma la tua recall fallirà nel momento in cui una query dell'utente richiede di sintetizzare due fatti diversi da due documenti diversi. Per eseguire questi test nel framework, definisci un oggetto test case. Questo oggetto contiene l'input dell'utente, l'expected output e una lista delle stringhe di context effettive che il tuo retriever ha recuperato dal database. Crei un'istanza della metrica specifica che desideri, come ad esempio una metrica di Contextual Recall, e le passi il test case. Il framework usa quindi un modello di valutazione sotto il cofano per leggere le stringhe, mappare le affermazioni, calcolare una penalità per le informazioni mancanti o con un ranking basso, e restituire un punteggio numerico finale tra zero e uno. Valutare il tuo retriever ti costringe a confrontarti esattamente con ciò che stai passando al tuo modello di generazione. Una pipeline RAG ad alte prestazioni non si limita a buttare dati addosso a un LLM; filtra e fa il ranking di quei dati in modo spietato. Grazie per l'ascolto, happy coding a tutti!

Ciao, sono Alex di DEV STORIES DOT EU. DeepEval Framework, episodio 6 di 18. Valutare una singola risposta testuale è semplice, confronti l'output finale con l'input. Ma come valuti un agent autonomo che decide i propri step, fa dei loop tra vari processi di pensiero e attiva dei tool esterni? Se la risposta finale è corretta, ma l'agent ha fatto venti step inutili e ha chiamato il database sbagliato per arrivarci, il tuo sistema è rotto. Per risolvere questo problema serve la Agentic Evaluation. Dobbiamo separare una semplice API call da un flow di un agent autonomo multi-step. L'integrazione standard di un language model segue un percorso predefinito. Invii un prompt e il modello ti restituisce una string. Un agentic flow sposta il controllo sul modello. Il modello riceve un obiettivo ampio e decide in autonomia quali tool interni usare, in che ordine, e quali argomenti passargli. Se valuti un agent guardando solo il suo output testuale finale, ti perdi i meccanismi reali del suo ragionamento. DeepEval risolve questo problema usando la metrica di Task Completion. Invece di fare il parsing della string di risposta finale, la metrica di Task Completion analizza la execution trace dell'agent. Una trace è la registrazione completa e sequenziale di ogni pensiero, azione e invocazione di un tool fatta dall'agent durante una specifica run. La metrica di Task Completion legge questa trace per determinare se l'agent ha effettivamente soddisfatto la richiesta dell'utente tramite azioni valide. Considera un agent per pianificare viaggi. Un utente gli chiede di prenotare un weekend a Roma con le prenotazioni per la cena. Per farcela, l'agent deve invocare correttamente un tool per cercare ristoranti, e poi passare quei dati a un tool per generare itinerari. Se l'agent restituisce in output un itinerario formattato alla perfezione ma non ha mai effettivamente eseguito il tool per cercare ristoranti, una metrica di valutazione testuale standard probabilmente lo farà passare. L'output sembra molto convincente. La metrica di Task Completion lo farà fallire. Analizzando la trace, la metrica vede che manca l'esecuzione del tool necessario. L'agent ha allucinato i dati del ristorante invece di recuperarli, e la trace lo dimostra. Questo sposta la valutazione dall'output finale agli step operativi. Devi anche valutare se i tool sono stati usati correttamente. I test case di DeepEval gestiscono questa cosa usando un parametro chiamato tools called. Quando costruisci un test case di valutazione, passi la lista dei tool che l'agent ha invocato durante la sua esecuzione in questo parametro tools called. Fornire questi dati permette al framework di valutare la Tool Correctness. La valutazione verifica se l'agent ha selezionato i tool appropriati per l'obiettivo specifico, se ha fornito i giusti argomenti di input a quei tool, e se ha elaborato con successo i dati restituiti dai tool. Se il tuo agent per pianificare viaggi ha deciso correttamente di usare il tool per cercare ristoranti, ma ha passato la città di Parigi invece di Roma come argomento, la valutazione di Tool Correctness intercetta l'errore nell'esatto punto di fallimento. Sai esattamente quale step ha rotto la chain. Ecco il punto chiave. Valutare gli agent significa entrare nella black box. Stai verificando l'integrità del processo di ragionamento dell'agent e delle sue azioni meccaniche step by step. Una risposta finale strutturalmente perfetta è completamente inutile se l'agent l'ha raggiunta bypassando i tool, con dati allucinati e una logica rotta. Grazie per l'ascolto, happy coding a tutti!

Ciao, sono Alex di DEV STORIES DOT EU. DeepEval Framework, episodio 7 di 18. Un chatbot potrebbe dare un'ottima prima risposta, ma dimenticare completamente lo user intent o la propria persona al terzo turn. Ecco perché utilizziamo la Multi-Turn Conversation Evaluation. Valutare risposte isolate è facile, ma gli utenti reali non inviano prompt isolati. Fanno domande di follow-up, cambiano idea e fanno riferimento a cose dette cinque minuti prima. I metodi di valutazione standard falliscono in questo caso perché considerano un singolo input e un singolo output. Non hanno alcun concetto di tempo o memoria. Per testare come un modello gestisce un dialogo in corso, hai bisogno di una struttura che catturi l'intero thread. Nel framework, lo gestisci con un oggetto specifico chiamato ConversationalTestCase. Invece di prendere una string di input e una string di output, accetta un parametro chiamato turns. Il parametro turns è una lista sequenziale. Ogni elemento in questa lista rappresenta un singolo scambio botta e risposta tra l'utente e il sistema. Ordini questi scambi dal primo all'ultimo messaggio. Wrappare la sequenza in un ConversationalTestCase dice al motore di valutazione di trattare l'intera lista come un'unica interazione continua e stateful. C'è una trappola comune qui. Non passare un ConversationalTestCase a metriche standard, non conversazionali. Le metriche standard sono costruite per output singoli. Se le usi su un oggetto multi-turn, ignoreranno completamente il contesto storico. Devi usare metriche conversazionali dedicate per valutare la lista dei turns. Le metriche conversazionali valutano la conversazione nel suo complesso. Prendono in considerazione il contesto precedente per giudicare il comportamento continuativo del modello. Due esempi principali sono la Role Adherence e la Knowledge Retention. Considera un chatbot di customer support esplicitamente istruito a comportarsi come un pirata. Nel turn uno, l'utente saluta e il bot risponde con gergo piratesco. Nel turn due, l'utente fa una domanda e il bot rimane nel personaggio. Ma arrivati al turn tre, quando l'utente chiede di un rimborso, il bot risponde con delle scuse aziendali standard. È completamente uscito dal personaggio. Puoi intercettare questo fallimento automaticamente usando la metrica di Role Adherence. Definisci la persona target nel setup della metrica, e questa valuta l'intera conversazione per verificare che il modello non sia mai uscito dal personaggio, anche quando il contesto è diventato più lungo. La Knowledge Retention risolve un problema diverso. Se un utente fornisce un numero di conto nel primo turn, e chiede un aggiornamento di stato nel quarto turn, il bot non dovrebbe chiedere di nuovo il numero di conto. La metrica di Knowledge Retention scansiona la lista dei turns per assicurarsi che il modello recuperi e applichi con successo i fatti introdotti in precedenza nella chat history. Implementarlo nel codice richiede solo pochi passaggi. Per prima cosa, crei i tuoi singoli turns, mappando l'input dell'utente all'output del modello per ogni step del dialogo. Successivamente, passi quell'intera sequenza a un nuovo ConversationalTestCase. Poi, fai il setup della tua metrica conversazionale, assegnando criteri come la persona attesa. Infine, esegui la metrica sul tuo test case. Il framework elabora l'intera history e restituisce un punteggio basato sull'interazione cumulativa. Ecco il concetto chiave. La valutazione multi-turn sposta il tuo testing dalla misurazione dell'accuratezza tecnica isolata alla misurazione della coerenza comportamentale continuativa nel tempo. Grazie per l'ascolto, buon coding a tutti!

Ciao, sono Alex di DEV STORIES DOT EU. DeepEval Framework, episodio 8 di 18. A volte le metriche standard non si adattano al tuo use case, come ad esempio verificare se un chatbot finanziario altamente regolamentato suona sufficientemente professionale. Hai bisogno di un modo per misurare in modo affidabile le caratteristiche soggettive, ed è proprio qui che entra in gioco la creazione di metriche custom con G-Eval. Prima di definire delle metriche custom, stabilisci che tipo di logica stai misurando. G-Eval è progettato esclusivamente per criteri soggettivi, come tono, coerenza o fluidità della conversazione. Se devi imporre una logica oggettiva rigorosa, dovresti usare i DAG. G-Eval gestisce le sfumature del linguaggio umano. Per creare una metrica di professionalità per un chatbot finanziario, non scrivi complesse regole di parsing. Usi G-Eval per definire una metrica custom usando il linguaggio di tutti i giorni. Istanzi la metrica assegnandole un nome e una stringa di criteri in linguaggio naturale. Per questo chatbot, i tuoi criteri potrebbero dire di determinare se l'actual output mantiene un tono formale e rispettoso ed evita rigorosamente gergo o espressioni informali. Ecco il punto chiave. La metrica non si limita a inviare i tuoi criteri a un Large Language Model chiedendo un punteggio immediato. G-Eval esegue un algoritmo di Chain of Thought a due step. Lo step uno è la generation. L'algoritmo legge i tuoi criteri in plain English e genera automaticamente un elenco strutturato di step di valutazione. Scrive la sua stessa grading rubric. Per la metrica di professionalità, potrebbe generare uno step per scansionare i saluti informali e un altro step per verificare l'uso di una terminologia finanziaria appropriata. Lo step due è la valutazione vera e propria. L'algoritmo prende quegli step generati e li applica ai parametri specifici del tuo test case. Un test case standard di G-Eval include in genere lo user input e l'actual output del tuo modello, ma puoi includere anche l'expected output o il retrieval context. Il valutatore esegue la sua rubrica custom sul testo, calcola un punteggio finale compreso tra zero e uno e fornisce una motivazione dettagliata che spiega perché ha detratto dei punti. Scrivere criteri efficaci determina la qualità della tua metrica. Tratta la stringa dei criteri come un prompt altamente vincolato. Non scrivere istruzioni vaghe come "verifica se la risposta è buona". Definisci esattamente cosa significa "buona". Se l'uso di gergo deve comportare un punteggio automatico di zero, specificalo esplicitamente nei criteri. Gli step di valutazione generati nello step uno sono precisi solo quanto le istruzioni che fornisci. Questo copre le singole interazioni. Le conversazioni presentano una sfida diversa. Un chatbot potrebbe iniziare con un tono professionale ma adottare un tono informale al quarto messaggio. Per gestire questa situazione, usi Conversational G-Eval. Conversational G-Eval applica lo stesso identico algoritmo a due step a una chat multi-turn. La differenza sta nel formato dell'input. Invece di valutare un singolo input e actual output, passi un'intera conversation history. Questa history è composta da turni sequenziali che si alternano tra l'utente e l'assistente. La metrica legge l'intera trascrizione, genera i suoi step di valutazione in base ai tuoi criteri custom e assegna un punteggio all'interazione nel suo complesso. Questo garantisce che l'output del modello rimanga coerente dal primo saluto alla chiusura finale. L'efficacia di qualsiasi metrica custom dipende interamente dal trattare i tuoi criteri come una specifica rigorosa, dove la chiarezza batte sempre la brevità. Grazie per l'ascolto, happy coding a tutti!

Ciao, sono Alex di DEV STORIES DOT EU. DeepEval Framework, episodio 9 di 18. Quando valuti regole di formattazione complesse, un singolo prompt denso può facilmente indurre il tuo LLM valutatore ad allucinare il punteggio. Potrebbe vedere le parole giuste nel testo, ignorare completamente l'ordine strutturale e assegnare un voto sufficiente a un test fallito. La soluzione a questo problema è la valutazione deterministica con DAG. DAG sta per Directed Acyclic Graph. In questo framework, una metrica DAG ti permette di costruire un albero decisionale rigoroso che controlla come l'LLM valuta una risposta. Invece di chiedere a un modello di ingerire un testo e valutarlo in base a un enorme blocco di istruzioni, scomponi la logica in operazioni granulari, passo dopo passo. I dati fluiscono rigorosamente in un'unica direzione, dai root node all'inizio del tuo albero giù fino ai leaf node alla fine. Per costruire questo albero, ti basi su tre componenti distinti. Il primo è il Task Node. Un errore comune è trattarlo come un valutatore. Non lo è. Un Task Node si limita a estrarre o elaborare i dati dall'input o dalla risposta generata. Poi c'è il Binary Judgement Node. Questo nodo prende i dati elaborati dal Task Node e li valuta in base a criteri specifici, restituendo un rigoroso sì o no. Infine, c'è il Verdict Node. Questo funge da leaf node. Termina un ramo del tuo albero decisionale e produce in output un punteggio numerico finale insieme a una motivazione scritta. Applichiamo questo concetto a uno scenario concreto. Stai testando un LLM che genera riassunti delle trascrizioni delle riunioni. Il tuo requisito rigoroso è che ogni riassunto debba avere esattamente tre heading: Intro, Body e Conclusion, in quell'esatta sequenza. Inizi la tua metrica creando un root Task Node. Istruisci questo nodo a leggere il riassunto generato e a estrarre una lista di tutti gli heading che trova. Questo è il suo unico compito. Isola i dati di formattazione e passa una semplice lista di testo al livello successivo dell'albero. Ora, dai in pasto quella lista a un Binary Judgement Node. Definisci i criteri di questo nodo per verificare se la lista contiene esattamente tre elementi. Se il nodo valuta questo come false, instrada l'esecuzione giù verso un Verdict Node. Quel Verdict Node fallisce immediatamente il test, assegna un punteggio di zero e produce in output una motivazione che indica che il conteggio degli heading era errato. Se il Binary Judgement Node valuta come true, l'esecuzione passa a un secondo Binary Judgement Node. Questo nodo prende la stessa lista estratta e ne verifica la sequenza. Controlla se il primo elemento è Intro, il secondo è Body e il terzo è Conclusion. Se questo è true, instrada verso un Verdict Node finale che assegna un punteggio perfetto. Se false, instrada verso un Verdict Node diverso che assegna uno zero a causa di un fallimento nell'ordine. Questa è la parte che conta. Separando l'estrazione delle informazioni in un Task Node dalla logica di valutazione nei Judgement Node, forzi l'LLM a seguire un percorso rigido. Il modello gestisce l'estrazione semantica, mentre il tuo grafo garantisce l'esecuzione deterministica delle regole. Grazie per l'ascolto, happy coding a tutti!

Ciao, sono Alex di DEV STORIES DOT EU. DeepEval Framework, episodio 10 di 18. Testare un language model su cinque prompt manuali è carino. Ma quando aggiorni a una nuova versione del modello, quei cinque prompt non ti diranno se hai rotto degli edge case su centinaia di interazioni storiche. Per essere production-ready, hai bisogno di un repository di verità robusto e version-controlled. Questo è ciò che offre l'Evaluation Dataset. Un Evaluation Dataset in DeepEval è semplicemente una raccolta strutturata di elementi chiamati Golden. Prima di procedere, dobbiamo chiarire un equivoco comune. Gli sviluppatori spesso confondono un Golden con un Test Case. Non sono la stessa cosa. Un Golden è la riga grezza del dataset. Contiene i tuoi parametri di test statici, come lo user input, l'expected output e il retrieval context. Rappresenta lo scenario ideale. Un Golden diventa un Test Case solo in un secondo momento, a runtime, dopo che la tua applicazione live elabora l'input e inietta il suo output effettivo. Il Golden è il blueprint, mentre il Test Case è il risultato eseguito. Caliamo il tutto in uno scenario specifico. Hai un log storico di 500 query di customer support salvate in un file CSV. Vuoi testare rigorosamente una nuova versione del modello contro questo esatto set di query. Non hai bisogno di scrivere una logica di parsing custom. Ti basta inizializzare un Evaluation Dataset e usare il metodo built-in per aggiungere dati da un file CSV. Passi il file path e definisci un mapping. Dici al dataset quale colonna del CSV corrisponde allo user input, quale mappa all'expected output e quale contiene il context. Il framework gestisce il parsing e costruisce 500 Golden in memoria. Puoi fare esattamente la stessa cosa con un file JSON, mappando le chiavi JSON ai campi del Golden. Ecco il punto chiave. L'Evaluation Dataset controlla uno specifico lifecycle che fa da ponte tra i tuoi dati statici e la tua evaluation pipeline dinamica. Per prima cosa, carichi e salvi i tuoi Golden nel dataset. Poi, durante la tua test run, iteri attraverso il dataset. Estrai l'input da ogni Golden, lo passi al tuo language model live e catturi la risposta generata. Quindi alleghi quella risposta live al Golden e lo converti in un Test Case ufficiale. Infine, passi quel Test Case completo alle tue metriche per lo scoring. Questo mantiene i tuoi dati grezzi completamente separati dalla tua logica di esecuzione. Fino ad ora abbiamo descritto dataset single-turn. Uno user input, un expected output. Ma molte applicazioni includono interfacce di chat. Per questo, DeepEval supporta dataset multi-turn. Invece di una stringa di input piatta, un dataset multi-turn contiene una sequenza di interazioni. Un singolo Golden multi-turn contiene l'intera history della conversazione, tracciando come l'utente e il sistema interagiscono su più step. Questo permette alle tue metriche di valutare il flusso e la context retention di una conversazione, invece di isolare una singola risposta. Strutturare i tuoi dati in Evaluation Dataset formali garantisce che ogni modifica al prompt e ogni model swap vengano misurati contro uno standard storico rigoroso e invariabile. Grazie per l'ascolto, happy coding a tutti!

Ciao, questo è Alex di DEV STORIES DOT EU. DeepEval Framework, episodio 11 di 18. Il principale ostacolo alla valutazione dei large language models non è il framework di test che usi. È la mancanza di dati di test di alta qualità in partenza. Generare dati sintetici usando il DeepEval Synthesizer è il modo in cui aggiri questo ostacolo. Immagina una startup che sta sviluppando un bot HR interno. Devi eseguire immediatamente dei test per verificare che recuperi le policy corrette. Ma il bot è nuovo di zecca. Hai zero query log di utenti reali. Questo è il classico problema di cold-start per i dati di valutazione. Non puoi valutare un retrieval system senza una solida lista di domande realistiche da fargli. Il DeepEval Synthesizer fa il bootstrap di un dataset di valutazione direttamente dalla tua knowledge base grezza. Invece di scrivere centinaia di test case a mano, punti il tool verso i tuoi documenti sorgente. Il metodo principale per farlo si chiama generate goldens from docs. In DeepEval, un Golden è la terminologia per un singolo test case contenente un input, un expected output e un context. Per usarlo, per prima cosa inizializzi un oggetto Synthesizer. Poi, chiami il metodo generate goldens from docs e gli passi un array di percorsi dei documenti. Per il bot HR, questi sarebbero i file path dei tuoi manuali per i dipendenti, delle policy sui permessi e dei PDF sui benefit. Quando esegui questo metodo, il Synthesizer elabora i file e suddivide il testo in chunk gestibili. Usa poi un language model valutatore per comportarsi come un utente curioso. Il modello analizza un chunk specifico del manuale HR e genera una domanda pertinente e realistica basata esclusivamente su quel testo. Questa domanda viene salvata come input sintetico. Il Synthesizer salva anche l'esatto chunk di testo usato per ispirare la domanda. Questo diventa l'expected context. Infine, il modello formula la risposta ideale e fattuale alla domanda e la salva come expected output. Questa è la parte che conta. Le persone spesso fraintendono i limiti della generazione sintetica. Il Synthesizer crea solo gli input, l'expected context e l'expected output. Non genera l'actual output. Trovare l'actual output è compito della tua applicazione HR durante la fase di testing. Pensa al Synthesizer come a un insegnante che prepara un esame e crea le soluzioni. Il tuo bot deve comunque sostenere l'esame. Puoi controllare lo scope di questa generazione. Quando chiami il metodo, puoi specificare quanti test case generare per documento. Questo mantiene il processo rapido ed economico per iterazioni veloci, oppure puoi scalarlo per una copertura completa. Una volta terminato il metodo, estrai i golden generati e li salvi. Puoi esportare il dataset localmente come file JSON, o fare il push direttamente su Confident AI per tracciare le versioni del tuo dataset nel tempo. Fare il bootstrap di dataset sintetici ti permette di passare dall'aspettare che gli utenti reali espongano i difetti del tuo sistema, al testare sistematicamente i limiti assoluti della logica dei tuoi documenti fin dal primo giorno. Grazie per l'ascolto, happy coding a tutti!

Ciao, sono Alex di DEV STORIES DOT EU. DeepEval Framework, episodio 12 di 18. Le query sintetiche di base generate dai tuoi documenti sono troppo semplici. I moderni language model superano con facilità le domande semplici, lasciando pericolosi gap logici completamente non testati. Per trovare i veri breaking point nella tua applicazione, devi aumentare artificialmente la difficoltà dei tuoi dati di test. Otteniamo questo risultato usando la Evolving Synthetic Complexity. La generazione standard produce domande semplici e dirette. L'evoluzione complica matematicamente queste domande per fare uno stress-test del tuo sistema. A volte le persone lo confondono con l'alterazione dei fatti di base. Evolvere una query sintetica non significa cambiare la ground truth. I dati di origine rimangono esattamente gli stessi. Quello che cambia è la difficoltà strutturale della query che interroga quei dati. In DeepEval, controlli questo processo di mutazione usando la Evolution Config. Questa configurazione applica specifiche strategie evolutive per trasformare un prompt di base in un edge case a vincoli multipli. Prendi una semplice domanda sintetica come: qual è la policy di rimborso? È diretta, ma è troppo generica per essere un test rigoroso. La prima strategia che puoi applicare è la Concretizing evolution. Questa prende una query astratta e la forza in uno scenario tangibile e altamente specifico. Invece di chiedere la policy generale, la concretizzazione muta la query in qualcosa del tipo: se ho comprato una maglietta rossa martedì, posso avere un rimborso la prossima settimana? Il modello ora deve mappare i vincoli specifici dell'utente sulla regola generale. La seconda strategia è la Reasoning evolution. Questa introduce un livello di deduzione obbligatorio. La domanda evoluta costringe il modello a eseguire dei passaggi logici prima di poter fornire la risposta finale. Invece di fare un semplice retrieval di un dato, la query potrebbe richiedere al sistema di calcolare date, confrontare valori o seguire una chain logica condizionale basata sul testo sorgente prima di formare la sua risposta. La terza strategia è la Multicontext evolution. Questa testa il retrieval e la sintesi costringendo il modello a tirare fuori risposte da pezzi di informazione disgiunti. Modifica la query in modo che la risposta non possa essere estratta da un singolo paragrafo. Per avere successo, il language model deve combinare la tempistica generale per i rimborsi di un documento con le esclusioni specifiche per gli articoli in saldo da una sezione completamente diversa. Quando muti artificialmente migliaia di query usando queste strategie, alcune inevitabilmente degraderanno. Una domanda evoluta potrebbe diventare così contorta da risultare letteralmente impossibile da rispondere, oppure potrebbe allontanarsi dai fatti originali. Questo è l'esatto problema che la Filtration Config risolve. Non puoi permettere che del rumore irrisolvibile inquini il tuo dataset di valutazione. La Filtration impiega un critic model separato per agire da gatekeeper per il controllo qualità. Esamina ogni query appena evoluta confrontandola con criteri rigorosi prima che venga salvata. Se una domanda mutata è logicamente fallata, non è più allineata con il contesto sorgente, o degrada nel nonsense, il critic model la rifiuta in tronco. Questo processo in due fasi ti assicura di generare domande incredibilmente difficili, ma comunque del tutto valide. Un punteggio alto sui dati sintetici di base non dimostra nulla sulla resilienza del tuo sistema; la vera affidabilità di un modello si misura solo da come gestisce gli edge case complessi e intenzionalmente evoluti che la generazione standard si lascia alle spalle. Grazie per l'ascolto, happy coding a tutti!

Ciao, sono Alex di DEV STORIES DOT EU. DeepEval Framework, episodio 13 di 18. Le valutazioni end-to-end ti dicono se un sistema ha fallito, ma ti lasciano nel dubbio sul perché. Il tracing a livello di componente ti dice esattamente quale funzione specifica è andata in errore. Oggi parliamo di LLM Tracing e Observability. Considera una pipeline standard di Retrieval-Augmented Generation. Un utente fa una domanda complessa e il tuo sistema restituisce una risposta allucinata dieci secondi dopo. Devi sapere esattamente cosa è andato storto. La funzione di retrieval degli embedding ha estratto documenti irrilevanti dal tuo database, oppure lo step finale di generazione del language model non è riuscito a sintetizzare il contesto corretto? Non puoi fare debug in modo efficiente solo guardando l'output finale. Devi ispezionare gli step interni. Per farlo, devi capire due termini fondamentali che vengono spesso confusi: Trace e Span. Una Trace è l'intero albero di esecuzione di una singola operazione. Rappresenta la timeline completa dal momento in cui l'utente invia un prompt al momento in cui il sistema fornisce la risposta finale. Uno Span, d'altra parte, è un componente o una funzione specifica che opera all'interno di quella Trace. L'intera esecuzione della tua pipeline è una Trace. La funzione che interroga il vector database è uno Span. La funzione che formatta il prompt è un altro Span. La chiamata effettiva al Large Language Model è un terzo Span. Ogni Trace è costruita a partire da questi Span annidati. Ogni Span registra i propri start time, end time, parametri di input e risultati di output. In DeepEval, catturi questa gerarchia usando il decorator observe. Ti basta posizionare la parola observe con il simbolo della chiocciola direttamente sopra le funzioni Python che vuoi monitorare. Lo associ alla tua funzione di entry-point principale, e lo associ alle funzioni helper interne come il tuo retriever e il tuo generator. Quando la tua applicazione è in esecuzione, il decorator observe intercetta automaticamente l'esecuzione. Logga gli argomenti esatti passati alla funzione e i dati esatti restituiti. Traccia anche la latenza e gli eventuali errori che si verificano. Cosa ancora più importante, capisce l'execution context. Se la funzione principale della tua pipeline chiama la tua funzione di retriever, il decorator registra automaticamente il retriever come child Span della Trace principale. Mappa le relazioni parent-child delle tue funzioni senza che tu debba collegarle manualmente. Ecco il punto chiave. Il tracing in questo modo è completamente non intrusivo. Non devi riscrivere la codebase della tua applicazione per generare telemetria. Non devi alterare le signature delle tue funzioni per passare trace ID o context object lungo la call stack. Mantieni pulita la tua business logic e ti limiti a wrappare i componenti che ti interessano. Facendo così, isoli i dati per ogni singolo step. Se in seguito vuoi valutare solo la logica di retrieval, gli input e gli output esatti di quello specifico Span sono già loggati. Valuti end-to-end per misurare l'esperienza utente finale, ma fai tracing a livello di componente per localizzare e sistemare effettivamente il codice sottostante. Grazie per l'ascolto, happy coding a tutti!

Ciao, sono Alex di DEV STORIES DOT EU. DeepEval Framework, episodio 14 di 18. Nei workflow complessi degli agent autonomi, non sai sempre quale dovrebbe essere il test case finché l'agent non inizia effettivamente l'esecuzione. Non puoi scrivere una test suite statica completa per decisioni intermedie che non sono ancora state prese. Le eval dinamiche a runtime risolvono questa limitazione permettendoti di costruire e valutare i test case al volo. In genere, gli sviluppatori definiscono i test case statici esternamente. Crei un file con input rigidi e output attesi, e poi ci esegui sopra la tua applicazione. Questo approccio non funziona quando hai a che fare con sistemi autonomi. Quando un agent riceve un prompt, potrebbe instradare la query, selezionare un tool specializzato e generare la propria search string interna. Questi input e output intermedi non esistono finché il codice non è effettivamente in esecuzione. Le eval dinamiche abbandonano il file esterno. Al contrario, costruiscono il test case passo dopo passo man mano che le variabili vengono popolate all'interno dell'applicazione attiva. Considera uno scenario specifico. Devi valutare la context precision all'interno di una funzione retriever profondamente annidata. Vuoi testare solo quello specifico step al volo, isolato dall'output finale che vede l'utente. Per farlo, DeepEval fornisce due funzioni specifiche per intercettare i dati di esecuzione: update current span e update current trace. Una trace registra l'intero ciclo di vita di una richiesta, dall'input iniziale dell'utente alla risposta finale. Uno span rappresenta una specifica operazione all'interno di quella trace, come ad esempio la tua funzione retriever. Quando quella funzione retriever viene eseguita, le variabili dinamiche finalmente si materializzano. Ora hai l'esatta search string generata dall'agent e gli specifici chunk di testo restituiti dal tuo database. Proprio in questo momento, all'interno della logica del retriever, chiami update current span. Usi questa funzione per intercettare quelle variabili live e mapparle direttamente in un nuovo test case. Prendi la search string intercettata e la assegni come input del test. Prendi i chunk grezzi del database e li assegni come retrieval context. Hai appena costruito un golden test case durante l'esecuzione. Dato che hai costruito questo golden dinamicamente all'interno dello span, puoi valutarlo immediatamente. Applichi la tua metrica di context precision direttamente lì. La metrica gira sui dati live, valuta lo step del retriever e associa quel punteggio direttamente allo span locale. Quando in seguito rivedi le tue trace, non vedi solo che è avvenuto un retrieval. Vedi una valutazione altamente mirata di quello specifico retrieval, basata sulle condizioni esatte di quella run. Questo copre gli step granulari. A volte, tuttavia, un'operazione annidata rivela qualcosa che modifica il contesto dell'intera richiesta. È qui che update current trace diventa necessario. Mentre update current span modifica lo step locale, update current trace permette a una funzione profondamente annidata di risalire e modificare il record di esecuzione globale. Se il tuo agent scopre informazioni al volo che cambiano completamente l'aspetto che dovrebbe avere la risposta finale, chiami update current trace per aggiornare l'expected output per l'intera run. Questo mantiene l'eval globale allineata con la realtà live e mutevole della logica di esecuzione. Ecco l'intuizione chiave. Spostare le eval dai file esterni all'albero di esecuzione a runtime trasforma il testing da un esercizio post-mortem a un meccanismo diagnostico live. Legando le metriche direttamente agli span durante la loro esecuzione, smetti di tirare a indovinare sul perché un agent multi-step abbia fallito e inizi a misurare esattamente quale handoff interno ha causato il fallimento. Grazie per l'ascolto, happy coding a tutti!

Ciao, sono Alex di DEV STORIES DOT EU. DeepEval Framework, episodio 15 di 18. Il tuo LLM potrebbe rispondere perfettamente a tutte le domande normali. Ma cosa succede quando un utente malintenzionato tenta attivamente di fare un jailbreak della tua applicazione per farle divulgare dati sensibili? Questo richiede un approccio completamente diverso, che ci porta a un'introduzione al Red Teaming. Per comprendere il Red Teaming, devi cambiare il modo in cui vedi il tuo sistema. La valutazione standard verifica la funzionalità. Misura se il tuo modello è utile, accurato e pertinente se utilizzato correttamente. Il Red Teaming testa la sicurezza, la safety e i guardrail. Richiede un cambio di mentalità: dal verificare la correttezza al simulare bad actor malevoli. Stai cercando attivamente di far fallire il modello. Prendiamo uno scenario comune. Se chiedi direttamente alla tua applicazione AI di restituire in output un profilo utente, i guardrail standard probabilmente lo intercetteranno. L'AI si rifiuta categoricamente di divulgare le Personal Identifiable Information, o PII. Una valutazione standard lo considera un successo. Ma un bad actor non lo chiederà direttamente. Potrebbe fare un prompt al modello utilizzando una specifica persona malevola, istruendo l'AI ad agire come un senior database administrator che esegue un override di emergenza del sistema. Improvvisamente, l'AI obbedisce e fa volontariamente il leak delle PII. Il red teaming è il processo sistematico per scoprire esattamente questi punti ciechi prima che arrivino in produzione. DeepEval struttura questo processo attorno a quattro componenti principali. Il primo componente sono le Vulnerabilità. Una vulnerabilità è la specifica debolezza, rischio o danno per cui stai testando. È il problema di fondo che vuoi prevenire. Nel nostro scenario di override di emergenza, la vulnerabilità è il leak di PII. Altre vulnerabilità potrebbero includere la generazione di output tossici, mostrare bias non autorizzati o offrire consigli pericolosi. Il secondo componente sono gli Attacchi Adversarial. Se la vulnerabilità è l'obiettivo, l'attacco è l'arma. Gli attacchi sono le tecniche o i mezzi specifici utilizzati per sfruttare una vulnerabilità. Adottare una persona fidata per ingannare l'AI è un tipo di attacco. Altri includono la prompt injection, dove istruzioni malevole vengono nascoste in un input normale, o jailbreak complessi progettati per bypassare completamente il safety training del modello. DeepEval separa la debolezza dalla tattica perché una singola vulnerabilità può essere esposta da molti tipi diversi di attacchi. Il terzo componente è il Target LLM System. Questa è l'applicazione effettiva che stai valutando. Non è solo il foundation model grezzo, ma la tua architettura specifica. Questo include i tuoi system prompt personalizzati, i tuoi meccanismi di retrieval e qualsiasi filtro di sicurezza esistente. Gli attacchi adversarial vengono eseguiti direttamente contro questo setup per vedere come si comporta il tuo prodotto reale sotto pressione. Il quarto componente sono le Metriche. Una volta eseguito un attacco contro il tuo target system per sondare una vulnerabilità, hai bisogno di un risultato quantificabile. Le metriche valutano la risposta del sistema. Determinano se l'attacco ha bypassato con successo i guardrail, o se il sistema ha rifiutato in modo sicuro la richiesta malevola. Una metrica assegna un punteggio all'interazione, dandoti un pass o fail concreto in base a quanto fosse effettivamente sicuro l'output. Ecco il punto chiave. Non puoi mettere in sicurezza un'applicazione AI semplicemente dimostrando che fa la cosa giusta quando glielo chiedi gentilmente; devi dimostrare sistematicamente che si rifiuta di fare la cosa sbagliata quando è sotto attacco. Grazie per l'ascolto, happy coding a tutti!

Ciao, sono Alex di DEV STORIES DOT EU. DeepEval Framework, episodio 16 di 18. Non dovresti essere costretto a digitare manualmente migliaia di input ingannevoli per trovare falle di sicurezza nella tua applicazione. Invece di pagare un team di sicurezza per cercare manualmente di violare il tuo sistema per settimane, puoi lasciare che un'IA attacchi autonomamente la tua IA. Oggi vediamo come eseguire degli adversarial attack. Per orchestrare un attacco LLM-on-LLM automatizzato, il motore di scansione ha bisogno di una linea di comunicazione diretta con la tua applicazione. Stabilisci questa connessione definendo una callback per il target model. È una funzione Python async che scrivi tu. Accetta un singolo argomento string, che è l'adversarial prompt generato dal motore di test, e deve restituire la response di tipo string dal tuo sistema. In uno scenario tipico con un modello OpenAI, definiresti questa funzione di callback async, prenderesti il parametro prompt in ingresso, lo passeresti al tuo client OpenAI, attenderesti la generazione con await e restituiresti il contenuto di testo finale. Questa callback fa da ponte. Il motore di red teaming non ha bisogno di conoscere la tua architettura interna, le tue API key o lo stato del database. Gli serve solo una funzione da poter colpire continuamente con input malevoli. Una volta che la tua callback è pronta, la passi alla funzione di red team. Questo è l'orchestratore principale che esegue la scansione. Per configurarlo, devi fornire due liste distinte: vulnerabilità e attacchi. È fondamentale capire la differenza tra i due. Le vulnerabilità sono i difetti strutturali specifici o i comportamenti dannosi che vuoi testare. Per esempio, se vuoi assicurarti che la tua applicazione non generi in output pregiudizi razziali o di genere, importi e passi la vulnerabilità Bias alla funzione di red team. Gli attacchi, d'altra parte, rappresentano la metodologia che il motore userà per cercare di esporre quella vulnerabilità. Per forzare il modello a produrre un'affermazione biased, potresti voler far usare al motore frasi ingannevoli o tecniche di jailbreak. Lo fai passando l'attacco Prompt Injection. Il motore ora genererà autonomamente prompt mirati e malevoli usando la prompt injection, progettati specificamente per bypassare i tuoi system prompt e triggerare la vulnerabilità Bias. Un punto di confusione comune durante questo setup è come vengono effettivamente valutati i risultati. Nella valutazione standard, passi un sacco di tempo a definire e fare il tuning di metriche specifiche. Quando esegui degli adversarial attack, non definire manualmente le metriche. Il framework gestisce tutto questo dietro le quinte. Mappa automaticamente la vulnerabilità che hai selezionato direttamente a una corrispondente metrica di valutazione interna. Dato che gli hai detto di testare il Bias, il motore esegue automaticamente un bias evaluator su ogni singola response restituita dalla callback del tuo target model. Dopo che la funzione di red team ha finito di inviare questi prompt generati e di valutare le response, produce in output un Risk Assessment completo. Questo assessment fornisce un'analisi chiara della scansione. Mostra esattamente quanti attacchi sono stati tentati, quali tecniche di attacco specifiche hanno violato con successo il tuo sistema e le esatte stringhe di input che hanno causato il fallimento. Ne esci con una lista concreta di input che il tuo sistema attualmente non è in grado di gestire. Ecco il punto chiave. La vera potenza di questo setup è il disaccoppiamento del metodo di attacco dalla vulnerabilità target, permettendoti di moltiplicare la tua copertura di sicurezza abbinando una singola falla come il bias a dozzine di vettori di attacco diversi contemporaneamente. Grazie per averci ascoltato, happy coding a tutti!

Ciao, sono Alex di DEV STORIES DOT EU. DeepEval Framework, episodio 17 di 18. Non faresti mai il merge di una pull request per del codice tradizionale senza prima eseguire i tuoi unit test. Eppure, i team fanno regolarmente il deploy di modelli linguistici non deterministici e sperano semplicemente che i nuovi prompt funzionino ancora. Se vuoi evitare che aggiornamenti sbagliati del modello rompano la produzione, hai bisogno di CI/CD e Continuous Evaluation. DeepEval tratta le valutazioni dei modelli linguistici esattamente come i test software standard, integrandosi direttamente con Pytest. Definisci una funzione di test, inizializzi le tue metriche di valutazione e fai un assert per verificare che la metrica passi. Valutare un modello su un singolo input è inutile, quindi devi validare le modifiche rispetto a un ampio batch di input di baseline approvati e di output attesi. Questo è il tuo golden dataset. Per iterare su questo dataset in modo efficiente, usi il decorator standard mark parametrize di Pytest. Carichi il tuo dataset, estrai i singoli test case e li passi al decorator. Quando la test suite viene eseguita, Pytest genera dinamicamente un'esecuzione del test separata per ogni singolo elemento nel tuo golden dataset. Ecco il punto chiave. Dato che il framework si integra strettamente con Pytest, gli sviluppatori spesso danno per scontato di poter semplicemente lanciare i comandi standard di Pytest nel terminale. Non farlo. Se lanci Pytest direttamente sui tuoi file di valutazione, ti imbatterai in errori imprevisti legati agli event loop asincroni e alla telemetry delle metriche mancante. Devi sempre usare la command line interface dedicata. Il comando corretto è deepeval test run seguito dal nome del tuo file Python. Questo wrapper gestisce il complesso setup asincrono richiesto dai modelli linguistici e garantisce che tutti i risultati dei test vengano catturati e loggati correttamente. Integrando questo comando nella tua deployment pipeline, ottieni una Continuous Evaluation. Considera un tipico setup con le GitHub Action. Configuri il workflow in modo che si attivi ogni volta che un ingegnere apre una pull request verso il main branch. L'action runner fa il checkout del repository, prepara l'ambiente Python ed esegue deepeval test run sullo script del tuo golden dataset. Il framework valuta il codice o il prompt appena modificato rispetto a ogni test case storico. Se uno sviluppatore altera un system prompt per rendere le risposte più concise, potrebbe accidentalmente istruire il modello a rimuovere gli avvisi di compliance obbligatori. Quando gira la pipeline di CI, la valutazione automatizzata rileva immediatamente questo contesto mancante. Se la nuova logica fa scendere il tuo punteggio di valutazione sotto la soglia definita su qualsiasi test case, l'assert fallisce. Lo script restituisce un exit code diverso da zero, la GitHub Action diventa immediatamente rossa e la pull request viene bloccata impedendo il merge. Questo controllo automatico di pre-deployment funge da rigoroso gatekeeper. Intercetta le regressioni automaticamente. Non devi più fare uno spot-check manuale degli output o aspettare che gli utenti si lamentino che un nuovo swap del modello ha rotto uno specifico edge case. La pipeline dimostra matematicamente se l'aggiornamento è sicuro per il deploy, rimuovendo completamente la soggettività umana dal processo di release. La Continuous Evaluation significa che smetti di trattare il prompt engineering come un azzardo operativo e inizi a trattarlo come una release software prevedibile, supportata da dati concreti. Grazie per l'ascolto, buon coding a tutti!

Ciao, sono Alex di DEV STORIES DOT EU. DeepEval Framework, episodio 18 di 18. Passi ore a fare tuning di un prompt in locale, ottieni un ottimo score di valutazione e rilasci il codice. Due settimane dopo, un altro engineer aggiorna il modello sottostante e improvvisamente l'applicazione fallisce su degli edge case che nessuno aveva tracciato. Eseguire le valutazioni in locale è solo metà del lavoro. Questo episodio illustra come scalare il testing e tracciare le regressioni nel tempo usando Confident AI. Innanzitutto, una distinzione necessaria. DeepEval è il framework open-source che fai girare nel tuo terminale o nel tuo environment Python per eseguire i test. Confident AI è la piattaforma cloud hosted costruita su di esso. Usi DeepEval per definire le tue metriche e lanciare le valutazioni vere e proprie. Usi Confident AI per centralizzare, tracciare e analizzare quei report di valutazione in tutta l'organizzazione engineering. Prende degli script locali isolati e li trasforma in un system of record collaborativo. Passare dall'esecuzione in locale al logging in cloud richiede un semplice passaggio. Nel tuo terminale, esegui il comando deepeval login. La CLI ti mostrerà un prompt per inserire una API key generata dal tuo workspace di Confident AI. Una volta effettuata l'autenticazione, il tuo workflow quotidiano rimane esattamente lo stesso. Lanci i tuoi file di test usando il comando di test standard. Il framework rileva automaticamente la sessione attiva e fa lo stream dei risultati direttamente sulla dashboard in cloud, continuando a stamparli in locale. Centralizzare i report ti sblocca la possibilità di tracciare le regressioni in modo metodico. Una regressione si verifica quando una modifica al codice o alla configurazione degrada inavvertitamente le performance del sistema. Per diagnosticare perché si è verificata una regressione, devi tracciare esattamente cosa è cambiato tra le test run. Questo si fa loggando gli iperparametri. Nel contesto delle valutazioni dei modelli linguistici, un iperparametro è qualsiasi variabile che modifica il comportamento della tua pipeline. Questo include l'architettura del modello, il setting della temperature, la chunk size usata per il retrieval, o persino la versione specifica del prompt template. Quando configuri DeepEval per loggare questi iperparametri, vengono allegati a ogni test run inviata a Confident AI. Prendi ad esempio un team che cerca di fare l'upgrade della propria applicazione. Vogliono sapere se passare da GPT-4o a Claude 3.5 Sonnet migliora effettivamente lo score complessivo della loro pipeline. Configurano il nome del modello come iperparametro tracciato. Quando l'engineer lancia la suite di valutazione usando il nuovo modello, Confident AI logga il nuovo nome del modello insieme agli score risultanti per metriche come la contextual precision o la factual consistency. Ecco il punto chiave. Dato che tutte le test run storiche sono salvate in cloud, il team può visualizzare una timeline che confronta gli esatti cambiamenti degli iperparametri con gli score di valutazione aggregati. Se passare al nuovo modello aumenta la answer relevancy ma fa crollare drasticamente la factual consistency, la dashboard evidenzia questa regressione all'istante. Tutti nel team vedono gli stessi dati. Non devi mai fare il parsing di vecchi output della console o affidarti alla memoria per decidere se un cambio di configurazione è stato un successo. La continuous evaluation richiede una baseline storica. Senza un sistema centralizzato che colleghi le tue configurazioni direttamente ai tuoi score di valutazione, stai semplicemente lanciando esperimenti isolati, non stai facendo engineering di un sistema affidabile. Questo conclude la nostra serie sul framework DeepEval. Ti incoraggio vivamente a esplorare la documentazione ufficiale e a provare a costruire queste valutazioni hands-on. Se hai argomenti tecnici che vorresti vedere trattati in una serie futura, visita devstories dot eu per lasciare un suggerimento. Grazie per l'ascolto, e buon coding a tutti!