DeepEval Framework (2026 Edition)

Hallo, hier ist Alex von DEV STORIES DOT EU. DeepEval Framework, Folge 1 von 18. Die meisten Teams evaluieren ihre neu deployten Sprachmodelle, indem sie manuell ein Spreadsheet mit Antworten durchlesen. Das ist langsam, stark biased und unmöglich zu skalieren, wenn eine Application wächst. DeepEval ist das Open-Source Evaluation Framework, das diese manuelle Arbeit ersetzt und quasi als Pytest für LLMs fungiert. Angenommen, dein Team deployt eine neue generative Application. Du musst sicherstellen, dass sie sich korrekt verhält, bevor du sie in Production pushst. Mit DeepEval schreibst du Tests genau so, wie du standardmäßige Python Unit Tests schreibst. Du erstellst eine Datei namens test example dot py. In dieser Datei baust du einen Test Case. Dieses Test-Case-Objekt enthält den initialen Input Prompt, den tatsächlichen Output, den deine Application generiert hat, und alle erwarteten Target Answers. Anschließend wendest du eine Evaluation Metric auf diesen Test Case an. Anstatt einen Standard-Equality-Check durchzuführen, um zu prüfen, ob Variable A exakt mit Variable B übereinstimmt, nutzt du eine spezielle Assertion Function, die vom Framework bereitgestellt wird. Du führst diese Datei über deine Command Line mit dem Standard-Pytest-Befehl aus. Das Framework führt die Tests parallel aus, fängt die Assertions ab und meldet Passes und Failures direkt in deinem Terminal. Hier ist der entscheidende Punkt. Standardmäßige deterministische Tests können die Qualität oder Genauigkeit menschlicher Sprache nicht bewerten. Wenn ein User deine Application nach einer Zusammenfassung eines Dokuments fragt, gibt es Tausende von korrekten Möglichkeiten, diese Zusammenfassung zu schreiben. Regex Patterns und exaktes String Matching sind hier nutzlos, da sie keine semantische Bedeutung interpretieren können. DeepEval bewältigt diese enorme Variabilität mithilfe eines Konzepts namens LLM-as-a-judge. Das Framework nutzt ein extrem leistungsstarkes, generalisiertes Sprachmodell, um die spezifischen Outputs deiner eigenen Application zu evaluieren. Das Judge-Modell liest den Output deiner Application, vergleicht ihn mit den strengen Kriterien der von dir gewählten Metric und berechnet einen numerischen Score. Noch wichtiger ist, dass es ein Boolean Result ausgibt, das anzeigt, ob der Score deinen vordefinierten Threshold erreicht, zusammen mit einer Begründung im Plain Text, die genau erklärt, warum es diesen Score vergeben hat. Das bedeutet, dass dir ein fehlgeschlagener Test sofortigen Debugging-Kontext liefert. Beim Designen dieser Test Cases musst du zwischen zwei verschiedenen Evaluation-Modi wählen. Es ist leicht, den Scope dieser Modi zu verwechseln, also lass uns eine klare Trennlinie ziehen. Die End-to-End Evaluation betrachtet lediglich den initialen Input und den finalen Output. Die gesamte Application wird als Black Box behandelt. Du übergibst einen Prompt, das System liefert eine Antwort, und der Judge scored diesen finalen Text. Es ignoriert völlig, wie die Application die Response generiert hat. Die Component-Level Evaluation ist ein White-Box-Ansatz. Anstatt nur die finale Antwort zu checken, traced dieser Modus die spezifischen internen Schritte, die deine Application gemacht hat, um dorthin zu gelangen. Wenn dein System eine Datenbank durchsucht, um Kontext-Dokumente abzurufen, bevor es seinen Text generiert, evaluiert ein Component-Level Test genau diesen Suchschritt. Er checkt, ob die abgerufenen Dokumente tatsächlich relevant für den Prompt des Users waren, völlig unabhängig von der final generierten Response. Du testest die internen Mechanismen, nicht nur das finale Produkt. Du kannst ein System haben, das einen End-to-End Test passed, indem es eine korrekte Antwort gibt, aber bei einem Component-Level Test failed, weil es diese Antwort aus dem falschen internen Dokument gezogen hat. Die Evaluation eines Sprachmodells ist keine subjektive Leseübung mehr; sie ist ein strikter, automatisierter und wiederholbarer Teil deiner Continuous Integration Pipeline. Danke fürs Zuhören, Happy Coding zusammen!

Hallo, hier ist Alex von DEV STORIES DOT EU. DeepEval Framework, Folge 2 von 18. Du kannst nicht messen, was du nicht definiert hast. Wenn sich deine automatisierten Evaluations inkonsistent anfühlen, beginnt das Problem oft schon, bevor die Metric überhaupt läuft. Wahrscheinlich übergibst du die falschen Komponenten deines Prompts an die falschen Evaluation Boundaries. Die Lösung ist, die LLM-Interaktion strikt mit dem LLM Test Case Blueprint zu definieren. Ein LLM Test Case in DeepEval dient als die atomare Einheit der Evaluation. Er zwingt dich, eine einzelne, spezifische Interaktion mit deinem System zu isolieren. Du übergibst keine vollständigen Conversation Logs oder rohen Datenbanken an einen Evaluator. Stattdessen extrahierst du genau, was reinging, was rauskam und welche Hintergrunddaten für einen einzelnen, bestimmten Turn relevant waren. Multi-Turn-Interaktionen haben ihren eigenen spezifischen Blueprint, aber der Standard Test Case konzentriert sich strikt auf einen isolierten Request und eine Response. Jeder Test Case benötigt zwei obligatorische Argumente. Erstens: der Input. Das ist der exakte String, den ein User oder System an das Model gesendet hat. Zweitens: der Actual Output. Das ist der Text, den dein Large Language Model als Response generiert hat. Selbst wenn du sonst nichts evaluierst, musst du diese beiden Parameter übergeben, um grundlegende Metrics wie Toxicity oder Answer Relevance zu messen. Stell dir einen Customer Support Chatbot vor. Der Input ist ein User, der fragt, ob er ein Paar getragene Schuhe nach fünfunddreißig Tagen zurückgeben kann. Der Actual Output ist dein Model, das eine Response generiert, die die Rückgabe ablehnt. Um zu evaluieren, ob diese Ablehnung wirklich korrekt ist, musst du eine Baseline Truth bereitstellen. DeepEval gibt dir dafür zwei verschiedene optionale Parameter. Das sind Expected Output und Context. Developer verwechseln diese ständig. Context ist rein faktisch. Er enthält die rohe, unformatierte Wahrheit, wie einen Text-String aus deiner Corporate Policy, der ein striktes dreißig-Tage-Limit für Rückerstattungen festlegt. Expected Output ist viel spezifischer. Er diktiert Tonfall, Linguistik und Formatierung. Du verwendest Expected Output, wenn du willst, dass der Evaluator prüft, ob das Model mit einer höflichen, spezifischen Entschuldigung geantwortet hat, anstatt einfach nur eine plumpe Ablehnung auszugeben. Context verankert die Fakten. Expected Output verankert den Stil und das genaue Phrasing. Hier ist die entscheidende Erkenntnis. Wie du den Rest dieses Test Cases konstruierst, ändert sich je nach deiner zugrundeliegenden Architektur. Wenn du eine Retrieval-Augmented Generation Pipeline evaluierst, musst du den Retrieval Context definieren. Dieser Parameter akzeptiert eine Liste von Strings, die die exakten Document Chunks repräsentieren, die dein Retriever aus der Vector Database gezogen hat. Verwechsle das nicht mit dem Standard-Context-Parameter. Context ist die ideale Wahrheit, die du für den Test hardcodest. Retrieval Context sind die realen Daten, die deine Pipeline in Production tatsächlich gefunden hat. Evaluatoren vergleichen die beiden, um festzustellen, ob dein Search Algorithm die richtigen Dokumente abruft. Wenn du einen Agenten anstelle einer Standard-Pipeline baust, nutzt du den Tools Called Parameter. Dieser akzeptiert eine Liste von Objekten oder Strings, die die spezifischen Funktionen repräsentieren, die der Agent während dieser isolierten Interaktion aufzurufen beschlossen hat, wie zum Beispiel das Triggern eines internen Refund Calculators. Wenn du das übergibst, kannst du agentic Routing-Entscheidungen zusammen mit der finalen Text Generation evaluieren. Die Zuverlässigkeit einer automatisierten Metric hängt vollständig von der Hygiene dieser Parameter ab. Ein Evaluator kann eine Hallucination niemals abstrafen, wenn du es versäumst, den strikten faktischen Context bereitzustellen, gegen den er den Output prüft. Danke fürs Zuhören, Happy Coding zusammen!

