DSPy

DSPy es un framework de Python para programar modelos de lenguaje en lugar de crear prompts manualmente. Desarrollado en Stanford NLP por Omar Khattab y publicado como código abierto bajo la licencia Apache 2.0, se originó a partir de una investigación publicada en ICLR 2024 y desde entonces ha crecido hasta alcanzar más de 34,000 estrellas en GitHub y aproximadamente 5.25 millones de descargas mensuales en PyPI hasta abril de 2026. El problema central que resuelve DSPy es la fragilidad de las cadenas de prompts creadas a mano: cuando cambias de modelo, modificas tu pipeline o descubres que tu prompt escrito a mano solo funciona bajo condiciones específicas, tienes que empezar de cero. DSPy reemplaza ese flujo de trabajo con un compilador que trata la optimización de prompts como un problema de búsqueda con una métrica.

El framework proporciona tres primitivas interconectadas: Signatures (especificaciones tipadas de entrada y salida escritas en lenguaje natural que declaran lo que quieres, no cómo obtenerlo), Modules (unidades componibles como ChainOfThought, ReAct, Refine, ProgramOfThought, BestOfN y Parallel que aplican estrategias de razonamiento) y Optimizers (BootstrapFewShot para la síntesis *few-shot*, MIPROv2 para el ajuste conjunto de instrucciones y demostraciones mediante optimización bayesiana, y BootstrapFinetune para la actualización de pesos). Defines una métrica, proporcionas un pequeño conjunto de datos etiquetado, ejecutas el optimizador y obtienes un programa de prompts compilado. DSPy 3.0, lanzado en el Databricks Data + AI Summit en junio de 2025 y seguido por la versión 3.2.0 en abril de 2026, añadió integración con MLflow para observabilidad, *fine-tuning* basado en RL, el optimizador de evolución reflexiva de prompts GEPA y herramientas reforzadas para producción desarrolladas a partir del uso interno de Databricks.

Lo que DSPy realmente hace en abril de 2026

La versión actual es DSPy 3.2.0, que incluye una interfaz de encadenamiento de optimizadores (BetterTogether) que permite secuenciar optimizadores en estrategias personalizadas: por ejemplo, optimización de prompts, luego *fine-tuning*, y después reoptimización (un ciclo "p -> w -> p"). También desacopló LiteLLM como dependencia obligatoria, pasando a ser opcional, lo que reduce el tamaño de instalación y elimina un conflicto de dependencias transitivas que frustraba a muchos usuarios en versiones anteriores. La validación de campos de entrada ahora advierte cuando los valores no coinciden con los tipos de firma declarados, y la primitiva dspy.Reasoning (introducida en 3.1.0) expone el razonamiento nativo de modelos de razonamiento como o3 y Claude Sonnet sin configuraciones adicionales.

La biblioteca de módulos cubre la mayoría de los patrones de razonamiento listos para usar. ChainOfThought obtiene una justificación antes de la respuesta final. ReAct intercala pasos de razonamiento con llamadas a herramientas para bucles de agentes. ProgramOfThought enruta a través de un intérprete de código para problemas con gran carga matemática. BestOfN toma muestras de múltiples finalizaciones y las califica según una métrica. Parallel ejecuta módulos simultáneamente para pipelines sensibles a la latencia. Todos los módulos aceptan backends de LLM arbitrarios a través de la interfaz de LiteLLM, por lo que cambiar de GPT-4o a Claude 3.7 Sonnet o a un modelo Llama que se ejecuta localmente es un cambio de configuración de una sola línea, con la reejecución del optimizador para derivar nuevamente los prompts al estilo del nuevo modelo.

El sistema de optimización distingue a DSPy de cualquier otra herramienta de orquestación de LLM en el mercado. BootstrapFewShot genera demostraciones etiquetadas ejecutando tu programa contra un conjunto de entrenamiento y conservando solo los ejemplos donde la salida supera tu métrica. MIPROv2 va más allá: propone instrucciones candidatas, las evalúa en minilotes utilizando optimización bayesiana y busca conjuntamente sobre el texto de la instrucción y los conjuntos de demostración para cada módulo en tu pipeline simultáneamente. Según el artículo de ICLR 2024, estos optimizadores producen pipelines que superan a las líneas base de prompts manuales en más de un 25% en GPT-3.5 y más de un 65% en Llama 2 13B en tareas representativas. El optimizador GEPA (introducido en 3.0) aplica evolución reflexiva, donde el modelo critica sus propias instrucciones propuestas e itera.

