🤖 AI

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

Este artigo apresenta uma prova de conceito demonstrando que o Aprendizado por Reforço com Recompensas Verificáveis (RLVR) melhora significativamente a capacidade de pequenos modelos de linguagem de executar chamadas de ferramentas complexas e de múltiplas etapas em ambientes sintéticos da Atlassian (Jira e Confluence), alcançando taxas de sucesso próximas da perfeição na maioria dos cenários sem depender de APIs ao vivo ou de feedback humano.

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

Publicado 2026-07-03

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

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

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você tem um bibliotecário muito inteligente e culto (a IA) que é ótimo em prever a próxima palavra de uma frase. Se você perguntar "O céu é...", ele dirá confiantemente "azul". Mas se você pedir para ele realmente fazer algo em um sistema de escritório complexo — como "Criar um novo ticket de projeto e vinculá-lo a uma página específica" — ele frequentemente tropeça. Ele pode saber as palavras para dizer, mas erra os detalhes, como colocar o número de ID errado na caixa errada ou esquecer de verificar se a caixa existe primeiro.

Este artigo trata de ensinar esse bibliotecário a realmente fazer o trabalho, não apenas falar sobre ele, usando um método de treinamento específico chamado RLVR (Aprendizado por Reforço com Recompensas Verificáveis).

Aqui está a divisão do experimento deles em termos cotidianos:

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

Grandes Modelos de Linguagem (LLMs) são treinados para serem como pilotos automáticos que preveem a próxima palavra. Eles são excelentes em escrever histórias ou e-mails. Mas, em um escritório corporativo (especificamente usando ferramentas da Atlassian como Jira e Confluence), o sucesso não é sobre escrever uma frase bonita; é sobre apertar os botões exatos na ordem exata com os dados exatos.

O Jeito Antigo: Você pede à IA para "Criar uma subtarefa". A IA pode dizer: "Ok, vou criar uma subtarefa", mas ela esquece de atribuí-la a uma pessoa ou usa o código do projeto errado. Ela parece fluente, mas a tarefa falha.
O Objetivo: Os autores queriam ver se poderiam treinar a IA para parar de apenas "adivinhar a próxima palavra" e começar a "agir como um piloto" que verifica os instrumentos antes de voar.

2. A Solução: Um Campo de Treinamento de "Videogame"

Em vez de deixar a IA praticar nos servidores reais e vivos da empresa (o que é arriscado e lento), os autores construíram um gêmeo digital perfeito (uma versão de videogame) dos sistemas Jira e Confluence.

O Simulador: Este "jogo" parece e age exatamente como o software real, mas é seguro. Se a IA cometer um erro, nada quebra.
O Árbitro (O Sistema de Recompensa): Este é o ingrediente secreto. Geralmente, você precisa de um humano para avaliar o trabalho da IA. Aqui, eles construíram um árbitro automatizado e rigoroso.
- Se a IA coloca os dados certos na caixa certa? Pontos.
- Se a IA verifica se uma página existe antes de tentar editá-la? Pontos de bônus.
- Se a IA tenta usar uma ferramenta que não existe ou esquece uma etapa obrigatória? Pontos de penalidade.
- Crucialmente: O árbitro não precisa de um humano para olhar a tela. Ele apenas verifica a matemática e o código.

3. O Treinamento: Tentativa e Erro

Eles pegaram duas versões de uma IA (um modelo menor de 1.7B e um modelo maior de 4B) e as deixaram jogar nesse simulador milhares de vezes.

A IA tenta completar uma tarefa (como "Criar uma página").
Ela falha, recebe uma pontuação baixa do árbitro e tenta novamente.
Ela aprende lentamente: "Ah, eu ganhei pontos quando verifiquei a página pai primeiro. Eu perdi pontos quando esqueci o código do projeto."
Isso é Aprendizado por Reforço: A IA aprende recebendo recompensas por bom comportamento e penalidades por mau comportamento.

4. Os Resultados: De "Ok" para "Perfeito"

Eles testaram a IA antes e depois deste treinamento em cinco tarefas de escritório diferentes.