Hallo, hier ist Alex von DEV STORIES DOT EU. DeepEval Framework, Folge 3 von 18. Traditionelle NLP-Metriken wie BLEU und ROUGE eignen sich überhaupt nicht dafür, moderne Large Language Models zu evaluieren, aber für jeden einzelnen Test Run einen Menschen einzusetzen, ist unmöglich. Die Lösung, um deine Evaluation zu skalieren, ohne das semantische Verständnis zu opfern, ist die Power von LLM-as-a-Judge. Traditionelle Metriken suchen nach exakten Wortübereinstimmungen. Wenn dein Modell eine perfekt korrekte Zusammenfassung mit anderen Synonymen ausgibt, wird eine Metrik, die auf exaktem String Matching basiert, sie schlecht bewerten, weil sie die Bedeutung nicht versteht. Ein LLM als Judge zu verwenden, löst dieses Problem. Es liest den Output, verarbeitet den Kontext und evaluiert die Semantik ganz ähnlich wie ein menschlicher Reviewer, aber in Maschinengeschwindigkeit. In DeepEval führt eine LLM-evaluierte Metrik drei spezifische Aktionen aus. Erstens berechnet sie einen Score zwischen null und eins. Null ist ein kompletter Fehlschlag, eins ist perfekt. Zweitens vergleicht sie diesen Score mit einem strikten Threshold, den du definierst. Wenn dein Threshold bei 0,7 liegt und das Modell einen Score von 0,6 erreicht, schlägt der Test fehl. Drittens gibt sie eine Begründung zurück. Das evaluierende LLM generiert eine Texterklärung, die genau detailliert, warum es diesen spezifischen Score vergeben hat. Das sagt dir, was schiefgelaufen ist, ohne dich zu zwingen, die Raw Logs manuell zu lesen. DeepEval unterteilt diese Metriken in drei Kategorien. RAG-Metriken evaluieren Retrieval-Augmented Generation Pipelines. Agentic-Metriken evaluieren autonome Agents. Custom-Metriken lassen dich deine eigenen Evaluationskriterien von Grund auf neu definieren. Obwohl sich die zugrunde liegenden Prompts dafür unterscheiden, nutzen sie alle denselben Judge-Mechanismus. Bei der Auswahl einer Metrik verwechseln Developer oft Reference-based und Referenceless Metriken. Hier ist die wichtigste Erkenntnis. Reference-based Metriken erfordern eine Ground Truth. Sie brauchen eine bekannte, korrekte Antwort zum Vergleichen, was sie während der frühen Development- und Testing-Phase extrem effektiv macht. Referenceless Metriken brauchen keine Ground Truth. Sie evaluieren den Output komplett basierend auf dem bereitgestellten Kontext oder dem Input Prompt selbst. Weil sie sich nicht auf eine vorgefertigte Antwort verlassen, sind Referenceless Metriken genau das, was du für Live Production Monitoring verwendest. Es ist verlockend, an jeden Prompt ein Dutzend Metriken anzuhängen, um die Qualität sicherzustellen. Tu das nicht. Die Faustregel ist, weniger als fünf Metriken pro Application zu verwenden. Wähle die Metriken, die wirklich zu deiner spezifischen Business Logic passen. Unnötige Metriken laufen zu lassen, führt nur zu langsameren Tests und höheren Compute Costs. Apropos Kosten: Ein kommerzielles Flagship-Modell als Judge für tausende tägliche Test Runs zu nutzen, wird schnell teuer. DeepEval erlaubt es dir, den Default Evaluator gegen Custom Models auszutauschen. Du kannst das Framework so konfigurieren, dass es Azure OpenAI nutzt, falls deine Enterprise-Infrastruktur das erfordert. Alternativ kannst du ein lokales Modell mit Ollama aufsetzen. Indem du ein fähiges Open-Source-Modell lokal auf deiner eigenen Hardware laufen lässt, erschaffst du einen kostenlosen, unvoreingenommenen Judge. Du initialisierst einfach deinen lokalen Ollama-Client und übergibst dieses Model-Objekt direkt in die Metric Configuration. DeepEval übernimmt dann den Rest und führt die gesamte Evaluation Pipeline aus, ohne externe Billing APIs aufzurufen. Der wahre Wert eines LLM-Judges ist nicht nur der numerische Score, sondern das Automated Reasoning, das er liefert, um dir beim Debuggen jedes einzelnen Fehlers zu helfen. Danke fürs Zuhören, Happy Coding zusammen!

Hallo, hier ist Alex von DEV STORIES DOT EU. DeepEval Framework, Folge 4 von 18. Es ist eine Sache, wenn deine RAG-Pipeline eine Frage beantwortet. Ein ganz anderes Problem ist es, wenn sie selbstbewusst Details erfindet, die in deinen Quelldokumenten gar nicht existieren. Heute schauen wir uns das Evaluieren von RAG-Generatoren an, und ganz besonders, wie man genau diese Fehler abfängt. Eine Retrieval-Augmented Generation Pipeline besteht aus zwei separaten Komponenten. Der Retriever holt sich die relevanten Dokumente. Der Generator nimmt diese Dokumente und schreibt die finale Antwort. Den Retriever ignorieren wir heute. Wir gehen davon aus, dass dein System die richtigen Dokumente bereits gefetcht hat. Unser Fokus liegt ausschließlich auf dem Generator, der den Text synthetisiert. Um sicherzustellen, dass dieser Text sowohl sicher als auch nützlich ist, verlässt du dich auf zwei Metriken: Faithfulness und Answer Relevancy. Die erste Metrik ist Faithfulness. Das ist deine wichtigste Guardrail gegen Halluzinationen. Faithfulness misst, ob die Antwort des Generators, die DeepEval den Actual Output nennt, vollständig durch den Retrieval Context gerechtfertigt werden kann. Stell dir ein Standard-Szenario vor. Ein User fragt deinen Chatbot nach der betrieblichen Krankenversicherung. Der Retriever holt das richtige HR-Handbuch. Der Generator antwortet, dass der Plan medizinische Versorgung, Sehhilfen und eine umfassende Zahnbehandlung abdeckt. Das HR-Handbuch erwähnt die Zahnbehandlung jedoch mit keinem Wort. Der Generator hat eine extrem plausible, gut formatierte Lüge synthetisiert. Die Faithfulness-Metrik fängt genau dieses Verhalten ab. Sie isoliert die Behauptungen im Actual Output und verifiziert sie Stück für Stück gegen den Retrieval Context. Wenn der Generator Fakten einbaut, die im Context fehlen, sinkt der Faithfulness Score. Dabei spielt es keine Rolle, ob der Fakt in der echten Welt zufällig wahr ist. Wenn er nicht explizit durch den bereitgestellten Context gestützt wird, flaggt die Metrik das als Failure. Der zweite Teil davon ist Answer Relevancy. Eine faithful Antwort ist nicht unbedingt eine nützliche Antwort. Der Generator könnte eine absolut akkurate Zusammenfassung des HR-Handbuchs als Output liefern, die komplett ignoriert, was der User eigentlich gefragt hat. Answer Relevancy misst, wie gut der Actual Output direkt auf den ursprünglichen Input eingeht. Sie evaluiert, ob die Response komplett, prägnant und frei von unnötigem Geschwafel ist. Wenn der User nach der Höhe der Selbstbeteiligung fragt, und der Generator listet die Selbstbeteiligung auf, fügt dann aber drei Absätze über die Geschichte der Firmenkrankenversicherung hinzu, sinkt der Answer Relevancy Score. Das System bestraft ausweichende oder aufgeblähte Informationen genauso streng wie fehlende Informationen. Um diese Metriken zu evaluieren, baust du einen Test Case in DeepEval. Du musst drei Variablen übergeben. Erstens den Input, der den User Prompt repräsentiert. Zweitens den Actual Output, also den Text, den dein Generator produziert hat. Drittens den Retrieval Context, der den rohen Text aus den Dokumenten enthält, die dein Retriever an den Generator verfüttert hat. Du übergibst diesen Test Case an beide Metriken. DeepEval evaluiert den Text und berechnet für jede einen Score zwischen null und eins. Du definierst einen Passing Threshold. Wenn eine Response null Komma neun bei Faithfulness erreicht, aber nur null Komma vier bei Answer Relevancy, weißt du, dass der Generator sicher, aber nicht hilfreich ist. Wenn die Scores umgekehrt sind, ist dein Generator hilfreich, aber halluziniert aktiv. Hier ist die entscheidende Erkenntnis. Beim Evaluieren von Generatoren musst du Wahrheit systematisch vom Context entkoppeln. Ein erfolgreicher Generator erzählt nicht die absolute Wahrheit; er erzählt exakt das, was die bereitgestellten Dokumente ihm erlauben, beantwortet nur das, was gefragt wurde, und nichts weiter. Danke fürs Zuhören, Happy Coding zusammen!

