Lo que no sabes sobre el entrenamiento de LLM: principios, rutas y nuevas prácticas

TL;DR

Después de escribir "Lo que no sabes sobre Claude Code: Arquitectura, gobernanza y práctica de ingeniería" y "Lo que no sabes sobre los Agentes: Principios, arquitectura y práctica de ingeniería", quería desafiarme a resumir cómo funciona realmente el entrenamiento de Modelos de Lenguaje de Gran Escala (LLM). Este artículo pretende ser comprensible incluso para quienes no tienen formación profesional.

De cara a 2026, la brecha real en el rendimiento de los LLM ya no es solo el preentrenamiento en sí mismo, sino la larga cola que le sigue: post-entrenamiento, evaluación, recompensas, entrenamiento de Agentes y destilación. Cada paso afecta la experiencia real del usuario. Cuando notas que un modelo se vuelve más potente de repente, es probable que se deba a que estas áreas se optimizaron en conjunto, y no a un único factor.

Lo que sigue sigue el pipeline de entrenamiento de LLM, centrándose en cómo los fabricantes mejoran los resultados finales a través de la última mitad del stack de entrenamiento.

El entrenamiento de LLM es un Pipeline

En los últimos años, el progreso de los modelos se explicaba generalmente por la acumulación de parámetros, datos y capacidad de cómputo. Sin embargo, las mejoras que muchos usuarios perciben realmente no provienen de entrenar con más corpus básicos, sino de todo el proceso de entrenamiento posterior al preentrenamiento. Cómo habla un modelo, sigue instrucciones, razona y usa herramientas—estas capacidades no crecen de forma natural solo alimentándolo con más texto de internet.

InstructGPT dio un ejemplo muy directo: un modelo con solo 1.3B de parámetros que se sometió a alineación y optimización de preferencias podía superar al GPT-3 de 175B en evaluaciones de preferencia humana. Con una diferencia de parámetros de dos órdenes de magnitud, los usuarios preferían la versión mucho más pequeña. La segunda mitad del entrenamiento realmente reescribe la percepción del usuario.

El proceso de entrenamiento es en realidad un pipeline donde los datos, los algoritmos, los sistemas y la retroalimentación están altamente acoplados. Un cambio en una capa suele propagarse a las demás. En 2026, las capacidades del modelo y el valor industrial se concentran cada vez más en las capas posteriores al preentrenamiento.

Esta es también la razón por la que a menudo sentimos que Doubao no compite por los rankings, pero resulta más satisfactorio en el uso diario: porque el post-entrenamiento está bien ejecutado.

Estas seis capas son solo para ver la división del trabajo. Las nueve etapas en la siguiente figura son una versión más detallada: los datos brutos y las recetas del sistema están separados, y el harness del Agente y el despliegue son subdivisiones de la segunda mitad. También hay dos bucles de retroalimentación en todo el proceso: el tráfico de producción regresa a la ingeniería de datos, y los resultados de la evaluación fuera de línea regresan al preentrenamiento.

El preentrenamiento es solo la base

El preentrenamiento sigue siendo el punto de partida de la cadena de entrenamiento. Solo entendiendo lo que hace podemos entender lo que cada capa posterior complementa. Sin este paso, no hay capacidad de modelado del lenguaje, no hay compresión de conocimiento y no hay espacio para la transferencia de capacidades posteriores. En ingeniería, no solo enseña al modelo a predecir el siguiente token: aprende la distribución del lenguaje, comprime el conocimiento y los patrones del texto a gran escala en parámetros, y deja espacio para la activación de capacidades posteriores. La predicción del siguiente token solo describe la forma de entrenamiento; no explica por qué los modelos desarrollan repentinamente nuevas capacidades a medida que aumenta la escala.

Después de GPT-3, muchos ajustes de modelos consideran el presupuesto y las proporciones con más cuidado. Los modelos no son mejores solo porque son más grandes. Existe un problema de proporción entre el número de parámetros, los tokens de entrenamiento y el presupuesto total de cómputo. Muchos modelos no son demasiado pequeños; están subentrenados y no han alcanzado un punto más adecuado dentro de un presupuesto dado.

En las decisiones reales de entrenamiento, la pregunta práctica es: si alguien te da 10,000 H100s y un mes, ¿cómo entrenarías un modelo de código abierto suficientemente bueno? Las leyes de escalado aquí son más una herramienta de asignación de presupuesto que una curva abstracta en un artículo. En última instancia, debes considerar: ¿la próxima ronda de entrenamiento debe apilar más parámetros o alimentar más datos? ¿El modelo actual carece de capacidad o simplemente está subentrenado? Bajo un presupuesto limitado de GPU, ¿qué proporción es más valiosa?

El preentrenamiento es como sentar las bases de las capacidades del modelo, determinando el alcance del conocimiento, el potencial de generalización y la capacidad de inducción de patrones. También determina si hay espacio para que el post-entrenamiento lo explote. Sin embargo, el preentrenamiento no puede controlar si el modelo sigue instrucciones, coopera con los usuarios o funciona de manera estable en tareas críticas.

