LlamaIndex: Context-Augmented LLM Applications

Hallo, hier ist Alex von DEV STORIES DOT EU. LlamaIndex: Context-Augmented LLM Applications, Folge 1 von 14. Pre-trained Modelle sind brillant, aber sie wissen absolut nichts über die privaten Dokumente, die du heute Morgen erstellt hast. Du bittest ein LLM, dein brandneues Q3-Financial-Slide-Deck zusammenzufassen, und es rät entweder blind oder sagt dir, dass es nicht helfen kann. Der Context-Augmentation-Imperative ist die Lösung dafür. Large Language Models besitzen unglaubliche Reasoning-Fähigkeiten, aber ihr Wissen ist in der Zeit eingefroren und auf öffentliche Daten beschränkt. Sie haben keinen Zugriff auf deine internen Wikis, deine Customer-Support-Tickets oder deine privaten Finanzberichte. LlamaIndex existiert, um genau diese Lücke zu schließen. Es dient als Bindeglied zwischen Foundational Models und deinen privaten, lokalen Daten. Wenn du ein Modell bittest, dieses Q3-Slide-Deck zusammenzufassen, kannst du nicht einfach nur die Frage senden. Du brauchst ein System, das die relevanten Slides findet, den Text extrahiert und diese spezifischen Informationen zusammen mit deinem Prompt an das Modell übergibt. Dieser Prozess nennt sich Context Augmentation. Du gibst dem Modell genau den Kontext, den es braucht, um seine Reasoning-Skills auf deine privaten Daten anzuwenden. LlamaIndex stellt die Infrastruktur bereit, um deine Daten zu ingesten, zu organisieren und zu retrieven, sodass Context Augmentation zuverlässig abläuft. Text zu fetchen und eine einzelne Frage zu beantworten, ist nur die Baseline. Moderne Applications erfordern mehr Autonomie. Das bringt uns zu Agentic Applications. Eine Agentic Application folgt nicht einfach einer geraden Linie von einer Frage über eine Datenbank zu einer Antwort. Sie trifft auf dem Weg Entscheidungen, um komplexe User Intents zu handhaben. Der erste Teil davon ist Routing. Wenn ein User eine Frage stellt, muss das System entscheiden, welche Data Source oder welches Tool das richtige ist. Fragt der User nach einer High-Level-Unternehmenszusammenfassung, leitet der Router die Query an den Index des Q3-Slide-Decks weiter. Fragt der User nach dem genauen numerischen Breakdown der regionalen Sales, sendet der Router die Query stattdessen vielleicht an eine strukturierte SQL-Datenbank. Routing stellt sicher, dass das Modell basierend auf dem Input das richtige Tool für den Job verwendet. Der zweite Teil ist Prompt Chaining. Komplexe Tasks schlagen oft fehl, wenn du ein Modell bittest, sie in einem einzigen massiven Prompt abzuarbeiten. Prompt Chaining bricht ein komplexes Ziel in kleinere, sequenzielle Tasks herunter. Das System führt vielleicht einen Prompt aus, um Umsatzzahlen aus dem Slide-Deck zu extrahieren, übergibt diese Zahlen an einen zweiten Prompt, der sie mit historischen Daten vergleicht, und sendet diesen Output an einen dritten Prompt, der eine Executive Summary entwirft. Der Output eines Schrittes wird zum exakten Kontext für den nächsten Schritt. Hier wird es interessant. Selbst mit den richtigen Daten und einer strukturierten Chain machen Modelle Fehler. Das bringt uns zu Reflection. Reflection ist ein automatisierter Qualitätskontrollschritt. Bevor die Agentic Application dem User die finale Zusammenfassung des Q3-Decks liefert, nutzt sie einen separaten Prompt, um ihren eigenen Draft zu evaluieren. Sie checkt, ob der generierte Text vollständig durch die abgerufenen Slides gestützt wird. Wenn der Reflection-Schritt eine Halluzination oder eine ausgelassene Key Metric entdeckt, verwirft er den Draft und triggert eine Korrektur. Die wahre Power von Context-Augmented Applications besteht nicht nur darin, einem LLM ein Dokument zum Lesen zu geben, sondern ihm einen strukturierten, selbstkorrigierenden Workflow bereitzustellen, um sicheres Reasoning über deine privaten Daten durchzuführen. Wenn du helfen möchtest, die Show am Laufen zu halten, kannst du auf Patreon nach DevStoriesEU suchen und uns dort unterstützen. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. LlamaIndex: Context-Augmented LLM Applications, Folge 2 von 14. Du kannst nicht einfach ein 500-seitiges PDF in ein LLM Context Window stopfen und eine präzise Antwort erwarten. Das Modell verliert den Überblick, halluziniert oder lehnt die Payload einfach ab, weil sie seine Limits überschreitet. Um riesige Dateien nutzbar zu machen, musst du sie in winzige Stücke zerlegen und in ein mathematisches Format übersetzen, das die Maschine durchsuchen kann. Genau diesen Prozess behandelt heute Data Ingestion: Documents and Nodes. Stell dir vor, du verarbeitest ein riesiges Personalhandbuch. Der Text steckt in einem riesigen PDF, das sich über Dutzende komplexe Kapitel erstreckt. Der erste Schritt in einer Retrieval-Augmented Generation Pipeline ist die Loading Stage. Hier kommen Data Connectors, oft auch Reader genannt, ins Spiel. Ein Connector nimmt deine Rohdatenquelle – sei das nun ein lokales PDF, eine Remote-Datenbanktabelle oder eine externe API Response – und verpackt sie in eine Datenstruktur namens Document. Viele Leute stolpern über diesen Begriff. In diesem Framework bedeutet ein Document nicht einfach eine Word-Datei oder ein PDF. Ein Document ist lediglich ein generischer Container für jede Art von ingested Data Source. Es enthält den Rohtext zusammen mit ein paar grundlegenden Properties. Ein einzelnes Document, das ein 500-seitiges Handbuch repräsentiert, ist jedoch für eine präzise, schnelle Suche völlig unbrauchbar. Du musst es zerlegen. Das bringt uns zu den Nodes. Ein Node ist die eigentliche atomare Dateneinheit in LlamaIndex. Er ist ein kleinerer, handhabbarer Chunk eines Parent Documents – vielleicht ein einzelner Absatz, der die Elternzeitrichtlinie im Detail beschreibt. Wenn du das Personalhandbuch verarbeitest, nimmt das Framework das riesige Document und zerschneidet es in Tausende von Nodes. Hier ist die entscheidende Erkenntnis. Nodes enthalten nicht einfach nur isolierten Text. Sie tragen reichhaltige Metadaten und strukturelle Beziehungen in sich. Ein Node weiß genau, aus welchem Parent Document er stammt. Er weiß auch, welcher Node ihm logisch vorausgeht und welcher Node ihm folgt. Diese verlinkte Struktur ermöglicht es dem System, später einen größeren Kontext zu synthetisieren, falls ein einzelner Chunk nicht die gesamte Antwort enthält. Sobald du deine Daten in präzise Nodes zerhackt hast, gehst du zur Indexing Stage über. Du brauchst einen robusten Weg, um den richtigen Node zu finden, wenn ein User später eine Frage stellt. Dafür muss menschliche Sprache in ein numerisches Format übersetzt werden, das man Embedding nennt. Ein Embedding ist ein Array aus Gleitkommazahlen, das die semantische Bedeutung des Textes innerhalb des Nodes repräsentiert. Du schickst jeden Node durch ein Embedding-Modell. Das Modell liest den Chunk und gibt einen hochdimensionalen Vektor zurück. Wenn zwei Nodes konzeptionell ähnliche Themen behandeln – wie Krankheitsurlaub und bezahlten Urlaub –, liegen ihre numerischen Vektoren im Raum mathematisch nah beieinander. Wenn diese Vektoren generiert sind, konstruierst du einen Index. Der Index ist die zentrale strukturelle Komponente, die deine Nodes so organisiert, dass sie abgefragt werden können. Bei den meisten Anwendungen wird dieser Index von einem Vector Store gestützt. Der Vector Store fungiert als spezialisierte Datenbank, die explizit dafür entwickelt wurde, diese mathematischen Repräsentationen zu speichern und hocheffiziente Ähnlichkeitsberechnungen darauf auszuführen. Der logische Ablauf ist extrem vorhersehbar. Zuerst konfigurierst du einen Data Connector, der auf dein Personalhandbuch abzielt. Der Connector liest die Datei und gibt ein einzelnes Document-Objekt aus. Als Nächstes nimmt ein Parser dieses Document und splittet es in ein Array aus unabhängigen Node-Objekten. Schließlich übergibst du dieses Array von Nodes an einen Index, der die Erstellung der Vector Embeddings koordiniert und sie in den Vector Store committet. Die gesamte Ingestion Pipeline existiert nur, um eine fundamentale Einschränkung zu lösen. Large Language Models können nicht zuverlässig ganze Bücher auf einmal lesen, aber sie können sofort die mathematische Distanz zwischen zwei Arrays aus Zahlen berechnen. Deine Rohdateien in Documents zu übersetzen, sie in verlinkte Nodes zu zerschneiden und sie in Vector Indexes zu encodieren, ist genau das, was diese Lücke schließt. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. LlamaIndex: Context-Augmented LLM Applications, Folge 3 von 14. Du schnappst dir den richtigen Document Chunk, schickst ihn an das Language Model und bekommst trotzdem eine schlechte Antwort, weil er unter zehn irrelevanten Chunks begraben war. Den Text zu finden, ist nur die halbe Miete. Filtering, Ranking und die Entscheidung, wie er überhaupt abgerufen wird, entscheiden letztlich darüber, ob das System erfolgreich ist oder scheitert. Heute schauen wir uns die Execution-Phase von RAG an, genauer gesagt die Query Pipeline: Retriever und Router. In dieser Phase sind deine Daten bereits geladen und indexiert. Ein User schickt eine Query ab. Die erste Komponente, die diese Query abfängt, ist oft ein Router. Ein Router ist eine Decision Engine. Er schaut sich die eingehende Frage an und bestimmt, welches zugrundeliegende Tool oder welcher Index am besten geeignet ist, um sie zu beantworten. Angenommen, ein User stellt eine komplexe Frage zu einem bestimmten historischen Ereignis, die auch sehr spezifische Akronyme enthält. Eine Standard-Vector-Search erfasst vielleicht die semantische Bedeutung des Ereignisses, übersieht aber die Akronyme. Eine Keyword Search trifft die Akronyme auf den Punkt, verfehlt aber den breiteren Kontext. Der Router wertet die Query aus und entscheidet, sie gleichzeitig über zwei Pfade zu schicken. Er routet den Request sowohl an eine Vector Search als auch an eine Keyword Search. Das bringt uns zu den Retrievern. Ein Retriever ist dafür verantwortlich, genau zu definieren, wie relevanter Kontext aus einem Index abgerufen wird. Er generiert keine Antworten. Er ruft nur Daten ab. Um bei unserem Szenario zu bleiben: Der Vector Retriever wandelt die User Query in ein Embedding um und zieht die mathematisch ähnlichsten Nodes heraus – was einfach nur Chunks deiner Quelldokumente sind. Gleichzeitig zieht der Keyword Retriever Nodes heraus, die exakte Text Matches für diese Akronyme enthalten. Jetzt hast du zwei verschiedene Stapel von Nodes. Du kannst sie nicht einfach blind alle an deinen Language Model Prompt anhängen. Context Windows sind begrenzt, und Models lassen sich leicht von irrelevanten Daten ablenken. Hier kommen die Node Postprocessors ins Spiel. Hier ist die wichtigste Erkenntnis. Node Postprocessors fungieren als Gatekeeper zwischen den Retrievern und dem Language Model. Sie wenden Transformations-, Filtering- oder Re-Ranking-Logik auf die abgerufenen Nodes an. Zum Beispiel kann ein Postprocessor einen Similarity Cutoff erzwingen und alle Nodes verwerfen, die unter einem bestimmten Threshold liegen. Er kann Nodes deduplizieren, falls die Vector Search und die Keyword Search zufällig genau denselben Absatz gezogen haben. Er kann die verbleibenden Nodes auch re-ranken, sodass der absolut relevanteste Chunk ganz oben im Context Window sitzt. Sobald der Postprocessor die Daten bereinigt und sortiert hat, übergibt das System sie an den Response Synthesizer. Der Synthesizer hat nur einen Job. Er nimmt die aufpolierte Liste von Nodes und die ursprüngliche User Query, kombiniert sie zu einem strukturierten Prompt und sendet sie an das Language Model. Das Language Model generiert dann die finale, menschenlesbare Antwort ausschließlich auf Basis dieses bereitgestellten Kontexts. Die Query Execution Phase ist strikt eine Pipeline. Du routest die Query, rufst die rohen Nodes ab, filterst und rankst diese Nodes mit einem Postprocessor und synthetisierst schließlich den Text. Wenn du kontrollierst, was das Language Model sieht, kontrollierst du die Qualität des Outputs. Danke, dass du ein paar Minuten mit mir verbracht hast. Bis zum nächsten Mal, mach's gut.