Hallo, hier ist Alex von DEV STORIES DOT EU. DeepEval Framework, Folge 5 von 18. Wenn dein LLM schlechte Antworten liefert, liegt das vielleicht gar nicht am Modell. Dein Retriever füttert es vielleicht einfach nur mit Müll. Heute sprechen wir über die Evaluierung von RAG-Retrievern, genauer gesagt über Contextual Precision, Contextual Recall und Contextual Relevancy. Stell dir vor, du fragst eine große Knowledge Base nach einem sehr spezifischen Richtlinien-Detail ab. Anstatt genau den einen Absatz zu extrahieren, den du eigentlich brauchst, schnappt sich dein Retriever zehn Seiten mit nur losem Bezug. Das LLM geht im Rauschen unter, die Token-Kosten steigen und die finale Antwort leidet darunter. Um das zu beheben, musst du den Retrieval-Schritt komplett getrennt vom Generation-Schritt messen. Die erste Metrik ist Contextual Relevancy. Diese Metrik schaut sich die rohen Text-Chunks an, die dein Retriever aus der Datenbank zieht, und berechnet das Verhältnis von relevanten zu allen Sätzen. Wenn du tausend Wörter abrufst, nur um einen einzigen nützlichen Satz zu erwischen, stürzt dein Relevancy-Score ab. Eine hohe Relevancy bedeutet, dass du einen sauberen, dichten Context an den LLM-Prompt übergibst, ohne Tokens für irrelevante Hintergrundinformationen zu verschwenden. Als Nächstes kommt Contextual Recall. Das bewertet, ob dein Retriever alle nötigen Informationen gefunden hat, die für die Beantwortung der User-Query erforderlich sind. DeepEval berechnet das, indem es den Expected Output für eine Query nimmt und alle faktischen Claims daraus extrahiert. Dann scannt es deinen abgerufenen Context, um zu sehen, ob diese spezifischen Claims tatsächlich vorhanden sind. Wenn ein entscheidender Fakt, der für die Antwort gebraucht wird, im Context fehlt, sinkt der Recall-Score. Ein hoher Recall garantiert, dass das LLM auch wirklich das Rohmaterial hat, das es für eine gute Antwort braucht. Dann haben wir noch Contextual Precision. Leute verwechseln Precision oft mit Recall. Recall bedeutet, du hast nichts verpasst. Precision bedeutet, du hast keinen unnötigen Ballast eingebaut. Bei RAG-Evaluierungen spielt Precision eine große Rolle beim Ranking. Sie prüft, ob die hochrelevanten Context-Chunks ganz oben in der abgerufenen Liste stehen. Wenn der eine entscheidende Absatz an Position zehn unter neun nutzlosen Chunks begraben ist, ist dein Precision-Score niedrig. Language Models achten generell mehr auf den Anfang des Prompts, also verändert die Reihenfolge beim Retrieval das Ergebnis komplett. Hier ist die wichtigste Erkenntnis: Es gibt ein ständiges Spannungsverhältnis zwischen Precision und Recall. Wenn du deinen Retriever so konfigurierst, dass er jedes Mal fünfzig Chunks zurückgibt, wird dein Recall wahrscheinlich perfekt sein, weil du ein riesiges Netz auswirfst. Aber deine Precision und Relevancy werden in den Keller stürzen, weil die meisten dieser fünfzig Chunks nur Rauschen sind. Wenn du den Retriever umgekehrt auf genau einen Chunk beschränkst, ist deine Relevancy makellos, aber dein Recall bricht in dem Moment ein, in dem eine User-Query erfordert, zwei verschiedene Fakten aus zwei verschiedenen Dokumenten zu synthetisieren. Um diese Tests im Framework auszuführen, definierst du ein Test Case Objekt. Dieses Objekt enthält den User Input, den Expected Output und eine Liste der tatsächlichen Context-Strings, die dein Retriever aus der Datenbank geholt hat. Du instanziierst die spezifische Metrik, die du willst, wie zum Beispiel eine Contextual Recall Metrik, und übergibst ihr den Test Case. Das Framework nutzt dann unter der Haube ein Evaluation Model, um die Strings zu lesen, die Claims zuzuordnen, eine Strafe für fehlende oder schlecht gerankte Informationen zu berechnen und einen finalen numerischen Score zwischen null und eins zurückzugeben. Deinen Retriever zu evaluieren zwingt dich dazu, dich genau damit auseinanderzusetzen, was du an dein Generation Model übergibst. Eine performante RAG-Pipeline schaufelt nicht einfach nur Daten in ein LLM; sie filtert und rankt diese Daten gnadenlos. Danke fürs Zuhören, Happy Coding zusammen!

Hallo, hier ist Alex von DEV STORIES DOT EU. DeepEval Framework, Folge 6 von 18. Eine einzelne Text-Response zu evaluieren ist unkompliziert: Du vergleichst den finalen Output mit dem Input. Aber wie evaluierst du einen autonomen Agenten, der seine eigenen Schritte bestimmt, durch mehrere Thought Processes loopt und externe Tools triggert? Wenn die finale Antwort zwar korrekt ist, der Agent aber zwanzig unnötige Schritte gemacht und die falsche Datenbank aufgerufen hat, um dorthin zu gelangen, ist dein System kaputt. Um das zu fixen, brauchst du Agentic Evaluation. Wir müssen einen einfachen API Call von einem autonomen Multi-Step Agent Flow trennen. Eine Standard-Integration eines Language Models folgt einem vordefinierten Pfad. Du sendest einen Prompt, und das Modell gibt einen String zurück. Ein Agentic Flow übergibt die Kontrolle an das Modell. Das Modell erhält ein grobes Ziel und entscheidet autonom, welche internen Tools es nutzt, in welcher Reihenfolge, und welche Arguments es an sie übergibt. Wenn du einen Agenten evaluierst, indem du dir nur seinen finalen Text-Output ansiehst, verpasst du die eigentliche Mechanik seines Reasonings. DeepEval löst das mit der Task Completion Metric. Anstatt den finalen Response String zu parsen, analysiert die Task Completion Metric den Execution Trace des Agenten. Ein Trace ist die komplette, sequenzielle Aufzeichnung jedes Thoughts, jeder Action und jeder Tool Invocation, die der Agent während eines bestimmten Runs gemacht hat. Die Task Completion Metric liest diesen Trace, um festzustellen, ob der Agent den User Request durch valide Actions tatsächlich erfüllt hat. Stell dir einen Trip Planner Agent vor. Ein User bittet ihn, ein Wochenende in Rom mit Dinner-Reservierungen zu buchen. Um erfolgreich zu sein, muss der Agent ein Restaurant Finder Tool korrekt aufrufen und diese Daten dann an ein Itinerary Generator Tool übergeben. Wenn der Agent eine perfekt formatierte Reiseroute ausgibt, das Restaurant Finder Tool aber nie tatsächlich ausgeführt hat, wird eine Standard Text Evaluation Metric ihn wahrscheinlich durchwinken. Der Output sieht extrem überzeugend aus. Die Task Completion Metric wird ihn durchfallen lassen. Durch die Analyse des Traces sieht die Metric, dass die nötige Tool Execution fehlt. Der Agent hat die Restaurantdaten halluziniert, anstatt sie abzurufen, und der Trace beweist das. Das verlagert die Evaluation vom finalen Output auf die operativen Schritte. Du musst auch evaluieren, ob die Tools richtig verwendet wurden. DeepEval Test Cases handhaben das mit einem Parameter namens tools called. Wenn du einen Evaluation Test Case baust, übergibst du die Liste der Tools, die der Agent während seiner Execution aufgerufen hat, an diesen tools called Parameter. Diese Daten bereitzustellen, erlaubt es dem Framework, die Tool Correctness zu evaluieren. Die Evaluation verifiziert, ob der Agent die passenden Tools für das spezifische Ziel ausgewählt hat, ob er die korrekten Input Arguments an diese Tools übergeben hat, und ob er die Daten, die die Tools zurückgegeben haben, erfolgreich verarbeitet hat. Wenn dein Trip Planner Agent sich korrekt dafür entschieden hat, das Restaurant Finder Tool zu nutzen, aber die Stadt Paris statt Rom als Argument übergeben hat, fängt die Tool Correctness Evaluation den Fehler genau am Point of Failure ab. Du weißt exakt, welcher Schritt die Chain gebrochen hat. Hier ist die entscheidende Erkenntnis. Agents zu evaluieren bedeutet, in die Black Box zu schauen. Du verifizierst die Integrität des Agent Reasoning Processes und seiner mechanischen Actions Schritt für Schritt. Eine strukturell perfekte finale Antwort ist komplett nutzlos, wenn der Agent sie durch umgangene Tools, halluzinierte Daten und kaputte Logik erreicht hat. Danke fürs Zuhören, happy coding zusammen!

