DeepEval Framework (2026 Edition)

Salut, sunt Alex de la DEV STORIES DOT EU. DeepEval Framework, episodul 1 din 18. Majoritatea echipelor își evaluează modelele de limbaj nou deployate citind manual un spreadsheet cu răspunsuri. Este un proces lent, puternic biasat și imposibil de scalat pe măsură ce o aplicație crește. DeepEval este framework-ul de evaluare open-source care înlocuiește această muncă manuală, funcționând practic ca un Pytest pentru LLM-uri. Să presupunem că echipa ta face deploy la o nouă aplicație generativă. Trebuie să te asiguri că se comportă corect înainte de a o pune în producție. Cu DeepEval, scrii teste exact așa cum scrii unit tests standard în Python. Creezi un fișier numit test example dot py. În interiorul acelui fișier, construiești un test case. Acest obiect de tip test case conține promptul de input inițial, outputul real generat de aplicația ta și orice răspunsuri target așteptate. Apoi aplici o metrică de evaluare acestui test case. În loc să folosești o verificare standard de egalitate pentru a vedea dacă variabila A se potrivește perfect cu variabila B, folosești o funcție de assertion specializată, oferită de framework. Rulezi acest fișier din command line folosind comanda standard Pytest. Framework-ul execută testele în paralel, prinde acele assertions și raportează ce a dat pass și ce a dat fail direct în terminalul tău. Iată ideea cheie. Testele deterministe standard nu pot evalua calitatea sau acuratețea limbajului uman. Dacă un utilizator cere aplicației tale un rezumat al unui document, există mii de moduri corecte de a scrie acel rezumat. Pattern-urile de regex și exact string matching-ul sunt inutile aici, deoarece nu pot interpreta sensul semantic. DeepEval gestionează această variabilitate masivă folosind un concept numit LLM-as-a-judge. Framework-ul folosește un model de limbaj generalizat, extrem de capabil, pentru a evalua outputurile specifice ale aplicației tale. Modelul judge citește outputul aplicației tale, îl compară cu criteriile stricte ale metricii pe care ai selectat-o și calculează un scor numeric. Mai important, returnează un rezultat boolean care indică dacă scorul atinge threshold-ul tău predefinit, alături de un motiv în plain text care explică exact de ce a acordat acel scor. Asta înseamnă că un test care dă fail îți oferă imediat context pentru debugging. Atunci când concepi aceste test cases, trebuie să alegi între două moduri distincte de evaluare. Este ușor să confunzi scope-ul acestor moduri, așa că hai să tragem o linie clară. Evaluarea end-to-end analizează doar inputul inițial și outputul final. Întreaga aplicație este tratată ca un black box. Oferi un prompt, sistemul dă un răspuns, iar modelul judge dă un scor acelui text final. Ignoră complet modul în care aplicația a generat răspunsul. Evaluarea la nivel de componentă este o abordare de tip white-box. În loc să verifice doar răspunsul final, acest mod urmărește pașii interni specifici pe care i-a parcurs aplicația ta pentru a ajunge acolo. Dacă sistemul tău caută într-o bază de date pentru a prelua documente de context înainte de a-și genera textul, un test la nivel de componentă evaluează acel pas specific de căutare. Verifică dacă documentele preluate au fost într-adevăr relevante pentru promptul utilizatorului, complet independent de răspunsul final generat. Testezi mecanismul intern, nu doar produsul final. Poți avea un sistem care trece un test end-to-end dând un răspuns corect, dar pică un test la nivel de componentă pentru că a extras acel răspuns din documentul intern greșit. Evaluarea unui model de limbaj nu mai este un exercițiu subiectiv de citire; este o piesă rigidă, automatizată și repetabilă din continuous integration pipeline-ul tău. Mulțumesc pentru audiție, happy coding tuturor!

Salut, sunt Alex de la DEV STORIES DOT EU. DeepEval Framework, episodul 2 din 18. Nu poți măsura ceea ce nu ai definit. Dacă evaluările automate par inconsistente, problema începe adesea înainte ca metrica să ruleze. Probabil că transmiți componentele greșite din promptul tău către limitele de evaluare greșite. Soluția este definirea strictă a interacțiunii cu LLM-ul folosind un LLM test case blueprint. Un LLM test case în DeepEval servește ca unitate atomică a evaluării. Te obligă să izolezi o singură interacțiune specifică cu sistemul tău. Nu transmiți loguri complete de conversație sau baze de date brute unui evaluator. În schimb, extragi exact ce a intrat, ce a ieșit și ce date de background au fost implicate pentru o singură rundă distinctă. Interacțiunile multi-turn au propriul lor blueprint specific, dar test case-ul standard se concentrează strict pe un singur request și response izolat. Fiecare test case necesită două argumente obligatorii. Primul este input-ul. Acesta este string-ul exact pe care un utilizator sau un sistem l-a trimis modelului. Al doilea este actual output. Acesta este textul generat de LLM-ul tău ca răspuns. Dacă nu evaluezi nimic altceva, trebuie să furnizezi acești doi parametri pentru a măsura metrici de bază, cum ar fi toxicitatea sau answer relevance. Gândește-te la un chatbot de customer support. Input-ul este un utilizator care întreabă dacă poate returna o pereche de pantofi purtați după treizeci și cinci de zile. Actual output-ul este modelul tău care generează un răspuns ce respinge returul. Pentru a evalua dacă această respingere este într-adevăr corectă, trebuie să furnizezi un baseline truth. DeepEval îți oferă doi parametri opționali diferiți pentru asta. Aceștia sunt expected output și context. Developerii le confundă constant. Contextul este strict factual. Conține adevărul brut, neformatat, ca un string de text din politica ta corporativă care stabilește o limită strictă de rambursare de treizeci de zile. Expected output este mult mai specific. Acesta dictează tonul, lingvistica și formatarea. Folosești expected output atunci când vrei ca evaluatorul să verifice dacă modelul a răspuns cu o scuză politicoasă și specifică, în loc să genereze doar o respingere tăioasă. Contextul ancorează faptele. Expected output ancorează stilul și formularea exactă. Iată ideea cheie. Modul în care construiești restul acestui test case se schimbă în funcție de arhitectura ta de bază. Dacă evaluezi un pipeline de Retrieval-Augmented Generation, trebuie să definești retrieval context. Acest parametru acceptă o listă de string-uri care reprezintă chunk-urile exacte de documente pe care retriever-ul tău le-a extras din vector database. Nu confunda asta cu parametrul context standard. Contextul este adevărul ideal pe care îl hardcodezi pentru test. Retrieval context reprezintă datele reale pe care pipeline-ul tău le-a găsit efectiv în producție. Evaluatorii compară cele două pentru a determina dacă algoritmul tău de căutare extrage documentele corecte. Dacă construiești un agent în loc de un pipeline standard, folosești parametrul tools called. Acesta acceptă o listă de obiecte sau string-uri care reprezintă funcțiile specifice pe care agentul a decis să le invoce în timpul acestei interacțiuni izolate, cum ar fi declanșarea unui calculator intern de rambursare. Furnizarea acestui lucru îți permite să evaluezi deciziile de agentic routing alături de generarea finală de text. Fiabilitatea unei metrici automate este în întregime legată de igiena acestor parametri. Un evaluator nu poate niciodată penaliza o halucinație dacă nu reușești să furnizezi contextul factual strict în raport cu care verifică output-ul. Mulțumesc pentru ascultare, happy coding tuturor!

