Prompt Flow: The Complete Guide

Hallo, hier ist Alex von DEV STORIES DOT EU. Prompt Flow: Der vollständige Leitfaden, Folge 1 von 14. Die meisten KI-Libraries versuchen, Komplexität zu abstrahieren, indem sie deine Prompts tief in Wrapper-Funktionen verstecken. Aber wenn du in Production gehst, sind diese Prompts genau das, was du kontrollieren musst. Das ist die Kernphilosophie von Prompt Flow. Lass uns zuerst ein häufiges Missverständnis aufklären. Prompt Flow ist kein Framework wie LangChain. LangChain ist ein Development-Framework, das vorgefertigte Chains und Agents bereitstellt, die oft die zugrundeliegenden Prompts kapseln. Prompt Flow ist eine Suite von Tools, die für Experimente und Evaluation entwickelt wurde. Es existiert, weil das traditionelle Software-Engineering-Prinzip der Kapselung tatsächlich zum Nachteil wird, wenn du Anwendungen mit Large Language Models baust. In der Standardprogrammierung versteckst du komplexe Logik hinter einem sauberen Function-Interface. Du musst nicht wissen, wie die Funktion intern arbeitet, dich interessiert nur, was sie zurückgibt. Aber Prompts sind extrem volatil. Sie sind keine statische Logik. Wenn du dein Modell von einer Version auf eine andere aktualisierst, kann ein Prompt, der gestern noch perfekt funktioniert hat, heute fehlschlagen. Wenn du eine undurchsichtige Third-Party-Library verwendest, um Dokumente zusammenzufassen, und der zugrundeliegende Prompt in dieser Library eingesperrt ist, kannst du eine schlechte Zusammenfassung nicht reparieren. Du bist komplett von den Library-Maintainern abhängig. Prompt Flow dreht dieses Design-Pattern um, indem es die Prompts offenlegt. Es behandelt sie als First-Class Developer Assets. Du musst sie kontinuierlich einsehen, tunen und versionieren. Statt einer Blackbox bekommst du eine transparente Toolchain, bei der du den genauen Text und die Variablen kontrollierst, die in das Language Model fließen. Das ist der entscheidende Punkt. Weil Prompts volatil sind, erfordert das Bauen von KI-Anwendungen eine grundlegend neue Arbeitsweise. Bei Standard-Software schreibst du Unit-Tests. Du stellst per Assertion sicher, dass ein bestimmter Input einen bestimmten Output erzeugt. Language Models sind probabilistisch, das heißt, sie liefern keine deterministischen Antworten. Du kannst keine einfache Assertion schreiben, um zu prüfen, ob eine generierte E-Mail höflich oder eine Zusammenfassung korrekt ist. Stattdessen musst du dir einen evaluierungszentrierten Workflow aneignen. Du musst deinen Prompt über hunderte verschiedener Beispiele laufen lassen und Metriken wie Relevanz oder Formatierungsgenauigkeit messen. Prompt Flow ist direkt um diesen Workflow herum aufgebaut. Es integriert Prompt-Tuning mit Massen-Evaluation. Wenn du ein einziges Wort in deinem Prompt änderst, hilft dir das Tooling statistisch zu sehen, ob diese Änderung deine Erfolgsquote über dein gesamtes Dataset hinweg verbessert oder verschlechtert hat. Die letzte Säule dieser Philosophie ist die Optimierung auf Visibility. KI-Anwendungen sind selten nur ein einziger API-Call. Sie sind komplexe Execution Graphs. Du nimmst vielleicht eine User-Frage, fragst eine Vektor-Datenbank ab, formatierst die abgerufenen Daten, injizierst sie in einen Prompt und rufst dann das Modell auf. Wenn die finale Antwort falsch ist, musst du genau wissen, wo die Chain gebrochen ist. Prompt Flow macht diesen Execution Graph sichtbar. Du kannst jeden Node inspizieren, um die genauen Inputs und Outputs an genau diesem Schritt im Prozess zu sehen, was das Debugging unkompliziert macht. Das absolut Wichtigste, was du mitnehmen solltest, ist, dass Prompts lebendige, volatile Variablen sind, die ständige Beobachtung erfordern – kein statischer Code, den du einmal schreibst und dann versteckst. Wenn du diese Folgen hilfreich findest und die Show unterstützen möchtest, kannst du nach DevStoriesEU auf Patreon 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. Prompt Flow: Der vollständige Guide, Folge 2 von 14. Bevor du auch nur eine Zeile Code schreibst, musst du aufhören, LLM-Applications als monolithische Skripte zu betrachten. Wenn du versuchst, sie linear zu schreiben, wird das Tracking von Dependencies und das Debugging von State über mehrere externe Services hinweg schnell unübersichtlich. Die strukturelle Lösung dafür ist, deine Application als einen Graphen von unabhängigen Function Calls zu betrachten – ein Konzept, das in Prompt Flow als Flows und DAG-Architektur bekannt ist. Ein Flow ist einfach ein ausführbarer Workflow. Im Kern ist eine LLM-Application eine orchestrierte Sequenz von externen Calls, die durch Logik zusammengehalten werden. Du rufst vielleicht eine Suchmaschine auf, machst eine Database Query, führst ein Python-Skript aus, um die abgerufenen Daten zu formatieren, und sendest schließlich einen Prompt an ein LLM. Prompt Flow modelliert diese Sequenz als Directed Acyclic Graph, oder DAG. In diesem Graphen ist jeder einzelne Schritt deiner Application ein Node, und die Verbindungen zwischen diesen Nodes repräsentieren den Data Flow. Er ist directed, weil sich die Daten von einer Funktion zur nächsten vorwärts bewegen, und er ist acyclic, weil der Datenpfad keine Loops bildet. Stell dir eine einfache Application vor, die Fragen basierend auf internen Unternehmensdaten beantwortet. Der User stellt eine Frage, die als dein initialer Input dient. Dieser Input fließt in den ersten Node, eine Python-Funktion, die eine Database Query ausführt. Die Datenbank liefert einen Textblock zurück. Dieser Text fließt zusammen mit der ursprünglichen User-Frage in den nächsten Node, der den eigentlichen Call an das LLM macht. Das LLM generiert eine Antwort, die zum finalen Output des gesamten Graphen wird. Durch diese Strukturierung der App ist jede Funktion strikt isoliert. Du weißt genau, was in den Database Call reingegangen ist und was herauskam, bevor das LLM überhaupt getriggert wurde. Beim Bauen dieser Workflows stoßen Developer oft auf zwei Begriffe und fragen sich, welcher besser ist: Flex Flow und DAG Flow. Hier wird es interessant. Beide erzielen exakt dasselbe Ergebnis. Sie bieten einfach eine unterschiedliche Developer Experience. Flex Flow ist ein Code-First-Ansatz. Du kapselst deine Logik in einer Standard-Python-Funktion oder -Klasse, definierst sie als Entry Point und schreibst Raw Code. Prompt Flow führt ihn einfach aus. DAG Flow hingegen definiert das Routing über eine YAML-Datei. Indem du Funktionen explizit als Nodes auflistest und ihre Inputs und Outputs in YAML verknüpfst, ermöglichst du der Plattform, eine visuelle Repräsentation deiner Application zu rendern. DAG Flows sind extrem UI-friendly, was es einfach macht, die Architektur auf einen Blick zu inspizieren. Wenn du dich für den DAG Flow-Ansatz entscheidest, wirst du mit drei spezifischen Arten von Flows arbeiten. Der erste ist der Standard Flow. Das ist deine General-Purpose-Pipeline, in der du Tools, Python-Code und Models verbindest, um typische Applications zu bauen. Der zweite ist der Chat Flow. Dieser baut direkt auf dem Standard Flow auf, ist aber speziell auf Conversational Applications zugeschnitten. Er fügt nativen Support für das Managen der Chat History hinzu und konfiguriert die nötigen Chat Inputs und Outputs automatisch. Der dritte Typ ist der Evaluation Flow. Du nutzt diesen Flow nicht, um End User zu bedienen. Stattdessen lässt du einen Evaluation Flow gegen die Outputs deiner Standard oder Chat Flows laufen. Er fungiert als Testing-Mechanismus, um Metrics wie Factual Accuracy oder Relevanz zu berechnen, basierend auf den Daten, die dein Main Flow produziert hat. Ob du deine Logik in purem Python definierst oder sie visuell mit YAML verdrahtest – deine LLM-Application ist letztendlich nur eine Pipeline, die Text zwischen externen Systemen routet. Meistere den Graphen, und du kontrollierst die Application. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Prompt Flow: Der vollständige Leitfaden, Folge 3 von 14. Du hast den perfekten Workflow für deine KI-Anwendung entworfen, aber ein Entwurf allein verarbeitet keine Daten. Du brauchst Komponenten, die die eigentliche Arbeit ausführen, wie zum Beispiel URLs abrufen, Strings formatieren und APIs aufrufen. Wenn Flows der Entwurf deiner Anwendung sind, sind Tools die Bausteine. Heute schauen wir uns Tools an. In Prompt Flow sind Tools die grundlegenden, ausführbaren Bausteine eines Flows. Jeder Node in deinem Graphen ist ein Tool. Wenn dein Flow läuft, übergibt er einfach Daten von einem Tool zum nächsten. Obwohl du die Plattform erweitern kannst, gibt es drei integrierte Tools, die du in fast jedem Projekt verwenden wirst: das Python-Tool, das Prompt-Tool und das LLM-Tool. Gehen wir mal ein praktisches Szenario durch, um zu sehen, wie sie zusammenwirken. Du möchtest eine Anwendung, die eine Webseite abruft, den Raw Text formatiert und eine Zusammenfassung generiert. Zuerst musst du den Inhalt der Webseite abrufen. Dafür verwendest du das Python-Tool. Mit diesem Tool kannst du eigene Python-Skripte schreiben, und es dient als deine Brücke zur Außenwelt. Du schreibst ein kurzes Skript, das eine URL als Input nimmt, einen HTTP-Request macht und den Raw Text der Seite zurückgibt. Das Python-Tool übernimmt die Ausführung und gibt diesen Raw Text als Output weiter. Als Nächstes musst du die Instructions für das Sprachmodell vorbereiten. Dafür nutzt du das Prompt-Tool. Dieses Tool nimmt Text-Inputs, wie den Raw Text von deinem Python-Tool und einen System Prompt, der die KI-Persona definiert, und formatiert sie zu einem einzigen, sauberen String. Das ist der entscheidende Teil. Das Prompt-Tool ruft kein KI-Modell auf. Es bereitet Text wirklich nur vor und formatiert ihn. Diesen Schritt zu trennen, macht deinen Flow viel einfacher zu lesen und zu testen, besonders wenn du mit komplexen, mehrteiligen Prompts arbeitest. Schließlich sendest du diesen vorbereiteten String mit dem LLM-Tool an das Modell. Dieses Tool übernimmt die eigentliche Verbindung zu einem Large Language Model Endpoint. Du übergibst ihm den formatierten String aus deinem Prompt-Tool, konfigurierst die Modellparameter wie Temperature, und es gibt die generierte Zusammenfassung zurück. Das LLM-Tool übernimmt die Schwerstarbeit, formatiert den API-Payload und interagiert mit dem Provider. Diese drei decken zwar die meisten Core Use Cases ab, aber sie sind nicht deine einzigen Optionen. Prompt Flow unterstützt Partner-Tools von Drittanbietern. Ein gängiges Beispiel ist das Vector DB Lookup Tool, das Vektor-Datenbanken basierend auf Embeddings nach ähnlichem Text durchsucht. Du kannst auch Custom Packages installieren oder deine eigenen Tools für hochspezifische Integrationen bauen. Unabhängig von ihrer Herkunft funktionieren sie alle nach genau demselben Prinzip: Sie nehmen Inputs, führen eine bestimmte Funktion aus und geben einen Output zurück. Das Wichtigste, was du dir merken solltest, ist die strikte Separation of Concerns. Schreibe keinen Python-Code, um Prompts zu formatieren, und nutze das LLM-Tool nicht, um Strings zu verketten. Das richtige Built-in-Tool für seinen genauen Zweck zu nutzen, hält deine Graphen sauber und debuggable. Danke, dass du dabei warst. Ich hoffe, du hast etwas Neues gelernt.