Hallo, hier ist Alex von DEV STORIES DOT EU. DeepEval Framework, Folge 7 von 18. Ein Chatbot gibt vielleicht eine super erste Antwort, aber vergisst schon beim dritten Turn komplett den User Intent oder seine eigene Persona. Deshalb nutzen wir Multi-Turn Conversation Evaluation. Isolierte Antworten zu evaluieren ist einfach, aber echte User senden keine isolierten Prompts. Sie stellen Follow-up-Fragen, ändern ihre Meinung und beziehen sich auf Dinge, die sie vor fünf Minuten gesagt haben. Standard-Evaluationsmethoden versagen hier, weil sie sich nur einen einzigen Input und einen einzigen Output ansehen. Sie haben kein Konzept von Zeit oder Memory. Um zu testen, wie ein Model einen fortlaufenden Dialog handhabt, brauchst du eine Struktur, die den gesamten Thread erfasst. Im Framework machst du das mit einem speziellen Object namens ConversationalTestCase. Anstatt nur einen Input String und einen Output String zu nehmen, erwartet es einen Parameter namens turns. Der turns-Parameter ist eine sequentielle Liste. Jedes Item in dieser Liste repräsentiert ein einzelnes Hin und Her zwischen dem User und dem System. Du ordnest diesen Austausch von der ersten bis zur allerletzten Message. Wenn du die Sequenz in einen ConversationalTestCase wrappst, sagst du der Evaluation Engine, dass sie die gesamte Liste als eine kontinuierliche, stateful Interaktion behandeln soll. Hier gibt es eine typische Falle. Übergib einen ConversationalTestCase nicht an non-conversational Standard-Metrics. Standard-Metrics sind für einzelne Outputs gebaut. Wenn du sie auf ein Multi-Turn Object anwendest, ignorieren sie den historischen Kontext komplett. Du musst dedizierte Conversational Metrics verwenden, um die turns-Liste zu evaluieren. Conversational Metrics evaluieren die Conversation als Ganzes. Sie ziehen den vorherigen Kontext in Betracht, um das dauerhafte Verhalten des Models zu beurteilen. Zwei primäre Beispiele sind Role Adherence und Knowledge Retention. Stell dir einen Customer Support Chatbot vor, der explizit angewiesen wurde, sich wie ein Pirat zu verhalten. In Turn eins sagt der User Hallo, und der Bot antwortet mit Piraten-Slang. In Turn zwei stellt der User eine Frage, und der Bot bleibt in Character. Aber bei Turn drei, wenn der User nach einem Refund fragt, antwortet der Bot mit einer standardmäßigen Corporate-Entschuldigung. Er hat seinen Character komplett abgelegt. Du kannst diesen Fehler automatisch mit der Role Adherence Metric abfangen. Du definierst die Target Persona im Metric Setup, und sie evaluiert die gesamte Conversation, um zu verifizieren, dass das Model nie aus dem Character gefallen ist, selbst als der Kontext länger wurde. Knowledge Retention löst ein anderes Problem. Wenn ein User im ersten Turn eine Accountnummer angibt und im vierten Turn nach einem Status-Update fragt, sollte der Bot nicht noch mal nach der Accountnummer fragen. Die Knowledge Retention Metric scannt die turns-Liste, um sicherzustellen, dass das Model Fakten, die früher in der Chat History eingeführt wurden, erfolgreich abruft und anwendet. Das im Code zu bauen, braucht nur ein paar Schritte. Zuerst erstellst du deine einzelnen Turns und mappst den User Input auf den Model Output für jeden Schritt des Dialogs. Als Nächstes übergibst du diese gesamte Sequenz an einen neuen ConversationalTestCase. Dann setzt du deine Conversational Metric auf und weist Kriterien wie die erwartete Persona zu. Zum Schluss führst du die Metric gegen deinen Test Case aus. Das Framework verarbeitet die komplette History und gibt einen Score basierend auf der kumulierten Interaktion zurück. Hier ist die entscheidende Erkenntnis. Multi-Turn Evaluation verlagert dein Testing von der Messung isolierter technischer Genauigkeit hin zur Messung dauerhafter Verhaltenskonsistenz über die Zeit. Danke fürs Zuhören, Happy Coding zusammen!

Hallo, hier ist Alex von DEV STORIES DOT EU. DeepEval Framework, Folge 8 von 18. Manchmal passen Standard-Metrics nicht zu deinem Use Case, zum Beispiel wenn du prüfen willst, ob ein stark regulierter Finanz-Chatbot professionell genug klingt. Du brauchst einen Weg, um subjektive Eigenschaften zuverlässig zu messen, und genau da kommt das Bauen von Custom Metrics mit G-Eval ins Spiel. Bevor du Custom Metrics definierst, solltest du festlegen, welche Art von Logik du eigentlich misst. G-Eval ist ausschließlich für subjektive Kriterien wie Tonfall, Kohärenz oder den Conversational Flow gedacht. Wenn du strikte objektive Logik erzwingen musst, solltest du DAGs verwenden. G-Eval kümmert sich um die Nuancen der menschlichen Sprache. Um eine Professionalism-Metric für einen Finanz-Chatbot zu bauen, schreibst du keine komplexen Parsing-Regeln. Du nutzt G-Eval, um eine Custom Metric in ganz normaler Alltagssprache zu definieren. Du instanziierst die Metric, indem du ihr einen Namen und einen Criteria String in natürlicher Sprache gibst. Für diesen Chatbot könnten deine Criteria zum Beispiel lauten: Bestimme, ob der Actual Output einen formellen, respektvollen Ton beibehält und Slang oder umgangssprachliche Ausdrücke strikt vermeidet. Hier ist der entscheidende Punkt: Die Metric schickt deine Criteria nicht einfach an ein Large Language Model und fragt nach einem schnellen Score. G-Eval führt einen zweistufigen Chain of Thought Algorithmus aus. Schritt eins ist die Generierung. Der Algorithmus liest deine Criteria in einfachem Englisch und generiert automatisch eine strukturierte Liste von Evaluation Steps. Er schreibt seine eigene Grading Rubric. Für die Professionalism-Metric könnte er einen Step generieren, der nach informellen Begrüßungen scannt, und einen weiteren Step, um die Verwendung angemessener Finanzterminologie zu verifizieren. Schritt zwei ist die eigentliche Evaluation. Der Algorithmus nimmt diese generierten Steps und wendet sie auf deine spezifischen Test Case Parameter an. Ein Standard-G-Eval Test Case enthält typischerweise den User Input und den Actual Output von deinem Model, aber du kannst auch den Expected Output oder den Retrieval Context mit einbeziehen. Der Evaluator lässt seine Custom Rubric über den Text laufen, berechnet einen finalen Score zwischen null und eins und liefert eine detaillierte Begründung, die erklärt, warum er Punkte abgezogen hat. Das Schreiben effektiver Criteria bestimmt die Qualität deiner Metric. Behandle den Criteria String wie einen stark eingeschränkten Prompt. Schreib keine vagen Anweisungen wie: Prüfe, ob die Response gut ist. Definiere genau, was gut bedeutet. Wenn die Verwendung von Slang automatisch zu einem Score von null führen soll, gib das explizit in den Criteria an. Die in Schritt eins generierten Evaluation Steps sind nur so präzise wie die Anweisungen, die du vorgibst. Das deckt einzelne Interaktionen ab. Konversationen stellen eine andere Herausforderung dar. Ein Chatbot fängt vielleicht professionell an, nimmt aber bei der vierten Nachricht einen lockeren Ton an. Um damit umzugehen, nutzt du Conversational G-Eval. Conversational G-Eval wendet genau denselben zweistufigen Algorithmus auf einen Multi-Turn Chat an. Der Unterschied ist das Input-Format. Anstatt einen einzelnen Input und Actual Output zu evaluieren, übergibst du eine komplette Conversation History. Diese History besteht aus sequenziellen Turns, die zwischen dem User und dem Assistant abwechseln. Die Metric liest das gesamte Transkript, generiert ihre Evaluation Steps basierend auf deinen Custom Criteria und bewertet die Interaktion als Ganzes. Das stellt sicher, dass der Model Output von der ersten Begrüßung bis zur finalen Verabschiedung konsistent bleibt. Die Effektivität jeder Custom Metric hängt komplett davon ab, dass du deine Criteria wie eine strikte Spezifikation behandelst, bei der Klarheit immer wichtiger ist als Kürze. Danke fürs Zuhören und Happy Coding zusammen!

Hallo, hier ist Alex von DEV STORIES DOT EU. DeepEval Framework, Folge 9 von 18. Beim Evaluieren komplexer Formatierungsregeln kann ein einzelner, dichter Prompt leicht dazu führen, dass dein Evaluator-LLM den Score halluziniert. Es sieht vielleicht die richtigen Wörter im Text, ignoriert die strukturelle Reihenfolge komplett und gibt einem fehlschlagenden Test einen Passing Score. Die Lösung dafür ist Deterministic Evaluation mit DAG. DAG steht für Directed Acyclic Graph. In diesem Framework ermöglicht dir eine DAG-Metric, einen strikten Decision Tree zu bauen, der steuert, wie das LLM eine Response evaluiert. Anstatt ein Model einen Text verarbeiten und basierend auf einem riesigen Block von Instructions scoren zu lassen, brichst du die Logik in granulare, schrittweise Operations herunter. Daten fließen strikt in eine Richtung, von Root Nodes am Anfang deines Trees hinunter zu Leaf Nodes am Ende. Um diesen Tree zu bauen, brauchst du drei verschiedene Components. Die erste ist die Task Node. Ein häufiger Fehler ist, sie wie einen Evaluator zu behandeln. Das ist sie nicht. Eine Task Node extrahiert oder verarbeitet einfach Daten aus dem Input oder der generierten Response. Als Nächstes kommt die Binary Judgement Node. Diese Node nimmt die von der Task Node verarbeiteten Daten und evaluiert sie gegen spezifische Kriterien, um ein striktes Ja oder Nein zurückzugeben. Zu guter Letzt gibt es die Verdict Node. Diese fungiert als Leaf Node. Sie beendet einen Branch deines Decision Trees und gibt einen finalen numerischen Score zusammen mit einer geschriebenen Reason aus. Wenden wir das mal auf ein konkretes Szenario an. Du testest ein LLM, das Zusammenfassungen von Meeting-Transcripts generiert. Dein striktes Requirement ist, dass jede Summary genau drei Headings haben muss: Intro, Body und Conclusion, in genau dieser Reihenfolge. Du beginnst deine Metric, indem du eine Root Task Node erstellst. Du instruierst diese Node, die generierte Summary zu lesen und eine Liste aller gefundenen Headings zu extrahieren. Das ist ihr ganzer Job. Sie isoliert die Formatting-Daten und übergibt eine einfache Textliste an das nächste Level des Trees. Jetzt fütterst du diese Liste in eine Binary Judgement Node. Du definierst die Kriterien für diese Node, um zu checken, ob die Liste genau drei Items enthält. Wenn die Node das als false evaluiert, routet sie die Execution runter zu einer Verdict Node. Diese Verdict Node lässt den Test sofort failen, weist einen Score von null zu und gibt eine Reason aus, die besagt, dass der Heading Count inkorrekt war. Wenn die Binary Judgement Node zu true evaluiert, geht die Execution zu einer zweiten Binary Judgement Node über. Diese Node nimmt dieselbe extrahierte Liste und checkt die Sequence. Sie verifiziert, ob das erste Item Intro ist, das zweite Body und das dritte Conclusion. Wenn das true ist, routet sie zu einer finalen Verdict Node, die einen perfekten Score vergibt. Wenn false, routet sie zu einer anderen Verdict Node, die wegen eines Order Failures eine Null zuweist. Das ist der entscheidende Punkt. Indem du die Informationsextraktion in eine Task Node von der Evaluierungslogik in den Judgement Nodes trennst, zwingst du das LLM, einem strikten Pfad zu folgen. Das Model übernimmt die semantische Extraktion, während dein Graph die deterministische Execution der Regeln garantiert. Danke fürs Zuhören, Happy Coding zusammen!

