Evaluación y optimización de agentes: comparación de DSPy, TextGrad, Reflexion y OPRO

Los equipos rara vez pasan directamente a la evaluación y optimización automatizadas de los agentes. El camino habitual es gradual: primero se utilizan prompts inteligentes y algunos experimentos puntuales, luego mediciones repetibles, seguidas de ajustes dirigidos, y finalmente se tiene suficiente confianza como para implementar los cambios de forma controlada.

Por lo general, comienza con un agente que cuenta con un prompt de sistema sólido, un puñado de herramientas y una demostración impresionante. Eso es un buen punto de partida, pero no resuelve muchos problemas. A medida que más personas dependen del agente, las preguntas se vuelven más prácticas: ¿qué flujos de trabajo resisten y cuáles fallan con mayor volumen de trabajo? ¿Qué ocurre con el comportamiento cuando se actualiza el modelo subyacente? ¿Funciona bien el agente en los casos más importantes para las operaciones, el control de riesgos o los clientes?

La ingeniería de prompts es una habilidad fundamental y valiosa, pero la verdadera madurez se logra al integrar al agente en un ciclo de mejora disciplinado. Un agente que puede ser evaluado de manera sistemática puede mejorarse también de forma sistemática, y uno que se puede mejorar así puede gestionarse con mucha más confianza. Por lo tanto, el objetivo no es solo obtener mejores prompts; se trata de un ciclo de aprendizaje controlado para los sistemas de modelos de lenguaje: decidir qué significa “bueno”, medir el comportamiento en función de ese criterio, aplicar optimizaciones dirigidas y mantener registros suficientes para confiar en los resultados.

Cinco enfoques comparten este principio: DSPy con sus optimizadores MIPRO y COPRO, TextGrad, Reflexion y OPRO. Sus mecanismos, nivel de madurez y adecuación operativa difieren, pero cada uno responde a una misma pregunta: ¿cómo puede un agente pasar de ajustes manuales de prompts a mejoras repetibles basadas en métricas?

La evaluación está en el centro de cada ciclo

La forma más sencilla de considerar estos métodos como una misma familia es como búsquedas diferentes sobre el comportamiento del agente. Todos ellos presuponen los mismos cuatro elementos.

• Algo modificable: un programa de agente, una instrucción, un flujo de trabajo o una política de toma de decisiones.
• Un conjunto de tareas, un conjunto de evaluación, que representa lo que se espera que haga el agente.
• Un criterio de medición, ya sea métrico, rúbrica, recompensa o regla de éxito, que distingue los resultados mejores de los peores.
• Un optimizador, explícito o implícito, que propone cambios basados en las puntuaciones anteriores.

Vistos de esa manera, estas técnicas se refieren más a la optimización en bucle cerrado que a la formulación de instrucciones. En una empresa, crear una instrucción mejor rara vez es la parte difícil. Encontrar una forma reproducible de mejorar el comportamiento en muchas tareas sí lo es, porque cada mejora tiene un costo en otro aspecto:

• precisión frente a latencia

calidad en relación con el gasto

cobertura contra el sobreajuste

autonomía frente al control

generalidad amplia frente a ajustes específicos para tareas

un paso mejorado localmente frente a la fiabilidad del sistema completo

Por lo tanto, es mejor considerar estas bibliotecas como posiciones dentro de un espacio de diseño para mejorar los agentes, y no como trucos competitivos en las instrucciones proporcionadas.

Por qué aumenta la presión

Los primeros proyectos de agentes empresariales suelen basarse en la intuición de expertos. Un profesional cualificado reescribe las instrucciones, ajusta las descripciones de las herramientas, agrega ejemplos y vuelve a probar hasta que el resultado parezca aceptable. Para uno o dos casos de uso, eso es suficiente.

Se vuelve problemático cuando varios equipos desarrollan agentes al mismo tiempo, cuando los prompts varían entre entornos, cuando los datos de evaluación quedan dispersos, cuando los equipos tienen concepciones diferentes sobre qué es la calidad, cuando una actualización del modelo modifica el comportamiento de formas impredecibles, o cuando los registros de auditoría y la confianza en las versiones comienzan a tener importancia real.

Entonces se necesita algo similar a una disciplina MLOps, adaptada a sistemas basados en modelos de lenguaje. Las pruebas habituales de software son necesarias pero insuficientes, y la evaluación clásica del aprendizaje automático ayuda aunque no abarca todo. Los agentes añaden sus propios elementos dinámicos: prompts, llamadas a herramientas, comportamiento de recuperación de información, estructura de planificación, memoria, intentos repetidos y sensibilidad al modelo específico. La evaluación y optimización automatizadas ofrecen herramientas prácticas para controlar esa variabilidad.