Hallo, hier ist Alex von DEV STORIES DOT EU. Prompt Flow: Der komplette Guide, Folge 4 von 14. Nichts ruiniert ein Production Deployment schneller als ein API Key, der aus Versehen in die Version Control committet wurde. Selbst wenn du dieses Desaster vermeidest, führt das Jonglieren von Credentials zwischen lokaler Entwicklung und Cloud Environments oft zu einem Chaos in den Config-Files und zu Sicherheitsrisiken. Das Managen von Secrets mit Connections löst dieses Problem, indem es deine sensiblen Daten komplett von deiner Flow-Logik isoliert. Eine Connection in Prompt Flow ist eine dedizierte Ressource, die die Endpoints und Credentials speichert, die für die Interaktion mit externen Services nötig sind. Wenn dein Flow ein externes Language Model aufrufen, das Web über einen externen Service durchsuchen oder eine Remote-Datenbank abfragen muss, braucht er eine Authorization. Anstatt API Keys direkt in deine Python-Skripte oder Config-Files zu schreiben, erstellst du eine Connection. Dein Flow referenziert diese Connection dann einfach über ihren Namen. Durch die Nutzung von Connections entkoppelst du deine Secret-Daten von deiner Execution-Logik. Dein Code weiß nur, dass er eine Connection mit dem Namen zum Beispiel main_language_model braucht. Den eigentlichen API Key kennt er gar nicht. Schauen wir uns an, wie das funktioniert, wenn du ein Projekt von deinem Laptop in die Cloud umziehst. Wenn du lokal entwickelst, werden deine Connections auf deiner lokalen Festplatte gespeichert. Um die Sicherheit zu gewährleisten, verschlüsselt Prompt Flow die Secret-Werte mit einem lokalen Encryption Key. Du kannst deinen Flow mit diesem lokalen Setup bauen und testen, ohne dass Plaintext Keys in deinem Working Directory offenliegen. Wenn du bereit bist, diesen Flow auf Azure AI zu deployen, ändert sich das Environment, aber dein Code nicht. In Azure AI werden Connections sicher durch den Azure Key Vault abgesichert. Die Secrets werden innerhalb der Key Vault-Infrastruktur gespeichert und gemanagt, geschützt durch strenge Access Policies. Das ist der entscheidende Punkt. Weil dein Flow die Connection nur über ihren Namen referenziert, erfordert der Wechsel vom lokalen Environment in die Cloud null Änderungen an deiner Flow-Logik. Du stellst einfach sicher, dass in deinem Azure Workspace eine Connection mit genau demselben Namen existiert. Wenn der Flow in der Cloud läuft, fragt er nach main_language_model. Das System fängt diesen Request nahtlos ab und liefert die Key Vault-gestützten Credentials anstelle der lokal verschlüsselten. Dein Code bleibt clean und environment-agnostic. Prompt Flow kategorisiert diese Connections in zwei Haupttypen. Der erste Typ sind Strongly Typed Connections. Das sind Built-in Templates für weit verbreitete Services wie Azure OpenAI. Sie bieten vordefinierte Felder für die Endpoint URL, den API Key und den API Type. Das System weiß genau, wie es mit diesen Feldern umgehen muss, was die Standard-Tool-Configuration unkompliziert macht. Der zweite Typ ist die Custom Connection. Wenn du eine interne Firmen-API oder einen Third-Party Service integrieren musst, für den es kein Built-in Template gibt, nutzt du eine Custom Connection. Diese fungiert als flexibles Dictionary, in dem du deine eigenen Key-Value Pairs definierst. Du kannst bestimmte Keys explizit als Secrets markieren. Sobald sie markiert sind, erhalten diese Custom Secrets exakt dieselbe lokale Encryption und denselben Key Vault-Schutz wie die Built-in Connections. Der entscheidende Mehrwert von Connections ist, dass sie als strikter Abstraction Layer für die Authentication fungieren. Das stellt sicher, dass dein Flow komplett portable bleibt und deine Secrets in jedem Execution Environment sicher sind. Das war's für dieses Mal. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Prompt Flow: Der vollständige Leitfaden, Folge 5 von 14. Hör auf, deine Language-Model-Prompts in riesigen Python-Strings zu verstecken. Wenn du Prompts fest in deine Application Logic hardcodest, wird das Tracken von Änderungen, das Ausführen von Standalone-Tests und die Zusammenarbeit mit Prompt Engineers zum absoluten Albtraum. Die Lösung ist die Prompty Specification. Ein Prompty ist ein Standardformat für das Verwalten von Prompts. Es holt deinen Prompt aus dem Code und verschiebt ihn in eine einzelne, versionskontrollierbare Markdown-Datei mit der Dateiendung dot prompty. Die Datei ist in zwei klare Abschnitte unterteilt. Oben hast du das YAML Front Matter. Unten hast du ein Jinja-formatiertes Prompt-Template. Drei Bindestriche trennen die beiden. Der YAML-Block dient als Steuerzentrale. Hier kannst du grundlegende Metadaten wie Name, Description und Author definieren. Noch wichtiger ist, dass er die Model Configuration enthält. Du legst den API-Typ fest, zum Beispiel Chat oder Completion. Du definierst die Konfigurationsdetails, zum Beispiel indem du auf ein Azure OpenAI Deployment von GPT-3.5 verweist. Hier legst du auch die Model Parameters fest. Wenn ein bestimmter Prompt eine Temperature von null Komma sieben und ein Max Token Limit von eintausend erfordert, deklarierst du das im YAML. Das bindet die Execution Settings direkt an den Prompt-Text und stellt sicher, dass sich der Prompt immer konsistent verhält, egal wo er verwendet wird. Der YAML-Abschnitt definiert außerdem Inputs und Sample Data. Wenn dein Prompt eine dynamische Variable erwartet, listest du sie hier auf und gibst Sample Values an. Das macht die Datei komplett in sich geschlossen. Jeder, der sie öffnet, weiß genau, welche Daten erwartet werden, ohne deinen Application Code reverse-engineeren zu müssen. Unter dem YAML und den drei Bindestrichen liegt das eigentliche Prompt-Template. Dieser Abschnitt nutzt die Jinja2-Syntax, um die Inputs, die du oben definiert hast, dynamisch einzufügen. Da moderne Language Models Chat-Interfaces nutzen, unterstützt das Template Role Designations. Du definierst Rollen in einem einfachen Textformat und trennst System Instructions von User Inputs. Stell dir ein minimales Chat-Szenario vor, in dem du einen Prompt möchtest, der einen User mit seinem Vornamen begrüßt. Ganz oben in deiner dot prompty-Datei schreibst du das YAML Front Matter. Du definierst deine Model Section, setzt den API-Typ auf Chat und verweist die Configuration auf ein GPT-3.5 Deployment. Als Nächstes fügst du eine Inputs Section hinzu, in der du eine Variable namens first name deklarierst. Außerdem fügst du einen Sample-Block hinzu, in dem first name auf Jane gesetzt wird. Du tippst drei Bindestriche, um das YAML Front Matter zu beenden. Jetzt baust du das Template. Du tippst das Wort system, gefolgt von einem Doppelpunkt, und gibst dem Model dann seine Baseline Instructions, zum Beispiel, dass es ein hilfreicher Assistent sein soll. Darunter tippst du das Wort user, gefolgt von einem Doppelpunkt. Schließlich schreibst du die Begrüßung und packst die first name-Variable in doppelte geschweifte Klammern, damit die Jinja-Engine weiß, wo der Text eingefügt werden soll. Du hast jetzt ein komplettes, wiederverwendbares Asset. Prompts als eigenständige Dateien statt als lose Strings in deinem Code zu behandeln, ist der erste Schritt in Richtung rigoroses Prompt Engineering. Denn es erzwingt einen klaren Contract zwischen der Application, die die Daten bereitstellt, und dem Language Model, das die Response generiert. Danke, dass du dir ein paar Minuten Zeit für mich genommen hast. Bis zum nächsten Mal, mach's gut.