Hallo, hier ist Alex von DEV STORIES DOT EU. DeepEval Framework, Folge 10 von 18. Ein Language Model mit fünf manuellen Prompts zu testen, ist ganz süß. Aber wenn du auf eine neue Model-Version upgradest, verraten dir diese fünf Prompts nicht, ob du Edge Cases in hunderten von historischen Interaktionen zerschossen hast. Um production-ready zu sein, brauchst du ein robustes, versionskontrolliertes Repository of Truth. Genau das bietet das Evaluation Dataset. Ein Evaluation Dataset in DeepEval ist einfach eine strukturierte Sammlung von Items, die Goldens genannt werden. Bevor wir weitermachen, müssen wir ein häufiges Missverständnis ausräumen. Developer verwechseln oft ein Golden mit einem Test Case. Das ist nicht dasselbe. Ein Golden ist die rohe Dataset-Zeile. Es enthält deine statischen Testing-Parameter, wie den User Input, den Expected Output und den Retrieval Context. Es repräsentiert das ideale Szenario. Ein Golden wird erst später, zur Runtime, zu einem Test Case, nachdem deine Live-Applikation den Input verarbeitet und ihren tatsächlichen Output injiziert hat. Das Golden ist der Blueprint, während der Test Case das ausgeführte Ergebnis ist. Machen wir das an einem konkreten Szenario fest. Du hast ein historisches Log von 500 Customer-Support-Anfragen in einer CSV-Datei gespeichert. Du willst eine neue Model-Version gegen genau dieses Set von Anfragen rigoros testen. Du musst keine eigene Parsing-Logik schreiben. Du initialisierst einfach ein Evaluation Dataset und nutzt die Built-in-Methode, um Daten aus einer CSV-Datei hinzuzufügen. Du übergibst den File Path und definierst ein Mapping. Du sagst dem Dataset, welche CSV-Spalte dem User Input entspricht, welche auf den Expected Output mappt und welche den Context enthält. Das Framework übernimmt das Parsing und baut 500 Goldens im Memory auf. Genau das Gleiche kannst du mit einer JSON-Datei machen, indem du die JSON-Keys auf die Golden-Fields mappst. Hier ist die wichtigste Erkenntnis: Das Evaluation Dataset steuert einen spezifischen Lifecycle, der eine Brücke zwischen deinen statischen Daten und deiner dynamischen Evaluation Pipeline schlägt. Zuerst lädst und speicherst du deine Goldens im Dataset. Als Nächstes iterierst du während deines Test Runs durch das Dataset. Du extrahierst den Input aus jedem Golden, fütterst damit dein Live Language Model und fängst die generierte Response ab. Dann hängst du diese Live Response an das Golden an und konvertierst es in einen offiziellen Test Case. Zum Schluss übergibst du diesen kompletten Test Case an deine Metrics fürs Scoring. So bleiben deine Rohdaten komplett von deiner Execution Logic getrennt. Bis jetzt haben wir Single-Turn Datasets beschrieben. Ein User Input, ein Expected Output. Aber viele Applikationen beinhalten Chat Interfaces. Dafür unterstützt DeepEval Multi-Turn Datasets. Statt eines flachen Input Strings enthält ein Multi-Turn Dataset eine Sequenz von Interaktionen. Ein einzelnes Multi-Turn Golden speichert die gesamte Conversation History und trackt, wie der User und das System über mehrere Steps interagieren. So können deine Metrics den Flow und die Context Retention einer Conversation evaluieren, anstatt nur eine einzelne isolierte Reply zu betrachten. Deine Daten in formale Evaluation Datasets zu strukturieren, garantiert, dass jeder Prompt Tweak und Model Swap gegen einen strengen, unveränderlichen historischen Standard gemessen wird. Danke fürs Zuhören, Happy Coding zusammen!

Hallo, hier ist Alex von DEV STORIES DOT EU. DeepEval Framework, Folge 11 von 18. Der größte Bottleneck bei der Evaluierung von Large Language Models ist nicht das Testing Framework, das du benutzt. Es ist von vornherein der Mangel an qualitativ hochwertigen Testdaten. Indem du synthetische Daten mit dem DeepEval Synthesizer generierst, kannst du diese Blockade umgehen. Stell dir ein Startup vor, das einen internen HR-Bot baut. Du musst sofort Tests laufen lassen, um zu verifizieren, dass er die richtigen Policies abruft. Aber der Bot ist brandneu. Du hast null echte User Query Logs. Das ist das klassische Cold-Start-Problem für Evaluation Data. Du kannst ein Retrieval System nicht evaluieren, ohne eine robuste Liste von realistischen Fragen zu haben, die du ihm stellen kannst. Der DeepEval Synthesizer bootstrappt ein Evaluation Dataset direkt aus deiner rohen Knowledge Base. Anstatt hunderte von Test Cases von Hand zu schreiben, richtest du das Tool einfach auf deine Source Documents. Die Core-Methode dafür heißt generate goldens from docs. In DeepEval ist ein Golden die Terminologie für einen einzelnen Test Case, der einen Input, einen Expected Output und einen Context enthält. Um das zu nutzen, initialisierst du zuerst ein Synthesizer-Objekt. Dann rufst du die Methode generate goldens from docs auf und übergibst ihr ein Array von Document Paths. Für den HR-Bot wären das die File Paths zu deinen Mitarbeiterhandbüchern, Urlaubs-Policies und Benefits-PDFs. Wenn du diese Methode ausführst, verarbeitet der Synthesizer die Files und zerlegt den Text in handhabbare Chunks. Dann nutzt er ein Evaluator Language Model, um wie ein neugieriger User zu agieren. Das Model analysiert einen bestimmten Chunk des HR-Handbuchs und generiert eine relevante, realistische Frage, die rein auf diesem Text basiert. Diese Frage wird als synthetischer Input gespeichert. Der Synthesizer speichert auch den exakten Text-Chunk, der die Frage inspiriert hat. Das wird dann der Expected Context. Zum Schluss formuliert das Model die ideale, faktische Antwort auf die Frage und speichert sie als Expected Output. Das ist der Teil, auf den es ankommt. Leute missverstehen oft die Grenzen der synthetischen Generierung. Der Synthesizer erstellt nur die Inputs, den Expected Context und den Expected Output. Er generiert nicht den Actual Output. Den Actual Output zu finden, ist der Job deiner eigenen HR-Application während der Testing-Phase. Stell dir den Synthesizer wie einen Lehrer vor, der eine Prüfung schreibt und einen Lösungsschlüssel erstellt. Dein Bot muss die Prüfung aber noch selbst ablegen. Du kannst den Scope dieser Generierung steuern. Wenn du die Methode aufrufst, kannst du spezifizieren, wie viele Test Cases pro Document generiert werden sollen. Das hält den Prozess schnell und günstig für schnelle Iterationen, oder du kannst ihn für eine umfassende Coverage hochskalieren. Sobald die Methode fertig ist, extrahierst du die generierten Goldens und speicherst sie. Du kannst das Dataset lokal als JSON-File exportieren oder es direkt zu Confident AI pushen, um deine Dataset-Versionen über die Zeit zu tracken. Das Bootstrappen von synthetischen Datasets erlaubt es dir, nicht mehr darauf zu warten, dass echte User die Schwachstellen in deinem System aufdecken, sondern die absoluten Edges deiner Document Logic schon an Tag eins systematisch zu testen. Danke fürs Zuhören und Happy Coding zusammen!