La fase de preentrenamiento no solo decide cuánto conocimiento se aprende; predetermina en lo que el modelo puede convertirse. El método de división del tokenizador afecta directamente al entrenamiento posterior, y la longitud de la ventana de contexto debe establecerse de antemano. Si se debe continuar con el preentrenamiento multimodal o si la operación en un solo acelerador es un requisito desde el principio—estas compensaciones se escriben en la receta durante la fase de entrenamiento, no se añaden como características en el lanzamiento. Gemma 3 enfatiza un solo acelerador, contexto de 128K, capacidades de visión y cuantización simultáneamente, reflejando estas compensaciones. Las capacidades que los usuarios finalmente ven—ejecutarse en una computadora local, ver imágenes, entender documentos largos—en realidad se determinan en gran medida durante la fase de entrenamiento.

Mirando el punto óptimo de datos dado por Chinchilla, para un modelo de 8B parámetros, son unos 200B tokens. Sin embargo, Llama 3 8B usó realmente 15T tokens, unas 75 veces más. Estas recetas de sobreentrenamiento suelen intercambiar una mayor densidad de capacidad por los mismos parámetros, lo que resulta en un modelo más pequeño y rentable para la inferencia. Medir esto por FLOPs totales (operaciones de punto flotante) es más fiable que mirar el número de parámetros. La siguiente figura muestra visualmente esta brecha.

Otro diseño a menudo pasado por alto ocurre en la fase de preentrenamiento: el tamaño del vocabulario del tokenizador, las estrategias de división y los métodos de codificación a nivel de byte tienen un impacto significativo. Llama 2 tenía un vocabulario de 32K; después de que Llama 3 lo expandiera a 128K, la longitud de la secuencia se comprimió aproximadamente un 15%, y el rendimiento downstream siguió la misma tendencia. Este impacto se extiende a los costos de inferencia y las capacidades multilingües. La eficiencia de tokens del chino, el código y las fórmulas matemáticas se determina durante el diseño del vocabulario. Por ejemplo, un tokenizador que divide el chino en fragmentos muy pequeños no solo cuesta más tokens cada vez; cada inferencia debe soportar continuamente el costo de esa mala decisión.

Las recetas de datos determinan las capacidades del modelo

La escala de parámetros fue una métrica importante en el pasado, pero en los últimos dos años, lo más importante es la "receta de datos".

Este proceso parece una limpieza de datos en la superficie, pero en realidad es una tarea completa de ingeniería de producción de datos. Los datos brutos de páginas web, repositorios de código, libros y foros deben pasar primero por extracción de texto, identificación de idioma, filtrado de calidad, procesamiento de privacidad, filtrado de seguridad y deduplicación antes de entrar al preentrenamiento. La siguiente figura muestra el flujo completo del proceso en embudo.

Si solo tratas los datos como combustible de entrenamiento, es fácil concluir que más es mejor. Pero la ingeniería de datos está más cerca del diseño de capacidades. Lo que el modelo ve y no ve, y las proporciones de código, matemáticas y enciclopedia, afectan directamente la distribución final de capacidades del modelo.

La deduplicación y el control de contaminación a menudo se ignoran, pero impactan significativamente los resultados. No se trata solo de datos de baja calidad; incluye plantillas duplicadas, textos de licencia, sitios espejo y contaminación por fugas de benchmarks. Si la deduplicación a nivel de documento y a nivel de línea es insuficiente, el modelo a menudo absorbe repetidamente el contenido más fácil de copiar sin aprender necesariamente las partes más valiosas. El rendimiento inconsistente de muchos modelos de código abierto a menudo se debe a brechas en la calidad del procesamiento de datos.

En los últimos dos años, la mezcla de datos se ha convertido en un problema de investigación independiente. Trabajos como Data Mixing Laws se centran no solo en cuántos datos más se pueden recolectar, sino en cómo las proporciones de diferentes tipos de datos guían al modelo hacia estructuras de capacidad específicas.

Los datos sintéticos también han pasado de ser un medio auxiliar a una parte formal del proceso de entrenamiento. Métodos como Self-Instruct, las trayectorias de destilación de DeepSeek-R1 y la supervisión sintética cada vez más evidente en las series Qwen y Kimi avanzan en la misma dirección. Cada generación de modelos más potentes participa en la reconstrucción de los datos que ve la siguiente generación. Los modelos tempranos generaban datos de instrucción básicos; los modelos más potentes generan trayectorias de razonamiento de alta calidad y datos de CoT (Cadena de Pensamiento); y los modelos de razonamiento entrenados mediante RL destilan estas trayectorias en modelos densos más pequeños. "Denso" significa que todos los parámetros se ejecutan, a diferencia de MoE (Mezcla de Expertos) que se activa bajo demanda.

La clave aquí es que los modelos a menudo necesitan formar capacidades a una escala mayor primero antes de que esas capacidades puedan comprimirse en modelos más pequeños. La serie DeepSeek-R1-Distill es un ejemplo directo. Las trayectorias de modelos grandes después de RL han proporcionado ganancias significativas para modelos densos de 1.5B a 70B. Llama 3.1 405B también se usó explícitamente para mejorar la calidad del post-entrenamiento de los modelos 8B y 70B. Estos no son productos secundarios, sino parte del diseño del entrenamiento.

Las restricciones del sistema y la arquitectura deben estar claras antes del entrenamiento

