Prompt Flow: The Complete Guide

Ciao, sono Alex di DEV STORIES DOT EU. Prompt Flow: La Guida Completa, episodio 1 di 14. La maggior parte delle librerie AI cerca di astrarre la complessità nascondendo i tuoi prompt in profondità all'interno di funzioni wrapper. Ma quando passi in produzione, quei prompt sono esattamente le cose che devi controllare. Questa è la filosofia alla base di Prompt Flow. Prima di tutto, chiariamo un malinteso comune. Prompt Flow non è un framework come LangChain. LangChain è un framework di sviluppo che fornisce chain e agent pre-costruiti, che spesso incapsulano i prompt sottostanti. Prompt Flow è una suite di tool progettata per la sperimentazione e la valutazione. Esiste perché il tradizionale principio di incapsulamento del software engineering diventa in realtà un ostacolo quando sviluppi applicazioni con i large language model. Nella programmazione standard, nascondi la logica complessa dietro un'interfaccia pulita della funzione. Non hai bisogno di sapere come funziona internamente la funzione, ti interessa solo cosa restituisce. Ma i prompt sono altamente volatili. Non sono logica statica. Se cambi il tuo modello da una versione all'altra, un prompt che ieri funzionava perfettamente oggi potrebbe fallire. Se usi una libreria di terze parti opaca per riassumere dei documenti, e il prompt sottostante è bloccato all'interno di quella libreria, non puoi correggere un riassunto scadente. Dipendi completamente dai maintainer della libreria. Prompt Flow ribalta questo design pattern esponendo i prompt. Li tratta come asset di sviluppo di prima classe. Devi visualizzarli, farne il tuning e versionarli continuamente. Invece di una black box, ottieni una toolchain trasparente dove controlli l'esatto testo e le variabili che entrano nel language model. Questa è la parte che conta. Dato che i prompt sono volatili, creare applicazioni AI richiede un modo di lavorare fondamentalmente nuovo. Nel software standard, scrivi degli unit test. Asserisci che uno specifico input produca uno specifico output. I language model sono probabilistici, il che significa che non forniscono risposte deterministiche. Non puoi scrivere una semplice assert per verificare se un'email generata è educata o se un riassunto è accurato. Devi invece adottare un workflow incentrato sulla valutazione. Devi eseguire il tuo prompt su centinaia di esempi diversi e misurare metriche come la pertinenza o l'accuratezza della formattazione. Prompt Flow è costruito direttamente intorno a questo workflow. Integra il prompt tuning con la valutazione di massa. Quando cambi una singola parola nel tuo prompt, il tooling ti aiuta a vedere statisticamente se quel cambiamento ha migliorato il tuo tasso di successo su tutto il tuo dataset o lo ha peggiorato. L'ultimo pilastro di questa filosofia è l'ottimizzazione per la visibilità. Le applicazioni AI raramente sono solo una singola chiamata API. Sono complessi execution graph. Potresti prendere una domanda dell'utente, interrogare un vector database, formattare i dati recuperati, iniettarli in un prompt e poi chiamare il modello. Quando la risposta finale è sbagliata, devi sapere esattamente dove si è rotta la chain. Prompt Flow rende visibile questo execution graph. Puoi ispezionare ogni nodo per vedere i precisi input e output in quell'esatto passaggio del processo, rendendo il debugging semplice. La cosa più importante da ricordare è che i prompt sono variabili vive e volatili che richiedono un'osservazione costante, non codice statico che puoi scrivere una volta e nascondere. Se trovi utili questi episodi e vuoi supportare lo show, puoi cercare DevStoriesEU su Patreon. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Prompt Flow: La Guida Completa, episodio 2 di 14. Prima di scrivere una sola riga di codice, devi smettere di pensare alle applicazioni LLM come a script monolitici. Se provi a scriverle in modo lineare, tenere traccia delle dipendenze e fare il debug dello stato su più servizi esterni diventa rapidamente ingestibile. La soluzione strutturale a questo problema è vedere la tua applicazione come un grafo di function call indipendenti, un concetto noto in Prompt Flow come Flow e architettura DAG. Un flow è semplicemente un workflow eseguibile. In sostanza, un'applicazione LLM è una sequenza orchestrata di chiamate esterne tenute insieme dalla logica. Potresti chiamare un motore di ricerca, fare una query su un database, eseguire uno script Python per formattare i dati recuperati e infine inviare un prompt a un LLM. Prompt Flow modella questa sequenza come un Directed Acyclic Graph, o DAG. In questo grafo, ogni singolo passaggio della tua applicazione è un nodo, e le connessioni tra questi nodi rappresentano il flusso di dati. È diretto perché i dati si muovono in avanti da una funzione all'altra, ed è aciclico perché il percorso dei dati non crea un loop su se stesso. Considera una semplice applicazione che risponde a domande basandosi sui dati interni aziendali. L'utente fa una domanda, che funge da input iniziale. Questo input fluisce nel primo nodo, una funzione Python che esegue una query sul database. Il database restituisce un blocco di testo. Questo testo, insieme alla domanda originale dell'utente, passa al nodo successivo, che effettua la chiamata vera e propria all'LLM. L'LLM genera una risposta, che diventa l'output finale dell'intero grafo. Strutturando l'app in questo modo, ogni funzione è rigorosamente isolata. Sai esattamente cosa è entrato nella chiamata al database e cosa è uscito, prima ancora che l'LLM venisse triggerato. Quando si costruiscono questi workflow, gli sviluppatori spesso incontrano due termini e si chiedono quale sia il migliore: Flex flow e DAG flow. Ed è qui che la cosa si fa interessante. Entrambi ottengono esattamente lo stesso risultato. Offrono semplicemente una developer experience diversa. Il Flex flow è un approccio code-first. Incapsuli la tua logica all'interno di una funzione o di una classe Python standard, la imposti come entry point e scrivi raw code. Prompt Flow si limita a eseguirlo. Il DAG flow, d'altra parte, definisce il routing utilizzando un file YAML. Elencando esplicitamente le funzioni come nodi e collegando i loro input e output nel file YAML, permetti alla piattaforma di renderizzare una rappresentazione visiva della tua applicazione. I DAG flow sono molto UI-friendly, il che rende facile ispezionare l'architettura a colpo d'occhio. Se scegli l'approccio DAG flow, lavorerai con tre tipi specifici di flow. Il primo è lo Standard flow. Questa è la tua pipeline general-purpose in cui colleghi tool, codice Python e modelli per creare le classiche applicazioni. Il secondo è il Chat flow. Questo si basa direttamente sullo Standard flow, ma è pensato specificamente per le applicazioni conversazionali. Aggiunge il supporto nativo per la gestione della chat history e configura automaticamente gli input e gli output necessari per la chat. Il terzo tipo è l'Evaluation flow. Non usi questo flow per servire gli utenti finali. Al contrario, esegui un Evaluation flow sugli output dei tuoi Standard o Chat flow. Funge da meccanismo di testing per calcolare metriche come l'accuratezza fattuale o la pertinenza, basandosi sui dati prodotti dal tuo flow principale. Che tu definisca la tua logica in puro Python o che tu la colleghi visivamente con YAML, la tua applicazione LLM alla fine è solo una pipeline che fa il routing del testo tra sistemi esterni. Padroneggia il grafo e avrai il controllo dell'applicazione. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Prompt Flow: La Guida Completa, episodio 3 di 14. Hai progettato il workflow perfetto per la tua applicazione AI, ma un semplice blueprint da solo non elabora i dati. Hai bisogno di componenti che eseguano effettivamente il lavoro, come recuperare URL, formattare string e chiamare API. Se i flow sono il blueprint della tua applicazione, i tool sono i mattoni. Oggi parleremo dei Tool. In Prompt Flow, i tool sono i blocchi costitutivi fondamentali ed eseguibili di un flow. Ogni node nel tuo graph è un tool. Quando il tuo flow viene eseguito, si limita a passare i dati da un tool all'altro. Anche se puoi estendere la piattaforma, ci sono tre tool built-in che userai in quasi tutti i progetti: il Python tool, il Prompt tool e l'LLM tool. Vediamo uno scenario pratico per capire come si integrano. Vuoi un'applicazione che recuperi una pagina web, formatti il testo grezzo e generi un riepilogo. Per prima cosa, devi ottenere il contenuto della pagina web. Usi il Python tool. Questo tool ti permette di scrivere script Python personalizzati e fa da ponte verso il mondo esterno. Scrivi un breve script che prende un URL come input, fa una richiesta HTTP e restituisce il testo grezzo della pagina. Il Python tool gestisce l'esecuzione e passa quel testo grezzo al passaggio successivo come output. Successivamente, devi preparare le istruzioni per il modello linguistico. Usi il Prompt tool. Questo tool prende degli input di testo, come il testo grezzo dal tuo Python tool e un system prompt che definisce la persona dell'AI, e li formatta in un'unica string pulita. Questa è la parte importante. Il Prompt tool non chiama un modello AI. Si limita a preparare e formattare il testo. Separare questo passaggio rende il tuo flow molto più facile da leggere e testare, soprattutto quando hai a che fare con prompt complessi e composti da più parti. Infine, invii quella string preparata al modello usando l'LLM tool. Questo tool gestisce la connessione effettiva a un endpoint del Large Language Model. Gli passi la string formattata dal tuo Prompt tool, configuri i parametri del modello come la temperature, e lui ti restituisce il riepilogo generato. L'LLM tool fa il lavoro pesante di formattare il payload dell'API e interagire con il provider. Anche se questi tre coprono la maggior parte dei casi d'uso principali, non sono le tue uniche opzioni. Prompt Flow supporta partner tool forniti da terze parti. Un esempio comune è il tool Vector DB Lookup, che cerca nei database vettoriali testi simili basandosi sugli embedding. Puoi anche installare pacchetti personalizzati o creare i tuoi tool per integrazioni molto specifiche. Indipendentemente dalla loro origine, funzionano tutti esattamente con lo stesso principio: prendono degli input, eseguono una funzione specifica e restituiscono un output. La cosa più importante da ricordare è la rigorosa separation of concerns. Non scrivere codice Python per formattare i prompt e non usare l'LLM tool per concatenare string. Usare il giusto tool built-in per il suo scopo esatto mantiene i tuoi graph puliti e debuggable. Grazie per averci fatto compagnia. Spero tu abbia imparato qualcosa di nuovo.

