DSPy: Nahradenie krehkého prompt engineeringu kompilovanými LLM pipeline-ami

Stále narážam na tú istú stenu, keď premýšľam o finančných AI pipeline-och: môžete vytvoriť niečo, čo krásne funguje na vašich testovacích prípadoch, a potom sledovať, ako sa to potichu rozpadá, keď dodávateľ zmení formát faktúry alebo sa objaví nový typ transakcie. Krehkosť spočíva takmer vždy v promptoch — ručne vytvorených reťazcoch, na ktoré nikto nechce siahnuť. DSPy, ktorý predstavili Khattab a kol. zo Stanfordu a publikovali na ICLR 2024, navrhuje zásadne odlišný spôsob budovania LLM pipeline-ov, ktorý si zaslúži pozornosť každého, kto sa snaží automatizovať účtovnú prácu.

Článok

DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines (Khattab, Singhvi, Maheshwari a kol., ICLR 2024) redefinuje konštrukciu LLM pipeline-ov ako programátorský problém, a nie ako problém prompt engineeringu. Hlavným postrehom je, že moderné aplikácie LLM sú zvyčajne postavené ako zbierky pevne zakódovaných reťazcov promptov — čo autori nazývajú „šablóny promptov“ — pospájaných pomocou riadiaceho toku v Pythone. Keď sa model zmení alebo sa posunie distribúcia úloh, niekto musí tieto reťazce ručne prepísať.

DSPy nahrádza šablóny promptov dvoma abstrakciami: signatúrami a modulmi. Signatúra je typovaná, deklaratívna špecifikácia toho, čo má volanie LM urobiť, zapísaná kompaktne ako otázka -> odpoveď alebo s explicitným popisom polí v triede Pythonu. Modul obalí signatúru stratégiou uvažovania — ChainOfThought, ReAct, ProgramOfThought, MultiChainComparison a podobne. Rozhodujúcim doplnkom je kompilátor (článok ho nazýva teleprompter), ktorý vezme program DSPy, malý označený dataset a metriku validácie, a potom automaticky vygeneruje few-shot ukážky, vyberie tie najlepšie a vytvorí prompty, ktoré sú optimalizované pre danú metriku. Kompilátor nepotrebuje menovky pre každý medzikrok — dokáže si ukážky vytvoriť sám (bootstrap) spustením učiteľského programu na neoznačených vstupoch a filtrovaním stôp, ktoré vedú k správnym konečným výstupom.

Kľúčové myšlienky

• Signatúry oddeľujú zámer od implementácie. Napísanie otázka, kontext -> odpoveď stačí na to, aby DSPy vedelo, ako zostaviť, vyvolať a optimalizovať základné volanie LM. Vývojár nikdy nepíše reťazec promptu.
• Kompilácia je bootstrapping riadený metrikami. Optimalizátor BootstrapFewShot spustí program na tréningových vstupoch, zhromaždí stopy vstupov a výstupov tam, kde pipeline uspeje, a použije ich ako ukážky — nevyžaduje sa žiadna ľudská anotácia medzikrokov uvažovania.
• Kompilátor odomyká malé modely. Na GSM8K (matematické slovné úlohy) dosahuje základná Llama2-13b s zero-shot promptovaním skóre 9,4 %. Po kompilácii DSPy s modulmi pre reflexiu a súbor (ensemble) dosahuje 46,9 %. T5-Large (770 miliónov parametrov), model, ktorý väčšina ľudí pre zložité uvažovanie odpisovala, dosahuje 39,3 % presnú zhodu odpovedí v HotPotQA s použitím iba 200 označených príkladov.
• Expertné prompty nie sú stropom. Na GSM8K dosahuje GPT-3.5 s bežným few-shot promptovaním 25,2 %. Expertný chain-of-thought to zvyšuje na približne 72 – 73 %. Kompilovaná pipeline DSPy s reflexiou a súborom modelov to posúva na 81,6 % — bez toho, aby človek písal akékoľvek prompty.
• Programy sú kompozitné. Pipeline pre multi-hop retrieval QA v DSPy má asi 12 riadkov v Pythone. Ekvivalent v LangChain, ako poznamenávajú autori, obsahuje 50 reťazcov presahujúcich 1000 znakov ručne vytvoreného obsahu promptov.
• Tri fázy kompilácie. Optimalizátor funguje ako: generovanie kandidátov (bootstrapping stôp), optimalizácia parametrov (náhodné vyhľadávanie alebo Optuna nad hyperparametrami) a optimalizácia vyššieho rádu (súbory modelov, dynamický riadiaci tok).

Čo obstojí — a čo nie