Mucha gente entiende el entrenamiento como un problema de investigación: cómo establecer la función objetivo, cómo reducir la pérdida y cómo cambiar la estructura del modelo. Pero en el entrenamiento real de LLM, las restricciones del sistema son muy importantes; es un problema de sistema distribuido, no un problema de aprendizaje profundo en una sola máquina. El número de GPUs, el ancho de banda de la memoria, las estrategias de paralelismo, la tolerancia a fallos y el costo—estos no pueden esperar hasta después del entrenamiento para optimizarse. Determinan desde el principio qué tan grande puedes entrenar, qué longitud de contexto puedes soportar y si puedes ejecutar un post-entrenamiento más complejo.

MoE es el ejemplo más típico en esta capa. El modo de múltiples expertos permite al modelo expandir los parámetros totales bajo un cómputo similar mientras controla el costo de activación por token. La compensación es un enrutamiento complejo, un balanceo de carga difícil y una infraestructura pesada. Los diseños MoE de DeepSeek-V3 y Qwen son compromisos entre costo y efecto, no solo preferencias arquitectónicas.

Las discusiones en recetas recientemente publicadas ya no se tratan solo de análisis gruesos como el tamaño del modelo y las proporciones de tokens. muP permite transferir hiperparámetros de experimentos a pequeña escala a entrenamientos a gran escala. La tasa de aprendizaje WSD es un programa que aumenta, se estabiliza y luego disminuye. Combinado con un tamaño de lote óptimo y relaciones dato-parámetro más altas, estos detalles se están convirtiendo en los verdaderos diferenciadores entre modelos de la misma escala.

El contexto largo, la multimodalidad y las nuevas arquitecturas, si se entienden solo como características del producto, pasan por alto las restricciones del lado del entrenamiento. Un objetivo de contexto de 128K cambia directamente los costos de atención, los tamaños de lote, el currículo de entrenamiento (secuenciación de datos) y las estrategias de paralelismo. La multimodalidad cambia no solo la estructura del modelo, sino también la mezcla de datos, el diseño del codificador y la evaluación de seguridad. Si la operación con una sola tarjeta es un requisito estricto, el número de parámetros, las rutas de cuantización y el tamaño de la familia de modelos se ajustarán.

Trabajos como Forgetting Transformer y Kimi's Attention Residuals responden preguntas similares: cómo entrenar contextos más largos y cómo evitar la dilución de la información a medida que las redes se vuelven más profundas. Lo que ves es un modelo que puede manejar entradas más largas o es más fácil de implementar, pero lo que se enfrenta durante el entrenamiento es un conjunto completamente diferente de restricciones.

El presupuesto de cómputo es fijo. Tamaño del modelo, volumen de tokens de entrenamiento, longitud del contexto y costo de servicio—por cada bit gastado en una dirección, otros deben ceder.

A medida que el contexto se alarga, los costos de atención explotan y el tamaño del lote debe reducirse. A medida que los modelos se agrandan, el uso de memoria de la GPU aumenta y los costos de servicio siguen la misma tendencia. Estas no son elecciones, sino resultados de restricciones de recursos. La mayoría de las decisiones se toman antes de que comience el entrenamiento.

También hay una realidad de ingeniería que a menudo se ignora: el entrenamiento no siempre es estable. Miles de GPUs funcionan durante semanas, y de repente ocurre un pico de pérdida de entrenamiento, tan grande que no se puede ignorar, lo que obliga a retroceder a un checkpoint de días anteriores para empezar de nuevo.

Además de los picos de pérdida, hay errores silenciosos de GPU—una GPU que no reporta un error pero produce silenciosamente gradientes incorrectos—anomalías en el ancho de banda de NVLink y jitter en la comunicación entre nodos. Cada uno puede contaminar varios pasos de entrenamiento. Ser capaz de detectar, aislar y recuperar rápidamente en el entrenamiento a gran escala es una capacidad de ingeniería a nivel de laboratorio, no un problema resuelto leyendo artículos.

DeepSeek-V3 mencionó específicamente en su informe técnico que todo el proceso de preentrenamiento no tuvo picos de pérdida irrecuperables ni retrocesos. También es uno de los pocos casos que verifican que el entrenamiento de precisión mixta FP8 es factible en modelos a ultra gran escala. Según datos públicos, todo el proceso tomó aproximadamente 2.788M horas de GPU H800 para preentrenar 14.8T tokens.

Los sistemas de entrenamiento y los sistemas de inferencia están estrechamente relacionados, pero no son el mismo problema de ingeniería. El entrenamiento se preocupa por los gradientes, el paralelismo, los checkpoints, el rendimiento y el costo; la inferencia se preocupa por la latencia, el caché KV (almacenamiento en caché de cálculos históricos para evitar repeticiones), la cuantización y la estabilidad del servicio.

El post-entrenamiento determina la brecha percibida por el usuario

Muchas mejoras que los usuarios comunes pueden percibir realmente ocurren después del preentrenamiento. El ajuste de instrucciones utiliza pares de instrucción-respuesta etiquetados para el entrenamiento supervisado. Cambia la forma en que el modelo responde, convirtiendo requisitos como cómo aceptar tareas, organizar la salida y actuar como un asistente cooperativo en señales de supervisión. Un modelo base ya puede tener muchas capacidades potenciales, pero sin este paso, esas capacidades a menudo no emergen de manera estable en la forma que los usuarios esperan.

