DeepEval Framework (2026 Edition)

Cześć, tu Alex z DEV STORIES DOT EU. DeepEval Framework, odcinek 1 z 18. Większość zespołów ocenia swoje nowo zdeployowane modele językowe, ręcznie przeglądając odpowiedzi w arkuszu kalkulacyjnym. To powolne, mocno subiektywne i niemożliwe do skalowania w miarę rozrostu aplikacji. DeepEval to open-source'owy framework do ewaluacji, który zastępuje tę ręczną robotę, działając w praktyce jak Pytest dla LLM-ów. Załóżmy, że twój zespół deployuje nową aplikację generatywną. Musisz upewnić się, że zachowuje się poprawnie, zanim wypuścisz ją na produkcję. Z DeepEval piszesz testy dokładnie tak samo, jak standardowe unit testy w Pythonie. Tworzysz plik o nazwie test example kropka py. Wewnątrz tego pliku konstruujesz test case. Ten obiekt test case przechowuje początkowy input prompt, faktyczny output wygenerowany przez twoją aplikację oraz wszelkie oczekiwane odpowiedzi docelowe. Następnie aplikujesz metrykę ewaluacyjną do tego test case'a. Zamiast używać standardowego sprawdzania równości, by upewnić się, czy zmienna A idealnie pasuje do zmiennej B, używasz specjalistycznej funkcji asercji dostarczonej przez framework. Uruchamiasz ten plik z linii komend, używając standardowej komendy Pytest. Framework wykonuje testy równolegle, wyłapuje asercje i raportuje passy oraz faile bezpośrednio w twoim terminalu. I tu pojawia się kluczowa kwestia. Standardowe testy deterministyczne nie są w stanie ocenić jakości ani dokładności ludzkiego języka. Jeśli użytkownik poprosi twoją aplikację o podsumowanie dokumentu, istnieją tysiące poprawnych sposobów na napisanie tego podsumowania. Wzorce regex i dokładne dopasowywanie stringów są tutaj bezużyteczne, ponieważ nie potrafią zinterpretować znaczenia semantycznego. DeepEval radzi sobie z tą ogromną zmiennością, wykorzystując koncepcję zwaną LLM-as-a-judge. Framework wykorzystuje wysoce zaawansowany, ogólny model językowy do oceny konkretnych outputów twojej własnej aplikacji. Model judge czyta output twojej aplikacji, porównuje go z surowymi kryteriami wybranej przez ciebie metryki i oblicza wynik liczbowy. Co ważniejsze, zwraca wynik typu boolean wskazujący, czy punktacja spełnia twój zdefiniowany próg, wraz z uzasadnieniem w formacie plain text, które dokładnie wyjaśnia, dlaczego przyznał taką ocenę. Oznacza to, że sfailowany test daje ci natychmiastowy kontekst do debugowania. Projektując te test case'y, musisz wybrać jeden z dwóch różnych trybów ewaluacji. Łatwo pomylić zakres tych trybów, dlatego nakreślmy wyraźną granicę. Ewaluacja end-to-end bierze pod uwagę tylko początkowy input i końcowy output. Cała aplikacja jest traktowana jak black box. Podajesz prompt, system daje odpowiedź, a judge ocenia ten końcowy tekst. Całkowicie ignoruje to, w jaki sposób aplikacja wygenerowała odpowiedź. Ewaluacja na poziomie komponentów to podejście typu white-box. Zamiast sprawdzać tylko końcową odpowiedź, ten tryb śledzi konkretne wewnętrzne kroki, które twoja aplikacja wykonała, aby do niej dotrzeć. Jeśli twój system przeszukuje bazę danych, aby pobrać dokumenty kontekstowe przed wygenerowaniem tekstu, test na poziomie komponentu ocenia ten konkretny krok wyszukiwania. Sprawdza, czy pobrane dokumenty były faktycznie trafne w stosunku do promptu użytkownika, całkowicie niezależnie od końcowej wygenerowanej odpowiedzi. Testujesz wewnętrzne mechanizmy, a nie tylko produkt końcowy. Możesz mieć system, który przechodzi test end-to-end, podając poprawną odpowiedź, ale failuje test na poziomie komponentu, ponieważ zaciągnął tę odpowiedź z niewłaściwego wewnętrznego dokumentu. Ewaluacja modelu językowego nie jest już subiektywnym ćwiczeniem z czytania; to sztywny, zautomatyzowany i powtarzalny element twojego pipeline'u continuous integration. Dzięki za wysłuchanie, udanego kodowania wszystkim!

Cześć, tu Alex z DEV STORIES DOT EU. DeepEval Framework, odcinek 2 z 18. Nie możesz zmierzyć tego, czego nie zdefiniowałeś. Jeśli twoje automatyczne ewaluacje wydają się niespójne, problem często zaczyna się jeszcze zanim metryka w ogóle się uruchomi. Prawdopodobnie przekazujesz niewłaściwe komponenty swojego promptu do niewłaściwych granic ewaluacji. Rozwiązaniem jest ścisłe zdefiniowanie interakcji z LLM za pomocą blueprintu LLM test case. LLM test case w DeepEval służy jako atomowa jednostka ewaluacji. Zmusza cię do wyizolowania pojedynczej, konkretnej interakcji z twoim systemem. Nie przekazujesz do ewaluatora pełnych logów konwersacji ani surowych baz danych. Zamiast tego wyciągasz dokładnie to, co weszło, co wyszło i jakie dane w tle były zaangażowane w jedną konkretną turę. Interakcje multi-turn mają swój własny, specyficzny blueprint, ale standardowy test case skupia się ściśle na jednym, izolowanym requeście i responsie. Każdy test case wymaga dwóch obowiązkowych argumentów. Pierwszy to input. Jest to dokładny string, który użytkownik lub system przesłał do modelu. Drugi to actual output. To jest tekst, który twój duży model językowy wygenerował w odpowiedzi. Nawet jeśli nie ewaluujesz niczego innego, musisz podać te dwa parametry, aby zmierzyć podstawowe metryki, takie jak toxicity czy answer relevance. Weźmy na warsztat chatbota obsługi klienta. Input to użytkownik pytający, czy może zwrócić parę noszonych butów po trzydziestu pięciu dniach. Actual output to twój model generujący odpowiedź, która odmawia zwrotu. Aby wyewaluować, czy ta odmowa jest faktycznie poprawna, musisz podać baseline truth. DeepEval daje ci do tego dwa różne, opcjonalne parametry. Są to expected output oraz context. Deweloperzy ciągle je mylą. Context jest ściśle oparty na faktach. Zawiera surową, niesformatowaną prawdę, jak string tekstowy z polityki twojej firmy, określający sztywny, trzydziestodniowy limit na zwrot. Expected output jest znacznie bardziej specyficzny. Narzuca ton, język i formatowanie. Używasz expected output, gdy chcesz, aby ewaluator sprawdził, czy model odpowiedział uprzejmymi, konkretnymi przeprosinami, zamiast po prostu zwrócić oschłą odmowę. Context odpowiada za fakty. Expected output odpowiada za styl i dokładne sformułowania. Oto kluczowa sprawa. To, jak skonstruujesz resztę tego test case'a, zmienia się w zależności od twojej architektury pod spodem. Jeśli ewaluujesz pipeline Retrieval-Augmented Generation, musisz zdefiniować retrieval context. Ten parametr przyjmuje listę stringów reprezentujących dokładne chunki dokumentów, które twój retriever wyciągnął z wektorowej bazy danych. Nie myl tego ze standardowym parametrem context. Context to idealna prawda, którą hardkodujesz na potrzeby testu. Retrieval context to rzeczywiste dane, które twój pipeline faktycznie znalazł na produkcji. Ewaluatory porównują je ze sobą, aby określić, czy twój algorytm wyszukiwania pobiera właściwe dokumenty. Jeśli budujesz agenta, a nie standardowy pipeline, używasz parametru tools called. Przyjmuje on listę obiektów lub stringów reprezentujących konkretne funkcje, które agent zdecydował się wywołać podczas tej izolowanej interakcji, takie jak odpalenie wewnętrznego kalkulatora zwrotów. Podanie tego pozwala ci ewaluować decyzje agenta dotyczące routingu równolegle z ostatecznym generowaniem tekstu. Niezawodność zautomatyzowanej metryki zależy całkowicie od higieny tych parametrów. Ewaluator nigdy nie ukarze halucynacji, jeśli nie dostarczysz ścisłego, opartego na faktach contextu, względem którego sprawdza on output. Dzięki za wysłuchanie, happy coding wszystkim!

