Lo que cambió en el stack de post-training en los últimos dos trimestres
La conversación de fine-tuning de alineación que ancló 2024 — cómo recolectamos suficientes datos de preferencia humana para correr PPO contra un modelo de recompensa aprendido — ya no es la conversación que están teniendo los laboratorios frontera. La forma que tomó el control durante Q1-Q2 2026 es el Aprendizaje por Refuerzo con Recompensas Verificables (RLVR, por sus siglas en inglés): el equipo escribe un verificador programático que comprueba si la salida del modelo es correcta, el verificador emite una señal de recompensa determinista, y la Optimización de Política Relativa de Grupo (GRPO) corre la actualización de política contra la recompensa del verificador sin el intermediario de modelo-de-recompensa-aprendido que requería PPO.
La forma operativamente importante:
- RLVR se ha convertido en el paradigma de post-training por defecto para modelos de razonamiento. El consenso de la literatura en las publicaciones de Q1-Q2 2026 — Tulu 3 de Allen AI, la serie R de DeepSeek, la línea de razonamiento open-source de Qwen — es que el stack de recompensa-verificable-más-GRPO es la receta de entrenamiento por defecto para cualquier clase de carga de trabajo donde se pueda escribir un verificador programático (matemáticas, código, extracción estructurada, cumplimiento de esquema, seguimiento de formato). El patrón de PPO con modelo-de-recompensa-aprendido sigue siendo la respuesta correcta para la cola de gusto-y-preferencia (tono, utilidad, alineación matizada de política) — pero la fracción portante del presupuesto de cómputo de post-training se ha desplazado a la ruta de recompensa-verificable.
- GRPO reemplaza a PPO como el algoritmo por defecto para cargas de trabajo de razonamiento. PPO requería un modelo de valor separado entrenado junto a la política, duplicando la huella de cómputo de entrenamiento y añadiendo una inestabilidad por lote alrededor de la cual el equipo tenía que afinar hiperparámetros. GRPO calcula la señal de ventaja relativa al grupo de completaciones muestreadas dentro del lote — sin modelo de valor separado, huella de cómputo menor, superficie de hiperparámetros más simple, y una señal de gradiente por lote más limpia contra la recompensa verificable. El equipo que corría PPO hace doce meses es el equipo que rehízo el pipeline de post-training contra GRPO en dos trimestres.
- El verificador es el artefacto de ingeniería portante, no el modelo de recompensa. Bajo RLHF, el modelo de recompensa aprendido era el artefacto portante — el equipo que mal-especificó los datos de entrenamiento del modelo de recompensa pasó el siguiente trimestre depurando el modo de falla de reward-hacking que el modelo aprendió a explotar. Bajo RLVR, el verificador programático es el artefacto portante — el equipo que escribe un verificador con una brecha de cobertura es el equipo que lanza un modelo que aprendió a explotar la brecha de cobertura. La competencia que el equipo tiene que mantener pasó de curación-de-modelo-de-recompensa a ingeniería-de-verificador, y la antigüedad del ingeniero que es dueño del verificador pasó de un dueño de equipo-de-investigación a un dueño de ingeniería-de-producción.
- Los artefactos de recompensa listos para auditoría cierran la brecha de revisión de cumplimiento. El verificador emite una recompensa por salida, una traza de verificación por salida, y un artefacto de calificación-de-política por salida. El conjunto de artefactos es la superficie de diligencia del comité de cumplimiento — qué verificador pasó, qué verificador falló, qué brecha-de-cobertura del verificador explotó el modelo, qué versión del verificador está corriendo el equipo contra el modelo de producción. El modelo de recompensa de agregación-de-preferencias no auditable de la era RLHF es reemplazado por una traza de verificación por salida auditable que el comité de cumplimiento del comprador de industria-regulada puede respaldar contra el despliegue de producción.
La lectura estructural no es RLHF está desapareciendo. RLHF sigue siendo la respuesta correcta para la cola de gusto-y-preferencia. La lectura estructural es que el paradigma de post-training por defecto para cualquier carga de trabajo donde se pueda escribir un verificador se ha desplazado al stack de RLVR-más-GRPO, el artefacto de ingeniería portante se ha desplazado del modelo de recompensa al verificador, y la superficie de revisión de cumplimiento se ha desplazado de un artefacto de agregación-de-preferencias no auditable a una traza de verificación por salida auditable.
Lo que RLVR cambia sobre el engagement de entrenamiento de IA del equipo
Cuatro cambios concretos que se siguen cuando el pipeline de post-training de grado-producción se mueve de RLHF contra un modelo de recompensa aprendido a RLVR contra un verificador programático.
La función de ingeniería-de-verificador se convierte en un rol de ingeniería-de-producción de primer nivel, no en un rol de investigación. El equipo que lanza un modelo entrenado con RLVR a producción tiene que dotar la función de ingeniería-de-verificador — el ingeniero que escribe el verificador por carga-de-trabajo, instrumenta el mapa de cobertura por verificador, mantiene la taxonomía de modos-de-falla por verificador, y es dueño de la retrospectiva por trimestre de brecha-de-cobertura. La respuesta honesta de dotación es un ingeniero de producción senior por clase mayor de carga-de-trabajo, no un científico de investigación que entrega el verificador al equipo de ingeniería después de que se publica el paper.
El mapa de cobertura por carga-de-trabajo del verificador se convierte en el artefacto permanente contra el que califica la superficie de fiabilidad de producción. La brecha de cobertura del verificador es la superficie de reward-hacking del modelo. El equipo que lanza el verificador sin el mapa de cobertura por carga-de-trabajo es el equipo que lee el post-mortem de producción sobre el modo de falla silencioso del modelo que el verificador no restringió. El mapa de cobertura es un artefacto listo-para-revisión-de-código, vive en el repositorio del equipo, se refresca en la misma cadencia en que se reentrena el modelo de producción, y es el artefacto contra el que la superficie de fiabilidad de producción califica el plan por trimestre de lanzamiento-de-brecha-de-cobertura.
La fuerza de trabajo human-in-the-loop pasa de etiquetado-de-preferencias a curación-de-modos-de-falla-del-verificador. La fuerza de trabajo human-in-the-loop de la era RLHF calificaba cuál de dos completaciones es mejor contra una rúbrica de preferencia por evaluador. La fuerza de trabajo human-in-the-loop de la era RLVR califica qué salidas pasadas por el verificador debió haber marcado el verificador como falla de brecha-de-cobertura contra una rúbrica de mapeo-de-cobertura por carga-de-trabajo — un perfil de competencia diferente (experto de dominio con alfabetización de modos-de-falla-del-verificador, no un evaluador generalista de preferencias), una banda de pago por evaluador diferente (tarifas de experto-de-dominio, no tarifas de trabajador-de-multitud), y un perfil de rendimiento por evaluador diferente (revisión más profunda por tarea, menos tareas por turno). El contrato permanente de servicios-de-entrenamiento-de-IA que se alcanzó contra la carga de trabajo de calificación-por-preferencia es el contrato que necesita la carga de trabajo de curación-por-brecha-de-cobertura añadida como partida de primer nivel.
La cola de gusto-y-preferencia sigue necesitando un sustrato RLHF — el equipo tiene que mantener ambos. RLVR cierra la brecha de corrección-verificable; no cierra la brecha de tono, utilidad, alineación-matizada-de-política que la característica de cara al usuario en producción todavía necesita. Los equipos que leen la narrativa de RLVR-por-defecto como podemos apagar el sustrato RLHF son los equipos que lanzan la regresión por característica en la superficie de experiencia-de-usuario dentro de un trimestre. La respuesta honesta de dotación es el pipeline de post-training de doble sustrato — RLVR para la ruta de corrección-verificable, RLHF para la ruta de gusto-y-preferencia, con la decisión de enrutamiento por característica contra las dos rutas mantenida como un artefacto listo-para-revisión-de-código.
Dónde golpea al equipo de producto-integrado-con-IA en el próximo sprint
El equipo de producto que lanza una característica de IA que depende de un modelo por carga-de-trabajo tiene tres piezas concretas de trabajo que caen en el backlog del sprint esta semana.
Escribir el verificador por carga-de-trabajo para la característica de producción de mayor riesgo. Para la característica cuya corrección por salida es la superficie portante (extracción transaccional, generación de datos estructurados, emisión-de-código, respuestas API compatibles con esquema), escribir el verificador programático por salida e instrumentar el registro de traza-de-verificación por salida. El verificador es el artefacto contra el que el equipo califica el modelo de producción hoy; es también el artefacto que el equipo entregará al proveedor de fine-tuning RLVR el día que el equipo decida lanzar el modelo entrenado por carga-de-trabajo.
Documentar el mapa de cobertura por carga-de-trabajo contra el verificador. La brecha de cobertura del verificador es la superficie de falla silenciosa del modelo. Para cada verificador que el equipo lanza, documentar el mapa de cobertura por carga-de-trabajo — qué clases de entrada cubre el verificador, qué clases de entrada no, qué clases de entrada ha marcado el equipo como fuera-de-alcance para el verificador, qué clases de entrada ha marcado el equipo como el objetivo por trimestre de lanzamiento-de-brecha-de-cobertura. El mapa de cobertura es el artefacto contra el que la superficie de fiabilidad de producción califica el plan por trimestre de lanzamiento.
Reformular el engagement human-in-the-loop de entrenamiento de IA contra la carga de trabajo de brecha-de-cobertura-del-verificador. El contrato actual de servicios-de-entrenamiento-de-IA del equipo probablemente se alcanzó contra la carga de trabajo de calificación-por-preferencia. La reformulación de Q3 añade la carga de trabajo de curación-por-brecha-de-cobertura-del-verificador como partida de primer nivel — el volumen de tareas por turno, la profundidad de revisión por tarea, el perfil de experto-de-dominio por evaluador, y la banda de pago por evaluador que requiere la carga de trabajo de curación-por-brecha-de-cobertura. El equipo que reformula el contrato este trimestre tiene la fuerza de trabajo lista para el ciclo de fine-tuning RLVR de Q4; el equipo que no reformula es el equipo que se apresura a conseguir la fuerza de trabajo cuando el objetivo por trimestre del mapa de cobertura del verificador aparece contra la superficie de fiabilidad de producción.
El juicio senior que hace visible la función de ingeniería-de-verificador
El sustrato de RLVR-más-GRPO comprime el costo de correr el bucle de post-training contra un modelo de recompensa aprendido para el que el equipo tuvo que curar los datos de preferencia. No comprime el juicio senior de decidir qué clases de carga-de-trabajo tienen forma de verificador y cuáles no, escribir el verificador por carga-de-trabajo contra la superficie de fiabilidad de producción, ser dueño del plan por trimestre de lanzamiento-de-brecha-de-cobertura contra el verificador, correr la prueba de regresión por característica contra el pipeline de doble sustrato RLVR-y-RLHF, y reformular el contrato permanente de servicios-de-entrenamiento-de-IA contra la carga de trabajo de brecha-de-cobertura-del-verificador. Los equipos que confunden la curación-de-modelo-de-recompensa abaratada con el juicio abaratado son los equipos que lanzan el post-mortem de producción sobre el modo de falla silencioso de reward-hacking del modelo que la brecha de cobertura del verificador no restringió. Los equipos que mantienen el juicio senior en el centro de la función de ingeniería-de-verificador son los equipos que lanzan el despliegue de producción listo-para-auditoría que el comité de cumplimiento del comprador de industria-regulada respalda en la revisión de fiabilidad de producción de FY27.
La pregunta de entrenamiento de IA ya no es con qué proveedor de RLHF contrata el equipo la carga de trabajo de etiquetado de preferencias; es qué función de ingeniería-de-verificador dota el equipo contra la superficie de fiabilidad de producción por carga-de-trabajo, qué mapa de cobertura por carga-de-trabajo lanza el equipo contra el verificador, qué pipeline de doble sustrato RLVR-y-RLHF opera el equipo contra la decisión de enrutamiento por característica, y qué carga de trabajo de curación-por-brecha-de-cobertura-del-verificador formula el equipo contra el contrato permanente de servicios-de-entrenamiento-de-IA. Los equipos que hacen la pregunta correcta este trimestre lanzan el modelo de producción listo-para-auditoría que el comité de cumplimiento del comprador de industria-regulada puede respaldar; los equipos que hacen la incorrecta lanzan el modo de falla silencioso de reward-hacking que la brecha de cobertura del verificador no restringió.
En SONNET CODE corremos el engagement de Entrenamiento de IA como una función de ingeniería-de-verificador y human-in-the-loop — autoría de verificadores por carga-de-trabajo, curación por brecha-de-cobertura por evaluadores expertos-de-dominio, refresco por trimestre del mapa de cobertura contra la superficie de fiabilidad de producción. Si tu equipo está moviendo el pipeline de post-training de RLHF-por-defecto al stack de RLVR-más-GRPO, agenda una llamada — te llevamos por la función de ingeniería-de-verificador por carga-de-trabajo que corremos contra el contrato permanente de servicios-de-entrenamiento-de-IA.