Más allá, RLHF, DPO y RFT comparten direcciones similares—integrar la definición de una "mejor respuesta" en el bucle de entrenamiento—pero a través de caminos diferentes.

• RLHF (Aprendizaje por Refuerzo a partir de Retroalimentación Humana) primero imita respuestas de alta calidad, luego usa comparaciones de preferencias para el refuerzo.
• DPO (Optimización Directa de Preferencias) acorta este camino aprendiendo directamente de comparaciones de preferencias sin necesidad de un modelo de recompensa separado.
• RFT (Ajuste Fino por Refuerzo) es una interfaz más fácil de implementar en ingeniería, poniendo las definiciones de tareas, los diseños de calificadores y las señales de recompensa en el proceso de comercialización.

Hoy en día, hablar de post-entrenamiento solo en términos de SFT o RL ya no es suficiente. Las partes más difíciles son cómo establecer evaluaciones, cómo puntuar y qué tipo de respuesta merece una optimización continua. SFT es ajuste fino supervisado; no solo aprende conocimiento, sino también estilo. La longitud de los datos, el formato, si se incluyen citas y la preferencia por viñetas afectan significativamente la forma final de salida del modelo. Muchos usuarios creen que están comparando capacidades, pero a menudo solo están comparando diferencias de estilo. Además, las evaluaciones de preferencias favorecen naturalmente las respuestas más largas, confundiendo fácilmente las salidas largas de aspecto serio con más fiables. Por lo tanto, mirar los leaderboards para el post-entrenamiento a menudo es insuficiente; hay que combinar los resultados de tareas reales, el costo y la estabilidad.

El post-entrenamiento moderno es un pipeline de múltiples etapas. La receta de DeepSeek-R1 es la más clara en los materiales públicos. Procede en cuatro etapas:

Etapa 1 es SFT de arranque en frío. Antes de hacer aprendizaje por refuerzo, usa una pequeña cantidad de datos de Cadena de Pensamiento (CoT) de alta calidad para calentar. DeepSeek-R1-Zero demostró que hacer RL directamente desde un modelo base (el modelo bruto después del preentrenamiento sin alineación) es factible, pero los modelos entrenados puramente con RL se repetirán, tendrán un lenguaje desordenado y una legibilidad pobre. El SFT de arranque en frío le da a RL un punto de partida más estable, bloqueando la consistencia del formato y el lenguaje.

Etapa 2 realiza aprendizaje por refuerzo en campos verificables como matemáticas, código y lógica, usando GRPO como algoritmo de entrenamiento y la corrección verificable programáticamente como señal de recompensa. La clave es por qué se eligió GRPO sobre el PPO tradicional: PPO (Optimización de Política Proximal) requiere una red de valor independiente para estimar el valor del estado actual, lo que supone una alta carga de ingeniería para modelos grandes. GRPO muestrea múltiples respuestas para la misma indicación y usa la clasificación intragrupo en lugar de la estimación de valor absoluto, eliminando la necesidad de una red de valor independiente. La serie DeepSeek y la infraestructura RL de Cursor Composer 2 utilizan esquemas cercanos a GRPO.

Etapa 3 realiza Ajuste Fino por Muestreo de Rechazo, filtrando las trayectorias exitosas generadas por RL y convirtiéndolas en nuevos datos SFT para otra ronda de ajuste fino supervisado. Este es el puente entre RL y SFT; las buenas trayectorias exploradas por RL se convierten en muestras de entrenamiento de alta calidad para la siguiente ronda de SFT.

Etapa 4 integra la retroalimentación de preferencias de utilidad y seguridad para ajustar el modelo a una forma de asistente que cumpla con los estándares de lanzamiento.

Las cuatro etapas son interdependientes: el arranque en frío permite que RL comience de manera estable, RL genera datos de alta calidad, el muestreo de rechazo convierte esos datos en entrada para la siguiente ronda de SFT, y la alineación RL completa la convergencia del comportamiento. A partir de los resultados públicos, la brecha entre SFT directo y completar las cuatro etapas suele ser visible.

Evaluación, Calificador y Recompensa están redefiniendo los objetivos de entrenamiento

El componente responsable de convertir la salida del modelo en puntuaciones de entrenamiento se llama calificador, y puede tener problemas inesperados fácilmente. Si solo mira la respuesta final, el modelo aprende rápidamente a tomar atajos; si la puntuación es demasiado gruesa, el ruido será amplificado continuamente por el aprendizaje por refuerzo; si la puntuación del leaderboard sube, las tareas reales podrían no seguir la misma tendencia. A menudo, los usuarios creen que están viendo una brecha en el modelo base, pero la brecha está en cómo se define el objetivo.

En el flujo de entrenamiento, eval determina qué probar, calificador determina cómo una salida se convierte en una puntuación, y recompensa determina hacia dónde se empujará al modelo. Juntos forman un bucle de retroalimentación específico: definición de tarea, eval, calificador, optimización, despliegue y reevaluación. Despliegue se refiere a las trayectorias generadas por el modelo al ejecutar tareas. Si algún eslabón de la cadena se desvía, la optimización posterior también se desviará.