Ciao, sono Alex di DEV STORIES DOT EU. Prompt Flow: La Guida Completa, episodio 4 di 14. Niente rovina un deploy in produzione più velocemente di una API key committata per sbaglio nel version control. Anche se eviti questo disastro, gestire le credenziali tra ambienti di sviluppo in locale e in cloud spesso porta a file di configurazione intricati e rischi per la sicurezza. Gestire i secret tramite le connection risolve questo problema, isolando completamente i tuoi dati sensibili dalla logica del tuo flow. Una connection in Prompt Flow è una risorsa dedicata che memorizza gli endpoint e le credenziali necessarie per interagire con servizi esterni. Se il tuo flow deve chiamare un language model esterno, fare una ricerca sul web usando un servizio esterno o interrogare un database remoto, ha bisogno di autorizzazione. Invece di scrivere le API key direttamente nei tuoi script Python o nei file di configurazione, crei una connection. Il tuo flow farà quindi riferimento a quella connection tramite il suo nome. Usando le connection, disaccoppi i tuoi dati segreti dalla logica di esecuzione. Il tuo codice sa solo di aver bisogno di una connection chiamata, ad esempio, main_language_model. Non conosce la vera API key. Vediamo come funziona quando sposti un progetto dal tuo laptop al cloud. Quando sviluppi in locale, le tue connection vengono salvate sul tuo disco locale. Per mantenere la sicurezza, Prompt Flow cripta i valori dei secret usando una encryption key locale. Puoi buildare e testare il tuo flow usando questo setup locale senza lasciare chiavi in chiaro esposte nella tua working directory. Quando sei pronto a fare il deploy di questo flow su Azure AI, l'ambiente cambia, ma il tuo codice no. In Azure AI, le connection si appoggiano in modo sicuro ad Azure Key Vault. I secret vengono salvati e gestiti all'interno dell'infrastruttura di Key Vault, protetti da rigide access policy. Questa è la parte importante. Dato che il tuo flow fa riferimento alla connection solo tramite il suo nome, il passaggio da un ambiente locale al cloud richiede zero modifiche alla logica del tuo flow. Ti basta assicurarti che esista una connection con lo stesso nome nel tuo workspace di Azure. Quando il flow gira in cloud, richiede main_language_model. Il sistema intercetta la richiesta in modo trasparente e fornisce le credenziali prese da Key Vault invece di quelle criptate in locale. Il tuo codice rimane pulito e environment-agnostic. Prompt Flow divide queste connection in due tipi principali. Il primo sono le strongly typed connection. Si tratta di template built-in per servizi molto usati come Azure OpenAI. Forniscono campi predefiniti per l'URL dell'endpoint, la API key e il tipo di API. Il sistema sa esattamente come gestire questi campi, il che rende semplice la configurazione dei tool standard. Il secondo tipo è la custom connection. Quando devi integrare una API aziendale interna o un servizio di terze parti a cui manca un template built-in, usi una custom connection. Questa funziona come un dizionario flessibile in cui definisci le tue coppie chiave-valore. Puoi marcare esplicitamente chiavi specifiche come secret. Una volta marcati, questi custom secret ricevono esattamente la stessa encryption locale e la stessa protezione di Key Vault delle connection built-in. Il vero valore delle connection è che fungono da rigoroso abstraction layer per l'autenticazione, garantendo che il tuo flow rimanga completamente portabile e i tuoi secret restino al sicuro in qualsiasi ambiente di esecuzione. Questo è tutto per questo episodio. Grazie per l'ascolto, e continuate a buildare!