Salut, sunt Alex de la DEV STORIES DOT EU. DeepEval Framework, episodul 3 din 18. Metricile NLP tradiționale, precum BLEU și ROUGE, sunt groaznice la evaluarea de Large Language Models moderne, dar să faci deploy la un om pentru fiecare test run este imposibil. Soluția pentru a-ți scala evaluarea fără a sacrifica înțelegerea semantică este puterea LLM-as-a-Judge. Metricile tradiționale caută suprapuneri exacte de cuvinte. Dacă modelul tău dă ca output un rezumat perfect precis folosind sinonime diferite, o metrică bazată pe exact string matching îi va da un scor mic, pentru că nu poate înțelege sensul. Folosirea unui LLM ca judge rezolvă această problemă. Citește output-ul, procesează contextul și evaluează semantica la fel cum ar face-o un reviewer uman, dar la viteza mașinii. În DeepEval, o metrică evaluată de un LLM execută trei acțiuni specifice. În primul rând, calculează un scor între zero și unu. Zero este un eșec complet, unu este perfect. În al doilea rând, compară acel scor cu un threshold strict pe care tu îl definești. Dacă threshold-ul tău este zero punct șapte, iar modelul obține zero punct șase, testul pică. În al treilea rând, returnează un motiv. LLM-ul evaluator generează o explicație text care detaliază exact de ce a atribuit acel scor specific. Asta îți spune ce a mers prost fără să te oblige să citești manual acele raw logs. DeepEval împarte aceste metrici în trei categorii. Metricile RAG evaluează pipeline-urile de retrieval-augmented generation. Metricile agentice evaluează agenții autonomi. Metricile custom te lasă să-ți definești propriile criterii de evaluare de la zero. Deși prompt-urile din spate pentru acestea diferă, toate folosesc același mecanism de judge. Când aleg o metrică, developerii confundă adesea metricile reference-based cu cele referenceless. Iată ideea cheie. Metricile reference-based necesită un ground truth. Au nevoie de un răspuns corect, cunoscut, cu care să facă o comparație, ceea ce le face extrem de eficiente în timpul fazelor incipiente de development și testing. Metricile referenceless nu au nevoie de un ground truth. Ele evaluează output-ul bazându-se în întregime pe contextul furnizat sau chiar pe input prompt. Pentru că nu se bazează pe un răspuns scris în prealabil, metricile referenceless sunt exact ceea ce folosești pentru monitorizarea în producție live. Este tentant să atașezi o duzină de metrici la fiecare prompt pentru a asigura calitatea. Nu face asta. Regula de bază este să folosești mai puțin de cinci metrici per aplicație. Alege metricile care se aliniază cu adevărat cu business logic-ul tău specific. Rularea de metrici inutile duce doar la teste mai lente și costuri de compute mai mari. Apropo de costuri, folosirea unui model comercial flagship ca judge pentru mii de test runs zilnice devine rapid costisitoare. DeepEval îți permite să schimbi evaluatorul default cu modele custom. Poți configura framework-ul să folosească Azure OpenAI dacă infrastructura ta enterprise o cere. Alternativ, poți seta un model local folosind Ollama. Rulând local un model open-source capabil pe propriul tău hardware, creezi un judge gratuit și imparțial. Pur și simplu îți inițializezi clientul local Ollama și pasezi acel model object direct în configurația metricii. DeepEval se ocupă apoi de restul, executând întregul evaluation pipeline fără să acceseze API-uri externe de billing. Adevărata valoare a unui LLM judge nu constă doar în scorul numeric, ci și în automated reasoning-ul pe care îl oferă pentru a te ajuta să faci debug la fiecare eroare în parte. Mulțumesc că m-ați ascultat, happy coding tuturor!

Salut, sunt Alex de la DEV STORIES DOT EU. DeepEval Framework, episodul 4 din 18. Una e dacă pipeline-ul tău RAG răspunde la o întrebare. Cu totul altă problemă e dacă inventează cu încredere detalii care nu există în documentele tale sursă. Astăzi ne uităm la evaluarea generatoarelor RAG, mai exact cum să prinzi fix acele erori. Un pipeline Retrieval-Augmented Generation are două componente distincte. Retriever-ul preia documentele relevante. Generatorul ia acele documente și scrie răspunsul final. Astăzi ignorăm retriever-ul. Presupunem că sistemul tău a extras deja documentele corecte. Ne concentrăm strict pe generatorul care sintetizează textul. Pentru a te asigura că acest text este și sigur, și util, te bazezi pe două metrici: Faithfulness și Answer Relevancy. Prima metrică este Faithfulness. Acesta este principalul tău guardrail împotriva halucinațiilor. Faithfulness măsoară dacă răspunsul generatorului, pe care DeepEval îl numește actual output, poate fi justificat în întregime de retrieval context. Ia în considerare un scenariu standard. Un user îți întreabă chatbot-ul despre planul de sănătate al companiei. Retriever-ul extrage manualul de HR corect. Generatorul răspunde că planul acoperă servicii medicale, oftalmologice și stomatologice complete. Totuși, manualul de HR nu menționează deloc acoperirea stomatologică. Generatorul a sintetizat o minciună foarte plauzibilă și bine formatată. Metrica de Faithfulness prinde exact acest comportament. Izolează afirmațiile făcute în actual output și le verifică bucată cu bucată în retrieval context. Dacă generatorul include fapte care lipsesc din context, scorul de Faithfulness scade. Nu contează dacă faptul respectiv este adevărat în lumea reală. Dacă nu este susținut explicit de contextul furnizat, metrica îl marchează ca un eșec. Acum, a doua componentă este Answer Relevancy. Un răspuns fidel nu este neapărat un răspuns util. Generatorul ar putea să dea ca output un rezumat perfect precis al manualului de HR, care ignoră complet ce a întrebat userul de fapt. Answer Relevancy măsoară cât de bine actual output-ul răspunde direct la input-ul inițial. Evaluează dacă răspunsul este complet, concis și fără divagații inutile. Dacă userul cere suma deductibilă, iar generatorul listează deductibila, dar apoi adaugă trei paragrafe despre istoria asigurării de sănătate a companiei, scorul de Answer Relevancy scade. Sistemul penalizează informația evazivă sau excesivă la fel de strict ca informația lipsă. Ca să evaluezi aceste metrici, construiești un test case în DeepEval. Trebuie să oferi trei variabile. În primul rând, input-ul, care reprezintă prompt-ul userului. În al doilea rând, actual output-ul, adică textul produs de generatorul tău. În al treilea rând, retrieval context-ul, care conține textul brut din documentele pe care retriever-ul tău le-a dat generatorului. Pasezi acest test case ambelor metrici. DeepEval evaluează textul și calculează un scor între zero și unu pentru fiecare. Tu definești un threshold de trecere. Dacă un răspuns obține un scor de zero virgulă nouă la Faithfulness, dar zero virgulă patru la Answer Relevancy, știi că generatorul este sigur, dar inutil. Dacă scorurile sunt inversate, generatorul tău este util, dar halucinează activ. Iată ideea cheie. Când evaluezi generatoarele, trebuie să decuplezi sistematic adevărul de context. Un generator de succes nu spune adevărul absolut; spune exact ce îi permit documentele furnizate să spună, răspunzând doar la ce a fost întrebat, și nimic mai mult. Mulțumesc pentru ascultare, happy coding tuturor!