Empirické výsledky sú reálne a podstatné. Prechod z 9,4 % na 46,9 % na GSM8K s Llama2-13b pri použití len niekoľkých označených tréningových príkladov nie je prírastkový — je to druh rozdielu, vďaka ktorému sú malé a lacné modely použiteľné pre úlohy, ktoré predtým vyžadovali GPT-4. Architektúra je tiež skutočne elegantná: signatúry sú ľahko čitateľné, moduly sú kombinovateľné a abstrakcia sa pri demonštrovaných úlohách nezdá byť deravá.

Limity sú však reálne, hoci ich článok nerozoberá v samostatnej časti. Ten najdôležitejší: kompilátor je len taký dobrý, ako je vaša metrika. Ak je vaša metrika validácie nepresná alebo nie je v súlade so skutočnou kvalitou úlohy — čo je v praxi mimoriadne bežné — optimalizátor nájde šikovné spôsoby, ako ju maximalizovať, pričom zlyhá v tom, na čom vám skutočne záleží. V štruktúrovanej doméne, akou je účtovníctvo, by ste mohli definovať metriku ako „účtovný zápis je vyrovnaný“, ale vyrovnaný zápis môže mať stále úplne nesprávne kódy účtov. Autori vedia, že tento problém existuje, ale nechávajú ho na zodpovednosti vývojára.

Druhé obmedzenie: kompilácia stále vyžaduje určité množstvo označených dát. Článok tvrdí, že môžete použiť len 10 príkladov s BootstrapFewShot a že sú potrebné iba vstupné hodnoty (nie priebežné menovky). To je pravda v ideálnom prípade, ale v praxi sa spoľahlivosť bootstrappingu znižuje, keď počiatočný program nedokáže vyriešiť žiadne tréningové príklady. Ak má vaša pipeline finančného agenta takmer nulovú počiatočnú presnosť — čo je bežné, keď staviate niečo nové — kompilácia môže bežať naprázdno.

Po tretie, a to je jemnejšie: DSPy optimalizuje prompty a ukážky, ale neoptimalizuje samotnú štruktúru programu. Ak ste moduly prepojili spôsobom, ktorý je pre danú úlohu zásadne nesprávny, kompilátor vám nepomôže. Návrh programu je stále na vývojárovi.

Prečo na tom záleží pre finančnú AI

Problém krehkosti promptov je snáď najväčšou praktickou prekážkou pri nasadzovaní agentov finančnej AI do produkcie. Pipeline, ktorý kategorizuje transakcie priraďovaním popisov ku kódom účtov, bude degradovať vždy, keď sa zmení formát údajov od obchodníka, keď sa objaví nová kategória výdavkov alebo keď sa aktualizuje účtová osnova. S DSPy definujete úlohu abstraktne (popis_transakcie, účtová_osnova -> kód_účtu, dôvera) a necháte kompilátor, aby zistil optimálne ukážky vždy, keď sa distribúcia zmení.

Konkrétne pre Beancount si viem predstaviť pipeline štruktúrovanú ako tri zreťazené moduly DSPy: jeden, ktorý extrahuje štruktúrované údaje o transakciách z nespracovaných exportov z banky, druhý, ktorý vyhľadá najvhodnejší účet v existujúcej účtovej osnove hlavnej knihy, a tretí, ktorý overí výsledný účtovný zápis voči obmedzeniam podvojného účtovníctva. Každý modul dostane vlastnú signatúru; celý program sa skompiluje voči metrike, ktorá kontroluje účtovnú správnosť aj súlad s formátom. Problém s kvalitou metriky tu naráža najviac — potrebujete metriku, ktorá zachytí nesprávne kódy účtov, nielen nevyrovnané zápisy — ale to je riešiteľný inžiniersky problém.

Hlbší dôsledok: DSPy presúva prácu z „písania lepších promptov“ na „písanie lepších metrík a zber malých označených datasetov“. To je oveľa udržateľnejšia inžinierska prax pre produkčný finančný systém, ktorý sa musí vyvíjať podľa toho, ako sa časom menia predpisy, štruktúry účtových osnov a formáty transakcií.

Čo si prečítať ďalej

• OPRO: Large Language Models as Optimizers (Yang et al., arXiv:2309.03409) — Prístup Google DeepMind k optimalizácii promptov prostredníctvom iteratívneho spresňovania generovaného LM; užitočný protipól k bootstrappingovému prístupu DSPy.
• TextGrad: Automatic "Differentiation" via Text (Yuksekgonul et al., arXiv:2406.07496) — Definuje optimalizáciu ako spätnú propagáciu (backpropagation) cez textovú spätnú väzbu namiesto bootstrappingu riadeného metrikami; vykazuje silné výsledky pri kódovaní a vedeckých úlohách, kde je prístup DSPy slabší.
• DSPy Assertions: Computational Constraints for Self-Refining Language Model Pipelines (Singhvi et al., arXiv:2312.13382) — Pridáva tvrdé a mäkké obmedzenia do programov DSPy, čo umožňuje pipeline-om samokorekciu, keď výstupy porušujú doménové pravidlá; priamo relevantné pre vynucovanie účtovných invariantov.