Ciao, sono Alex di DEV STORIES DOT EU. Prompt Flow: La Guida Completa, episodio 5 di 14. Smettila di seppellire i prompt del tuo language model dentro enormi stringhe Python. Quando fai l'hardcode dei prompt nella logica della tua applicazione, tracciare le modifiche, eseguire test standalone e collaborare con i prompt engineer diventa un vero incubo. La soluzione è la Prompty Specification. Un Prompty è un formato standard per la gestione dei prompt. Sposta il tuo prompt fuori dal codice e dentro un singolo file markdown sotto controllo di versione, con estensione punto prompty. Il file è diviso in due sezioni distinte. In alto, hai il front matter YAML. In basso, hai un prompt template formattato in Jinja. Tre trattini separano le due parti. Il blocco YAML funge da centro di controllo. Puoi definire i metadati di base come il nome, la descrizione e l'autore. Cosa ancora più importante, contiene la configurazione del model. Specifichi il tipo di API, come chat o completion. Definisci i dettagli di configurazione, come puntare a un deploy Azure OpenAI di GPT-3.5. Fissi anche i parametri del model proprio qui. Se un prompt specifico richiede una temperature di zero virgola sette e un limite di max token di mille, lo dichiari nello YAML. Questo lega i setting di esecuzione direttamente al testo del prompt, assicurando che il prompt si comporti in modo coerente ovunque venga usato. La sezione YAML definisce anche gli input e i sample data. Se il tuo prompt si aspetta una variabile dinamica, la elenchi qui e fornisci dei sample value. Questo rende il file completamente self-contained. Chiunque lo apra sa esattamente quali dati si aspetta senza dover fare reverse-engineering del codice della tua applicazione. Sotto lo YAML e i tre trattini si trova il prompt template vero e proprio. Questa sezione usa la sintassi Jinja2 per iniettare dinamicamente gli input che hai definito sopra. Dato che i moderni language model usano interfacce chat, il template supporta l'assegnazione dei ruoli. Definisci i ruoli usando un semplice formato di testo, separando le istruzioni di system dagli input dello user. Considera uno scenario di chat minimale in cui vuoi un prompt che saluti un utente con il suo first name. In cima al tuo file punto prompty, scrivi il front matter YAML. Definisci la sezione del tuo model, impostando il tipo di API su chat e puntando la configurazione a un deploy di GPT-3.5. Poi, aggiungi una sezione inputs dichiarando una variabile chiamata first name. Aggiungi anche un blocco sample dove first name è impostato su Jane. Digiti tre trattini per terminare il front matter YAML. Ora costruisci il template. Digiti la parola system seguita da due punti, poi dai al model le sue istruzioni di base, come dirgli di essere un assistente utile. Lì sotto, digiti la parola user seguita da due punti. Infine, scrivi il saluto, racchiudendo la variabile first name tra doppie parentesi graffe in modo che il motore Jinja sappia dove iniettare il testo. Ora hai un asset completo e riutilizzabile. Trattare i prompt come file self-contained anziché come stringhe sparse nel tuo codice è il primo passo verso un rigoroso prompt engineering, perché impone un contratto chiaro tra l'applicazione che fornisce i dati e il language model che genera la risposta. Grazie per aver passato qualche minuto con me. Alla prossima, stammi bene.

