Elige un modelo con pruebas

Define la decisión

Comparar modelos requiere un uso concreto. Un modelo que explica bien una función pequeña puede no resolver igual de bien un cambio grande en el repositorio. Uno de menor coste puede cumplir los requisitos de calidad de transformaciones rutinarias. Una investigación difícil puede necesitar más capacidad de razonamiento.

Escribe primero la tarea y sus restricciones. Incluye los datos permitidos, las herramientas necesarias, el tiempo de respuesta y el coste máximo aceptable. Algunas restricciones son obligatorias. No compenses una restricción de tratamiento de datos con una puntuación alta en otro aspecto.

Usa tareas representativas

Construye un conjunto pequeño de evaluación con trabajo que tu equipo realice de verdad. Elimina los datos sensibles, salvo que el entorno de evaluación esté autorizado para tratarlos. Incluye tareas sencillas, difíciles y otras cuya respuesta correcta sea pedir información que falta.

Para un servicio ficticio de informes, usa un defecto conocido de fechas, una función pequeña de filtrado y la explicación de una regla de autorización. Prepara el resultado esperado antes de ejecutar la comparación. Incluye una prueba negativa que rechace el defecto conocido.

Reserva algunas tareas fuera del desarrollo del prompt. Si lo ajustas repetidamente con todos los ejemplos, la puntuación final puede exagerar el rendimiento general. Un conjunto separado ayuda a saber si el prompt mejorado funciona más allá de los ejemplos usados para crearlo.

Mantén una comparación justa

Registra la versión exacta del modelo, el prompt, el contexto proporcionado, las herramientas y los permisos. Usa estados iniciales equivalentes. Si un modelo recibe un repositorio completo y otro un archivo, el resultado compara tanto flujos de trabajo como modelos.

Comparar flujos puede ser útil. Identifica correctamente qué estás comparando. Un producto basado en agentes incluye más que un modelo: la selección de contexto, las herramientas, los límites de ejecución y el comportamiento de recuperación pueden influir en el resultado.

Repite las ejecuciones cuando la variación de resultados sea relevante. Registra los intentos fallidos en vez de mostrar solo el mejor resultado. Para criterios subjetivos, usa una rúbrica escrita y más de una persona revisora cuando sea viable.

Evalúa la calidad antes que la velocidad

Primero, comprueba los criterios de aceptación obligatorios. ¿Cumple el cambio el requisito? ¿Conserva los controles de acceso? ¿Pasan las pruebas pertinentes? ¿Puede entender el diff quien lo revisa?

Después, compara esfuerzo, tiempo transcurrido y coste de los resultados aceptables. Incluye los reintentos y la revisión humana. Una respuesta barata que necesita correcciones repetidas puede resultar cara al considerar la tarea completa.

Los benchmarks públicos pueden ayudar a identificar candidatos. Usan conjuntos de tareas y métodos de puntuación concretos. No trates su puntuación como una medida directa de la productividad de tu equipo.

Registra la decisión y cuándo deja de ser válida

El resultado puede ser una recomendación limitada. Por ejemplo: «Usa este modelo para añadir pruebas pequeñas en este repositorio, con los requisitos de revisión actuales». No necesitas un único modelo para todas las tareas.

Indica qué exigiría otra evaluación. Por ejemplo, un cambio de versión del modelo, otra configuración de herramientas, una nueva categoría de datos o un patrón persistente de fallos. Mantén una alternativa para las tareas que superen la capacidad del modelo seleccionado.

La evaluación pretende reducir la incertidumbre sobre una decisión real. Evita una competición permanente entre modelos que consuma más esfuerzo que el trabajo al que ayuda.