DSPy: Reemplazando la Frágil Ingeniería de Prompts con Pipelines de LLM Compilados

Sigo chocando con el mismo muro al pensar en los pipelines de IA financiera: puedes construir algo que funcione de maravilla en tus casos de prueba, y luego ver cómo se desmorona silenciosamente cuando un proveedor cambia el formato de su factura o aparece un nuevo tipo de transacción. La fragilidad casi siempre reside en los prompts: cadenas creadas a mano que nadie quiere tocar. DSPy, presentado por Khattab et al. en Stanford y publicado en ICLR 2024, propone una forma fundamentalmente diferente de construir pipelines de LLM que merece una atención cuidadosa por parte de cualquiera que intente automatizar el trabajo contable.

El artículo

DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines (Khattab, Singhvi, Maheshwari et al., ICLR 2024) replantea la construcción de pipelines de LLM como un problema de programación en lugar de un problema de ingeniería de prompts. La observación principal es que las aplicaciones modernas de LLM se construyen típicamente como colecciones de cadenas de prompts codificadas —lo que los autores llaman "plantillas de prompts"— unidas con flujo de control de Python. Cuando el modelo cambia, o la distribución de la tarea se desplaza, alguien tiene que reescribir esas cadenas a mano.

DSPy reemplaza las plantillas de prompts con dos abstracciones: firmas (signatures) y módulos. Una firma es una especificación declarativa y tipada de lo que debe hacer una llamada al modelo de lenguaje, escrita de forma compacta como pregunta -> respuesta o con descripciones de campos explícitas en una clase de Python. Un módulo envuelve una firma con una estrategia de razonamiento: ChainOfThought, ReAct, ProgramOfThought, MultiChainComparison, y así sucesivamente. La adición crítica es un compilador (el artículo lo llama teleprompter) que toma un programa DSPy, un pequeño conjunto de datos etiquetados y una métrica de validación, y genera automáticamente demostraciones few-shot, selecciona entre ellas y produce prompts optimizados para esa métrica. El compilador no necesita etiquetas en cada paso intermedio; puede realizar un "bootstrap" de las demostraciones ejecutando un programa maestro en entradas no etiquetadas y filtrando las trazas que resultan en salidas finales correctas.

Ideas clave

• Las firmas desacoplan la intención de la implementación. Escribir pregunta, contexto -> respuesta es suficiente para que DSPy sepa cómo construir, invocar y optimizar la llamada subyacente al modelo. El desarrollador nunca escribe una cadena de prompt.
• La compilación es un bootstrapping guiado por métricas. El optimizador BootstrapFewShot ejecuta el programa con entradas de entrenamiento, recolecta trazas de entrada-salida donde el pipeline tiene éxito y las utiliza como demostraciones; no se requiere anotación humana de los pasos de razonamiento intermedios.
• El compilador libera el potencial de los modelos pequeños. En GSM8K (problemas matemáticos con palabras), Llama2-13b estándar obtiene un 9.4% con prompts zero-shot. Después de la compilación de DSPy con módulos de reflexión y conjunto (ensemble), alcanza el 46.9%. T5-Large (770M parámetros), un modelo que la mayoría descartó para razonamiento complejo, logra un 39.3% de coincidencia exacta de respuestas en HotPotQA usando solo 200 ejemplos etiquetados.
• Los prompts de expertos no son el techo. En GSM8K, GPT-3.5 con prompting few-shot estándar alcanza el 25.2%. La cadena de pensamiento (CoT) creada por expertos eleva eso a aproximadamente 72–73%. El pipeline de reflexión y conjunto compilado de DSPy lo empuja al 81.6%, sin que ningún humano escriba prompts.
• Los programas se componen. Un pipeline de QA de recuperación de múltiples saltos en DSPy ocupa unas 12 líneas de Python. El equivalente en LangChain, señalan los autores, contiene 50 cadenas que superan los 1000 caracteres de contenido de prompt creado a mano.
• Tres etapas de compilación. El optimizador opera como: generación de candidatos (bootstrapping de trazas), optimización de parámetros (búsqueda aleatoria u Optuna sobre hiperparámetros) y optimización de orden superior (conjuntos, flujo de control dinámico).

Qué se mantiene — y qué no