Hallo, hier ist Alex von DEV STORIES DOT EU. DeepEval Framework, Folge 12 von 18. Einfache synthetische Queries, die aus deinen Dokumenten generiert werden, sind zu leicht. Moderne Language Models beantworten einfache Fragen mühelos und lassen dabei gefährliche Logiklücken völlig ungetestet. Um echte Breaking Points in deiner Application zu finden, musst du die Schwierigkeit deiner Testdaten künstlich erhöhen. Das erreichen wir durch Evolving Synthetic Complexity. Die Standard Generation erzeugt einfache, direkte Fragen. Die Evolution verkompliziert diese Fragen mathematisch, um dein System einem Stresstest zu unterziehen. Leute verwechseln das manchmal damit, die zugrundeliegenden Fakten zu verändern. Das Evolving einer synthetischen Query bedeutet nicht, die Ground Truth zu verändern. Die Source Data bleibt exakt gleich. Was sich ändert, ist die strukturelle Schwierigkeit der Query, die diese Daten abfragt. In DeepEval steuerst du diesen Mutationsprozess mithilfe der Evolution Config. Diese Config wendet spezifische Evolutionsstrategien an, um einen einfachen Prompt in einen Multi-Constraint Edge Case zu verwandeln. Nimm zum Beispiel eine einfache synthetische Frage wie: Wie lauten die Rückerstattungsbedingungen? Sie ist zwar unkompliziert, aber zu generisch für einen rigorosen Test. Die erste Strategie, die du anwenden kannst, ist die Concretizing Evolution. Diese nimmt eine abstrakte Query und zwingt sie in ein hochspezifisches, greifbares Szenario. Anstatt nach der allgemeinen Richtlinie zu fragen, mutiert Concretizing die Query in etwas wie: Wenn ich am Dienstag ein rotes Hemd gekauft habe, kann ich es nächste Woche zurückgeben? Das Modell muss nun spezifische User Constraints auf die allgemeine Regel mappen. Die zweite Strategie ist die Reasoning Evolution. Diese führt eine erforderliche Deduktionsebene ein. Die evolvierte Frage zwingt das Modell, logische Schritte durchzuführen, bevor es die finale Antwort liefern kann. Anstatt nur einen Fakt abzurufen, könnte die Query vom System verlangen, Daten zu berechnen, Werte zu vergleichen oder einer Conditional Logic Chain basierend auf dem Source Text zu folgen, bevor es seine Antwort formuliert. Die dritte Strategie ist die Multicontext Evolution. Diese testet Retrieval und Synthesis, indem sie das Modell zwingt, Antworten aus unzusammenhängenden Informationen zu ziehen. Sie modifiziert die Query so, dass die Antwort nicht aus einem einzelnen Absatz extrahiert werden kann. Um erfolgreich zu sein, muss das Language Model die allgemeine Rückerstattungsfrist aus einem Dokument mit spezifischen Ausnahmen für reduzierte Artikel aus einem völlig anderen Abschnitt kombinieren. Wenn du mithilfe dieser Strategien Tausende von Queries künstlich mutierst, werden einige zwangsläufig degradieren. Eine evolvierte Frage kann so verschachtelt werden, dass sie wirklich unmöglich zu beantworten ist, oder sie driftet von den ursprünglichen Fakten ab. Genau dieses Problem löst die Filtration Config. Du darfst nicht zulassen, dass unlösbarer Noise dein Evaluation Dataset verschmutzt. Filtration verwendet ein separates Critic Model, das als Quality Control Gatekeeper fungiert. Es prüft jede neu evolvierte Query anhand strenger Kriterien, bevor sie gespeichert wird. Wenn eine mutierte Frage logisch kaputt ist, nicht mehr mit dem Source Context übereinstimmt oder zu Nonsens degradiert, lehnt das Critic Model sie strikt ab. Dieser zweistufige Prozess stellt sicher, dass du Fragen generierst, die unglaublich schwierig, aber dennoch völlig valide sind. Ein hoher Score bei einfachen synthetischen Daten beweist nichts über die Resilience deines Systems; die wahre Zuverlässigkeit eines Modells misst sich nur daran, wie es mit den absichtlich evolvierten, komplexen Edge Cases umgeht, die die Standard Generation außen vor lässt. Danke fürs Zuhören, Happy Coding zusammen!

Hallo, hier ist Alex von DEV STORIES DOT EU. DeepEval Framework, Folge 13 von 18. End-to-End-Evaluations zeigen dir zwar, ob ein System fehlgeschlagen ist, aber sie lassen dich im Dunkeln darüber, warum. Component-Level Tracing sagt dir genau, welche spezifische Funktion fehlerhaft war. Heute schauen wir uns LLM Tracing und Observability an. Stell dir eine Standard Retrieval-Augmented Generation Pipeline vor. Ein User stellt eine komplexe Frage, und dein System liefert zehn Sekunden später eine halluzinierte Antwort. Du musst genau wissen, was schiefgelaufen ist. Hat die Embedding Retrieval Funktion irrelevante Dokumente aus deiner Datenbank gezogen, oder hat der finale Language Model Generation Schritt einfach versagt, den richtigen Context zu synthetisieren? Du kannst das nicht effizient debuggen, indem du dir nur den finalen Output anschaust. Du musst die internen Schritte inspizieren. Dafür musst du zwei grundlegende Begriffe verstehen, die häufig verwechselt werden: Traces und Spans. Ein Trace ist der komplette Execution Tree einer einzelnen Operation. Er repräsentiert die komplette Timeline von dem Moment, in dem der User einen Prompt sendet, bis zu dem Moment, in dem das System die finale Response liefert. Ein Span hingegen ist eine spezifische Komponente oder Funktion, die innerhalb dieses Traces arbeitet. Deine gesamte Pipeline Execution ist ein Trace. Die Funktion, die die Vector Database abfragt, ist ein Span. Die Funktion, die den Prompt formatiert, ist ein weiterer Span. Der eigentliche Call an das Large Language Model ist ein dritter Span. Jeder Trace ist aus diesen nested Spans aufgebaut. Jeder Span trackt seine eigene Startzeit, Endzeit, Input-Parameter und Output-Ergebnisse. In DeepEval erfasst du diese Hierarchie mit dem observe Decorator. Du platzierst einfach das Wort observe mit einem At-Zeichen direkt über den Python-Funktionen, die du monitoren willst. Du hängst ihn an deine Main Entry-Point Funktion und an die internen Helper-Funktionen wie deinen Retriever und deinen Generator. Wenn deine Application läuft, fängt der observe Decorator die Execution automatisch ab. Er loggt die exakten Argumente, die an die Funktion übergeben werden, und die exakten Daten, die zurückgegeben werden. Er trackt auch die Latency und alle Fehler, die auftreten. Noch wichtiger ist, dass er den Execution Context versteht. Wenn deine Main Pipeline Funktion deine Retriever Funktion aufruft, registriert der Decorator den Retriever automatisch als Child Span des Main Trace. Er mappt die Parent-Child-Beziehungen deiner Funktionen, ohne dass du sie manuell verlinken musst. Hier ist die entscheidende Erkenntnis. Tracing auf diese Weise ist komplett non-intrusive. Du musst deine Application Codebase nicht umschreiben, um Telemetry zu generieren. Du musst deine Function Signatures nicht ändern, um Trace IDs oder Context Objects den Call Stack hinunterzureichen. Du hältst deine Business Logic sauber und wrappst einfach nur die Komponenten, die dich interessieren. Dadurch isolierst du die Daten für jeden einzelnen Schritt. Wenn du später nur die Retrieval Logic evaluieren willst, sind die genauen Inputs und Outputs dieses spezifischen Spans bereits geloggt. Du evaluierst End-to-End, um die finale User Experience zu messen, aber du tracest auf Component-Level, um den zugrundeliegenden Code tatsächlich zu lokalisieren und zu fixen. Danke fürs Zuhören, Happy Coding zusammen!

Hallo, hier ist Alex von DEV STORIES DOT EU. DeepEval Framework, Folge 14 von 18. In komplexen autonomen Agent-Workflows weißt du nicht immer, wie der Test Case aussehen sollte, bis der Agent tatsächlich mit der Ausführung beginnt. Du kannst keine umfassende statische Test Suite für Zwischenentscheidungen schreiben, die noch gar nicht getroffen wurden. Dynamic Evals zur Runtime lösen dieses Problem, indem sie dich Test Cases mid-flight erstellen und evaluieren lassen. Normalerweise definieren Entwickler statische Test Cases extern. Du erstellst ein File mit festen Inputs und erwarteten Outputs und lässt deine Anwendung dann dagegen laufen. Dieser Ansatz stößt bei autonomen Systemen an seine Grenzen. Wenn ein Agent einen Prompt erhält, routet er die Query vielleicht weiter, wählt ein spezialisiertes Tool aus und generiert seinen eigenen internen Search String. Diese Zwischen-Inputs und -Outputs existieren erst, wenn der Code tatsächlich läuft. Dynamic Evals verzichten auf das externe File. Stattdessen bauen sie den Test Case Schritt für Schritt auf, während sich die Variablen innerhalb der aktiven Anwendung füllen. Stell dir ein konkretes Szenario vor: Du musst die Context Precision innerhalb einer tief verschachtelten Retriever-Funktion evaluieren. Du möchtest genau diesen spezifischen Mid-Flight-Schritt testen, isoliert vom finalen Output, den der User sieht. Dafür bietet DeepEval zwei spezielle Funktionen, um Execution-Daten abzufangen: update current span und update current trace. Ein Trace zeichnet den gesamten Lifecycle eines Requests auf, vom ersten User Input bis zur finalen Response. Ein Span repräsentiert eine spezifische Operation innerhalb dieses Traces, wie zum Beispiel deine Retriever-Funktion. Wenn diese Retriever-Funktion ausgeführt wird, materialisieren sich endlich die dynamischen Variablen. Du hast nun den exakten Search String, den der Agent generiert hat, und die spezifischen Text Chunks, die deine Datenbank zurückgegeben hat. Genau in diesem Moment rufst du innerhalb der Retriever-Logik update current span auf. Du nutzt diese Funktion, um diese Live-Variablen abzufangen und sie direkt auf einen neuen Test Case zu mappen. Du nimmst den abgefangenen Search String und weist ihn als Test Input zu. Du nimmst die rohen Database Chunks und weist sie als Retrieval Context zu. Du hast soeben während der Execution einen Golden Test Case konstruiert. Weil du diesen Golden dynamisch innerhalb des Spans gebaut hast, kannst du ihn sofort evaluieren. Du wendest deine Context Precision Metrik direkt dort an. Die Metrik läuft gegen die Live-Daten, bewertet den Retriever-Schritt und hängt diesen Score direkt an den lokalen Span an. Wenn du später deine Traces überprüfst, siehst du nicht nur, dass ein Retrieval stattgefunden hat. Du siehst eine hochgradig zielgerichtete Evaluation dieses spezifischen Retrievals, basierend auf den exakten Bedingungen dieses Runs. Das deckt granulare Schritte ab. Manchmal deckt jedoch eine verschachtelte Operation etwas auf, das den Kontext des gesamten Requests verändert. Hier wird update current trace notwendig. Während update current span den lokalen Schritt modifiziert, erlaubt update current trace einer tief verschachtelten Funktion, nach oben zu greifen und den globalen Execution Record zu ändern. Wenn dein Agent mid-flight Informationen entdeckt, die komplett verändern, wie die finale Antwort aussehen sollte, rufst du update current trace auf, um den Expected Output für den gesamten Run zu aktualisieren. Das hält die globale Evaluation im Einklang mit der lebendigen, sich verändernden Realität der Execution-Logik. Hier ist die wichtigste Erkenntnis: Wenn du Evaluations aus externen Files in den Runtime Execution Tree verlagerst, wird Testing von einer Post-Mortem-Analyse zu einem Live-Diagnosemechanismus. Indem du Metriken direkt an Spans bindest, während sie ausgeführt werden, hörst du auf zu raten, warum ein Multi-Step-Agent fehlgeschlagen ist, und fängst an genau zu messen, welcher interne Handoff den Fehler verursacht hat. Danke fürs Zuhören, Happy Coding zusammen!

