DSPy: Reemplaçant l'enginyeria de prompts fràgil amb pipelines d'LLM compilats

Em continuo trobant amb el mateix mur quan penso en pipelines d'IA per a finances: pots construir alguna cosa que funcioni perfectament en els teus casos de prova, i després veure com s'esfondra silenciosament quan un proveïdor canvia el format de la seva factura o apareix un nou tipus de transacció. La fragilitat gairebé sempre es troba en els prompts — cadenes fetes a mà que ningú vol tocar. DSPy, introduït per Khattab et al. a Stanford i publicat a l'ICLR 2024, proposa una manera fonamentalment diferent de construir pipelines d'LLM que mereix una atenció acurada per part de qualsevol que intenti automatitzar el treball comptable.

L'article

DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines (Khattab, Singhvi, Maheshwari et al., ICLR 2024) replanteja la construcció de pipelines d'LLM com un problema de programació en lloc d'un problema d'enginyeria de prompts. L'observació central és que les aplicacions modernes d'LLM se solen construir com a col·leccions de cadenes de prompts codificades rígidament —el que els autors anomenen "plantilles de prompts"— unides amb flux de control de Python. Quan el model canvia, o la distribució de tasques es desplaça, algú ha de reescriure aquestes cadenes a mà.

DSPy substitueix les plantilles de prompts per dues abstraccions: signatures i mòduls. Una signatura és una especificació declarativa i tipificada de què ha de fer una crida a l'LM, escrita de forma compacta com question -> answer o amb descripcions de camps explícites en una classe de Python. Un mòdul envolta una signatura amb una estratègia de raonament — ChainOfThought, ReAct, ProgramOfThought, MultiChainComparison, i així successivament. L'addició crítica és un compilador (l'article l'anomena teleprompter) que agafa un programa DSPy, un petit conjunt de dades etiquetades i una mètrica de validació, i després genera automàticament demostracions few-shot, selecciona entre elles i produeix prompts que estan optimitzats per a aquesta mètrica. El compilador no necessita etiquetes en cada pas intermedi —pot fer un bootstrapping de les demostracions executant un programa mestre sobre entrades no etiquetades i filtrant les traces que resulten en sortides finals correctes.

Idees clau

• Les signatures desvinculen la intenció de la implementació. Escriure question, context -> answer és suficient perquè DSPy sàpiga com construir, invocar i optimitzar la crida a l'LM subjacent. El desenvolupador mai escriu una cadena de prompt.
• La compilació és un bootstrapping basat en mètriques. L'optimitzador BootstrapFewShot executa el programa amb entrades d'entrenament, recull traces d'entrada-sortida on el pipeline té èxit i les utilitza com a demostracions —sense que calgui anotació humana dels passos de raonament intermedis.
• El compilador desbloqueja els models petits. A GSM8K (problemes matemàtics amb text), Llama2-13b base obté un 9,4% amb prompting zero-shot. Després de la compilació DSPy amb mòduls de reflexió i d'ensemble, arriba al 46,9%. T5-Large (770 milions de paràmetres), un model que la majoria de la gent va descartar per al raonament complex, aconsegueix un 39,3% de coincidència exacta de respostes a HotPotQA utilitzant només 200 exemples etiquetats.
• Els prompts d'experts no són el sostre. A GSM8K, GPT-3.5 amb prompting few-shot convencional arriba al 25,2%. La cadena de pensament (CoT) elaborada per experts puja fins aproximadament el 72–73%. El pipeline de reflexió i ensemble compilat de DSPy l'empeny fins al 81,6% —sense que cap humà hagi d'escriure prompts.
• Els programes es componen. Un pipeline de QA de recuperació de múltiples salts en DSPy té unes 12 línies de Python. L'equivalent en LangChain, segons assenyalen els autors, conté 50 cadenes que superen els 1000 caràcters de contingut de prompt fet a mà.
• Tres etapes de compilació. L'optimitzador funciona com: generació de candidats (bootstrapping de traces), optimització de paràmetres (cerca aleatòria o Optuna sobre hiperparàmetres) i optimització d'ordre superior (ensembles, flux de control dinàmic).

Què es manté — i què no