Ciao, sono Alex di DEV STORIES DOT EU. Prompt Flow: La Guida Completa, episodio 6 di 14. Crei un prompt template accuratamente ottimizzato per la produzione, ma quando vuoi testarlo con un modello più economico o regolare la temperatura per uno specifico edge case, ti ritrovi a modificare manualmente il file sorgente. Un template statico crea attrito quando il tuo ambiente o la tua logica devono cambiare al volo. Questo attrito è esattamente ciò che la Dynamic Prompty Execution è progettata per eliminare. Un asset Prompty in genere definisce le impostazioni del modello, come il deployment name, la connessione API e i parametri, all'interno del suo header block. Tuttavia, hardcodare questi valori limita il modo in cui puoi utilizzare il file in ambienti diversi. L'esecuzione dinamica ti consente di trattare il file Prompty come un base layer flessibile, facendo l'override delle sue configurazioni direttamente in Python o da command line a runtime. Per eseguire un file Prompty in Python, usi la funzione load prompty della core library di Prompt Flow. Passi il file path a questa funzione, e lei ti restituisce un callable object in memoria. Per eseguirlo, ti basta chiamare quell'oggetto, passando le variabili del prompt come standard keyword arguments. La libreria gestisce la compilazione e la chiamata API, restituendo l'output di testo finale. È proprio a questo punto che l'esecuzione dinamica dimostra il suo valore. Puoi intercettare l'esecuzione per fare l'override delle impostazioni del modello senza toccare il file sottostante. Supponi di avere un Prompty configurato per un deployment standard di Azure OpenAI, ma per uno specifico batch job, devi puntarlo verso un endpoint Azure diverso e alzare la temperatura per ottenere risposte più varie. Invece di duplicare il file, definisci un dizionario nel tuo codice Python contenente le tue nuove impostazioni. Aggiungi il tuo endpoint alternativo e il tuo nuovo valore di temperatura a questo dizionario. Poi, quando chiami il tuo oggetto Prompty caricato, passi questo dizionario al keyword argument model, insieme ai tuoi standard prompt inputs. Il runtime di Prompt Flow fa il merge del tuo dizionario con la configurazione del file di base. I tuoi override dinamici hanno la precedenza, il prompt viene eseguito con le nuove impostazioni e il file originale rimane completamente invariato. Questo ti permette di scambiare le API keys, cambiare i max tokens, o reindirizzare il target del modello programmaticamente in base allo stato della tua applicazione. A volte, non hai voglia di scrivere uno script Python solo per vedere se un prompt produce un buon risultato. Per una validazione rapida, puoi testare un file Prompty direttamente dal tuo terminale. Usi il comando pf flow test, fornendo il path del tuo file tramite il flag source. Puoi aggiungere il flag inputs per passare le tue variabili direttamente nel comando come coppie key-value. La command line interface esegue il Prompty e stampa la risposta del modello direttamente sullo standard output. Questo ti dà un feedback loop immediato durante lo sviluppo senza dover scrivere del wrapper code. Il vero valore di un asset Prompty non sta nel bloccare le configurazioni, ma nell'isolare il testo del prompt dall'ambiente di esecuzione. Iniettando dinamicamente gli override del modello a runtime, un singolo file può servire senza problemi la tua sandbox di test locale, le tue automated pipelines e i tuoi endpoint di produzione. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Prompt Flow: La Guida Completa, episodio 7 di 14. Potresti pensare che usare un framework specializzato per i Large Language Models significhi imparare una complessa interfaccia visiva o mantenere enormi file di configurazione. Ma se sai già scrivere uno script Python, sai già abbastanza per creare un'applicazione completamente tracciabile. I Flex Flow basati su funzioni risolvono completamente questo problema. Nello sviluppo standard con Prompt Flow, costruisci un Directed Acyclic Graph. Questa struttura è molto efficace per pipeline rigide e multi-step, ma a volte gli sviluppatori vogliono scrivere codice Python puro senza doversi adattare a un sistema visivo a nodi. I Flex Flow ti permettono di fare esattamente questo. Incapsuli la logica della tua applicazione LLM all'interno di funzioni Python standard, e la piattaforma gestisce il tracking e l'orchestrazione in background. Considera l'approccio basato su funzioni. Inizi scrivendo una normale funzione Python. Le dai un nome descrittivo, come chat, e definisci i suoi input, ad esempio accettando una domanda come parametro string. All'interno di questa funzione, scrivi la tua logica proprio come faresti di solito. Potresti caricare un file Prompty per ottenere il tuo system message, inizializzare il client del tuo language model, passare la domanda al modello, e poi restituire la risposta di testo come string. A questo punto, hai semplicemente uno script Python standard. Gira in locale, è facile da testare e non richiede conoscenze specifiche del framework. Per trasformare questo script Python puro in un componente Prompt Flow tracciabile, importi il decorator trace dal package di tracing di promptflow. Posizioni questo decorator direttamente sopra la tua funzione chat. Quando esegui il tuo codice, questo decorator dice al sistema di monitorare l'esecuzione in modo silenzioso. Registra automaticamente gli input passati alla funzione, l'output di testo restituito, il tempo di esecuzione esatto e qualsiasi errore interno. Se applichi il decorator trace ad altre helper function all'interno del tuo script, il sistema costruisce un call tree completo. Ottieni la piena observability di un flusso visivo, inclusa la possibilità di visualizzare l'execution trace nella user interface locale, senza cambiare il modo in cui strutturi la tua logica. Ora, il tooling ha bisogno di un modo per sapere che questa specifica funzione è l'entry point della tua applicazione. Lo fai creando un singolo, brevissimo file di configurazione chiamato flow.flex.yaml nella stessa directory del tuo codice. Questo file non definisce un grafo di routing complesso. Ha bisogno solo di un'informazione fondamentale, ovvero l'entry mapping. Scrivi la parola entry seguita dal nome del tuo modulo Python, due punti, e il nome della tua funzione. Se il tuo file si chiama app.py e la tua funzione è chat, il tuo valore di entry è semplicemente app due punti chat. Quando testi o esegui questo flusso usando il command line tool di Prompt Flow o l'estensione di VS Code, il sistema legge quel file yaml. Cerca la funzione chat nel tuo modulo app, inietta gli input forniti, esegue il tuo codice Python puro e raccoglie le trace generate dal decorator. Il vero potere dei flex flow basati su funzioni è che rimuovono l'attrito tra la prototipazione di uno script e il deploy di un'applicazione in produzione; la tua logica Python pura rimane completamente sotto il tuo controllo, mentre un singolo decorator e un file di configurazione di due righe sbloccano un'observability di livello enterprise. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a costruire!

