Continuo a imbattermi nello stesso muro quando penso alle pipeline AI finanziarie: puoi costruire qualcosa che funziona perfettamente sui tuoi casi di test, per poi vederlo crollare silenziosamente quando un fornitore cambia il formato della fattura o appare un nuovo tipo di transazione. La fragilità è quasi sempre nei prompt — stringhe artigianali che nessuno vuole toccare. DSPy, introdotto da Khattab et al. a Stanford e pubblicato a ICLR 2024, propone un modo fondamentalmente diverso di costruire pipeline LLM, che merita attenzione attenta da parte di chiunque cerchi di automatizzare il lavoro contabile.
L'articolo
DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines (Khattab, Singhvi, Maheshwari et al., ICLR 2024) riformula la costruzione di pipeline LLM come un problema di programmazione piuttosto che un problema di ingegneria dei prompt. L'osservazione centrale è che le applicazioni LLM moderne sono tipicamente costruite come collezioni di stringhe di prompt hard-coded — ciò che gli autori chiamano "modelli di prompt" — incollate insieme con il flusso di controllo Python. Quando il modello cambia, o la distribuzione dei compiti si sposta, qualcuno deve riscrivere quelle stringhe a mano.
DSPy sostituisce i modelli di prompt con due astrazioni: firme e moduli. Una firma è una specifica tipizzata e dichiarativa di ciò che una chiamata LM dovrebbe fare, scritta in modo compatto come domanda -> risposta o con descrizioni esplicite dei campi in una classe Python. Un modulo avvolge una firma con una strategia di ragionamento — ChainOfThought, ReAct, ProgramOfThought, MultiChainComparison e così via. L'aggiunta critica è un compilatore (l'articolo lo chiama teleprompter) che prende un programma DSPy, un piccolo dataset etichettato e una metrica di validazione, quindi genera automaticamente dimostrazioni few-shot, seleziona tra di esse e produce prompt ottimizzati per quella metrica. Il compilatore non richiede etichette in ogni passaggio intermedio — può avviare le dimostrazioni eseguendo un programma insegnante su input non etichettati e filtrando le tracce che portano a risultati finali corretti.
Idee chiave
- Le firme disaccoppiano l'intenzione dall'implementazione. Scrivere
domanda, contesto -> rispostaè sufficiente affinché DSPy sappia come costruire, invocare e ottimizzare la chiamata LM sottostante. Lo sviluppatore non scrive mai una stringa di prompt. - La compilazione è un avviamento guidato da metriche. L'ottimizzatore
BootstrapFewShotesegue il programma su input di addestramento, raccoglie tracce input-output dove la pipeline ha successo e le usa come dimostrazioni — nessuna annotazione umana dei passaggi di ragionamento intermedi è richiesta. - Il compilatore sblocca i modelli piccoli. Su GSM8K (problemi matematici testuali), la normale Llama2-13b ottiene il 9,4% con prompting zero-shot. Dopo la compilazione DSPy con moduli di riflessione e ensemble, raggiunge il 46,9%. T5-Large (770 milioni di parametri), un modello che la maggior parte delle persone aveva scartato per il ragionamento complesso, ottiene una corrispondenza esatta della risposta del 39,3% su HotPotQA utilizzando solo 200 esempi etichettati.
- I prompt esperti non sono il limite massimo. Su GSM8K, GPT-3.5 con prompting few-shot normale raggiunge il 25,2%. La catena di pensiero artigianale lo porta a circa il 72-73%. La pipeline compilata di riflessione e ensemble di DSPy la spinge all'81,6% — senza che nessun umano scriva prompt.
- I programmi si compongono. Una pipeline QA di recupero multi-hop in DSPy richiede circa 12 righe di Python. L'equivalente in LangChain, notano gli autori, contiene 50 stringhe che superano 1000 caratteri di contenuto di prompt artigianali.
- Tre fasi di compilazione. L'ottimizzatore opera come: generazione di candidati (avviamento delle tracce), ottimizzazione dei parametri (ricerca casuale o Optuna sugli iperparametri) e ottimizzazione di ordine superiore (ensemble, flusso di controllo dinamico).
Cosa funziona — e cosa no
I risultati empirici sono reali e sostanziali. Passare dal 9,4% al 46,9% su GSM8K con Llama2-13b, utilizzando solo una manciata di esempi di addestramento etichettati, non è incrementale — è il tipo di divario che rende i modelli piccoli ed economici praticabili per compiti che prima richiedevano GPT-4. L'architettura è anche genuinamente elegante: le firme sono facili da leggere, i moduli sono componibili e l'astrazione non sembra permeabile per i compiti dimostrati.
Le limitazioni sono reali, anche se l'articolo non le discute in una sezione dedicata. La più importante: il compilatore è valido quanto la tua metrica. Se la tua metrica di validazione è imprecisa o disallineata con la qualità effettiva del compito — cosa estremamente comune nella pratica — l'ottimizzatore troverà modi astuti per massimizzarla fallendo in ciò che conta veramente. In un dominio strutturato come la contabilità, potresti definire una metrica come "la registrazione contabile è in pareggio", ma una registrazione in pareggio può comunque avere codici conto completamente sbagliati. Gli autori sanno che questo problema esiste ma lo lasciano come responsabilità dello sviluppatore.
Una seconda limitazione: la compilazione richiede comunque alcuni dati etichettati. L'articolo sostiene che puoi utilizzare solo 10 esempi con BootstrapFewShot e che sono necessari solo i valori di input (non le etichette intermedie). Questo è vero nel migliore dei casi, ma in pratica, l'affidabilità dell'avviamento diminuisce quando il programma iniziale non riesce a risolvere nessun esempio di addestramento. Se la tua pipeline agente finanziaria ha una precisione di base quasi nulla — come è comune quando si costruisce qualcosa di nuovo — la compilazione può girare a vuoto.
Terzo, e più sottile: DSPy ottimizza i prompt e le dimostrazioni, ma non ottimizza la struttura del programma stessa. Se hai collegato i moduli insieme in un modo fondamentalmente sbagliato per il compito, il compilatore non ti aiuterà. La progettazione del programma è ancora a carico dello sviluppatore.
Perché questo è importante per l'AI finanziaria
Il problema della fragilità dei prompt è forse il più grande ostacolo pratico all'implementazione di agenti AI finanziari in produzione. Una pipeline che categorizza le transazioni abbinando descrizioni a codici conto si degraderà ogni volta che i dati del commerciante cambiano formato, ogni volta che appare una nuova categoria di spesa o ogni volta che il piano dei conti viene aggiornato. Con DSPy, definisci il compito in modo astratto (descrizione_transazione, piano_dei_conti -> codice_conto, livello_di_fiducia) e lasci che il compilatore trovi le dimostrazioni ottimali ogni volta che la distribuzione cambia.
Per Beancount in particolare, posso vedere una pipeline strutturata come tre moduli DSPy in cascata: uno che estrae dati di transazione strutturati da esportazioni bancarie grezze, uno che cerca il miglior conto corrispondente nel piano dei conti esistente del registro e uno che valida la registrazione contabile risultante rispetto ai vincoli della partita doppia. Ogni modulo ha la propria firma; l'intero programma viene compilato rispetto a una metrica che verifica sia la correttezza contabile che la conformità del formato. Il problema della qualità della metrica colpisce più duramente qui — hai bisogno di una metrica che catturi i codici conto sbagliati, non solo le registrazioni in pareggio — ma questo è un problema di ingegneria risolvibile.
L'implicazione più profonda: DSPy sposta il lavoro da "scrivi prompt migliori" a "scrivi metriche migliori e raccogli piccoli dataset etichettati." Questa è una pratica ingegneristica molto più sostenibile per un sistema finanziario di produzione che deve evolversi man mano che le normative, le strutture del piano dei conti e i formati delle transazioni cambiano nel tempo.
Cosa leggere dopo
- OPRO: Large Language Models as Optimizers (Yang et al., arXiv:2309.03409) — L'approccio di Google DeepMind all'ottimizzazione dei prompt tramite affinamento iterativo generato da LLM; un utile contrappunto all'approccio di avviamento di DSPy.
- TextGrad: Automatic "Differentiation" via Text (Yuksekgonul et al., arXiv:2406.07496) — Inquadra l'ottimizzazione come retropropagazione attraverso feedback testuale piuttosto che avviamento guidato da metriche; mostra risultati forti su compiti di codifica e scientifici dove l'approccio di DSPy è più debole.
- DSPy Assertions: Computational Constraints for Self-Refining Language Model Pipelines (Singhvi et al., arXiv:2312.13382) — Aggiunge vincoli rigidi e morbidi ai programmi DSPy, consentendo alle pipeline di autocorreggersi quando gli output violano le regole del dominio; direttamente rilevante per far rispettare gli invarianti contabili.