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", quise desafiarme a mí mismo para resumir cómo funciona realmente el entrenamiento de Modelos de Lenguaje Grande (LLM). Este artículo pretende ser comprensible incluso para quienes no tienen una formación profesional.

De cara a 2026, la verdadera brecha 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 encuentras que un modelo de repente se vuelve más fuerte, es probable que se deba a que estas áreas se optimizaron juntas, en lugar de un solo factor.

A continuación, se sigue el pipeline de entrenamiento de LLM, centrándose en cómo los fabricantes mejoran los resultados finales a través de la segunda mitad del stack de entrenamiento.

El Entrenamiento de LLM es un Pipeline

En los últimos años, el progreso de los modelos generalmente se explicaba por la acumulación de parámetros, datos y poder de cómputo. Sin embargo, las mejoras que muchos usuarios realmente sienten no provienen de entrenar con más corpus básicos, sino de todo el proceso de entrenamiento posterior al preentrenamiento. Cómo un modelo habla, sigue instrucciones, razona y usa herramientas — estas cosas no crecen naturalmente solo con alimentarlo 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 vencer al GPT-3 de 175B en evaluaciones de preferencia humana. Con una diferencia de parámetros de dos órdenes de magnitud, los usuarios finalmente prefirieron 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, algoritmos, sistemas y retroalimentación están altamente acoplados. Un cambio en una capa generalmente se propaga 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 se siente más satisfactorio en el uso diario — es porque el post-entrenamiento está bien ejecutado.

Estas seis capas son solo para ver la división del trabajo. Las nueve etapas en la figura a continuación son una versión más detallada: los datos brutos y las recetas del sistema están separados, y el arnés 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 offline regresan al preentrenamiento.

El Preentrenamiento es Solo la Base

El preentrenamiento sigue siendo el punto de partida de la cadena de entrenamiento. Solo al entender lo que hace podemos entender qué suplementa cada capa posterior. 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, hace más que solo enseñar 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 esfuerzos de ajuste de modelos consideran el presupuesto y las proporciones con más cuidado. Los modelos no son mejores solo porque sean más grandes. Hay 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 bajo un presupuesto dado.

En las decisiones reales de entrenamiento, la pregunta práctica es: si alguien te da 10,000 H100 y un mes, ¿cómo entrenarías un modelo de código abierto suficientemente bueno? Las leyes de escalado aquí son más como 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 debería 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 para 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 explote. Sin embargo, el preentrenamiento no puede controlar si el modelo sigue instrucciones, coopera con los usuarios o se ejecuta de manera estable en tareas críticas.

La fase de preentrenamiento no solo decide cuánto conocimiento se aprende; predetermina en qué puede convertirse el modelo. La forma en que el tokenizador divide el texto afecta directamente el entrenamiento posterior, y la longitud de la ventana de contexto debe establecerse de antemano. Si 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 agregan 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 están determinadas en gran medida durante la fase de entrenamiento.

Observando el punto óptimo de datos dado por Chinchilla, para un modelo de 8B parámetros, es alrededor de 200B tokens. Sin embargo, Llama 3 8B realmente usó 15T tokens, aproximadamente 75 veces más. Tales recetas de sobreentrenamiento generalmente intercambian una mayor densidad de capacidad por los mismos parámetros, resultando en un modelo más pequeño y más rentable para la inferencia. Medir esto por FLOPs totales (operaciones de punto flotante) es más confiable que mirar los recuentos de parámetros. La figura a continuación 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 bytes tienen un impacto significativo. Llama 2 tenía un vocabulario de 32K; después de que Llama 3 lo expandió a 128K, la longitud de la secuencia se comprimió aproximadamente un 15%, y el rendimiento downstream también mejoró. Este impacto se extiende a los costos de inferencia y las capacidades multilingües. La eficiencia de token 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 piezas muy pequeñas 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 era 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 primero deben pasar por extracción de texto, identificación de idioma, filtrado de calidad, procesamiento de privacidad, filtrado de seguridad y deduplicación antes de ingresar al preentrenamiento. La figura a continuación muestra el flujo completo del embudo de procesamiento.

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 necesariamente aprender 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 separado. Trabajos como Data Mixing Laws se centran no solo en cuántos más datos se pueden recopilar, 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 están todos moviéndose en la misma dirección. Cada generación de modelos más fuertes participa en la reconstrucción de los datos vistos por la próxima generación. Los primeros modelos generaron datos de instrucción básicos; los modelos más fuertes generan trayectorias de razonamiento de alta calidad y datos de CoT (Cadena de Pensamiento); y los modelos de razonamiento entrenados con 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 mayor escala 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 desde 1.5B hasta 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 GPU, el ancho de banda de 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é contexto tan largo 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 que el modelo expanda 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 equilibrio 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 publicadas recientemente ya no solo tratan de análisis de grano grueso como el tamaño del modelo y las proporciones de tokens. muP permite que los hiperparámetros se transfieran de experimentos a pequeña escala a entrenamiento a gran escala. La tasa de aprendizaje WSD es un programa que sube, se estabiliza y luego decae. Combinado con un tamaño de lote óptimo y proporciones de datos a parámetros 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, se pierden 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 de 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 los Residuales de Atención de Kimi 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 hacen más grandes, el uso de memoria de la GPU aumenta y los costos de servicio lo siguen. 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 a menudo ignorada: el entrenamiento no siempre es estable. Miles de GPU se ejecutan 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 antes para comenzar de nuevo.