Ciao, sono Alex di DEV STORIES DOT EU. Prompt Flow: La Guida Completa, episodio 8 di 14. Fai il deploy di una nuova app basata su un language model, ma ogni volta che un utente invia un messaggio, ci vogliono secondi preziosi solo per stabilire la connessione al database e caricare le credenziali del client. Quando la tua applicazione deve mantenere una connessione persistente o ricordare la chat history, uno script standalone fallisce perché riparte completamente da zero a ogni run. La soluzione a questo problema è Flex Flows: Sviluppo Basato su Classi. Quando crei applicazioni che scalano, lo state management diventa una preoccupazione primaria. Se il tuo flow si basa su una risorsa esterna, come un client Azure OpenAI, l'inizializzazione di questo client richiede la lettura dei secrets, la verifica degli endpoint e l'allocazione di memoria. Se inserisci questa logica all'interno di una sequenza di esecuzione base, paghi questo pesante costo di startup ogni singola volta che arriva una richiesta. Usare una classe Python come entry point per il tuo Flex Flow ti permette di separare nettamente la logica di inizializzazione dalla logica di esecuzione. Un flow basato su classi si affida a due metodi Python standard per gestire questo lifecycle. Il primo è il costruttore, o metodo init. Questa è la tua fase di setup. Prompt Flow esegue questo metodo esattamente una volta quando il flow viene caricato in memoria per la prima volta. È qui che fai tutto il lavoro pesante. Il secondo metodo è il metodo call. Questa è la tua fase di esecuzione, e gira ogni volta che il flow viene attivato da una richiesta dell'utente. Immagina una classe per un chat flow. Definisci il tuo metodo init in modo che accetti un oggetto connection di Azure OpenAI e una stringa di system prompt. All'interno del metodo init, crei il tuo client Azure OpenAI e lo salvi come property sull'istanza della classe stessa. Il client ora è pronto e in attesa. Successivamente, definisci il tuo metodo call. Questo metodo accetta una nuova domanda dell'utente e una lista di messaggi passati che rappresentano la chat history. Dato che il client è già completamente inizializzato, il metodo call formatta immediatamente il prompt, invia la chat history al language model e restituisce la response. L'esecuzione è veloce perché il costoso setup del client è stato completamente bypassato. Per far funzionare tutto questo, Prompt Flow deve sapere come istanziare la tua classe. Puoi configurarlo creando un file YAML per il tuo flow. L'entry point in questo file di configurazione usa un formato specifico, indicando il modulo Python seguito da due punti e dal nome della tua classe. Questa è la parte che conta. La tua configurazione YAML non si limita a puntare alla classe, ma definisce i parametri richiesti dal tuo metodo init. Se il costruttore della tua classe richiede una connection di Azure e il nome di un modello, dichiari questi input nel file YAML sotto una sezione init dedicata. Quando l'engine di Prompt Flow si avvia, legge il file YAML, inietta quei parametri configurati nel costruttore della tua classe, e poi mantiene quell'oggetto istanziato vivo in memoria per gestire le call in arrivo. Testare un flow basato su classi in locale è incredibilmente semplice perché si basa sul comportamento standard di Python. Non hai bisogno di un framework di test complesso. Ti basta scrivere un normale script Python, importare la tua classe, creare un'istanza passando delle mock connection o credenziali locali al costruttore, e poi invocare direttamente l'oggetto passandogli un messaggio di test. Puoi fare il debug della logica di setup e della logica di esecuzione in modo indipendente. Il concetto fondamentale è che i flow basati su classi ti offrono la struttura architetturale per separare il lavoro pesante di inizializzazione dal lavoro ripetitivo di esecuzione, mantenendo il tuo state persistente e le tue response veloci. Se trovi utili questi episodi e vuoi supportare il podcast, puoi cercare DevStoriesEU su Patreon. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Prompt Flow: La Guida Completa, episodio 9 di 14. A volte, fissare un muro di codice non basta per comprendere un'applicazione complessa. Quando prompt, script e chiamate API interagiscono in decine di modi diversi, devi vedere fisicamente i dati che si muovono tra di loro per individuare i colli di bottiglia. I DAG flow sono la risposta per i team che vogliono una chiarezza architetturale esplicita. DAG sta per Directed Acyclic Graph, ovvero grafo aciclico diretto. In Prompt Flow, un DAG flow è un metodo per creare applicazioni AI collegando diversi tool tra loro come nodi. Invece di scrivere un unico grande script, definisci la struttura della tua applicazione in un file chiamato flow punto dag punto yaml. Questo file funge da blueprint principale. Dichiara gli input iniziali, i singoli step e gli output finali della tua applicazione. Ogni step in un DAG flow è chiamato nodo. Un nodo rappresenta un tool specifico che esegue un singolo task. Potresti avere un nodo che esegue uno snippet Python, un altro nodo che formatta un prompt e un terzo nodo che chiama un Large Language Model. Il file YAML descrive come questi nodi sono correlati tra loro tramite dipendenze di input e output. Questa mappatura delle dipendenze è ciò che fa funzionare il flow. Non devi dire manualmente al sistema in che ordine eseguire gli step. Invece, specifichi che il nodo B richiede l'output del nodo A. Dato che il nodo B non può partire finché il nodo A non finisce, si forma naturalmente un ordine di esecuzione. Se aggiungi un nodo C che dipende solo dall'input iniziale dell'utente, Prompt Flow riconoscerà che non ha bisogno di aspettare il nodo A o B. Eseguirà il nodo C in parallelo automaticamente. L'engine legge il file yaml, risolve il grafo e gestisce l'orchestrazione. Scrivere e mantenere a mano questo file yaml può diventare difficile man mano che la tua applicazione cresce. Ecco perché la maggior parte degli sviluppatori usa l'estensione Prompt Flow di VS Code. Questa estensione legge il tuo file flow punto dag punto yaml e renderizza un'interfaccia utente visuale drag-and-drop. Puoi vedere la tua applicazione letteralmente come una mappa di blocchi collegati. Considera uno scenario concreto. Stai costruendo un'applicazione per leggere report finanziari e scrivere dei brevi executive summary. Nell'editor visuale, crei un nodo tool Python e lo chiami Extract Text. Lì di fianco, aggiungi un nodo tool LLM chiamato Summarize. Invece di scrivere codice per gestire lo state tra queste due operazioni, usi l'interfaccia. Clicchi sulla porta di output del nodo Extract Text e trascini una linea fino alla porta di input del nodo Summarize. Hai appena cablato visivamente il percorso dei dati. L'estensione aggiorna istantaneamente il file yaml sottostante per registrare la connessione. Ottieni la velocità e la chiarezza di un builder low-code visuale, ma generi comunque un file di configurazione in plain text che puoi tracciare nel version control. Questo approccio visuale impone disciplina architetturale. Il grafo è aciclico, il che significa che i dati possono fluire solo in avanti. Non ci sono loop infiniti. I dati entrano, passano attraverso la tua sequenza di tool ed escono. Questo flow rigorosamente direzionale semplifica il debugging. Se un summary finale sembra sbagliato, puoi aprire il grafo visuale, cliccare sulla connessione tra i nodi di estrazione e summarization, e ispezionare l'esatta string di testo che è passata attraverso quel cavo. Sai esattamente da dove sono arrivati i dati e dove sono andati. Il vero vantaggio di un DAG flow è che il diagramma dell'architettura di sistema e la tua applicazione eseguibile sono esattamente la stessa cosa. Questo è tutto per questo episodio. Grazie per aver ascoltato, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Prompt Flow: La Guida Completa, episodio 10 di 14. Quando un modello linguistico restituisce una risposta allucinata e senza senso, come fai a sapere se ha fallito il modello stesso, o se c'era un bug nella logica di formattazione del tuo prompt? Puoi spargere print statement per tutta la tua applicazione, ma diventa impossibile da mantenere man mano che l'applicazione cresce. Il tracing delle interazioni LLM risolve questo problema catturando il contesto esatto di ogni esecuzione. Il tracing trasforma un'applicazione LLM black-box in una sequenza di eventi trasparente e debuggabile. Registra con precisione quali dati entrano in una funzione, cosa ne esce e quanto tempo impiega l'esecuzione. In questo ecosistema, gestisci tutto questo con il package promptflow-tracing. I dati che genera si basano sulla specifica OpenTelemetry, il che significa che i tuoi record di esecuzione seguono un formato standard di settore per l'observability. Per catturare le interazioni di base con un modello, usi una funzione chiamata start trace. Se chiami questa funzione proprio all'inizio del tuo script Python, Prompt Flow strumenta automaticamente i client dei modelli supportati. Ad esempio, se stai usando il package Python standard di OpenAI, non devi modificare minimamente le tue API call. Il tracer intercetta silenziosamente l'interazione, registrando il system message, lo user prompt, i parametri specifici del modello e la response string finale. Catturare l'API call è solo metà del lavoro. La logica che precede quella chiamata è solitamente il punto in cui si nascondono i bug. Per fare il tracing della logica della tua applicazione, applichi il decorator trace alle tue funzioni personalizzate. Considera una funzione chiamata math to code. Questa funzione prende la descrizione di un problema matematico da parte di un utente, recupera il context necessario, costruisce un prompt e infine richiede del codice Python a GPT-4. Posizionando il decorator trace direttamente sopra la definizione della funzione math to code, dici a Prompt Flow di registrare ogni esecuzione di questo specifico blocco di logica. Registrerà l'input string dell'utente, il codice finale restituito e la latenza dell'intera operazione. Poiché hai anche eseguito start trace in cima al tuo file, il sistema comprende la relazione tra il tuo codice e la model call. Costruisce un record gerarchico. La tua funzione math to code diventa il parent span, e la call interna a OpenAI diventa un child span annidato al suo interno. Puoi visualizzare questa gerarchia usando la Trace UI locale. Quando esegui un traced script, Prompt Flow avvia un server locale che puoi aprire nel tuo web browser. Questa interfaccia ti fornisce una timeline visiva del tuo application flow. Puoi selezionare il parent span math to code per verificare gli argomenti che ha ricevuto. Poi, puoi selezionare il child span di OpenAI per ispezionare l'esatta raw prompt string che è stata inviata con successo al modello tramite la rete. Se la tua logica di context assembly ha mancato una variabile, vedrai immediatamente lo spazio vuoto nel raw prompt. Il vero potere del tracing non sta solo nel raccogliere gli execution log, ma nel dimostrare in modo definitivo cosa è successo esattamente al confine tra il tuo application code e il modello esterno. Questo è tutto per questo episodio. Grazie per aver ascoltato, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Prompt Flow: La Guida Completa, episodio 11 di 14. Hai appena passato tre mesi a sviluppare un'applicazione complessa usando LangChain. La logica funziona quasi sempre, ma quando un agent occasionalmente entra in un bad loop o perde il context, scoprire esattamente dove ha perso il filo è un incubo, e riscrivere tutto solo per avere dei log migliori è assolutamente fuori discussione. L'Advanced Tracing per LangChain e AutoGen è come risolvi direttamente questo problema. Quando sviluppi con dei framework di orchestrazione, guadagni velocità grazie all'astrazione. Il framework nasconde i dettagli noiosi della sequenza dei prompt, dell'esecuzione dei tool e del parsing. Ma l'astrazione crea inevitabilmente una black box. Quando il tuo agent restituisce una risposta confusa, devi vedere la sua chain of thought interna. Devi sapere esattamente quale sub-prompt ha generato, la risposta API raw che ha ricevuto e quale specifica tool call è fallita. Prompt Flow include una funzionalità di tracing standalone progettata proprio per questo. Non ti obbliga a usare Prompt Flow per la tua logica o per l'esecuzione. Mantieni il tuo codice LangChain o AutoGen esistente esattamente com'è. Stai solo collegando il sistema di tracking di Prompt Flow alla tua applicazione esterna. Pensa al tuo script Python esistente che esegue un agent LangChain. Per avere piena visibilità, non tocchi le definizioni delle tue chain. Vai semplicemente in cima al tuo file di esecuzione principale. Importi la funzione di setup del trace dal modulo prompt flow e la chiami una volta sola prima che il tuo agent inizi a lavorare. Quel singolo comando è l'intera integrazione. Quando chiami quella funzione, questa strumenta il tuo ambiente. Dato che il tracing di Prompt Flow è basato sugli standard OpenTelemetry, sa come ascoltare gli eventi specifici scatenati da questi framework popolari. Mentre la tua applicazione LangChain è in esecuzione, la strumentazione intercetta automaticamente le chiamate API sottostanti. Cattura gli input, la durata dell'esecuzione, gli output e l'utilizzo dei token per ogni step. Questo si applica perfettamente anche ad AutoGen. I setup multi-agent in AutoGen sono notoriamente difficili da debuggare perché più agent si scambiano messaggi in modo autonomo. Tracciare chi ha passato quale context a chi, di solito significa scavare attraverso enormi muri di testo nel terminale. Inizializzando il trace in cima al tuo script AutoGen, ogni singolo scambio di messaggi viene automaticamente catturato e strutturato. Una volta che il tuo script ha finito l'esecuzione, apri la UI locale di Prompt Flow Trace. Invece di scorrere i print nella console, ottieni una timeline visiva. Vedi un chiaro albero di esecuzione. Clicchi sulla run dell'agent di livello superiore, espandi il nodo e vedi la sequenza di chiamate LLM annidate e di esecuzioni dei tool. Se un agent ha avuto un'allucinazione allo step quattro, puoi cliccare direttamente sullo step quattro per leggere il testo esatto e non formattato che è stato inviato al modello. Ottieni una visibilità completa su un framework opaco senza dover migrare una singola riga della tua effettiva business logic. Il vero vantaggio qui è la libertà architetturale; puoi orchestrare la tua applicazione usando il framework che si adatta meglio al tuo team, mantenendo al contempo il debug e l'osservabilità centralizzati in un'unica interfaccia visiva e pulita. Come sempre, grazie per l'ascolto. Ci vediamo al prossimo episodio.