Hallo, hier ist Alex von DEV STORIES DOT EU. LlamaIndex: Context-Augmented LLM Applications, Folge 4 von 14. Du baust einen Agenten für IT-Support-Tickets, aber die Hälfte der Anfragen besteht nur aus Smartphone-Fotos von blinkenden Warnleuchten. Reine Textverarbeitung zwingt dich, separate Vision-Pipelines zu bauen oder den visuellen Kontext komplett zu verwerfen. Heute behandeln wir Interfacing mit LLMs und Multi-Modal Inputs, was dieses Problem direkt auf dem Model Layer löst. In LlamaIndex läuft die Interaktion mit einem Language Model über die Base LLM Class. Diese dient als einheitliches Interface. Egal, ob du ein OpenAI-Model, ein Anthropic-Model oder einen anderen Provider aufrufst, die Core Methods, die du nutzt, sind identisch. Diese Abstraktion schützt deine Application Logic vor Provider-spezifischen API-Änderungen. Wenn du eine Antwort vom Model haben willst, wählst du zwischen zwei primären Methods. Die erste ist die complete Method. Du übergibst ihr einen einzelnen Text-String, der deinen Prompt enthält, und sie gibt eine einzelne Text-Response zurück. Das ist für einfache Single-Shot Tasks gedacht, wie das Zusammenfassen eines Dokuments oder das Extrahieren eines bestimmten Fakts. Die zweite Method ist die chat Method. Diese ist für Conversations oder strukturierte Interaktionen gedacht. Statt eines einzelnen Strings übergibst du eine Liste von Chat Message Objects. Jeder Message ist eine bestimmte Role zugeordnet, typischerweise system, user oder assistant. Indem du eine Liste übergibst, gibt die chat Method dem Model den vollen Context eines Hin-und-Her-Austauschs, bevor es seine nächste Reply generiert. Sowohl complete als auch chat warten, bis das Model seine gesamte Generation abgeschlossen hat, bevor sie den Output zurückgeben. Wenn das Model eine lange Response schreibt, steht deine Application still. Um das zu beheben, nutzt du Streaming. Du rufst stattdessen stream complete oder stream chat auf. Diese Methods geben einen Generator zurück. Während das Model Tokens produziert, empfängt dein Code sie in kleinen Chunks. Du loopst durch diesen Generator, um die Response in Echtzeit auf einem User Interface auszugeben, was die wahrgenommene Latency eliminiert. Nun zum zweiten Teil: dem Handling von Non-Text Data. Hier wird es interessant. Moderne LLMs parsen visuelle Informationen, und LlamaIndex unterstützt das durch Content Blocks. Statt einen einfachen Text-String in einer User Chat Message zu übergeben, kannst du eine Liste von Blocks übergeben. Denk zurück an das IT-Support-Ticket mit dem kaputten Server-Rack. Das Model muss sich das Foto ansehen und deine Diagnose-Anweisungen lesen. Zuerst erstellst du einen ImageBlock. Du übergibst diesem Block die Image Data. LlamaIndex erlaubt es dir, einen lokalen File Path, eine direkte URL oder rohe Base64-encoded Bytes zu übergeben. Als Nächstes erstellst du einen TextBlock. Du gibst ihm deinen Text-Prompt und bittest das Model, den im Bild gezeigten Hardware-Fehler zu identifizieren. Du packst sowohl den ImageBlock als auch den TextBlock in eine einzige Liste und hängst diese Liste an eine neue User Chat Message an. Wenn du diese Message in die chat Method eines Vision-fähigen Models übergibst, verarbeitet das LLM das visuelle Layout des Server-Racks zusammen mit deinen Text Instructions. Es gibt eine Diagnose basierend auf beiden kombinierten Inputs zurück. Hier ist die Key Insight. Die wahre Stärke dieser Architektur ist ihre Konsistenz. Egal, ob du einen einzeiligen String sendest, eine Real-Time Response streamst oder ein komplexes Array aus Text- und Image-Blocks übergibst – das Interaction Pattern mit der LLM Class bleibt in deiner gesamten Codebase komplett standardisiert. Das war's für diese Folge. Bis zum nächsten Mal!