Cześć, tu Alex z DEV STORIES DOT EU. DeepEval Framework, odcinek 3 z 18. Tradycyjne metryki NLP, takie jak BLEU i ROUGE, słabo sprawdzają się w ewaluacji nowoczesnych dużych modeli językowych, ale angażowanie człowieka do każdego test runu jest niemożliwe. Rozwiązaniem pozwalającym na skalowanie ewaluacji bez utraty zrozumienia semantyki jest potęga LLM-as-a-Judge. Tradycyjne metryki szukają dokładnego dopasowania słów. Jeśli twój model wygeneruje idealnie dokładne podsumowanie używając innych synonimów, metryka oparta na dokładnym dopasowaniu stringów oceni je nisko, ponieważ nie rozumie znaczenia. Użycie LLM-a jako sędziego rozwiązuje ten problem. Odczytuje on output, przetwarza kontekst i ocenia semantykę podobnie jak zrobiłby to człowiek, ale z prędkością maszyny. W DeepEval, metryka ewaluowana przez LLM-a wykonuje trzy konkretne akcje. Po pierwsze, oblicza score między zero a jeden. Zero to kompletna porażka, jeden to ideał. Po drugie, porównuje ten score z restrykcyjnym progiem, który sam definiujesz. Jeśli twój próg wynosi zero przecinek siedem, a model uzyska score zero przecinek sześć, test failuje. Po trzecie, zwraca powód. Ewaluujący LLM generuje tekstowe wyjaśnienie, szczegółowo opisujące, dlaczego przypisał taki, a nie inny score. Dzięki temu wiesz, co poszło nie tak, bez konieczności ręcznego czytania surowych logów. DeepEval dzieli te metryki na trzy kategorie. Metryki RAG ewaluują pipeline'y Retrieval-Augmented Generation. Metryki agentowe ewaluują autonomicznych agentów. Customowe metryki pozwalają ci zdefiniować własne kryteria ewaluacji od zera. Chociaż pod spodem ich prompty się różnią, wszystkie wykorzystują ten sam mechanizm sędziego. Wybierając metrykę, developerzy często mylą metryki reference-based i referenceless. Oto kluczowa różnica. Metryki reference-based wymagają ground truth. Potrzebują znanej, poprawnej odpowiedzi do porównania, co czyni je bardzo skutecznymi na wczesnym etapie developmentu i testowania. Metryki referenceless nie potrzebują ground truth. Ewaluują output wyłącznie na podstawie dostarczonego kontekstu lub samego promptu wejściowego. Ponieważ nie opierają się na gotowej odpowiedzi, metryki referenceless są dokładnie tym, czego używasz do monitorowania live na produkcji. Kuszące jest podpinanie kilkunastu metryk do każdego promptu, żeby zapewnić jakość. Nie rób tego. Złota zasada to używanie mniej niż pięciu metryk na aplikację. Wybierz te metryki, które faktycznie pokrywają się z twoją specyficzną logiką biznesową. Odpalanie niepotrzebnych metryk skutkuje tylko wolniejszymi testami i wyższymi kosztami obliczeniowymi. A propos kosztów, używanie flagowego komercyjnego modelu do oceniania tysięcy codziennych test runów szybko staje się drogie. DeepEval pozwala ci podmienić domyślnego ewaluatora na customowe modele. Możesz skonfigurować framework tak, aby używał Azure OpenAI, jeśli wymaga tego twoja infrastruktura enterprise. Alternatywnie, możesz postawić lokalny model używając Ollama. Odpalając wydajny model open-source lokalnie na własnym sprzęcie, tworzysz darmowego, bezstronnego sędziego. Po prostu inicjalizujesz lokalnego klienta Ollama i przekazujesz ten obiekt modelu bezpośrednio do konfiguracji metryki. DeepEval zajmuje się resztą, wykonując cały pipeline ewaluacji bez uderzania do zewnętrznych API bilingowych. Prawdziwą wartością sędziego LLM nie jest tylko numeryczny score, ale też zautomatyzowane wnioskowanie, które pomaga ci debugować każdy pojedynczy błąd. Dzięki za wysłuchanie, miłego kodowania wszystkim!

Cześć, tu Alex z DEV STORIES DOT EU. DeepEval Framework, odcinek 4 z 18. To jedna sprawa, gdy twój RAG pipeline odpowiada na pytanie. Zupełnie innym problemem jest, gdy z pełnym przekonaniem wymyśla szczegóły, których nie ma w twoich dokumentach źródłowych. Dzisiaj przyjrzymy się ewaluacji generatorów RAG, a konkretnie temu, jak wyłapywać dokładnie te błędy. Pipeline Retrieval-Augmented Generation składa się z dwóch odrębnych, ruchomych części. Retriever pobiera odpowiednie dokumenty. Generator bierze te dokumenty i tworzy ostateczną odpowiedź. Dzisiaj ignorujemy retriever. Zakładamy, że twój system pobrał już odpowiednie dokumenty. Skupiamy się wyłącznie na generatorze, który syntetyzuje tekst. Aby upewnić się, że ten tekst jest zarówno bezpieczny, jak i użyteczny, polegasz na dwóch metrykach: Faithfulness i Answer Relevancy. Pierwsza metryka to Faithfulness. To twój główny guardrail przed halucynacjami. Faithfulness mierzy, czy odpowiedź generatora, którą DeepEval nazywa actual output, może być w pełni uzasadniona przez retrieval context. Weźmy pod uwagę standardowy scenariusz. Użytkownik pyta twojego chatbota o firmowy pakiet medyczny. Retriever pobiera właściwy podręcznik HR. Generator odpowiada, że pakiet obejmuje opiekę medyczną, okulistyczną i kompleksową opiekę stomatologiczną. Jednak podręcznik HR w ogóle nie wspomina o opiece stomatologicznej. Generator wygenerował bardzo wiarygodne, dobrze sformatowane kłamstwo. Metryka Faithfulness wyłapuje dokładnie to zachowanie. Izoluje twierdzenia zawarte w actual output i weryfikuje je kawałek po kawałku z retrieval context. Jeśli generator dołączy fakty, których brakuje w kontekście, wynik Faithfulness spada. Nie ma znaczenia, czy ten fakt przypadkiem jest prawdziwy w świecie zewnętrznym. Jeśli nie ma on wyraźnego poparcia w dostarczonym kontekście, metryka oznacza to jako błąd. Teraz druga część, czyli Answer Relevancy. Odpowiedź o wysokim Faithfulness niekoniecznie jest użyteczna. Generator mógłby wygenerować idealnie dokładne podsumowanie podręcznika HR, które całkowicie ignoruje to, o co faktycznie zapytał użytkownik. Answer Relevancy mierzy, jak dobrze actual output bezpośrednio odnosi się do oryginalnego inputu. Ocenia, czy odpowiedź jest kompletna, zwięzła i pozbawiona zbędnego lania wody. Jeśli użytkownik pyta o kwotę wkładu własnego, a generator podaje tę kwotę, ale potem dodaje trzy akapity o historii firmowego ubezpieczenia zdrowotnego, wynik Answer Relevancy spada. System karze za wymijające lub rozwlekłe informacje równie surowo, co za brakujące informacje. Aby ewaluować te metryki, budujesz test case w DeepEval. Musisz podać trzy zmienne. Po pierwsze, input, reprezentujący prompt użytkownika. Po drugie, actual output, czyli tekst, który wyprodukował twój generator. Po trzecie, retrieval context, zawierający surowy tekst z dokumentów, które twój retriever przekazał do generatora. Przekazujesz ten test case do obu metryk. DeepEval ewaluuje tekst i oblicza dla każdej z nich wynik od zera do jednego. Definiujesz threshold. Jeśli odpowiedź uzyskuje wynik zero przecinek dziewięć dla Faithfulness, ale zero przecinek cztery dla Answer Relevancy, wiesz, że generator jest bezpieczny, ale mało pomocny. Jeśli wyniki są odwrotne, twój generator jest pomocny, ale aktywnie halucynuje. Oto kluczowy wniosek. Ewaluując generatory, musisz systematycznie oddzielać prawdę od kontekstu. Skuteczny generator nie mówi absolutnej prawdy; mówi dokładnie to, na co pozwalają mu dostarczone dokumenty, odpowiadając tylko na to, o co go zapytano, i nic więcej. Dzięki za wysłuchanie, miłego kodowania wszystkim!

