Entrenar un modelo de lenguaje desde cero no es un ejercicio de fuerza bruta computacional. Es un proyecto de ingeniería con decenas de decisiones encadenadas donde un error temprano puede invalidar semanas de cómputo y miles de euros de GPU. La mayoría de guías explican el pipeline ideal (tokenizador, dataset, preentrenamiento, ajuste fino), pero casi ninguna se detiene en los fallos que de verdad ocurren cuando alguien intenta llevarlo a la práctica. Este artículo cubre precisamente eso: los errores más frecuentes y cómo detectarlos antes de que sea tarde.
Errores en la fase de datos: el origen de casi todo
1. Medir el dataset en gigabytes en vez de en tokens útiles
Un error habitual es presumir de corpus por su tamaño en disco. Un archivo comprimido de 50 GB puede contener menos texto útil del que sugiere, y tras deduplicar y filtrar boilerplate HTML puede quedarse en una fracción. Lo que importa es el número de tokens tras la tokenización real, no el peso del archivo.
Cómo evitarlo: tokeniza una muestra representativa (por ejemplo, 1 GB descomprimido) con el tokenizador exacto que vas a usar, calcula la ratio tokens/carácter y extrapola. Repite el cálculo después de cada fase de limpieza. Si el corpus final no alcanza un volumen razonable para el tamaño de modelo, replantea el objetivo antes de lanzar el entrenamiento.
2. Deduplicar solo con coincidencia exacta
La deduplicación por hash exacto elimina copias idénticas, pero deja pasar paráfrasis, plantillas repetidas y fragmentos casi duplicados que inflan artificialmente ciertas distribuciones. El modelo termina memorizando frases recurrentes y generando salidas repetitivas.
Cómo evitarlo: aplica deduplicación difusa por n-gramas o por similitud de MinHash sobre bloques de documento. No necesitas un sistema perfecto: eliminar duplicados cercanos a nivel de párrafo ya reduce mucho el ruido.
3. Ignorar la mezcla de dominios y el filtrado de calidad
Mezclar web genérica, código, artículos científicos y foros sin ponderar produce modelos que imitan el tono de un foro en respuestas que deberían ser formales. También es común no filtrar contenido tóxico, spam o texto generado automáticamente.
Cómo evitarlo: define proporciones explícitas por fuente, documenta de dónde sale cada bloque y aplica clasificadores de calidad ligeros. Según documentación oficial de varios proyectos abiertos, el filtrado de calidad tiene más impacto en el resultado final que añadir más datos de baja calidad.
4. Contaminación del conjunto de evaluación
Este es probablemente el fallo más silencioso. Si tu conjunto de validación o tus benchmarks internos aparecen, aunque sea parcialmente, en los datos de entrenamiento, las métricas mienten. Un modelo que «mejora» en cada evaluación puede estar simplemente memorizando.
Cómo evitarlo: separa los conjuntos de evaluación antes de construir el corpus, guarda huellas (hashes de n-gramas) de esos conjuntos y comprueba solapamiento contra el dataset de entrenamiento. Si hay coincidencias, elimínalas del corpus, no del test.
Errores en tokenización y arquitectura
5. Entrenar el tokenizador con un corpus que no representa el dominio final
Si el tokenizador se entrena solo con inglés y luego el modelo se usa en español o código, el número de tokens por palabra se dispara, la ventana de contexto efectiva se reduce y el coste de entrenamiento e inferencia aumenta sin que se note en las métricas iniciales.
Cómo evitarlo: entrena el tokenizador con una muestra estratificada que refleje los idiomas y dominios reales de uso. Verifica con texto fuera de muestra cuántos tokens consume una misma frase en distintos idiomas; si hay diferencias abismales, revisa el vocabulario.
6. Elegir el tamaño del modelo sin presupuesto de cómputo claro
Un modelo más grande no siempre es mejor para un objetivo concreto, y además impone requisitos de memoria y tiempo que muchos proyectos subestiman. Lanzar un preentrenamiento sin haber calculado el coste total (horas de GPU, checkpoints, almacenamiento, reintentos) es una vía rápida a quedarse a medias.
Cómo evitarlo: haz una prueba de escalado con un modelo pequeño durante pocas horas, mide throughput real en tu hardware y extrapola. Si el presupuesto no cubre el entrenamiento completo más al menos un reinicio desde checkpoint, reduce el tamaño.
7. No definir la longitud de contexto realista
Anunciar contextos enormes sin datos que los aprovechen genera modelos que rinden peor en ventanas largas de lo que sugiere la arquitectura. La atención sobre secuencias largas encarece el entrenamiento y, si el corpus está compuesto por documentos cortos, el modelo nunca aprende a usarla.
Cómo evitarlo: alinea la longitud de secuencia con la distribución real de tus documentos. Si necesitas contexto largo, incluye datos con estructura larga y evalúa específicamente tareas que lo requieran.
Errores durante el preentrenamiento
8. No monitorizar la pérdida por dominio
La pérdida global puede bajar mientras un dominio concreto empeora. Si el modelo se está sobreajustando a la web genérica y perdiendo capacidad en código o en un idioma específico, la métrica agregada lo oculta.
Cómo evitarlo: registra la pérdida de validación desglosada por fuente. Un panel con curvas separadas por dominio detecta desequilibrios mucho antes que la media global.
9. Checkpoints insuficientes o mal gestionados
Guardar solo al final es una apuesta. Fallos de hardware, reinicios del clúster o inestabilidad numérica pueden obligar a repetir días de cómputo. También es común guardar checkpoints sin registrar la configuración exacta asociada, lo que hace imposible reproducir el estado.
Cómo evitarlo: guarda checkpoints periódicos con su configuración, semilla y estado del optimizador. Verifica que la reanudación desde checkpoint funciona antes de lanzar el entrenamiento largo.
10. Ignorar la inestabilidad numérica
Picos de pérdida, gradientes que explotan o NaN intermitentes son señales de que la configuración de entrenamiento no es estable. Muchos proyectos los tratan como ruido y siguen adelante, y el modelo final queda degradado de forma difícil de diagnosticar.
Cómo evitarlo: usa recorte de gradiente, revisa la escala de inicialización y prueba con secuencias más cortas antes de escalar. Si aparecen NaN, detén y analiza; no reinicies a ciegas.
Errores en el ajuste fino y la evaluación
11. Confundir ajuste fino con arreglo de todo
El ajuste fino no corrige un preentrenamiento deficiente. Si el modelo base no tiene capacidad o datos suficientes, el ajuste fino solo maquilla el resultado en el conjunto de evaluación y generaliza mal.
Cómo evitarlo: evalúa el modelo base antes de ajustar. Si las métricas base son pobres, invierte en datos y preentrenamiento, no en más épocas de ajuste.
12. Evaluar solo con métricas automáticas
Perplejidad y precisión en tareas sintéticas no describen el comportamiento real. Un modelo puede mejorar en una métrica y volverse más repetitivo, más inseguro o menos útil en conversación.
Cómo evitarlo: combina métricas automáticas con evaluaciones humanas sobre una muestra pequeña pero bien definida. Documenta los criterios y revisa periódicamente si siguen midiendo lo que te importa.
13. No documentar el proceso
Sin registro de versiones de datos, hiperparámetros y resultados, cada experimento es irrepetible. Esto no es un detalle académico: en producción, cuando algo falla, la trazabilidad es lo que permite diagnosticar.
Cómo evitarlo: versiona el dataset, la configuración y los checkpoints con identificadores claros. Un registro mínimo pero consistente evita semanas de confusión.
Un caso concreto que ilustra el problema
En un proyecto real de ajuste de un modelo pequeño para respuestas técnicas en español, el equipo detectó que el modelo generaba respuestas correctas pero con un tono extrañamente promocional. La causa no estaba en el ajuste fino: el corpus de preentrenamiento incluía una proporción alta de páginas de marketing y blogs de producto que dominaban ciertos temas. La pérdida global era buena y las métricas automáticas no lo detectaban. Se corrigió reequilibrando la mezcla de dominios y filtrando contenido promocional, no añadiendo más datos.
Este tipo de problema solo se detecta leyendo salidas reales del modelo con regularidad y comparándolas con lo esperado, no solo mirando curvas de pérdida.
Lo que este artículo no cubre y por qué
Entrenar un LLM desde cero a escala industrial requiere infraestructura distribuida, estrategias de paralelismo y optimizaciones de memoria que dependen del hardware concreto y del framework elegido. Lo aquí descrito se centra en los errores de criterio que afectan a cualquier escala, desde un modelo pequeño en una sola GPU hasta un proyecto mayor. Ninguna de estas recomendaciones garantiza resultados: el comportamiento final depende de la interacción entre datos, arquitectura y configuración, y siempre hay incertidumbre.
Si algo caracteriza a quienes han entrenado modelos con éxito es la prudencia: asumen que el dataset tiene problemas, que las métricas pueden engañar y que el primer entrenamiento no será el definitivo. Planificar para esa realidad ahorra más tiempo que cualquier optimización prematura.
Perfiles verificables: Sitio web
Publicado el 25 de October de 2026. Última revisión: 25 de October de 2026.