Hallo, hier ist Alex von DEV STORIES DOT EU. LlamaIndex: Context-Augmented LLM Applications, Folge 5 von 14. Nichts bringt eine Production Pipeline schneller zum Absturz, als wenn ein LLM entscheidet, direkt vor dem eigentlichen Data Payload noch ein „Klar, hier ist dein JSON“ einzufügen. Du fragst nach maschinenlesbarem Output, bekommst Conversational Filler, und dein Parser stürzt sofort ab. Die Lücke zwischen unstrukturierter natürlicher Sprache und zuverlässigen programmatischen Types zu schließen, ist genau das, was Structured Data Extraction mit Pydantic löst. Nehmen wir das Szenario, in dem du einen chaotischen E-Mail-Posteingang voller Lieferantennachrichten, Zahlungserinnerungen und unstrukturierter Belege parsen musst. Dein System muss aus diesem Text strukturierte Rechnungsdaten extrahieren. Wenn du dich auf Standard Text Generation verlässt, bekommst du unvorhersehbare Ergebnisse. Eine Response verwendet vielleicht Camel Case für Keys, eine andere formatiert Datumsangaben anders, und Preise kommen oft als Strings mit angehängten Währungssymbolen zurück. Am Ende schreibst du endlose String-Manipulation-Logik, nur um eine brauchbare Zahl aus der Response zu bekommen. Anstatt das Model nach JSON zu fragen und zu hoffen, dass es sich daran hält, definierst du deine genauen Anforderungen mit einem Pydantic Base Model. Du erstellst eine Python-Klasse namens Invoice. Innerhalb dieser Klasse deklarierst du die exakten Datentypen, die deine Application erwartet. Du definierst das Datum als String, die gekauften Artikel als Liste von Strings und den Gesamtpreis strikt als Float. Hier ist die entscheidende Erkenntnis: LlamaIndex nimmt deine Pydantic-Klasse und serialisiert sie automatisch in ein striktes JSON-Schema. Wenn du den E-Mail-Text an das Model sendest, hängt LlamaIndex dieses Schema an und triggert die Structured Output oder Function-Calling API des zugrundeliegenden Models. Das Schema fungiert als harte Grenze. Das LLM generiert keinen Freitext mehr. Es ist darauf beschränkt, die Felder des JSON-Schemas spezifisch mit den Types zu befüllen, die du verlangt hast. Du kannst das Reasoning des Models auch direkt innerhalb deiner Datenstrukturen steuern. Indem du einem Attribut eine Field Description anhängst, gibst du dem LLM gezielte Anweisungen. Für das Preis-Attribut könntest du eine Field Description hinzufügen, die besagt, dass die Gesamtkosten ohne Versandkosten extrahiert werden sollen. Das LLM liest diese Description als Teil der Schema-Definition und wendet diese Logik während der Extraktionsphase an. Wenn die Response zurückkommt, übergibt dir LlamaIndex keinen Raw String oder ein generisches Dictionary. Es verarbeitet die Response durch Pydantic und gibt ein vollständig instanziiertes Invoice-Objekt zurück. Die Daten sind bereits validiert. Weil das Framework native Structured Output Features nutzt, weiß das Model im Voraus, dass es einen echten Float für den Preis liefern muss, und keine String-Repräsentation davon. Du kannst in deinem Code sofort auf das Attribut invoice dot price zugreifen und damit rechnen. Es ist nicht nötig, Conversational Filler herauszufiltern, Dollarzeichen zu entfernen oder Strings in Zahlen zu casten. Der Übergang von natürlicher Sprache zu Application Logic passiert nahtlos auf dem Extraction Layer. Indem du dein Data Schema direkt in den Extraktionsprozess pushst, zwingst du das LLM, sich an deinen Application Code anzupassen, anstatt fragilen Application Code zu schreiben, der unvorhersehbares LLM-Verhalten toleriert. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. LlamaIndex: Context-Augmented LLM Applications, Folge 6 von 14. Was wäre, wenn deine Anwendung anhand des User Intents entscheiden könnte, welche Funktionen ausgeführt werden, anstatt einem starren Set von Conditional Statements zu folgen? Das ist die Kernidee hinter dem Entwickeln von Autonomous Function Agents. Wenn du eine Standard-Query-Pipeline baust, gibst du den Execution Path vor. Ein Agent dreht dieses Paradigma um. Du stellst ein Set von Tools bereit, und eine automatisierte Reasoning Engine nutzt ein Large Language Model, um zu entscheiden, welche Tools in welcher Reihenfolge aufgerufen werden, um ein Problem zu lösen. Bevor wir weitergehen, müssen wir ein häufiges Missverständnis ausräumen. Das LLM selbst führt deinen Python-Code nicht aus. Es generiert lediglich einen strukturierten Text-Request, der besagt, dass es eine bestimmte Funktion mit bestimmten Argumenten aufrufen möchte. Das LlamaIndex Agent Framework fängt diesen Request ab, führt deinen lokalen Python-Code aus und gibt das Ergebnis dann an das LLM zurück. Damit dieses autonome Routing funktioniert, brauchst du Tools. Ein Tool ist im Wesentlichen eine Standard-Python-Funktion, die in einer LlamaIndex-Klasse namens FunctionTool gewrappt ist. Aber weil das LLM wissen muss, wann und wie es deine Funktion nutzen soll, werden deine Code-Metadaten zu einem kritischen Teil des Systems. Das Framework extrahiert den Funktionsnamen, die Type Hints und den Docstring und übergibt sie als Instructions an das LLM. Schauen wir uns ein konkretes Szenario an. Du möchtest, dass dein Agent Mathe-Textaufgaben löst. Du schreibst zwei Python-Funktionen, eine namens add und eine namens multiply. Für die multiply-Funktion legen deine Type Hints fest, dass sie zwei Integers entgegennimmt und einen Integer zurückgibt. Ganz wichtig: Du schreibst einen Docstring, der klar besagt, dass diese Funktion zwei Zahlen miteinander multipliziert. Du wrappst beide Funktionen in Tools und übergibst sie in einer Liste, zusammen mit deinem gewählten LLM, um den Agenten zu initialisieren. Hier wird es interessant. Du fragst den Agenten, was zwei plus zwei, multipliziert mit drei ist. Der Agent geht in einen Reasoning Loop. Zuerst analysiert das LLM den Prompt und schaut sich die verfügbaren Tools an. Es liest deine Docstrings und entscheidet, dass es zuerst addieren muss. Es gibt einen Request aus, das add-Tool mit den Argumenten zwei und zwei aufzurufen. Das Framework führt deine Python-Funktion lokal aus und gibt das Ergebnis, vier, an den Agenten zurück. Der Agent ist noch nicht fertig. Er schaut sich das Zwischenergebnis und sein ursprüngliches Ziel an. Er entscheidet, dass er nun multiplizieren muss. Er fordert das multiply-Tool an und übergibt die vier, die er gerade erhalten hat, und die drei aus deinem ursprünglichen Prompt. Das Framework führt die Multiplikation aus und gibt zwölf zurück. Schließlich erkennt das LLM, dass das Problem gelöst ist, und generiert eine Conversational Response für den User. Hier gibt es keine hardcodierten Regeln oder explizite Routing Logic. Der Agent hat die Abhängigkeiten und die Reihenfolge der Operationen komplett selbstständig anhand der verfügbaren Tools herausgefunden. Das bedeutet, dass die Art und Weise, wie du deine Python-Definitionen schreibst, direkt bestimmt, wie intelligent dein Agent ist. Deine Type Hints und deine Docstrings sind nicht mehr nur für andere Entwickler gedacht, sie sind der buchstäbliche Prompt, der die autonome Logik des Agenten steuert. Wenn du einen Mehrwert aus diesen Folgen ziehst und die Show unterstützen möchtest, kannst du auf Patreon nach DevStoriesEU suchen. Das war’s für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. LlamaIndex: Context-Augmented LLM Applications, Folge 7 von 14. Du baust einen Agent, der Aktienkurse abfragen, Nachrichten aus Slack ziehen oder eine Datenbank abfragen muss. Du könntest Tage damit verbringen, API-Dokumentationen zu lesen, Authentication Schemas zu handhaben und Boilerplate Integration Code zu schreiben. Oder du schnappst dir einfach die fertige Arbeit, die ein Community Developer bereits geschrieben und verifiziert hat. In dieser Folge geht es um das Erweitern von Agents mit LlamaHub Tools. Agents brauchen Tools, um mit der Außenwelt zu interagieren. Du kannst zwar jede Integration manuell schreiben, aber LlamaHub gibt es genau dafür, um diese redundante Arbeit zu eliminieren. Es funktioniert als riesige Open-Source-Registry für pre-built Tool Specs. Eine Tool Specification, oder Tool Spec, ist im Grunde eine Python-Klasse, die mehrere zusammengehörige API Calls in einem einzigen Package bündelt. Indem du diese direkt in dein Projekt ziehst, sparst du dir den kompletten Prozess, die zugrundeliegende Logik für Third-Party-Services selbst zu schreiben. Um eine dieser Integrationen zu nutzen, installierst du das entsprechende Package. Wenn dein Agent Fragen zum Aktienkurs einer Company beantworten soll, schreibst du keinen Custom HTTP Request an die Yahoo API. Stattdessen nutzt du deinen Standard Package Manager, um das LlamaIndex Yahoo Finance Tools Package zu installieren. Sobald es installiert ist, importierst du die Yahoo Finance Tool Spec Klasse in dein Script. Hier ist der entscheidende Punkt: Du übergibst die Tool Spec Klasse nicht direkt an den Agent. Weil eine Tool Spec ein Bundle aus mehreren Capabilities ist, musst du sie zuerst entpacken. Das machst du, indem du eine Instanz der Yahoo Finance Tool Spec erstellst und dann eine spezifische Methode darauf aufrufst, die to tool list heißt. Diese Methode bricht das Bundle auf und gibt ein standardmäßiges, flaches Array von einzelnen Tools zurück, die der Agent lesen und ausführen kann. Durch dieses modulare Design bist du nicht darauf beschränkt, nur externe oder nur interne Tools zu verwenden. Du kannst sie nahtlos kombinieren. Angenommen, du hast bereits ein lokales Custom Function Tool, das Währungsbeträge speziell für dein firmeninternes Dashboard formatiert. Du erstellst einfach eine Standard Python List. In diese Liste packst du dein Custom Currency Formatter Tool und hängst außerdem die entpackten Tools aus der Yahoo Finance Tool List an. Du nimmst dann dieses kombinierte Array und übergibst es während der Initialisierung direkt an deinen Agent, indem du es dem tools Parameter zuweist. Wenn du den Agent mit einer Frage zu einem aktuellen Aktienkurs promptest, evaluiert der Agent den User Request anhand der Descriptions aller Tools in dieser kombinierten Liste. Er erkennt, dass das Yahoo Finance Tool die richtige Wahl ist, um die Marktdaten abzurufen. Er extrahiert das Company Ticker Symbol aus dem User Prompt, führt das Yahoo Finance Tool aus, ruft den Real-Time-Preis ab und kann dieses Raw Result dann optional in dein lokales Formatting Tool chainen, bevor er dem User die finale Antwort zurückgibt. Du hast deiner Application gerade komplexe Financial Lookup Capabilities gegeben, indem du ein Package installiert, eine Klasse instanziiert und eine Unpacking-Methode aufgerufen hast. Dieses Architectural Pattern gilt für Hunderte von Integrationen auf LlamaHub, vom Lesen von Google Drive Dokumenten bis hin zum Querying von Wikipedia. Die wahre Power eines autonomen Agents liegt nicht nur in der Reasoning Capability des zugrundeliegenden Language Models, sondern in der schieren Bandbreite an externen Systemen, auf die er über pre-built Tool Specs sofort zugreifen kann. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. LlamaIndex: Context-Augmented LLM Applications, Folge 8 von 14. Du fütterst ein Sprachmodell mit einem riesigen Prompt und bittest es, ein Thema zu recherchieren, einen Bericht zu schreiben und seine eigene Arbeit kritisch zu überprüfen. Es scheitert. Das Context Window wird durcheinandergebracht, Tools werden falsch eingesetzt, und der Output ist ein oberflächlicher Kompromiss. Die Lösung ist, diesen riesigen Prompt in einen Schwarm von Spezialisten aufzuteilen, und zwar mit Multi-Agent Swarms und AgentWorkflow. Ein einzelner, aufgeblähter Agent hat Schwierigkeiten, weil er zu viele Tools und widersprüchliche Anweisungen hat. Er muss entscheiden, wann er sucht, wann er einen Entwurf schreibt und wann er editiert – und das alles, während er einen riesigen internen Context verwaltet. AgentWorkflow löst das, indem es dir erlaubt, ein Netzwerk aus hochfokussierten Agenten zu definieren. Jeder Agent arbeitet mit einem engen System Prompt, einem begrenzten Set an Tools und einem einzigen Ziel. Stell dir eine Content Generation Pipeline vor. Statt eines einzigen Mega-Agenten erstellen wir drei verschiedene FunctionAgents. Zuerst den Researcher. Wir statten diesen Agenten mit einem Web Search Tool aus und weisen ihn strikt an, nur Fakten zu sammeln. Er schreibt keine Fließtexte. Als Nächstes definieren wir den Writer. Wir nehmen ihm die Search Tools komplett weg, damit er nicht abgelenkt wird. Seine einzige Aufgabe ist es, die rohen Fakten zu nehmen und saubere Absätze zu schreiben. Zum Schluss definieren wir den Reviewer. Wir geben ihm Guidelines zu Tonfall und faktischer Genauigkeit und weisen ihn an, den Text zu reviewen. Hier ist die entscheidende Erkenntnis. Mehrere Agenten zu haben ist nutzlos, wenn sie sich nicht koordinieren können. Aber ihnen freie Hand zu lassen, mit jedem zu reden, sorgt für Chaos. Du musst sie explizit miteinander verdrahten. In AgentWorkflow machst du das, indem du Handoff-Berechtigungen definierst. Wenn du deine Agenten konfigurierst, gibst du eine Property namens can handoff to an. Diese akzeptiert eine Liste von anderen Agenten. Für unsere Pipeline geben wir dem Researcher die Berechtigung für einen Handoff an den Writer. Wir geben dem Writer die Berechtigung für einen Handoff an den Reviewer. Wir geben dem Reviewer außerdem die Berechtigung für einen Handoff zurück an den Writer, falls der Text überarbeitet werden muss. Das erzeugt einen strikten, gerichteten Graphen von Agenten. Das Framework erzwingt diese Grenzen. Der Researcher kann den Writer nicht umgehen und rohe Notizen direkt an den Reviewer schicken. Er hat schlichtweg nicht die Autorisierung dafür. Um das auszuführen, übergibst du deine Liste von Agenten an eine AgentWorkflow-Instanz. Du startest den Prozess, indem du den Workflow mit einer initialen User Query ausführst und ihn auf den Researcher richtest, um das Ganze anzustoßen. Das Workflow-Framework verwaltet den Shared State und das Routing automatisch. Der Researcher führt seine Search Tools aus, stellt die Daten zusammen und entscheidet intern, dass sein Job erledigt ist. Dann nutzt er sein Handoff Tool, um die Kontrolle zusammen mit den gesammelten Daten an den Writer zu übergeben. Der Writer nimmt diesen Context, entwirft den Bericht und macht einen Handoff an den Reviewer. Wenn der Reviewer einen Fehler entdeckt, triggert er einen Handoff zurück an den Writer mit Feedback. Dieser Loop geht weiter, bis ein Agent entscheidet, dass die Arbeit abgeschlossen ist, und eine finale Response an den User zurückgibt, anstatt einen weiteren Handoff zu triggern. Einen Agenten auf eine einzige Rolle zu beschränken und seine Kommunikationswege explizit zu definieren, ist der zuverlässigste Weg, um komplexes, mehrstufiges Reasoning aus Sprachmodellen herauszuholen. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. LlamaIndex: Context-Augmented LLM Applications, Folge 9 von 14. Wenn du autonome Agents die Kontrolle Peer-to-Peer weitergeben lässt, landest du schnell in Endlosschleifen oder verlierst den Context. Manchmal kannst du dich nicht darauf verlassen, dass Agents die Kontrolle reibungslos aneinander übergeben. Du brauchst einen zentralen Manager, der die gesamte Operation steuert. Genau das ist das Orchestrator Agent Pattern. In einem Multi-Agent-System klingt es zwar mächtig, wenn Agents direkt miteinander kommunizieren, aber das wird schnell zum Debugging-Albtraum. Du verlierst den Überblick darüber, wer das Sagen hat, und das Management des globalen States der Applikation wird extrem komplex. Das Orchestrator Pattern löst dieses Problem, indem es strikt ein Hub-and-Spoke-Modell erzwingt. Es gibt einen Top-Level Orchestrator Agent, und alle anderen Agents werden strikt als Tools behandelt, die dieser Orchestrator nutzt. Gehen wir mal ein Szenario durch, in dem dein System ein fundiert recherchiertes technisches Briefing generieren muss. Du richtest einen Orchestrator Agent ein, der als strenger Manager fungiert. Dieser Manager besitzt den globalen State. Er merkt sich den ursprünglichen User Prompt, hält den Master Context und trackt, was bisher erreicht wurde. Er erledigt die eigentliche harte Arbeit aber nicht selbst. Stattdessen stellst du ihm Tools zur Verfügung. Diese Tools sind keine einfachen API-Wrapper oder simplen Taschenrechner. Es sind komplett separate, voll funktionsfähige Sub-Agents. Du baust vielleicht einen Sub-Agent speziell für die Recherche, ausgestattet mit Vector Search und Web Scraping. Und vielleicht baust du einen zweiten Sub-Agent speziell fürs Schreiben, ausgestattet mit Style-Guidelines und Formatting-Logik. In LlamaIndex nimmst du diese Sub-Agents und stellst ihre Run-Methoden als Tools bereit. Dadurch kapselst du ihre gesamten internen Reasoning Loops hinter einem Standard-Tool-Interface mit einem Namen und einer Description. Für den Orchestrator sehen diese Sub-Agents exakt wie Standard-Python-Funktionen aus. Wenn der User das Briefing anfordert, evaluiert der Orchestrator das Gesamtziel basierend auf den Tool Descriptions, die du bereitgestellt hast. Er entscheidet sich, zuerst das Research Tool aufzurufen, und übergibt die nötigen Parameter. Die Kontrolle wechselt vorübergehend zum Research Sub-Agent. Dieser Sub-Agent führt seinen eigenen autonomen Loop aus. Er macht vielleicht drei oder vier interne Tool Calls, um Daten zu sammeln, die Fakten zu synthetisieren und eine Antwort zu formulieren. Sobald der Research Agent fertig ist, fasst er all diese Arbeit in einem finalen Text String zusammen und gibt ihn zurück. Hier ist die entscheidende Erkenntnis: Der Orchestrator gibt die Kontrolle über den Main Process eigentlich nie ab. Er wartet nur darauf, dass das Tool einen Wert zurückgibt. Der Orchestrator empfängt die Research Summary, fügt sie seinem eigenen Context hinzu und evaluiert den nächsten Schritt. Er erkennt, dass die Informationen in ein Dokument gegossen werden müssen, also ruft er das Writing Tool auf und übergibt die frische Recherche als Input-Parameter. Der Writing Sub-Agent übernimmt, macht sein eigenes internes Processing und gibt den fertigen Text zurück. Der Orchestrator sieht, dass das finale Ziel erreicht ist, und liefert dem User die Response. Diese strikte Separation of Concerns macht dein System extrem berechenbar. Der Research Agent muss nicht wissen, dass der Writing Agent existiert. Keiner der Sub-Agents muss sich darum kümmern, den Context zu übergeben, die finale User Response zu formatieren oder zu entscheiden, wann der gesamte Job erledigt ist. Der Orchestrator zentralisiert die gesamte High-Level-Entscheidungslogik. Indem du Sub-Agents zwingst, rein als isolierte Tools innerhalb des Loops eines zentralen Managers zu agieren, kannst du extrem leistungsfähige Multi-Agent-Systeme bauen, die komplett berechenbar und leicht zu debuggen bleiben. Das war's für diese Folge. Bis zum nächsten Mal!