Hallo, hier ist Alex von DEV STORIES DOT EU. Prompt Flow: The Complete Guide, Folge 6 von 14. Du baust ein sorgfältig optimiertes Prompt Template für Production, aber wenn du es mit einem günstigeren Modell testen oder die Temperature für einen speziellen Edge Case anpassen willst, ertappst du dich dabei, wie du die Source-Datei manuell bearbeitest. Ein statisches Template erzeugt Friction, wenn sich deine Environment oder Logik on the fly ändern muss. Genau diese Friction soll die Dynamic Prompty Execution beseitigen. Ein Prompty Asset definiert typischerweise Model Settings wie den Deployment Name, die API Connection und Parameter in seinem Header-Block. Das Hardcoden dieser Werte schränkt jedoch ein, wie du die Datei über verschiedene Environments hinweg nutzen kannst. Die dynamische Execution erlaubt es dir, die Prompty-Datei als flexible Base Layer zu behandeln und ihre Konfigurationen direkt in Python oder über die Command Line zur Runtime zu überschreiben. Um eine Prompty-Datei in Python auszuführen, nutzt du die load prompty Funktion aus der Prompt Flow Core Library. Du übergibst dieser Funktion den File Path, und sie gibt ein Callable Object in Memory zurück. Um es auszuführen, rufst du einfach dieses Objekt auf und übergibst deine Prompt-Variablen als Standard Keyword Arguments. Die Library übernimmt die Compilation und den API Call und gibt den finalen Text-Output zurück. Genau hier zeigt sich der wahre Wert der dynamischen Execution. Du kannst die Execution abfangen, um die Model Settings zu überschreiben, ohne die zugrundeliegende Datei anzufassen. Angenommen, du hast ein Prompty für ein Standard Azure OpenAI Deployment konfiguriert, musst es aber für einen bestimmten Batch Job auf einen anderen Azure Endpoint verweisen und die Temperature erhöhen, um vielfältigere Responses zu erhalten. Anstatt die Datei zu duplizieren, definierst du in deinem Python-Code ein Dictionary mit deinen neuen Settings. Du fügst diesem Dictionary deinen alternativen Endpoint und deinen neuen Temperature-Wert hinzu. Wenn du dann dein geladenes Prompty-Objekt aufrufst, übergibst du dieses Dictionary an das Model Keyword Argument, zusammen mit deinen Standard Prompt Inputs. Die Prompt Flow Runtime kombiniert dein Dictionary mit der Base File Configuration. Deine dynamischen Overrides haben Vorrang, der Prompt wird mit den neuen Settings ausgeführt, und die Originaldatei bleibt komplett unverändert. Das erlaubt es dir, API Keys auszutauschen, die Max Tokens zu ändern oder das Model Target programmatisch basierend auf deinem Application State umzuleiten. Manchmal willst du nicht extra ein Python-Skript schreiben, nur um zu sehen, ob ein Prompt ein gutes Ergebnis liefert. Für eine schnelle Validation kannst du eine Prompty-Datei direkt aus deinem Terminal testen. Du nutzt den pf flow test Command und gibst den Pfad zu deiner Datei über das source Flag an. Du kannst das inputs Flag anhängen, um deine Variablen direkt als Key-Value Pairs in den Command zu übergeben. Das Command Line Interface führt das Prompty aus und gibt die Model Response direkt im Standard Output aus. Das gibt dir einen sofortigen Feedback Loop während der Development-Phase, ohne Wrapper Code schreiben zu müssen. Der wahre Wert eines Prompty Assets liegt nicht darin, Konfigurationen festzuschreiben, sondern in der Isolation des Prompt-Textes von der Execution Environment. Indem du Model Overrides dynamisch zur Runtime einfügst, kann eine einzige Datei nahtlos deine lokale Testing Sandbox, deine automatisierten Pipelines und deine Production Endpoints bedienen. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Prompt Flow: Der vollständige Leitfaden, Folge 7 von 14. Du denkst vielleicht, dass die Verwendung eines spezialisierten Frameworks für Large Language Models bedeutet, ein komplexes visuelles Interface zu erlernen oder riesige Konfigurationsdateien zu pflegen. Aber wenn du bereits weißt, wie man ein Python-Skript schreibt, weißt du schon genug, um eine vollständig trackbare Application zu bauen. Function-Based Flex Flows lösen diesen Konflikt komplett auf. In der Standardentwicklung mit Prompt Flow baust du einen Directed Acyclic Graph. Diese Struktur ist extrem effektiv für strikte, Multi-Step Pipelines, aber manchmal wollen Entwickler reinen Python-Code schreiben, ohne sich an ein visuelles Node-System anpassen zu müssen. Flex Flows ermöglichen dir genau das. Du kapselst deine LLM Application Logic in Standard-Python-Funktionen, und die Plattform übernimmt das Tracking und die Orchestration im Hintergrund. Schauen wir uns den Function-Based Ansatz an. Du fängst damit an, eine normale Python-Funktion zu schreiben. Gib ihr einen aussagekräftigen Namen, wie chat, und definiere ihre Inputs, zum Beispiel, dass sie eine Frage als String-Parameter annimmt. Innerhalb dieser Funktion schreibst du deine Logic genau so, wie du es normalerweise tun würdest. Du lädst vielleicht eine Prompty-Datei, um deine System Message zu bekommen, initialisierst deinen Language Model Client, übergibst die Frage an das Model und gibst dann die Text Response als String zurück. In dieser Phase hast du einfach ein Standard-Python-Skript. Es läuft lokal, es ist leicht zu testen und es erfordert kein spezielles Framework-Wissen. Um dieses reine Python-Skript in eine trackbare Prompt Flow Component zu verwandeln, importierst du den Trace Decorator aus dem Promptflow Tracing Package. Du platzierst diesen Decorator direkt über deiner Chat-Funktion. Wenn du deinen Code ausführst, sagt dieser Decorator dem System, dass es die Execution still im Hintergrund überwachen soll. Er zeichnet automatisch die Inputs auf, die an die Funktion übergeben wurden, den zurückgegebenen Text Output, die genaue Execution Time und alle internen Errors. Wenn du den Trace Decorator auf andere Helper-Funktionen innerhalb deines Skripts anwendest, baut das System einen kompletten Call Tree. Du bekommst die volle Observability eines Visual Flows, einschließlich der Möglichkeit, den Execution Trace im lokalen User Interface anzusehen, ohne die Struktur deiner Logic ändern zu müssen. Jetzt braucht das Tooling einen Weg, um zu wissen, dass diese spezifische Funktion der Entry Point deiner Application ist. Dafür erstellst du eine einzige, sehr kurze Konfigurationsdatei namens flow.flex.yaml im selben Verzeichnis wie dein Code. Diese Datei definiert keinen komplexen Routing Graph. Sie braucht nur eine einzige, kritische Information, und das ist das Entry Mapping. Du schreibst das Wort entry, gefolgt vom Namen deines Python-Moduls, einem Doppelpunkt und dem Namen deiner Funktion. Wenn deine Datei app.py heißt und deine Funktion chat, ist dein Entry Value einfach app Doppelpunkt chat. Wenn du diesen Flow mit dem Prompt Flow Command Line Tool oder der VS Code Extension testest oder ausführst, liest das System diese YAML-Datei. Es sucht die Chat-Funktion in deinem App-Modul, injiziert die bereitgestellten Inputs, führt deinen reinen Python-Code aus und sammelt die Traces, die vom Decorator generiert wurden. Die wahre Stärke von Function-Based Flex Flows ist, dass sie die Reibung zwischen dem Prototyping eines Skripts und dem Deployen einer Production Application beseitigen. Deine reine Python-Logic bleibt komplett unter deiner Kontrolle, während ein einziger Decorator und eine zweizeilige Konfigurationsdatei Enterprise-Grade Observability freischalten. Das war's für diese Folge. Danke fürs Zuhören, und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Prompt Flow: Der vollständige Leitfaden, Folge 8 von 14. Du deployst eine neue Language Model App, aber jedes Mal, wenn ein User eine Nachricht sendet, dauert es wertvolle Sekunden, allein die Datenbankverbindung herzustellen und die Client Credentials zu laden. Wenn deine App eine persistente Verbindung aufrechterhalten oder sich die Conversation History merken muss, schlägt ein Standalone-Skript fehl, weil es bei jedem Run komplett von vorne anfängt. Die Antwort auf dieses Problem sind Flex Flows: Class-Based Development. Wenn du skalierbare Apps baust, wird State Management zu einem zentralen Thema. Wenn dein Flow auf eine externe Ressource wie einen Azure OpenAI Client angewiesen ist, erfordert das Initialisieren dieses Clients das Auslesen von Secrets, das Überprüfen von Endpoints und das Zuweisen von Memory. Wenn du diese Logik in eine einfache Execution Sequence packst, zahlst du diese hohen Startup-Kosten bei jedem einzelnen Request, der reinkommt. Wenn du eine Python-Klasse als Entry Point für deinen Flex Flow nutzt, kannst du deine Initialisierungslogik grundlegend von deiner Execution-Logik trennen. Ein Class-Based Flow nutzt zwei Standard-Python-Methoden, um diesen Lifecycle zu managen. Die erste ist der Konstruktor, oder die init-Methode. Das ist deine Setup-Phase. Prompt Flow führt diese Methode genau einmal aus, wenn der Flow zum ersten Mal in den Memory geladen wird. Hier passiert das Heavy Lifting. Die zweite Methode ist die call-Methode. Das ist deine Execution-Phase, und sie läuft jedes Mal, wenn der Flow durch einen User Request getriggert wird. Stell dir eine Chat Flow Klasse vor. Du definierst deine init-Methode so, dass sie ein Azure OpenAI Connection-Objekt und einen System Prompt String akzeptiert. Innerhalb der init-Methode erstellst du deinen Azure OpenAI Client und speicherst ihn als Property direkt auf der Klasseninstanz. Der Client ist jetzt bereit und wartet. Als Nächstes definierst du deine call-Methode. Diese Methode akzeptiert eine neue User-Frage und eine Liste vergangener Nachrichten, die die Chat History repräsentieren. Weil der Client schon vollständig initialisiert ist, formatiert die call-Methode sofort den Prompt, sendet die Chat History an das Language Model und gibt die Response zurück. Die Execution ist schnell, weil das teure Client-Setup komplett umgangen wurde. Damit das funktioniert, muss Prompt Flow wissen, wie deine Klasse instanziiert wird. Du konfigurierst das, indem du ein YAML-File für deinen Flow erstellst. Der Entry Point in diesem Config-File nutzt ein bestimmtes Format: Er nennt das Python-Modul, gefolgt von einem Doppelpunkt und dem Namen deiner Klasse. Das ist der entscheidende Teil. Deine YAML-Config verweist nicht nur auf die Klasse, sie definiert auch die Parameter, die deine init-Methode braucht. Wenn dein Klassenkonstruktor eine Azure Connection und einen Model Name erfordert, deklarierst du diese Inputs im YAML-File unter einer eigenen init-Section. Wenn die Prompt Flow Engine startet, liest sie das YAML, injiziert diese konfigurierten Parameter in deinen Klassenkonstruktor und hält das instanziierte Objekt dann im Memory am Leben, um eingehende Calls zu verarbeiten. Einen Class-Based Flow lokal zu testen, ist unglaublich unkompliziert, weil es auf Standard-Python-Verhalten basiert. Du brauchst kein komplexes Test Harness. Du schreibst einfach ein Standard-Python-Skript, importierst deine Klasse, erstellst eine Instanz, indem du Mock Connections oder lokale Credentials an den Konstruktor übergibst, und rufst das Objekt dann direkt auf, indem du ihm eine Test Message übergibst. Du kannst die Setup-Logik und die Execution-Logik unabhängig voneinander debuggen. Die Kernaussage ist, dass Class-Based Flows dir die architektonische Struktur geben, um das Heavy Lifting der Initialisierung von der repetitiven Arbeit der Execution zu trennen. So bleibt dein State persistent und deine Responses schnell. Wenn du diese Episoden hilfreich findest und die Show unterstützen willst, 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. Prompt Flow: Der vollständige Leitfaden, Folge 9 von 14. Manchmal reicht es nicht aus, auf eine Wand aus Code zu starren, um eine komplexe Anwendung zu verstehen. Wenn Prompts, Skripte und API Calls auf dutzende Arten interagieren, musst du die Daten zwischen ihnen fließen sehen, um die Bottlenecks zu erkennen. DAG Flows sind die Antwort für Teams, die sich explizite architektonische Klarheit wünschen. DAG steht für Directed Acyclic Graph. In Prompt Flow ist ein DAG Flow eine Methode, um AI-Anwendungen zu bauen, indem verschiedene Tools als Nodes miteinander verknüpft werden. Anstatt ein einziges großes Skript zu schreiben, definierst du deine Anwendungsstruktur in einer Datei namens flow dot dag dot yaml. Diese Datei dient als Master-Blueprint. Sie deklariert die Start-Inputs, die einzelnen Schritte und die finalen Outputs deiner Anwendung. Jeder Schritt in einem DAG Flow wird als Node bezeichnet. Ein Node repräsentiert ein spezifisches Tool, das eine einzelne Task ausführt. Du könntest einen Node haben, der ein Python Snippet ausführt, einen weiteren Node, der einen Prompt formatiert, und einen dritten Node, der ein Large Language Model aufruft. Die YAML-Datei beschreibt, wie diese Nodes durch Input- und Output-Dependencies miteinander in Beziehung stehen. Dieses Dependency Mapping ist es, was den Flow zum Laufen bringt. Du sagst dem System nicht manuell, in welcher Reihenfolge die Schritte ausgeführt werden sollen. Stattdessen gibst du an, dass Node B den Output von Node A benötigt. Weil Node B nicht starten kann, bevor Node A fertig ist, bildet sich ganz natürlich eine Ausführungsreihenfolge. Wenn du einen Node C hinzufügst, der nur vom anfänglichen User Input abhängt, erkennt Prompt Flow, dass er nicht auf Node A oder B warten muss. Es wird Node C automatisch parallel ausführen. Die Engine liest die YAML-Datei, löst den Graphen auf und übernimmt die Orchestrierung. Diese YAML-Datei von Hand zu schreiben und zu pflegen, kann schwierig werden, wenn deine Anwendung wächst. Deshalb nutzen die meisten Developer die Prompt Flow VS Code Extension. Diese Extension liest deine flow dot dag dot yaml Datei und rendert ein visuelles Drag-and-Drop User Interface. Du kannst deine Anwendung buchstäblich als eine Karte aus verbundenen Blöcken betrachten. Stell dir ein konkretes Szenario vor. Du baust eine Anwendung, die Finanzberichte liest und kurze Executive Summaries schreibt. Im visuellen Editor erstellst du einen Python Tool Node und nennst ihn Extract Text. Daneben fügst du einen LLM Tool Node namens Summarize hinzu. Anstatt Code zu schreiben, um den State zwischen diesen beiden Operationen zu managen, nutzt du das Interface. Du klickst auf den Output Port des Extract Text Nodes und ziehst eine Linie zum Input Port des Summarize Nodes. Damit hast du den Datenpfad visuell verkabelt. Die Extension aktualisiert sofort die zugrundeliegende YAML-Datei, um diese Verbindung zu speichern. Du bekommst die Geschwindigkeit und Klarheit eines visuellen Low-Code Builders, aber generierst trotzdem eine Plain Text Konfigurationsdatei, die du in der Version Control tracken kannst. Dieser visuelle Ansatz erzwingt architektonische Disziplin. Der Graph ist azyklisch, was bedeutet, dass Daten nur vorwärts fließen können. Es gibt keine Endlosschleifen. Daten kommen rein, durchlaufen deine Sequenz von Tools und gehen wieder raus. Dieser strikte, direktionale Flow macht das Debugging unkompliziert. Wenn eine finale Summary falsch aussieht, kannst du den visuellen Graphen öffnen, auf die Verbindung zwischen den Extract Text- und Summarize-Nodes klicken und den exakten String inspizieren, der über diese Leitung übergeben wurde. Du weißt genau, woher die Daten kamen und wohin sie gegangen sind. Der wahre Vorteil eines DAG Flows ist, dass dein Systemarchitektur-Diagramm und deine ausführbare Anwendung exakt dasselbe sind. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Prompt Flow: The Complete Guide, Folge 10 von 14. Wenn ein Sprachmodell eine halluzinierte Garbage-Antwort liefert, woher weißt du dann, ob das Model selbst versagt hat oder ob deine Prompt-Formatting-Logik einen Bug hatte? Du kannst zwar überall in deiner Application Print-Statements verteilen, aber das wird unmöglich zu maintainen, wenn deine App wächst. Das Tracing von LLM-Interaktionen löst dieses Problem, indem es den genauen Context jeder Execution erfasst. Tracing verwandelt eine Black-Box-LLM-Application in eine transparente, debugbare Sequenz von Events. Es zeichnet genau auf, welche Daten in eine Funktion reingehen, was rauskommt und wie lange die Execution dauert. In diesem Ökosystem machst du das mit dem promptflow-tracing Package. Die Daten, die es generiert, basieren auf der OpenTelemetry-Spezifikation. Das heißt, deine Execution Records folgen einem Industriestandard für Observability. Um die Baseline-Interaktionen mit einem Model zu erfassen, nutzt du eine Funktion namens start trace. Wenn du diese Funktion ganz am Anfang deines Python-Scripts aufrufst, instrumentiert Prompt Flow automatisch unterstützte Model Clients. Wenn du zum Beispiel das Standard-OpenAI-Python-Package verwendest, musst du deine API-Calls überhaupt nicht anpassen. Der Tracer fängt die Interaktion unauffällig ab und loggt die System Message, den User Prompt, die spezifischen Model-Parameter und den finalen Response String. Den API-Call zu erfassen, ist aber nur die halbe Miete. Die Logik, die zu diesem Call führt, ist meistens der Ort, wo sich Bugs verstecken. Um deine eigene Application-Logik zu tracen, wendest du den Trace-Decorator auf deine Custom Functions an. Stell dir eine Funktion namens math to code vor. Diese Funktion nimmt einen User Input, der ein Matheproblem beschreibt, holt den nötigen Context, baut einen Prompt zusammen und fordert schließlich Python-Code von GPT-4 an. Indem du den Trace-Decorator direkt über der math to code Function Definition platzierst, sagst du Prompt Flow, dass es jede Execution von diesem spezifischen Logikblock aufzeichnen soll. Es loggt den User Input String, den finalen Returned Code und die Latency der gesamten Operation. Weil du außerdem start trace ganz oben in deinem File ausgeführt hast, versteht das System die Beziehung zwischen deinem Code und dem Model Call. Es baut einen hierarchischen Record auf. Deine math to code Funktion wird zum Parent Span, und der interne OpenAI-Call wird zu einem Child Span, der darin verschachtelt ist. Du schaust dir diese Hierarchie über die lokale Trace UI an. Wenn du ein getracetes Script ausführst, startet Prompt Flow einen lokalen Server, den du in deinem Webbrowser öffnen kannst. Dieses Interface gibt dir eine visuelle Timeline deines Application Flows. Du kannst den Parent math to code Span auswählen, um die Argumente zu überprüfen, die er empfangen hat. Danach kannst du den Child OpenAI Span auswählen, um den exakten Raw Prompt String zu inspizieren, der erfolgreich über das Netzwerk an das Model gesendet wurde. Wenn deine Context-Assembly-Logik eine Variable vergessen hat, siehst du die leere Stelle im Raw Prompt sofort. Die wahre Power von Tracing ist nicht nur das Sammeln von Execution Logs, sondern der definitive Beweis, was genau an der Grenze zwischen deinem Application Code und dem externen Model passiert ist. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Prompt Flow: The Complete Guide, Folge 11 von 14. Du hast gerade drei Monate damit verbracht, eine komplexe Application mit LangChain zu bauen. Die Logik funktioniert größtenteils, aber wenn ein Agent gelegentlich in einem Bad Loop landet oder den Context verliert, ist es ein Albtraum, genau herauszufinden, wo er entgleist ist. Und das ganze Ding neu zu schreiben, nur um bessere Logs zu bekommen, kommt überhaupt nicht in Frage. Advanced Tracing für LangChain und AutoGen ist die direkte Lösung dafür. Wenn du mit Orchestration Frameworks baust, gewinnst du durch Abstraktion an Geschwindigkeit. Das Framework verbirgt die unschönen Details von Prompt Sequencing, Tool Execution und Parsing. Aber Abstraktion erzeugt zwangsläufig eine Black Box. Wenn dein Agent eine verwirrende Antwort liefert, musst du seine interne Chain of Thought sehen können. Du musst den exakten Sub-Prompt kennen, den er generiert hat, die Raw API Response, die er empfangen hat, und welcher spezifische Tool Call fehlgeschlagen ist. Prompt Flow beinhaltet eine Standalone-Tracing-Funktion, die genau dafür entwickelt wurde. Sie erfordert nicht, dass du Prompt Flow für deine Logik oder Execution verwendest. Du behältst deinen bestehenden LangChain- oder AutoGen-Code genau so, wie er ist. Du hängst einfach nur das Tracking-System von Prompt Flow an deine externe Application an. Denk an dein bestehendes Python-Script, das einen LangChain-Agenten ausführt. Um volle Visibility zu bekommen, fasst du deine Chain Definitions gar nicht erst an. Du gehst einfach ganz nach oben in dein Main Execution File. Du importierst die Trace-Setup-Funktion aus dem Prompt Flow Modul und rufst sie einmal auf, bevor dein Agent anfängt zu arbeiten. Dieser eine Befehl ist die komplette Integration. Wenn du diese Funktion aufrufst, instrumentiert sie dein Environment. Da das Prompt Flow Tracing auf OpenTelemetry-Standards basiert, weiß es, wie es auf die spezifischen Events lauschen muss, die von diesen beliebten Frameworks getriggert werden. Während deine LangChain-Application läuft, fängt die Instrumentation automatisch die zugrunde liegenden API Calls ab. Sie erfasst die Inputs, die Execution Duration, die Outputs und die Token Usage für jeden Schritt. Das gilt nahtlos auch für AutoGen. Multi-Agent-Setups in AutoGen sind bekanntermaßen schwer zu debuggen, weil mehrere Agents autonom Messages hin und her schicken. Zu tracken, wer welchen Context an wen übergeben hat, bedeutet normalerweise, sich durch massive Wände von Terminal-Text zu wühlen. Indem du den Trace ganz oben in deinem AutoGen-Script initialisierst, wird jeder einzelne Message Exchange automatisch erfasst und strukturiert. Sobald dein Script fertig ausgeführt ist, öffnest du die lokale Prompt Flow Trace UI. Anstatt durch Console Print Statements zu scrollen, bekommst du eine visuelle Timeline. Du siehst einen klaren Execution Tree. Du klickst auf den Top-Level Agent Run, klappst die Node auf und siehst die Sequenz der nested LLM Calls und Tool Executions. Wenn ein Agent bei Schritt vier halluziniert hat, kannst du direkt auf Schritt vier klicken, um den exakten, unformatierten Text zu lesen, der an das Model gesendet wurde. Du bekommst komplette Visibility in ein undurchsichtiges Framework, ohne eine einzige Zeile deiner eigentlichen Business Logic migrieren zu müssen. Der wahre Vorteil hier ist die architektonische Freiheit: Du kannst deine Application mit dem Framework orchestrieren, das am besten zu deinem Team passt, und behältst dein Debugging und deine Observability zentral in einem sauberen, visuellen Interface. Wie immer, danke fürs Zuhören. Wir sehen uns in der nächsten Folge.