Salut, sunt Alex de la DEV STORIES DOT EU. DeepEval Framework, episodul 5 din 18. Dacă LLM-ul tău oferă răspunsuri greșite, s-ar putea să nu fie vina modelului. Retriever-ul tău s-ar putea să-i dea doar gunoaie. Astăzi vorbim despre evaluarea retrieverelor RAG, în special folosind Contextual Precision, Contextual Recall și Contextual Relevancy. Gândește-te că faci un query într-o bază de cunoștințe uriașă pentru un detaliu foarte specific dintr-o politică. În loc să extragă exact acel singur paragraf de care ai de fapt nevoie, retriever-ul tău trage zece pagini de text care are doar o vagă legătură. LLM-ul se pierde în zgomot, costurile cu tokenii cresc, iar răspunsul final are de suferit. Pentru a repara asta, trebuie să măsori pasul de retrieval complet separat de pasul de generare. Prima măsurătoare este Contextual Relevancy. Această metrică se uită la chunk-urile brute de text pe care retriever-ul tău le trage din baza de date și calculează raportul dintre propozițiile relevante și totalul de propoziții. Dacă faci retrieve la o mie de cuvinte doar pentru a prinde o singură propoziție utilă, scorul tău de relevancy se prăbușește. Un relevancy ridicat înseamnă că trimiți un context curat și dens în promptul LLM-ului, fără să irosești tokeni pe informații de fundal irelevante. Urmează Contextual Recall. Asta evaluează dacă retriever-ul tău a găsit toate informațiile necesare pentru a răspunde la query-ul utilizatorului. DeepEval calculează asta luând output-ul așteptat pentru un query și extrăgând toate afirmațiile factuale din el. Apoi scanează contextul la care ai făcut retrieve pentru a vedea dacă acele afirmații specifice sunt de fapt prezente. Dacă un fapt crucial necesar pentru răspuns lipsește din context, scorul de recall scade. Un recall ridicat garantează că LLM-ul are într-adevăr materia primă de care are nevoie pentru a reuși. Apoi avem Contextual Precision. Oamenii confundă frecvent precision cu recall. Recall înseamnă că nu ai ratat nimic. Precision înseamnă că nu ai inclus informații inutile. În evaluările RAG, precision ține cont foarte mult de ranking. Verifică dacă chunk-urile de context extrem de relevante apar chiar în partea de sus a listei de retrieval. Dacă singurul paragraf vital este îngropat la poziția numărul zece sub nouă chunk-uri inutile, scorul tău de precision este scăzut. Modelele de limbaj acordă, în general, mai multă atenție părții de sus a promptului, așa că ordinea de retrieval schimbă complet rezultatul. Iată ideea cheie. Există o tensiune constantă între precision și recall. Dacă îți configurezi retriever-ul să returneze cincizeci de chunk-uri de fiecare dată, recall-ul tău va fi probabil perfect, pentru că arunci o plasă masivă. Dar precision-ul și relevancy-ul tău se vor prăbuși, deoarece majoritatea acelor cincizeci de chunk-uri sunt zgomot. În schimb, dacă restricționezi retriever-ul la exact un chunk, relevancy-ul tău este impecabil, dar recall-ul eșuează în momentul în care un query al utilizatorului necesită sintetizarea a două fapte diferite din două documente diferite. Pentru a rula aceste teste în framework, definești un obiect de tip test case. Acest obiect conține input-ul utilizatorului, output-ul așteptat și o listă a string-urilor de context reale pe care retriever-ul tău le-a adus din baza de date. Instanțiezi metrica specifică pe care o vrei, cum ar fi o metrică de Contextual Recall, și îi pasezi test case-ul. Framework-ul folosește apoi un model de evaluare în fundal pentru a citi string-urile, a mapa afirmațiile, a calcula o penalizare pentru informațiile lipsă sau cu un ranking slab și a returna un scor numeric final între zero și unu. Evaluarea retriever-ului te obligă să te confrunți exact cu ceea ce îi dai modelului tău de generare. Un pipeline RAG de înaltă performanță nu doar aruncă date către un LLM; el filtrează și face ranking pe acele date fără milă. Mulțumesc pentru audiție, happy coding tuturor!

Salut, sunt Alex de la DEV STORIES DOT EU. DeepEval Framework, episodul 6 din 18. Evaluarea unui singur text response este simplă, verifici output-ul final în raport cu input-ul. Dar cum evaluezi un agent autonom care își decide propriii pași, trece prin mai multe procese de reasoning și declanșează tool-uri externe? Dacă răspunsul final este corect, dar agentul a făcut douăzeci de pași inutili și a apelat baza de date greșită pentru a ajunge acolo, sistemul tău este stricat. Rezolvarea acestei probleme necesită Agentic Evaluation. Trebuie să separăm un simplu API call de un agent flow autonom, multi-step. O integrare standard de language model urmează o cale predefinită. Trimiți un prompt, iar modelul returnează un string. Un agentic flow transferă controlul către model. Modelul primește un obiectiv general și decide autonom ce tool-uri interne să folosească, în ce ordine și ce argumente să le transmită. Dacă evaluezi un agent doar uitându-te la text output-ul final, ratezi mecanica reală a reasoning-ului său. DeepEval rezolvă asta folosind metrica Task Completion. În loc să parseze string-ul de răspuns final, metrica Task Completion analizează execution trace-ul agentului. Un trace este înregistrarea completă și secvențială a fiecărui thought, action și tool invocation pe care agentul le-a făcut în timpul unui run specific. Metrica Task Completion citește acest trace pentru a determina dacă agentul a îndeplinit pe bune request-ul utilizatorului prin acțiuni valide. Gândește-te la un agent de planificare a călătoriilor. Un utilizator îi cere să rezerve un weekend la Roma cu rezervări pentru cină. Pentru a reuși, agentul trebuie să invoce corect un tool de restaurant finder, și apoi să paseze acele date către un tool de itinerary generator. Dacă agentul dă ca output un itinerariu perfect formatat, dar nu a executat niciodată tool-ul de restaurant finder, o metrică standard de evaluare a textului probabil îl va trece. Output-ul pare foarte convingător. Metrica Task Completion îl va pica. Analizând trace-ul, metrica observă că execuția necesară a tool-ului lipsește. Agentul a halucinat datele restaurantului în loc să le recupereze, iar trace-ul dovedește asta. Asta mută evaluarea de la output-ul final la pașii operaționali. De asemenea, trebuie să evaluezi dacă tool-urile au fost folosite corect. Test case-urile DeepEval gestionează asta folosind un parametru numit tools called. Când construiești un test case de evaluare, pasezi lista de tool-uri invocate de agent în timpul execuției sale în acest parametru tools called. Furnizarea acestor date permite framework-ului să evalueze Tool Correctness. Evaluarea verifică dacă agentul a selectat tool-urile adecvate pentru obiectivul specific, dacă a furnizat argumentele de input corecte acelor tool-uri și dacă a procesat cu succes datele returnate de tool-uri. Dacă agentul tău de planificare a călătoriilor a decis corect să folosească tool-ul de restaurant finder, dar a pasat orașul Paris în loc de Roma ca argument, evaluarea Tool Correctness detectează eroarea exact în punctul de eșec. Știi exact care pas a rupt chain-ul. Iată ideea cheie. Evaluarea agenților înseamnă să pășești în interiorul black box-ului. Verifici integritatea procesului de reasoning al agentului și acțiunile sale mecanice pas cu pas. Un răspuns final structural perfect este complet inutil dacă agentul a ajuns la el făcând bypass la tool-uri, cu date halucinate și logică stricată. Mulțumesc pentru audiție, happy coding tuturor!

Salut, sunt Alex de la DEV STORIES DOT EU. DeepEval Framework, episodul 7 din 18. Un chatbot ar putea oferi un prim răspuns excelent, dar să uite complet intenția utilizatorului sau propria persona până la al treilea turn. De aceea folosim evaluarea conversațiilor multi-turn. Evaluarea răspunsurilor izolate este ușoară, dar utilizatorii reali nu trimit prompt-uri izolate. Ei pun întrebări de follow-up, se răzgândesc și fac referire la lucruri pe care le-au spus acum cinci minute. Metodele standard de evaluare eșuează aici, deoarece se uită la un singur input și un singur output. Nu au conceptul de timp sau memorie. Pentru a testa modul în care un model gestionează un dialog continuu, ai nevoie de o structură care să captureze întregul thread. În framework, gestionezi acest lucru cu un obiect specific numit ConversationalTestCase. În loc să ia un singur input string și un singur output string, primește un parametru numit turns. Parametrul turns este o listă secvențială. Fiecare element din această listă reprezintă un singur schimb de replici între utilizator și sistem. Ordonezi aceste schimburi de la primul mesaj până la ultimul. Împachetarea secvenței într-un ConversationalTestCase îi spune motorului de evaluare să trateze întreaga listă ca pe o singură interacțiune continuă, stateful. Există o capcană frecventă aici. Nu pasa un ConversationalTestCase către metrici standard, non-conversaționale. Metricile standard sunt construite pentru output-uri individuale. Dacă le folosești pe un obiect multi-turn, vor ignora complet contextul istoric. Trebuie să folosești metrici conversaționale dedicate pentru a evalua lista de turns. Metricile conversaționale evaluează conversația în ansamblu. Acestea iau în considerare contextul anterior pentru a judeca comportamentul susținut al modelului. Două exemple principale sunt Role Adherence și Knowledge Retention. Ia în considerare un chatbot de customer support care este instruit explicit să se comporte ca un pirat. În primul turn, utilizatorul spune salut, iar botul răspunde cu argou de pirat. În al doilea turn, utilizatorul pune o întrebare, iar botul rămâne în caracter. Dar la al treilea turn, când utilizatorul întreabă despre un refund, botul răspunde cu o scuză corporate standard. A ieșit complet din caracter. Poți detecta automat această eroare folosind metrica Role Adherence. Definești persona țintă în configurarea metricii, iar aceasta evaluează întreaga conversație pentru a verifica dacă modelul nu a ieșit niciodată din caracter, chiar și pe măsură ce contextul a devenit mai lung. Knowledge Retention rezolvă o problemă diferită. Dacă un utilizator furnizează un număr de cont în primul turn și solicită un status update în al patrulea turn, botul nu ar trebui să solicite din nou numărul de cont. Metrica Knowledge Retention scanează lista de turns pentru a se asigura că modelul extrage și aplică cu succes faptele introduse anterior în istoricul chat-ului. Să construiești asta în cod necesită doar câțiva pași. Mai întâi, îți creezi turn-urile individuale, mapând input-ul utilizatorului la output-ul modelului pentru fiecare pas al dialogului. Apoi, pasezi întreaga secvență într-un nou ConversationalTestCase. Apoi, îți configurezi metrica conversațională, atribuind criterii precum persona așteptată. În cele din urmă, execuți metrica pe test case-ul tău. Framework-ul procesează istoricul complet și returnează un scor bazat pe interacțiunea cumulativă. Iată ideea principală. Evaluarea multi-turn îți mută testarea de la măsurarea acurateței tehnice izolate la măsurarea consistenței comportamentale susținute în timp. Mersi pentru audiție, spor la codat tuturor!