Las cuatro técnicas principales

DSPy con MIPRO y COPRO: optimizando el programa

Dentro de estas herramientas, DSPy va más allá al hacer que el comportamiento del modelo sea programable en lugar de improvisado. Los prompts dejan de ser cadenas únicas y los pipelines se declaran de manera estructurada, lo que proporciona una superficie adecuada para realizar mejoras.

MIPRO y COPRO son los optimizadores automatizados de ese ecosistema. MIPRO ajusta prompts, instrucciones y demostraciones de pocos ejemplos en función de una métrica, y es adecuado para equipos cuya definición de tareas es bastante estable y que desean que un algoritmo encuentre configuraciones de prompts mejores que las que una persona podría establecer a mano. COPRO perfecciona prompts y programas siguiendo líneas similares. La idea subyacente es la misma: el programa se convierte en un objeto que puede compilarse, ajustarse y reevaluarse, en lugar de solo editarse manualmente.

En la práctica, esto permite una compilación automática de prompts, la selección de ejemplos de tipo few-shot, el ajuste basado en instrucciones, la mejora guiada por métricas y una separación más clara entre la lógica de la tarea y el prompt optimizado final. La ventaja es la reproducibilidad, una base más sólida para la evaluación fuera de línea, menos dependencia de la elaboración manual de prompts y una optimización que se asemeja más a la ingeniería que a métodos artesanales.

Para una empresa que busque un flujo de trabajo de optimización interno serio en lugar de un montón de prompts elaborados a mano, DSPy es uno de los candidatos más fuertes, especialmente para tareas que se ajustan a módulos repetibles y métricas estables. Sin embargo, tiene sus limitaciones: funciona mejor cuando una tarea está lo suficientemente estructurada como para que un conjunto de evaluación guíe la búsqueda, y no es tan mágico como parece. Con una señal débil, parcial o desalineada, el optimizador simplemente mejora en lo incorrecto.

TextGrad: la crítica como gradiente

TextGrad sigue un enfoque más audaz. En lugar de gradientes numéricos, se basa en críticas escritas y señales de actualización para mejorar los prompts y los componentes similares a prompts. La lógica es elegante: si un modelo puede indicar qué está mal en un resultado y cómo corregirlo, esos comentarios pueden servir como señales de optimización.

Permite el perfeccionamiento repetido del texto del prompt, actualizaciones al estilo de optimizador, y el trabajo con prompts de sistema, rúbricas, planes e incluso instrucciones de evaluación. La optimización se convierte en un proceso iterativo en lugar de una búsqueda única. Es adecuado para casos en los que es más fácil expresar la retroalimentación adecuada con palabras que con números, y puede mejorar tanto la rúbrica del evaluador como el prompt de la tarea.

Es mejor considerarlo como una herramienta primitiva prometedora y no como una solución definitiva para toda la empresa. Resulta útil cuando los equipos desean perfeccionar las instrucciones, los planes y los criterios de evaluación a través de retroalimentación basada en el lenguaje, pero no constituye la opción predeterminada obvia para toda la organización. Su principal fortaleza es también su mayor riesgo: la señal de actualización proviene del propio lenguaje, generado por un modelo. Sin un mecanismo de evaluación estructurado, esto puede hacer que la optimización sea menos estable, menos interpretable y más difícil de auditar.

Reflexión: aprender de los intentos fallidos

Reflexion difiere de las dos anteriores. Su enfoque no está en la compilación offline de instrucciones, sino en la auto-mejora en tiempo real, impulsada por la reflexión sobre los fracasos. Tras un intento fallido, el agente escribe una crítica, y esa reflexión memorizada guía los intentos posteriores. El resultado es un ciclo de aprendizaje sencillo que no requiere ajuste fino del modelo.

Ofrece la posibilidad de intentar nuevamente con autocrítica, un registro de los modos de fallo anteriores, la corrección de la trayectoria del agente y su adaptación dentro o entre intentos. Muchos problemas de agentes no son en absoluto problemas de respuesta inmediata; se trata de problemas de ejecución, como pasos de razonamiento deficientes, uso incorrecto de herramientas o omisión de verificaciones, y la reflexión ayuda a superarlos. Además, acerca el aprendizaje a las condiciones reales de operación en mayor medida que los benchmarks offline por sí solos.