"La ingeniería de prompts es frágil, son 'plantillas' codificadas que no se generalizan, y simplemente no es escalable." - vincirufus, Hacker News, agosto de 2025

Dónde se sitúa DSPy frente a LangChain y LlamaIndex

LangChain es un framework de orquestación: te ofrece abstracciones de cadenas componibles, gestión de memoria, más de 100 integraciones de herramientas preconstruidas y ejecutores de agentes que enrutan entre herramientas mediante el análisis de cadenas o la llamada a funciones. El modelo fundamental es imperativo: escribes una cadena de prompt, la conectas a una cadena de ejecución e iteras editando el texto. No hay optimizador. Cuando quieres que el prompt mejore frente a una métrica, escribes esa lógica tú mismo. LangChain tiene ~90k estrellas en GitHub y el ecosistema de integración más grande de cualquier framework de LLM, pero su manejo de prompts es completamente manual y las cadenas imponen una sobrecarga de ~10ms por llamada (frente a DSPy con ~3.5ms según los benchmarks de Morph LLM, 2025). La comparación se reduce a esto: LangChain optimiza la rapidez con la que puedes construir algo que funcione; DSPy optimiza la fiabilidad con la que esa cosa mejora y sigue funcionando a medida que cambian los modelos.

LlamaIndex es infraestructura RAG: su principal diferenciación es la capa de indexación, con más de 10 tipos de índices (VectorStore, SummaryIndex, KnowledgeGraph, SQL y más), pipelines sofisticados de fragmentación (*chunking*) y *embeddings*, recuperación híbrida con BM25 más búsqueda semántica, y reordenamiento (*re-ranking*). Si tu problema es "cómo ingiero y recupero documentos a escala", LlamaIndex tiene herramientas creadas específicamente para ello. Sus agentes de motor de consulta envuelven esa capa de recuperación en un bucle ReAct. Lo que LlamaIndex no tiene es un optimizador: una vez que has definido tu pipeline RAG, la calidad del prompt es un problema de iteración manual. De hecho, DSPy se puede usar sobre la recuperación de LlamaIndex tratando al recuperador como un módulo compatible con DSPy, lo cual es un patrón documentado en los casos de uso de la comunidad de DSPy y disponible a través de integraciones como el propio LlamaIndex.

Un enfoque útil de la comunidad de ingeniería: los usuarios a menudo combinan la optimización de DSPy con la amplitud de integración de LangChain, o usan DSPy para generar prompts optimizados que luego se implementan en un pipeline de LangChain. Para la observabilidad y el rastreo de las ejecuciones de DSPy en producción, la integración de Databricks se empareja con MLflow, mientras que herramientas de terceros como Langfuse también admiten el rastreo de DSPy de forma nativa. Para los equipos que construyen aplicaciones LLM que necesitan flexibilidad de proveedores de modelos, LiteLLM es el enrutador en el que DSPy delega internamente. Para cargas de trabajo con gran cantidad de agentes donde la coordinación multiagente importa más que la optimización de prompts, AutoGen y CrewAI adoptan enfoques arquitectónicos diferentes que vale la pena comparar.

"Ley de Khattab: Cualquier sistema de IA suficientemente complicado contiene una implementación ad hoc, especificada informalmente y llena de errores de la mitad de DSPy." - Skylar Payne, blog de ingeniería de IA, 2024

Cómo es la realidad del flujo de trabajo de DSPy

Comenzar con DSPy requiere una inversión inicial que es más pronunciada que con LangChain, pero que vale la pena de diferentes maneras. El flujo de trabajo tiene cuatro etapas: definir tu firma, escribir la composición de tu módulo, definir tu métrica y ejecutar el optimizador. Un ejemplo de trabajo mínimo se ve así: escribir `class QA(dspy.Signature): question: str -> answer: str`, instanciar `cot = dspy.ChainOfThought(QA)`, escribir una métrica que verifique la exactitud de la respuesta, llamar a `optimizer.compile(cot, trainset=examples)`. El programa compilado almacena en caché prompts optimizados y demostraciones que se pueden guardar en el disco, controlar en versiones y reproducir exactamente.