Salut, sunt Alex de la DEV STORIES DOT EU. DeepEval Framework, episodul 8 din 18. Uneori, metricile standard nu se potrivesc pentru use case-ul tău, cum ar fi verificarea dacă un chatbot financiar extrem de reglementat sună suficient de profesional. Ai nevoie de o modalitate de a măsura în mod fiabil trăsăturile subiective, iar exact aici intervine construirea de metrici custom cu G-Eval. Înainte de a defini metrici custom, stabilește ce fel de logică măsori. G-Eval este conceput exclusiv pentru criterii subiective, cum ar fi tonul, coerența sau fluxul conversațional. Dacă trebuie să aplici o logică obiectivă strictă, ar trebui să folosești DAG-uri. G-Eval gestionează nuanțele limbajului uman. Pentru a construi o metrică de Profesionalism pentru un chatbot financiar, nu scrii reguli complexe de parsing. Folosești G-Eval pentru a defini o metrică custom folosind limbajul cotidian. Instanțiezi metrica dându-i un nume și un string de criterii în limbaj natural. Pentru acest chatbot, criteriile tale ar putea spune, determină dacă output-ul real menține un ton formal, respectuos și evită strict argoul sau formularea casuală. Iată ideea cheie. Metrica nu se limitează doar să trimită criteriile tale către un Large Language Model și să solicite un scor rapid. G-Eval rulează un algoritm Chain of Thought în doi pași. Primul pas este generarea. Algoritmul citește criteriile tale în limba engleză simplă și generează automat o listă structurată de pași de evaluare. Își scrie propria grilă de evaluare. Pentru metrica de Profesionalism, ar putea genera un pas pentru a scana saluturile informale și un alt pas pentru a verifica utilizarea terminologiei financiare adecvate. Al doilea pas este evaluarea propriu-zisă. Algoritmul preia acei pași generați și îi aplică parametrilor specifici ai test case-ului tău. Un test case G-Eval standard include de obicei input-ul utilizatorului și output-ul real al modelului tău, dar poți include și expected output-ul sau retrieval context-ul. Evaluatorul rulează grila sa custom pe text, calculează un scor final între zero și unu și oferă un motiv detaliat care explică de ce a scăzut puncte. Scrierea unor criterii eficiente dictează calitatea metricii tale. Tratează string-ul de criterii ca pe un prompt extrem de constrâns. Nu scrie instrucțiuni vagi, cum ar fi verifică dacă răspunsul este bun. Definește exact ce înseamnă bun. Dacă utilizarea argoului ar trebui să aibă ca rezultat un scor automat de zero, menționează acest lucru explicit în criterii. Pașii de evaluare generați în primul pas sunt doar la fel de preciși ca instrucțiunile pe care le furnizezi. Asta acoperă interacțiunile individuale. Conversațiile prezintă o provocare diferită. Un chatbot ar putea începe profesional, dar să adopte un ton casual până la al patrulea mesaj. Pentru a gestiona asta, folosești Conversational G-Eval. Conversational G-Eval aplică exact același algoritm în doi pași unui chat multi-turn. Diferența constă în formatul de input. În loc să evaluezi un singur input și output real, transmiți un istoric complet al conversației. Acest istoric constă în turn-uri secvențiale care alternează între utilizator și asistent. Metrica citește întreaga transcriere, generează pașii de evaluare pe baza criteriilor tale custom și punctează interacțiunea în ansamblu. Asta asigură că output-ul modelului rămâne consistent de la primul salut până la încheierea finală. Eficacitatea oricărei metrici custom depinde în întregime de tratarea criteriilor tale ca pe o specificație riguroasă, unde claritatea învinge întotdeauna concizia. Mulțumesc pentru ascultare, spor la codat tuturor!

Salut, sunt Alex de la DEV STORIES DOT EU. DeepEval Framework, episodul 9 din 18. Atunci când evaluezi reguli complexe de formatare, un singur prompt dens poate face foarte ușor ca LLM-ul tău evaluator să halucineze scorul. S-ar putea să vadă cuvintele corecte în text, să ignore complet ordinea structurală și să dea o notă de trecere unui test care a picat. Soluția pentru asta este Evaluarea Deterministă cu DAG. DAG vine de la Directed Acyclic Graph. În acest framework, o metrică DAG îți permite să construiești un decision tree strict care controlează cum evaluează LLM-ul un răspuns. În loc să ceri unui model să ingereze un text și să-i dea un scor pe baza unui bloc masiv de instrucțiuni, spargi logica în operațiuni granulare, pas cu pas. Datele curg strict într-o singură direcție, de la root nodes de la începutul arborelui tău, până la leaf nodes de la final. Ca să construiești acest arbore, te bazezi pe trei componente distincte. Prima este Task Node. O greșeală comună e să-l tratezi ca pe un evaluator. Nu este. Un Task Node pur și simplu extrage sau procesează date din input sau din răspunsul generat. Următoarea este Binary Judgement Node. Acest nod ia datele procesate de Task Node și le evaluează pe baza unor criterii specifice, returnând un da sau nu strict. În final, există Verdict Node. Acesta acționează ca un leaf node. El termină o ramură a arborelui tău de decizie și dă ca output un scor numeric final, împreună cu un motiv scris. Hai să aplicăm asta la un scenariu concret. Testezi un LLM care generează rezumate pentru transcripturile unor ședințe. Cerința ta strictă e ca fiecare rezumat să aibă exact trei heading-uri: Intro, Body și Conclusion, exact în această secvență. Îți începi metrica prin crearea unui Task Node de tip root. Instruiești acest nod să citească rezumatul generat și să extragă o listă cu toate heading-urile pe care le găsește. Asta e toată treaba lui. Izolează datele de formatare și pasează o listă simplă de text către următorul nivel al arborelui. Acum, trimiți acea listă către un Binary Judgement Node. Definești criteriile pentru ca acest nod să verifice dacă lista conține exact trei elemente. Dacă nodul evaluează asta ca false, rutează execuția către un Verdict Node. Acel Verdict Node pică imediat testul, dă un scor de zero și dă ca output un motiv care spune că numărul de heading-uri a fost incorect. Dacă Binary Judgement Node evaluează ca true, execuția se mută la un al doilea Binary Judgement Node. Acest nod ia aceeași listă extrasă și verifică secvența. Verifică dacă primul element e Intro, al doilea e Body, iar al treilea e Conclusion. Dacă asta e true, rutează către un Verdict Node final, dând un scor perfect. Dacă e false, rutează către un alt Verdict Node, dând un scor de zero din cauza erorii de ordine. Asta e partea care contează. Prin separarea extragerii de informații într-un Task Node, față de logica de evaluare din Judgement Nodes, forțezi LLM-ul să urmeze o cale strictă. Modelul se ocupă de extragerea semantică, în timp ce graful tău garantează execuția deterministă a regulilor. Mulțumesc pentru ascultare, happy coding tuturor!

