Prompt Flow: The Complete Guide

Salut, sunt Alex de la DEV STORIES DOT EU. Prompt Flow: Ghidul complet, episodul 1 din 14. Majoritatea librăriilor de AI încearcă să abstractizeze complexitatea ascunzând prompturile adânc în funcții wrapper. Dar când treci în producție, acele prompturi sunt exact lucrurile pe care trebuie să le controlezi. Aceasta este filosofia de bază din spatele Prompt Flow. Să clarificăm mai întâi o concepție greșită des întâlnită. Prompt Flow nu este un framework precum LangChain. LangChain este un framework de development care oferă chains și agenți pre-construiți, care adesea încapsulează prompturile din spate. Prompt Flow este o suită de tool-uri concepute pentru experimentare și evaluare. Există deoarece principiul tradițional de software engineering al încapsulării devine de fapt o povară atunci când construiești aplicații cu large language models. În programarea standard, ascunzi logica complexă în spatele unei interfețe curate a funcției. Nu trebuie să știi cum funcționează funcția intern, te interesează doar ce returnează. Dar prompturile sunt foarte volatile. Nu sunt o logică statică. Dacă schimbi modelul de la o versiune la alta, un prompt care a funcționat perfect ieri ar putea să eșueze astăzi. Dacă folosești o librărie third-party opacă pentru a rezuma documente, iar promptul din spate este blocat în interiorul acelei librării, nu poți repara un rezumat slab. Depinzi în întregime de maintainerii librăriei. Prompt Flow inversează acest design pattern prin expunerea prompturilor. Le tratează ca asset-uri de development de primă clasă. Trebuie să le vezi, să le faci tuning și să le versionezi continuu. În loc de un black box, primești un toolchain transparent în care controlezi exact textul și variabilele care intră în modelul de limbaj. Asta e partea care contează. Pentru că prompturile sunt volatile, construirea de aplicații de AI necesită un mod de lucru fundamental nou. În software-ul standard, scrii unit teste. Faci un assert că un anumit input produce un anumit output. Modelele de limbaj sunt probabilistice, ceea ce înseamnă că nu oferă răspunsuri deterministe. Nu poți scrie un simplu assert pentru a verifica dacă un email generat este politicos sau dacă un rezumat este corect. În schimb, trebuie să adopți un workflow centrat pe evaluare. Trebuie să rulezi promptul pe sute de exemple diverse și să măsori metrici precum relevanța sau acuratețea formatării. Prompt Flow este construit direct în jurul acestui workflow. Integrează prompt tuning-ul cu evaluarea în masă. Când schimbi un singur cuvânt în prompt, tooling-ul te ajută să vezi statistic dacă acea modificare a îmbunătățit rata de succes pe tot dataset-ul tău sau a degradat-o. Ultimul pilon al acestei filosofii este optimizarea pentru vizibilitate. Aplicațiile de AI sunt rareori doar un singur API call. Sunt grafuri complexe de execuție. Poți să iei o întrebare a utilizatorului, să faci un query într-o bază de date vectorială, să formatezi datele returnate, să le injectezi într-un prompt și apoi să apelezi modelul. Când răspunsul final este greșit, trebuie să știi exact unde s-a rupt chain-ul. Prompt Flow face acest graf de execuție vizibil. Poți inspecta fiecare node pentru a vedea exact inputurile și outputurile la acel pas precis din proces, făcând debugging-ul foarte simplu. Cel mai important lucru de reținut este că prompturile sunt variabile vii, volatile, care cer o observare constantă, nu cod static pe care îl poți scrie o singură dată și apoi să-l ascunzi. Dacă găsești aceste episoade utile și vrei să susții emisiunea, poți căuta DevStoriesEU pe Patreon. Asta e tot pentru acest episod. Mulțumesc pentru audiție și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Prompt Flow: Ghidul complet, episodul 2 din 14. Înainte de a scrie o singură linie de cod, trebuie să încetezi să te mai gândești la aplicațiile LLM ca la niște scripturi monolitice. Dacă încerci să le scrii liniar, urmărirea dependențelor și debugging-ul de state pe mai multe servicii externe devin rapid imposibil de gestionat. Soluția structurală pentru asta este să îți privești aplicația ca pe un graf de function calls independente, un concept cunoscut în Prompt Flow sub numele de flows și arhitectura DAG. Un flow este pur și simplu un workflow executabil. În esență, o aplicație LLM este o secvență orchestrată de call-uri externe, legate între ele prin logică. Poți apela un motor de căutare, poți face un query într-o bază de date, poți rula un script Python pentru a formata datele obținute și, în final, poți trimite un prompt către un LLM. Prompt Flow modelează această secvență ca un Directed Acyclic Graph, sau DAG. În acest graf, fiecare pas discret al aplicației tale este un node, iar conexiunile dintre aceste nodes reprezintă flow-ul de date. Este directed pentru că datele se mișcă înainte, de la o funcție la alta, și este acyclic pentru că traseul datelor nu face loop înapoi. Gândește-te la o aplicație simplă care răspunde la întrebări pe baza datelor interne ale companiei. Userul pune o întrebare, care servește ca input inițial. Acest input merge în primul node, o funcție Python care execută un query în baza de date. Baza de date returnează un bloc de text. Acel text, împreună cu întrebarea originală a userului, merge în următorul node, care face call-ul propriu-zis către LLM. LLM-ul generează un răspuns, care devine output-ul final al întregului graf. Structurând aplicația în acest fel, fiecare funcție este strict izolată. Știi exact ce a intrat în call-ul către baza de date și exact ce a ieșit, înainte ca LLM-ul să fie măcar declanșat. Când construiesc aceste workflow-uri, developerii întâlnesc adesea doi termeni și se întreabă care este superior: Flex flow sau DAG flow. Aici devine interesant. Ambele obțin exact același rezultat. Doar că oferă developer experiences diferite. Flex flow este o abordare code-first. Îți încapsulezi logica într-o funcție sau clasă Python standard, o desemnezi ca entry point și scrii raw code. Prompt Flow pur și simplu îl rulează. DAG flow, pe de altă parte, definește routing-ul folosind un fișier YAML. Listând explicit funcțiile ca nodes și conectând inputurile și outputurile lor în YAML, permiți platformei să randeze o reprezentare vizuală a aplicației tale. DAG flows sunt foarte UI-friendly, făcând ușoară inspectarea arhitecturii dintr-o privire. Dacă alegi abordarea DAG flow, vei lucra cu trei tipuri specifice de flows. Primul este Standard flow. Acesta este pipeline-ul tău general-purpose unde conectezi tools, cod Python și modele pentru a construi aplicații tipice. Al doilea este Chat flow. Acesta este construit direct pe Standard flow, dar este special adaptat pentru aplicații conversaționale. Adaugă suport nativ pentru gestionarea chat history-ului și configurează automat inputurile și outputurile de chat necesare. Al treilea tip este Evaluation flow. Nu folosești acest flow pentru a servi end userii. În schimb, rulezi un Evaluation flow pe outputurile din Standard sau Chat flows. Acționează ca un mecanism de testing pentru a calcula metrics precum factual accuracy sau relevanța, pe baza datelor produse de flow-ul tău principal. Indiferent dacă îți definești logica în Python pur sau o conectezi vizual cu YAML, aplicația ta LLM este în cele din urmă doar un pipeline care rutează text între sisteme externe. Stăpânește graful și controlezi aplicația. Asta e tot pentru acest episod. Mersi pentru audiție și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Prompt Flow: Ghidul complet, episodul 3 din 14. Ai conceput workflow-ul perfect pentru aplicația ta de AI, dar o simplă schiță nu procesează date. Ai nevoie de componente care să execute efectiv treaba, cum ar fi preluarea de URL-uri, formatarea de string-uri și apelarea de API-uri. Dacă flow-urile sunt schița aplicației tale, tool-urile sunt cărămizile. Astăzi, ne uităm la Tools. În Prompt Flow, tool-urile sunt componentele de bază, executabile, ale unui flow. Fiecare node din graph-ul tău este un tool. Când flow-ul tău rulează, pur și simplu dă datele mai departe de la un tool la altul. Deși poți extinde platforma, există trei tool-uri built-in pe care le vei folosi în aproape fiecare proiect: tool-ul Python, tool-ul Prompt și tool-ul LLM. Hai să parcurgem un scenariu practic ca să vedem cum se potrivesc. Vrei o aplicație care face fetch la o pagină web, formatează textul raw și generează un rezumat. Mai întâi, trebuie să obții conținutul paginii web. Folosești tool-ul Python. Acest tool îți permite să scrii scripturi Python custom și acționează ca o punte către lumea exterioară. Scrii un script scurt care primește un URL ca input, face un request HTTP și returnează textul raw al paginii. Tool-ul Python se ocupă de execuție și dă acel text raw mai departe ca output. Apoi, trebuie să pregătești instrucțiunile pentru modelul de limbaj. Folosești tool-ul Prompt. Acest tool preia input-uri de text, cum ar fi textul raw din tool-ul tău Python și un system prompt care definește persona de AI, și le formatează într-un singur string curat. Asta e partea care contează. Tool-ul Prompt nu apelează un model de AI. El strict pregătește și formatează text. Separarea acestui pas face flow-ul tău mult mai ușor de citit și de testat, mai ales atunci când ai de-a face cu prompt-uri complexe, din mai multe părți. În cele din urmă, trimiți acel string pregătit către model folosind tool-ul LLM. Acest tool se ocupă de conexiunea propriu-zisă la un endpoint de Large Language Model. Îi dai string-ul formatat din tool-ul tău Prompt, configurezi parametrii modelului, cum ar fi temperatura, iar el returnează rezumatul generat. Tool-ul LLM face munca grea de formatare a payload-ului API și de interacțiune cu providerul. Deși aceste trei acoperă majoritatea use case-urilor de bază, nu sunt singurele tale opțiuni. Prompt Flow suportă tool-uri partenere oferite de third parties. Un exemplu comun este tool-ul Vector DB Lookup, care caută în bazele de date vectoriale text similar pe bază de embeddings. De asemenea, poți instala pachete custom sau îți poți construi propriile tool-uri pentru integrări foarte specifice. Indiferent de originea lor, toate funcționează pe exact același principiu: preiau input-uri, execută o funcție specifică și returnează un output. Cel mai important lucru de reținut este principiul strict de separation of concerns. Nu scrie cod Python pentru a formata prompt-uri și nu folosi tool-ul LLM pentru a concatena string-uri. Folosirea tool-ului built-in potrivit pentru scopul lui exact îți menține graph-urile curate și debuggable. Mersi că ai stat cu noi. Sper că ai învățat ceva nou.

