🤖 AI

Beyond Next-Token Prediction: An RLVR Proof of Concept for Tool-Use Agents on Atlassian Workflows

Este artículo presenta una prueba de concepto que demuestra que el Aprendizaje por Refuerzo con Recompensas Verificables (RLVR) mejora significativamente la capacidad de los modelos de lenguaje pequeños para ejecutar llamadas a herramientas complejas y de múltiples pasos en entornos sintéticos de Atlassian (Jira y Confluence), logrando tasas de éxito casi perfectas en la mayoría de los escenarios sin depender de APIs en vivo o retroalimentación humana.

Autores originales: Karthikeya Aditya Vissa, Sankalp Mane, Ananya Mantravadi, Harshit Rajgarhia, Abhishek Mukherji

Publicado 2026-07-03

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Karthikeya Aditya Vissa, Sankalp Mane, Ananya Mantravadi, Harshit Rajgarhia, Abhishek Mukherji

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que tienes a un bibliotecario muy inteligente y culto (la IA) que es excelente prediciendo la siguiente palabra en una oración. Si le preguntas: "El cielo es...", con confianza dirá "azul". Pero si le pides que realmente haga algo en un sistema de oficina complejo —como "Crear un nuevo ticket de proyecto y vincularlo a una página específica"— a menudo tropieza. Puede que sepa las palabras para decir, pero se equivoca en los detalles, como poner el número de ID incorrecto en la casilla equivocada o olvidar verificar primero si la casilla existe.

Este artículo trata sobre enseñar a ese bibliotecario cómo realmente hacer el trabajo, no solo hablar de él, utilizando un método de entrenamiento específico llamado RLVR (Aprendizaje por Refuerzo con Recompensas Verificables).

Aquí está el desglose de su experimento en términos cotidianos:

1. El Problema: El "Piloto Automático" vs. El "Piloto"

Los Grandes Modelos de Lenguaje (LLMs) son entrenados para ser como pilotos automáticos que predicen la siguiente palabra. Son excelentes escribiendo historias o correos electrónicos. Pero en una oficina corporativa (específicamente usando herramientas de Atlassian como Jira y Confluence), el éxito no se trata de escribir una frase bonita; se trata de presionar los botones exactos en el orden exacto con los datos exactos.

La Forma Antigua: Le pides a la IA que "Cree una subtarea". La IA podría decir: "De acuerdo, crearé una subtarea", pero olvida asignarla a una persona o usa el código de proyecto incorrecto. Parece fluida, pero la tarea falla.
El Objetivo: Los autores querían ver si podían entrenar a la IA para que deje de solo "adivinar la siguiente palabra" y comience a "actuar como un piloto" que revisa los instrumentos antes de volar.

2. La Solución: Un Campo de Entrenamiento de "Videojuego"

En lugar de dejar que la IA practique en los servidores reales y vivos de la empresa (lo cual es arriesgado y lento), los autores construyeron un gemelo digital perfecto (una versión de videojuego) de los sistemas Jira y Confluence.

El Simulador: Este "juego" se ve y actúa exactamente como el software real, pero es seguro. Si la IA comete un error, nada se rompe.
El Árbitro (El Sistema de Recompensa): Esta es la salsa secreta. Usualmente, necesitas a un humano para calificar el trabajo de la IA. Aquí, construyeron un árbitro automatizado y estricto.
- ¿La IA pone los datos correctos en la casilla correcta? Puntos.
- ¿La IA verifica si una página existe antes de intentar editarla? Puntos de bonificación.
- ¿La IA intenta usar una herramienta que no existe o olvida un paso requerido? Puntos de penalización.
- Crucialmente: El árbitro no necesita que un humano mire la pantalla. Solo revisa las matemáticas y el código.

3. El Entrenamiento: Ensayo y Error

Tomaron dos versiones de una IA (un modelo más pequeño de 1.7B y uno más grande de 4B) y las dejaron jugar en este simulador miles de veces.

La IA intenta completar una tarea (como "Crear una página").
Falla, recibe una puntuación baja del árbitro e intenta de nuevo.
Lentamente aprende: "Oh, obtuve puntos cuando verifiqué la página principal primero. Perdí puntos cuando olvidé el código del proyecto".
Esto es Aprendizaje por Refuerzo: La IA aprende recibiendo recompensas por un buen comportamiento y penalizaciones por un mal comportamiento.