Salut, sunt Alex de la DEV STORIES DOT EU. DeepEval Framework, episodul 10 din 18. Să testezi un language model pe cinci prompturi manuale e drăguț. Dar când faci upgrade la o nouă versiune a modelului, acele cinci prompturi nu îți vor spune dacă ai stricat edge case-uri de-a lungul a sute de interacțiuni istorice. Ca să fii production-ready, ai nevoie de un repository of truth robust și version-controlled. Asta îți oferă un Evaluation Dataset. Un Evaluation Dataset în DeepEval este pur și simplu o colecție structurată de elemente numite Goldens. Înainte să mergem mai departe, trebuie să clarificăm o concepție greșită des întâlnită. Developerii confundă adesea un Golden cu un Test Case. Nu sunt același lucru. Un Golden este rândul raw din dataset. Conține parametrii tăi statici de testare, cum ar fi user input-ul, expected output-ul și retrieval context-ul. Reprezintă scenariul ideal. Un Golden devine un Test Case abia mai târziu, la runtime, după ce aplicația ta live procesează input-ul și injectează actual output-ul. Golden-ul este blueprint-ul, în timp ce Test Case-ul este rezultatul executat. Hai să luăm un scenariu specific. Ai un log istoric cu 500 de query-uri de customer support salvate într-un fișier CSV. Vrei să testezi riguros o nouă versiune a modelului pe acest set exact de query-uri. Nu trebuie să scrii o logică de parsing custom. Pur și simplu inițializezi un Evaluation Dataset și folosești metoda built-in pentru a adăuga date dintr-un fișier CSV. Pasezi file path-ul și definești un mapping. Îi spui dataset-ului care coloană CSV corespunde user input-ului, care se mapează la expected output și care conține context-ul. Framework-ul se ocupă de parsing și construiește 500 de Goldens în memorie. Poți face exact același lucru cu un fișier JSON, mapând cheile JSON la câmpurile din Golden. Iată key insight-ul. Evaluation Dataset-ul controlează un lifecycle specific care face legătura între datele tale statice și pipeline-ul tău dinamic de evaluare. Mai întâi, îți încarci și stochezi Golden-urile în dataset. Apoi, în timpul test run-ului, iterezi prin dataset. Extragi input-ul din fiecare Golden, îl trimiți către language model-ul tău live și capturezi răspunsul generat. Apoi atașezi acel răspuns live la Golden și îl convertești într-un Test Case oficial. La final, pasezi acel Test Case complet către metricile tale pentru scoring. Asta îți menține datele raw complet separate de execution logic. Până acum, am descris dataset-uri single-turn. Un user input, un expected output. Dar multe aplicații implică interfețe de chat. Pentru asta, DeepEval suportă dataset-uri multi-turn. În loc de un input string flat, un dataset multi-turn conține o secvență de interacțiuni. Un singur Golden multi-turn conține întregul istoric al conversației, urmărind modul în care userul și sistemul interacționează pe parcursul mai multor pași. Asta permite metricilor tale să evalueze flow-ul și context retention-ul unei conversații, în loc să izoleze un singur răspuns izolat. Structurarea datelor tale în Evaluation Datasets formale garantează că fiecare tweak la prompt și model swap este măsurat în raport cu un standard istoric strict și invariabil. Mulțumesc pentru audiție, happy coding tuturor!

Salut, sunt Alex de la DEV STORIES DOT EU. DeepEval Framework, episodul 11 din 18. Cel mai mare bottleneck în evaluarea de large language models nu este framework-ul de testare pe care îl folosești. Ci lipsa datelor de testare de înaltă calitate, încă de la bun început. Generarea de date sintetice folosind DeepEval Synthesizer este modul prin care poți ocoli acest blocaj. Gândește-te la un startup care construiește un bot de HR intern. Trebuie să rulezi teste imediat pentru a verifica dacă face retrieve la politicile corecte. Dar botul este complet nou. Nu ai deloc log-uri cu query-uri reale de la utilizatori. Aceasta este clasica problemă de cold-start pentru datele de evaluare. Nu poți evalua un sistem de retrieval fără o listă robustă de întrebări realiste pe care să i le pui. DeepEval Synthesizer face bootstrap la un dataset de evaluare direct din knowledge base-ul tău raw. În loc să scrii manual sute de test cases, îndrepți tool-ul către documentele tale sursă. Metoda principală pentru asta se numește generate goldens from docs. În DeepEval, un Golden este terminologia pentru un singur test case care conține un input, un expected output și un context. Ca să-l folosești, mai întâi inițializezi un obiect Synthesizer. Apoi, apelezi metoda generate goldens from docs și îi pasezi un array de path-uri către documente. Pentru botul de HR, acestea ar fi path-urile fișierelor pentru manualele angajaților, politicile de concediu și PDF-urile cu beneficii. Când rulezi această metodă, Synthesizer procesează fișierele și împarte textul în chunk-uri ușor de gestionat. Apoi folosește un language model cu rol de evaluator pentru a acționa ca un utilizator curios. Modelul analizează un anumit chunk din manualul de HR și generează o întrebare relevantă și realistă, bazată exclusiv pe acel text. Această întrebare este salvată ca synthetic input. Synthesizer salvează, de asemenea, exact chunk-ul de text folosit pentru a inspira întrebarea. Acesta devine expected context-ul. În cele din urmă, modelul formulează răspunsul ideal și factual la întrebare și îl salvează ca expected output. Asta este partea care contează. Oamenii înțeleg adesea greșit limitele generării sintetice. Synthesizer-ul creează doar input-urile, expected context-ul și expected output-ul. Nu generează actual output-ul. Găsirea actual output-ului este treaba propriei tale aplicații de HR în timpul fazei de testare. Gândește-te la Synthesizer ca la un profesor care scrie un examen și creează un barem de corectare. Botul tău tot trebuie să dea examenul. Poți controla scope-ul acestei generări. Când apelezi metoda, poți specifica câte test cases să genereze per document. Asta menține procesul rapid și ieftin pentru iterații rapide, sau îi poți face scale up pentru o acoperire completă. Odată ce metoda se termină, extragi Golden-urile generate și le salvezi. Poți exporta dataset-ul local ca fișier JSON, sau îi poți da push direct în Confident AI pentru a-ți urmări versiunile de dataset în timp. Bootstrapping-ul de dataset-uri sintetice îți permite să treci de la a aștepta ca utilizatorii reali să expună defectele din sistemul tău, la testarea sistematică a edge case-urilor absolute ale logicii documentelor tale încă din prima zi. Mulțumesc pentru audiție, spor la codat tuturor!