Salut, sunt Alex de la DEV STORIES DOT EU. Prompt Flow: Ghidul complet, episodul 4 din 14. Nimic nu distruge un deployment în producție mai repede decât un API key dat commit accidental în version control. Chiar dacă eviți acest dezastru, jonglarea cu credentials între mediile de development local și cloud duce adesea la fișiere de configurare încurcate și riscuri de securitate. Gestionarea secretelor prin connections rezolvă asta izolând complet datele tale sensibile de logica de flow. Un connection în Prompt Flow este o resursă dedicată care stochează endpoint-urile și credentials necesare pentru a interacționa cu servicii externe. Dacă flow-ul tău trebuie să apeleze un language model extern, să caute pe web folosind un serviciu extern sau să facă un query într-o bază de date remote, are nevoie de autorizare. În loc să scrii API keys direct în scripturile tale Python sau în fișierele de configurare, creezi un connection. Flow-ul tău va face apoi referință la acel connection după numele său. Folosind connections, îți decuplezi datele secrete de logica de execuție. Codul tău știe doar că are nevoie de un connection numit, de exemplu, main_language_model. Nu cunoaște acel API key real. Hai să vedem cum funcționează asta când muți un proiect de pe laptopul tău în cloud. Când faci development local, connections sunt stocate pe discul tău local. Pentru a menține securitatea, Prompt Flow criptează valorile secrete folosind o cheie de criptare locală. Poți să construiești și să testezi flow-ul folosind acest setup local, fără să lași chei în plaintext expuse în working directory. Când ești gata să dai deploy la acest flow în Azure AI, mediul se schimbă, dar codul tău nu. În Azure AI, connections sunt susținute în siguranță de Azure Key Vault. Secretele sunt stocate și gestionate în infrastructura Key Vault, protejate de politici de acces stricte. Asta e partea care contează. Pentru că flow-ul tău face referință la connection doar prin numele său, tranziția de la un mediu local la cloud necesită zero modificări în logica de flow. Pur și simplu te asiguri că există un connection cu nume identic în workspace-ul tău Azure. Când flow-ul rulează în cloud, cere main_language_model. Sistemul interceptează transparent acel request și furnizează credentials susținute de Key Vault în loc de cele criptate local. Codul tău rămâne curat și environment-agnostic. Prompt Flow clasifică aceste connections în două tipuri principale. Primul tip îl reprezintă strongly typed connections. Acestea sunt built-in templates pentru servicii foarte folosite, cum ar fi Azure OpenAI. Ele oferă câmpuri predefinite pentru endpoint URL, API key și tipul de API. Sistemul știe exact cum să gestioneze aceste câmpuri, ceea ce menține configurarea standard a tool-urilor simplă. Al doilea tip este custom connection. Când trebuie să integrezi un API intern al companiei sau un serviciu third-party care nu are un built-in template, folosești un custom connection. Acesta acționează ca un dicționar flexibil în care îți definești propriile perechi key-value. Poți marca explicit anumite chei ca secrets. Odată marcate, acele custom secrets primesc exact aceeași criptare locală și protecție Key Vault ca și built-in connections. Valoarea definitorie a connections este că acționează ca un abstraction layer strict pentru autentificare, asigurându-te că flow-ul tău rămâne complet portabil, iar secretele tale rămân în siguranță în orice mediu de execuție. Asta e tot pentru acest episod. Mulțumesc pentru audiție și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Prompt Flow: Ghidul complet, episodul 5 din 14. Nu mai îngropa prompturile modelului de limbaj în string-uri Python masive. Când faci hardcode la prompturi în logica aplicației, urmărirea modificărilor, rularea de teste standalone și colaborarea cu prompt engineers devin un coșmar absolut. Soluția este specificația Prompty. Un Prompty este un format standard pentru gestionarea prompturilor. Acesta îți mută promptul din cod într-un singur fișier markdown, cu version control, care are extensia punct prompty. Fișierul este împărțit în două secțiuni distincte. În partea de sus, ai un YAML front matter. În partea de jos, ai un prompt template formatat cu Jinja. Cele două sunt separate de trei cratime. Blocul YAML acționează ca un centru de control. Poți defini metadata de bază, cum ar fi numele, descrierea și autorul. Mai important, conține configurația modelului. Specifici tipul de API, cum ar fi chat sau completion. Definești detaliile de configurare, cum ar fi să pointezi către un deployment Azure OpenAI de GPT-3.5. Tot aici fixezi și parametrii modelului. Dacă un anumit prompt necesită o temperatură de zero virgulă șapte și o limită de max tokens de o mie, declari asta în YAML. Asta leagă setările de execuție direct de textul promptului, asigurându-te că promptul se comportă consecvent, indiferent unde este folosit. Secțiunea YAML definește, de asemenea, inputs și sample data. Dacă promptul tău așteaptă o variabilă dinamică, o listezi aici și oferi sample values. Asta face ca fișierul să fie complet self-contained. Oricine îl deschide știe exact ce date așteaptă, fără să fie nevoie să facă reverse-engineering pe codul aplicației tale. Sub YAML și cele trei cratime se află prompt template-ul propriu-zis. Această secțiune folosește sintaxa Jinja2 pentru a injecta dinamic acele inputs pe care le-ai definit mai sus. Pentru că modelele de limbaj moderne folosesc interfețe de chat, template-ul suportă definirea de roluri. Definești rolurile folosind un format de text simplu, separând instrucțiunile de system de user inputs. Ia în considerare un scenariu de chat minimal în care vrei un prompt care salută un user cu prenumele lui. În partea de sus a fișierului tău punct prompty, scrii YAML front matter-ul. Definești secțiunea de model, setând tipul de API pe chat și pointând configurația către un deployment de GPT-3.5. Apoi, adaugi o secțiune de inputs care declară o variabilă numită first name. De asemenea, adaugi un bloc de sample unde first name este setat pe Jane. Tastezi trei cratime pentru a încheia YAML front matter-ul. Acum construiești template-ul. Tastezi cuvântul system urmat de două puncte, apoi îi dai modelului instrucțiunile de bază, cum ar fi să-i spui să fie un asistent de ajutor. Sub asta, tastezi cuvântul user urmat de două puncte. În cele din urmă, scrii salutul, încadrând variabila first name între acolade duble, astfel încât motorul Jinja să știe unde să injecteze textul. Acum ai un asset complet și reutilizabil. Tratarea prompturilor ca fișiere self-contained, în loc de string-uri aruncate prin codul tău, este primul pas către un prompt engineering riguros, deoarece forțează un contract clar între aplicația care furnizează datele și modelul de limbaj care generează răspunsul. Mulțumesc că ai petrecut câteva minute cu mine. Până data viitoare, numai bine.