Hallo, hier ist Alex von DEV STORIES DOT EU. DeepEval Framework, Folge 15 von 18. Dein LLM beantwortet vielleicht jede normale Frage perfekt. Aber was passiert, wenn ein böswilliger User aktiv versucht, deine Application durch einen Jailbreak dazu zu bringen, sensible Daten zu leaken? Das erfordert einen völlig anderen Ansatz, und das bringt uns zu einer Einführung ins Red Teaming. Um Red Teaming zu verstehen, musst du deine Sichtweise auf dein System ändern. Eine Standard-Evaluation testet die Funktionalität. Sie misst, ob dein Model hilfreich, akkurat und relevant ist, wenn es richtig genutzt wird. Red Teaming testet Security, Safety und Guardrails. Es erfordert einen Mindset-Shift: weg vom reinen Prüfen auf Korrektheit, hin zur Simulation von böswilligen Bad Actors. Du versuchst aktiv, das Model zum Scheitern zu bringen. Nehmen wir ein typisches Szenario. Wenn du deine AI-Application direkt aufforderst, ein User-Profil auszugeben, werden Standard-Guardrails das wahrscheinlich abfangen. Die AI weigert sich strikt, die Personal Identifiable Information, kurz PII, zu leaken. Eine Standard-Evaluation wertet das als Erfolg. Aber ein Bad Actor wird nicht direkt danach fragen. Er könnte das Model mit einer bestimmten, bösartigen Persona prompten und die AI anweisen, als Senior Database Administrator zu agieren, der einen Emergency System Override durchführt. Plötzlich gehorcht die AI und leakt bereitwillig die PII. Red Teaming ist der systematische Prozess, genau diese Blind Spots aufzudecken, bevor sie in Production gehen. DeepEval strukturiert diesen Prozess anhand von vier Kernkomponenten. Die erste Komponente sind Vulnerabilities. Eine Vulnerability ist die spezifische Schwäche, das Risiko oder der Schaden, auf den du testest. Es ist das zugrunde liegende Problem, das du verhindern willst. In unserem Emergency-Override-Szenario ist die Vulnerability das PII-Leakage. Andere Vulnerabilities könnten das Generieren von toxischem Output, das Zeigen von unautorisiertem Bias oder das Erteilen gefährlicher Ratschläge sein. Die zweite Komponente sind Adversarial Attacks. Wenn die Vulnerability das Ziel ist, ist der Angriff die Waffe. Angriffe sind die spezifischen Techniken oder Mittel, die verwendet werden, um eine Vulnerability zu exploiten. Das Annehmen einer vertrauenswürdigen Persona, um die AI auszutricksen, ist eine Art von Angriff. Andere umfassen Prompt Injection, bei der bösartige Anweisungen in regulärem Input versteckt werden, oder komplexe Jailbreaks, die darauf ausgelegt sind, das Safety-Training des Models komplett zu umgehen. DeepEval trennt die Schwäche von der Taktik, da eine einzelne Vulnerability durch viele verschiedene Arten von Angriffen aufgedeckt werden kann. Die dritte Komponente ist das Target LLM System. Das ist die eigentliche Application, die du evaluierst. Es ist nicht nur das rohe Foundation Model, sondern deine spezifische Architektur. Dazu gehören deine Custom System Prompts, deine Retrieval-Mechanismen und alle vorhandenen Safety-Filter. Die Adversarial Attacks werden direkt gegen dieses Setup ausgeführt, um zu sehen, wie dein eigentliches Produkt unter Druck performt. Die vierte Komponente sind Metrics. Sobald ein Angriff gegen dein Target System ausgeführt wurde, um eine Vulnerability zu prüfen, brauchst du ein quantifizierbares Ergebnis. Metrics evaluieren die Response des Systems. Sie bestimmen, ob der Angriff die Guardrails erfolgreich umgangen hat, oder ob das System den bösartigen Request sicher abgewiesen hat. Eine Metric bewertet die Interaktion und gibt dir ein konkretes Pass oder Fail, basierend darauf, wie sicher der Output tatsächlich war. Hier ist die entscheidende Erkenntnis. Du kannst eine AI-Application nicht absichern, indem du nur beweist, dass sie das Richtige tut, wenn man nett fragt; du musst systematisch beweisen, dass sie sich weigert, das Falsche zu tun, wenn sie angegriffen wird. Danke fürs Zuhören, Happy Coding zusammen!

Hallo, hier ist Alex von DEV STORIES DOT EU. DeepEval Framework, Folge 16 von 18. Du solltest nicht Tausende von irreführenden Inputs manuell eintippen müssen, um Sicherheitslücken in deiner Anwendung zu finden. Anstatt ein Security-Team wochenlang dafür zu bezahlen, dein System manuell zu knacken, kannst du eine AI deine AI autonom angreifen lassen. Heute schauen wir uns Executing Adversarial Attacks an. Um eine automatisierte LLM-on-LLM Attack zu orchestrieren, braucht die Scanning Engine eine direkte Kommunikationsverbindung zu deiner Anwendung. Diese Verbindung stellst du her, indem du einen Target Model Callback definierst. Das ist eine asynchrone Python-Funktion, die du schreibst. Sie nimmt ein einzelnes String-Argument entgegen – den von der Testing Engine generierten Adversarial Prompt – und muss die String Response deines Systems zurückgeben. In einem typischen Szenario mit einem OpenAI-Modell definierst du diese Async Callback-Funktion, nimmst den eingehenden Prompt-Parameter, übergibst ihn an deinen OpenAI-Client, wartest auf die Generation und gibst den finalen Text Content zurück. Dieser Callback fungiert als Brücke. Die Red Teaming Engine braucht keine Informationen über deine interne Architektur, API Keys oder den Database State. Sie braucht lediglich eine Funktion, die sie kontinuierlich mit bösartigen Inputs aufrufen kann. Sobald dein Callback bereit ist, übergibst du ihn an die Red Team Funktion. Das ist der zentrale Orchestrator, der den Scan ausführt. Zur Konfiguration übergibst du zwei separate Listen: Vulnerabilities und Attacks. Es ist entscheidend, den Unterschied zwischen ihnen zu verstehen. Vulnerabilities sind die spezifischen strukturellen Mängel oder schädlichen Verhaltensweisen, auf die du testen möchtest. Wenn du beispielsweise sicherstellen möchtest, dass deine Anwendung keine rassistischen oder geschlechtsspezifischen Vorurteile ausgibt, importierst und übergibst du die Bias Vulnerability an die Red Team Funktion. Attacks hingegen repräsentieren die Methodik, mit der die Engine versucht, diese Vulnerability aufzudecken. Um das Modell zu einer biased Aussage zu zwingen, möchtest du vielleicht, dass die Engine irreführende Formulierungen oder Jailbreak-Techniken verwendet. Das erreichst du, indem du die Prompt Injection Attack übergibst. Die Engine generiert nun autonom gezielte, bösartige Prompts mittels Prompt Injection, die speziell darauf ausgelegt sind, deine System Prompts zu umgehen und die Bias Vulnerability zu triggern. Ein häufiger Verwirrungspunkt bei diesem Setup ist, wie die Ergebnisse eigentlich bewertet werden. Bei der Standard Evaluation verbringst du viel Zeit mit der Definition und dem Tuning spezifischer Metrics. Wenn du Adversarial Attacks ausführst, definiere keine Metrics manuell. Das Framework übernimmt das vollständig im Hintergrund. Es mappt die von dir ausgewählte Vulnerability automatisch direkt auf eine entsprechende interne Evaluation Metric. Weil du vorgegeben hast, auf Bias zu testen, führt die Engine automatisch einen Bias Evaluator für jede einzelne Response aus, die dein Target Model Callback zurückgibt. Nachdem die Red Team Funktion das Abfeuern dieser generierten Prompts und das Evaluieren der Responses abgeschlossen hat, gibt sie ein umfassendes Risk Assessment aus. Dieses Assessment bietet eine klare Aufschlüsselung des Scans. Es zeigt genau, wie viele Attacks versucht wurden, welche spezifischen Attack Techniques dein System erfolgreich geknackt haben und die genauen Input Strings, die den Fehler verursacht haben. Du erhältst am Ende eine konkrete Liste von Inputs, die dein System derzeit nicht verarbeiten kann. Hier ist die entscheidende Erkenntnis. Die wahre Stärke dieses Setups liegt darin, die Attack Method von der Target Vulnerability zu entkoppeln. Das erlaubt es dir, deine Security Coverage zu vervielfachen, indem du einen einzelnen Flaw wie Bias mit Dutzenden verschiedener Attack Vectors gleichzeitig kombinierst. Danke fürs Zuhören, Happy Coding zusammen!