Para los agentes que funcionan como flujos de trabajo en lugar de generadores de una sola respuesta, Reflexion es sumamente relevante, especialmente cuando es viable intentar nuevamente y recopilar patrones de fallos recurrentes aporta valor. Por lo general, se presenta como un patrón implementado en código, y no como una biblioteca canónica; por eso, una empresa debería tratarlo como un patrón de diseño para estandarizarlo en su capa de orquestación, y no como una decisión del proveedor. El peligro radica en el ruido: la autocrítica ilimitada genera retrasos, costos e incoherencias. La reflexión debe estar guiada por políticas, activarse de forma selectiva y evaluarse como cualquier otro comportamiento.

OPRO: un modelo como optimizador

OPRO, abreviatura de Optimization by PROmpting, convierte a un modelo de lenguaje en el optimizador. Propone mejores opciones de prompts utilizando el historial de calificaciones anteriores, de modo que un modelo busca entre las instrucciones posibles para otro modelo o programa.

Cubre la búsqueda por prompts, la generación y clasificación de candidatos, así como la mejora iterativa. Su lógica se basa en el hecho de que los modelos de lenguaje son buenos para proponer alternativas de redacción, por lo que se genera rápidamente un espacio de búsqueda diverso y el enfoque se adapta a muchos tipos de tareas.

OPRO es estratégicamente interesante, aunque suele formar parte más del conjunto de herramientas para experimentación que del stack de plataformas estándar. Tiende a aparecer en código de tipo investigativo o bucles personalizados, y no en bibliotecas de producción estandarizadas. Su mejor uso podría ser como componente de búsqueda controlada dentro de un servicio de optimización más amplio, y no como primitiva independiente ofrecida directamente a los desarrolladores.

Dos formas de ordenar las opciones

Las técnicas pueden organizarse según dos ejes: dónde tiene lugar la optimización y qué es lo que se está optimizando.

Por ubicación:

• La optimización sin conexión abarca DSPy con MIPRO y COPRO, TextGrad y OPRO.
• La adaptación en tiempo de ejecución o por episodio es el ámbito en el que se utiliza Reflexion.
• También es posible un uso híbrido, ya que las señales generadas por Reflexion pueden recopilarse sin conexión y suministrarse a bucles de tipo DSPy-, TextGrad- u OPRO.

Por objetivo:

• El texto de la instrucción y las indicaciones son manejados por MIPRO, COPRO, TextGrad y OPRO.
• Los ejemplos de pocos casos se ajustan con MIPRO y COPRO.
• La estructura del programa y los componentes de la cadena de procesamiento corresponden al ecosistema más amplio de DSPy.
• Las trayectorias de ejecución y la recuperación de errores son responsabilidad de Reflexion.

El patrón común en ambas tablas es que estos métodos se complementan entre sí, siempre y cuando formen parte de la arquitectura de control adecuada.

Sigan midiendo y mejorando como capas separadas

El error arquitectónico más costoso es adoptar la optimización antes de contar con un método de evaluación fiable. Con una evaluación deficiente, la optimización se vuelve peligrosa, ya que el optimizador mejorará cualquier indicador con el que cuente, incluidos aquellos no relacionados con el verdadero valor empresarial. Un diseño sólido divide la tarea en dos capas.

La estructura de evaluación define y ejecuta las mediciones. Debe contener conjuntos de datos de referencia y tareas representativas, métricas y rúbricas específicas para cada tarea, registros de las trayectorias de los agentes, indicadores de costo, latencia y fiabilidad, análisis a nivel detallado para subpoblaciones o modos de fallo importantes, además de puntos de liberación con detección de regresión.

La estructura de optimización toma los resultados de la evaluación y propone y valida mejoras. Su alcance incluye: ajustar los prompts, seleccionar ejemplos, establecer políticas de reflexión durante la ejecución, generar y buscar candidatos, seguir de cerca los experimentos y definir reglas de promoción que deciden cuándo un candidato prometedor se convierte en la opción predeterminada aprobada.

La separación es importante porque la evaluación es una capacidad de gobernanza, mientras que la optimización es un mecanismo para el cambio. Una empresa necesita ambas cosas, y confundirlas es un error.

Una lista reducida

En el caso de un stack empresarial práctico, a diferencia del enfoque académico, la lista de candidatos debe reducirse drásticamente. No toda idea de investigación prometedora merece ser una dependencia de primera categoría en la plataforma.

