Compilando Inteligencia: Cómo DSPy Optimiza los Pipelines de Agentes

The difference between a demo and a production agent is optimization. Most AI systems ship with hand-written prompts that someone tweaked until they “felt right.” DSPy replaces that intuition with compilation.

La diferencia entre un demo y un agente en producción es la optimización. La mayoría de los sistemas de IA se entregan con prompts escritos a mano que alguien ajustó hasta que “se sentían bien”. DSPy reemplaza esa intuición con compilación.

The pipeline is deceptively simple: define a signature (input → output), pick a module (ChainOfThought, ReAct, ProgramOfThought), attach a metric, and run an optimizer. BootstrapFewShot mines successful trajectories for few-shot examples. MIPROv2 jointly searches over instruction candidates and demonstration subsets. The result isn’t a prompt—it’s a compiled program that outperforms hand-crafted originals by 20-40% on standard benchmarks.

El pipeline es engañosamente simple: define una signature (entrada → salida), elige un módulo (ChainOfThought, ReAct, ProgramOfThought), adjunta una métrica y ejecuta un optimizador. BootstrapFewShot extrae trazas exitosas para ejemplos few-shot. MIPROv2 busca conjuntamente entre candidatos de instrucciones y subconjuntos de demostraciones. El resultado no es un prompt—es un programa compilado que supera los originales escritos a mano en un 20-40% en benchmarks estándar.

What makes this powerful for agent architectures is composability. A ReAct agent becomes a module. Two agents become a pipeline. The optimizer treats the entire composition as a single trainable program, backpropagating metric feedback through every layer. You’re not prompt-engineering anymore—you’re programming with language models.

Lo que hace esto poderoso para arquitecturas de agentes es la composabilidad. Un agente ReAct se convierte en un módulo. Dos agentes se convierten en un pipeline. El optimizador trata la composición entera como un único programa entrenable, retropropagando la retroalimentación de métricas a través de cada capa. Ya no estás haciendo ingeniería de prompts—estás programando con modelos de lenguaje.

BAMLAdapter and the end of verbose JSON Schema. DSPy 3.0 introduced a new adapter system. The BAMLAdapter replaces verbose JSON Schema with simplified type notation—instead of generating full schema definitions, you write name: string and the adapter handles the rest. This improves structured output quality dramatically, especially for smaller models that struggle with JSON Schema compliance. The adapter handles nested Pydantic models, multimodal types, and the edge cases that trip up conventional approaches. Enable it with dspy.configure(adapter=dspy.adapters.BAMLAdapter()).

BAMLAdapter y el fin del JSON Schema verbose. DSPy 3.0 introdujo un nuevo sistema de adaptadores. El BAMLAdapter reemplaza el verbose JSON Schema con notación de tipos simplificada—en lugar de generar definiciones completas de esquema, escribes name: string y el adaptador se encarga del resto. Esto mejora drásticamente la calidad de las salidas estructuradas, especialmente para modelos más pequeños que tienen dificultades con el cumplimiento de JSON Schema. El adaptador maneja modelos Pydantic anidados, tipos multimodales y los casos extremos que complican los enfoques convencionales. Se habilita con dspy.configure(adapter=dspy.adapters.BAMLAdapter()).

GEPA: reflective prompt evolution. The GEPA optimizer (Genetic-Pareto Optimizer) constructs Pareto trees of prompt candidates using natural language reflection to extract and validate lessons from each optimization step. The result: shorter prompts that perform better downstream. The paper “GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning” (July 2025) demonstrates that reflective prompt evolution can match or exceed RL-based approaches at a fraction of the computational cost. In practice, GEPA wins over MIPROv2 on several benchmark tasks, producing concise, high-quality instructions.

