Loops de Retroalimentación Generativa de DSPy: Compilando Programas LM que se Mejoran Solos

The standard approach to building LM pipelines is prompt engineering—hand-crafting instructions and few-shot examples through trial and error. DSPy replaces this with a different paradigm: compile your programs, then let the system optimize itself. The mechanism that makes this possible is the Generative Feedback Loop (GFL)—a closed-loop system where an LLM generates candidate parameters, evaluates them against a metric, and iteratively improves the program without gradient descent. No weight updates, no fine-tuning, no RLHF. The LLM’s own generative capability is the optimization engine.

El enfoque estándar para construir pipelines de LM es la ingeniería de prompts—diseñar instrucciones y ejemplos few-shot manualmente a través de ensayo y error. DSPy reemplaza esto con un paradigma diferente: compila tus programas, luego deja que el sistema se optimice solo. El mecanismo que hace esto posible es el Loop de Retroalimentación Generativa (GFL)—un sistema de bucle cerrado donde un LLM genera parámetros candidatos, los evalúa contra una métrica, y mejora iterativamente el programa sin descenso de gradiente. Sin actualizaciones de pesos, sin fine-tuning, sin RLHF. La capacidad generativa del LLM es el motor de optimización.

The DSPy Framework

El Framework DSPy

DSPy (Declarative Self-improving Python), from Stanford NLP, abstracts LM pipelines as imperative programs built from composable modules. The four core abstractions are: Signature (a declarative input/output specification), Module (a composable LM operation like React, ChainOfThought, or Retrieve), Example (a data point with inputs and labels), and Optimizer (the mechanism that tunes the program). The key insight from the DSPy paper (Khattab et al., ICLR 2024 Spotlight): prompts are the assembly language of AI. DSPy lets you write Python, then compiles optimized prompts automatically.

DSPy (Python Auto-Mejorable Declarativo), de Stanford NLP, abstrae los pipelines de LM como programas imperativos construidos a partir de módulos componibles. Las cuatro abstracciones centrales son: Signature (una especificación declarativa de entrada/salida), Module (una operación LM componible como React, ChainOfThought o Retrieve), Example (un punto de datos con entradas y etiquetas), y Optimizer (el mecanismo que ajusta el programa). La clave del paper de DSPy (Khattab et al., ICLR 2024 Spotlight): los prompts son el lenguaje ensamblador de la IA. DSPy te permite escribir Python, luego compila prompts optimizados automáticamente.

The optimization works because DSPy separates two concerns: flow (the Python control graph connecting modules) and parameters (the learnable parts of each module—typically a system instruction string and a set of few-shot demonstrations). When you call optimizer.compile(program, trainset), DSPy runs the program on training examples, collects execution traces, generates and evaluates candidate parameters, and updates the program. The program structure stays identical—only the underlying prompts change.

La optimización funciona porque DSPy separa dos preocupaciones: el flujo (el grafo de control de Python conectando módulos) y los parámetros (las partes aprendibles de cada módulo—típicamente una string de instrucción del sistema y un conjunto de demostraciones few-shot). Cuando llamas optimizer.compile(program, trainset), DSPy ejecuta el programa en ejemplos de entrenamiento, recolecta trazas de ejecución, genera y evalúa parámetros candidatos, y actualiza el programa. La estructura del programa permanece idéntica—solo los prompts subyacentes cambian.

The GFL Mechanism

El Mecanismo GFL

Every DSPy optimizer implements the same three-stage loop. Stage 1: Trace Collection—run the program forward on training examples, capturing inputs, outputs, and intermediate states at every module call. This produces a complete execution trace. Stage 2: Feedback Generation—for each trace, evaluate against the metric. The metric returns a scalar score (for basic optimizers like BootstrapFewShot) or rich textual feedback (for advanced optimizers like GEPA). Stage 3: Program Update—based on scores, update the program’s learnable parameters: keep successful demonstrations, propose new instruction variants, or modify module structure. The loop repeats until convergence or budget exhaustion.

Cada optimizador DSPy implementa el mismo bucle de tres etapas. Etapa 1: Recolección de Trazas—ejecuta el programa hacia adelante en ejemplos de entrenamiento, capturando entradas, salidas y estados intermedios en cada llamada a módulos. Esto produce una traza de ejecución completa. Etapa 2: Generación de Retroalimentación—para cada traza, evaluar contra la métrica. La métrica devuelve un puntaje escalar (para optimizadores básicos como BootstrapFewShot) o retroalimentación textual rica (para optimizadores avanzados como GEPA). Etapa 3: Actualización del Programa—basado en puntajes, actualizar los parámetros aprendibles del programa: conservar demostraciones exitosas, proponer variantes de instrucción, o modificar la estructura de módulos. El bucle se repite hasta convergencia o agotar presupuesto.