Cześć, tu Alex z DEV STORIES DOT EU. DeepEval Framework, odcinek 5 z 18. Jeśli twój LLM daje słabe odpowiedzi, to może wcale nie być wina modelu. Twój retriever może po prostu karmić go śmieciami. Dzisiaj porozmawiamy o ewaluacji retrieverów w RAG, a konkretnie o metrykach Contextual Precision, Contextual Recall i Contextual Relevancy. Wyobraź sobie, że odpytujesz dużą bazę wiedzy o bardzo specyficzny szczegół jakiegoś regulaminu. Zamiast wyciągnąć ten jeden konkretny akapit, którego faktycznie potrzebujesz, twój retriever pobiera dziesięć stron luźno powiązanego tekstu. LLM gubi się w szumie, koszty tokenów rosną, a ostateczna odpowiedź na tym cierpi. Aby to naprawić, musisz mierzyć etap retrievalu całkowicie niezależnie od etapu generacji. Pierwsza metryka to Contextual Relevancy. Ta metryka analizuje surowe chunki tekstu, które twój retriever wyciąga z bazy danych, i oblicza stosunek istotnych zdań do wszystkich zdań. Jeśli pobierasz tysiąc słów tylko po to, żeby złapać jedno przydatne zdanie, twój wynik relevancy leci w dół. Wysokie relevancy oznacza, że przekazujesz czysty, gęsty kontekst do promptu dla LLM-a, bez marnowania tokenów na nieistotne tło. Kolejna metryka to Contextual Recall. Ocenia ona, czy twój retriever znalazł wszystkie niezbędne informacje potrzebne do odpowiedzi na zapytanie użytkownika. DeepEval oblicza to, biorąc oczekiwany output dla zapytania i wyciągając z niego wszystkie fakty. Następnie skanuje pobrany kontekst, aby sprawdzić, czy te konkretne fakty rzeczywiście w nim są. Jeśli w kontekście brakuje kluczowego faktu potrzebnego do odpowiedzi, wynik recall spada. Wysoki recall gwarantuje, że LLM faktycznie ma surowy materiał, którego potrzebuje, żeby wygenerować dobrą odpowiedź. Następnie mamy Contextual Precision. Ludzie często mylą precision z recall. Recall oznacza, że niczego nie pominąłeś. Precision oznacza, że nie dorzuciłeś żadnego lania wody. W ewaluacjach RAG, precision mocno opiera się na rankingu. Sprawdza, czy te najbardziej istotne chunki kontekstu pojawiają się na samej górze pobranej listy. Jeśli ten jeden kluczowy akapit jest zakopany na dziesiątej pozycji pod dziewięcioma bezużytecznymi chunkami, twój wynik precision jest niski. Modele językowe zazwyczaj zwracają większą uwagę na początek promptu, więc kolejność retrievalu całkowicie zmienia wynik. I tu jest kluczowa sprawa. Istnieje ciągłe napięcie między precision a recall. Jeśli skonfigurujesz swój retriever tak, aby za każdym razem zwracał pięćdziesiąt chunków, twój recall prawdopodobnie będzie idealny, bo zarzucasz ogromną sieć. Ale twoje precision i relevancy gwałtownie spadną, ponieważ większość z tych pięćdziesięciu chunków to szum. Z drugiej strony, jeśli ograniczysz retriever do dokładnie jednego chunka, twoje relevancy będzie nieskazitelne, ale recall leży w momencie, gdy zapytanie użytkownika wymaga zsyntetyzowania dwóch różnych faktów z dwóch różnych dokumentów. Aby uruchomić te testy we frameworku, definiujesz obiekt test case. Ten obiekt przechowuje input użytkownika, oczekiwany output oraz listę rzeczywistych stringów kontekstowych, które twój retriever pobrał z bazy danych. Inicjalizujesz konkretną metrykę, której potrzebujesz, na przykład metrykę Contextual Recall, i przekazujesz do niej ten test case. Framework używa wtedy pod spodem modelu ewaluacyjnego, żeby przeczytać te stringi, zmapować fakty, obliczyć karę za brakujące lub źle zrankowane informacje i zwrócić ostateczny wynik liczbowy od zera do jedynki. Ewaluacja twojego retrievera zmusza cię do skonfrontowania się z tym, co dokładnie przekazujesz do swojego modelu generatywnego. Dobrze działający pipeline RAG nie tylko wrzuca dane do LLM-a; on bezlitośnie je filtruje i rankuje. Dzięki za wysłuchanie, udanego kodowania!

Cześć, tu Alex z DEV STORIES DOT EU. DeepEval Framework, odcinek 6 z 18. Ewaluacja pojedynczej odpowiedzi tekstowej jest prosta – porównujesz finalny output z inputem. Ale jak ewaluować autonomicznego agenta, który sam decyduje o swoich krokach, zapętla się w wielu procesach myślowych i triggeruje zewnętrzne toole? Jeśli finalna odpowiedź jest poprawna, ale agent wykonał dwadzieścia niepotrzebnych kroków i odpytał złą bazę danych, żeby do niej dojść, twój system jest zepsuty. Naprawienie tego wymaga Agentic Evaluation. Musimy oddzielić proste wywołanie API od autonomicznego, wieloetapowego flow agenta. Standardowa integracja modelu językowego podąża predefiniowaną ścieżką. Wysyłasz prompt, a model zwraca string. Agentic flow przekazuje kontrolę modelowi. Model otrzymuje ogólny cel i autonomicznie decyduje, jakich wewnętrznych tooli użyć, w jakiej kolejności i jakie argumenty do nich przekazać. Jeśli ewaluujesz agenta patrząc tylko na jego finalny text output, omija cię cała mechanika jego rozumowania. DeepEval rozwiązuje ten problem przy użyciu metryki Task Completion. Zamiast parsować finalny string odpowiedzi, metryka Task Completion analizuje trace z wykonania agenta. Trace to kompletny, sekwencyjny zapis każdej myśli, akcji i wywołania toola, którego agent dokonał podczas konkretnego runu. Metryka Task Completion czyta ten trace, aby określić, czy agent faktycznie zrealizował request użytkownika poprzez prawidłowe akcje. Weźmy na przykład agenta do planowania podróży. Użytkownik prosi go o zarezerwowanie weekendu w Rzymie wraz z rezerwacją stolika na kolację. Aby to się udało, agent musi poprawnie wywołać tool do wyszukiwania restauracji, a następnie przekazać te dane do toola generującego plan podróży. Jeśli agent zwróci idealnie sformatowany plan podróży, ale tak naprawdę nigdy nie uruchomi toola do wyszukiwania restauracji, standardowa metryka ewaluacji tekstu prawdopodobnie to przepuści. Output wygląda bardzo przekonująco. Metryka Task Completion zwróci fail. Analizując trace, metryka widzi, że brakuje wymaganego wywołania toola. Agent wyhalucynował dane restauracji zamiast je pobrać, a trace to udowadnia. To przenosi ewaluację z finalnego outputu na kroki operacyjne. Musisz też ewaluować, czy toole zostały użyte prawidłowo. Test case'y w DeepEval obsługują to za pomocą parametru o nazwie tools called. Kiedy konstruujesz test case do ewaluacji, przekazujesz listę tooli, które agent wywołał podczas swojego działania, do tego parametru tools called. Dostarczenie tych danych pozwala frameworkowi na ewaluację Tool Correctness. Ewaluacja weryfikuje, czy agent wybrał odpowiednie toole do konkretnego celu, czy przekazał do nich poprawne argumenty wejściowe i czy z sukcesem przetworzył dane, które te toole zwróciły. Jeśli twój agent do planowania podróży poprawnie zdecydował się użyć toola do wyszukiwania restauracji, ale przekazał Paryż zamiast Rzymu jako argument, ewaluacja Tool Correctness wyłapie błąd dokładnie w punkcie awarii. Wiesz dokładnie, który krok przerwał chain. Oto kluczowy wniosek. Ewaluacja agentów oznacza wejście do czarnej skrzynki. Weryfikujesz integralność procesu rozumowania agenta i jego mechaniczne akcje krok po kroku. Strukturalnie idealna finalna odpowiedź jest całkowicie bezużyteczna, jeśli agent dotarł do niej przez pominięte toole, wyhalucynowane dane i zepsutą logikę. Dzięki za wysłuchanie, happy coding wszystkim!

Cześć, tu Alex z DEV STORIES DOT EU. DeepEval Framework, odcinek 7 z 18. Chatbot może dać świetną pierwszą odpowiedź, ale w trzeciej turze całkowicie zapomnieć o intencjach użytkownika albo swojej personie. Dlatego korzystamy z Multi-Turn Conversation Evaluation. Ewaluacja pojedynczych odpowiedzi jest prosta, ale prawdziwi użytkownicy nie wysyłają izolowanych promptów. Zadają kolejne pytania, zmieniają zdanie i wracają do rzeczy, o których mówili pięć minut temu. Standardowe metody ewaluacji w tym przypadku zawodzą, ponieważ analizują pojedynczy input i pojedynczy output. Nie mają pojęcia czasu ani pamięci. Żeby przetestować, jak model radzi sobie z trwającym dialogiem, potrzebujesz struktury, która łapie cały wątek. We frameworku rozwiązujesz to za pomocą specjalnego obiektu o nazwie ConversationalTestCase. Zamiast przyjmować jeden input string i jeden output string, przyjmuje on parametr o nazwie turns. Parametr turns to sekwencyjna lista. Każdy element na tej liście reprezentuje pojedynczą wymianę zdań między użytkownikiem a systemem. Układasz te wymiany po kolei, od pierwszej do samej ostatniej wiadomości. Opakowanie tej sekwencji w ConversationalTestCase mówi silnikowi ewaluacji, żeby traktował całą listę jako jedną ciągłą interakcję typu stateful. Jest tu jednak pewna pułapka. Nie przekazuj obiektu ConversationalTestCase do standardowych, niekonwersacyjnych metryk. Standardowe metryki są zbudowane dla pojedynczych outputów. Jeśli użyjesz ich na obiekcie typu multi-turn, całkowicie zignorują historyczny kontekst. Musisz użyć dedykowanych metryk konwersacyjnych, żeby ocenić listę tur. Metryki konwersacyjne oceniają konwersację jako całość. Biorą pod uwagę wcześniejszy kontekst, żeby ocenić spójne zachowanie modelu. Dwa główne przykłady to Role Adherence i Knowledge Retention. Weźmy na przykład chatbota obsługi klienta, który dostał wyraźną instrukcję, żeby zachowywać się jak pirat. W pierwszej turze użytkownik wita się, a bot odpowiada pirackim slangiem. W drugiej turze użytkownik zadaje pytanie, a bot pozostaje w roli. Ale w trzeciej turze, kiedy użytkownik pyta o zwrot pieniędzy, bot odpowiada standardowymi, korporacyjnymi przeprosinami. Całkowicie wyszedł z roli. Możesz automatycznie wyłapać ten błąd, używając metryki Role Adherence. Definiujesz docelową personę w konfiguracji metryki, a ona ocenia całą konwersację, żeby zweryfikować, czy model nie wyszedł z roli, nawet gdy kontekst stawał się coraz dłuższy. Knowledge Retention rozwiązuje inny problem. Jeśli użytkownik poda numer konta w pierwszej turze, a w czwartej poprosi o aktualizację statusu, bot nie powinien ponownie pytać o numer konta. Metryka Knowledge Retention skanuje listę tur, żeby upewnić się, że model poprawnie wyciąga i stosuje fakty wprowadzone wcześniej w historii czatu. Zbudowanie tego w kodzie wymaga tylko kilku kroków. Najpierw tworzysz swoje pojedyncze tury, mapując user input na model output dla każdego kroku dialogu. Następnie przekazujesz całą sekwencję do nowego ConversationalTestCase. Potem konfigurujesz swoją metrykę konwersacyjną, przypisując kryteria, takie jak oczekiwana persona. Na koniec odpalasz metrykę na swoim test case. Framework przetwarza pełną historię i zwraca wynik na podstawie skumulowanej interakcji. Oto kluczowy wniosek. Ewaluacja multi-turn przenosi twoje testowanie z mierzenia izolowanej technicznej dokładności na mierzenie spójności zachowania w czasie. Dzięki za wysłuchanie, miłego kodowania wszystkim!