DSPy como el marco de optimización principal. Ofrece la estructura más sólida para tratar los programas de modelo como artefactos que pueden ser optimizados. MIPRO y COPRO se relacionan directamente con el ajuste práctico de instrucciones y ejemplos, y todo este enfoque se adapta mejor a flujos de trabajo internos repetibles que a instrucciones puntuales. Su función es servir como motor predeterminado para tareas estables, como base para la compilación de instrucciones fuera de línea, y como abstracción principal para equipos que buscan mejoras repetibles basadas en métricas.

La reflexión como patrón estándar en tiempo de ejecución. No tiene por qué ser una dependencia independiente. Aborda un problema distinto al de DSPy, concretamente la recuperación durante la ejecución, y ayuda a los agentes que utilizan herramientas y a los flujos de trabajo de múltiples pasos. Se integra en capas de orquestación como LangGraph o ejecutores de Python simples. Su función es: una política selectiva de intentos repetidos y reflexión para los agentes de flujos de trabajo, una fuente de datos estructurados sobre fallos para un ajuste posterior fuera de línea, y una forma estándar de realizar una autocorrección limitada.

TextGrad como opción avanzada y experimental. Ofrece un primitivo de refinamiento novedoso que resulta útil para prompts, rúbricas o planes que se benefician de la iteración impulsada por críticas. Es mejor añadirlo una vez que exista un sistema de evaluación estable. Su función es ser una herramienta especializada para equipos de optimización, aplicada en situaciones en las que los comentarios escritos son más detallados que una simple puntuación.

OPRO, con prioridad menor como estándar de la plataforma. A menudo es más adecuado como modo de optimización interna que como opción de biblioteca central. Muchas de sus ideas pueden replicarse mediante bucles de búsqueda personalizados alrededor de un marco de evaluación más robusto, y no constituye la opción predeterminada más natural para los desarrolladores promedio. Si se utiliza, debería servir como estrategia de búsqueda dentro de un servicio de optimización central, o como capacidad de experimentación para los equipos de la plataforma.

Sobre qué construir

Los desarrolladores no deberían tener que armar estas técnicas a partir de bibliotecas básicas en cada proyecto. La mayoría de los equipos no necesitan cinco paradigmas de optimización en la capa de aplicación. Lo que requieren es un framework interno más simple que resuelva cómo se define, mide, mejora y promueve la calidad de los agentes. La solución sensata es una plataforma interna ligera pero bien definida, construida sobre un conjunto selectivo de bibliotecas. Esta debería ocultar la complejidad accidental al tiempo que estandariza los controles que son importantes.

1. Un SDK de evaluación. Una forma compartida de definir tareas, conjuntos de datos y métricas para los agentes. Estándariza el esquema de casos de prueba, las salidas esperadas o las rúbricas de calificación, el formato de registro de trazas, la captura de costos y latencias, la versionación de los conjuntos de datos y las líneas base para pruebas de regresión. El objetivo: que un equipo pueda describir su agente, su conjunto de evaluación y su medida de éxito sin tener que crear un mecanismo personalizado.

Un servicio de optimización. Se trata de un servicio controlado que ejecuta tareas de optimización para que los equipos no tengan que configurar sus propios ciclos. Permite el ajuste de prompts y ejemplos basado en DSPy, un refinamiento opcional con TextGrad, búsquedas inspiradas en OPRO, comparación de experimentos con informes al estilo tabla de clasificación, y flujos de trabajo para la aprobación de candidatos. Un desarrollador puede solicitar el ajuste de un agente en una versión fija de conjunto de datos, dentro de límites definidos en cuanto a tiempo de respuesta y costo, y recibir candidatos que puedan compararse directamente.

Una capa de política de reflexión en tiempo de ejecución. El comportamiento similar a la reflexión se convierte en una configuración en lugar de código personalizado en cada agente. Las políticas determinan cuándo se permiten las reintentos, cuándo entra en acción la reflexión, cuántos reintentos se autorizan, qué información de fallos anteriores se mantiene y cuándo es necesario recurrir a un humano o a un flujo de trabajo alternativo. Los equipos cuentan con una autocorrección estructurada a través de plantillas y evitan crear lógicas de reintentos incoherentes.