Hallo, hier ist Alex von DEV STORIES DOT EU. Prompt Flow: Der vollständige Leitfaden, Folge 12 von 14. Dein Prompt hat bei deiner Testfrage einwandfrei funktioniert, aber was passiert, wenn du ihn gegen zehntausend echte User Queries laufen lässt? Meistens schlägt er fehl. Einen Prompt manuell mit zwei Beispielen zu testen, ist einfach, aber zu beweisen, dass er über Hunderte von Edge Cases hinweg funktioniert, erfordert etwas Robusteres. Hier kommt Scaling Up: Batch Runs mit Daten ins Spiel. Ein Batch Run nimmt deinen einzelnen Flow und führt ihn auf einem großen Dataset aus. Das bringt dich vom reinen Bauen der Logik dazu, sie at scale zu verifizieren. Anstatt Inputs in ein User Interface einzutippen, triggerst du diesen Prozess über das Command Line Interface. Der Kernbefehl lautet pf run create. Wenn du das ausführst, weist du Prompt Flow an, eine neue Run-Instanz hochzufahren, ein bestimmtes Flow-Directory zu lesen und ihm eine Datei mit all deinen Test-Records zu übergeben. Die Engine verarbeitet diese Records, indem sie deinen gesamten Flow Graph für jede einzelne Zeile in deinem Dataset unabhängig ausführt. Das erforderliche Datenformat für dieses Input-File ist JSONL. JSONL steht für JSON Lines. Wenn du Standard-JSON gewohnt bist, erwartest du vielleicht ein einzelnes großes Array, das all deine Objekte umschließt. JSONL lässt das Array weg. Jede einzelne Zeile im Text-File ist ein eigenes, gültiges, eigenständiges JSON-Objekt, das genau einen Test Case repräsentiert. Dieses Format wird bei Machine Learning und Data Pipelines stark bevorzugt, weil es lightweight ist und sich leicht streamen lässt. Die Engine kann es Zeile für Zeile lesen, ohne ein riesiges File auf einmal in den Memory laden zu müssen. Stell dir einen Web-Classification-Flow vor. Dein Flow ist so designt, dass er eine Webadresse nimmt, den Content scrapt und ein Language Model nutzt, um ihn zu kategorisieren. Der Flow Graph erwartet einen spezifischen Input String namens url. Du willst diese Logik gegen hundert verschiedene Websites testen, um zu sehen, wie sie mit Edge Cases umgeht. Du baust dein JSONL-File. Jede Zeile enthält ein JSON-Objekt mit einem Key, vielleicht namens web link, der die Target-Adresse enthält. Um den Batch Run zu starten, tippst du pf run create. Du gibst dein Flow-Directory mit dem flow Flag an und verweist mit dem data Flag auf dein JSONL-File. Aber da gibt es sofort einen strukturellen Mismatch. Deine Flow-Logik erfordert strikt einen Input namens url, während dein Data-File ein Feld namens web link bereitstellt. Wenn du den Command jetzt ausführst, wird er fehlschlagen. Die Engine rät nicht, welche Data Fields zu welchen Flow Inputs gehören. Du überbrückst diese Lücke mit dem Column Mapping Flag. Dieses Flag sagt der Execution Engine genau, wie sie die Keys in deinem JSONL-File mit den spezifischen Input Nodes deines Flows verbinden soll. In deinen Command Line Arguments schreibst du den Flow Input Namen, ein Gleichheitszeichen und dann eine Referenz auf die Data Column. Prompt Flow nutzt eine spezifische Binding-Syntax für diese Referenzen. Du schreibst ein Dollarzeichen, gefolgt vom Wort data, einem Punkt und dann dem Column-Namen aus deinem File. Für das Web-Classification-Szenario mappst du es, indem du schreibst: url equals Dollarzeichen data dot web link. Diese explizite Anweisung bindet das Data Field an die Flow-Anforderung. Die Engine wird nun den web link String aus Zeile eins deines JSONL-Files extrahieren und ihn in den url Input deines Flows injecten. Dann wiederholt sie genau diesen Prozess für Zeile zwei, Zeile drei und so weiter, bis das gesamte File verarbeitet ist. Du kannst auf diese Weise mehrere Inputs mappen. Wenn dein Flow eine url und eine user id erwartet, fügst du einfach eine weitere Mapping-Anweisung zum selben Command hinzu. Deine Testdaten durch explizites Column Mapping von deinen Flow Inputs zu entkoppeln bedeutet, dass du deinen Core Code nie ändern musst, nur um ein neues Dataset auszuführen. 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. Prompt Flow: Der vollständige Leitfaden, Folge 13 von 14. Du kannst keinen Standard-Unit-Test schreiben, der per Assert prüft, ob die Response eines Large Language Models einem exakten String entspricht. Wenn sich der Output jedes Mal ändert, wie beweist du dann mathematisch, dass deine Application tatsächlich funktioniert, bevor du sie deployest? Die Antwort lautet: das Evaluation Paradigm. Im traditionellen Software Engineering ist Unit Testing deterministisch. Du übergibst einer Funktion einen bestimmten Input und erwartest einen exakten Output. Large Language Models sind stochastisch. Sie sind von Natur aus unvorhersehbar. Wenn du ein Model bittest, eine Webpage zu klassifizieren, gibt es vielleicht das Wort Sport aus, oder es sagt, die Kategorie ist Sport, oder es liefert dir einfach ein passendes Emoji. Eine Standard-Test-Assertion wird bei zwei von drei Fällen fehlschlagen, obwohl das Model die Antwort im Grunde richtig hatte. Um die Release Readiness nachzuweisen, musst du über Unit-Tests hinausgehen und auf statistische Evaluation setzen. In Prompt Flow wird das durch einen Evaluation Flow gelöst. Ein Evaluation Flow ist einfach ein normaler Flow, aber anstatt Text für einen End User zu generieren, besteht sein einziger Job darin, den Output eines anderen Flows zu bewerten. Er nimmt die Predictions, die deine Main Application generiert hat, vergleicht sie mit einem bekannten Set an korrekten Antworten und gibt berechnete Metriken aus. Machen wir das mal konkret. Sagen wir, du hast gerade einen Batch Run von einem Web Classification Flow abgeschlossen. Er hat hundert Website-Adressen verarbeitet und für jede eine predicted Category ausgegeben. Jetzt musst du genau wissen, wie akkurat diese Predictions sind. Du nimmst die Outputs von diesem Base Run und fütterst sie in einen neuen, dedizierten Evaluation Flow, der dafür gemacht ist, die Classification Accuracy zu berechnen. Du triggerst das über die Command Line mit dem run create Command. Du gibst deinen Evaluation Flow an, aber anstatt ihm einfach ein statisches File mit neuen Inputs zu geben, übergibst du ihm eine Referenz auf deinen vorherigen Batch Run. Der Evaluation Flow braucht zwei Informationen, um seinen Job zu machen. Er braucht die Model Prediction und er braucht die Ground Truth, also die historisch korrekte Antwort. Du stellst ein Data Mapping bereit, das diese Punkte verbindet. Du sagst dem System, dass es den Prediction Input des Evaluation Flows auf den Category Output deines Base Runs mappen soll. Dann mappst du den Ground Truth Input auf die tatsächliche True Label Column in deinem ursprünglichen Test Dataset. Das ist der Teil, auf den es ankommt. Der Evaluation Flow wird Row by Row ausgeführt und geht dabei durch die gesamte History des vorherigen Runs. Für jede Row schaut er sich an, was dein Main Flow predicted hat, und vergleicht es mit der Ground Truth. Er vergibt einen Score für diese spezifische Interaktion. In unserem Classification-Szenario könnte das eine simple Eins für einen Match und eine Null für einen Miss sein. Andere Evaluation Flows nutzen vielleicht ein Language Model, um die Qualität einer Summary auf einer Skala von eins bis fünf zu bewerten. Sobald der Flow die Bewertung jeder einzelnen Row abgeschlossen hat, aggregiert er diese individuellen Scores zu einer finalen Overall Metric. Du bekommst nicht einfach ein riesiges Log aus Einsen und Nullen. Du bekommst eine definitive Top-Level-Zahl, wie eine Overall Accuracy von zweiundneunzig Prozent. Du kannst dir dann diese aggregierten Metriken ansehen, um zu entscheiden, ob die aktuelle Version deiner Application ready für Production ist. Du musst nicht mehr raten, ob ein Prompt Tweak dein System verbessert hat; du hast den statistischen Beweis, wie viel besser oder schlechter es über dein gesamtes Dataset hinweg performt. Danke fürs Einschalten. Bis zum nächsten Mal!