Antes do Treinamento: A IA era decente em tarefas simples, mas terrível em tarefas complexas. Por exemplo, ao criar uma nova página no Confluence, a IA não treinada obtinha apenas cerca de 35% dos pontos. Ela cometia erros pequenos, mas custosos.
Após o Treinamento: A IA treinada tornou-se quase perfeita. Na mesma tarefa de criação de página, ela saltou para 100%.
A Grande Vitória: O treinamento foi mais eficaz nas tarefas mais difíceis (aquelas com mais regras e campos de dados). A IA aprendeu a seguir o padrão rigoroso de "verificar-então-fazer" exigido por esses sistemas.

5. A Ressalva (Limitações)

Os autores são muito honestos sobre o que isso ainda não faz:

Não é mágica para tudo: Eles tiveram que criar manualmente as "regras do árbitro" para essas tarefas específicas. Você não pode simplesmente conectar isso a qualquer software no mundo sem construir um novo árbitro para ele primeiro. É como ter um treinador que é incrível ensinando futebol, mas ainda não aprendeu basquete.
Uma tarefa era fácil demais: Para uma tarefa específica (alterar o status de um ticket), a IA já era perfeita antes do treinamento, então o treinamento não adicionou valor ali.

A Conclusão

Este artigo prova que você pode pegar uma IA padrão, colocá-la em um ambiente de escritório simulado e seguro, e usar um árbitro automatizado e rigoroso para ensiná-la a seguir regras complexas. Isso transforma a IA de um "bot tagarela" que soa bem, mas falha nos detalhes, em um "trabalhador confiável" que realiza o trabalho perfeitamente. No entanto, isso requer a construção de uma "academia de treinamento" personalizada para cada tipo específico de software que você deseja que ela utilize.

Resumo Técnico: Além da Predição do Próximo Token: Uma Prova de Conceito de RLVR para Agentes de Uso de Ferramentas em Fluxos de Trabalho da Atlassian

Problema
Grandes Modelos de Linguagem (LLMs) são fundamentalmente otimizados para a predição do próximo token em textos de escala de internet, um objetivo que não se alinha com os requisitos de fluxos de trabalho de nicho de SaaS empresarial. Nesses ambientes, o sucesso depende da execução de chamadas de API específicas com argumentos aninhados precisos em uma ordem rigorosa. O artigo argumenta que esse descompasso de objetivos se manifesta como "falhas silenciosas" em agentes de uso de ferramentas: ausência de campos obrigatórios, alucinação de ferramentas inexistentes ou terminação prematura após uma única operação de leitura. Enquanto a literatura existente aborda a invocação de ferramentas via ajuste fino supervisionado ou Aprendizado por Reforço (RL) em benchmarks de web aberta ou agentes amplos, há uma falta de foco em fluxos de trabalho empresariais estreitos e densos em esquemas, dominados por padrões de "verificar-então-mutar".

Metodologia
Os autores propõem uma prova de conceito utilizando Aprendizado por Reforço com Recompensas Verificáveis (RLVR) aplicado diretamente dentro de cópias sintéticas e fiéis ao esquema dos ambientes alvo. A abordagem elimina a necessidade de APIs ao vivo, juízes de recompensa aprendidos ou rotulagem humana no ciclo (human-in-the-loop).