What distinguishes GFL from conventional training is that no gradients are computed. The LLM generates its own training signal—by proposing demonstrations, instructions, or self-reflections—and the metric provides the selection pressure. It’s a zero-gradient approach where the LLM’s generative capability replaces backpropagation. The practical implication: you optimize production LM programs using API calls, not GPU training runs.

Lo que distingue a GFL del entrenamiento convencional es que no se computan gradientes. El LLM genera su propia señal de entrenamiento—proporcionando demostraciones, instrucciones o autorreflexiones—y la métrica proporciona la presión de selección. Es un enfoque de cero gradientes donde la capacidad generativa del LLM reemplaza la propagación hacia atrás. La implicación práctica: optimizas programas LM de producción usando llamadas API, no ejecuciones de entrenamiento en GPU.

BootstrapFewShot: The Foundational GFL

BootstrapFewShot: El GFL Fundacional

BootstrapFewShot is the canonical GFL optimizer. The mechanism: run a teacher module on training examples at temperature=1.0 with unique rollout_ids to bypass caches and generate diverse traces. Keep only the traces where the metric succeeds. These passing demonstrations become the student’s few-shot examples. The result: the student module now contains demonstrations that were automatically verified to produce correct outputs on their inputs.

BootstrapFewShot es el optimizador GFL canónico. El mecanismo: ejecutar un módulo teacher en ejemplos de entrenamiento a temperature=1.0 con rollout_ids únicos para evitar cachés y generar trazas diversas. Conservar solo las trazas donde la métrica tiene éxito. Estas demostraciones aprobadas se convierten en los ejemplos few-shot del student. El resultado: el módulo student ahora contiene demostraciones que fueron automáticamente verificadas como productoras de salidas correctas en sus entradas.

BootstrapFewShotWithRandomSearch runs BootstrapFewShot multiple times with randomized demonstration subsets, selecting the best over a validation set. BootstrapFewShotWithOptuna integrates Optuna’s TPE sampler for Bayesian hyperparameter optimization over the demonstration selection space. Both extend the basic GFL with more sophisticated search strategies, but the core loop remains the same: generate → evaluate → keep.

BootstrapFewShotWithRandomSearch ejecuta BootstrapFewShot múltiples veces con subconjuntos de demostraciones aleatorias, seleccionando el mejor sobre un conjunto de validación. BootstrapFewShotWithOptuna integra el muestreador TPE de Optuna para optimización bayesiana de hiperparámetros sobre el espacio de selección de demostraciones. Ambos extienden el GFL básico con estrategias de búsqueda más sofisticadas, pero el bucle central permanece igual: generar → evaluar → conservar.

MIPROv2: Instruction-Aware Optimization

MIPROv2: Optimización Consciente de Instrucciones

MIPROv2 (Opsahl-Ong et al., EMNLP 2024) is the current recommended default for rigorous DSPy optimization. It jointly optimizes instructions and few-shot demonstrations using a three-stage pipeline: (1) Bootstrap—generate candidate demonstration sets from training data; (2) Propose—use GroundedProposer, an LM-powered proposal mechanism, to generate instruction candidates conditioned on dataset summaries, program code, and random strategy tips; (3) Search—Bayesian Optimization via Optuna’s TPE sampler over the combined instruction × demo-set space. The search uses minibatch_size evaluations per trial with periodic full evaluation.

MIPROv2 (Opsahl-Ong et al., EMNLP 2024) es el optimizador recomendado actualmente para optimización rigurosa de DSPy. Optimiza conjuntamente instrucciones y demostraciones few-shot usando un pipeline de tres etapas: (1) Bootstrap—generar conjuntos candidatos de demostraciones de datos de entrenamiento; (2) Proponer—usar GroundedProposer, un mecanismo de propuesta basado en LM, para generar candidatos de instrucción condicionados a resúmenes del dataset, código del programa, y consejos estratégicos aleatorios; (3) Buscar—Optimización Bayesiana vía el muestreador TPE de Optuna sobre el espacio combinado de instrucción × conjunto de demos. La búsqueda usa evaluaciones de minibatch_size por trial con evaluación periódica completa.

MIPROv2’s impact is significant. On HotPotQA multi-hop RAG: 24% → 51% accuracy with the light preset. On StackExchange RAG: 53% → 61%. The auto parameter provides presets for optimization budget: light (~6–24 trials), medium (~12–48 trials), heavy (~18–72 trials). For ML engineers, this is the optimizer you reach for first when building DSPy pipelines.