Salut, sunt Alex de la DEV STORIES DOT EU. Prompt Flow: Ghidul complet, episodul 6 din 14. Construiești un prompt template atent reglat pentru producție, dar când vrei să-l testezi cu un model mai ieftin sau să ajustezi temperatura pentru un anumit edge case, te trezești că editezi manual fișierul sursă. Un template static creează fricțiune atunci când environment-ul sau logica ta trebuie să se schimbe din mers. Această fricțiune este exact ceea ce Dynamic Prompty Execution este conceput să elimine. Un asset Prompty definește de obicei setările modelului, cum ar fi numele de deployment, conexiunea API și parametrii, în blocul său de header. Totuși, hardcodarea acestor valori restricționează modul în care folosești fișierul în diferite environment-uri. Execuția dinamică îți permite să tratezi fișierul Prompty ca un strat de bază flexibil, făcând override la configurațiile sale direct din Python sau din command line, la runtime. Pentru a rula un fișier Prompty în Python, folosești funcția load prompty din core library-ul Prompt Flow. Pasezi file path-ul către această funcție, iar ea returnează un obiect callable în memorie. Pentru a-l executa, pur și simplu apelezi acel obiect, pasând variabilele tale de prompt ca keyword arguments standard. Library-ul gestionează compilarea și apelul API, returnând text output-ul final. Acesta este exact punctul în care execuția dinamică își dovedește valoarea. Poți intercepta execuția pentru a face override la setările modelului fără să atingi fișierul de bază. Să presupunem că ai un Prompty configurat pentru un deployment Azure OpenAI standard, dar pentru un anumit batch job, trebuie să-l îndrepți către un alt endpoint Azure și să crești temperatura pentru a obține răspunsuri mai variate. În loc să duplici fișierul, definești un dicționar în codul tău Python care conține noile setări. Adaugi endpoint-ul alternativ și noua valoare a temperaturii în acest dicționar. Apoi, când apelezi obiectul Prompty încărcat, pasezi acest dicționar keyword argument-ului model, alături de prompt input-urile standard. Runtime-ul Prompt Flow face merge între dicționarul tău și configurația fișierului de bază. Override-urile tale dinamice au prioritate, promptul se execută cu noile setări, iar fișierul original rămâne complet neschimbat. Acest lucru îți permite să schimbi cheile API, să modifici max tokens sau să redirecționezi programatic target-ul modelului în funcție de state-ul aplicației. Uneori, nu vrei să scrii un script Python doar ca să vezi dacă un prompt dă un rezultat bun. Pentru o validare rapidă, poți testa un fișier Prompty direct din terminal. Folosești comanda pf flow test, furnizând calea către fișierul tău cu ajutorul flag-ului source. Poți adăuga flag-ul inputs pentru a pasa variabilele direct în comandă ca perechi key-value. Command line interface-ul execută Prompty-ul și afișează răspunsul modelului direct în standard output. Acest lucru îți oferă un feedback loop imediat în timpul development-ului, fără să scrii cod de wrapper. Valoarea reală a unui asset Prompty nu constă în blocarea configurațiilor, ci în izolarea textului de prompt de environment-ul de execuție. Prin injectarea dinamică a override-urilor de model la runtime, un singur fișier poate servi perfect sandbox-ul tău de testare locală, pipeline-urile automate și endpoint-urile de producție. Asta e tot pentru acest episod. Mulțumesc pentru audiție și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Prompt Flow: Ghidul complet, episodul 7 din 14. S-ar putea să crezi că utilizarea unui framework specializat pentru large language models înseamnă să înveți o interfață vizuală complexă sau să menții fișiere de configurare masive. Dar dacă știi deja cum să scrii un script Python, știi deja suficient pentru a construi o aplicație complet trackable. Flex Flows bazate pe funcții rezolvă complet această tensiune. În dezvoltarea standard din Prompt Flow, construiești un Directed Acyclic Graph. Această structură este extrem de eficientă pentru pipelines stricte, cu mai mulți pași, dar uneori developerii vor să scrie cod Python pur fără să se adapteze la un sistem vizual de tip node. Flex Flows îți permit să faci exact asta. Încapsulezi logica aplicației tale LLM în funcții Python standard, iar platforma se ocupă de tracking și orchestrare în fundal. Ia în considerare abordarea bazată pe funcții. Începi prin a scrie o funcție Python normală. Dă-i un nume descriptiv, cum ar fi chat, și definește-i inputurile, cum ar fi preluarea unei întrebări ca parametru de tip string. În interiorul acestei funcții, îți scrii logica exact așa cum ai face-o în mod normal. Ai putea încărca un fișier Prompty pentru a obține acel system message, a inițializa clientul de language model, a transmite întrebarea către model și apoi a returna răspunsul text ca string. În această etapă, ai pur și simplu un script Python standard. Rulează local, este ușor de testat și nu necesită cunoștințe speciale de framework. Pentru a transforma acest script Python pur într-o componentă Prompt Flow trackable, imporți decoratorul trace din package-ul de tracing promptflow. Plasezi acest decorator direct deasupra funcției tale chat. Când rulezi codul, acest decorator îi spune sistemului să monitorizeze execuția în mod silențios. Înregistrează automat inputurile transmise funcției, outputul text returnat, timpul exact de execuție și orice erori interne. Dacă aplici decoratorul trace altor funcții helper din scriptul tău, sistemul construiește un call tree complet. Obții observabilitatea completă a unui visual flow, inclusiv capacitatea de a vizualiza acel execution trace în interfața locală, fără a schimba modul în care îți structurezi logica. Acum, tooling-ul are nevoie de o modalitate de a ști că această funcție specifică este entry point-ul aplicației tale. Oferi acest lucru prin crearea unui singur fișier de configurare foarte scurt, numit flow.flex.yaml, în același director cu codul tău. Acest fișier nu definește un routing graph complex. Are nevoie doar de o informație critică, și anume acel entry mapping. Scrii cuvântul entry urmat de numele modulului tău Python, două puncte și numele funcției tale. Dacă fișierul tău se numește app.py și funcția ta este chat, valoarea pentru entry este pur și simplu app două puncte chat. Când testezi sau rulezi acest flow folosind command line tool-ul Prompt Flow sau extensia VS Code, sistemul citește acel fișier yaml. Caută funcția chat în modulul tău app, injectează inputurile furnizate, rulează codul tău Python pur și colectează acele traces generate de decorator. Adevărata putere a Flex Flows bazate pe funcții este că elimină fricțiunea dintre prototiparea unui script și deploy-ul unei aplicații de producție; logica ta Python pură rămâne în întregime sub controlul tău, în timp ce un singur decorator și un fișier de configurare de două linii deblochează observabilitate enterprise-grade. Asta e tot pentru acest episod. Mulțumesc că m-ai ascultat și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Prompt Flow: Ghidul complet, episodul 8 din 14. Faci deploy la o nouă aplicație cu un language model, dar de fiecare dată când un utilizator trimite un mesaj, durează secunde prețioase doar pentru a stabili conexiunea la baza de date și a încărca credențialele clientului. Când aplicația ta trebuie să mențină o conexiune persistentă sau să țină minte istoricul conversației, un script standalone eșuează pentru că pornește complet de la zero la fiecare rulare. Răspunsul la această problemă este Flex Flows: Dezvoltare Class-Based. Când construiești aplicații care scalează, state management-ul devine o preocupare principală. Dacă flow-ul tău se bazează pe o resursă externă, cum ar fi un client Azure OpenAI, inițializarea acelui client necesită citirea de secrets, verificarea de endpoints și alocarea de memorie. Dacă pui această logică într-o secvență de execuție de bază, plătești acel cost uriaș de startup de fiecare dată când vine un request. Folosirea unei clase Python ca entry point pentru Flex Flow-ul tău îți permite să separi fundamental logica de inițializare de logica de execuție. Un flow class-based se bazează pe două metode Python standard pentru a gestiona acest lifecycle. Prima este constructorul, sau metoda init. Aceasta este faza ta de setup. Prompt Flow rulează această metodă exact o singură dată când flow-ul este încărcat pentru prima dată în memorie. Aici faci tot greul. A doua metodă este metoda call. Aceasta este faza ta de execuție și rulează de fiecare dată când flow-ul este declanșat de un request al utilizatorului. Imaginează-ți o clasă pentru un chat flow. Îți definești metoda init pentru a accepta un obiect de conexiune Azure OpenAI și un string pentru system prompt. În interiorul metodei init, îți creezi clientul Azure OpenAI și îl stochezi ca proprietate chiar pe instanța clasei. Clientul este acum gata și așteaptă. Apoi, îți definești metoda call. Această metodă acceptă o nouă întrebare de la utilizator și o listă de mesaje anterioare care reprezintă istoricul de chat. Pentru că acest client este deja complet inițializat, metoda call formatează imediat prompt-ul, trimite istoricul de chat către language model și returnează răspunsul. Execuția este rapidă pentru că acel setup costisitor al clientului a fost complet evitat. Ca asta să funcționeze, Prompt Flow trebuie să știe cum să îți instanțieze clasa. Configurezi asta creând un fișier YAML pentru flow-ul tău. Entry point-ul din acest fișier de configurare folosește un format specific, punând numele modulului Python urmat de două puncte și numele clasei tale. Asta e partea care contează. Configurația ta YAML nu doar indică spre clasă, ci definește parametrii ceruți de metoda ta init. Dacă constructorul clasei tale cere o conexiune Azure și un nume de model, declari acele inputs în fișierul YAML sub o secțiune init dedicată. Când engine-ul Prompt Flow pornește, citește YAML-ul, injectează acei parametri configurați în constructorul clasei tale, și apoi ține acel obiect instanțiat viu în memorie pentru a gestiona call-urile primite. Testarea locală a unui flow class-based este incredibil de simplă, pentru că se bazează pe comportamentul standard din Python. Nu ai nevoie de un test harness complex. Pur și simplu scrii un script Python standard, îți imporți clasa, creezi o instanță pasând conexiuni mock sau credențiale locale către constructor, și apoi invoci obiectul direct pasându-i un mesaj de test. Poți face debug la logica de setup și la logica de execuție în mod independent. Ideea principală este că flow-urile class-based îți oferă structura arhitecturală pentru a separa greul inițializării de munca repetitivă de execuție, păstrându-ți state-ul persistent și răspunsurile rapide. Dacă ți se par utile aceste episoade și vrei să susții emisiunea, poți căuta DevStoriesEU pe Patreon. Asta e tot pentru acest episod. Mulțumesc că m-ai ascultat și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Prompt Flow: Ghidul complet, episodul 9 din 14. Uneori, să te uiți la un perete de cod nu e suficient ca să înțelegi o aplicație complexă. Când prompt-urile, script-urile și apelurile API interacționează în zeci de moduri, trebuie să vezi fizic cum se mișcă datele între ele ca să identifici blocajele. Flow-urile DAG sunt răspunsul pentru echipele care vor o claritate arhitecturală explicită. DAG vine de la Directed Acyclic Graph. În Prompt Flow, un DAG flow este o metodă de a construi aplicații AI prin conectarea diferitelor tool-uri între ele sub formă de noduri. În loc să scrii un singur script mare, definești structura aplicației tale într-un fișier numit flow dot dag dot yaml. Acest fișier funcționează ca un blueprint principal. El declară input-urile inițiale, pașii individuali și output-urile finale ale aplicației tale. Fiecare pas dintr-un DAG flow se numește nod. Un nod reprezintă un tool specific care execută un singur task. Poți avea un nod care rulează un snippet Python, un alt nod care formatează un prompt și un al treilea nod care apelează un Large Language Model. Fișierul YAML descrie cum relaționează aceste noduri între ele prin dependențe de input și output. Această mapare a dependențelor este ceea ce face flow-ul să funcționeze. Nu îi spui manual sistemului în ce ordine să execute pașii. În schimb, specifici că nodul B are nevoie de output-ul nodului A. Pentru că nodul B nu poate începe până când nodul A nu se termină, se formează natural o ordine de execuție. Dacă adaugi un nod C care depinde doar de input-ul inițial al utilizatorului, Prompt Flow va recunoaște că nu trebuie să aștepte după nodul A sau B. Va rula automat nodul C în paralel. Engine-ul citește fișierul yaml, rezolvă graful și se ocupă de orchestrare. Să scrii și să menții manual acest fișier yaml poate deveni dificil pe măsură ce aplicația ta crește. De aceea, majoritatea developerilor folosesc extensia Prompt Flow pentru VS Code. Această extensie citește fișierul tău flow dot dag dot yaml și randează o interfață vizuală de tip drag-and-drop. Îți poți vizualiza aplicația ca pe o hartă propriu-zisă de blocuri conectate. Ia în considerare un scenariu concret. Construiești o aplicație care citește rapoarte financiare și scrie rezumate executive scurte. În editorul vizual, creezi un nod de tip tool Python și îl numești Extract Text. Lângă el, adaugi un nod de tip tool LLM numit Summarize. În loc să scrii cod ca să gestionezi state-ul dintre aceste două operații, folosești interfața. Dai click pe portul de output al nodului Extract Text și tragi o linie către portul de input al nodului Summarize. Tocmai ai conectat vizual calea datelor. Extensia actualizează instantaneu fișierul yaml din spate pentru a înregistra acea conexiune. Obții viteza și claritatea unui builder vizual low-code, dar generezi în continuare un fișier de configurare plain text pe care îl poți urmări în version control. Această abordare vizuală impune o disciplină arhitecturală. Graful este aciclic, ceea ce înseamnă că datele pot curge doar înainte. Nu există loop-uri infinite. Datele intră, trec prin secvența ta de tool-uri și ies. Acest flow direcțional strict face ca debugging-ul să fie simplu. Dacă un rezumat final pare greșit, poți deschide graful vizual, dai click pe conexiunea dintre nodurile de extragere și sumarizare și inspectezi exact acel string de text care a fost transmis pe acel fir. Știi exact de unde au venit datele și unde s-au dus. Adevăratul avantaj al unui DAG flow este că diagrama de arhitectură a sistemului tău și aplicația executabilă sunt exact același lucru. Asta e tot pentru acest episod. Mulțumesc că ai ascultat și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Prompt Flow: Ghidul complet, episodul 10 din 14. Când un model de limbaj returnează un răspuns halucinat, complet greșit, cum știi dacă modelul în sine a eșuat sau dacă logica ta de formatare a prompt-ului a avut un bug? Poți împrăștia print statements în întreaga aplicație, dar asta devine imposibil de menținut pe măsură ce aplicația ta crește. Tracing-ul interacțiunilor LLM rezolvă asta prin capturarea contextului exact al fiecărei execuții. Tracing-ul transformă o aplicație LLM de tip black-box într-o secvență de evenimente transparentă, ușor de debugat. Înregistrează exact ce date intră într-o funcție, ce iese din ea și cât durează execuția. În acest ecosistem, gestionezi asta cu pachetul promptflow-tracing. Datele pe care le generează se bazează pe specificația OpenTelemetry, ceea ce înseamnă că înregistrările execuției tale respectă un format standard din industrie pentru observabilitate. Pentru a captura interacțiunile de bază cu un model, folosești o funcție numită start trace. Dacă apelezi această funcție chiar la începutul scriptului tău Python, Prompt Flow instrumentează automat clienții de model suportați. De exemplu, dacă folosești pachetul standard OpenAI Python, nu trebuie să modifici deloc apelurile API. Tracer-ul interceptează în liniște interacțiunea, logând mesajul de sistem, prompt-ul utilizatorului, parametrii specifici ai modelului și string-ul final de răspuns. Capturarea apelului API este doar jumătate din bătălie. Logica ce duce la acel apel este de obicei locul unde se ascund bug-urile. Pentru a face trace la propria logică a aplicației, aplici decoratorul trace pe funcțiile tale custom. Ia în considerare o funcție numită math to code. Această funcție primește input de la un utilizator care descrie o problemă de matematică, aduce contextul necesar, construiește un prompt și, în final, cere cod Python de la GPT-4. Plasând decoratorul trace direct deasupra definiției funcției math to code, îi spui lui Prompt Flow să înregistreze fiecare execuție a acestui bloc specific de logică. Va loga string-ul de input al utilizatorului, codul final returnat și latența întregii operațiuni. Pentru că ai rulat și start trace în partea de sus a fișierului tău, sistemul înțelege relația dintre codul tău și apelul către model. Acesta construiește o înregistrare ierarhică. Funcția ta math to code devine parent span, iar apelul intern OpenAI devine un child span imbricat în interiorul acestuia. Vizualizezi această ierarhie folosind Trace UI-ul local. Când rulezi un script cu trace, Prompt Flow pornește un server local pe care îl poți deschide în browserul web. Această interfață îți oferă un timeline vizual al flow-ului aplicației tale. Poți selecta parent span-ul math to code pentru a verifica argumentele pe care le-a primit. Apoi, poți selecta child span-ul OpenAI pentru a inspecta string-ul exact al raw prompt-ului care a fost trimis cu succes către model prin rețea. Dacă logica ta de asamblare a contextului a omis o variabilă, vei vedea imediat spațiul gol în raw prompt. Adevărata putere a tracing-ului nu constă doar în colectarea log-urilor de execuție, ci în demonstrarea definitivă a ceea ce s-a întâmplat la granița exactă dintre codul aplicației tale și modelul extern. Asta e tot pentru acest episod. Mulțumesc pentru audiție și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Prompt Flow: Ghidul complet, episodul 11 din 14. Tocmai ai petrecut trei luni construind o aplicație complexă folosind LangChain. Logica funcționează în mare parte, dar când un agent intră ocazional într-un bad loop sau pierde contextul, să afli exact unde a deraiat este un coșmar, iar rescrierea întregului cod doar pentru a obține logs mai bune este complet exclusă. Tracing avansat pentru LangChain și AutoGen este soluția directă pentru asta. Când construiești cu framework-uri de orchestrare, câștigi viteză prin abstractizare. Framework-ul ascunde detaliile complicate de prompt sequencing, tool execution și parsing. Dar abstractizarea creează inerent un black box. Când agentul tău returnează un răspuns confuz, trebuie să îi vezi acel chain of thought intern. Trebuie să știi exact sub-promptul pe care l-a generat, răspunsul API raw pe care l-a primit și ce tool call specific a eșuat. Prompt Flow include o funcționalitate de tracing standalone concepută exact pentru asta. Nu îți cere să folosești Prompt Flow pentru logica sau execuția ta. Îți păstrezi codul LangChain sau AutoGen existent exact așa cum e. Doar atașezi sistemul de tracking din Prompt Flow la aplicația ta externă. Gândește-te la scriptul tău Python existent care rulează un agent LangChain. Pentru a obține vizibilitate completă, nu te atingi de definițiile de chain. Pur și simplu mergi la începutul fișierului principal de execuție. Imporți funcția de setup pentru trace din modulul prompt flow și o apelezi o singură dată înainte ca agentul tău să înceapă treaba. Acea singură comandă reprezintă întreaga integrare. Când apelezi acea funcție, ea îți instrumentează environment-ul. Pentru că tracing-ul din Prompt Flow este construit pe standardele OpenTelemetry, știe cum să asculte evenimentele specifice declanșate de aceste framework-uri populare. Pe măsură ce aplicația ta LangChain rulează, instrumentarea interceptează automat apelurile API din spate. Capturează inputurile, durata de execuție, outputurile și token usage-ul pentru fiecare pas. Asta se aplică perfect și la AutoGen. Setup-urile multi-agent în AutoGen sunt notoriu de greu de făcut debug, pentru că mai mulți agenți trimit mesaje back and forth în mod autonom. Să faci tracking la cine a transmis ce context cui înseamnă de obicei să sapi prin pereți masivi de text în terminal. Prin inițializarea trace-ului la începutul scriptului tău AutoGen, fiecare schimb de mesaje este capturat și structurat automat. După ce scriptul termină de executat, deschizi Prompt Flow Trace UI local. În loc să dai scroll prin print statements în consolă, primești un timeline vizual. Vezi un execution tree clar. Dai click pe run-ul agentului de top-level, extinzi nodul și vezi secvența de apeluri LLM nested și tool executions. Dacă un agent a halucinat la pasul patru, poți da click direct pe pasul patru ca să citești textul exact, unformatted, care a fost trimis către model. Obții vizibilitate completă într-un framework opac, fără să fii nevoit să migrezi nicio linie din business logic-ul tău actual. Adevăratul avantaj aici este libertatea arhitecturală; îți poți orchestra aplicația folosind orice framework se potrivește cel mai bine echipei tale, păstrând în același timp debugging-ul și observability-ul centralizate într-o singură interfață vizuală curată. Ca întotdeauna, mersi că m-ai ascultat. Ne vedem în următorul episod.