Hallo, hier ist Alex von DEV STORIES DOT EU. LlamaIndex: Context-Augmented LLM Applications, Folge 10 von 14. Built-in Agent Orchestration ist super, bis deine Business Logic anfängt, wie ein Teller Spaghetti auszusehen. Wenn Standard-Hand-offs deine hochspezifischen Scheduling-Regeln nicht mehr abbilden können, werden Abstraktionen zum Blocker. Genau dann brauchst du Custom Multi-Agent Planners. Ein Custom Planner ist deine Power-User Escape Hatch. Damit kannst du deine eigene Orchestration Loop von Grund auf mit einem Standard LlamaIndex Workflow bauen. Anstatt dich auf einen pre-built Supervisor zu verlassen, der vorgibt, welcher Agent als Nächstes dran ist, steuerst du den gesamten Scheduling-Prozess imperativ in Python. Du bestimmst die Execution Order, das Data Routing und das State Management. Der Prozess beginnt normalerweise in einer Custom Class, oft PlannerWorkflow genannt. Die erste Phase ist das Planning. Wenn ein User einen Request schickt, sendet dein Workflow einen Prompt an ein Large Language Model. Dieser Prompt enthält die User Query und eine strikte Beschreibung der Tools oder Agents, die dir zur Verfügung stehen. Du weist das Language Model explizit an, einen Step-by-Step-Plan in einem hochstrukturierten Format zu generieren. Zum Beispiel könntest du dem Model sagen, dass es jede Action in einen XML-Block mit Step-Tags packen oder als JSON Array formatieren soll. Wenn das Model antwortet, parst du diesen strukturierten Output. Du nutzt eine Library wie Pydantic, um das XML oder JSON zu validieren und in eine konkrete Liste von Tasks umzuwandeln, über die dein Code iterieren kann. Jetzt kommst du in die Execution-Phase. Dieser Teil ist komplett deiner Custom Logic überlassen. Dein Workflow iteriert nacheinander durch die geparste Liste der Steps. Bei jedem Step prüft er die angeforderte Action. Du nutzt Standard Conditional Logic, um zu entscheiden, was als Nächstes passiert. Wenn der geparste Step einen Research Task vorgibt, ruft dein Code explizit deinen Research Agent auf. Wenn der nächste Step eine Berechnung erfordert, triggerst du deinen Math Agent. Hier ist der entscheidende Punkt: Weil du die Loop selbst schreibst, behältst du die komplette Ownership über den State. Typischerweise erstellst du ein Shared Context Dictionary, das für die Dauer des Workflow Runs existiert. Wenn dein Research Agent seinen Task beendet hat, nimmt dein Workflow das Result und schreibt es direkt in dieses Dictionary. Wenn der nächste Step den Math Agent triggert, kann deine Custom Logic ihm genau die benötigten Daten aus diesem Shared Dictionary übergeben. Du hoffst nicht einfach darauf, dass ein Black-Box Orchestrator die richtigen Variablen übergibt. Du mappst die Outputs des einen Agents explizit auf die Inputs des nächsten. Sobald die Loop alle Steps in deinem validierten Plan abgeschlossen hat, übernimmt dein Workflow das finale Formatting und gibt die Antwort zurück. Einen Custom Planner zu bauen bedeutet, dass du Out-of-the-box-Convenience gegen totale Kontrolle eintauschst. Wenn ein Agent fehlschlägt, kannst du eine Custom Retry Logic für diesen spezifischen Step schreiben. Wenn ein Step eine externe API Validation braucht, kannst du die Loop pausieren. Du schreibst ganz normalen imperativen Code, der eben zufällig Language Models als Funktionen nutzt. Der ultimative Mehrwert eines Custom Planners ist Predictability. Indem du das Language Model zwingst, einen strikten XML-Plan zu generieren, und diesen mit Standard Python Loops und Dictionaries ausführst, eliminierst du das Rätselraten von Black-Box Orchestration komplett. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. LlamaIndex: Context-Augmented LLM Applications, Folge 11 von 14. Du baust einen Agenten, um deine Infrastruktur zu verwalten, und er entscheidet, dass der beste Weg zur Behebung eines Fehlers darin besteht, eine Production-Datenbank zu löschen. Lass einen autonomen Agenten niemals eine destruktive Aktion ausführen, ohne vorher explizit einen Menschen um Erlaubnis zu fragen. Um das zu verhindern, brauchst du Human-in-the-Loop Workflows. Human-in-the-Loop ist ein Event-driven Mechanismus, der einen Agenten pausiert, externen Input anfordert und die Execution basierend auf der Antwort fortsetzt. Anstatt den Agenten ungestört durch seinen Thought and Action Cycle laufen zu lassen, fängst du High-Risk-Operationen ab. Das erreichst du in LlamaIndex Workflows mit drei spezifischen Komponenten: dem InputRequiredEvent, der wait_for_event Methode und dem HumanResponseEvent. Stell dir ein gefährliches Task-Tool vor, das dafür gedacht ist, eine Cloud-Ressource zu löschen. Der Agent entscheidet, dass er dieses Tool nutzen muss, und triggert den entsprechenden Workflow Step. Wenn das Tool sofort ausgeführt wird, ist die Ressource weg. Stattdessen fängt der Workflow Step die Execution ab. Bevor irgendetwas gelöscht wird, erstellt der Step ein InputRequiredEvent. Dieses Event enthält einen Payload mit Details zur Aktion, wie dem Namen der Zielressource und einem Prompt, der den User bittet, die Löschung zu bestätigen. Der Step sendet dieses Event an die Main Application. Hier ist der entscheidende Punkt. Der Workflow Step kann nicht einfach in einem Active Loop sitzen und auf eine Antwort warten. Du musst seinen State pausieren. Das machst du, indem du wait_for_event auf dem Workflow Context aufrufst und angibst, dass der Step nun auf ein HumanResponseEvent lauscht. Diese Aktion gibt die Kontrolle an das Environment zurück. Die Workflow Engine pausiert den Step komplett und friert den Agenten in seinem aktuellen State ein, ohne Compute-Ressourcen zu verbrauchen, während er wartet. Außerhalb des Workflows fängt dein Application Layer das InputRequiredEvent ab. Du liest den Payload und zeigst dem User den Confirmation Prompt auf seinem Command-Line Interface an. Der Mensch liest die Warnung und tippt yes oder no. Jetzt musst du den Agenten wieder entpausieren. Deine Application nimmt den User Input und verpackt ihn in ein HumanResponseEvent. Du sendest dieses neue Event direkt zurück in die laufende Workflow Engine. Die Engine erkennt den Event-Typ und routet es genau zu dem Step, der pausiert wurde. Die wait_for_event Methode resolvet und gibt den Human Response String zurück an die Tool-Logik. Das Tool wertet die Response aus. Wenn der Mensch yes getippt hat, fährt das Tool mit dem API Call fort, um die Cloud-Ressource zu löschen. Wenn der Mensch no getippt hat, bricht das Tool die Löschung ab. In beiden Fällen gibt das Tool eine finale Status Message an den Agenten zurück. Der Agent verarbeitet dieses Outcome, versteht, ob die Aktion erfolgreich war oder vom User blockiert wurde, und entscheidet über seinen nächsten Schritt. Indem du Events nutzt, um die Execution zu pausieren und fortzusetzen, behält dein Agent seinen gesamten Reasoning Context und Memory, während er Stunden oder sogar Tage darauf wartet, dass ein Mensch eine Entscheidung trifft. Das war es für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. LlamaIndex: Context-Augmented LLM Applications, Folge 12 von 14. Wenn ein autonomer Agent einen Fehler macht, ist es ein absoluter Albtraum, sich durch Standard-Python-Print-Statements zu wühlen, um das Problem zu finden. Du stellst eine einfache Frage, bekommst eine halluzinierte Antwort, und der Standard-Stacktrace sagt dir absolut gar nichts darüber, warum das Modell gelogen hat. Um das zu beheben, brauchst du eine Möglichkeit, in die Blackbox zu schauen. Diese Folge behandelt Observability und Tracing. Herkömmliche Debugging-Tools stoßen bei Large Language Models an ihre Grenzen. Ein Stacktrace sagt dir zwar, wo der Code gecrasht ist, aber LLM-Bugs sind meistens logischer Natur. Der Code läuft perfekt, aber das System ruft das falsche Dokument ab oder interpretiert einen Prompt falsch. Standard-Python-Logging ist deine erste Verteidigungslinie. Wenn du das Logging-Level auf Debug setzt, gibt LlamaIndex einen Raw-Feed von allem aus, was es tut. Du siehst die exakten Prompts, die an das Language Model gesendet werden, und die rohen HTTP-Responses. Das ist nützlich, um zu checken, ob ein Network Call fehlgeschlagen ist, aber für einen mehrstufigen Agent-Workflow ist das Lesen einer Wand aus unstrukturiertem Text unglaublich mühsam. Hier ist die entscheidende Erkenntnis: Du brauchst nicht einfach nur ein Event-Log; du musst den Call Graph sehen. Du brauchst eine strukturierte Ansicht, wie die Daten von der initialen Query durch die Retriever in das Language Model und wieder zurück fließen. LlamaIndex handhabt das mithilfe eines Callback-Systems. Callbacks sind Hooks, die an bestimmten Punkten im Ausführungszyklus auslösen. Das Framework bietet ein integriertes Tool namens Llama Debug Handler. Du initialisierst diesen Handler und hängst ihn an deine globalen Settings an. Von da an zeichnet er still im Hintergrund jede Operation auf. Angenommen, du führst eine Query Engine aus, und sie liefert einen völlig frei erfundenen Fakt zurück. Ohne Tracing hast du keine Ahnung, ob das Modell halluziniert hat oder ob deine Datenbank ihm schlechte Informationen geliefert hat. Wenn der Debug Handler angehängt ist, kannst du ihn anweisen, den Trace nach Abschluss der Query auszugeben. Der Trace zeigt die genaue Abfolge der Events. Du siehst die initiale Query. Du siehst den Retrieval-Schritt. Ganz entscheidend: Du siehst die exakten Text Nodes, die der Retriever aus deinem Index gezogen hat. Du inspizierst diese Nodes im Trace und stellst fest, dass ein veraltetes Dokument abgerufen wurde. Das Language Model hat nicht halluziniert; es hat einfach nur schlechte Daten gelesen. Du fixt den Index, und der Bug ist behoben. Terminal-Traces sind super für die lokale Entwicklung, aber sie skalieren nicht gut, wenn du komplexe Agents hast, die Dutzende von Reasoning-Schritten machen. Für Production bietet LlamaIndex die sogenannte One-Click Observability. Indem du eine bestimmte Environment Variable setzt oder eine einzige Konfigurationszeile hinzufügst, kannst du all diese Callback-Daten an eine dedizierte Observability-Plattform routen. Diese Plattformen lesen die Trace-Daten ein und generieren visuelle Dashboards. Du kannst dich durch einen visuellen Tree deines Agent-Workflows klicken und die genaue Latency, Token Usage und Payload für jeden einzelnen Schritt inspizieren. Du musst nicht jede Funktion manuell instrumentieren; die nativen Callbacks des Frameworks übernehmen die Hauptarbeit. Der Unterschied zwischen einem fragilen Prototyp und einer zuverlässigen Production-Anwendung ist, ob du genau erklären kannst, warum das System eine bestimmte Response generiert hat. Wenn du das nützlich fandest und die Show unterstützen möchtest, kannst du auf Patreon nach DevStoriesEU suchen. Das war's für diese Folge. Danke fürs Zuhören und viel Spaß beim Entwickeln!