Els resultats empírics són reals i substancials. Passar del 9,4% al 46,9% a GSM8K amb Llama2-13b, utilitzant només uns quants exemples d'entrenament etiquetats, no és incremental —és el tipus de salt que fa que els models petits i barats siguin viables per a tasques que abans requerien GPT-4. L'arquitectura també és genuïnament elegant: les signatures són fàcils de llegir, els mòduls són combinables i l'abstracció no sembla tenir fuites per a les tasques demostrades.

Les limitacions existeixen, tot i que l'article no les discuteix en una secció dedicada. La més important: el compilador és tan bo com ho sigui la teva mètrica. Si la teva mètrica de validació és imprecisa o no està alineada amb la qualitat real de la tasca —cosa extremadament comuna a la pràctica—, l'optimitzador trobarà maneres enginyoses de maximitzar-la mentre falla en el que realment t'importa. En un domini estructurat com la comptabilitat, podries definir una mètrica com "l'assentament comptable quadra", però un assentament quadrat encara pot tenir codis de compte completament erronis. Els autors saben que aquest problema existeix, però el deixen com a responsabilitat del desenvolupador.

Una segona limitació: la compilació encara requereix algunes dades etiquetades. L'article afirma que es poden utilitzar només 10 exemples amb BootstrapFewShot, i que només calen els valors d'entrada (no les etiquetes intermèdies). Això és cert en el millor dels casos, però a la pràctica, la fiabilitat del bootstrapping es degrada quan el programa inicial no pot resoldre cap exemple d'entrenament. Si el teu pipeline d'agent financer té una precisió base propera a zero —com sol passar quan estàs construint alguna cosa nova—, la compilació pot girar en buit.

Tercer, i més subtil: DSPy optimitza els prompts i les demostracions, però no optimitza l'estructura del programa en si. Si has connectat els mòduls d'una manera que és fonamentalment incorrecta per a la tasca, el compilador no t'ajudarà. El disseny del programa segueix sent cosa del desenvolupador.

Per què això és important per a la IA en finances

El problema de la fragilitat dels prompts és potser el major obstacle pràctic per desplegar agents d'IA financera en producció. Un pipeline que categoritza transaccions fent coincidir descripcions amb codis de compte es degradarà cada vegada que les dades del comerciant canviïn de format, cada vegada que aparegui una nova categoria de despesa o cada vegada que s'actualitzi el pla de comptes. Amb DSPy, defineixes la tasca de manera abstracta (transaction_description, chart_of_accounts -> account_code, confidence) i deixes que el compilador esbrini les demostracions òptimes cada vegada que la distribució canvia.

Específicament per a Beancount, veig un pipeline estructurat com tres mòduls DSPy encadenats: un que extreu dades de transaccions estructurades a partir d'exportacions bancàries en brut, un que busca el compte que millor coincideix en el pla de comptes existent del llibre major i un que valida l'assentament comptable resultant contra les restriccions de partida doble. Cada mòdul té la seva pròpia signatura; tot el programa es compila contra una mètrica que comprova tant la correcció comptable com el compliment del format. El problema de la qualitat de la mètrica és on més afecta aquí —necessites una mètrica que detecti codis de compte incorrectes, no només assentaments desquadrats— però és un problema d'enginyeria solucionable.

La implicació més profunda: DSPy desplaça el treball d'"escriure millors prompts" a "escriure millors mètriques i recollir petits conjunts de dades etiquetades". Aquesta és una pràctica d'enginyeria molt més sostenible per a un sistema financer en producció que ha d'evolucionar a mesura que canvien les regulacions, les estructures dels plans de comptes i els formats de les transaccions.

Què llegir a continuació

• OPRO: Large Language Models as Optimizers (Yang et al., arXiv:2309.03409) — L'enfocament de Google DeepMind per a l'optimització de prompts mitjançant el refinament iteratiu generat per LM; un contrapunt útil a l'enfocament de bootstrapping de DSPy.
• TextGrad: Automatic "Differentiation" via Text (Yuksekgonul et al., arXiv:2406.07496) — planteja l'optimització com una retropropagació a través del feedback de text en lloc del bootstrapping basat en mètriques; mostra resultats sòlids en tasques de programació i científiques on l'enfocament de DSPy és més feble.
• DSPy Assertions: Computational Constraints for Self-Refining Language Model Pipelines (Singhvi et al., arXiv:2312.13382) — afegeix restriccions dures i toves als programes DSPy, permetent que els pipelines s'autocorregeixin quan les sortides violen les regles del domini; directament rellevant per fer complir els invariants comptables.