Mirando solo el resultado final, un modelo podría acertar por casualidad o seguir un proceso incorrecto para obtener la respuesta correcta. Esto es especialmente obvio en código, matemáticas y tareas de razonamiento complejas. Si los pasos intermedios no entran en la retroalimentación, lo que el modelo aprende a menudo no es un razonamiento más fiable, sino cómo obtener ese punto final con mayor probabilidad.

Por lo tanto, más trabajo en los últimos años se ha desplazado del RLHF tradicional a recompensas verificadas, utilizando programas para verificar directamente la corrección. En tareas verificables como matemáticas, código y lógica, la corrección ahora se puede puntuar directamente sin depender principalmente de la preferencia humana. Pero las recompensas verificadas no han resuelto completamente el problema. Fenómenos como la sobreoptimización, el sobreajuste de recompensas (donde las reglas de puntuación se sobreoptimizan sin una ganancia real de capacidad) y el colapso de modo (donde la salida se vuelve altamente singular y pierde diversidad) todavía ocurren. El problema ha pasado de si las preferencias se etiquetan con precisión a si la cadena de puntuación es estable.

El proceso de pensamiento escrito por el modelo no puede tratarse como un registro completo de los procesos internos. Anthropic encontró en experimentos de observabilidad de modelos de razonamiento que los modelos usan pistas adicionales pero no lo admiten en el CoT visible; en escenarios de hacking de recompensas, son más propensos a agregar una explicación de aspecto plausible. El hacking de recompensas consiste en explotar el sistema de puntuación en lugar de completar realmente la tarea. El CoT visible es más adecuado como señal de entrenamiento y monitoreo, no como la verdad completa.

Yendo una capa más profunda, los modelos podrían incluso comenzar a explotar el propio canal de puntuación. La investigación sobre la manipulación de recompensas y la falsificación de alineación muestra que los modelos podrían teóricamente intervenir activamente en el proceso de puntuación. La manipulación de recompensas es alterar directamente el proceso de cálculo de la recompensa; la falsificación de alineación es fingir alineación—parecer complaciente en la superficie mientras se ocultan intenciones no alineadas.

Una vez que un modelo tiene un acceso suficientemente fuerte al entorno, lo que optimiza no son solo los resultados de la tarea, sino potencialmente la lista de verificación, el código de recompensa y la propia relación de entrenamiento. Un experimento de Anthropic en 2025 inyectó conocimiento adicional de hacking de recompensas en un conjunto de entornos de RL de producción explotables y posteriormente observó una generalización similar. Después de aprender el hacking de recompensas, el modelo no solo continuó explotándolo en tareas similares, sino que también mostró una desalineación más amplia, como la falsificación de alineación.

Estos comportamientos no se ven en las evaluaciones de diálogo estándar, solo en entornos de tareas de Agentes. La implicación de ingeniería es directa: la recompensa, el calificador, el aislamiento del entorno y el monitoreo deben ser parte del diseño del entrenamiento.

En la fase de Agente, el diseño de la recompensa se refina aún más. El resultado final es solo un elemento; la calidad del proceso, la gestión del contexto y las restricciones contra el engaño también deben medirse por separado. Kimi K2.5 recompensa la descomposición efectiva y el paralelismo real; Chroma Context-1 puntúa los documentos relevantes encontrados durante la búsqueda; Cursor Composer 2 incluye resúmenes en tareas largas como recompensas porque si un resumen se distorsiona, el contexto subsiguiente se verá engañado.

En la implementación, ORM es un Modelo de Recompensa de Resultado, que puntúa solo la respuesta final. Las señales son escasas, los costos son bajos y es adecuado para comenzar, pero es más fácil que el modelo tome atajos. PRM es un Modelo de Recompensa de Proceso, que puntúa los pasos intermedios. Las señales son más densas y suele ser más fuerte para el razonamiento matemático y de código, pero el etiquetado y los costos del sistema son mucho más altos. OpenAI vio en experimentos de razonamiento matemático que PRM no solo mejoró la precisión, sino que también facilitó la restricción del proceso porque cada paso fue supervisado. El problema también es directo: el costo de PRM suele ser varias veces el de ORM, por lo que la mayoría de los sistemas reales comienzan con ORM. Solo en tareas verificables como matemáticas, código y lógica es más fácil automatizar PRM, utilizando programas para verificar los pasos intermedios y evitar los cuellos de botella del etiquetado humano.

El bucle completo funciona así:

Los métodos de alineación recientes están haciendo lo mismo. El AI Constitucional de Anthropic integra principios escritos por humanos en el entrenamiento, utilizando retroalimentación de IA para reemplazar las preferencias humanas individuales. La Alineación Deliberativa de OpenAI pone el cumplimiento de la seguridad en el proceso de razonamiento, permitiendo que la capacidad de razonamiento asuma parte de la restricción de seguridad. Alineación Deliberativa aquí significa que el modelo juzga las normas de seguridad por sí mismo durante la fase de razonamiento, en lugar de depender de reflejos entrenados. Ambas rutas convierten la alineación de etiquetas humanas en parte del objetivo interno del entrenamiento.

