O problema com agentes de busca baseados em LLMs
Agentes de busca alimentados por grandes modelos de linguagem (LLMs) estão mudando a forma como empresas recuperam informações. Em vez de exigir que o usuário formule a consulta perfeita, esses agentes decidem autonomamente o que buscar, qual estratégia de recuperação usar e quando parar — tudo isso ao longo de múltiplas rodadas de interação, refinando a abordagem com base no que já foi recuperado.
O problema é que fazer esse comportamento multi-etapas funcionar de forma confiável não é trivial. Nenhum modelo base chega pronto conhecendo as suas ferramentas ou o seu ambiente. Modelos menores raramente entregam comportamento multi-turn consistente. Modelos de fronteira funcionam, mas cobram caro em latência e custo.
O fine-tuning surge como um terceiro caminho: você ensina diretamente a um modelo menor as ferramentas e o ambiente específicos do seu caso de uso. O resultado é a velocidade e o custo de um modelo menor com a confiabilidade que, de outra forma, só um modelo de fronteira entregaria.
As abordagens tradicionais de fine-tuning, porém, têm limitações claras. O Ajuste Fino Supervisionado (SFT) depende de demonstrações de especialistas com trajetórias multi-turn ideais — caras de coletar e raramente disponíveis. O Aprendizado por Reforço (RL) de turno único, como o RL com recompensas verificáveis (RLVR), avalia uma resposta de cada vez. Mas um agente de busca toma decisões interdependentes ao longo de vários turnos, e otimizar um único passo de forma isolada ignora completamente essas dependências.
O que se precisa é de uma abordagem que otimize o agente ao longo de toda a trajetória multi-turn. O sinal de recompensa só precisa refletir se o resultado final foi bom. É exatamente isso que o Aprendizado por Reforço Multi-turn (MTRL) oferece.
O que é o Amazon SageMaker AI MTRL
O Amazon SageMaker AI MTRL permite fazer fine-tuning de LLMs usando aprendizado por reforço em cenários de interação multi-turn. Ele enquadra uma tarefa agêntica como uma sequência de decisões, usa rollouts multi-turn para gerar dados de treinamento e otimiza o modelo com algoritmos de gradiente de política.
Entre os principais recursos que a AWS destaca para o serviço:
- Interface modular agente-ambiente: você define recompensas personalizadas, loops de ferramentas e formatos de conversa multi-turn com pouco código.
- Execução serverless: RL agêntico em escala de produção com precificação por token, sem necessidade de provisionar ou gerenciar clusters de GPU.
- Rollout assíncrono e coleta de trajetórias: geração e atualizações de gradiente rodam em paralelo com controle de desatualização off-policy, mantendo o treinamento rápido sem se afastar demais da política atual.
- Biblioteca nativa de algoritmos: suporte a Otimização de Política Proximal (PPO), Otimização de Política por Amostragem de Importância Recortada (CISPO) e perdas de amostragem de importância (IS), combinadas com estimadores de vantagem baseados em grupos (GRPO, GRPO pass@k, RLOO e outros).
- Treinamento retomável: execuções longas podem ser divididas em múltiplos jobs, superando o limite de tempo de um único job.
- Observabilidade de trajetórias e recompensas: é possível inspecionar o que o agente fez turno a turno e ao longo dos passos de treinamento no MLflow gerenciado pelo Amazon SageMaker AI.
- Jobs de avaliação: métricas de recompensa, pass@k e trajetórias podem ser verificadas antes do deploy em um endpoint do Amazon SageMaker AI ou no Amazon Bedrock.
Ambiente e configuração do experimento
O experimento descrito pela AWS utilizou os seguintes componentes:
- Uma conta AWS com acesso ao Amazon SageMaker AI na região US West (Oregon) —
us-west-2. - Datasets de treinamento e validação enviados ao Amazon Simple Storage Service (Amazon S3) no formato exigido pelo serviço.
- Um endpoint de agente implantado que expõe ferramentas de busca BM25 e vetorial para o ambiente MTRL chamar durante os rollouts.
O modelo escolhido para o fine-tuning foi o Qwen3.6-27B, suportado na região us-west-2. O agente de busca foi configurado com duas ferramentas disponíveis:
- Busca lexical (BM25): encontra correspondências exatas de palavras-chave contando frequências de termos. Ideal para consultas com termos específicos ou identificadores.
- Busca vetorial: converte consultas e documentos em vetores de embedding e calcula similaridades. Recomendada para consultas semânticas ou conceituais.
O número de turnos por interação também foi limitado, evitando respostas excessivamente longas e incentivando um comportamento de busca mais eficiente.
Datasets utilizados
Para treinamento e teste, foram utilizados os seguintes conjuntos de dados públicos:
- FRAMES (treino — HuggingFace): perguntas factuais multi-hop que exigem síntese de múltiplos artigos da Wikipedia.
- BRIGHT (treino — HuggingFace): recuperação intensiva em raciocínio em 12 domínios, onde a relevância exige raciocínio e não apenas sobreposição de palavras-chave.
- Enterprise RAG (treino — GitHub): benchmark com mais de 500.000 documentos corporativos sintéticos e 500 perguntas para treinar e avaliar sistemas de Geração Aumentada por Recuperação (RAG) em conhecimento interno de empresas.
- ESCI (treino — GitHub): dataset multilíngue de busca de produtos que rotula pares consulta–produto como Exato, Substituto, Complementar ou Irrelevante.
- Musique (treino — GitHub): dataset de perguntas e respostas construído compondo questões de um único salto em problemas desafiadores de raciocínio multi-hop.
- MLQA (treino — HuggingFace): benchmark de perguntas e respostas extrativas paralelo em sete idiomas para avaliar compreensão entre línguas.
- FreshStack (teste — HuggingFace): perguntas e respostas recentes de desenvolvedores sobre Stack Overflow e documentações em cinco tópicos.
- WixQA (teste — HuggingFace): perguntas e respostas de suporte sobre a base de conhecimento da Wix.
- BrowseComp-Plus (teste — GitHub): consultas de pesquisa profunda sobre aproximadamente 100.000 documentos da web verificados por humanos.
- Wands (teste — HuggingFace): dataset de busca de produtos da Wayfair com mais de 42.000 julgamentos de relevância rotulados como Exato, Parcial ou Irrelevante.
Os datasets foram pré-processados no formato reconhecido pelo serviço MTRL conforme a documentação oficial. Além disso, 5% das instâncias de treinamento de cada dataset foram reservadas para validação.
Função de recompensa
A métrica principal utilizada foi o nDCG@10 (Ganho Cumulativo Descontado Normalizado no rank 10). Trata-se de uma métrica padrão de recuperação de informações que mede o quão bem os 10 documentos recuperados correspondem ao ranking ideal. Ela recompensa sistemas que colocam documentos altamente relevantes no topo da lista — pontuação 1.0 significa ranking perfeito, 0.0 significa nenhum documento relevante recuperado.
O nDCG@10 foi usado diretamente como função de recompensa no MTRL. É uma recompensa no nível da trajetória: o agente conclui toda a sua busca multi-turn e a recompensa reflete o quão bem os documentos finais recuperados correspondem ao gabarito.
Quando o agente atinge o número máximo de turnos ou o limite de tokens de amostragem em um único turno, é atribuída uma recompensa de -1 para ensinar explicitamente o modelo a evitar esses modos de falha. Esse tipo de design de recompensa baseado em penalidade é eficaz para afastar o modelo de comportamentos indesejados sem precisar criar recompensas intermediárias complexas.
Configuração do job de treinamento
Um dos pontos destacados pela AWS é o baixo esforço de configuração necessário para começar. No experimento, apenas três hiperparâmetros foram alterados — todo o restante ficou nos valores padrão. O trecho de código abaixo mostra como configurar e iniciar o job de treinamento usando o SDK MultiTurnRLTrainer:
from sagemaker.modules.train import MultiTurnRLTrainer
trainer = MultiTurnRLTrainer(
model_id="qwen3.6-27b",
agent_endpoint="<your-agent-endpoint>",
training_dataset_s3_uri="s3://amzn-s3-demo-bucket/datasets/train/",
validation_dataset_s3_uri="s3://amzn-s3-demo-bucket/datasets/validation/",
hyperparameters={
"max_epochs": 1,
"global_batch_size": 128,
"rollout_max_concurrency": 32,
},
output_s3_uri="s3://amzn-s3-demo-bucket/output/",
)
trainer.train()Os três hiperparâmetros modificados foram:
max_epochs: 1— controla quantas passagens completas sobre os dados de treinamento são realizadas.global_batch_size: 128— define o número de prompts por passo de treinamento.rollout_max_concurrency: 32— controla quantos rollouts rodam em paralelo durante a coleta de trajetórias.
Decisões que normalmente exigem expertise em RL — como o algoritmo, o estimador de vantagem e os limites de desatualização off-policy — rodam com os valores padrão. Toda a jornada do modelo base até os resultados descritos a seguir exigiu apenas essa configuração.
Vale mencionar que o treinamento MTRL pode durar vários dias e o serviço tem um limite de tempo padrão de 24 horas, ajustável pelo esquema JSON do CreateJob. Caso um job seja interrompido ou falhe por timeout ou erro de infraestrutura, é possível retomar o treinamento a partir de um checkpoint anterior com o suporte a retomada.
Resultados obtidos
O fine-tuning com MTRL melhorou o agente de busca em três dos quatro benchmarks de teste e o tornou substancialmente mais confiável em todos eles. Os maiores ganhos vieram no BrowseComp-Plus (+23,7% de nDCG@10) e no WixQA (+18,4%), com ganho menor no Wands e uma leve regressão no FreshStack.
A melhoria na confiabilidade foi o resultado mais expressivo. No BrowseComp-Plus, a taxa de falhas caiu de 22,89% para 0,68%. Isso significa que o agente aprendeu não apenas a buscar melhor, mas também a concluir a tarefa dentro do orçamento de turnos e tokens.
A tabela abaixo compara o modelo fine-tuned com o Qwen3.6-27B original nos quatro datasets de teste. As colunas são: tamanho do dataset (número de perguntas), nDCG@10 (o Ganho Cumulativo Descontado Normalizado — tarefas com falha recebem nDCG@10 igual a 0), taxa de falhas (percentual de perguntas onde o agente excede o limite de turnos ou tokens) e média de turnos por pergunta.
- WixQA (400 perguntas): Qwen3.6-27B → 0,5725 | Qwen3.6-27B-finetune → 0,6781 (+18,4%) | Falhas: 0,67% → 0,17% | Turnos médios: 4,3 → 4,5
- Wands (147 perguntas): Qwen3.6-27B → 0,5762 | Qwen3.6-27B-finetune → 0,6112 (+6%) | Falhas: 0,00% → 0,00% | Turnos médios: 2,2 → 2,9
- FreshStack (672 perguntas): Qwen3.6-27B → 0,4112 | Qwen3.6-27B-finetune → 0,4089 (-0,6%) | Falhas: 0,20% → 0,05% | Turnos médios: 3,1 → 2,8
- BrowseComp-Plus (830 perguntas): Qwen3.6-27B → 0,5136 | Qwen3.6-27B-finetune → 0,6354 (+23,7%) | Falhas: 22,89% → 0,68% | Turnos médios: 7,0 → 6,3
Dois padrões se destacam nos dados: a melhora na qualidade de busca foi consistente na maioria dos benchmarks, e a redução de falhas foi dramática — especialmente no BrowseComp-Plus, que é o benchmark mais desafiador do conjunto.
Principais aprendizados
Com base nos resultados apresentados, a AWS destaca os seguintes pontos sobre o Amazon SageMaker AI MTRL:
- Baixa barreira de entrada: as configurações padrão funcionam bem e não é necessária expertise profunda em RL para começar.
- Infraestrutura serverless: sem necessidade de provisionar GPUs ou gerenciar clusters de treinamento distribuído — o modelo de cobrança é por token.
- Treinamento retomável: execuções longas podem ser divididas em múltiplos jobs.
- Otimização direta: o treinamento ocorre contra a métrica real da tarefa, não contra perdas proxy.
- Observabilidade completa: é possível inspecionar trajetórias turno a turno no MLflow gerenciado pelo Amazon SageMaker AI para entender o que o agente aprendeu.
Próximos passos
Para quem quiser explorar essa abordagem, a AWS indica os seguintes pontos de partida:
- Consultar a documentação do Amazon SageMaker AI MTRL.
- Preparar o dataset no formato exigido pelo serviço.
- Definir o agente e a função de recompensa com base na métrica específica da sua tarefa.
- Começar com as configurações padrão, que funcionaram bem no experimento descrito.
- Avaliar e iterar.
Após explorar a abordagem, lembre-se de limpar os recursos para evitar cobranças contínuas: interromper ou excluir o job de treinamento MTRL no console do Amazon SageMaker AI, remover os artefatos do modelo no Amazon S3 se não forem mais necessários e excluir os endpoints implantados para avaliação.
Fonte
Fine-tune a search agent with multi-turn RL on Amazon SageMaker AI (https://aws.amazon.com/blogs/machine-learning/fine-tune-a-search-agent-with-multi-turn-rl-on-amazon-sagemaker-ai/)
Leave a Reply