Salut, sunt Alex de la DEV STORIES DOT EU. DeepEval Framework, episodul 12 din 18. Query-urile sintetice de bază generate din documentele tale sunt prea ușoare. Modelele de limbaj moderne trec foarte ușor prin întrebările simple, lăsând lacune logice periculoase complet netestate. Pentru a găsi breaking points reale în aplicația ta, trebuie să crești artificial dificultatea datelor de testare. Facem asta folosind Evolving Synthetic Complexity. Generarea standard produce întrebări simple și directe. Evoluția complică matematic aceste întrebări pentru a face un stress-test sistemului tău. Lumea confundă uneori asta cu modificarea informațiilor de bază. Evoluția unui query sintetic nu înseamnă schimbarea ground truth-ului. Datele sursă rămân exact la fel. Ce se schimbă este dificultatea structurală a query-ului legat de acele date. În DeepEval, controlezi acest proces de mutație folosind Evolution Config. Această configurație aplică strategii evolutive specifice pentru a transforma un prompt de bază într-un edge case cu mai multe constrângeri. Ia o întrebare sintetică simplă, cum ar fi: care este politica de retur? Este directă, dar e prea generică pentru a fi un test riguros. Prima strategie pe care o poți aplica este evoluția de tip Concretizing. Aceasta preia un query abstract și îl forțează într-un scenariu extrem de specific, tangibil. În loc să întrebe despre politica generală, concretizarea transformă query-ul în ceva de genul: dacă am cumpărat o cămașă roșie marți, pot să o returnez săptămâna viitoare? Modelul trebuie acum să mapeze constrângerile specifice ale utilizatorului la regula generală. A doua strategie este evoluția de tip Reasoning. Aceasta introduce un nivel obligatoriu de deducție. Întrebarea evoluată obligă modelul să efectueze pași logici înainte de a putea oferi răspunsul final. În loc să extragă pur și simplu un fapt, query-ul ar putea cere sistemului să calculeze date calendaristice, să compare valori sau să urmeze un chain de logică condițională bazat pe textul sursă înainte de a-și forma răspunsul. A treia strategie este evoluția de tip Multicontext. Aceasta testează retrieval-ul și sinteza, forțând modelul să extragă răspunsuri din bucăți de informație disjuncte. Modifică query-ul astfel încât răspunsul să nu poată fi extras dintr-un singur paragraf. Pentru a reuși, modelul de limbaj trebuie să combine termenul general de retur dintr-un document cu excluderile specifice pentru articolele la lichidare dintr-o secțiune complet diferită. Când transformi artificial mii de query-uri folosind aceste strategii, unele se vor degrada inevitabil. O întrebare evoluată ar putea deveni atât de întortocheată încât să fie cu adevărat imposibil de răspuns la ea, sau s-ar putea îndepărta de faptele inițiale. Aceasta este exact problema pe care o rezolvă Filtration Config. Nu poți permite ca zgomotul imposibil de rezolvat să îți polueze dataset-ul de evaluare. Filtration folosește un critic model separat care acționează ca un gatekeeper de quality control. Acesta verifică fiecare query nou evoluat în funcție de criterii stricte înainte de a fi salvat. Dacă o întrebare transformată este invalidă logic, nu se mai aliniază cu contextul sursă sau se degradează în nonsens, critic model-ul o respinge complet. Acest proces în doi pași te asigură că generezi întrebări incredibil de dificile, dar totuși complet valide. Un scor mare pe date sintetice de bază nu dovedește nimic despre rezistența sistemului tău; adevărata fiabilitate a unui model este măsurată doar prin modul în care gestionează edge case-urile complexe, evoluate intenționat, pe care generarea standard le lasă în urmă. Mulțumesc pentru audiție, happy coding tuturor!

Salut, sunt Alex de la DEV STORIES DOT EU. DeepEval Framework, episodul 13 din 18. Evaluările end-to-end îți spun dacă un sistem a eșuat, dar te lasă să ghicești de ce. Tracing-ul la nivel de componentă îți spune exact ce funcție specifică a crăpat. Astăzi, ne uităm la LLM Tracing și Observability. Ia în considerare un pipeline standard de Retrieval-Augmented Generation. Un utilizator pune o întrebare complexă, iar sistemul tău returnează un răspuns halucinat zece secunde mai târziu. Trebuie să știi exact ce a mers prost. Funcția de embedding retrieval a extras documente irelevante din baza ta de date, sau pasul final de generare al modelului de limbaj pur și simplu nu a reușit să sintetizeze contextul corect? Nu poți face debug eficient la asta doar uitându-te la output-ul final. Trebuie să inspectezi pașii interni. Pentru a face asta, trebuie să înțelegi doi termeni fundamentali care sunt frecvent confundați: Traces și Spans. Un Trace este arborele complet de execuție al unei singure operațiuni. Reprezintă timeline-ul complet din momentul în care utilizatorul trimite un prompt până în momentul în care sistemul livrează răspunsul final. Un Span, pe de altă parte, este o componentă sau o funcție specifică ce operează în interiorul acelui Trace. Întreaga execuție a pipeline-ului tău este un singur Trace. Funcția care interoghează baza de date vectorială este un Span. Funcția care formatează promptul este un alt Span. Apelul propriu-zis către Large Language Model este un al treilea Span. Fiecare Trace este construit din aceste Span-uri nested. Fiecare Span își înregistrează propriul start time, end time, parametri de input și rezultate de output. În DeepEval, capturezi această ierarhie folosind decoratorul observe. Pur și simplu plasezi cuvântul observe cu un simbol arond direct deasupra funcțiilor Python pe care vrei să le monitorizezi. Îl atașezi la funcția ta principală de entry-point și îl atașezi la funcțiile interne de tip helper, cum ar fi retriever-ul și generatorul tău. Când aplicația ta rulează, decoratorul observe interceptează automat execuția. Loghează argumentele exacte pasate în funcție și datele exacte returnate. De asemenea, urmărește latency-ul și orice erori care apar. Mai important, înțelege contextul de execuție. Dacă funcția ta principală din pipeline apelează funcția de retriever, decoratorul înregistrează automat retriever-ul ca un child Span al Trace-ului principal. Acesta mapează relațiile de tip parent-child ale funcțiilor tale fără să fii nevoit să le legi manual. Iată ideea cheie. Tracing-ul în acest mod este complet non-intruziv. Nu trebuie să rescrii codebase-ul aplicației tale pentru a genera telemetry. Nu trebuie să modifici semnăturile funcțiilor pentru a pasa trace ID-uri sau obiecte de context în jos pe call stack. Îți păstrezi business logic-ul curat și doar faci wrap la componentele care te interesează. Făcând asta, izolezi datele pentru fiecare pas individual. Dacă vrei să evaluezi ulterior doar logica de retrieval, inputurile și outputurile exacte ale acelui Span specific sunt deja logate. Evaluezi end-to-end pentru a măsura experiența finală a utilizatorului, dar faci tracing la nivel de componentă pentru a localiza și repara efectiv codul din spate. Mulțumesc pentru audiție, happy coding tuturor!

Salut, sunt Alex de la DEV STORIES DOT EU. DeepEval Framework, episodul 14 din 18. În workflow-urile complexe cu agenți autonomi, nu știi întotdeauna care ar trebui să fie test case-ul până când agentul nu începe efectiv execuția. Nu poți scrie un test suite static cuprinzător pentru decizii intermediare care nu au fost încă luate. Dynamic Evals la runtime rezolvă această limitare permițându-ți să construiești și să evaluezi test case-urile din mers. De obicei, developerii definesc test case-urile statice extern. Creezi un fișier cu inputs rigide și outputs așteptate, apoi rulezi aplicația pe baza lor. Această abordare pică atunci când ai de-a face cu sisteme autonome. Când un agent primește un prompt, s-ar putea să ruteze query-ul, să selecteze un tool specializat și să genereze propriul său search string intern. Aceste inputs și outputs intermediare nu există până când codul nu rulează efectiv. Evaluările dinamice abandonează fișierul extern. În schimb, construiesc test case-ul pas cu pas, pe măsură ce variabilele se populează în interiorul aplicației active. Ia în considerare un scenariu țintit. Trebuie să evaluezi context precision în interiorul unei funcții retriever deeply nested. Vrei să testezi doar acel pas specific din mers, izolat de output-ul final pe care îl vede utilizatorul. Pentru a face asta, DeepEval oferă două funcții specifice pentru a intercepta datele de execuție: update current span și update current trace. Un trace înregistrează întregul ciclu de viață al unui request, de la input-ul inițial al utilizatorului până la răspunsul final. Un span reprezintă o operațiune specifică în interiorul acelui trace, cum ar fi funcția ta retriever. Când acea funcție retriever se execută, variabilele dinamice se materializează în sfârșit. Acum ai exact search string-ul generat de agent și chunk-urile de text specifice returnate de baza de date. Chiar în acest moment, în logica retriever-ului, apelezi update current span. Folosești această funcție pentru a intercepta acele variabile live și a le mapa direct într-un nou test case. Iei search string-ul interceptat și îl atribui ca test input. Iei chunk-urile brute din baza de date și le atribui ca retrieval context. Tocmai ai construit un golden test case în timpul execuției. Pentru că ai construit acest golden dinamic în interiorul span-ului, îl poți evalua imediat. Aplici metrica de context precision chiar acolo. Metrica rulează pe datele live, dă un scor pasului de retriever și atașează acel scor direct la span-ul local. Când îți revizuiești ulterior trace-urile, nu vezi doar că a avut loc un retrieval. Vezi o evaluare extrem de precisă a acelui retrieval specific, bazată pe condițiile exacte ale acelei rulări. Asta acoperă pașii granulari. Uneori, însă, o operațiune nested descoperă ceva care schimbă contextul întregului request. Aici devine necesar update current trace. În timp ce update current span modifică pasul local, update current trace permite unei funcții deeply nested să ajungă mai sus și să modifice înregistrarea globală de execuție. Dacă agentul tău descoperă informații din mers care schimbă complet cum ar trebui să arate răspunsul final, apelezi update current trace pentru a actualiza expected output-ul pentru întreaga rulare. Asta menține evaluarea globală aliniată cu realitatea live, în continuă schimbare, a logicii de execuție. Iată ideea de bază. Mutarea evaluărilor din fișiere externe în execution tree-ul de la runtime transformă testarea dintr-un exercițiu post-mortem într-un mecanism de diagnosticare live. Prin legarea directă a metricilor la span-uri pe măsură ce se execută, încetezi să mai ghicești de ce a eșuat un agent multi-step și începi să măsori exact ce handoff intern a cauzat eșecul. Mersi pentru ascultare, happy coding tuturor!