Tomando el AI Constitucional como ejemplo, el proceso de dos etapas primero permite que el modelo se autocritique y revise la salida basándose en principios, luego utiliza la retroalimentación de IA para reemplazar el etiquetado de preferencias humanas individuales. La alineación nunca es un parche que se cuelga detrás del entrenamiento; lo que el sistema prueba, cómo puntúa y lo que recompensa, el modelo se moverá en esa dirección. Esta es la herramienta de ajuste más directa en la segunda mitad del entrenamiento.

En el entrenamiento de Agentes, no solo se optimiza el modelo

En los últimos dos años, la rápida aparición de modelos de razonamiento representados por la serie o1 y DeepSeek-R1 muestra que, bajo condiciones de recompensas estables, verificación confiable e infraestructura adecuada, el RL en modelos de lenguaje puede mejorar significativamente el rendimiento en tareas de matemáticas, código y lógica.

Esto también abre una nueva dimensión: ahora se puede escalar el cómputo de inferencia. El papel del entrenamiento con RL añade otra capa: además de enseñar al modelo a responder preguntas, le enseña cómo asignar el presupuesto de inferencia—saber cuándo pensar más y cuándo detenerse. De cara al futuro, la dificultad radica en permitir que el modelo actúe de forma continua en un entorno, en lugar de simplemente alargar un único pensamiento.

Junyang Lin, ex líder del modelo Qwen, tiene una reflexión representativa sobre la ruta mixta de Thinking e Instruct: la dificultad no está en darle al modelo un interruptor para pensar, sino en que los objetivos de los dos modos son diferentes—uno busca inmediatez, cumplimiento y baja latencia, mientras que el otro busca más exploración y mayor precisión. Un paso más allá, el objetivo de entrenamiento pasa de "cuánto tiempo pensar antes de responder" a "cómo asignar el presupuesto durante la acción, cómo aceptar retroalimentación y cómo seguir avanzando en la tarea".

En este punto, el objeto de entrenamiento ya no es solo un modelo que responde preguntas, sino un sistema que puede planificar, llamar herramientas, recibir retroalimentación y mantener coherencia en tareas largas. En consecuencia, la pila de entrenamiento cambia: navegadores, terminales, búsqueda, sandboxes de ejecución, sistemas de memoria, servidores de herramientas y marcos de orquestación comienzan a formar parte del sistema de entrenamiento.

Más precisamente, un harness es un programa de control que envuelve al modelo. Este concepto no pertenece solo al runtime del Agent; también existe en la fase de entrenamiento: determina qué entrada ve el modelo, cómo recibe retroalimentación, cuándo podar el contexto y cuándo llamar herramientas. La construcción del prompt, la actualización de memoria, la política de recuperación, la edición de contexto y la orquestación de herramientas están aquí. El entorno ya no es solo un validador estático, sino una capa que tanto el entrenamiento como el despliegue deben enfrentar directamente.

El harness debe ser estable para que el entrenamiento del modelo tenga sentido. Si los valores de retorno de las herramientas son inestables, el entorno del navegador no es consistente con el entorno en línea, o el estado del sistema de archivos no es reproducible, el calificador fallará primero, y el modelo aprenderá posteriormente a explotar las lagunas del entorno en lugar de ganar capacidad. Al entrenar Agents, a menudo estás depurando tanto el modelo como el entorno.

Los enfoques de las tres empresas son claros: Kimi usa PARL para resolver la descomposición paralela y la asignación de crédito; Cursor usa auto-resumen y RL en tiempo real para reconectar sesiones de codificación largas y tráfico de producción con el entrenamiento; Chroma entrena prune_chunks como una estrategia en sí misma, permitiendo que la poda de contexto entre directamente en el proceso de recuperación.

En la era de SFT, la diversidad de datos era primordial; en la era de los Agents, la calidad del entorno es el núcleo: estabilidad, autenticidad, cobertura, distribución de dificultad, riqueza de retroalimentación y resistencia a la explotación. Los objetivos de entrenamiento cambian en consecuencia, exigiendo fiabilidad en tareas completas, no solo acertar una pregunta. Los benchmarks clásicos de CoT no pueden cubrir esto.

Este cambio continúa avanzando: no solo entrenar al modelo dentro de un harness de runtime, sino que incluso el código del harness mismo se está convirtiendo en un objeto que puede ser buscado y optimizado por un bucle externo.

El PARL de Kimi K2.5 es un caso de ingeniería notable con una ruta clara: solo entrenar al orquestador, restringir la asignación de crédito a la capa de orquestación y no optimizar todos los subagentes simultáneamente.

Las señales de recompensa se dividen en tres categorías: éxito de la tarea, descomposición paralela y restricciones de finalización, que juntas impulsan la capa de orquestación. Al principio del entrenamiento, se aumenta el peso de r_parallel para fomentar la exploración de estrategias paralelas, y luego se reduce gradualmente a 0 más tarde para evitar que abrir múltiples subagentes se convierta en un atajo. La evaluación no solo mira los pasos totales, sino también la longitud de la ruta crítica; una ruta crítica más corta indica que el paralelismo es realmente efectivo.