El impacto de MIPROv2 es significativo. En RAG multi-hop de HotPotQA: 24% → 51% de precisión con el preset light. En RAG de StackExchange: 53% → 61%. El parámetro auto proporciona presets para presupuesto de optimización: light (~6–24 trials), medium (~12–48 trials), heavy (~18–72 trials). Para ingenieros de ML, este es el optimizador al que recurres primero cuando construyes pipelines DSPy.

GEPA: Evolutionary Prompt Optimization

GEPA: Optimización Evolutiva de Prompts

GEPA (Agrawal et al., ICLR 2026 Oral) represents the most advanced GFL optimizer as of 2026. GEPA introduces three pillars: Reflective Prompt Mutation—the LLM reads full execution traces (reasoning, tool calls, outputs), diagnoses why a candidate failed, and proposes targeted fixes in natural language; Rich Textual Feedback—metrics return not just scalar scores but diagnostic feedback strings explaining what went wrong and how to fix it; Pareto-based Candidate Selection—candidates are maintained on a Pareto frontier (best on at least one instance), with next mutations sampled proportionally to coverage.

GEPA (Agrawal et al., ICLR 2026 Oral) representa el optimizador GFL más avanzado a fecha de 2026. GEPA introduce tres pilares: Mutación Reflexiva de Prompts—el LLM lee trazas de ejecución completas (razonamiento, llamadas a herramientas, salidas), diagnostica por qué falló un candidato, y propone correcciones dirigidas en lenguaje natural; Retroalimentación Textual Rica—las métricas devuelven no solo puntajes escalares sino cadenas de diagnóstico retroalimentativa explicando qué salió mal y cómo corregirlo; Selección de Candidatos Pareto—los candidatos se mantienen en una frontera de Pareto (mejores en al menos una instancia), con mutaciones siguientes sampleadas proporcionalmente a la cobertura.

The numbers are striking. GEPA outperforms GRPO by 6% on average (up to 20% on specific tasks), uses 35× fewer rollouts than GRPO, and beats MIPROv2 by 10%+ (e.g., +12% on AIME-2025). The evolutionary framing is intentional: prompt optimization is a search problem, and GEPA treats it as one. Mutations are proposed by the LLM (not random), evaluated against the metric, and selected via Pareto dominance—directly analogous to evolutionary algorithms in optimization theory.

Los números son impactantes. GEPA supera a GRPO en 6% en promedio (hasta 20% en tareas específicas), usa 35× menos rollouts que GRPO, y supera a MIPROv2 en más de 10% (ej., +12% en AIME-2025). El enfoque evolutivo es intencional: la optimización de prompts es un problema de búsqueda, y GEPA lo trata como tal. Las mutaciones son propuestas por el LLM (no aleatorias), evaluadas contra la métrica, y seleccionadas mediante dominancia de Pareto—análogo directo a algoritmos evolutivos en teoría de optimización.

COPRO and Beyond

COPRO y Más Allá

COPRO (Cooperative Prompt Optimization) uses coordinate ascent with LLM-generated instructions. The compile loop: seed N instruction candidates from a base instruction, evaluate each predictor with each candidate across depth iterations, select the best, then generate next-generation candidates conditioned on previous best and worst attempts. COPRO handles multi-predictor programs by re-evaluating all predictors when any single predictor’s instruction changes—a critical correctness guarantee.

COPRO (Optimización Cooperativa de Prompts) usa ascenso de coordenadas con instrucciones generadas por LLM. El bucle de compilación: sembrar N candidatos de instrucción de una instrucción base, evaluar cada predictor con cada candidato a través de iteraciones de profundidad, seleccionar el mejor, luego generar candidatos de siguiente generación condicionados en los mejores y peores intentos anteriores. COPRO maneja programas multi-predictor re-evaluando todos los predictores cuando cambia la instrucción de cualquier predictor individual—una garantía de corrección crítica.

BootstrapFinetune completes the pipeline—distilling a prompted DSPy program into weight updates. Each LM call is replaced with a finetuned model. BetterTogether orchestrates meta-optimization: prompt optimization discovers effective task decompositions, weight optimization specializes the model, and alternating p → w → p sequences allow each to build on the other. SIMBA uses LLM introspection to analyze mini-batch failures and generate self-reflective improvement rules or select demonstrations.