4. Los Resultados: De "Aceptable" a "Perfecto"

Probaron la IA antes y después de este entrenamiento en cinco tareas de oficina diferentes.

Antes del Entrenamiento: La IA era decente en tareas simples pero terrible en las complejas. Por ejemplo, al crear una nueva página de Confluence, la IA no entrenada solo obtenía aproximadamente el 35% de los puntos. Seguía cometiendo errores pequeños pero costosos.
Después del Entrenamiento: La IA entrenada se volvió casi perfecta. En esa misma tarea de creación de páginas, saltó al 100%.
La Gran Victoria: El entrenamiento fue más efectivo en las tareas más difíciles (aquellas con más reglas y campos de datos). La IA aprendió a seguir el patrón estricto de "verificar-luego-hacer" requerido por estos sistemas.

5. El "Pero" (Limitaciones)

Los autores son muy honestos sobre lo que esto no hace todavía:

No es magia para todo: Tuvieron que diseñar manualmente las "reglas del árbitro" para estas tareas específicas. No puedes simplemente conectar esto a cualquier software en el mundo sin construir un nuevo árbitro para él primero. Es como tener un entrenador que es increíble enseñando fútbol pero aún no ha aprendido baloncesto.
Una tarea era demasiado fácil: Para una tarea específica (cambiar el estado de un ticket), la IA ya era perfecta antes del entrenamiento, por lo que el entrenamiento no añadió ningún valor ahí.

La Conclusión

Este artículo demuestra que puedes tomar una IA estándar, ponerla en un entorno de oficina simulado y seguro, y usar un árbitro automatizado estricto para enseñarle cómo seguir reglas complejas. Esto transforma a la IA de un "bot charlatán" que suena bien pero falla en los detalles, en un "trabajador confiable" que hace el trabajo perfectamente. Sin embargo, esto requiere construir un "gimnasio de entrenamiento" personalizado para cada tipo específico de software que quieras que utilice.

Resumen Técnico: Más allá de la predicción del siguiente token: Una prueba de concepto de RLVR para agentes de uso de herramientas en flujos de trabajo de Atlassian

Planteamiento del problema
Los modelos de lenguaje de gran tamaño (LLM) están optimizados fundamentalmente para la predicción del siguiente token en textos a escala de internet, un objetivo que no se alinea con los requisitos de los flujos de trabajo de SaaS empresarial de nicho. En estos entornos, el éxito depende de la ejecución de llamadas a API específicas con argumentos anidados precisos en un orden estricto. El artículo sostiene que este desajuste de objetivos se manifiesta como "fallos silenciosos" en los agentes de uso de herramientas: omisión de campos obligatorios, alucinación de herramientas inexistentes o terminación prematura tras una única operación de lectura. Mientras que la literatura existente aborda la invocación de herramientas mediante el ajuste fino supervisado o el Aprendizaje por Refuerzo (RL) en la web abierta o en benchmarks de agentes generales, existe una falta de enfoque en flujos de trabajo empresariales estrechos y densos en esquemas, dominados por patrones de "verificar-luego-mutar".

Metodología
Los autores proponen una prueba de concepto utilizando Aprendizaje por Refuerzo con Recompensas Verificables (RLVR) aplicado directamente dentro de copias sintéticas y fieles al esquema de los entornos objetivo. Este enfoque elimina la necesidad de APIs en vivo, jueces de recompensa aprendidos o etiquetado mediante intervención humana.

