A Salesforce apresentou em 11 de novembro de 2026 o SFR-AutoR&D, um sistema de agentes que formula hipóteses, altera código, treina modelos e retém uma melhoria somente quando ela supera uma linha de base em avaliações controladas. Em um ciclo de cerca de 80 horas, a empresa relata ganho de 6,13 pontos em nDCG@10 para dez tarefas públicas de recuperação. Em outra sessão, relata 36 por cento mais throughput e 17 por cento menos latência, com perda mínima de qualidade. O caso mostra potencial, mas também reforça que metas, dados, orçamento, testes isolados e aprovação de produção continuam humanos.
Entenda o que foi automatizado
O SFR-AutoR&D combina dois agentes. AutoR&D-Engineer procura melhorias algorítmicas e de sistemas em código existente. TrainForge explora métodos de treinamento, executa experimentos e avalia candidatos em benchmarks reservados. A infraestrutura AutoInfra distribui as execuções em capacidade compartilhada de GPU.
A automação cobre o ciclo experimental, não a definição ilimitada do que vale a pena pesquisar. Pesquisadores estabelecem objetivo, orçamento de computação, avaliações, dados permitidos e requisitos de segurança. Sem ganho verificado sobre a linha de base, a mudança não é mantida.
Escolha um problema com métrica verificável
Um piloto precisa de uma função objetiva que represente valor técnico real. Para busca e RAG, podem entrar precisão, recall, nDCG e latência. Para código, testes corretos, consumo de memória, tempo de execução e compatibilidade. Uma meta única pode produzir uma solução rápida e barata que perde qualidade ou segurança.
Crie uma matriz de aceite com métricas obrigatórias e limites que não podem piorar. Separe benchmark de desenvolvimento de um conjunto final reservado. O agente não deve treinar, ajustar prompts ou selecionar casos com base nas mesmas amostras usadas para aprovar a entrega.
- Linha de base reproduzível
- Conjunto de validação separado
- Métrica principal e limites de segurança
- Orçamento de tempo e computação
- Critério explícito para rejeitar a mudança
Controle dados, código e ambiente
Cada execução deve partir de um commit, ambiente e conjunto de dados identificados. O agente trabalha em branch ou sandbox isolada, sem acesso direto à produção. Dependências, imagens de container, sementes aleatórias e configurações precisam ser registradas para que outra equipe repita o resultado.
Use apenas dados com origem, licença, finalidade e revisão adequadas. A Salesforce afirma que modelos destinados a produto usam conjuntos aprovados em análises éticas e jurídicas. Esse controle não pode ser inferido do uso de um agente: a empresa precisa aplicá-lo à própria base, inclusive a dados pessoais, confidenciais e sintéticos.
Exija evidência para cada melhoria
O relatório do agente deve mostrar hipótese, alteração, configuração, resultado por tarefa, variância, custo e motivo da seleção. Um valor agregado pode esconder regressão em idioma, segmento ou caso raro. Revise cortes relevantes para o uso real antes de aceitar a média.
Repita os melhores experimentos em uma execução limpa e compare com a linha de base sob as mesmas condições. Teste significância quando aplicável e procure vazamento de dados, tuning excessivo e benchmark contaminado. Resultado não reproduzível é uma pista, não uma melhoria pronta para produção.
Separe descoberta de promoção para produção
O agente pode abrir uma proposta de mudança com artefatos e evidências, mas não deve promover sozinho um modelo ou biblioteca usada por clientes. Exija revisão de engenharia, pesquisa, segurança e área responsável. Faça canário, shadow test ou rollout limitado com opção de reversão.
Defina quem pode aprovar alterações em dados, arquitetura, métrica e orçamento. Mudanças que melhoram latência podem afetar explicabilidade ou cobertura; mudanças de treinamento podem ampliar risco jurídico. A aprovação precisa considerar o sistema completo, não apenas o benchmark escolhido pelo agente.
Leia os resultados sem generalizar
Os números divulgados vêm de experimentos da Salesforce em modelos e tarefas específicos. O ganho de 6,13 pontos em nDCG@10 se refere a dez tarefas públicas de recuperação. Os ganhos de throughput e latência vieram de uma segunda sessão de aproximadamente nove horas. Eles não prometem o mesmo efeito em outro modelo, hardware, idioma ou conjunto de dados.
A publicação é uma fonte primária do fornecedor e não substitui reprodução independente. Use os resultados para formular uma hipótese de piloto. Compare com uma equipe humana, inclua o custo total de GPU e revisão e registre tentativas sem sucesso. Selecionar apenas o melhor experimento superestima o retorno esperado.
Meça produtividade científica e risco
Acompanhe tempo até uma melhoria reproduzível, experimentos úteis, custo por candidato, horas de revisão, regressões encontradas e mudanças que chegaram com segurança à produção. Contar apenas experimentos ou commits favorece volume sem aprendizado. O objetivo é aumentar evidência confiável por unidade de tempo e custo.
Comece com um código aberto ou componente interno reversível, sem dados sensíveis e com testes maduros. Estabeleça teto de gasto, interrupção automática e revisão dos artefatos. Só amplie quando os ganhos sobreviverem à reprodução, ao teste de produção e à comparação com o processo atual.
Para levar daqui
Agentes autônomos de P&D são úteis quando exploram dentro de limites definidos e entregam evidência reproduzível. Meta, dados, orçamento, benchmark reservado e promoção para produção continuam sob governança humana.
