Yeda AI Tips · #054

Prueba los modelos en tareas difíciles, no en las fáciles

Si estás probando modelos de IA con "resume esto" o "escribe una landing page", no estás probando nada: solo estás marcando una casilla que cualquier modelo de frontera actual ya aprueba. Alguien que prueba a fondo descubrió que los prompts fáciles y bien definidos aplanan el campo por completo. Construye una prueba genuinamente desordenada y las diferencias reales aparecen rápido.

Por qué los prompts fáciles no discriminan

Los modelos de frontera modernos han convergido todos en un buen desempeño para tareas pequeñas, limpias y bien acotadas: ese es exactamente el tipo de trabajo fácil de entrenar y fácil de evaluar, así que todos los proveedores han optimizado para él. Una landing page, un resumen, una función simple: cualquier modelo actual de primer nivel producirá algo razonable. Juzgar modelos con esta clase de tarea te dice que todos son competentes. No te dice nada sobre en cuál deberías confiar realmente para tu trabajo más difícil, más feo y más ambiguo.

La diferencia entre modelos vive en la cola larga: requisitos ambiguos, datos desordenados del mundo real, contexto de múltiples archivos, casos límite para los que nadie escribió una especificación limpia. Los benchmarks fáciles —públicos o privados— ocultan sistemáticamente justo las diferencias que importan para el trabajo real.

Cómo se ve una prueba de estrés de verdad

Alguien que fue más a fondo que una comparación rápida lado a lado construyó un benchmark privado en lugar de apoyarse en prompts de juguete o en tablas de clasificación públicas:

Una migración de datos desordenada que abarcaba cientos de archivos, sembrada deliberadamente con problemas: un archivo JSON corrupto y registros falsos/plantados, incluyendo un cliente llamado "Mickey Mouse", un cliente de prueba con un nombre basura y un pago grande fabricado que no debería haberse tratado como real.
Un informe ejecutivo grande, de múltiples archivos que requería sintetizar información a través de muchas fuentes en lugar de resumir un solo documento.

Los resultados fueron genuinamente mixtos, no una victoria limpia. En la tarea de migración, el modelo bajo prueba detectó los problemas plantados que se suponía específicamente que debía detectar: señaló y rechazó a "Mickey Mouse", al cliente de prueba basura y al pago grande falso. Pero el mismo modelo aún pasó por alto un problema más sutil en el mismo conjunto de datos: códigos de servicio en conflicto, un problema de higiene de datos en el back-end que su esquema de salida ni siquiera contemplaba. Bueno con las trampas plantadas obvias. Todavía flojo con los problemas estructurales más silenciosos por debajo.

Cómo construir tu propia prueba de estrés

Elige tu carpeta o tarea realmente más desordenada, no un prompt de juguete. Si tu tarea es pequeña, limpia y bien definida, concluirás que todos los modelos son intercambiables, y solo tendrás razón sobre la categoría de trabajo equivocada.
Siembra problemas conocidos si puedes, tal como quien probó plantó clientes falsos y un archivo corrupto. Saber exactamente qué debería detectar un buen resultado convierte un vago "¿esto se ve bien?" en un aprobado/reprobado verificable.
Puntúa más que el resultado titular. La prueba de migración no era solo aprobado/reprobado: el modelo pasó la comprobación obvia y falló una más sutil. Registra ambas.
Vuelve a correr tu benchmark privado contra los nuevos lanzamientos de modelos. Una prueba desordenada del mundo real es reutilizable: córrela de nuevo cada vez que un proveedor publica una actualización, en lugar de confiar en las afirmaciones de marketing sobre qué mejoró.

messy task -> model -> human review -> ship

El paso de revisión humana no es opcional

Sea lo que sea que un modelo devuelva, si toca dinero, leyes o datos de producción, un humano lo revisa antes de que se despliegue, punto. La propia conclusión de quien probó, tras encontrar un modelo genuinamente capaz, fue aun así agregar validadores y exigir aprobación humana antes de que cualquier salida se tratara como canónica, precisamente porque "bueno para detectar los problemas obvios" no es lo mismo que "seguro para confiar sin supervisión". Un modelo que hoy rechaza correctamente un pago falso de $25,000 aún puede pasar por alto un problema estructural más silencioso en la misma corrida.

Trampas

Extrapolar de un prompt fácil a "estos modelos son básicamente iguales". Puede que lo sean, para esa tarea estrecha, y completamente distintos para el trabajo que realmente te importa.
Probar solo la corrección en el camino feliz. Las fallas más útiles en este tipo de prueba de estrés son las sembradas específicamente para ser tentadoras de equivocar.
Tratar un buen aprobado de benchmark como permiso para saltarse la revisión humana en salidas de alto riesgo. Quien construyó la prueba de migración aun así agregó una puerta de aprobación humana después de que el modelo se desempeñara bien.

Conclusión

Un prompt limpio no prueba nada: todos los modelos ya lo aprueban. Tu tarea real más fea y desordenada lo prueba todo: profundidad de razonamiento, manejo de la ambigüedad y cómo se comporta ante las trampas plantadas que un prompt de juguete nunca revelaría. Construye esa prueba una vez, córrela de nuevo contra cada modelo que estés considerando y mantén a un humano en el circuito para cualquier cosa que toque dinero, leyes o datos de producción.

Recursos

¿Estás construyendo una función con IA? Yeda AI diseña, audita y despliega sistemas LLM en producción.

Habla con nosotros · Lee el blog