Especificaciones de las pruebas
Dimensiones de evaluación
| Dimensión | Categoría | Descripción |
|---|---|---|
| Fricción de configuración | Proceso | Puntuación determinada por la capacidad del agente para completar la tarea de forma autónoma. Si el agente se detuvo para hacer preguntas o encontró errores, la puntuación disminuyó. |
| Velocidad de configuración | Proceso | Puntuación determinada por el tiempo de ejecución activa del agente. Los resultados son comparables entre entornos. |
| Eficiencia | Proceso | Puntuación determinada por la cantidad de llamadas a herramientas necesarias para completar la tarea. Menos llamadas a herramientas implican menos costo y menos complejidad. |
| Recuperación ante errores | Proceso | Puntuación determinada por errores de infraestructura (límites de frecuencia, tiempos de espera) que interrumpieron la ejecución. |
| Corrección | Resultado | Puntuación determinada por si el código generado importa paquetes reales, llama a métodos reales y conecta correctamente los componentes. |
| Alucinación | Resultado | Puntuación determinada por si el agente inventó paquetes que no existen o usó variantes de SDK incorrectas. |
| Seguridad | Resultado | Puntuación determinada por si el agente dejó secretos codificados de forma fija, almacenó tokens de forma insegura o incluyó credenciales en el código fuente. |
Calificaciones
| Calificación | Puntuación mínima | Descripción |
|---|---|---|
| A | 90 | Lista para producción. Problemas mínimos. |
| B | 75 | Sólida, pero con algunos aspectos por corregir. |
| C | 60 | Utilizable, pero necesita pulirse. |
| D | 40 | Problemas importantes. |
| F | < 40 | No es útil — es más rápido empezar desde cero. |
Validación de resultados
- Comprobaciones de presencia: Los símbolos del SDK, las importaciones y las claves de configuración requeridos están presentes en el resultado.
- Detección de alucinaciones: Se detectan paquetes inventados, variantes incorrectas del SDK y métodos de API inexistentes.
- Comprobaciones de seguridad: Se marcan las credenciales codificadas de forma fija, los tokens almacenados de forma insegura y los secretos en el código fuente.
- Validación estructural: El código está correctamente ensamblado: los componentes adecuados en los archivos correctos, los hooks del ciclo de vida gestionados y el middleware en el orden correcto.
- Corrección de versión: El agente usa las API actuales, no patrones obsoletos (solo se comprueba cuando el agente tiene acceso a la documentación actual).
- Revisión integral: Un juez de LLM evalúa la corrección general de la implementación.
Coste y tiempo estimados
Costo estimado
Tiempo estimado
- La latencia de la API del proveedor del modelo y los límites de frecuencia
- La cantidad de llamadas a herramientas necesarias (varía según la complejidad de la tarea)
- Las condiciones de red entre el entorno de evaluación y el proveedor del modelo
- La profundidad de la cola y la carga del proveedor