Hay más de 200 modelos de lenguaje disponibles públicamente en este momento. OpenAI, Anthropic, Google, Meta, Mistral, Cohere y docenas de laboratorios más pequeños publican nuevas versiones con regularidad. Cada uno llega con un press release explicando por qué supera a sus competidores en algún benchmark. Y casi siempre es verdad: todos son mejores en algo. Pero eso no te dice si el modelo es bueno para lo que tú necesitas.

Esta guía no es sobre qué modelo es "el mejor" en abstracto. Es sobre cómo construir un proceso de evaluación que responda a la pregunta que realmente importa: ¿cuál modelo produce los mejores resultados en mi caso de uso específico?

Por qué los benchmarks públicos son insuficientes

Los benchmarks como MMLU, HumanEval, GSM8K o ARC son herramientas valiosas para comparaciones rápidas entre modelos. El problema es que miden rendimiento en tareas genéricas estandarizadas, no en tu tarea específica. Un modelo que puntúa 90 en MMLU puede ser significativamente peor que uno que puntúa 83 para resumir documentos legales en español, detectar anomalías en registros financieros o responder preguntas sobre tu catálogo de productos.

Adicionalmente, los laboratorios conocen estos benchmarks y sus modelos se entrenan (o se ajustan) sabiendo que serán medidos con ellos. El fenómeno se llama "benchmark contamination" y significa que los números que ves en los leaderboards públicos a menudo sobreestiman el rendimiento en condiciones reales.

Los cinco ejes de evaluación que realmente importan

1. Fidelidad factual y tasa de alucinación

La capacidad de un modelo para decir "no sé" o "no tengo esa información" en lugar de inventar respuestas plausibles es uno de los criterios más críticos para aplicaciones en producción. Mídelo con preguntas que sabes que el modelo no puede responder correctamente (eventos recientes, datos internos de tu empresa, preguntas con respuesta negativa). Cuenta con qué frecuencia el modelo inventa una respuesta versus reconoce su ignorancia.

Algunos modelos como Claude 3.5 Sonnet y GPT-4o han mejorado significativamente en esto, pero ninguno ha resuelto el problema completamente. Para aplicaciones críticas, combina siempre el LLM con un sistema de recuperación (RAG) que le proporcione contexto verificado.

2. Seguimiento de instrucciones y restricciones

¿Cuántas instrucciones complejas puede seguir el modelo simultáneamente sin "olvidar" alguna? Un prompt que incluye formato específico, restricciones de longitud, tono particular, lista de temas a evitar y estructura de salida determinada es un reto que diferencia mucho a los modelos. Construye un conjunto de prompts de evaluación con 5–10 restricciones simultáneas y mide la tasa de seguimiento completo.

3. Coherencia en conversaciones largas

En aplicaciones conversacionales, los modelos degradan su rendimiento a medida que el contexto se alarga. La "ventana de contexto" que anuncia el fabricante (128K tokens, 200K tokens) no significa que el modelo preste igual atención a toda esa ventana. Prueba preguntas sobre información introducida al principio de una conversación larga y observa si el modelo la recuerda correctamente.

4. Latencia y coste de inferencia

Un modelo excelente que cuesta 0.06 USD por cada mil tokens de salida es impracticable para aplicaciones de alto volumen. Un modelo competente que cuesta 0.001 USD y responde en 400ms puede ser la elección correcta. Calcula el coste real de tu caso de uso estimando el número de solicitudes diarias, los tokens promedio de entrada y salida, y el presupuesto disponible. Incluye también el coste de los errores: si el modelo falla el 15% de las veces y cada fallo requiere revisión humana, ese coste debe entrar en el cálculo.

5. Comportamiento en casos límite y adversariales

Los sistemas de producción reciben inputs inesperados: texto con errores tipográficos graves, preguntas ambiguas, instrucciones contradictorias, intentos de manipulación del sistema. ¿Cómo se comporta el modelo cuando el input no es el ideal? Dedica parte de tu evaluación a casos límite deliberados: preguntas muy cortas, preguntas muy largas, inputs en múltiples idiomas mezclados, preguntas con premisas falsas.

Construyendo tu golden dataset de evaluación

La herramienta más valiosa que puedes desarrollar es un "golden dataset": un conjunto de 50–200 pares entrada/salida esperada representativos de tu caso de uso real. Lo construyes tomando ejemplos reales de tu aplicación (o creando ejemplos representativos) y definiendo criterios claros de qué constituye una buena respuesta.

Este dataset te permite:

  • Comparar modelos de forma reproducible con el mismo conjunto de pruebas
  • Detectar regresiones cuando un modelo actualiza su versión
  • Justificar decisiones de selección de modelos con datos concretos
  • Estimar el impacto real de cambios en los prompts del sistema

Para la evaluación automática de respuestas de texto libre, muchos equipos están usando LLMs como jueces (LLM-as-a-judge), donde un modelo más potente evalúa las respuestas de los modelos candidatos. Es una aproximación pragmática pero tiene sus propios sesgos: los LLMs tienden a preferir respuestas más largas y a favorecer el estilo del modelo que los entrenó.

Modelos propietarios vs. modelos open-source

Esta no es una decisión únicamente técnica. Los modelos propietarios (GPT-4o, Claude 3.5, Gemini 1.5 Pro) ofrecen rendimiento de primer nivel con infraestructura gestionada, pero implican dependencia de un proveedor, costes que escalan con el volumen y limitaciones de personalización. Los modelos open-source (Llama 3.1, Mistral, Qwen) permiten despliegue en infraestructura propia, costes marginales bajos a escala y personalización total mediante fine-tuning, pero requieren expertise técnico para operarlos.

Para la mayoría de equipos que empiezan, comenzar con APIs gestionadas es lo correcto. Cuando el volumen justifica la inversión de ingeniería (típicamente desde los 10–50 millones de tokens por día), evaluar un despliegue de modelo open-source suele tener sentido económico.

El modelo que elijas hoy no será el que uses en 18 meses

El campo avanza demasiado rápido para que ninguna elección de modelo sea definitiva. Lo que sí debe ser duradera es tu arquitectura: diseña sistemas que puedan cambiar de modelo con modificaciones mínimas. Abstrae el acceso al modelo detrás de una interfaz común. Mantén tu golden dataset actualizado. Y revisa tu elección de modelo al menos cada dos trimestres.

La evaluación de LLMs no es un proceso de una sola vez sino una práctica continua, igual que el monitoreo de cualquier otro componente crítico de tu sistema.