Salut, sunt Alex de la DEV STORIES DOT EU. Prompt Flow: Ghidul complet, episodul 12 din 14. Promptul tău a funcționat perfect pe întrebarea de test, dar ce se întâmplă când îl rulezi pe zece mii de interogări reale ale utilizatorilor? De obicei, crapă. Testarea manuală a unui prompt cu două exemple e ușoară, dar ca să demonstrezi că funcționează pe sute de edge cases ai nevoie de ceva mai robust. Aici intervine scalarea: Batch Runs cu date. Un batch run îți ia acel flow singular și îl execută pe un dataset mare. Asta te trece de la construirea logicii la verificarea ei la scară largă. În loc să tastezi inputuri într-o interfață de utilizator, declanșezi procesul ăsta folosind command line interface. Comanda de bază este pf run create. Executând-o, instruiești Prompt Flow să pornească o nouă instanță de run, să citească un anumit director de flow și să-i dea un fișier care conține toate înregistrările tale de test. Motorul procesează aceste înregistrări executând întregul tău flow graph independent pentru fiecare linie din datasetul tău. Formatul de date necesar pentru acest fișier de input este JSONL. JSONL vine de la JSON Lines. Dacă ești obișnuit cu JSON standard, te-ai putea aștepta la un singur array mare care să înglobeze toate obiectele. JSONL renunță la array. Fiecare linie din fișierul text este propriul ei obiect JSON valid și independent, reprezentând exact un test case. Formatul ăsta este foarte preferat în machine learning și data pipelines, pentru că este lightweight și face streaming ușor. Motorul îl poate citi linie cu linie fără să încarce un fișier masiv în memorie dintr-o dată. Ia în considerare un flow de web-classification. Flow-ul tău e conceput să ia o adresă web, să facă scrape la conținut și să folosească un language model ca să-l categorizeze. Flow graph-ul așteaptă un anumit input string numit url. Vrei să testezi logica asta pe o sută de site-uri diferite ca să vezi cum gestionează acele edge cases. Îți construiești fișierul JSONL. Fiecare linie conține un obiect JSON cu o cheie, numită poate web link, care conține adresa țintă. Ca să pornești batch run-ul, tastezi pf run create. Specifici directorul de flow folosind flag-ul flow și indici fișierul JSONL folosind flag-ul data. Dar există o nepotrivire structurală imediată. Logica de flow necesită strict un input numit url, în timp ce fișierul tău de date oferă un câmp numit web link. Dacă rulezi comanda chiar acum, va eșua. Motorul nu ghicește ce câmpuri de date aparțin căror inputuri de flow. Rezolvi problema asta folosind flag-ul de column mapping. Acest flag îi spune motorului de execuție exact cum să conecteze cheile din fișierul JSONL la acele input nodes specifice ale flow-ului tău. În argumentele din command line, scrii numele de flow input, un semn de egal, și apoi o referință către coloana de date. Prompt Flow folosește o binding syntax specifică pentru aceste referințe. Scrii un semn de dolar, urmat de cuvântul data, un punct, și apoi numele coloanei din fișier. Pentru scenariul de web-classification, faci maparea scriind url equals dollar sign data dot web link. Această instrucțiune explicită face bind între câmpul de date și cerința de flow. Motorul va extrage acum string-ul web link din prima linie a fișierului JSONL și îl va injecta în inputul url al flow-ului tău. Apoi repetă exact același proces pentru linia a doua, linia a treia, și așa mai departe până când întregul fișier este procesat. Poți mapa mai multe inputuri în felul ăsta. Dacă flow-ul tău așteaptă un url și un user id, pur și simplu adaugi o altă instrucțiune de mapare la aceeași comandă. Decuplarea datelor de test de flow inputs folosind column mapping explicit înseamnă că nu va trebui niciodată să-ți modifici codul de bază doar ca să rulezi un nou dataset. Mersi că ai petrecut câteva minute cu mine. Până data viitoare, numai bine.