Ciao, sono Alex di DEV STORIES DOT EU. Prompt Flow: La Guida Completa, episodio 12 di 14. Il tuo prompt ha funzionato perfettamente sulla tua domanda di test, ma cosa succede quando lo esegui su diecimila query di utenti reali? Di solito si rompe. Testare un prompt manualmente con due esempi è facile, ma dimostrare che funziona su centinaia di edge case richiede qualcosa di più robusto. È qui che entra in gioco Scaling Up: Batch Run con i Dati. Un batch run prende il tuo singolo flow e lo esegue su un ampio dataset. Questo ti permette di passare dalla creazione della logica alla sua verifica su larga scala. Invece di digitare gli input in una user interface, avvii questo processo usando la command line interface. Il comando principale è pf run create. Eseguendolo, indichi a Prompt Flow di avviare una nuova istanza di run, leggere una specifica directory del flow e passargli un file che contiene tutti i tuoi record di test. L'engine elabora questi record eseguendo l'intero graph del flow in modo indipendente per ogni singola riga del tuo dataset. Il formato dati richiesto per questo file di input è JSONL. JSONL sta per JSON Lines. Se sei abituato al JSON standard, potresti aspettarti un singolo grande array che racchiude tutti i tuoi oggetti. JSONL elimina l'array. Ogni singola riga nel file di testo è un oggetto JSON valido e indipendente, che rappresenta esattamente un test case. Questo formato è molto apprezzato nel machine learning e nelle data pipeline perché è leggero e si presta facilmente allo streaming. L'engine può leggerlo riga per riga senza caricare un file enorme in memoria tutto in una volta. Considera un flow di classificazione web. Il tuo flow è progettato per prendere un indirizzo web, fare scraping del contenuto e usare un language model per categorizzarlo. Il graph del flow si aspetta una specifica stringa di input chiamata url. Vuoi testare questa logica su cento siti web diversi per vedere come gestisce gli edge case. Costruisci il tuo file JSONL. Ogni riga contiene un oggetto JSON con una chiave, magari chiamata web link, che contiene l'indirizzo di destinazione. Per avviare il batch run, digiti pf run create. Specifichi la directory del tuo flow usando il flag flow, e punti al tuo file JSONL usando il flag data. Ma c'è un'immediata incongruenza strutturale. La logica del tuo flow richiede rigorosamente un input chiamato url, mentre il tuo file dati fornisce un campo chiamato web link. Se esegui il comando in questo momento, fallirà. L'engine non indovina quali campi dati appartengono a quali input del flow. Colmi questa lacuna usando il flag di column mapping. Questo flag dice all'execution engine esattamente come collegare le chiavi nel tuo file JSONL agli specifici nodi di input del tuo flow. Negli argomenti della tua command line, scrivi il nome dell'input del flow, un segno di uguale, e poi un riferimento alla colonna dei dati. Prompt Flow usa una specifica sintassi di binding per questi riferimenti. Scrivi un segno del dollaro, seguito dalla parola data, un punto, e poi il nome della colonna dal tuo file. Per lo scenario di classificazione web, lo mappi scrivendo url uguale segno del dollaro data punto web link. Questa istruzione esplicita associa il campo dati al requisito del flow. L'engine ora estrarrà la stringa web link dalla riga uno del tuo file JSONL e la inietterà nell'input url del tuo flow. Poi ripete quell'esatto processo per la riga due, la riga tre, e così via finché l'intero file non è stato elaborato. Puoi mappare input multipli in questo modo. Se il tuo flow si aspetta un url e uno user id, aggiungi semplicemente un'altra istruzione di mapping allo stesso comando. Disaccoppiare i tuoi dati di test dagli input del tuo flow usando un column mapping esplicito significa non dover mai alterare il tuo codice principale solo per eseguire un nuovo dataset. Grazie per aver passato qualche minuto con me. Alla prossima, stammi bene.