Hallo, hier ist Alex von DEV STORIES DOT EU. DeepEval Framework, Folge 17 von 18. Du würdest niemals einen Pull Request für traditionellen Code mergen, ohne vorher deine Unit Tests auszuführen. Trotzdem deployen Teams regelmäßig nicht-deterministische Sprachmodelle und hoffen einfach, dass die neuen Prompts noch funktionieren. Wenn du verhindern willst, dass fehlerhafte Model-Updates die Production kaputt machen, brauchst du CI/CD und Continuous Evaluation. DeepEval behandelt Sprachmodell-Evaluations genau wie Standard-Softwaretests, indem es sich direkt in Pytest integriert. Du definierst eine Testfunktion, initialisierst deine Evaluation Metrics und stellst per Assert sicher, dass die Metric durchgeht. Ein Model mit einem einzigen Input zu evaluieren, ist sinnlos. Deshalb musst du Änderungen gegen einen großen Batch von freigegebenen Baseline-Inputs und Expected Outputs validieren. Das ist dein Golden Dataset. Um effizient durch dieses Dataset zu iterieren, benutzt du den Standard Pytest mark parametrize Decorator. Du lädst dein Dataset, extrahierst die einzelnen Test Cases und übergibst sie an den Decorator. Wenn die Test Suite läuft, generiert Pytest dynamisch eine separate Test Execution für jedes einzelne Item in deinem Golden Dataset. Hier ist der entscheidende Punkt. Weil das Framework so eng mit Pytest integriert ist, gehen Entwickler oft davon aus, dass sie einfach Standard-Pytest-Befehle in ihrem Terminal ausführen können. Mach das nicht. Wenn du Pytest direkt gegen deine Evaluation-Files ausführst, wirst du auf unerwartete Fehler stoßen, die mit asynchronen Event Loops und fehlender Metric Telemetry zu tun haben. Du musst immer das dedizierte Command Line Interface nutzen. Der korrekte Befehl lautet deepeval test run, gefolgt von deinem Python-Dateinamen. Dieser Wrapper übernimmt das komplexe asynchrone Setup, das für Sprachmodelle erforderlich ist, und stellt sicher, dass alle Testergebnisse korrekt erfasst und geloggt werden. Wenn du diesen Befehl in deine Deployment Pipeline integrierst, erhältst du Continuous Evaluation. Stell dir ein typisches GitHub Action Setup vor. Du konfigurierst den Workflow so, dass er immer dann triggert, wenn ein Entwickler einen Pull Request gegen den Main Branch öffnet. Der Action Runner checkt das Repository aus, setzt die Python-Umgebung auf und führt deepeval test run gegen dein Golden Dataset Skript aus. Das Framework evaluiert den neu geänderten Code oder Prompt gegen jeden historischen Test Case. Wenn ein Entwickler einen System Prompt ändert, um die Antworten kürzer zu machen, könnte er das Model versehentlich anweisen, obligatorische Compliance-Warnungen zu entfernen. Wenn die CI Pipeline läuft, fängt die automatisierte Evaluation diesen fehlenden Kontext sofort ab. Wenn die neue Logik dazu führt, dass dein Evaluation Score bei irgendeinem Test Case unter deinen definierten Threshold fällt, schlägt die Assertion fehl. Das Skript gibt einen Non-Zero Exit Code zurück, die GitHub Action wird sofort rot und der Pull Request wird für das Mergen blockiert. Dieser automatisierte Pre-Deployment Check fungiert als strenger Gatekeeper. Er fängt Regressions automatisch ab. Du musst Outputs nicht mehr manuell stichprobenartig überprüfen oder darauf warten, dass User sich beschweren, weil ein neuer Model Swap einen bestimmten Edge Case kaputt gemacht hat. Die Pipeline beweist mathematisch, ob das Update sicher zu deployen ist, und entfernt so die menschliche Subjektivität komplett aus dem Release-Prozess. Continuous Evaluation bedeutet, dass du aufhörst, Prompt Engineering wie ein operatives Glücksspiel zu behandeln, und anfängst, es wie ein vorhersehbares Software Release zu behandeln, das durch harte Daten gestützt wird. Vielen Dank fürs Zuhören, Happy Coding zusammen!

Hallo, hier ist Alex von DEV STORIES DOT EU. DeepEval Framework, Folge 18 von 18. Du verbringst Stunden damit, einen Prompt lokal zu tunen, erzielst einen großartigen Evaluation Score und shipst den Code. Zwei Wochen später updatet ein anderer Engineer das zugrundeliegende Model, und plötzlich schlägt die Anwendung bei Edge Cases fehl, die niemand getrackt hat. Evaluations lokal auszuführen, ist nur die halbe Miete. In dieser Folge erfährst du, wie du dein Testing skalierst und Regressionen im Zeitverlauf mit Confident AI trackst. Zunächst eine wichtige Unterscheidung. DeepEval ist das Open-Source-Framework, das du in deinem Terminal oder deiner Python-Environment ausführst, um Tests laufen zu lassen. Confident AI ist die gehostete Cloud-Plattform, die darauf aufbaut. Du nutzt DeepEval, um deine Metrics zu definieren und die eigentlichen Evaluations auszuführen. Du nutzt Confident AI, um diese Evaluation Reports über eine gesamte Engineering-Organisation hinweg zu zentralisieren, zu tracken und zu analysieren. Es macht aus isolierten lokalen Scripts ein kollaboratives System of Record. Der Wechsel von lokaler Execution zu Cloud-Logging erfordert nur einen einfachen Schritt. In deinem Terminal führst du den Command deepeval login aus. Die CLI wird dich nach einem API-Key fragen, den du in deinem Confident AI Workspace generiert hast. Sobald du dich authentifiziert hast, bleibt dein täglicher Workflow genau gleich. Du führst deine Test-Files mit dem Standard-Test-Command aus. Das Framework erkennt automatisch die aktive Session und streamt die Ergebnisse direkt an das Cloud-Dashboard, während sie weiterhin lokal ausgegeben werden. Das Zentralisieren der Reports gibt dir die Möglichkeit, Regressionen methodisch zu tracken. Eine Regression passiert, wenn eine Änderung in deinem Code oder deiner Configuration die Performance des Systems unbeabsichtigt verschlechtert. Um zu diagnostizieren, warum eine Regression aufgetreten ist, musst du genau tracken, was sich zwischen den Test Runs geändert hat. Das machst du durch das Logging von Hyperparametern. Im Kontext von Language Model Evaluations ist ein Hyperparameter jede Variable, die das Verhalten deiner Pipeline verändert. Dazu gehören die Model-Architektur, die Temperature-Einstellung, die Chunk Size für das Retrieval oder sogar die spezifische Version des Prompt Templates. Wenn du DeepEval so konfigurierst, dass diese Hyperparameter geloggt werden, werden sie an jeden Test Run angehängt, der an Confident AI gesendet wird. Stell dir ein Team vor, das versucht, seine Application upzugraden. Sie wollen wissen, ob der Wechsel von GPT-4o zu Claude 3.5 Sonnet ihren gesamten Pipeline Score tatsächlich verbessert. Sie konfigurieren den Model-Namen als getrackten Hyperparameter. Wenn der Engineer die Evaluation Suite mit dem neuen Model ausführt, loggt Confident AI den neuen Model-Namen zusammen mit den resultierenden Scores für Metrics wie Contextual Precision oder Factual Consistency. Hier ist die entscheidende Erkenntnis. Weil alle historischen Test Runs in der Cloud gespeichert sind, kann das Team eine Timeline ansehen, die die genauen Hyperparameter-Änderungen mit den aggregierten Evaluation Scores vergleicht. Wenn der Wechsel zum neuen Model die Answer Relevancy erhöht, aber die Factual Consistency drastisch abfällt, hebt das Dashboard diese Regression sofort hervor. Jeder im Team sieht dieselben Daten. Du musst nie wieder alte Console Outputs durchsuchen oder dich auf dein Gedächtnis verlassen, um zu entscheiden, ob eine Configuration-Änderung ein Erfolg war. Continuous Evaluation erfordert eine historische Baseline. Ohne ein zentralisiertes System, das deine Configurations direkt mit deinen Evaluation Scores verknüpft, führst du lediglich isolierte Experimente durch und entwickelst kein zuverlässiges System. Damit endet unsere Serie zum DeepEval Framework. Ich kann dir nur wärmstens empfehlen, die offizielle Documentation zu erkunden und zu versuchen, diese Evaluations hands-on zu bauen. Wenn du technische Themen hast, die du gerne in einer zukünftigen Serie behandelt sehen möchtest, besuche devstories dot eu, um einen Vorschlag zu hinterlassen. Danke fürs Zuhören, happy coding euch allen!