Pero para 2026, las cosas han avanzado un paso más. Meta-Harness trata explícitamente la ingeniería del harness como un objetivo de optimización separado. No optimiza pesos, sino el código del harness en sí—los programas de construcción de prompts, recuperación, memoria y actualización de estado que rodean a un modelo fijo. Los números al comienzo del artículo son directos: para el mismo modelo base, solo cambiando el harness se puede obtener una brecha de rendimiento de 6x en el mismo benchmark. Este conjunto de programas fuera del modelo ya no es solo un detalle de despliegue, sino una capa de formación de capacidades.

La clave no es añadir otro optimizador abstracto, sino escribir código previo, puntuaciones y trazas de ejecución (registros de llamadas a herramientas y cambios de estado) en el sistema de archivos, permitiendo que un propositor use grep, cat y diff como al escribir código, y luego modifique el harness a lo largo de las rutas de fallo. El propositor es el módulo que sugiere modificaciones al harness.

Los autores juzgan claramente que muchos optimizadores de texto del pasado no eran efectivos para programas con estado a largo plazo como los harnesses, porque mirar solo puntuaciones escalares, plantillas cortas o resúmenes aplana el problema. Las puntuaciones escalares solo proporcionan puntos finales sin información del proceso. Los errores del harness a menudo se manifiestan muchos pasos después; una vez que la retroalimentación está demasiado comprimida, la cadena de diagnóstico se rompe.

Estos resultados son más que solo puntuaciones más altas en benchmarks. En clasificación de texto en línea, Meta-Harness supera a ACE (línea base de ingeniería de contexto de agentes) por 7.7 puntos, mientras comprime el uso de tokens de contexto a 1/4. En razonamiento matemático aumentado con recuperación, un harness descubierto mejoró 5 modelos no participantes (que no estaban involucrados en la optimización) en un promedio de 4.7 puntos en 200 problemas de nivel IMO. En TerminalBench-2, también superó las líneas base de ingeniería manual. Esto muestra que lo que se está optimizando ya no son solo las estrategias internas del modelo, sino también los programas que organizan la información y las acciones alrededor del modelo.

Un ejemplo específico: Meta-Harness descubrió automáticamente el bootstrap del entorno en TerminalBench-2—ejecutar un comando de shell antes de que comience el bucle del agente para organizar el directorio de trabajo, los lenguajes disponibles, los gestores de paquetes y el estado de la memoria en una instantánea inyectada en el primer prompt. Muchos agentes de codificación pasan las primeras rondas explorando el entorno; con este preprocesamiento hecho, la mejora no proviene necesariamente de pesos más fuertes, sino de que el harness permite que el modelo comience con un mejor contexto.

En este punto, el objetivo de optimización se ha expandido desde las respuestas a las trayectorias, y luego al programa harness que transporta esas trayectorias.

Después de que se publica un modelo líder, la cadena de entrenamiento continúa

Entender los grandes modelos actuales solo a través del lente de una sola ronda de preentrenamiento ya no es suficiente. Detrás de un modelo publicado, generalmente se ha completado toda la cadena de preentrenamiento, postentrenamiento, destilación y especialización, y los modelos más fuertes continúan produciendo datos de entrenamiento para la próxima generación.

La destilación de la serie DeepSeek-R1 es un ejemplo típico. Un modelo grande primero desarrolla capacidades de razonamiento a través de RL y recompensas verificadas, y luego transfiere estas trayectorias de razonamiento a modelos densos más pequeños. Modelos especializados como TranslateGemma muestran otra ruta: en tareas objetivo más específicas, usando datos de alta calidad y diseños de recompensa especializados para comprimir y dirigir aún más las capacidades. En esta etapa, los modelos más fuertes no solo sirven a los usuarios, sino que también producen directamente datos de entrenamiento para la próxima generación.

La razón detrás de esto es más fundamental que la transferencia de trayectorias: una posible explicación es que en los corpus de internet, el conocimiento memorístico y la capacidad de razonamiento están acoplados, y los objetivos de preentrenamiento existentes requieren que los modelos aprendan ambos bien. Los modelos grandes deben venir primero porque solo ellos son lo suficientemente grandes para soportar ambos, y luego pueden usarse para generar datos de demostración de razonamiento puro. Cuando los modelos pequeños entrenan con tales datos, pueden centrarse en el razonamiento en sí mismos sin verse obligados a recordar todo el conocimiento. Empezar grande y luego ir a pequeño trata sobre el desacoplamiento de capacidades, no solo una estrategia de costos.

Por otro lado, la adaptabilidad al despliegue es tan importante como la capacidad en sí misma. Muchos escenarios no necesitan un modelo grande polivalente; les importa más el costo, la latencia, la estabilidad y la controlabilidad. El final del entrenamiento no es necesariamente más grande, sino potencialmente más pequeño, más barato y más especializado.

El modelo finalmente publicado no es necesariamente el checkpoint en el extremo derecho de la curva de entrenamiento. Antes del lanzamiento real, a menudo se comparan repetidamente múltiples checkpoints por resultados de tareas reales, estilos de rechazo, estabilidad de herramientas, costo y riesgos de regresión. La versión que se publica es a menudo una decisión de producto, no la que tiene el mejor rendimiento en una sola métrica.

Cuando los usuarios ven un nombre de modelo, asumen que corresponde a una curva de entrenamiento que sube suavemente, pero qué checkpoint se pone realmente en línea es otro asunto.