Además de los picos de pérdida, hay errores silenciosos de GPU: una sola GPU que no reporta un error pero produce silenciosamente gradientes incorrectos — anomalías en el ancho de banda de NVLink y fluctuaciones en la comunicación entre nodos. Cada uno puede contaminar varios pasos de entrenamiento. Poder detectar, aislar y recuperarse 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, el proceso completo tomó aproximadamente 2.788 millones de 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 (almacenar cálculos históricos para evitar repeticiones), la cuantización y la estabilidad del servicio.

El Post-entrenamiento Determina la Brecha que Percibe el Usuario

Muchas mejoras que los usuarios comunes realmente pueden sentir 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.

Mirando 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 diferentes caminos.

• RLHF (Aprendizaje por Refuerzo a partir de Retroalimentación Humana) primero imita respuestas de alta calidad, luego utiliza 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, colocando definiciones de tareas, diseños de calificación y señales de recompensa en el proceso de productizació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 vale la pena optimizar continuamente. SFT es el 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 piensan 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 apariencia seria con otras más confiables. Por lo tanto, mirar los rankings para el post-entrenamiento a menudo es insuficiente; uno debe 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 poca legibilidad. El SFT de arranque en frío le da a RL un punto de partida más estable, asegurando la consistencia del formato y el lenguaje.

Etapa 2 realiza aprendizaje por refuerzo en campos verificables como matemáticas, código y lógica, utilizando 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 Próxima) requiere una red de valor independiente para estimar el valor del estado actual, lo que es una alta carga de ingeniería para modelos grandes. GRPO muestrea múltiples respuestas para el mismo prompt y utiliza la clasificación dentro del grupo 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 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 próxima ronda de SFT.

Etapa 4 integra 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 próxima ronda de SFT, y la RL de alineación completa la convergencia del comportamiento. A partir de resultados públicos, la brecha entre el SFT directo y completar las cuatro etapas suele ser visible.

