Cómo se entrenan los modelos (y por qué tú no lo harás)
Todo modelo de chat que puedes descargar pasó por la misma tubería de tres etapas. Casi con seguridad nunca correrás la etapa uno — eso es territorio de centro de datos — pero quizá corras primos baratos de las etapas dos y tres. Conocer las etapas explica el comportamiento base-vs-instruct, por qué los modelos alucinan y qué es en realidad un modelo «fusionado» en Hugging Face.
Etapa 1: preentrenamiento — la parte cara
Un objetivo a escala inimaginable: predecir el siguiente token a lo largo de billones de tokens de texto web, código y libros. Aquí es donde el conocimiento y la habilidad entran en los pesos, y donde va la inmensa mayoría del cómputo.
| Qué | Escala aproximada (orden de magnitud) |
|---|---|
| Datos | 10–30T tokens para las familias modernas |
| Hardware | miles de GPU-meses; las corridas de vanguardia ocupan clústeres durante meses |
| Coste | ~$1M–$10M+ para un 7B; $10M–$100M+ para clase 70B; las corridas de vanguardia se rumorean muy por encima |
| Salida | un modelo base — autocompletado con forma de internet, sin comportamiento de asistente |
La salida es un modelo base: brillante en la continuación, inútil como asistente. Ante una pregunta, responde — y sigue con otra pregunta, una lista, un salto de página, porque eso es lo que hace el texto en internet.
Etapa 2: ajuste fino supervisado (SFT)
Decenas de miles a unos pocos millones de pares curados (instrucción → respuesta), unos días de GPU. Error de redondeo junto al preentrenamiento, pero recablea el comportamiento: responde a la instrucción, en un formato útil, y luego se detiene. Esta es la etapa que convierte un modelo base en algo con lo que puedes chatear.
Etapa 3: ajuste de preferencias
- RLHF: humanos ordenan pares de respuestas; un modelo de recompensa aprende el orden; la política se optimiza contra la recompensa (PPO). La receta clásica, maquinaria pesada.
- DPO: se salta el modelo de recompensa y optimiza pares de preferencias directamente. Más simple, estable, el favorito del código abierto.
- Efecto: estilo, utilidad, rechazos, afirmaciones mejor calibradas. También complacencia — el modelo aprende que la gente premia el acuerdo.
Cómo se ve en realidad los datos de SFT — JSONL plano de pares instrucción/respuesta, nada exótico:
{"instruction": "Summarize the changelog in three bullets.", "response": "- Adds ..."}
{"instruction": "답변을 존댓말로 작성하세요.", "response": "네, 알겠습니다 ..."}
Miles a millones de estos, unas pocas épocas, y el modelo base aprende el formato de asistente.
Mismos pesos, distintas etapas
prompt: "Write a haiku about GPUs."
base (after stage 1):
"Write a haiku about GPUs.
Write a sonnet about CPUs.
1. Choose your topic carefully..." ← continúa el documento
instruct (stages 1+2+3):
"A thousand cores wake,
each chasing one quiet token—
fans hold their breath." ← responde, formatea, se detiene
El sufijo del repo te dice la etapa: nombre pelado = base; -instruct / -it / -chat = afinado (véase parámetros).
Una pieza más de vocabulario: la fecha de corte del conocimiento — la fecha en que se recopiló el corpus de preentrenamiento. Pregunta por algo posterior y obtienes o un honesto «no lo sé» o, peor, ficción confiado; ambos son comportamiento correcto para pesos congelados (qué es un LLM).
Entrenamiento vs ajuste fino: a unos 1000× de distancia
| Preentrenamiento | Ajuste fino LoRA | |
|---|---|---|
| Datos | 10^12–10^13 tokens | 10^6–10^9 tokens |
| Parámetros actualizados | todos | menos del 1–2% (matrices adaptadoras pequeñas) |
| Hardware | clúster | una GPU |
| Tiempo de reloj | semanas–meses | horas–días |
| Coste | $M–$100M+ | $0–$100 alquilada |
| Para qué sirve | conocimiento + habilidades | estilo, formato, comportamiento de dominio estrecho |
| Riesgo | corridas con pérdida inestable, checkpoints arruinados | sobreajuste a un conjunto de datos diminuto |
| Modo de fallo | bugs de datos silenciosos descubiertos meses después | olvido catastrófico de habilidades generales |
| ¿Reproducible? | rara vez (datos no públicos) | sí (el conjunto de datos está en el repo) |
| Fuente de datos | web pública, código, libros, archivos con licencia | tus prompts y tus respuestas ideales |
| Quién puede | laboratorios bien financiados | tú, este fin de semana |
El ajuste fino mueve los diales; no añade conocimiento. Enseñarle a un 7B el tono de tu empresa: LoRA, una tarde. Enseñarle tus 50k documentos internos: eso es recuperación, no entrenamiento (RAG, ajuste fino).
Qué puede y qué no puede hacer el ajuste fino, para que lo apuntes bien:
- Puede: formato de salida, tono, terminología, estilo de rechazos, sintaxis de llamada a herramientas, una tarea estrecha hecha con fiabilidad.
- Puede: destilar una tarea estrecha de un modelo grande a uno pequeño.
- No puede (con fiabilidad): añadir hechos nuevos, arreglar razonamiento débil, extender fechas de corte, volver grande a un modelo pequeño.
- Regla: si el problema es «no lo sabe», usa recuperación; si es «no se comporta», ajusta fino.
Checkpoints, fusiones y lo que descargas
- El entrenamiento va guardando checkpoints por el camino; los lanzamientos suelen ser los pesos finales de la etapa instruct — recibes el asistente terminado, no el proceso que lo construyó.
- Una «fusión» promedia o interpola múltiples ajustes finos del mismo modelo base (model soups). No ocurre entrenamiento; es aritmética de pesos que a menudo aterriza entre sus padres. Popular en Hugging Face, barata, ocasionalmente excelente.
- Linaje poco claro significa licencia poco clara: las fusiones heredan los términos de cada padre (pesos abiertos vs APIs cerradas).
- Los pesos base detrás de un modelo de chat a veces también se publican — tómalos solo para cargas de completación o como sustrato de ajuste fino.
- Por qué los lanzamientos abiertos se detienen en la etapa final: los datos de preentrenamiento y los checkpoints intermedios son los activos competitivos caros; los pesos terminados son la demo.
- Los modelos instruct comunitarios comparten recetas y conjuntos de datos de post-entrenamiento, por eso tantos se sienten intercambiables: misma base, mismo manual de etapas 2/3.
- Prefiere lanzamientos cuya tarjeta de modelo liste datos y etapas; un checkpoint final documentado envejece mejor que uno publicitado.
Relacionados: ajuste fino · RAG · pesos abiertos vs APIs cerradas · parámetros