Cześć, tu Alex z DEV STORIES DOT EU. DeepEval Framework, odcinek 8 z 18. Czasami standardowe metryki nie pasują do twojego use case'u, na przykład do sprawdzenia, czy ściśle regulowany chatbot finansowy brzmi wystarczająco profesjonalnie. Potrzebujesz sposobu na wiarygodny pomiar subiektywnych cech i właśnie tutaj wkracza budowanie customowych metryk za pomocą G-Eval. Zanim zdefiniujesz customowe metryki, ustal, jaki rodzaj logiki mierzysz. G-Eval jest zaprojektowany wyłącznie do subiektywnych kryteriów, takich jak ton, spójność czy flow konwersacji. Jeśli musisz wymusić ścisłą, obiektywną logikę, powinieneś użyć DAG-ów. G-Eval radzi sobie z niuansami ludzkiego języka. Żeby zbudować metrykę profesjonalizmu dla finansowego chatbota, nie piszesz skomplikowanych reguł parsowania. Używasz G-Eval, żeby zdefiniować customową metrykę przy użyciu potocznego języka. Tworzysz instancję metryki, podając jej nazwę i string z kryteriami w języku naturalnym. Dla tego chatbota twoje kryteria mogą brzmieć: określ, czy actual output zachowuje formalny, pełen szacunku ton i rygorystycznie unika slangu lub potocznych sformułowań. I tu jest kluczowa sprawa. Metryka nie wysyła po prostu twoich kryteriów do dużego modelu językowego z prośbą o szybki wynik. G-Eval uruchamia dwuetapowy algorytm Chain of Thought. Krok pierwszy to generowanie. Algorytm czyta twoje kryteria napisane prostym angielskim i automatycznie generuje ustrukturyzowaną listę kroków ewaluacji. Tworzy własną rubrykę oceniania. Dla metryki profesjonalizmu może wygenerować krok skanujący pod kątem nieformalnych powitań, i kolejny krok weryfikujący użycie odpowiedniej terminologii finansowej. Krok drugi to właściwa ewaluacja. Algorytm bierze te wygenerowane kroki i aplikuje je do parametrów twojego konkretnego test case'u. Standardowy test case w G-Eval zazwyczaj zawiera input użytkownika i actual output z twojego modelu, ale możesz też dołączyć expected output albo retrieval context. Ewaluator przepuszcza tekst przez swoją customową rubrykę, oblicza końcowy score między zero a jeden i podaje szczegółowe uzasadnienie, wyjaśniając, dlaczego odjął punkty. Pisanie skutecznych kryteriów decyduje o jakości twojej metryki. Traktuj string z kryteriami jak mocno obwarowany prompt. Nie pisz niejasnych instrukcji w stylu: sprawdź, czy odpowiedź jest dobra. Zdefiniuj dokładnie, co znaczy dobra. Jeśli użycie slangu powinno skutkować automatycznym scorem równym zero, napisz to wprost w kryteriach. Kroki ewaluacji wygenerowane w pierwszym kroku są tylko tak precyzyjne, jak instrukcje, które podasz. To pokrywa pojedyncze interakcje. Konwersacje stanowią inne wyzwanie. Chatbot może zacząć profesjonalnie, ale przy czwartej wiadomości przyjąć luźny ton. Żeby sobie z tym poradzić, używasz Conversational G-Eval. Conversational G-Eval stosuje dokładnie ten sam dwuetapowy algorytm do czatu multi-turn. Różnica polega na formacie inputu. Zamiast ewaluować pojedynczy input i actual output, przekazujesz całą historię konwersacji. Ta historia składa się z sekwencyjnych tur, na przemian użytkownika i asystenta. Metryka czyta cały transkrypt, generuje kroki ewaluacji na podstawie twoich customowych kryteriów i ocenia interakcję jako całość. Dzięki temu output modelu pozostaje spójny od pierwszego powitania aż do pożegnania. Skuteczność każdej customowej metryki zależy całkowicie od traktowania kryteriów jak rygorystycznej specyfikacji, gdzie jasność zawsze wygrywa ze zwięzłością. Dzięki za wysłuchanie, udanego kodowania wszystkim!

Cześć, tu Alex z DEV STORIES DOT EU. DeepEval Framework, odcinek 9 z 18. Podczas oceny złożonych reguł formatowania, pojedynczy, rozbudowany prompt może łatwo sprawić, że Twój ewaluator LLM zacznie halucynować wynik. Może zauważyć odpowiednie słowa w tekście, całkowicie zignorować strukturę i przepuścić test, który powinien oblać. Rozwiązaniem tego problemu jest Deterministic Evaluation z DAG. DAG to skrót od Directed Acyclic Graph. W tym frameworku metryka DAG pozwala Ci zbudować ścisłe drzewo decyzyjne, które kontroluje, jak LLM ocenia odpowiedź. Zamiast prosić model o przetworzenie tekstu i ocenę na podstawie wielkiego bloku instrukcji, rozbijasz logikę na granularne operacje krok po kroku. Dane przepływają ściśle w jednym kierunku, od root nodes na początku Twojego drzewa, aż do leaf nodes na samym końcu. Aby zbudować to drzewo, opierasz się na trzech odrębnych komponentach. Pierwszy to Task Node. Częstym błędem jest traktowanie go jak ewaluatora. A nim nie jest. Task Node po prostu wyodrębnia lub przetwarza dane z inputu albo wygenerowanej odpowiedzi. Kolejny to Binary Judgement Node. Ten node bierze dane przetworzone przez Task Node i ocenia je na podstawie konkretnych kryteriów, zwracając twarde tak lub nie. Na koniec mamy Verdict Node. Działa on jako leaf node. Kończy on gałąź Twojego drzewa decyzyjnego i zwraca końcowy wynik liczbowy wraz z pisemnym uzasadnieniem. Zastosujmy to do konkretnego scenariusza. Testujesz LLM, który generuje podsumowania transkryptów ze spotkań. Twoim twardym wymaganiem jest, aby każde podsumowanie miało dokładnie trzy nagłówki: Intro, Body i Conclusion, w dokładnie takiej kolejności. Zaczynasz budować metrykę od utworzenia root Task Node. Instruujesz ten node, aby przeczytał wygenerowane podsumowanie i wyciągnął listę wszystkich znalezionych nagłówków. To jego jedyne zadanie. Izoluje on dane o formatowaniu i przekazuje prostą listę tekstową do kolejnego poziomu drzewa. Teraz przekazujesz tę listę do Binary Judgement Node. Definiujesz kryteria dla tego node'a, aby sprawdził, czy lista zawiera dokładnie trzy elementy. Jeśli node oceni to jako fałsz, kieruje wykonanie w dół do Verdict Node. Ten Verdict Node natychmiast oblewa test, przypisuje wynik zero i zwraca uzasadnienie, że liczba nagłówków była nieprawidłowa. Jeśli Binary Judgement Node zwróci prawdę, wykonanie przechodzi do drugiego Binary Judgement Node. Ten node bierze tę samą wyciągniętą listę i sprawdza sekwencję. Weryfikuje, czy pierwszy element to Intro, drugi to Body, a trzeci to Conclusion. Jeśli to prawda, kieruje do końcowego Verdict Node, przyznając maksymalny wynik. Jeśli fałsz, kieruje do innego Verdict Node, przypisując zero z powodu błędnej kolejności. I to jest najważniejsza część. Oddzielając ekstrakcję informacji w Task Node od logiki ewaluacji w Judgement Nodes, zmuszasz LLM do podążania sztywną ścieżką. Model zajmuje się semantyczną ekstrakcją, podczas gdy Twój graf gwarantuje deterministyczne wykonanie reguł. Dzięki za wysłuchanie, udanego kodowania wszystkim!