Salut, sunt Alex de la DEV STORIES DOT EU. DeepEval Framework, episodul 15 din 18. LLM-ul tău ar putea răspunde perfect la fiecare întrebare normală. Dar ce se întâmplă când un utilizator rău intenționat încearcă în mod activ să facă jailbreak aplicației tale pentru a o face să divulge date sensibile? Asta necesită o abordare complet diferită, ceea ce ne aduce la o Introducere în Red Teaming. Pentru a înțelege red teaming-ul, trebuie să schimbi modul în care privești sistemul tău. Evaluarea standard testează funcționalitatea. Măsoară dacă modelul tău este util, precis și relevant atunci când este utilizat corect. Red teaming-ul testează securitatea, siguranța și guardrails-urile. Necesită o schimbare de mentalitate de la verificarea corectitudinii la simularea actorilor rău intenționați. Încerci în mod activ să faci modelul să eșueze. Să luăm un scenariu comun. Dacă îi ceri direct aplicației tale AI să dea ca output un profil de utilizator, guardrails-urile standard probabil vor bloca asta. AI-ul refuză strict să divulge informațiile personale de identificare, sau PII. O evaluare standard marchează asta ca un succes. Dar un actor rău intenționat nu va cere asta direct. Ar putea să dea un prompt modelului folosind o persona specifică, rău intenționată, instruind AI-ul să acționeze ca un administrator senior de baze de date care face un override de sistem de urgență. Dintr-o dată, AI-ul se conformează și divulgă de bunăvoie PII-ul. Red teaming-ul este procesul sistematic de a descoperi exact aceste puncte oarbe înainte ca ele să ajungă în producție. DeepEval structurează acest proces în jurul a patru componente principale. Prima componentă sunt Vulnerabilitățile. O vulnerabilitate este slăbiciunea, riscul sau dauna specifică pe care o testezi. Este problema de bază pe care vrei să o previi. În scenariul nostru de override de urgență, vulnerabilitatea este divulgarea de PII. Alte vulnerabilități ar putea include generarea de output toxic, afișarea de bias neautorizat sau oferirea de sfaturi periculoase. A doua componentă sunt Atacurile Adversariale. Dacă vulnerabilitatea este ținta, atacul este arma. Atacurile sunt tehnicile sau mijloacele specifice utilizate pentru a exploata o vulnerabilitate. Adoptarea unei persona de încredere pentru a păcăli AI-ul este un tip de atac. Altele includ prompt injection, unde instrucțiunile rău intenționate sunt ascunse în input-ul obișnuit, sau jailbreak-uri complexe concepute pentru a ocoli complet antrenamentul de siguranță al modelului. DeepEval separă slăbiciunea de tactică, deoarece o singură vulnerabilitate poate fi expusă de multe tipuri diferite de atacuri. A treia componentă este Sistemul LLM țintă. Asta este aplicația reală pe care o evaluezi. Nu este vorba doar de foundation model-ul brut, ci de arhitectura ta specifică. Asta include system prompt-urile tale custom, mecanismele tale de retrieval și orice filtre de siguranță existente. Atacurile adversariale sunt executate direct împotriva acestui setup pentru a vedea cum performează produsul tău real sub presiune. A patra componentă sunt Metricile. Odată ce un atac este executat împotriva sistemului tău țintă pentru a detecta o vulnerabilitate, ai nevoie de un rezultat cuantificabil. Metricile evaluează răspunsul sistemului. Ele determină dacă atacul a făcut bypass cu succes la guardrails-uri, sau dacă sistemul a refuzat în siguranță solicitarea rău intenționată. O metrică evaluează interacțiunea, oferindu-ți un pass sau fail concret în funcție de cât de sigur a fost de fapt output-ul. Iată ideea cheie. Nu poți securiza o aplicație AI doar demonstrând că face ceea ce trebuie atunci când i se cere frumos; trebuie să demonstrezi sistematic că refuză să facă ceea ce nu trebuie atunci când este atacată. Mulțumesc pentru ascultare, spor la codat tuturor!

Salut, sunt Alex de la DEV STORIES DOT EU. DeepEval Framework, episodul 16 din 18. Nu ar trebui să fie nevoie să introduci manual mii de inputuri înșelătoare pentru a găsi vulnerabilități de securitate în aplicația ta. În loc să plătești o echipă de securitate ca să încerce manual să-ți spargă sistemul timp de săptămâni, poți lăsa un AI să-ți atace AI-ul în mod autonom. Astăzi, ne uităm la executarea de adversarial attacks. Pentru a orchestra un atac automat LLM-on-LLM, motorul de scanare are nevoie de o linie directă de comunicare cu aplicația ta. Stabilești această conexiune definind un callback pentru modelul target. Aceasta este o funcție Python async pe care o scrii tu. Preia un singur argument de tip string, care este adversarial prompt-ul generat de motorul de testare, și trebuie să returneze răspunsul de tip string de la sistemul tău. Într-un scenariu tipic în care folosești un model OpenAI, ai defini această funcție de callback async, ai lua parametrul prompt primit, l-ai transmite clientului tău OpenAI, ai da await generării și ai returna conținutul text final. Acest callback acționează ca o punte. Motorul de red teaming nu trebuie să știe despre arhitectura ta internă, API keys sau starea bazei de date. Are nevoie doar de o funcție pe care să o poată accesa continuu cu inputuri malițioase. Odată ce callback-ul tău este gata, îl transmiți funcției de red team. Acesta este principalul orchestrator care execută scanarea. Pentru a o configura, furnizezi două liste distincte: vulnerabilități și atacuri. Este crucial să înțelegi diferența dintre ele. Vulnerabilitățile sunt defectele structurale specifice sau comportamentele dăunătoare pe care vrei să le testezi. De exemplu, dacă vrei să te asiguri că aplicația ta nu generează prejudecăți rasiale sau de gen, imporți și transmiți vulnerabilitatea Bias funcției de red team. Atacurile, pe de altă parte, reprezintă metodologia pe care motorul o va utiliza pentru a încerca să expună acea vulnerabilitate. Pentru a forța modelul să facă o afirmație părtinitoare, este posibil să vrei ca motorul să utilizeze formulări înșelătoare sau tehnici de jailbreak. Faci acest lucru prin transmiterea atacului de tip Prompt Injection. Motorul va genera acum autonom prompturi direcționate, malițioase, folosind prompt injection, special concepute pentru a ocoli system prompts-urile tale și a declanșa vulnerabilitatea Bias. Un punct frecvent de confuzie în timpul acestei configurări este modul în care rezultatele sunt efectiv evaluate. În evaluarea standard, petreci mult timp definind și ajustând metrici specifice. Când execuți adversarial attacks, nu defini manual metrici. Framework-ul gestionează acest lucru în întregime în culise. Acesta mapează automat vulnerabilitatea pe care ai selectat-o direct la o metrică de evaluare internă corespunzătoare. Deoarece i-ai spus să testeze pentru Bias, motorul rulează automat un evaluator de bias pentru fiecare răspuns pe care îl returnează callback-ul modelului target. După ce funcția de red team termină de trimis aceste prompturi generate și de evaluat răspunsurile, aceasta generează o Evaluare a Riscurilor cuprinzătoare. Această evaluare oferă o defalcare clară a scanării. Arată exact câte atacuri au fost încercate, ce tehnici de atac specifice au spart cu succes sistemul tău și input strings-urile exacte care au cauzat eșecul. Pleci cu o listă concretă de inputuri pe care sistemul tău nu le poate gestiona în prezent. Iată ideea cheie. Adevărata putere a acestei configurări constă în decuplarea metodei de atac de vulnerabilitatea target, permițându-ți să-ți multiplici acoperirea de securitate prin asocierea unui singur defect, cum ar fi bias-ul, cu zeci de vectori de atac diferiți simultan. Mulțumesc pentru audiție, happy coding tuturor!