Entornos Sintéticos: El equipo construyó cinco entornos sintéticos que emulan las APIs Jira REST v3 y Confluence v2. Estos entornos mantienen la fidelidad del esquema (coincidiendo con los contratos públicos), son deterministas y mantienen un estado pero son reajustables entre ejecuciones para evitar la contaminación.
Funciones de Recompensa Verificables: En lugar de depender de un modelo de recompensa aprendido, la corrección se determina mediante comprobadores programáticos que inspeccionan la traza de la llamada a la herramienta. La función de recompensa ( $R \in [0, 1]$ $R \in [0, 1]$ ) se descompone en tres componentes aditivos:
1. Corrección por argumento (R1): Constantes pequeñas otorgadas por coincidir con los valores de los argumentos esperados (por ejemplo, claves de proyecto específicas, IDs de padre).
2. Bonificaciones estructurales (R2): Recompensas por adherirse al patrón validar–mutar–verificar (por ejemplo, realizar una llamada get_* antes de una llamada create_*).
3. Penalizaciones (R3): Restas por comportamientos destructivos, tales como la omisión de llamadas obligatorias, formas de carga útil (payload) inválidas, llamadas duplicadas, nombres de herramientas alucinados o exceder los presupuestos de llamadas.
Bucle de Entrenamiento: Los autores emplean la Optimización de Política Relativa de Grupo (GRPO) en modelos Qwen3-1.7B y Qwen3.5-4B. El bucle de entrenamiento implica generar múltiples ejecuciones (rollouts) por cada prompt, calificándolas frente a las funciones de recompensa verificables y actualizando los parámetros de la política. El entrenamiento se realiza en hardware modesto (una o dos GPUs Nvidia RTX PRO 6000) y utiliza la parada temprana basada en la convergencia de la recompensa.

Contribuciones Clave

Suite Sintética de Atlassian: Un conjunto de cinco entornos fieles al esquema que cubren transiciones de tickets de Jira, creación de subtareas, creación de páginas de Confluence, etiquetado de páginas y un escenario de producto cruzado.
Diseño de Recompensa: Un marco para descomponer la corrección del uso de herramientas en señales verificables y programáticas (coincidencia de argumentos, orden estructural y aplicación de penalizaciones) computables enteramente a partir de las trazas de llamadas a herramientas.
Línea Base y Resultados de Entrenamiento: Una evaluación exhaustiva que compara las líneas base de prompting (Qwen3-1.7B y Qwen3.5-4B) contra las políticas entrenadas con RLVR utilizando los mismos comprobadores de recompensa.
Receta de Entrenamiento: Una receta de entrenamiento de GRPO de extremo a extremo que logra la convergencia en decenas o pocos cientos de lotes de generación en modelos pequeños.

Resultados
El estudio evalúa el rendimiento en cinco escenarios, señalando que el escenario de "transición de ticket" es un control de transparencia donde la función de recompensa se satura (el modelo 4B con prompting ya alcanza una puntuación perfecta).

Ganancias de Rendimiento: En los cuatro escenarios no degenerados, la política entrenada con RL supera significativamente a las líneas base de prompting.
- Creación de Páginas de Confluence: La mejora más drástica, subiendo de una línea base de 0.35 a 1.00 (+0.65).
- Etiquetado de Páginas de Confluence: Mejoró de 0.52 a 0.95 (+0.43).
- Creación de Subtareas de Jira: Mejoró de 0.68 a 1.00 (+0.32).
- Producto Cruzado (Jira + Confluence): Mejoró de 0.92 a 1.00, cerrando la brecha residual para lograr un éxito de ejecución perfecto en los 12 prompts de evaluación.
Dinámicas de Entrenamiento: Los modelos alcanzaron una recompensa promedio de $\ge 0.95$ dentro de los 100 lotes de generación para los escenarios desde cero. La varianza de la recompensa (mínimo/máximo a través del grupo de generación) se contrajo durante el entrenamiento a medida que la política dejó de emitir ejecuciones de baja recompensa.

Significado y Limitaciones
El artículo posiciona este trabajo como una prueba de concepto preliminar que demuestra que los modelos pequeños optimizados por resultados pueden ser entrenados para APIs empresariales de nicho utilizando sustratos sintéticos económicos y recompensas verificables.

Los autores destacan explícitamente dos limitaciones para moderar las expectativas:

Escalabilidad del Diseño de Recompensa: La creación manual de recompensas verificables no escala actualmente a la totalidad de la API pública de Atlassian o a ecosistemas empresariales más amplios; es efectivo solo para el pequeño grupo de endpoints reportados.
Saturación de la Recompensa: Un escenario (transición de ticket) posee una forma de recompensa demasiado simple, lo que permite que el modelo 4B con prompting alcance el máximo de inmediato, haciendo que el RL sea innecesario para esa tarea específica.

Los autores concluyen que, si bien la receta funciona en este sustrato específico, aún no establece una solución generalizable para todas las tareas de uso de herramientas empresariales sin un significativo diseño manual de recompensas.