Desarrollo de agentes basado en evaluaciones: Cómo dejé de ajustar prompts por intuición

Cambié un prompt. La siguiente ejecución se vio mejor. ¿Ayudó el cambio o simplemente tuve suerte?

Durante mucho tiempo, mi respuesta fue "creo que sí". Retocaba un comando, ejecutaba el pipeline, veía que funcionaba y lo lanzaba. Esto es ingeniería basada en la intuición. Casi todos los que construyen agentes hacen esto porque la alternativa parece difícil.

Pero los agentes de programación son no deterministas. Puedes ejecutar la misma tarea dos veces y obtener dos resultados diferentes. Una sola ejecución exitosa no te dice nada. No puedes saber si tu cambio funcionó o si simplemente los dados rodaron a tu favor.

Resolví esto aplicando la disciplina del aprendizaje automático. Construí un framework de evaluación para envolver todo mi sistema.

Así es como funciona el framework:

• Target (Objetivo): Una base de código congelada. Esta se mantiene igual para que las puntuaciones sigan siendo comparables. • Task (Tarea): Un elemento de benchmark específico con un prompt y un oráculo. • Oracle (Oráculo): Una comprobación determinista. Son comandos de shell que deben pasar. • Variant (Variante): El cambio específico que estás probando, como un nuevo planificador. • Trial (Ensayo): Una única ejecución. Ejecuto cada tarea varias veces para tener en cuenta la aleatoriedad.

Utilizo dos tipos de puntuación para detectar diferentes fallos:

  • Code Graders (Deterministas): Comprueban las tasas de aprobación de las pruebas, el coste, el tiempo y los cambios en los archivos.
  • LLM Judge (Probabilístico): Un modelo separado y fijo puntúa la calidad de la especificación y la fidelidad de la implementación.

Los code graders te dicen si el código funciona. El judge te dice si el código es bueno. Necesitas ambos.

También dejé de usar promedios. Las medias mienten sobre los agentes. Si una tarea tiene éxito 2 de cada 3 veces, parece estar bien. Pero no es fiable. En su lugar, utilizo dos métricas:

  • pass@k: ¿Tuvo éxito el agente al menos una vez? (Capacidad)
  • pass^k: ¿Tuvo éxito el agente todas y cada una de las veces? (Fiabilidad)

Un salto en pass^k es la verdadera victoria. Significa que has hecho que el agente sea consistente, no solo que haya tenido suerte.

Para mantener el sistema afilado, añado tareas difíciles que requieren una comprensión profunda. Cuando un agente falla ante un error real, convierto ese fallo en una tarea permanente. Esto crea un bucle cerrado. El benchmark se vuelve más difícil a medida que el agente mejora.

Esta infraestructura requiere mucho trabajo, pero es lo que más apalancamiento me ha dado. Transformó el "creo que esto es mejor" en "esto es un 20% más fiable a un coste menor".

Los agentes de programación son fáciles de demostrar, pero difíciles de confiar. Si quieres ir más allá de las demostraciones, debes decidir medir.

Fuente: https://dev.to/rickjms/eval-driven-agent-development-how-i-stopped-tuning-prompts-on-vibes-1189

Comunidad de aprendizaje opcional: https://t.me/GyaanSetuAi