Salut, sunt Alex de la DEV STORIES DOT EU. DeepEval Framework, episodul 17 din 18. Nu ai da niciodată merge la un pull request pentru cod tradițional fără să rulezi mai întâi unit testele. Cu toate acestea, echipele fac deploy în mod curent la modele de limbaj nedeterministe și doar speră că noile prompturi încă funcționează. Dacă vrei să previi ca update-urile proaste ale modelului să strice producția, ai nevoie de CI/CD și Continuous Evaluation. DeepEval tratează evaluările modelelor de limbaj exact ca pe testele software standard, integrându-se direct cu Pytest. Definești o funcție de test, inițializezi metricile de evaluare și faci un assert că metrica trece. Evaluarea unui model pe un singur input este inutilă, așa că trebuie să validezi modificările pe un batch mare de inputuri baseline aprobate și outputuri așteptate. Acesta este golden dataset-ul tău. Pentru a itera eficient prin acest dataset, folosești decoratorul standard Pytest mark parametrize. Îți încarci dataset-ul, extragi test case-urile individuale și le pasezi în decorator. Când rulează test suite-ul, Pytest generează dinamic o execuție separată de test pentru fiecare element din golden dataset-ul tău. Iată ideea cheie. Pentru că framework-ul se integrează strâns cu Pytest, developerii presupun adesea că pot rula pur și simplu comenzi standard Pytest în terminalul lor. Nu face asta. Dacă execuți Pytest direct pe fișierele tale de evaluare, te vei lovi de erori neașteptate legate de event loop-uri asincrone și telemetrie lipsă pentru metrici. Trebuie să folosești mereu interfața dedicată de command line. Comanda corectă este deepeval test run, urmată de numele fișierului tău Python. Acest wrapper gestionează setup-ul asincron complex cerut de modelele de limbaj și se asigură că toate rezultatele testelor sunt capturate și logate corect. Integrarea acestei comenzi în pipeline-ul tău de deployment îți oferă evaluare continuă. Ia în considerare un setup tipic de GitHub Action. Configurezi workflow-ul să facă trigger ori de câte ori un inginer deschide un pull request către branch-ul main. Action runner-ul face checkout la repository, face setup-ul mediului Python și execută deepeval test run pe scriptul tău cu golden dataset-ul. Framework-ul evaluează codul sau promptul nou modificat pe fiecare test case istoric. Dacă un developer modifică un system prompt pentru a face răspunsurile mai concise, ar putea instrui accidental modelul să elimine avertismentele obligatorii de compliance. Când rulează pipeline-ul de CI, evaluarea automată prinde imediat acest context lipsă. Dacă noua logică face ca scorul tău de evaluare să scadă sub pragul definit pe orice test case, assert-ul pică. Scriptul returnează un exit code diferit de zero, GitHub Action-ul se face imediat roșu, iar pull request-ul este blocat de la merge. Acest check automat de pre-deployment acționează ca un gatekeeper strict. Prinde automat regresiile. Nu mai trebuie să faci spot-check manual pe outputuri sau să aștepți ca userii să se plângă că un nou model swap a stricat un anumit edge case. Pipeline-ul dovedește matematic dacă update-ul este safe pentru deploy, eliminând complet subiectivitatea umană din procesul de release. Evaluarea continuă înseamnă că te oprești din a trata prompt engineering-ul ca pe un joc de noroc operațional și începi să-l tratezi ca pe un software release predictibil, susținut de date concrete. Mersi pentru audiție, happy coding tuturor!

Salut, sunt Alex de la DEV STORIES DOT EU. DeepEval Framework, episodul 18 din 18. Petreci ore întregi făcând tuning pe un prompt local, obții un scor excelent la evaluare și faci deploy la cod. Două săptămâni mai târziu, un alt inginer actualizează modelul de bază și, dintr-o dată, aplicația pică pe edge cases pe care nimeni nu le-a urmărit. Să rulezi evaluările local e doar jumătate din treabă. Acest episod acoperă cum să-ți scalezi testarea și să urmărești regresiile în timp folosind Confident AI. În primul rând, o distincție necesară. DeepEval este framework-ul open-source pe care îl rulezi în terminal sau în mediul tău Python pentru a executa teste. Confident AI este platforma cloud hostată, construită peste el. Folosești DeepEval pentru a-ți defini metricile și a rula evaluările propriu-zise. Folosești Confident AI pentru a centraliza, urmări și analiza aceste rapoarte de evaluare la nivelul întregii organizații de inginerie. Ia scripturile locale izolate și le transformă într-un sistem colaborativ de referință. Trecerea de la execuția locală la logging-ul în cloud necesită un singur pas simplu. În terminalul tău, execuți comanda deepeval login. CLI-ul îți va cere să introduci un API key generat din workspace-ul tău Confident AI. După ce te autentifici, workflow-ul tău zilnic rămâne exact la fel. Rulezi fișierele de test folosind comanda standard de testare. Framework-ul detectează automat sesiunea activă și face stream la rezultate direct în dashboard-ul din cloud, în timp ce le afișează și local. Centralizarea rapoartelor îți oferă posibilitatea de a urmări regresiile în mod metodic. O regresie apare atunci când o modificare în codul sau configurația ta degradează accidental performanța sistemului. Pentru a diagnostica de ce a apărut o regresie, trebuie să urmărești exact ce s-a schimbat între test runs. Acest lucru se face prin logarea hiperparametrilor. În contextul evaluărilor pentru modele de limbaj, un hiperparametru este orice variabilă care modifică comportamentul pipeline-ului tău. Aici intră arhitectura modelului, setarea de temperature, chunk size-ul folosit pentru retrieval, sau chiar versiunea specifică a template-ului de prompt. Când configurezi DeepEval să logheze acești hiperparametri, ei sunt atașați fiecărui test run trimis către Confident AI. Gândește-te la o echipă care încearcă să-și facă upgrade la aplicație. Vor să știe dacă trecerea de la GPT-4o la Claude 3.5 Sonnet îmbunătățește de fapt scorul general al pipeline-ului. Configurează numele modelului ca hiperparametru urmărit. Când inginerul rulează suita de evaluare folosind noul model, Confident AI loghează noul nume al modelului alături de scorurile obținute pentru metrici precum precizia contextuală sau consistența factuală. Iată ideea cheie. Pentru că toate test runs-urile istorice sunt salvate în cloud, echipa poate vedea un timeline care compară modificările exacte ale hiperparametrilor cu scorurile agregate de evaluare. Dacă trecerea la noul model crește relevanța răspunsurilor, dar scade drastic consistența factuală, dashboard-ul evidențiază instantaneu această regresie. Toți membrii echipei văd aceleași date. Nu mai trebuie niciodată să faci parse prin output-urile vechi din consolă sau să te bazezi pe memorie pentru a decide dacă o schimbare de configurație a fost un succes. Evaluarea continuă necesită un baseline istoric. Fără un sistem centralizat care să-ți lege direct configurațiile de scorurile de evaluare, pur și simplu rulezi experimente izolate, nu construiești un sistem fiabil. Aici se încheie seria noastră despre framework-ul DeepEval. Te încurajez cu tărie să explorezi documentația oficială și să încerci să construiești aceste evaluări hands-on. Dacă ai subiecte tehnice pe care ai vrea să le vezi abordate într-o serie viitoare, vizitează devstories dot eu pentru a lăsa o sugestie. Mulțumesc pentru audiție, happy coding tuturor!