GEPA: evolución reflexiva de prompts. El optimizador GEPA (Genetic-Pareto Optimizer) construye árboles de Pareto de candidatos de prompts utilizando reflexión en lenguaje natural para extraer y validar lecciones de cada paso de optimización. El resultado: prompts más cortos que funcionan mejor en tareas downstream. El paper “GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning” (julio 2025) demuestra que la evolución reflexiva de prompts puede igualar o superar enfoques basados en RL a una fracción del costo computacional. En la práctica, GEPA supera a MIPROv2 en varias tareas de benchmark, produciendo instrucciones concisas y de alta calidad.

BetterTogether: multi-optimizer compilation. BetterTogether chains multiple optimizers via strategy strings, enabling multi-stage compilation pipelines. A configuration like BetterTogether(metric=m, p=GEPA(...), w=BootstrapFinetune(...), strategy="p -> w -> p") runs prompt optimization, then weight fine-tuning, then prompt optimization again—evaluating each step on a validation set and returning the best program. This composable approach recognizes that no single optimizer dominates all tasks, and that sequential application of complementary strategies yields compound improvements.

BetterTogether: compilación multi-optimizador. BetterTogether encadena múltiples optimizadores mediante cadenas de estrategia, habilitando pipelines de compilación multi-etapa. Una configuración como BetterTogether(metric=m, p=GEPA(...), w=BootstrapFinetune(...), strategy="p -> w -> p") ejecuta optimización de prompts, luego fine-tuning de pesos, luego optimización de prompts nuevamente—evaluando cada paso en un conjunto de validación y devolviendo el mejor programa. Este enfoque componible reconoce que ningún optimizador único domina todas las tareas, y que la aplicación secuencial de estrategias complementarias produce mejoras compuestas.

GRPO: reinforcement learning for composed pipelines. The GRPO optimizer (Group Relative Policy Optimization) applies reinforcement learning to complex multi-module DSPy pipelines. Combined with MIPROv2 via BetterTogether, it yields 5-11% improvements on downstream tasks. This is the first implementation of GRPO for composed LM programs—treating an entire agent pipeline as a single policy and optimizing end-to-end. The paper “Multi-module GRPO: Composing Policy Gradients and Prompt Optimization for LM Programs” (arXiv:2508.04660) details the approach and its advantages over single-module optimization.

GRPO: reinforcement learning para pipelines compuestos. El optimizador GRPO (Group Relative Policy Optimization) aplica aprendizaje por refuerzo a pipelines complejos de múltiples módulos en DSPy. Combinado con MIPROv2 a través de BetterTogether, produce mejoras del 5-11% en tareas downstream. Esta es la primera implementación de GRPO para programas LM compuestos—tratando un pipeline de agentes completo como una única política y optimizando end-to-end. El paper “Multi-module GRPO: Composing Policy Gradients and Prompt Optimization for LM Programs” (arXiv:2508.04660) detalla el enfoque y sus ventajas sobre la optimización de módulos individuales.

Custom LM backends: decoupling from LiteLLM. DSPy 3.2 decoupled the framework from LiteLLM entirely. The new BaseLM abstract class exposes capability properties—supports_function_calling, supports_reasoning, and others—so custom LM backends integrate cleanly without any litellm dependency. The new dspy.ContextWindowExceededError provides structured error handling for context limits. This architectural shift means DSPy can now target any inference provider, from custom serving infrastructure to specialized hardware backends, with full capability negotiation.

Custom LM Backends: desacoplamiento de LiteLLM. DSPy 3.2 desacopló el framework de LiteLLM por completo. La nueva clase abstracta BaseLM expone propiedades de capacidad—supports_function_calling, supports_reasoning, y otras—para que los backends LM personalizados se integren limpiamente sin ninguna dependencia de litellm. El nuevo dspy.ContextWindowExceededError proporciona manejo estructurado de errores para límites de contexto. Este cambio arquitectónico significa que DSPy ahora puede dirigirse a cualquier proveedor de inferencia, desde infraestructura de serving personalizada hasta backends de hardware especializado, con negociación completa de capacidades.

References

Referencias