AWS ajusta agente de busca com RL multiturno no SageMaker

AWS ajusta agente de busca com RL multiturno no SageMaker

A Amazon Web Services (AWS) publicou em 2 de outubro de 2026 um artigo técnico que mostra como ajustar um agente de busca baseado em modelos de linguagem de grande porte (LLMs) por meio de aprendizado por reforço multiturno (MTRL) no Amazon SageMaker AI. A ideia central é treinar um modelo menor para que ele aprenda as ferramentas e o ambiente da empresa, em vez de depender das capacidades de um modelo de fronteira.

O gargalo dos agentes de busca

Agentes de busca com LLM vêm mudando a forma como empresas recuperam informação. Em vez de exigir que o usuário formule a consulta perfeita, o agente decide sozinho o que procurar, qual estratégia de recuperação usar e quando parar de buscar, refinando o caminho a cada rodada de interação com base no que já encontrou.

O problema é fazer esse comportamento de vários passos funcionar bem: nenhum modelo-base chega sabendo quais são as suas ferramentas ou como o seu ambiente está organizado. Instruir um modelo pequeno por prompt raramente produz comportamento multiturno confiável; usar um modelo de fronteira costuma funcionar, mas a conta chega em latência e custo.

O ajuste fino aparece como terceiro caminho. Ainda assim, as abordagens tradicionais têm limites claros.

O ajuste fino supervisionado (SFT) depende de demonstrações especialistas de trajetórias ideais de múltiplos turnos, caras de coletar e normalmente inexistentes para configurações específicas de cada empresa. Já o aprendizado por reforço de turno único, como o RL com recompensas verificáveis (RLVR), pontua uma resposta por vez — e um agente de busca toma decisões interdependentes ao longo de muitos turnos, cada uma construída sobre o contexto anterior.

Otimizar um passo isolado ignora essas dependências.

Como o mtrl funciona na prática

O Amazon SageMaker AI MTRL trata a tarefa agentica como uma sequência de decisões, usa rollouts multiturno para gerar dados de treino e otimiza o modelo com algoritmos de policy gradient. O sinal de recompensa só precisa refletir se o resultado final foi bom, o que permite otimizar o agente ao longo de toda a trajetória.

Entre os recursos descritos pela AWS estão uma interface modular entre agente e ambiente, que mantém a integração com pouco código e permite definir recompensas personalizadas, loops de ferramentas e formatos de conversa multiturno; execução serverless com preço por token, sem provisionar ou gerenciar clusters de GPU; rollout assíncrono e coleta de trajetórias em paralelo às atualizações de gradiente, com staleness off-policy limitado; e uma biblioteca nativa de algoritmos com Proximal Policy Optimization (PPO), Clipped Importance Sampling Policy Optimization (CISPO) e perdas de importance sampling (IS), combinadas a estimadores de vantagem baseados em grupo como GRPO, GRPO pass@k e RLOO.

O pacote inclui ainda treinamento retomável, para dividir execuções longas entre vários jobs e ultrapassar limites de tempo de uma única tarefa; observabilidade de trajetória e recompensa no MLflow gerenciado pelo Amazon SageMaker AI, permitindo inspecionar turno a turno o que o agente fez; e jobs de avaliação capazes de reportar métricas de recompensa, pass@k e trajetória antes da implantação em um endpoint do SageMaker AI ou no Amazon Bedrock.

O experimento com qwen3.6-27b, bm25 e busca vetorial

O cenário descrito no artigo usa o MTRL para ajustar o modelo Qwen3.6-27B, disponível na região US West (Oregon), us-west-2. O ambiente exige uma conta AWS com acesso ao Amazon SageMaker AI nessa região, datasets de treino e validação carregados no Amazon Simple Storage Service (Amazon S3) no formato requerido, um endpoint de agente implantado que exponha ferramentas de busca BM25 e busca vetorial, chamadas pelo ambiente MTRL durante os rollouts, e familiaridade com o SageMaker AI e com Python.

A escolha do caso de uso não é acidental: um agente de busca reúne as três condições que tornam o MTRL adequado, segundo a AWS. Há um sinal de recompensa claro (a qualidade da recuperação), um loop de interação multiturno no qual o agente dispara consultas e recebe resultados, e um ambiente bem definido, formado pelas ferramentas de busca.

Por que isso importa

Se o treinamento funciona como proposto, o ganho é direto para quem opera agentes em produção: a velocidade e o custo de um modelo pequeno, com a confiabilidade que normalmente exigiria um modelo de fronteira. Como se trata de um modelo especializado e menor, a inferência tende a ser mais rápida e mais barata, e o comportamento específico do ambiente fica embutido no próprio modelo, com mais controle sobre a qualidade da saída.

O artigo afirma que a AWS mediu ganhos em qualidade de recuperação e confiabilidade com essa abordagem, embora os detalhes numéricos dependam do ambiente de cada empresa. A combinação de avaliação estruturada antes do deploy, observabilidade das trajetórias e possibilidade de retomar treinamentos longos aponta para um esforço maior de transformar RL multiturno em uma etapa de produção, e não apenas em um experimento de pesquisa.

Fontes e links

Matéria publicada originalmente em AWS

Últimas Notícias

Capcom planeja criar jogos 'junto com a IA' na RE Engine
Amazon para de usar NDAs em data centers após críticas, diz AWS
Instinct, Caddy, Fambot e Folk: agentes de IA por mensagem
Ex-funcionário de segurança da OpenAI renuncia e faz alerta