Hallo, hier ist Alex von DEV STORIES DOT EU. Prompt Flow: Der vollständige Leitfaden, Folge 14 von 14. Du hast deinen Language Model Flow gebaut, getraced und evaluiert – und er funktioniert perfekt. Aber aktuell liegt er einfach nur in deiner Development Environment, völlig isoliert von deinen eigentlichen Usern. Ihn aus deiner IDE zu holen und in einen stabilen, erreichbaren Service zu verwandeln, ist genau das, was wir uns heute anschauen, wenn wir Flows in Production bringen. Im Ruhezustand ist ein Prompt Flow einfach nur ein Ordner. Er enthält ein Configuration YAML File und deine Python Scripts oder Jinja Templates. Damit dieser Ordner in der echten Welt irgendetwas tut, brauchst du eine Execution Environment, die diese Dateien lädt und auf eingehende HTTP-Requests lauscht. Während der Entwicklung hast du wahrscheinlich den lokalen Built-in-Server genutzt. Du führst einen simplen Command aus, und er fährt einen lokalen Endpoint hoch, um Inputs und Outputs zu testen. Das ist völlig okay, um die Logik zu verifizieren, aber es ist nicht dafür gemacht, concurrent Production-Traffic zu handlen, Memory effizient zu managen oder einen System-Crash zu überleben. Um in Production zu gehen, brauchst du Containerization. Prompt Flow ist so gebaut, dass es sich direkt in Docker integriert. Anstatt deinen eigenen Webserver from scratch zu schreiben, nutzt du das Prompt Flow Tooling, um deinen Flow als Docker-Container zu exportieren. Wenn du den Export-Prozess ausführst, generiert das System ein Dockerfile. Diese Datei definiert ein Base Image, kopiert dein Flow-Directory hinein, installiert exakt die Python-Dependencies, die in deinem Requirements-File stehen, und setzt einen production-ready Webserver auf, um den Flow als REST API zu serven. Das ist der entscheidende Punkt. Sobald dein Flow in einem Docker-Container steckt, ist er kein spezielles Machine-Learning-Experiment mehr, sondern wird zu einem Standard-Software-Artifact. Du kannst ihn wie jeden anderen Microservice behandeln. Nehmen wir ein konkretes Szenario. Du hast einen validierten Customer-Support-Chat-Flow. Du baust das Docker-Image und pushst es in deine private Container Registry. Als Nächstes deployest du dieses Image auf einen Kubernetes-Cluster. Du schreibst eine Standard-Deployment-Config, die Kubernetes anweist, drei Replicas deines Chat-Flow-Containers hochzufahren, und du packst einen Load Balancer davor. Jetzt sendet deine Frontend Application Standard-HTTP-Requests an den Load Balancer, der den Traffic auf deine Container verteilt. Wenn dein Chat-Flow mit User-Requests überrannt wird, skaliert Kubernetes einfach weitere Instances deines Flows hoch. Wenn du keinen Kubernetes-Cluster managen willst, funktioniert genau dasselbe Docker-Image auch perfekt auf Managed Platform Services. Du kannst es direkt auf Azure App Service oder bei jedem anderen Cloud-Provider deployen, der Container hostet. Dem Flow ist es völlig egal, wo er läuft, solange er eine Container Runtime hat. Es gibt noch ein alternatives Deployment Pattern. Wenn du keinen Web Service baust, kannst du einen Flow auch als Executable Application verteilen. Das verpackt den Flow und seine Runtime-Dependencies in ein Standalone Executable File. Das ist super nützlich, wenn du die Logik direkt auf einer Client Machine oder einem Edge Device ausführen musst und dir so die Installation von Python oder das Aufsetzen eines Servers komplett sparst. Einen Prompt Flow in Production zu bringen, erfordert kein proprietäres Hosting oder eine spezielle Machine-Learning-Infrastructure. Durch den Export zu Docker integrieren sich deine Language Model Flows nahtlos in exakt dieselben Continuous Delivery Pipelines und Container Orchestrators, die du bereits für deine traditionellen Backend Services nutzt. Wenn du noch tiefer einsteigen willst, empfehle ich dir, die offizielle Prompt Flow Documentation zu lesen, selbst mal einen Container zu deployen oder auf devstories dot eu vorbeizuschauen, um Themen vorzuschlagen, die du in zukünftigen Serien sehen möchtest. Ich möchte mir kurz die Zeit nehmen, dir fürs Zuhören zu danken – das hilft uns extrem weiter. Mach's gut!