La experiencia de depuración ha mejorado significativamente en la versión 3.x. La función `inspect_history()` imprime cada llamada al LLM realizada en la sesión con prompts y respuestas completos. La integración con MLflow (para usuarios de Databricks) registra cada prueba de optimización con entradas, salidas y puntuaciones de métricas, lo que permite auditar por qué el optimizador eligió demostraciones específicas. Las advertencias de validación de tipos en la versión 3.2.0 señalan desajustes de firmas antes de que se conviertan en fallos silenciosos. Aun así, depurar un pipeline multimódulo donde el optimizador tomó decisiones con las que no estás de acuerdo requiere comprender para qué estaba optimizando la búsqueda, lo que exige más conocimiento contextual que depurar un prompt escrito manualmente.

Los costes de optimización varían ampliamente según el optimizador y el tamaño del conjunto de datos. Una ejecución rápida de BootstrapFewShot en 50 ejemplos con GPT-4o-mini como maestro cuesta aproximadamente $1-3. Una ejecución completa de MIPROv2 con generación de instrucciones candidatas en 200 ejemplos puede costar $10-50 dependiendo de la elección del modelo. La documentación da una estimación de $2 para una "ejecución simple típica". Los equipos que ejecutaron MIPROv2 sin leer la guía de costes a principios de 2024 informaron de facturas de API sorprendentes, un problema que la documentación ahora aborda de manera más explícita.

Para quién está creado DSPy

DSPy es ideal para ingenieros de ML e investigadores que piensan en términos de sistemas en lugar de cadenas de texto. Si tienes datos etiquetados, una métrica medible y un pipeline que necesita ser mantenible a medida que los modelos evolucionan, el bucle del optimizador de DSPy ofrece un valor que ninguna cantidad de creación manual de prompts puede igualar. Equipos en empresas como Google, IBM, VMware y Databricks han informado que DSPy hace que el cambio de modelo sea significativamente más barato: cuando se lanza un nuevo modelo, se vuelve a ejecutar el optimizador en lugar de reescribir cada prompt. El framework es especialmente valioso en dominios científicos y de uso intensivo de datos donde los pipelines aumentados por recuperación necesitan una medición sistemática de la calidad. Los investigadores que publican experimentos reproducibles de LLM se benefician de los programas compilados serializables de DSPy que se pueden compartir junto con el código del artículo.

El framework no es una buena opción para la creación rápida de prototipos bajo presión de tiempo. El coste inicial de escribir métricas de evaluación, preparar ejemplos de entrenamiento y comprender las abstracciones del optimizador es real. Como señaló un análisis de un profesional, los equipos "adoptan DSPy directamente, o pueden tomar prestados sus patrones intencionalmente desde el primer día, en lugar de reconstruirlos dolorosamente más tarde". Los productos sin un criterio de éxito programable (chatbots abiertos, asistentes de escritura creativa) no pueden aprovechar el optimizador, lo que elimina el principal diferenciador de DSPy. Python es el único entorno de ejecución de primera clase, aunque en 2025 apareció una adaptación a Go mantenida por la comunidad.

Lo que DSPy no es

DSPy no es un reemplazo para todo LangChain o LlamaIndex. No incluye más de 100 integraciones preconstruidas, no gestiona la memoria de conversación para aplicaciones de chat de múltiples turnos y no proporciona una interfaz de usuario, un *playground* o un servicio alojado. Es una biblioteca de Python. La instalas, escribes en Python, llamas a las API de LLM (a través de LiteLLM, que admite OpenAI, Anthropic, Gemini, Cohere, modelos locales a través de Ollama y la mayoría de los demás proveedores). El despliegue, el servicio y la monitorización están fuera del alcance del propio DSPy, y son manejados por tu propia infraestructura o por la pila de Databricks si estás en ese ecosistema.

Tampoco es un framework para usuarios que quieren evitar pensar en los prompts por completo. DSPy te traslada de escribir prompts manualmente a escribir firmas y métricas, pero aún necesitas entender cómo se ve una buena salida para poder definir la métrica. El optimizador es una búsqueda sobre el espacio de los prompts, no un oráculo que descubre tu caso de uso desde cero. La distinción es importante: DSPy automatiza la tediosa iteración y hace que el proceso sea sistemático y reproducible, pero no reemplaza el conocimiento del dominio.