Hallo, hier ist Alex von DEV STORIES DOT EU. LlamaIndex: Context-Augmented LLM Applications, Folge 13 von 14. Du tauschst dein Embedding Model aus und plötzlich wirken deine Antworten etwas merkwürdig, aber du kannst nicht genau sagen, warum. Wenn du dir die Outputs nur grob anschaust, um die Qualität zu prüfen, tappt deine Pipeline im Dunkeln. Um dich nicht länger auf dein Bauchgefühl zu verlassen und Regressions in Production zu vermeiden, brauchst du RAG Evaluation Metrics. Eine RAG-Applikation zu bauen ist einfach, aber sie robust zu machen, ist schwer. Du wirst ständig Chunk Sizes, Prompts und Retrieval-Strategien anpassen. Wenn du dich bei jeder Änderung auf manuelle Reviews verlässt, verlangsamst du entweder die Entwicklung oder du deployest Regressions. Du brauchst automatisierte, objektive Messungen. Weil RAG aus zwei separaten Schritten besteht – dem Finden der richtigen Informationen und dem Generieren einer Antwort darauf – musst du beide Phasen separat evaluieren. Schauen wir uns zuerst die Generierung an. Das nennt man Response Evaluation. Die primäre Metrik hier ist Faithfulness. Das Ziel ist es, Halluzinationen abzufangen. Eine faithful Response ist eine, bei der sich das Language Model komplett auf den abgerufenen Context verlässt, anstatt Fakten aus seinen eigenen Pre-Training-Daten zu erfinden. In LlamaIndex machst du das mit dem FaithfulnessEvaluator. Dieses Tool nutzt unter der Haube ein Language Model, das als Judge agiert. Du initialisierst den Evaluator, dann übergibst du ihm die ursprüngliche Query, das Array der abgerufenen Context Nodes und den finalen generierten Text. Der Evaluator gibt ein Evaluation Object zurück, das einen binären Pass- oder Fail-Boolean enthält. Dieser sagt dir, ob die Response strikt durch den bereitgestellten Context gestützt wird. Es liefert auch einen Reasoning String, der erklärt, warum der Judge diese Entscheidung getroffen hat. Wenn dein Faithfulness Score nach einem Update sinkt, werden dein Prompt oder dein Language Model vielleicht zu kreativ. Nun zum zweiten Teil des Ganzen. Selbst das beste Language Model kann keine faithful Answer generieren, wenn du ihm die falschen Dokumente übergibst. Hier kommt die Retrieval Evaluation ins Spiel. Hier ist die entscheidende Erkenntnis: Du evaluierst das Retrieval, indem du prüfst, ob das System für eine bestimmte Query genau die erwarteten Source Nodes gefetcht hat, und ignorierst dabei den finalen generierten Text komplett. Das machst du mit dem RetrieverEvaluator. Stell dir ein Szenario vor, in dem du ein neues Embedding Model testen willst. Anstatt es zu deployen und zu raten, ob es besser ist, baust du ein Evaluation Dataset. Dieses Dataset enthält eine Liste von Queries, gepaart mit den spezifischen Document Identifiers, die die korrekten Antworten enthalten. Du jagst deinen gesamten Batch an Queries durch den RetrieverEvaluator. Der Evaluator berechnet zwei entscheidende Metriken: Hit Rate und MRR. Die Hit Rate ist simpel. Sie prüft, ob das erwartete Dokument irgendwo in deinen Top-Ergebnissen aufgetaucht ist. Wenn du fünf Dokumente abrufst und das richtige dabei ist, ist das ein Hit. Sie misst reinen Recall. Aber die Position ist wichtig. Wenn das richtige Dokument immer an fünfter Stelle steht, ignoriert dein Language Model es vielleicht wegen Context Limits oder Attention Decay. Hier kommt der Mean Reciprocal Rank, oder MRR, ins Spiel. MRR schaut sich die Position des ersten relevanten Dokuments an. Wenn das richtige Dokument ganz oben steht, ist der Score eins. Ist es an zweiter Stelle, ist der Score ein Halb. Ist es an dritter Stelle, ein Drittel. Der Evaluator bildet den Durchschnitt dieser Brüche über dein gesamtes Dataset. Ein höherer MRR bedeutet, dass dein Retriever die relevantesten Informationen konstant ganz nach oben ins Context Window pusht. Indem du die Hit Rate und den MRR deines alten Embedding Models mit dem neuen vergleichst, bekommst du den mathematischen Beweis, welches Modell besser performt. Du kannst diese Zahlen über die Zeit tracken und diese Pipeline bei jedem Pull Request automatisch laufen lassen. Das absolut Wertvollste, was du für deine RAG Pipeline tun kannst, ist, die Evaluation dessen, was du abrufst, davon zu trennen, wie du die finale Answer generierst. Danke, dass du ein paar Minuten mit mir verbracht hast. Bis zum nächsten Mal, mach's gut.