Los resultados empíricos son reales y sustanciales. Pasar del 9.4% al 46.9% en GSM8K con Llama2-13b, utilizando solo un puñado de ejemplos de entrenamiento etiquetados, no es algo incremental; es el tipo de brecha que hace que los modelos pequeños y económicos sean viables para tareas que antes requerían GPT-4. La arquitectura también es genuinamente elegante: las firmas son fáciles de leer, los módulos son componibles y la abstracción no parece tener filtraciones para las tareas demostradas.

Sin embargo, las limitaciones son reales, aunque el artículo no las discute en una sección dedicada. La más importante: el compilador es tan bueno como tu métrica. Si tu métrica de validación es imprecisa o no está alineada con la calidad real de la tarea —lo cual es extremadamente común en la práctica— el optimizador encontrará formas ingeniosas de maximizarla mientras falla en lo que realmente te importa. En un dominio estructurado como la contabilidad, podrías definir una métrica como "el asiento contable cuadra", pero un asiento cuadrado aún puede tener códigos de cuenta completamente erróneos. Los autores saben que este problema existe, pero lo dejan como responsabilidad del desarrollador.

Una segunda limitación: la compilación aún requiere algunos datos etiquetados. El artículo afirma que se pueden usar tan solo 10 ejemplos con BootstrapFewShot, y que solo se necesitan los valores de entrada (no etiquetas intermedias). Esto es cierto en el mejor de los casos, pero en la práctica, la fiabilidad del bootstrapping se degrada cuando el programa inicial no puede resolver ningún ejemplo de entrenamiento. Si tu pipeline de agente financiero tiene una precisión base cercana a cero —como suele ocurrir al construir algo nuevo— la compilación puede girar en falso sin avanzar.

Tercero, y más sutil: DSPy optimiza prompts y demostraciones, pero no optimiza la estructura del programa en sí. Si has conectado los módulos de una manera que es fundamentalmente incorrecta para la tarea, el compilador no te ayudará. El diseño del programa sigue dependiendo del desarrollador.

Por qué esto importa para la IA en finanzas

El problema de la fragilidad de los prompts es quizás el mayor obstáculo práctico para desplegar agentes de IA financiera en producción. Un pipeline que categoriza transacciones comparando descripciones con códigos de cuenta se degradará cada vez que los datos del comercio cambien de formato, cada vez que aparezca una nueva categoría de gasto o cada vez que se actualice el catálogo de cuentas. Con DSPy, defines la tarea de forma abstracta (descripcion_transaccion, catalogo_de_cuentas -> codigo_cuenta, confianza) y dejas que el compilador determine las demostraciones óptimas cada vez que la distribución cambie.

Específicamente para Beancount, puedo ver un pipeline estructurado como tres módulos DSPy encadenados: uno que extrae datos de transacciones estructurados de exportaciones bancarias en bruto, uno que busca la cuenta que mejor coincide en el catálogo de cuentas existente del libro mayor, y uno que valida el asiento contable resultante contra las restricciones de partida doble. Cada módulo obtiene su propia firma; todo el programa se compila contra una métrica que verifica tanto la corrección contable como el cumplimiento del formato. El problema de la calidad de la métrica golpea más fuerte aquí —necesitas una métrica que detecte códigos de cuenta incorrectos, no solo asientos desbalanceados— pero ese es un problema de ingeniería solucionable.

La implicación más profunda: DSPy desplaza el trabajo de "escribir mejores prompts" a "escribir mejores métricas y recolectar pequeños conjuntos de datos etiquetados". Esa es una práctica de ingeniería mucho más sostenible para un sistema financiero en producción que necesita evolucionar a medida que cambian las regulaciones, las estructuras de los catálogos de cuentas y los formatos de las transacciones.

Qué leer a continuación

• OPRO: Large Language Models as Optimizers (Yang et al., arXiv:2309.03409) — El enfoque de Google DeepMind para la optimización de prompts mediante el refinamiento iterativo generado por el propio modelo; un contrapunto útil al enfoque de bootstrapping de DSPy.
• TextGrad: Automatic "Differentiation" via Text (Yuksekgonul et al., arXiv:2406.07496) — plantea la optimización como retropropagación a través de retroalimentación de texto en lugar de bootstrapping basado en métricas; muestra resultados sólidos en tareas de codificación y científicas donde el enfoque de DSPy es más débil.
• DSPy Assertions: Computational Constraints for Self-Refining Language Model Pipelines (Singhvi et al., arXiv:2312.13382) — añade restricciones rígidas y flexibles a los programas DSPy, permitiendo que los pipelines se autocorrijan cuando las salidas violan las reglas del dominio; directamente relevante para aplicar invariantes contables.