Cześć, tu Alex z DEV STORIES DOT EU. DeepEval Framework, odcinek 10 z 18. Testowanie modelu językowego na pięciu manualnych promptach jest urocze. Ale kiedy robisz upgrade do nowej wersji modelu, te pięć promptów nie powie ci, czy nie zepsułeś edge case'ów w setkach historycznych interakcji. Żeby być production-ready, potrzebujesz solidnego, wersjonowanego repozytorium prawdy. Właśnie to zapewnia Evaluation Dataset. Evaluation Dataset w DeepEval to po prostu ustrukturyzowana kolekcja elementów nazywanych Goldenami. Zanim przejdziemy dalej, musimy wyjaśnić pewne powszechne nieporozumienie. Developerzy często mylą Goldena z Test Case'em. To nie jest to samo. Golden to surowy wiersz w datasecie. Zawiera twoje statyczne parametry testowe, takie jak user input, oczekiwany output i retrieval context. Reprezentuje idealny scenariusz. Golden staje się Test Case'em dopiero później, w runtime'ie, po tym, jak twoja aplikacja live przetworzy input i wstrzyknie swój rzeczywisty output. Golden to blueprint, podczas gdy Test Case to wynik wykonania. Omówmy to na konkretnym scenariuszu. Masz historyczny log 500 zapytań do supportu zapisany w pliku CSV. Chcesz rygorystycznie przetestować nową wersję modelu na tym konkretnym zestawie zapytań. Nie musisz pisać customowej logiki do parsowania. Po prostu inicjalizujesz Evaluation Dataset i używasz wbudowanej metody, żeby dodać dane z pliku CSV. Przekazujesz ścieżkę do pliku i definiujesz mapowanie. Mówisz datasetowi, która kolumna CSV odpowiada za input użytkownika, która mapuje się na oczekiwany output, a która zawiera kontekst. Framework zajmuje się parsowaniem i konstruuje 500 Goldenów w pamięci. Dokładnie to samo możesz zrobić z plikiem JSON, mapując klucze JSON na pola Goldena. Oto kluczowa sprawa. Evaluation Dataset kontroluje specyficzny cykl życia, który łączy twoje statyczne dane z dynamicznym pipelinem ewaluacyjnym. Najpierw ładujesz i przechowujesz swoje Goldeny w datasecie. Następnie, podczas test runu, iterujesz po datasecie. Wyciągasz input z każdego Goldena, karmisz nim swój model językowy live i przechwytujesz wygenerowany response. Następnie dołączasz ten live response do Goldena i konwertujesz go na oficjalny Test Case. Na koniec przekazujesz ten kompletny Test Case do swoich metryk w celu scoringu. Dzięki temu twoje surowe dane są całkowicie oddzielone od logiki egzekucji. Do tej pory opisywaliśmy datasety single-turn. Jeden input użytkownika, jeden oczekiwany output. Ale wiele aplikacji wykorzystuje interfejsy czatowe. Do tego DeepEval wspiera datasety multi-turn. Zamiast płaskiego stringa z inputem, dataset multi-turn zawiera sekwencję interakcji. Pojedynczy multi-turn Golden przechowuje całą historię konwersacji, śledząc, jak użytkownik i system wchodzą w interakcje na przestrzeni wielu kroków. Dzięki temu twoje metryki mogą ewaluować flow i retencję kontekstu konwersacji, zamiast oceniać pojedynczą, wyizolowaną odpowiedź. Ustrukturyzowanie danych w formalne Evaluation Datasety gwarantuje, że każdy tweak promptu i podmiana modelu są mierzone względem ścisłego, niezmiennego historycznego standardu. Dzięki za wysłuchanie, happy coding wszystkim!

Cześć, tu Alex z DEV STORIES DOT EU. DeepEval Framework, odcinek 11 z 18. Największym wąskim gardłem w ewaluacji dużych modeli językowych nie jest framework testowy, którego używasz. Jest nim brak wysokiej jakości danych testowych na samym starcie. Generowanie syntetycznych danych za pomocą DeepEval Synthesizer to sposób na ominięcie tej blokady. Wyobraź sobie startup budujący wewnętrznego bota HR. Musisz od razu uruchomić testy, żeby sprawdzić, czy pobiera odpowiednie zasady. Ale bot jest zupełnie nowy. Nie masz absolutnie żadnych logów zapytań od prawdziwych użytkowników. To klasyczny problem cold-startu dla danych ewaluacyjnych. Nie możesz ewaluować systemu retrieval bez solidnej listy realistycznych pytań, które możesz mu zadać. DeepEval Synthesizer bootstrapuje dataset ewaluacyjny bezpośrednio z twojej surowej bazy wiedzy. Zamiast pisać setki przypadków testowych ręcznie, po prostu wskazujesz narzędziu swoje dokumenty źródłowe. Główna metoda, która za to odpowiada, nazywa się generate goldens from docs. W DeepEval, Golden to określenie na pojedynczy przypadek testowy zawierający input, expected output oraz context. Żeby go użyć, najpierw inicjalizujesz obiekt Synthesizer. Następnie wywołujesz metodę generate goldens from docs i przekazujesz jej tablicę ze ścieżkami do dokumentów. Dla bota HR będą to ścieżki do plików z podręcznikami dla pracowników, politykami urlopowymi i PDF-ami z benefitami. Kiedy uruchamiasz tę metodę, Synthesizer przetwarza pliki i dzieli tekst na mniejsze, łatwe do zarządzania chunki. Następnie używa modelu językowego ewaluatora, żeby zachowywać się jak dociekliwy użytkownik. Model analizuje konkretny chunk podręcznika HR i generuje trafne, realistyczne pytanie bazując wyłącznie na tym tekście. To pytanie jest zapisywane jako syntetyczny input. Synthesizer zapisuje również dokładny chunk tekstu, który posłużył jako inspiracja do pytania. Staje się on twoim expected context. Na koniec model formułuje idealną, opartą na faktach odpowiedź na to pytanie i zapisuje ją jako expected output. I to jest najważniejsza część. Ludzie często źle rozumieją granice syntetycznej generacji. Synthesizer tworzy tylko inputy, expected context i expected output. Nie generuje actual output. Znalezienie actual output to zadanie twojej własnej aplikacji HR podczas fazy testowania. Pomyśl o Synthesizerze jak o nauczycielu, który układa egzamin i tworzy klucz odpowiedzi. Twój bot wciąż musi do tego egzaminu podejść. Możesz kontrolować zakres tej generacji. Wywołując metodę, możesz określić, ile przypadków testowych wygenerować na dokument. Dzięki temu proces pozostaje szybki i tani dla szybkich iteracji, albo możesz go przeskalować, żeby uzyskać kompleksowe pokrycie. Kiedy metoda skończy działanie, wyciągasz wygenerowane Goldeny i je zapisujesz. Możesz wyeksportować dataset lokalnie jako plik JSON, albo wypchnąć go bezpośrednio do Confident AI, żeby śledzić wersje swojego datasetu w czasie. Bootstrappowanie syntetycznych datasetów pozwala ci przejść od czekania, aż prawdziwi użytkownicy obnażą błędy w twoim systemie, do systematycznego testowania absolutnych granic logiki twoich dokumentów już od pierwszego dnia. Dzięki za wysłuchanie, miłego kodowania wszystkim!