Ciao, sono Alex di DEV STORIES DOT EU. Prompt Flow: La Guida Completa, episodio 13 di 14. Non puoi scrivere un unit test standard per verificare che la risposta di un Large Language Model sia uguale a una string esatta. Se l'output cambia ogni volta, come puoi dimostrare matematicamente che la tua applicazione funziona davvero prima di fare il deploy? La risposta è l'Evaluation Paradigm. Nel software engineering tradizionale, lo unit testing è deterministico. Passi un input specifico a una funzione e ti aspetti un output esatto. I Large Language Model sono stocastici. Sono intrinsecamente imprevedibili. Chiedi a un modello di classificare una pagina web, e potrebbe darti in output la parola sport, oppure potrebbe dire che la categoria è sport, o magari darti semplicemente un'emoji correlata. Una test assertion standard fallirà in due casi su tre, anche se il modello ha fondamentalmente dato la risposta corretta. Per dimostrare di essere pronto per la release, devi andare oltre gli unit test e abbracciare la valutazione statistica. In Prompt Flow, questo viene gestito da un Evaluation Flow. Un Evaluation Flow è solo un flow normale, ma invece di generare testo per un utente finale, il suo unico compito è valutare l'output di un altro flow. Prende le prediction generate dalla tua applicazione principale, le confronta con un set noto di risposte corrette e dà in output delle metriche calcolate. Facciamo un esempio concreto. Mettiamo che tu abbia appena finito una batch run di un flow di classificazione web. Ha elaborato cento indirizzi web e ha dato in output una categoria predetta per ciascuno. Ora devi sapere esattamente quanto siano accurate quelle prediction. Prendi gli output di quella base run e li passi a un nuovo Evaluation Flow dedicato, progettato per calcolare l'accuratezza della classificazione. Lo avvii dalla command line usando il comando run create. Specifichi il tuo Evaluation Flow, ma invece di dargli semplicemente un file statico di nuovi input, gli passi una reference alla tua batch run precedente. L'Evaluation Flow ha bisogno di due informazioni per fare il suo lavoro. Ha bisogno della prediction del modello, e ha bisogno della ground truth, che è la risposta storicamente corretta. Fornisci un data mapping che collega questi punti. Dici al sistema di mappare l'input di prediction dell'Evaluation Flow all'output di categoria della tua base run. Poi, mappi l'input di ground truth alla colonna della true label effettiva che si trova nel tuo test dataset originale. Questa è la parte che conta. L'Evaluation Flow viene eseguito riga per riga, passando attraverso l'intera history della run precedente. Per ogni riga, guarda cosa ha predetto il tuo main flow e lo confronta con la ground truth. Assegna un punteggio per quella specifica interazione. Nel nostro scenario di classificazione, potrebbe essere un semplice uno per un match e uno zero per un miss. Altri Evaluation Flow potrebbero usare un language model per giudicare la qualità di un riassunto su una scala da uno a cinque. Una volta che il flow finisce di valutare ogni singola riga, aggrega quei punteggi individuali in una metrica finale complessiva. Non ottieni semplicemente un enorme log di uni e zeri. Ottieni un numero definitivo di alto livello, come un'accuratezza complessiva del novantadue percento. Puoi quindi visualizzare queste metriche aggregate per decidere se la versione attuale della tua applicazione è pronta per la produzione. Non devi più tirare a indovinare se una modifica al prompt ha migliorato il tuo sistema; hai la prova statistica di quanto esattamente performi meglio o peggio sull'intero dataset. Grazie per averci seguito. Alla prossima!