Salut, sunt Alex de la DEV STORIES DOT EU. Prompt Flow: Ghidul complet, episodul 13 din 14. Nu poți scrie un unit test standard care să facă assert că răspunsul unui large language model este egal cu un string exact. Dacă output-ul se schimbă de fiecare dată, cum demonstrezi matematic că aplicația ta funcționează cu adevărat înainte de a-i face deploy? Răspunsul este Paradigma Evaluării. În software engineering-ul tradițional, unit testing-ul este determinist. Dai un input specific unei funcții și te aștepți la un output exact. Large language models sunt stocastice. Sunt inerent imprevizibile. Cere-i unui model să clasifice o pagină web și ar putea da ca output cuvântul sport, sau ar putea spune că categoria este sport, sau ar putea pur și simplu să-ți dea un emoji relevant. Un assert de test standard va da fail la două din trei dintre acestea, chiar dacă modelul a dat, în esență, răspunsul corect. Pentru a demonstra că ești gata de release, trebuie să treci de unit tests și să adopți evaluarea statistică. În Prompt Flow, acest lucru este gestionat de un Evaluation Flow. Un evaluation flow este doar un flow normal, dar în loc să genereze text pentru un end user, singurul său job este să noteze output-ul unui alt flow. Ia predicțiile generate de aplicația ta principală, le compară cu un set cunoscut de răspunsuri corecte și dă ca output metrici calculate. Hai să fim mai concreți. Să zicem că tocmai ai terminat un batch run al unui flow de clasificare web. A procesat o sută de adrese web și a dat ca output o categorie prezisă pentru fiecare. Acum trebuie să știi exact cât de precise sunt aceste predicții. Iei output-urile acelui base run și le dai ca input într-un evaluation flow nou, dedicat, conceput să calculeze acuratețea clasificării. Declanșezi asta din command line folosind comanda run create. Specifici evaluation flow-ul tău, dar în loc să-i dai doar un fișier static cu input-uri noi, îi pasezi o referință către batch run-ul tău anterior. Evaluation flow-ul are nevoie de două informații pentru a-și face jobul. Are nevoie de predicția modelului și are nevoie de ground truth, adică răspunsul corect istoric. Oferi un data mapping care conectează aceste puncte. Îi spui sistemului să mapeze input-ul de predicție din evaluation flow la output-ul categoriei din base run-ul tău. Apoi, mapezi input-ul de ground truth la coloana cu true label-ul real, aflată în dataset-ul tău de test original. Asta e partea care contează. Evaluation flow-ul se execută rând cu rând, parcurgând întregul istoric al run-ului anterior. Pentru fiecare rând, se uită la ce a prezis flow-ul tău principal și compară cu ground truth-ul. Atribuie un scor pentru acea interacțiune specifică. În scenariul nostru de clasificare, asta ar putea însemna pur și simplu unu pentru un match și zero pentru un miss. Alte evaluation flows ar putea folosi un language model pentru a judeca calitatea unui rezumat pe o scară de la unu la cinci. Odată ce flow-ul termină de notat absolut fiecare rând, agregă acele scoruri individuale într-o metrică finală, generală. Nu primești doar un log masiv de unu și zero. Primești un număr definitiv, top-level, cum ar fi o acuratețe generală de nouăzeci și doi la sută. Poți apoi să vizualizezi aceste metrici agregate pentru a decide dacă versiunea curentă a aplicației tale este gata de producție. Nu mai trebuie să ghicești dacă un tweak la prompt ți-a îmbunătățit sistemul; ai dovada statistică exactă a cât de bine sau de prost performează pe întregul tău dataset. Mulțumesc că m-ai ascultat. Pe data viitoare!