Cześć, tu Alex z DEV STORIES DOT EU. DeepEval Framework, odcinek 12 z 18. Podstawowe syntetyczne zapytania generowane z twoich dokumentów są zbyt proste. Nowoczesne modele językowe bez problemu radzą sobie z prostymi pytaniami, pozostawiając niebezpieczne luki logiczne całkowicie nieprzetestowane. Aby znaleźć prawdziwe punkty krytyczne w twojej aplikacji, musisz sztucznie zwiększyć poziom trudności swoich danych testowych. Osiągamy to dzięki Evolving Synthetic Complexity. Standardowe generowanie tworzy proste, bezpośrednie pytania. Ewolucja matematycznie komplikuje te pytania, aby zrobić stress-test twojego systemu. Ludzie czasami mylą to ze zmianą samych faktów. Ewolucja syntetycznego zapytania nie oznacza zmiany ground truth. Dane źródłowe pozostają dokładnie takie same. Zmienia się natomiast strukturalna trudność zapytania, które o te dane pyta. W DeepEval kontrolujesz ten proces mutacji za pomocą Evolution Config. Ta konfiguracja stosuje określone strategie ewolucyjne, aby przekształcić podstawowy prompt w edge case z wieloma ograniczeniami. Weźmy proste syntetyczne pytanie, na przykład: jaka jest polityka zwrotów? Jest proste, ale zbyt ogólne, by stanowić rygorystyczny test. Pierwszą strategią, którą możesz zastosować, jest Concretizing evolution. Bierze ona abstrakcyjne zapytanie i wtłacza je w bardzo specyficzny, namacalny scenariusz. Zamiast pytać o ogólną zasadę, Concretizing mutuje zapytanie w coś w stylu: jeśli kupiłem czerwoną koszulkę we wtorek, czy mogę ją zwrócić w przyszłym tygodniu? Model musi teraz zmapować specyficzne ograniczenia użytkownika na ogólną zasadę. Drugą strategią jest Reasoning evolution. Wprowadza ona wymaganą warstwę dedukcji. Wyewoluowane pytanie zmusza model do wykonania logicznych kroków, zanim będzie mógł podać ostateczną odpowiedź. Zamiast po prostu wyciągnąć fakt, zapytanie może wymagać od systemu obliczenia dat, porównania wartości lub przejścia przez warunkowy logic chain oparty na tekście źródłowym, zanim sformułuje odpowiedź. Trzecia strategia to Multicontext evolution. Testuje ona retrieval i syntezę, zmuszając model do wyciągania odpowiedzi z rozproszonych fragmentów informacji. Modyfikuje zapytanie tak, aby odpowiedź nie mogła zostać wyciągnięta z pojedynczego akapitu. Aby sobie poradzić, model językowy musi połączyć ogólny czas na zwrot z jednego dokumentu z konkretnymi wykluczeniami dla produktów z wyprzedaży z zupełnie innej sekcji. Kiedy sztucznie mutujesz tysiące zapytań za pomocą tych strategii, niektóre z nich nieuchronnie ulegną degradacji. Wyewoluowane pytanie może stać się tak zawiłe, że odpowiedź na nie będzie po prostu niemożliwa, albo może całkowicie odbiec od pierwotnych faktów. To dokładnie ten problem, który rozwiązuje Filtration Config. Nie możesz pozwolić, aby nierozwiązywalny szum zanieczyścił twój ewaluacyjny dataset. Filtration wykorzystuje oddzielny critic model, który działa jak strażnik kontroli jakości. Sprawdza każde nowo wyewoluowane zapytanie pod kątem ścisłych kryteriów, zanim zostanie zapisane. Jeśli zmutowane pytanie jest logicznie zepsute, nie pasuje już do źródłowego kontekstu albo zamienia się w bełkot, critic model po prostu je odrzuca. Ten dwuetapowy proces gwarantuje, że generujesz pytania, które są niezwykle trudne, ale nadal całkowicie poprawne. Wysoki wynik na podstawowych syntetycznych danych nie dowodzi niczego o odporności twojego systemu; prawdziwą niezawodność modelu mierzy się tylko tym, jak radzi sobie z celowo wyewoluowanymi, złożonymi edge case'ami, które standardowe generowanie zostawia w tyle. Dzięki za wysłuchanie, miłego kodowania wszystkim!

Cześć, tu Alex z DEV STORIES DOT EU. DeepEval Framework, odcinek 13 z 18. Ewaluacje end-to-end mówią ci, czy system zawiódł, ale nie dają odpowiedzi dlaczego. Tracing na poziomie komponentów dokładnie pokazuje, która konkretna funkcja się wysypała. Dzisiaj przyjrzymy się tematom takim jak tracing i observability w LLM-ach. Weźmy na warsztat standardowy pipeline Retrieval-Augmented Generation. Użytkownik zadaje skomplikowane pytanie, a twój system po dziesięciu sekundach zwraca wyhalucynowaną odpowiedź. Musisz dokładnie wiedzieć, co poszło nie tak. Czy funkcja retrievalu dla embeddingów wyciągnęła nieistotne dokumenty z bazy danych, czy może końcowy krok generacji przez model językowy po prostu nie potrafił zsyntetyzować odpowiedniego kontekstu? Nie możesz tego skutecznie zdebugować, patrząc tylko na ostateczny output. Musisz przeanalizować wewnętrzne kroki. Aby to zrobić, musisz zrozumieć dwa podstawowe pojęcia, które często są ze sobą mylone: Trace'y i Spany. Trace to pełne drzewo wykonania pojedynczej operacji. Reprezentuje kompletną oś czasu od momentu, gdy użytkownik wysyła prompt, aż do chwili, gdy system dostarcza ostateczną odpowiedź. Z kolei Span to konkretny komponent lub funkcja działająca wewnątrz tego Trace'a. Wykonanie całego twojego pipeline'u to jeden Trace. Funkcja, która odpytuje wektorową bazę danych, to jeden Span. Funkcja formatująca prompt to kolejny Span. Samo wywołanie dużego modelu językowego to trzeci Span. Każdy Trace jest zbudowany z takich zagnieżdżonych Spanów. Każdy Span rejestruje swój własny czas startu, czas zakończenia, parametry wejściowe i ostateczny output. W DeepEval przechwytujesz tę hierarchię za pomocą dekoratora observe. Po prostu umieszczasz słowo observe ze znakiem małpy bezpośrednio nad funkcjami w Pythonie, które chcesz monitorować. Dodajesz go do swojej głównej funkcji entry-point, a także do wewnętrznych funkcji pomocniczych, takich jak twój retriever i generator. Kiedy twoja aplikacja działa, dekorator observe automatycznie przechwytuje jej wykonanie. Loguje dokładne argumenty przekazane do funkcji i dokładne zwrócone dane. Śledzi również latency i wszelkie błędy, które wystąpią. Co ważniejsze, rozumie kontekst wykonania. Jeśli twoja główna funkcja pipeline'u wywołuje funkcję retrievera, dekorator automatycznie rejestruje retriever jako child Span głównego Trace'a. Mapuje relacje parent-child twoich funkcji, bez konieczności ich ręcznego linkowania. I tu jest kluczowa sprawa. Taki tracing jest całkowicie bezinwazyjny. Nie musisz przepisywać codebase'u swojej aplikacji, żeby generować telemetrię. Nie musisz zmieniać sygnatur funkcji, żeby przekazywać trace ID czy obiekty kontekstu w dół call stacka. Utrzymujesz czystą logikę biznesową i po prostu opakowujesz te komponenty, na których ci zależy. Robiąc to, izolujesz dane dla każdego pojedynczego kroku. Jeśli później zechcesz poddać ewaluacji tylko logikę retrievalu, dokładne inputy i outputy tego konkretnego Spana są już zalogowane. Robisz ewaluację end-to-end, żeby zmierzyć końcowe user experience, ale używasz tracingu na poziomie komponentów, żeby faktycznie zlokalizować i naprawić kod pod spodem. Dzięki za wysłuchanie, udanego kodowania wszystkim!

Cześć, tu Alex z DEV STORIES DOT EU. DeepEval Framework, odcinek 14 z 18. W złożonych workflowach autonomicznych agentów nie zawsze wiesz, jaki powinien być test case, dopóki agent nie zacznie się faktycznie wykonywać. Nie możesz napisać kompleksowego, statycznego test suite'a dla pośrednich decyzji, które jeszcze nie zapadły. Dynamiczne evals w runtime rozwiązują to ograniczenie, pozwalając ci konstruować i ewaluować test case'y w locie. Zazwyczaj developerzy definiują statyczne test case'y zewnętrznie. Tworzysz plik ze sztywnymi inputami i oczekiwanymi outputami, a następnie uruchamiasz na nich swoją aplikację. To podejście zawodzi w przypadku systemów autonomicznych. Gdy agent otrzyma prompt, może zroutować zapytanie, wybrać wyspecjalizowanego toola i wygenerować swój własny, wewnętrzny search string. Te pośrednie inputy i outputy nie istnieją, dopóki kod faktycznie nie zacznie działać. Dynamiczne evals porzucają zewnętrzny plik. Zamiast tego, budują test case krok po kroku, w miarę jak zmienne wypełniają się wewnątrz działającej aplikacji. Wyobraź sobie konkretny scenariusz. Musisz wyewaluować context precision wewnątrz głęboko zagnieżdżonej funkcji retrievera. Chcesz przetestować tylko ten jeden, konkretny krok w locie, odizolowany od końcowego outputu, który widzi użytkownik. Aby to zrobić, DeepEval udostępnia dwie konkretne funkcje do przechwytywania danych z wykonania: update current span oraz update current trace. Trace rejestruje cały cykl życia requestu, od początkowego inputu użytkownika aż po ostateczną odpowiedź. Span reprezentuje jedną konkretną operację wewnątrz tego trace'a, taką jak twoja funkcja retrievera. Kiedy ta funkcja retrievera się wykonuje, dynamiczne zmienne w końcu się materializują. Masz teraz dokładny search string wygenerowany przez agenta oraz konkretne chunki tekstu, które zwróciła twoja baza danych. Dokładnie w tym momencie, wewnątrz logiki retrievera, wywołujesz update current span. Używasz tej funkcji, aby przechwycić te zmienne na żywo i zmapować je bezpośrednio na nowy test case. Bierzesz przechwycony search string i przypisujesz go jako test input. Bierzesz surowe chunki z bazy danych i przypisujesz je jako retrieval context. Właśnie skonstruowałeś golden test case podczas wykonania. Ponieważ zbudowałeś tego goldena dynamicznie wewnątrz spana, możesz go natychmiast wyewaluować. Aplikujesz swoją metrykę context precision dokładnie w tym miejscu. Metryka uruchamia się na danych na żywo, ocenia krok retrievera i przypina ten wynik bezpośrednio do lokalnego spana. Kiedy później przeglądasz swoje trace'y, nie widzisz tylko, że nastąpił retrieval. Widzisz wysoce precyzyjną ewaluację tego konkretnego retrievala, opartą na dokładnych warunkach tego runa. To tyle, jeśli chodzi o granularne kroki. Czasami jednak zagnieżdżona operacja odkrywa coś, co zmienia kontekst całego requestu. Wtedy właśnie niezbędne staje się użycie update current trace. Podczas gdy update current span modyfikuje lokalny krok, update current trace pozwala głęboko zagnieżdżonej funkcji sięgnąć wyżej i zmodyfikować globalny rekord wykonania. Jeśli twój agent odkryje w locie informacje, które całkowicie zmieniają to, jak powinna wyglądać ostateczna odpowiedź, wywołujesz update current trace, aby zaktualizować oczekiwany output dla całego runa. Dzięki temu globalna ewaluacja pozostaje w zgodzie z żywą, zmieniającą się rzeczywistością logiki wykonania. Oto kluczowy wniosek. Przeniesienie ewaluacji z zewnętrznych plików do drzewa wykonania w runtime przekształca testowanie z analizy post-mortem w mechanizm diagnostyki na żywo. Wiążąc metryki bezpośrednio ze spanami podczas ich wykonywania, przestajesz zgadywać, dlaczego wieloetapowy agent zawiódł, i zaczynasz dokładnie mierzyć, który wewnętrzny handoff spowodował błąd. Dzięki za wysłuchanie, miłego kodowania wszystkim!