Un registro de prompts y políticas. Los prompts, las rúbricas y los artefactos de optimización se tratan como activos regulados: almacenamiento versionado, seguimiento desde el prompt hasta el experimento y su lanzamiento, notas sobre compatibilidad de modelos, soporte para reversión y registros de aprobación para las variantes en producción. De este modo, los prompts funcionan como configuraciones desplegables, y no como texto copiado entre cuadernos de notas y repositorios.

Conexión con el plano de control empresarial. El framework se conecta con puntos de control de CI/CD, herramientas de observabilidad, catálogos de modelos, gestión de secretos y entornos, controles de gobernanza de datos y flujos de trabajo de aprobación para usos de alto riesgo. Esa conexión separa una biblioteca de técnicas de una capacidad empresarial real.

Para la mayoría de los desarrolladores, esto se reduce a cuatro conceptos: definir el contrato del agente, proporcionar casos de evaluación, elegir un modo de optimización y revisar el candidato seleccionado junto con su informe de despliegue. Debajo de todo esto, puede estar en juego cualquiera de las cuatro técnicas, pero lo que ven los desarrolladores debe mantenerse sencillo. El problema de escalabilidad rara vez se debe a una falta de algoritmos; se debe a la dispersión de bucles de mejora personalizados e inconsistentes entre los equipos.

Despliegue por fases

Etapa uno: disciplina de evaluación. Antes de realizar cualquier optimización a gran escala, establezca esquemas de evaluación compartidos, conjuntos de datos de referencia cuidadosamente seleccionados, captura y reproducción de trazas, además de valores de referencia para el costo, la latencia y la calidad de las tareas.

Etapa dos: optimización offline con DSPy. Haga que DSPy, junto con MIPRO y COPRO, sea la vía principal para las clases de tareas estables, abarcando la compilación de instrucciones, la selección de ejemplos, el ajuste de instrucciones y la comparación reproducible de experimentos.

Etapa tres: reflexión durante el tiempo de ejecución con límites. Introduzca políticas al estilo de Reflexion para agentes cuyos fallos a menudo pueden corregirse mediante intentos repetidos con retroalimentación, intentos selectivos, memoria de reflexión estructurada y diagnósticos a nivel de trayectoria.

Etapa cuatro: modos avanzados, con moderación. Añada TextGrad y búsquedas similares a OPRO únicamente cuando exista una necesidad clara y la evaluación esté lo suficientemente desarrollada como para gestionarlos. Por lo general, esto debería seguir siendo una funcionalidad exclusiva del equipo de la plataforma antes de estar al alcance de los desarrolladores en general.

Dónde surgen los problemas

• Sobreajuste de métricas. Un punto de referencia estrecho o obsoleto enseña al optimizador ese punto de referencia en lugar de la tarea real.
• Rúbricas frágiles. Si la calificación depende de modelos evaluadores débiles o inconsistentes, la optimización termina adaptándose a las peculiaridades de esos evaluadores.
• Ganancias locales, pérdidas globales. Ajustar una subtarea puede aumentar silenciosamente los costos o ralentizar otros pasos, o cambiar la forma en que funciona el resto del flujo de trabajo.
• Reflexión ruidosa. La reflexión sin límites definidos genera más tokens y más retrasos con pocos beneficios reales.

Fragmentación organizacional. Cuando cada equipo elige sus propias bibliotecas de optimización y convenciones de evaluación, la empresa pierde la capacidad de comparación y el control.

Todo esto lleva a la misma conclusión: la optimización solo es tan eficaz como la evaluación y la gobernanza que la rodean.

La forma de la solución

Lo que une a DSPy, MIPRO, COPRO, TextGrad, Reflexion y OPRO no es que cada uno mejore los prompts; cada uno intenta convertir la mejora de los agentes en un sistema de retroalimentación. El paso estratégico no consiste en exponer cada idea a todos los desarrolladores, sino en crear un marco interno controlado donde la evaluación esté estandarizada, la optimización sea selectiva, la reflexión en tiempo de ejecución siga políticas definidas y las variantes de prompts se gestionen como activos de producción.

Para una recomendación más precisa, la estrategia más sólida es dejar que DSPy, junto con MIPRO y COPRO, se encargue de la optimización offline, adoptar Reflexion como patrón de tiempo de ejecución compartido para la autocorrección limitada, reservar TextGrad para equipos especializados, y tratar a OPRO principalmente como una técnica de búsqueda interna en lugar de una dependencia dirigida a desarrolladores. Los mejores agentes empresariales se decidirán según la calidad del ciclo de retroalimentación que los rodee, siendo la agilidad en la resolución de problemas mucho menos importante.