Ciao, sono Alex di DEV STORIES DOT EU. Prompt Flow: La Guida Completa, episodio 14 di 14. Hai creato, tracciato e valutato il flow del tuo language model, e funziona perfettamente. Ma al momento se ne sta lì nel tuo ambiente di sviluppo, completamente isolato dai tuoi utenti reali. Portarlo fuori dal tuo IDE e trasformarlo in un servizio stabile e raggiungibile è esattamente ciò di cui parleremo oggi, portando i flow in produzione. Di base, un prompt flow è semplicemente una cartella. Contiene un file YAML di configurazione e i tuoi script Python o template Jinja. Per far sì che quella cartella faccia qualcosa nel mondo reale, ti serve un execution environment che carichi quei file e si metta in ascolto delle richieste HTTP in entrata. Durante lo sviluppo, probabilmente hai usato il built-in server locale. Lanci un semplice comando e questo tira su un endpoint locale per testare input e output. Questo va bene per verificare la logica, ma non è progettato per gestire il traffico concorrente in produzione, gestire la memoria in modo efficiente o sopravvivere a un crash di sistema. Per andare in produzione, ti serve la containerizzazione. Prompt Flow è progettato per integrarsi direttamente con Docker. Invece di scrivere un web server da zero, usi il tooling di Prompt Flow per esportare il tuo flow come container Docker. Quando lanci il processo di export, il sistema genera un Dockerfile. Questo file definisce una base image, ci copia dentro la directory del tuo flow, installa le esatte dipendenze Python elencate nel tuo file requirements e configura un web server production-ready per servire il flow come API REST. Questa è la parte che conta. Una volta che il tuo flow è in un container Docker, smette di essere un esperimento speciale di machine learning e diventa un artefatto software standard. Puoi trattarlo come qualsiasi altro microservizio. Prendi uno scenario concreto. Hai un chat flow di customer support validato. Fai la build dell'immagine Docker e fai il push sul tuo container registry privato. Successivamente, fai il deploy di quell'immagine su un cluster Kubernetes. Scrivi una configurazione di deployment standard che dice a Kubernetes di tirare su tre repliche del container del tuo chat flow, e ci metti davanti un load balancer. Ora, la tua applicazione frontend invia richieste HTTP standard al load balancer, che distribuisce il traffico tra i tuoi container. Se il tuo chat flow viene sommerso dalle richieste degli utenti, Kubernetes fa semplicemente lo scale up di altre istanze del tuo flow. Se non vuoi gestire un cluster Kubernetes, quella stessa immagine Docker funziona perfettamente su managed platform services. Puoi farne il deploy direttamente su Azure App Service o su qualsiasi altro cloud provider che ospita container. Al flow non importa dove viene eseguito, purché abbia un container runtime. C'è un deployment pattern alternativo. Se non stai creando un web service, puoi distribuire un flow come applicazione eseguibile. Questo impacchetta il flow e le sue dipendenze di runtime in un file eseguibile standalone. Questo è utile se devi eseguire la logica direttamente su una macchina client o un dispositivo edge, evitando completamente la necessità di installare Python o configurare un server. Portare un prompt flow in produzione non richiede hosting proprietario o infrastrutture specializzate per il machine learning. Esportando in Docker, i flow del tuo language model si integrano perfettamente nelle stesse identiche pipeline di continuous delivery e nei container orchestrator che già usi per i tuoi servizi backend tradizionali. Se vuoi approfondire l'argomento, ti invito a leggere la documentazione ufficiale di Prompt Flow, a provare a fare il deploy di un container tu stesso, o a visitare devstories dot eu per suggerire argomenti che vorresti vedere nelle prossime serie. Vorrei prendermi un momento per ringraziarti di averci ascoltato: ci aiuta tantissimo. Buona giornata!