Hallo, hier ist Alex von DEV STORIES DOT EU. LlamaIndex: Context-Augmented LLM Applications, Folge 14 von 14. Schluss mit dem ständigen Copy-and-Paste derselben API und des React-Boilerplates, wenn du eine neue Retrieval-Augmented Generation Idee testen willst. Du verstehst die Framework-Mechaniken bereits, aber ein sauberes Interface aufzusetzen, um deine Models tatsächlich zu nutzen, kostet immer noch Stunden an repetitiver Arbeit. Heute schauen wir uns die Starter-Tools an, mit denen du in Sekundenschnelle ein Scaffold für die Production bauen kannst. Eine funktionierende Application zu bauen, erfordert viel mehr als nur einen Index und eine Query Engine. Du brauchst einen Backend-Server, der eingehende Requests sicher verarbeitet. Du brauchst API-Routes, um Messages hin und her zu schicken. Du brauchst einen Frontend-Client, der die Chat History anzeigt, Loading States rendert und die Responses parst. Diese Infrastruktur für jedes neue Dataset oder jeden Prototyp from scratch zu schreiben, raubt dir extrem viel Zeit. Um das zu lösen, bietet LlamaIndex ein Command-Line Utility namens create-llama. Dieses Tool generiert eine komplette Full-Stack Web Application, die mit LlamaIndex Best Practices vorkonfiguriert ist. Du öffnest dein Terminal und führst den create-llama Command aus. Das Tool führt dich dann durch eine Reihe von Auswahlmöglichkeiten. Es fragt dich, ob du ein Python-Backend mit FastAPI oder ein Node-Backend mit Express haben möchtest. Es fragt, ob du ein Next JS Frontend willst, um deinen Usern ein poliertes Web-Interface zu bieten. Dann fragt es nach deiner Data Source. Du kannst das Tool direkt auf einen lokalen Ordner mit deinen PDF-Files zeigen lassen. Sobald du die Prompts abgeschlossen hast, übernimmt create-llama. Es installiert alle benötigten Dependencies. Es scaffoldet die Directory-Struktur. Es schreibt das Ingestion-Script, um deine PDFs zu parsen. Es verkabelt die API-Endpoints, damit dein Frontend mit deiner Retrieval Engine kommunizieren kann. Zu guter Letzt richtet es die Environment Variables ein. Du führst einen einzigen Start-Command aus und hast sofort ein gestyltes Chat-Interface, das in deinem Browser läuft. Du kannst eine Frage eintippen, und das Interface ruft das generierte Backend auf, holt den Context aus deinen PDFs und streamt die Antwort zurück auf deinen Screen. Du kommst in etwa dreißig Sekunden von einem leeren Ordner zu einem funktionierenden Full-Stack Prototypen. Damit wären Web Applications abgedeckt. Aber manchmal sind ein Webserver und ein grafisches Interface einfach Overkill. Wenn du gerade eine lange technische Spezifikation heruntergeladen hast und sie sofort queryn musst, ohne deine Command Line zu verlassen, nutzt du die RAG CLI. Die RAG CLI ist ein Tool, das rein für die terminalbasierte Document Interaction gebaut wurde. Du installierst es und führst dann einen Command aus, um es auf dein lokales Document Directory zeigen zu lassen. Die CLI führt den Ingestion-Prozess automatisch aus. Sie chunkt den Text, generiert Embeddings und speichert sie in einer lokalen Vector Database direkt auf deiner Maschine. Wenn die Ingestion fertig ist, führst du den Chat-Command aus. Dein Standard-Terminal-Prompt verwandelt sich in eine Chat-Session. Du stellst eine Frage, die CLI holt die relevanten Daten, queryt das Language Model und printet die generierte Antwort direkt in deine Console. Es gibt keine visuellen Components oder Web-Routes, die konfiguriert werden müssen. Es ist der absolut schnellste Weg, lokal mit deinen Daten zu sprechen. Hier ist die wichtigste Erkenntnis. Du verstehst jetzt die tiefen Mechaniken von Context-Augmented Applications, vom Chunken von Documents bis hin zum Bauen komplexer Agent Routers. Diese Scaffolding-Tools existieren, damit du dich nicht mehr mit grundlegender Infrastruktur herumschlagen musst und deine Zeit damit verbringen kannst, diese Core Retrieval Strategies zu tunen. Da dies die letzte Folge unserer LlamaIndex-Serie ist, ist der beste nächste Schritt, rüber zur offiziellen Documentation zu gehen und zu versuchen, diese Pipelines hands-on zu bauen. Wenn du eine Idee für einen komplett anderen Technology Stack hast, den wir behandeln sollen, besuche devstories dot eu, um ein Thema vorzuschlagen. Das war's für diese Folge. Danke fürs Zuhören und keep building!