Eval, 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 fácilmente problemas inesperados. Si solo mira la respuesta final, el modelo aprende rápidamente a tomar atajos; si la puntuación es demasiado gruesa, el ruido se amplificará continuamente por el aprendizaje por refuerzo; si la puntuación del ranking sube, las tareas reales podrían no seguir. A menudo, los usuarios piensan 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, el calificador determina cómo una salida se convierte en una puntuación, y la recompensa determina hacia dónde se empujará el modelo. Juntos forman un bucle de retroalimentación específico: definición de tarea, eval, calificador, optimización, despliegue y reevaluación. El 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 puede 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 complejo. Si los pasos intermedios no entran en la retroalimentación, lo que el modelo aprende a menudo no es un razonamiento más confiable, 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 recompensa (donde las reglas de puntuación se optimizan en exceso 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 se ha desplazado de si las preferencias están etiquetadas 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 manipulación de recompensas, es más probable que agreguen una explicación de apariencia plausible. La manipulación de recompensas es explotar el sistema de puntuación en lugar de completar realmente la tarea. El CoT visible es más adecuado como una 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 manipulación de recompensas y 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 recompensas; la falsificación de alineación es fingir alineación — parecer obediente en la superficie mientras se ocultan intenciones no alineadas.

Una vez que un modelo tiene suficiente acceso 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 relación de entrenamiento misma. Un experimento de Anthropic en 2025 inyectó conocimiento adicional de manipulación de recompensas en un conjunto de entornos de RL de codificación de producción explotables y posteriormente observó una generalización similar. Después de aprender la manipulación de recompensas, el modelo no solo continuó explotándola 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 recompensas 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 anti-trampas también deben medirse por separado. Kimi K2.5 recompensa la descomposición efectiva y el paralelismo verdadero; 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 está distorsionado, el contexto posterior 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 para el modelo tomar 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 estaba 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 de etiquetado humano.

El bucle completo se ejecuta así:

Los métodos de alineación recientes están haciendo lo mismo. La IA 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 seguridad en el proceso de razonamiento, permitiendo que la capacidad de razonamiento misma soporte parte de la restricción de seguridad. La Alineación Deliberativa aquí significa que el modelo juzga las normas de seguridad por sí mismo durante la fase de razonamiento en lugar de confiar en reflejos entrenados. Ambas rutas convierten la alineación de etiquetas humanas en parte del objetivo interno de entrenamiento.

Tomando la IA 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 colgado detrás del entrenamiento; lo que el sistema prueba, cómo puntúa y qué 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 rol del entrenamiento con RL agrega 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 pasa a ser permitir que el modelo actúe de forma continua en un entorno, en lugar de solo 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, el stack de entrenamiento cambia: navegadores, terminales, búsqueda, sandboxes de ejecución, sistemas de memoria, servidores de herramientas y marcos de orquestación comienzan a entrar en el sistema de entrenamiento.

Más precisamente, un harness es un programa de control que envuelve al modelo. Este concepto no solo pertenece al runtime de Agent; también existe en la fase de entrenamiento: determinar qué entrada ve el modelo, cómo recibe retroalimentación, cuándo podar el contexto y cuándo llamar herramientas. La construcción de prompts, la actualización de memoria, la política de recuperación, la edición de contexto y la orquestación de herramientas están todas 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 es inconsistente con el entorno en línea, o el estado del sistema de archivos no es reproducible, el calificador fallará primero, y el modelo aprenderá a explotar las vulnerabilidades 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 largas de codificación y tráfico de producción de vuelta al entrenamiento; Chroma entrena prune_chunks como una estrategia en sí misma, dejando 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 Agent, 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, requiriendo confiabilidad 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 el modelo dentro de un harness de runtime, sino que incluso el código del harness se está convirtiendo en un objeto que puede ser buscado y optimizado por un bucle externo.

PARL de Kimi K2.5 es un caso de ingeniería notable con una ruta clara: entrenar solo al orquestador, consolidando la asignación de crédito en 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. En el entrenamiento temprano, se aumenta el peso de r_parallel para fomentar la exploración de estrategias paralelas, luego se reduce gradualmente a 0 más tarde para evitar tratar la apertura de múltiples subagentes como 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 verdaderamente 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í mismo: 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 agregar 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 proposer haga grep, cat y diff como al escribir código, y luego modifique el harness a lo largo de las rutas de fallo. El proposer es el módulo que sugiere modificaciones del harness.

Los autores juzgan claramente que muchos optimizadores de texto pasados no fueron efectivos para programas con estado a largo plazo como los harness porque mirar solo puntuaciones escalares, plantillas cortas o resúmenes aplana el problema. Las puntuaciones escalares solo proporcionan puntos finales sin información de proceso. Los errores del harness a menudo se manifiestan muchos pasos después; una vez que la retroalimentación se comprime en exceso, 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 (baseline 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 retenidos (no involucrados en la optimización) en un promedio de 4.7 puntos en 200 problemas de nivel Olimpiada Internacional de Matemáticas (IMO). En TerminalBench-2, también superó las líneas base manuales de ingeniería. 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 la inicialización del entorno (bootstrap) 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, la mejora no necesariamente proviene de pesos más fuertes, sino del harness que permite al modelo comenzar con un mejor contexto.

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

Después de Lanzar un Modelo Líder, la Cadena de Entrenamiento Continúa

Ya no es suficiente entender los grandes modelos de hoy únicamente a través de una sola ronda de preentrenamiento. Detrás de un modelo lanzado, la cadena completa de preentrenamiento, post-entrenamiento, destilación y especialización suele estar completada, 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, 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 corpus de internet, la memoria de conocimiento y la capacidad de razonamiento están acopladas, 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 concentrarse en el razonamiento en sí mismos sin verse obligados a recordar todo el conocimiento. Empezar grande y luego ir a pequeño se trata de desacoplar capacidades, no solo de 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 todoterreno; les importa más el costo, la latencia, la estabilidad y el control. 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 lanzado no es necesariamente el checkpoint en el extremo derecho de la curva de entrenamiento. Antes del lanzamiento real, a menudo se comparan múltiples checkpoints repetidamente por resultados en tareas reales, estilos de rechazo, estabilidad de herramientas, costos y riesgos de regresión. La versión que sale en línea suele ser 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 Agent han comenzado a iterar 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 evaluación y recompensas bien, y tomar decisiones finales de lanzamiento.

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

• Primero, mira si el cambio ocurrió en la capa de preentrenamiento o en el proceso de entrenamiento posterior. Muchas mejoras de capacidad provienen ciertamente de un mejor preentrenamiento y mejores recetas de datos, pero muchos cambios percibidos provienen en realidad del post-entrenamiento. Si un modelo sigue instrucciones, usa herramientas, o tiene un estilo de respuesta estable, a menudo no crece naturalmente solo con entrenar en más corpus.
• A continuación, mira de qué capa proviene la mejora: si es de pesos y recetas de entrenamiento, o de recompensa/evaluación/calificador, o del código del harness y el bucle de despliegue. Para cuando llegamos a modelos de razonamiento y Agents, la fortaleza 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 el rendimiento final del producto.
• Finalmente, mira qué está optimizando la versión en línea. Algunas versiones persiguen un techo más alto, otras persiguen 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. Así que al mirar las actualizaciones de modelo, mirar qué está optimizando realmente estará más cerca de la verdad.

Desglosar la mejora repentina de un modelo en etapas de producción muestra que muchas ganancias son en realidad amplificadas por la segunda mitad del stack 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 rollouts, registros y retroalimentación de tareas reales.

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

Materiales de Estudio

1. Hoffmann et al. (2022). Entrenamiento de modelos de lenguaje grandes con cómputo óptimo (Chinchilla). arXiv:2203.15556
2. Ouyang et al. (2022). Entrenamiento de modelos de lenguaje para seguir instrucciones con retroalimentación humana (InstructGPT). arXiv:2203.02155
3. Shao et al. (2024). DeepSeekMath: Empujando los límites del razonamiento matemático en modelos de lenguaje abiertos (GRPO). arXiv:2402.03300
4. DeepSeek-AI (2025). DeepSeek-R1: Incentivando la capacidad de razonamiento en modelos de lenguaje grandes mediante aprendizaje por refuerzo. arXiv:2501.12948
5. DeepSeek-AI (2024). Informe técnico de DeepSeek-V3. arXiv:2412.19437
6. Llama Team, AI @ Meta (2024). La manada de modelos Llama 3. arXiv:2407.21783
7. Bai et al. (2022). IA Constitucional: Inocuidad a partir de retroalimentación de IA. arXiv:2212.08073
8. OpenAI (2024). Alineación deliberativa: El razonamiento permite modelos de lenguaje más seguros. openai.com/index/deliberative-alignment
9. Anthropic (2025). De la adulación al subterfugio: Investigando la manipulación de recompensas en modelos de lenguaje. anthropic.com/research/reward-tampering
10. MacDiarmid et al. (2025). Desalineación emergente natural a partir del hackeo de recompensas en RL de producción. arXiv:2511.18397
11. Lee et al. (2026). Meta-Harness: Optimización de extremo a extremo de harnesses de modelos (página del proyecto preprint). yoonholee.com/meta-harness
12. Kimi Team (2026). Blog técnico de Kimi K2.5: Inteligencia agentiva visual. kimi.com/blog/kimi-k2-5
13. Rush, S. (2026). Un informe técnico sobre Composer 2. cursor.com/blog/composer-2-technical-report
14. Chroma (2026). Chroma Context-1: Entrenando un agente de búsqueda autoeditante. trychroma.com/research/context-1

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