Cześć, tu Alex z DEV STORIES DOT EU. DeepEval Framework, odcinek 15 z 18. Twój LLM może idealnie odpowiedzieć na każde standardowe pytanie. Ale co się stanie, gdy złośliwy użytkownik aktywnie spróbuje zrobić jailbreak Twojej aplikacji, żeby zmusić ją do wycieku poufnych danych? To wymaga zupełnie innego podejścia, i tak przechodzimy do wprowadzenia do Red Teamingu. Żeby zrozumieć red teaming, musisz zmienić sposób, w jaki patrzysz na swój system. Standardowa ewaluacja testuje funkcjonalność. Mierzy, czy Twój model jest pomocny, dokładny i trafny, gdy używa się go w prawidłowy sposób. Red teaming testuje bezpieczeństwo, niezawodność i guardrails. Wymaga to zmiany nastawienia ze sprawdzania poprawności na symulowanie działań złośliwych użytkowników. Aktywnie próbujesz sprawić, żeby model popełnił błąd. Weźmy na warsztat typowy scenariusz. Jeśli bezpośrednio poprosisz swoją aplikację AI o zwrócenie profilu użytkownika jako output, standardowe guardrails prawdopodobnie to wyłapią. AI kategorycznie odmówi wycieku danych osobowych, czyli PII. Standardowa ewaluacja uzna to za sukces. Ale złośliwy użytkownik nie zapyta wprost. Może on wysłać prompt do modelu, przyjmując konkretną, złośliwą personę i instruując AI, żeby działało jako senior database administrator wykonujący awaryjne obejście systemu. Nagle AI posłusznie wykonuje polecenie i chętnie ujawnia PII. Red teaming to systematyczny proces odkrywania dokładnie takich martwych punktów, zanim trafią na produkcję. DeepEval opiera ten proces na czterech głównych komponentach. Pierwszy komponent to Vulnerabilities. Vulnerability to konkretna słabość, ryzyko lub szkoda, pod kątem której testujesz system. To fundamentalny problem, któremu chcesz zapobiec. W naszym scenariuszu awaryjnego obejścia, tą podatnością jest wyciek PII. Inne podatności mogą obejmować generowanie toksycznego outputu, wykazywanie nieautoryzowanego biasu lub udzielanie niebezpiecznych porad. Drugi komponent to Adversarial Attacks. Jeśli podatność jest celem, atak jest bronią. Ataki to konkretne techniki lub środki używane do wykorzystania danej podatności. Przyjęcie zaufanej persony w celu oszukania AI to jeden z rodzajów ataku. Inne obejmują prompt injection, gdzie złośliwe instrukcje są ukryte w zwykłym inpucie, albo złożone jailbreaki zaprojektowane tak, żeby całkowicie ominąć trening bezpieczeństwa modelu. DeepEval oddziela słabość od taktyki, ponieważ pojedyncza podatność może zostać obnażona przez wiele różnych typów ataków. Trzeci komponent to Target LLM System. To właściwa aplikacja, którą ewaluujesz. To nie tylko surowy foundation model, ale Twoja konkretna architektura. Obejmuje to Twoje customowe system prompty, mechanizmy retrievalu i wszelkie istniejące filtry bezpieczeństwa. Adversarial attacks są przeprowadzane bezpośrednio na tym setupie, żeby sprawdzić, jak Twój rzeczywisty produkt radzi sobie pod presją. Czwarty komponent to Metrics. Kiedy atak zostanie przeprowadzony na Twój target system w celu zbadania podatności, potrzebujesz mierzalnego wyniku. Metryki ewaluują odpowiedź systemu. Określają, czy atak skutecznie ominął guardrails, czy też system bezpiecznie odrzucił złośliwe żądanie. Metryka ocenia interakcję, dając Ci konkretny wynik pass lub fail na podstawie tego, jak bezpieczny w rzeczywistości był output. Oto kluczowy wniosek. Nie możesz zabezpieczyć aplikacji AI tylko udowadniając, że robi to, co trzeba, gdy grzecznie ją o to poprosisz; musisz systematycznie udowadniać, że odmawia zrobienia czegoś złego, gdy jest atakowana. Dzięki za wysłuchanie, happy coding wszystkim!

Cześć, tu Alex z DEV STORIES DOT EU. DeepEval Framework, odcinek 16 z 18. Nie powinieneś musieć ręcznie wpisywać tysięcy podchwytliwych inputów, żeby znaleźć luki w zabezpieczeniach swojej aplikacji. Zamiast płacić zespołowi security za ręczne próby złamania twojego systemu tygodniami, możesz pozwolić, by AI autonomicznie zaatakowało twoje AI. Dzisiaj przyjrzymy się wykonywaniu ataków adwersarskich. Aby zorkiestrować zautomatyzowany atak LLM-on-LLM, silnik skanujący potrzebuje bezpośredniej linii komunikacji z twoją aplikacją. Nawiązujesz to połączenie, definiując callback modelu docelowego. To asynchroniczna funkcja w Pythonie, którą musisz napisać. Przyjmuje ona pojedynczy argument typu string, którym jest adversarial prompt wygenerowany przez silnik testujący, i musi zwrócić odpowiedź z twojego systemu również jako string. W typowym scenariuszu z użyciem modelu OpenAI, definiujesz tę asynchroniczną funkcję callback, bierzesz przychodzący parametr prompt, przekazujesz go do swojego klienta OpenAI, robisz await na generację i zwracasz końcowy tekst. Ten callback działa jak most. Silnik red teaming nie musi znać twojej wewnętrznej architektury, kluczy API ani stanu bazy danych. Potrzebuje tylko funkcji, w którą może bez przerwy uderzać złośliwymi inputami. Kiedy twój callback jest gotowy, przekazujesz go do funkcji red team. To główny orkiestrator, który uruchamia skan. Aby go skonfigurować, podajesz dwie odrębne listy: podatności i ataki. Zrozumienie różnicy między nimi jest kluczowe. Podatności to konkretne wady strukturalne lub szkodliwe zachowania, które chcesz przetestować. Na przykład, jeśli chcesz się upewnić, że twoja aplikacja nie generuje uprzedzeń rasowych lub płciowych, importujesz i przekazujesz podatność Bias do funkcji red team. Z kolei ataki reprezentują metodologię, której silnik użyje, żeby spróbować ujawnić tę podatność. Aby zmusić model do wygenerowania stronniczej wypowiedzi, możesz chcieć, żeby silnik użył zwodniczych sformułowań lub technik jailbreak. Robisz to, przekazując atak Prompt Injection. Silnik będzie teraz autonomicznie generował ukierunkowane, złośliwe prompty przy użyciu prompt injection, specjalnie zaprojektowane tak, aby ominąć twoje system prompty i wyzwolić podatność Bias. Częstym powodem do nieporozumień podczas tego setupu jest to, jak wyniki są właściwie oceniane. W standardowej ewaluacji spędzasz dużo czasu na definiowaniu i tunowaniu konkretnych metryk. Podczas wykonywania ataków adwersarskich, nie definiuj metryk ręcznie. Framework zajmuje się tym całkowicie w tle. Automatycznie mapuje wybraną przez ciebie podatność bezpośrednio na odpowiadającą jej wewnętrzną metrykę ewaluacji. Ponieważ kazałeś mu testować pod kątem Bias, silnik automatycznie uruchamia ewaluator biasu dla każdej pojedynczej odpowiedzi, którą zwraca callback twojego modelu docelowego. Po tym, jak funkcja red team skończy odpalać te wygenerowane prompty i ewaluować odpowiedzi, wyrzuca kompleksowy Risk Assessment. Ten assessment zapewnia przejrzyste podsumowanie skanu. Pokazuje dokładnie, ile ataków spróbowano przeprowadzić, które konkretnie techniki ataku skutecznie przełamały twój system, oraz dokładne stringi wejściowe, które spowodowały błąd. Wychodzisz z konkretną listą inputów, z którymi twój system obecnie nie potrafi sobie poradzić. Oto kluczowy wniosek. Prawdziwa siła tego setupu polega na odsprzęgnięciu metody ataku od docelowej podatności, co pozwala ci zwielokrotnić pokrycie bezpieczeństwa poprzez sparowanie pojedynczej wady, takiej jak bias, z dziesiątkami różnych wektorów ataku jednocześnie. Dzięki za wysłuchanie, miłego kodowania wszystkim!

