Elegir un modelo de lenguaje para trabajar en español no se resuelve con una tabla de puntuaciones. La mayoría de comparativas públicas se centran en benchmarks en inglés, y cuando trasladas esas cifras a un caso real en castellano descubres que el modelo que ganaba en MMLU pierde el hilo en una conversación con modismos argentinos o mezcla terminología catalana con castellana. Esta guía no te da un ranking cerrado: te da un procedimiento de configuración reproducible para que tú mismo midas qué modelo rinde mejor en tu caso concreto, con pruebas concretas y umbrales de decisión.
Paso 0: define qué significa «rendimiento en español» para tu proyecto
Antes de tocar una API o descargar pesos, escribe en una hoja qué tareas vas a delegar al modelo. No es lo mismo un clasificador de tickets de soporte que un generador de resúmenes jurídicos. Los ejes que de verdad discriminan entre modelos en español son cuatro:
- Comprensión lectora: extraer respuestas de un texto largo sin inventar datos.
- Fluidez y registro: que el texto no suene a traducción automática del inglés.
- Robustez dialectal: comportamiento ante variantes rioplatense, mexicana, peninsular o andina.
- Fidelidad instruccional: respetar formatos (JSON, listas, longitudes) en castellano.
Un modelo puede ser excelente en el primero y desastroso en el tercero. Según documentación oficial de varios proveedores, sus evaluaciones multilingües agregan resultados por idioma, lo que oculta diferencias regionales. Por eso el paso 0 es imprescindible.
Paso 1: monta el banco de pruebas con textos reales tuyos
Reúne entre 20 y 40 ejemplos propios. Sirven correos de clientes, fragmentos de tu base de conocimiento, páginas de producto o transcripciones de llamadas. Etiqueta manualmente la respuesta esperada en una columna aparte. Este detalle marca la diferencia: los benchmarks públicos usan plantillas que los modelos han visto en entrenamiento; tus textos no.
Qué incluir obligatoriamente
- Al menos cinco ejemplos con code-switching (castellano con términos en inglés, habitual en tecnología).
- Dos o tres con cifras y unidades (fechas, importes, porcentajes) para detectar errores de formato.
- Un ejemplo con instrucción negativa: «no menciones precios» o «responde solo con la tabla».
- Textos con tildes, eñes y signos de apertura (¿ ¡). Es un test barato que descarta modelos con tokenizadores pobres para español.
Paso 2: configura el entorno de comparación
No compares modelos desde interfaces de chat distintas: cambian el system prompt por defecto, la temperatura y el truncado. Usa un script único que llame a cada endpoint con parámetros idénticos. Un esqueleto en Python con la librería estándar de cada proveedor basta.
params = { «temperature»: 0.2, «max_tokens»: 800, «top_p»: 1.0 }Fija temperatura baja (0.1–0.3) para tareas de extracción. Si tu caso es creativo, repite la batería con temperatura 0.8 y compara estabilidad entre ejecuciones. Un modelo que varía mucho con la misma semilla es difícil de integrar en producción.
El error que casi todos cometen aquí
Comparar solo la primera respuesta. Los modelos grandes suelen acertar en el primer turno y degradarse cuando el contexto crece. Añade una prueba de dos y tres turnos con contexto acumulado de 3.000–6.000 tokens en español. En mi experiencia con asistentes de atención al cliente, la caída más brusca aparece justo ahí: el modelo empieza a responder en inglés o pierde la instrucción de formato cuando el historial se alarga. Esa limitación no sale en ninguna tabla comparativa pública.
Paso 3: define métricas que puedas calcular sin un equipo de anotadores
No necesitas un laboratorio. Con tres métricas sencillas obtienes señal suficiente:
- Acierto exacto o por solapamiento: para extracción, compara con la respuesta etiquetada usando coincidencia de palabras clave o similitud de cadenas.
- Tasa de violación de formato: porcentaje de respuestas que no respetan el esquema pedido (JSON inválido, listas con viñetas cuando se pedía prosa).
- Penalización por anglicismos: cuenta de términos en inglés no justificados por el dominio. Un umbral razonable es más de dos por cada 200 palabras en textos divulgativos.
Si necesitas evaluar fluidez, pide a dos compañeros que ordenen pares de respuestas a ciegas. Con 30 pares obtienes una preferencia bastante estable. No hace falta más para decidir.
Paso 4: ejecuta la batería y lee los resultados con escepticismo
Lanza cada modelo tres veces por ejemplo y registra la varianza. Un modelo con 85 % de acierto y desviación alta es peor para producción que uno con 80 % estable. Documenta también latencia y coste por 1.000 tokens: en español, la longitud media de las respuestas suele ser un 10–20 % mayor que en inglés para el mismo contenido, y eso encarece el uso real aunque el precio por token parezca bajo.
Qué esperar según el tipo de modelo
Los modelos abiertos de tamaño medio suelen defenderse bien en clasificación y extracción con instrucciones claras, pero flojean en matices dialectales y en mantener registro formal durante textos largos. Los modelos propietarios grandes tienden a producir castellano más natural, aunque a veces «sobrecorrigen» y generan un español neutro artificial que suena raro a un lector local. Ninguno gana en todo. Si tu producto es para España, prueba explícitamente con ejemplos que usen «vosotros» y léxico peninsular; si es para LatAm, evita que el modelo imponga «ordenador» donde tu usuario dice «computadora».
Paso 5: ajusta el prompt antes de cambiar de modelo
Muchas diferencias entre modelos desaparecen con un system prompt bien escrito en español. Incluye el idioma de salida de forma explícita, el registro deseado y un ejemplo de respuesta. Los modelos interpretan mejor las instrucciones cuando el propio prompt está en el idioma objetivo, aunque entiendan inglés perfectamente.
Prueba esta secuencia: primero optimiza el prompt con el modelo A; después aplica el mismo prompt al modelo B. Si B mejora mucho, el problema era el prompt y no el modelo. Si B sigue fallando en los mismos ejemplos, ahí tienes una limitación real que justifica el cambio.
Paso 6: decide con una matriz, no con una corazonada
Puntúa cada candidato de 1 a 5 en cuatro criterios ponderados según tu caso: acierto en tu batería, estabilidad entre ejecuciones, coste total y latencia. Multiplica por el peso y suma. Un modelo que saca 4 en acierto pero 2 en estabilidad rara vez es la elección correcta para un flujo automatizado.
Añade una columna de «riesgo»: si el proveedor no documenta el tratamiento de datos en español o no ofrece retención cero, ese factor puede pesar más que dos puntos de precisión. La transparencia del proveedor sobre sus datos de entrenamiento es una señal de calidad, no un adorno.
Limitaciones que esta metodología no resuelve
No evalúa sesgos culturales de forma sistemática, ni cubre idiomas cooficiales (catalán, gallego, euskera) salvo que añadas ejemplos propios. Tampoco predice el comportamiento tras una actualización del proveedor: los modelos cambian sin aviso y tu batería debe repetirse cada cierto tiempo. Y no sustituye una revisión humana en dominios regulados. Si tu caso es sanitario o legal, la validación por expertos es obligatoria independientemente de la puntuación.
Por último, ten presente que el rendimiento en español no es una propiedad fija del modelo: depende del tokenizador, de la longitud del contexto y del dominio. Un modelo que brilla en conversación general puede fallar en terminología técnica de tu sector. La única comparativa que importa es la que ejecutas con tus datos, tus parámetros y tus criterios de aceptación. El resto son pistas, no veredictos.
Perfiles verificables: Sitio web
Publicado el 25 de October de 2026. Última revisión: 25 de October de 2026.