BootstrapFinetune completa el pipeline—destilando un programa DSPy con prompts en actualizaciones de pesos. Cada llamada LM se reemplaza con un modelo fine-tuned. BetterTogether orquestra meta-optimización: la optimización de prompts descubre descomposiciones de tareas efectivas, la optimización de pesos especializa el modelo, y secuencias alternantes p → w → p permiten que cada una se construya sobre la otra. SIMBA usa introspección del LLM para analizar fallas de mini-batch y generar reglas de mejora autorreflexivas o seleccionar demostraciones.

The Agentic Parallel

El Paralelo Agéntico

For ML engineers building agentic systems, the GFL pattern maps directly to agent optimization. An agent pipeline in DSPy is a multi-module program with Retrieve → ReAct → Respond steps. Each step has learnable parameters (instructions + demos). GFL optimizes them jointly—finding the specific instruction that makes retrieval surface the right context, the reasoning chain that produces correct intermediate steps, and the response format that matches the gold answer.

Para ingenieros de ML construyendo sistemas agénticos, el patrón GFL se mapea directamente a la optimización de agentes. Un pipeline de agente en DSPy es un programa multi-módulo con pasos Retrieve → ReAct → Respond. Cada paso tiene parámetros aprendibles (instrucciones + demos). GFL los optimiza conjuntamente—encontrando la instrucción específica que hace que la recuperación superficie el contexto correcto, la cadena de razonamiento que produce pasos intermedios correctos, y el formato de respuesta que coincide con la respuesta dorada.

The key insight is that GFL operates at the program level, not the model level. You don’t need to retrain or fine-tune your LLM. You write the program logic in Python, define a metric that captures quality, and the optimizer searches over demonstration and instruction spaces to maximize that metric. This makes GFL fundamentally composable: the same optimizer that optimizes a RAG system works for a multi-agent tool-use pipeline. The agentic system becomes a first-class optimization target.

La clave es que GFL opera a nivel de programa, no de modelo. No necesitas reentrenar ni hacer fine-tuning de tu LLM. Escribes la lógica del programa en Python, defines una métrica que captura la calidad, y el optimizador busca en espacios de demostración e instrucción para maximizar esa métrica. Esto hace GFL fundamentalmente componible: el mismo optimizador que optimiza un sistema RAG funciona para un pipeline de uso de herramientas multi-agente. El sistema agéntico se convierte en un objetivo de optimización de primera clase.

Practical Patterns

Patrones Prácticos

The typical DSPy workflow follows three lines: define your metric, define your program, compile. BootstrapFewShot handles the GFL directly—no optimizer selection needed for simple cases. For production pipelines, MIPROv2 with auto="light" is the recommended starting point. For cutting-edge performance on hard tasks, GEPA delivers the best results but requires more rollouts. Multi-optimizer patterns are standard: sequential composition (MIPROv2 → BootstrapFinetune), ensemble selection from candidate programs, and meta-optimization via BetterTogether.

El flujo de trabajo típico de DSPy sigue tres líneas: define tu métrica, define tu programa, compila. BootstrapFewShot maneja el GFL directamente—no se necesita selección de optimizador para casos simples. Para pipelines de producción, MIPROv2 con auto="light" es el punto de partida recomendado. Para rendimiento de vanguardia en tareas difíciles, GEPA entrega los mejores resultados pero requiere más rollouts. Los patrones multi-optimizador son estándar: composición secuencial (MIPROv2 → BootstrapFinetune), selección de ensemble desde programas candidatos, y meta-optimización vía BetterTogether.

Why This Matters

Por Qué Importa

GFL represents a fundamentally different approach to LM optimization. Traditional methods—fine-tuning, RLHF, PEFT—modify model weights with gradient descent. They’re powerful but expensive, slow, and create model coupling. GFL treats the program as the unit of optimization, not the model. The same GFL that optimizes a RAG system today could optimize a completely different agent architecture tomorrow—because it operates on prompts and demonstrations, not weights. This composability, combined with the zero-gradient property, makes GFL the most practical optimization strategy for production LM pipelines built with DSPy.

GFL representa un enfoque fundamentalmente diferente a la optimización de LM. Los métodos tradicionales—fine-tuning, RLHF, PEFT—modifican los pesos del modelo con descenso de gradiente. Son poderosos pero costosos, lentos, y crean acoplamiento de modelo. GFL trata el programa como la unidad de optimización, no el modelo. El mismo GFL que optimiza un sistema RAG hoy podría optimizar una arquitectura de agente completamente diferente mañana—porque opera en prompts y demostraciones, no en pesos. Esta composibilidad, combinada con la propiedad de cero gradientes, hace de GFL la estrategia de optimización más práctica para pipelines LM de producción construidos con DSPy.

References

Referencias