Salut, sunt Alex de la DEV STORIES DOT EU. Prompt Flow: Ghidul complet, episodul 14 din 14. Ai construit, ai făcut trace și ai evaluat flow-ul modelului tău de limbaj, iar acesta funcționează perfect. Dar acum, stă pur și simplu în mediul tău de development, complet izolat de utilizatorii reali. Să îl scoți din IDE și să îl transformi într-un serviciu stabil și accesibil este exact ceea ce acoperim astăzi, ducând flow-urile în producție. Când nu rulează, un prompt flow este pur și simplu un folder. Acesta conține un fișier de configurare YAML și scripturile tale Python sau template-urile Jinja. Pentru ca acel folder să facă ceva în lumea reală, ai nevoie de un mediu de execuție care să încarce acele fișiere și să asculte request-urile HTTP primite. În timpul development-ului, probabil ai folosit serverul local built-in. Rulezi o comandă simplă, iar acesta pornește un endpoint local pentru a testa input-urile și output-urile. Asta este în regulă pentru a verifica logica, dar nu este conceput pentru a face față traficului concurent din producție, pentru a gestiona memoria eficient sau pentru a supraviețui unui system crash. Pentru a ajunge în producție, ai nevoie de containerizare. Prompt Flow este construit pentru a se integra direct cu Docker. În loc să îți scrii propriul web server de la zero, folosești tooling-ul Prompt Flow pentru a-ți exporta flow-ul ca un container Docker. Când rulezi procesul de export, sistemul generează un Dockerfile. Acest fișier definește o imagine de bază, copiază directorul flow-ului în ea, instalează exact dependențele Python listate în fișierul tău requirements și configurează un web server production-ready pentru a servi flow-ul ca un REST API. Asta este partea care contează. Odată ce flow-ul tău este într-un container Docker, încetează să mai fie un experiment special de machine learning și devine un artefact software standard. Îl poți trata ca pe orice alt microservice. Ia un scenariu concret. Ai un chat flow validat pentru customer support. Construiești imaginea Docker și îi dai push în container registry-ul tău privat. Apoi, faci deploy la acea imagine pe un cluster Kubernetes. Scrii o configurație standard de deployment care îi spune lui Kubernetes să ridice trei replici ale containerului tău de chat flow și pui un load balancer în fața lor. Acum, aplicația ta de frontend trimite request-uri HTTP standard către load balancer, care distribuie traficul între containerele tale. Dacă chat flow-ul tău este asaltat de request-uri de la utilizatori, Kubernetes pur și simplu face scale up la mai multe instanțe ale flow-ului tău. Dacă nu vrei să gestionezi un cluster Kubernetes, aceeași imagine Docker funcționează perfect pe servicii de tip managed platform. Poți să îi faci deploy direct în Azure App Service sau pe orice alt cloud provider care găzduiește containere. Flow-ului nu îi pasă unde rulează, atâta timp cât are un container runtime. Există un deployment pattern alternativ. Dacă nu construiești un web service, poți distribui un flow ca o aplicație executabilă. Asta împachetează flow-ul și dependențele sale de runtime într-un fișier executabil standalone. Asta este util dacă trebuie să rulezi logica direct pe o mașină client sau pe un edge device, ocolind complet nevoia de a instala Python sau de a configura un server. Mutarea unui prompt flow în producție nu necesită hosting proprietar sau o infrastructură specializată de machine learning. Prin exportul în Docker, flow-urile modelului tău de limbaj se integrează perfect în exact aceleași pipeline-uri de continuous delivery și orchestratoare de containere pe care le folosești deja pentru serviciile tale tradiționale de backend. Dacă vrei să aprofundezi, te încurajez să citești documentația oficială Prompt Flow, să încerci să faci deploy la un container tu însuți, sau să vizitezi devstories dot eu pentru a sugera subiecte pe care vrei să le vezi în seriile viitoare. Aș vrea să îmi iau un moment să îți mulțumesc pentru că ne asculți — ne ajută foarte mult. Să ai o zi super!