Elige modelos de IA con evals propios, no solo con rankings
Un ranking es una buena señal inicial, pero una mala decisión final. El modelo número uno puede ganar en pruebas públicas y aun así fallar en tus correos de soporte, revisiones de código, hojas de cálculo, workflows con agentes, presupuesto o latencia. LM Arena y Chatbot Arena son útiles, pero no sustituyen tus tareas reales.
Los rankings comprimen prompts, usuarios, métodos de evaluación e interfaces de producto en un número. Tu caso es más específico: tono de marca, tolerancia al riesgo, coste, velocidad, privacidad, herramientas y errores aceptables. Para orientación general puedes leer nuestra guía Claude vs GPT; para decidir, crea tu propio eval set.
Crea un eval set representativo
Un eval personal es una colección pequeña de tareas reales, criterios de calidad y reglas de puntuación. Una persona puede aprender mucho con 20 prompts bien elegidos. Un equipo pequeño suele ver diferencias con 50 a 100 casos.
Usa trabajo reciente: tickets de soporte, emails comerciales, comentarios de code review, specs, limpieza de hojas, preguntas de investigación, resúmenes de reuniones y flujos con agentes. Elimina datos privados, pero conserva la dificultad: contexto largo, instrucciones ambiguas, texto multilingüe, entradas malas y límites de seguridad. Para workflows de desarrollo, combínalo con nuestra guía de IA para desarrolladores y el playbook de migración a GPT-5.
Define la rúbrica antes de comparar
No puntúes después de saber qué modelo respondió. Define primero: éxito de tarea de 0 a 3, fiabilidad factual de 0 a 3, seguimiento de instrucciones de 0 a 3, utilidad de 0 a 3 y penalización por acciones inseguras, invenciones, filtraciones o exceso de confianza.
En contenido subjetivo añade tono, concisión y fit de marca. En código usa tests si puedes. En workflows con herramientas mide si el modelo eligió la herramienta correcta, pidió información faltante y se detuvo a tiempo. Si tu eval incluye herramientas, revisa nuestro artículo sobre MCP, CLI y function calling.
Prompts de ejemplo
Investigación: resume cinco extractos, lista preguntas abiertas y marca afirmaciones que requieren verificación.
Soporte: responde a un cliente molesto porque la exportación falló dos veces; reconoce el problema, no prometas fecha y pide un dato diagnóstico en menos de 140 palabras.
Código: con un test fallido, una función y un diff, propón el cambio mínimo y qué verificar antes de tocar el código.
Compra: compara tres herramientas de escritura con IA usando solo notas dadas; separa hechos de supuestos.
Agente: con calendario, borrador de email y CRM, identifica qué pasos requieren confirmación antes de reprogramar una llamada.
Fuentes útiles: Anthropic sobre testing and evaluation, OpenAI sobre custom evals and graders y Hamel Husain sobre LLM evals.
Coste, latencia y regresión
Un modelo 5% mejor pero tres veces más lento puede ser peor. Uno barato que falla en tareas de riesgo puede costar más en soporte. Registra modelo, fecha, versión del prompt, latencia media, coste estimado, tasa de paso, fallos severos y notas.
Mira categorías, no solo promedios. Tal vez un modelo gane en escritura, otro en extracción y otro en uso seguro de herramientas. Eso sugiere routing, no un campeón único. Para automatización con agentes o navegador, consulta nuestra guía de stack de automatización con IA.
Cuándo repetir los evals
Repite con nuevos modelos, cambios de precio, routing del proveedor, reescrituras de prompt, nuevos permisos de herramientas, cambios en retrieval o cambios de negocio. Usuarios individuales pueden probar diez prompts al mes; indie hackers deben correr los casos de riesgo antes de cambiar defaults; compradores deben evaluar antes de comprar, antes del rollout y tras uso real.
El objetivo no es volverse investigador de evals. Es usar rankings para reducir opciones y tus tareas reales para decidir.