Una empresa despliega RAG sobre su documentación interna, los resultados son aceptables, pero el modelo sigue cometiendo errores extraños — no entiende las abreviaturas, confunde conceptos del sector, responde de forma genérica. El equipo prueba SFT (supervised fine-tuning) con unos pocos cientos de ejemplos. Hay mejora, pero el conocimiento profundo del dominio sigue faltando. Alguien propone: "¿Y si entrenamos el modelo sobre toda la documentación interna? Todos esos 800 PDF?"
Esta es exactamente la situación en la que entra en juego el continued pretraining — un método que se sitúa entre entrenar un modelo desde cero y el fine-tuning de dominio clásico. Es más potente, más costoso y menos explorado que el SFT. Y precisamente por eso merece entenderse antes de desplegarlo o descartarlo.
Qué es el continued pretraining y qué no es
El continued pretraining (a veces llamado domain-adaptive pretraining, DAPT, o second-stage pretraining) es el proceso de tomar un modelo ya preentrenado y seguir entrenándolo al estilo del preentrenamiento — es decir, sobre un corpus amplio de textos no etiquetados, mediante causal language modeling (predicción del siguiente token).
La diferencia respecto al fine-tuning clásico (SFT) es fundamental:
- SFT entrena el modelo sobre pares etiquetados entrada–salida (pregunta–respuesta, instrucción–resultado). Enseña al modelo *cómo comportarse* y *cómo responder*. Requiere datasets relativamente pequeños pero cuidadosamente etiquetados.
- Continued pretraining entrena el modelo sobre textos en bruto sin respuestas estructuradas. Enseña al modelo *qué sabe* — la distribución del lenguaje, los conceptos, los patrones y la factografía de un dominio concreto. Requiere grandes volúmenes de texto, pero sin etiquetado manual.
Otra confusión habitual: el continued pretraining no es idéntico al full fine-tuning. El full fine-tuning describe *cuántos pesos se entrenan* (todos, a diferencia de LoRA). El continued pretraining describe *qué tipo de entrenamiento* se realiza (preentrenamiento adicional frente a fine-tuning instruccional). Se puede hacer continued pretraining con LoRA, QLoRA o con actualización completa de parámetros — son dimensiones ortogonales.
Cuándo tiene sentido el continued pretraining
No todo problema de dominio requiere continued pretraining. En la práctica, vemos que tiene sentido en tres escenarios principales:
1. Dominio nuevo con alta densidad técnica y lenguaje propio
Cuando su dominio utiliza terminología, abreviaturas y expresiones que son raras o inexistentes en los textos de entrenamiento estándar. Ejemplos: documentación industrial con decenas de miles de abreviaturas, sub-especialidades médicas específicas, lenguaje regulatorio corporativo, normas técnicas. Después del SFT, el modelo sabe *formatear* respuestas, pero no comprende los conceptos en profundidad — y eso se manifiesta ante preguntas concretas.
2. Escasez de datos etiquetados, pero abundancia de texto en bruto
El etiquetado de datos para SFT es costoso y lento. Si tiene 500 GB de documentación técnica pero solo 500 ejemplos Q&A etiquetados con calidad, el continued pretraining le permite aprovechar todo el corpus textual sin necesidad de etiquetado. A continuación viene el SFT como «ajuste del comportamiento» sobre esa nueva base de conocimiento.
3. Otro idioma o mezcla de idiomas
La mayoría de los modelos open-weight populares son predominantemente anglófonos. Si necesita capacidades sólidas en español, alemán, checo u otros idiomas con menor representación en el preentrenamiento original, el continued pretraining sobre un corpus lingüístico amplio mejorará notablemente las capacidades en ese idioma — incluidas la gramática, los modismos y el contexto cultural.
Por el contrario, el continued pretraining *no tiene sentido* cuando: - Dispone de suficientes ejemplos Q&A de calidad y el dominio no es radicalmente distinto del preentrenamiento original - Su necesidad principal es cambiar el *comportamiento* (formato, tono, rechazo, estructura de respuestas) — eso es trabajo para SFT o DPO - Tiene un presupuesto computacional limitado y necesita resultados rápidos
Pipeline típico: cómo es en la práctica
Cuando se decide por el continued pretraining, se trata de un proceso multifásico. Los atajos no llevan a buen puerto.
Fase 1 — Preparación del corpus
Esta es la fase más larga e importante. El texto fuente debe estar limpio: sin duplicados, sin artefactos de OCR, sin contenido irrelevante (pies de página, navegación, campos de formulario). También se recomienda deduplicación a nivel de n-gramas — el modelo no debería ver la misma frase cien veces, porque eso conduce a memorización en lugar de generalización.
Tamaño del corpus: para un efecto significativo se habla en la práctica de *cientos de millones de tokens*, idealmente *miles de millones*. Un documento técnico estándar en PDF tiene del orden de 50 000–200 000 tokens tras el procesamiento. Quinientos documentos de ese tipo equivalen aproximadamente a 25–100 millones de tokens — lo que está en el límite inferior de un continued pretraining con sentido.
Un detalle importante: el preentrenamiento mixto es mejor que el puramente de dominio. Si entrena solo sobre textos de dominio, el modelo olvidará las capacidades generales y su lenguaje se «endurecerá» en un único registro. Una buena receta es una mezcla del 80–90 % de datos de dominio y un 10–20 % de texto general (por ejemplo, un corpus web de calidad). Esto mitiga el olvido catastrófico.
Fase 2 — Configuración del entrenamiento
Diferencia clave respecto al SFT: el learning rate debe ser significativamente menor que en el preentrenamiento desde cero. Se suelen usar valores del orden de 1e-5 a 1e-4, lo que es típicamente 10–100 veces menor que en el preentrenamiento original. Un learning rate demasiado alto hace que el modelo «olvide» lo que sabía; demasiado bajo produce ninguna adaptación de dominio.
En cuanto a la arquitectura de entrenamiento: la mayoría de los equipos recurre en la práctica a LoRA o QLoRA también para el continued pretraining, porque la actualización completa de parámetros es extremadamente costosa. LoRA funciona en continued pretraining — no tan bien como los pesos completos, pero en la práctica es suficiente para la mayoría de las adaptaciones de dominio.
Fase 3 — SFT como finalización
El continued pretraining por sí solo no produce un modelo «conversable». Produce un modelo que comprende el dominio en profundidad, pero que solo sabe generar texto libre. Por eso, casi siempre se aplica SFT (y a veces DPO) después del continued pretraining, para que el modelo aprenda a reaccionar correctamente a las instrucciones, responder a preguntas y respetar el formato. Puede encontrar más información sobre este pipeline en el artículo sobre cómo decidir entre SFT, DPO y GRPO.
Costes y requisitos de hardware
Aquí conviene ser honesto: el continued pretraining es *más caro* que el SFT, y notablemente.
Con SFT sobre 10 000 ejemplos hablamos de horas de entrenamiento en una A100 — del orden de decenas de dólares. El continued pretraining sobre 500 millones de tokens puede durar días incluso con varias GPU — y eso también con LoRA. La actualización completa de parámetros sobre un corpus de miles de millones puede requerir decenas de horas-A100, lo que en la nube supone costes de cientos a miles de euros.
Para orientación práctica: - LoRA continued pretraining de un modelo 7B sobre ~200M tokens: del orden de 10–30 horas en una A100 80 GB - QLoRA 4-bit continued pretraining de un modelo 7B sobre el mismo corpus: más lento (la decuantización ralentiza), pero cabe en una GPU de consumo con 24 GB de VRAM - Full parameter continued pretraining de un modelo 13B: multi-GPU prácticamente obligatorio
Los precios de A100 en la nube están hoy del orden de ~0,60 $/h (precios spot en proveedores menores) a ~3–4 $/h en los grandes hiperescaladores. Planifique un margen — la primera ejecución suele revelar problemas con los datos y hay que relanzar el entrenamiento.
Riesgos que observamos en la práctica
El olvido catastrófico es una amenaza real. Un modelo sometido a un continued pretraining demasiado agresivo puede degradar sus capacidades generales — peor inglés, peor seguimiento de instrucciones, peor lógica. Soluciones: learning rate bajo, entrenamiento mixto (véase más arriba) y, opcionalmente, regularización. Evalúe no solo el rendimiento de dominio, sino también los benchmarks generales antes y después del entrenamiento.
«El modelo solo memoriza» — si el corpus es pequeño y contiene muchos documentos repetidos, el modelo aprenderá a citar textos en lugar de comprenderlos. La deduplicación y la diversidad de datos son obligatorias.
Datos ingenuos = modelo ingenuo — en 2026, una parte significativa del nuevo texto web es generada por IA, lo que al hacer web crawling introduce el riesgo de entrenar sobre generación sintética distribuida. Para documentación corporativa industrial esto no suele ser problema, pero hay que tener cuidado al recopilar fuentes externas.
Riesgos regulatorios y de datos — el continued pretraining sobre documentación corporativa puede eliminar involuntariamente los guardrails del modelo instruction-tuned original. Tras el continued pretraining se aplica SFT y alignment fine-tuning (DPO o GRPO) para restablecer estos mecanismos. Si se omite este paso, se obtiene un modelo sin comportamientos de seguridad integrados. Para sectores regulados esto es crítico.
Sobre otros motivos por los que la adaptación de dominio fracasa, escribimos con más detalle en el artículo sobre las causas más frecuentes de un fine-tuning fallido.
Alternativa: cuándo RAG sustituye al continued pretraining
Para muchas empresas, el continued pretraining es la respuesta equivocada a la pregunta correcta. Cuando el objetivo es que el modelo «conozca el contenido de los documentos», RAG (Retrieval-Augmented Generation) lo resuelve de forma más barata, más rápida y con mejor capacidad de actualización. El modelo no necesita «saber» los documentos — basta con que los reciba en el contexto en el momento de la consulta.
El continued pretraining es la mejor opción cuando: - El lenguaje de dominio es tan específico que el retrieval no es suficiente (el modelo no entiende los conceptos ni cuando los recibe en el contexto) - Se necesita baja latencia sin paso de retrieval (despliegue en el edge, procesos en tiempo real) - Se quiere que el modelo genere contenido en el lenguaje del dominio, no solo que responda preguntas
RAG y continued pretraining no son mutuamente excluyentes — los mejores resultados en la práctica se obtienen con la combinación: un modelo adaptado al dominio con RAG sobre la documentación actualizada. Puede encontrar más información sobre cómo decidir entre estos enfoques en el artículo de comparación RAG vs. fine-tuning.
Marco de decisión práctico
Cuando un cliente llega con la pregunta «¿reentrenamos el modelo o no?», seguimos estos pasos:
- 1.¿Qué es exactamente lo que no funciona? — mal formato/tono → SFT; el modelo no entiende los conceptos → continued pretraining; el modelo cita información obsoleta → RAG; el modelo alucina hechos → combinación
- 2.¿Cuánto texto no etiquetado tiene? — menos de 10 millones de tokens? El continued pretraining probablemente no vale la pena; ¿100M+ tokens? Tiene sentido planteárselo
- 3.¿Cuál es su presupuesto computacional? — si no tiene acceso a A100+ o GPU en la nube, empiece con SFT; el continued pretraining es para equipos con infraestructura ML consolidada
- 4.¿El dominio es realmente específico? — si su lenguaje técnico aparece también en textos web comunes, un buen SFT con ejemplos de calidad será suficiente
Preguntas frecuentes
¿Es el continued pretraining lo mismo que el domain-adaptive pretraining?
En esencia, sí — los términos se usan indistintamente. «Domain-adaptive pretraining» (DAPT) es el término académico de la comunidad investigadora; «continued pretraining» es más habitual en la industria. Ambos describen lo mismo: continuar el preentrenamiento sobre un corpus específico de dominio con textos no etiquetados.
¿Puedo hacer continued pretraining con LoRA o necesito actualización completa de parámetros?
LoRA (y también QLoRA) funciona en continued pretraining y la mayoría de los equipos lo prefiere precisamente por el ahorro de memoria. La actualización completa de parámetros da resultados ligeramente mejores, pero la diferencia suele ser menor que la diferencia de coste. Para la mayoría de las adaptaciones de dominio, LoRA es suficiente.
¿Cuánto texto necesito para un efecto significativo?
En la práctica: por debajo de 50 millones de tokens el efecto suele ser marginal. Una adaptación de dominio notable empieza a manifestarse a partir de cientos de millones de tokens. Si tiene menos, invierta mejor en la calidad de los datos SFT — probablemente obtendrá un mejor resultado a un coste menor.
¿Perderá el modelo la capacidad de seguir instrucciones después del continued pretraining?
Sí — y es una trampa habitual. El continued pretraining se realiza típicamente sobre un modelo *base* (no sobre la variante instruction-tuned), o si se hace sobre uno instruction-tuned, se arriesga a debilitar los comportamientos integrados. Por eso, tras el continued pretraining sigue obligatoriamente el SFT (y eventualmente DPO). Nunca lleve un modelo con continued pretraining directamente a producción sin una capa de instruction fine-tuning.
¿Es el continued pretraining adecuado también para modelos pequeños (1B–4B)?
Sí, y a veces es incluso más eficaz. Los modelos pequeños tienen una capacidad limitada de conocimiento general, por lo que la «sobreescritura» de dominio es relativamente mayor. Un modelo 4B fine-tuned en un dominio estrecho puede superar dentro de ese dominio a un modelo genérico notablemente más grande. Puede encontrar más información sobre este tema en el artículo de comparación entre un modelo pequeño fine-tuned y un modelo base grande.
Conclusión
El continued pretraining no es la respuesta universal a los problemas con LLM de dominio — pero para empresas con documentación técnica extensa, un lenguaje especializado específico o necesidad de adaptación lingüística profunda, es una herramienta que el SFT simplemente no puede sustituir. La clave está en saber cuándo usarlo: cuando el modelo no comprende el dominio a nivel fundamental, no solo cuando no sabe formatear correctamente las respuestas.
*Si está valorando si el continued pretraining es adecuado para su caso, o si busca un marco para decidir entre RAG, SFT y adaptación de dominio, estaremos encantados de analizarlo juntos. MP Industrial Solutions tiene experiencia en el despliegue de LLM locales en entornos industriales — incluidos casos en los que hemos recomendado descartar el continued pretraining y optar por una solución más sencilla.*