Ambientes Sintéticos: A equipe construiu cinco ambientes sintéticos emulando as APIs Jira REST v3 e Confluence v2. Esses ambientes mantêm a fidelidade ao esquema (correspondendo aos contratos públicos), são estatais, mas resetáveis entre os rollouts para evitar poluição, e são totalmente determinísticos.
Funções de Recompensa Verificáveis: Em vez de depender de um modelo de recompensa aprendido, a correção é determinada por verificadores programáticos que inspecionam o rastro da chamada da ferramenta. A função de recompensa ( $R \in [0, 1]$ $R \in [0, 1]$ ) é decomposta em três componentes aditivos:
1. Correção de argumento por argumento (R1): Pequenas constantes concedidas por corresponder aos valores de argumento esperados (ex: chaves de projeto específicas, IDs de pai).
2. Bônus Estruturais (R2): Recompensas por aderir ao padrão validar–mutar–verificar (ex: realizar uma chamada get_* antes de uma chamada create_*).
3. Penalidades (R3): Subtrações por comportamentos destrutivos, como chamadas ausentes, formas de payload inválidas, chamadas duplicadas, nomes de ferramentas alucinados ou excesso de orçamento de chamadas.
Ciclo de Treinamento: Os autores empregam Otimização de Política Relativa de Grupo (GRPO) nos modelos Qwen3-1.7B e Qwen3.5-4B. O ciclo de treinamento envolve a geração de múltiplos rollouts por prompt, pontuando-os contra as funções de recompensa verificáveis e atualizando os parâmetros da política. O treinamento ocorre em hardware modesto (uma ou duas GPUs Nvidia RTX PRO 6000) e utiliza interrupção precoce baseada na convergência da recompensa.

Principais Contribuições

Suíte Atlassian Sintética: Um conjunto de cinco ambientes fiéis ao esquema cobrindo transições de tickets do Jira, criação de subtarefas, criação de páginas do Confluence, rotulagem de páginas e um cenário de produto cruzado.
Design de Recompensa: Um framework para decompor a correção complexa do uso de ferramentas em sinais programáticos verificáveis (correspondência de argumentos, ordenação estrutural e aplicação de penalidades) computáveis inteiramente a partir dos rastros de chamada de ferramenta.
Baseline e Resultados de Treinamento: Uma avaliação abrangente comparando baselines de prompting (Qwen3-1.7B e Qwen3.5-4B) contra políticas treinadas via RLVR usando os mesmos verificadores de recompensa.
Receita de Treinamento: Uma receita de treinamento GRPO de ponta a ponta que alcança convergência em dezenas a poucas centenas de lotes de geração em modelos pequenos.

Resultados
O estudo avalia o desempenho em cinco cenários, observando que o cenário de "transição de ticket" é um controle de transparência onde a função de recompensa satura (o modelo 4B via prompting já atinge uma pontuação perfeita).

Ganhos de Desempenho: Nos quatro cenários não degenerados, a política treinada via RL supera significativamente os baselines de prompting.
- Criação de Página no Confluence: A melhoria mais dramática, subindo de um baseline de 0.35 para 1.00 (+0.65).
- Rotulagem de Página no Confluence: Melhorou de 0.52 para 0.95 (+0.43).
- Criação de Subtarefa no Jira: Melhorou de 0.68 para 1.00 (+0.32).
- Produto Cruzado (Jira + Confluence): Melhorou de 0.92 para 1.00, fechando a lacuna residual para alcançar sucesso perfeito de rollout em todos os 12 prompts de avaliação.
Dinâmica de Treinamento: Os modelos atingiram uma recompensa média de $\ge 0.95$ dentro de 100 lotes de geração para os cenários do zero. A variância da recompensa (mín/máx entre o grupo de geração) contraiu-se durante o treinamento à medida que a política parou de emitir rollouts de baixa recompensa.

Significância e Limitações
O artigo posiciona este trabalho como uma prova de conceito preliminar demonstrando que modelos pequenos otimizados por resultado podem ser treinados para APIs empresariais de nicho usando substratos sintéticos baratos e recompensas verificáveis.

Os autores explicitamente destacam duas limitações para moderar expectativas:

Escalabilidade do Design de Recompensa: A construção manual de recompensas verificáveis não escala atualmente para toda a superfície da API pública da Atlassian ou ecossistemas empresariais mais amplos; é eficaz apenas para a pequena quantidade de endpoints relatados.
Saturação de Recompensa: Um cenário (transição de ticket) possui uma forma de recompensa muito simples, permitindo que o modelo 4B via prompting atinja o máximo imediatamente, tornando o RL desnecessário para essa tarefa específica.

Os autores concluem que, embora a receita funcione neste substrato específico, ela ainda não estabelece uma solução generalizável para todas as tarefas de uso de ferramentas empresariais sem engenharia de recompensa manual significativa.