Cześć, tu Alex z DEV STORIES DOT EU. DeepEval Framework, odcinek 17 z 18. Nigdy nie zmergowałbyś pull requesta dla tradycyjnego kodu bez wcześniejszego uruchomienia unit testów. Mimo to zespoły rutynowo deployują niedeterministyczne modele językowe i po prostu liczą na to, że nowe prompty nadal działają. Jeśli chcesz zapobiec temu, by złe aktualizacje modeli zepsuły produkcję, potrzebujesz CI/CD i Continuous Evaluation. DeepEval traktuje ewaluacje modeli językowych dokładnie tak samo jak standardowe testy oprogramowania, integrując się bezpośrednio z Pytestem. Definiujesz funkcję testową, inicjalizujesz metryki ewaluacji i robisz assert, że metryka przechodzi. Ewaluacja modelu na pojedynczym inputcie jest bezużyteczna, dlatego musisz zwalidować zmiany na dużej paczce zatwierdzonych, bazowych inputów i oczekiwanych outputów. To jest twój złoty dataset. Aby sprawnie iterować po tym datasecie, używasz standardowego dekoratora Pytest mark parametrize. Ładujesz swój dataset, wyciągasz poszczególne test case'y i przekazujesz je do dekoratora. Kiedy test suite się uruchamia, Pytest dynamicznie generuje osobne wykonanie testu dla każdego pojedynczego elementu w twoim złotym datasecie. Oto kluczowa sprawa. Ponieważ framework ściśle integruje się z Pytestem, developerzy często zakładają, że mogą po prostu odpalać standardowe komendy Pytesta w terminalu. Nie rób tego. Jeśli odpalisz Pytesta bezpośrednio na swoich plikach ewaluacyjnych, natrafisz na nieoczekiwane błędy związane z asynchronicznymi event loopami i brakującą telemetrią metryk. Musisz zawsze używać dedykowanego command line interface. Prawidłowa komenda to deepeval test run, a po niej nazwa twojego pliku w Pythonie. Ten wrapper obsługuje złożony asynchroniczny setup wymagany przez modele językowe i upewnia się, że wszystkie wyniki testów są poprawnie przechwytywane i logowane. Zintegrowanie tej komendy z twoim deployment pipeline'em daje ci Continuous Evaluation. Weźmy pod uwagę typowy setup GitHub Actions. Konfigurujesz workflow tak, aby triggerował się za każdym razem, gdy inżynier otworzy pull request do brancha main. Runner akcji robi checkout repozytorium, stawia środowisko Pythona i odpala deepeval test run na skrypcie twojego złotego datasetu. Framework ewaluuje nowo zmodyfikowany kod lub prompt w odniesieniu do każdego historycznego test case'a. Jeśli developer zmieni system prompt, aby odpowiedzi były bardziej zwięzłe, może przypadkowo poinstruować model, by usunął obowiązkowe ostrzeżenia o zgodności. Kiedy odpala się CI pipeline, zautomatyzowana ewaluacja natychmiast wychwytuje ten brakujący kontekst. Jeśli nowa logika sprawi, że twój wynik ewaluacji spadnie poniżej zdefiniowanego progu w jakimkolwiek test case'ie, assert nie przechodzi. Skrypt zwraca niezerowy exit code, GitHub Action natychmiast świeci na czerwono, a pull request zostaje zablokowany przed zmergowaniem. Ten zautomatyzowany check przed deploymentem działa jak surowy gatekeeper. Automatycznie wychwytuje regresje. Nie musisz już ręcznie wyrywkowo sprawdzać outputów ani czekać, aż użytkownicy zaczną narzekać, że podmiana modelu zepsuła konkretny edge case. Pipeline matematycznie dowodzi, czy aktualizacja jest bezpieczna do zdeployowania, całkowicie eliminując ludzką subiektywność z procesu release'u. Continuous Evaluation oznacza, że przestajesz traktować prompt engineering jak operacyjny hazard, a zaczynasz traktować go jak przewidywalny software release poparty twardymi danymi. Dzięki za wysłuchanie, udanego kodowania wszystkim!

Cześć, tu Alex z DEV STORIES DOT EU. DeepEval Framework, odcinek 18 z 18. Spędzasz godziny na lokalnym dostrajaniu prompta, osiągasz świetny wynik ewaluacji i robisz deploy kodu. Dwa tygodnie później inny inżynier aktualizuje model bazowy i nagle aplikacja przestaje działać na edge case'ach, których nikt nie śledził. Lokalne uruchamianie ewaluacji to tylko połowa sukcesu. W tym odcinku dowiesz się, jak skalować testy i śledzić regresje w czasie za pomocą Confident AI. Na początek ważne rozróżnienie. DeepEval to framework open source, który uruchamiasz w terminalu lub środowisku Python, żeby wykonywać testy. Confident AI to hostowana platforma chmurowa zbudowana na jego bazie. Używasz DeepEval do definiowania metryk i uruchamiania samych ewaluacji. Z kolei Confident AI używasz do centralizacji, śledzenia i analizowania tych raportów z ewaluacji w całej organizacji inżynierskiej. Bierze on odizolowane lokalne skrypty i przekształca je we wspólny system rejestrowania. Przejście z lokalnego wykonywania do logowania w chmurze wymaga jednego prostego kroku. W terminalu wykonujesz polecenie deepeval login. CLI wyświetli prompt z prośbą o podanie klucza API wygenerowanego z twojego workspace'a Confident AI. Po uwierzytelnieniu twój codzienny workflow pozostaje dokładnie taki sam. Uruchamiasz swoje pliki testowe za pomocą standardowego polecenia test. Framework automatycznie wykrywa aktywną sesję i streamuje wyniki bezpośrednio do dashboardu w chmurze, jednocześnie wypisując je lokalnie. Centralizacja raportów umożliwia metodyczne śledzenie regresji. Regresja występuje, gdy zmiana w twoim kodzie lub konfiguracji nieumyślnie obniża wydajność systemu. Aby zdiagnozować przyczynę regresji, musisz dokładnie śledzić, co zmieniło się między uruchomieniami testów. Robi się to poprzez logowanie hiperparametrów. W kontekście ewaluacji modeli językowych, hiperparametr to dowolna zmienna, która zmienia zachowanie twojego pipeline'u. Obejmuje to architekturę modelu, ustawienie temperatury, chunk size używany do retrievalu, a nawet konkretną wersję szablonu prompta. Kiedy skonfigurujesz DeepEval do logowania tych hiperparametrów, są one dołączane do każdego uruchomienia testu wysyłanego do Confident AI. Wyobraź sobie zespół próbujący zaktualizować swoją aplikację. Chcą wiedzieć, czy przejście z GPT-4o na Claude 3.5 Sonnet faktycznie poprawia ogólny wynik ich pipeline'u. Konfigurują nazwę modelu jako śledzony hiperparametr. Gdy inżynier uruchamia pakiet ewaluacyjny z użyciem nowego modelu, Confident AI loguje nową nazwę modelu wraz z wynikami dla metryk, takich jak precyzja kontekstowa czy spójność faktyczna. I tu pojawia się kluczowy wniosek. Ponieważ wszystkie historyczne przebiegi testów są zapisywane w chmurze, zespół może wyświetlić oś czasu, porównującą dokładne zmiany hiperparametrów ze skumulowanymi wynikami ewaluacji. Jeśli przejście na nowy model zwiększa trafność odpowiedzi, ale drastycznie obniża spójność faktograficzną, dashboard natychmiast podświetla tę regresję. Wszyscy w zespole widzą te same dane. Nigdy więcej nie musisz parsować starych outputów z konsoli ani polegać na pamięci, żeby ocenić, czy zmiana konfiguracji była udana. Ciągła ewaluacja wymaga historycznego baseline'u. Bez scentralizowanego systemu wiążącego twoje konfiguracje bezpośrednio z wynikami ewaluacji, po prostu przeprowadzasz izolowane eksperymenty, a nie budujesz niezawodnego systemu. To kończy naszą serię o frameworku DeepEval. Gorąco zachęcam cię do zapoznania się z oficjalną dokumentacją i wypróbowania tych ewaluacji w praktyce. Jeśli masz jakieś techniczne tematy, które chciałbyś zobaczyć w przyszłych seriach, odwiedź devstories dot eu, żeby zostawić sugestię. Dzięki za wysłuchanie, miłego kodowania wszystkim!