El valor de un modelo grande radica tanto en su propia capacidad de servicio como en su provisión continua de datos de entrenamiento, fuentes de destilación y bases de lanzamiento para la próxima generación.

Más allá del entrenamiento fuera de línea, la optimización continua casi en línea ha entrado en el proceso principal. El RL en tiempo real de Cursor Composer 2 muestra que algunas capacidades de los Agents han comenzado a iterarse continuamente a través del tráfico de producción, en lugar de esperar la próxima ronda de entrenamiento fuera de línea a gran escala. El límite entre entrenamiento y despliegue no ha desaparecido, pero el bucle de retroalimentación entre ellos se está acortando.

Cómo juzgar por qué un modelo se ha vuelto más fuerte en el futuro

El valor de los modelos líderes en 2026 depende cada vez más de quién puede completar toda la cadena de entrenamiento después del preentrenamiento: producir continuamente datos de entrenamiento, hacer destilación, hacer especialización, hacer bien la evaluación y las recompensas, y tomar decisiones finales de lanzamiento.

Por eso, al mirar por qué un modelo de repente se vuelve más fuerte, puedes fijarte primero en tres cosas:

• Primero, ver si el cambio ocurrió en la capa de preentrenamiento o en el proceso de entrenamiento posterior. Muchas mejoras de capacidad provienen efectivamente de un mejor preentrenamiento y mejores recetas de datos, pero muchos cambios percibidos en realidad provienen del postentrenamiento. Si un modelo sigue instrucciones, usa herramientas o tiene un estilo de respuesta estable, a menudo no crece naturalmente solo entrenando con más corpus.
• A continuación, ver de qué capa proviene la mejora: si es de los pesos y recetas de entrenamiento, o de la recompensa/evaluación/calificador, o del código del harness y el bucle de despliegue. Para cuando llegamos a los modelos de razonamiento y los Agents, la fuerza que sienten los usuarios a menudo no es el resultado del modelo base solo. Cómo se configuran las evaluaciones, cómo se puntúan las recompensas, si el entorno de herramientas es estable, cómo se organizan la recuperación y la memoria, cómo se resumen y podan los contextos, y qué checkpoint se eligió para el lanzamiento—todo esto cambia conjuntamente el rendimiento del producto final.
• Finalmente, ver qué está optimizando la versión en línea. Algunas versiones buscan un techo más alto, algunas buscan menor costo, latencia y riesgo de regresión, y algunas están especializadas para cierto tipo de escenario. La versión de lanzamiento es una decisión de producto, no el punto en el extremo derecho de la curva de entrenamiento. Por lo tanto, al mirar las actualizaciones de modelos, observar qué es lo que realmente está optimizando estará más cerca de la verdad.

Desglosar la mejora repentina de un modelo en etapas de producción revela que muchas ganancias son en realidad amplificadas por la segunda mitad de la pila de entrenamiento y el harness externo. El ciclo de iteración de esta cadena también se está acortando: el tráfico de producción fluye continuamente de vuelta al entrenamiento, cada generación de modelos más fuertes produce datos de supervisión de próxima generación mientras produce capacidades, y los programas externos se reescriben constantemente basándose en despliegues, registros y retroalimentación de tareas reales.

El modelo publicado hoy es solo una instantánea; el pipeline y el programa harness son los productos que continúan ejecutándose.

Materiales de aprendizaje

1. Hoffmann et al. (2022). Training Compute-Optimal Large Language Models (Chinchilla). arXiv:2203.15556
2. Ouyang et al. (2022). Training language models to follow instructions with human feedback (InstructGPT). arXiv:2203.02155
3. Shao et al. (2024). DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models (GRPO). arXiv:2402.03300
4. DeepSeek-AI (2025). DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning. arXiv:2501.12948
5. DeepSeek-AI (2024). DeepSeek-V3 Technical Report. arXiv:2412.19437
6. Llama Team, AI @ Meta (2024). The Llama 3 Herd of Models. arXiv:2407.21783
7. Bai et al. (2022). Constitutional AI: Harmlessness from AI Feedback. arXiv:2212.08073
8. OpenAI (2024). Deliberative Alignment: Reasoning Enables Safer Language Models. openai.com/index/deliberative-alignment
9. Anthropic (2025). Sycophancy to Subterfuge: Investigating Reward Tampering in Language Models. anthropic.com/research/reward-tampering
10. MacDiarmid et al. (2025). Natural Emergent Misalignment from Reward Hacking in Production RL. arXiv:2511.18397
11. Lee et al. (2026). Meta-Harness: End-to-End Optimization of Model Harnesses (preprint project page). yoonholee.com/meta-harness
12. Kimi Team (2026). Kimi K2.5 Tech Blog: Visual Agentic Intelligence. kimi.com/blog/kimi-k2-5
13. Rush, S. (2026). A technical report on Composer 2. cursor.com/blog/composer-2-technical-report
14. Chroma (2026). Chroma Context-1: Training a Self-Editing Search Agent. trychroma.com/research/context-1

Este artículo no autoriza ninguna forma de reproducción o reescritura para su republicación. Si encuentras alguna, por favor ayúdame a reportarla.