ServiceNow transforma falhas de agentes em dados de treinamento

Toda equipe que já implantou um agente de IA em um sistema empresarial real conhece a mesma dor. O modelo é amplamente capaz e, então, encontra suas ferramentas específicas, suas políticas específicas, sua bagunça particular de máquina de estados, e tropeça.

O braço de pesquisa da ServiceNow, o CoreAI, lançou um sistema que tenta transformar esses tropeços em um ativo. Ele se chama AutoSynthData, e sua premissa é que as falhas de um modelo são a matéria-prima mais valiosa que você tem para treiná-lo.

O movimento central

O pipeline começa executando um modelo-alvo e um modelo professor mais forte nas mesmas tarefas de diagnóstico em um ambiente real. Onde o modelo-alvo falha e o professor tem sucesso, há uma lacuna de capacidade. O AutoSynthData destila essa lacuna no que a equipe chama de cartões de especificação de capacidade: descrições sanitizadas das ferramentas, fluxos de trabalho, estados finais e variações permitidas envolvidas, despojadas dos prompts de avaliação originais e dos detalhes das entidades.

Esses cartões semeiam a geração de novas tarefas. Crucialmente, o gerador nunca vê as trajetórias de avaliação originais, então os dados resultantes testam a competência subjacente em vez de sequências memorizadas. O framework escala isso em duas fases. Uma fase-alvo cria tarefas centrais em paralelo. Uma fase de multiplicação pega as tarefas verificadas e gera variantes com novos enunciados, novas configurações de entidades e novos estados iniciais. Uma regra impede que os dados se desviem: uma amostra multiplicada nunca pode semear outra multiplicação.

Três condições para uma tarefa que vale a pena gerar

A ServiceNow deixa claro que uma solicitação que parece plausível não basta. Uma tarefa gerada precisa satisfazer três coisas ao mesmo tempo.

Ela precisa ser viável, ou seja, deve existir pelo menos um caminho executável pelo ambiente que conclua a solicitação respeitando as regras. Precisa ser realista, ou seja, espelhar um trabalho que um usuário real realmente pediria, em vez de uma ação tecnicamente válida que ninguém tomaria. E precisa ser difícil, ou seja, mirar uma fraqueza genuína. Uma tarefa trivial não ensina nada, e uma impossível ensina a lição errada.

Cada tarefa vem com um verificador, e o verificador precisa atender ao seu próprio padrão. Ele deve ser consistente com o prompt e o estado do sistema, sólido o suficiente para rejeitar violações de restrições e completo o suficiente para aceitar qualquer solução funcional, em vez de insistir em um único caminho de referência.

Os portões de qualidade são o verdadeiro produto

A parte disso que merece atenção não é a geração de tarefas. É a verificação.

Todo candidato passa por dois portões. Um portão positivo executa a solução de referência dentro do ambiente para confirmar que a resposta pretendida realmente satisfaz o verificador, o que captura incompatibilidades entre o prompt, o estado inicial e os critérios de sucesso. Um portão negativo então modifica deliberadamente o estado final para confirmar que resultados errados são realmente rejeitados. Esse segundo portão é o que captura verificadores subespecificados, do tipo que recompensaria alegremente uma trajetória de agente malformada.

Quando um candidato falha, um crítico diagnostica a falha, identificando referências quebradas ou estados contraditórios, e direciona um reparo limitado em vez de descartar o trabalho de imediato. Acima do nível da amostra, uma revisão de lote observa o agregado: quais clusters de tarefas estão sobrerrepresentados, quais dimensões estão faltando, quais padrões de geração continuam travando. O controlador então direciona o próximo lote para as lacunas que permanecem.

Por que alguém precisa de dados sintéticos, afinal

Vale a pena dar um passo atrás e perguntar por que isso importa. Os dados de treinamento ideais para um agente empresarial são um registro de pessoas reais fazendo trabalho real no sistema real, com rótulos corretos. Esses dados são escassos, sensíveis e caros de coletar, e grande parte deles não pode sair da empresa por questões de privacidade ou conformidade.

A geração sintética é a válvula de escape, mas vem com um modo de falha conhecido. Se você gera tarefas a partir de um modelo, herda os pontos cegos desse modelo, e os dados resultantes podem parecer abundantes enquanto ensinam muito pouco. A contribuição inteira do AutoSynthData é a maquinaria em torno da geração que mantém os dados honestos: portões que rejeitam tarefas ruins, verificações de diversidade que evitam repetição e um currículo que continua mirando no que o agente ainda não dominou. Geração sem verificação é ruído. Esta é uma tentativa de transformá-la em sinal.

O que os números dizem, e o que não dizem

Em testes no EnterpriseOps Gym, um ambiente de código aberto para tarefas de agentes empresariais, um modelo baseado em Gemma ajustado com 2.000 amostras do AutoSynthData melhorou sua métrica Pass@1 em 35% em relação à linha de base em um domínio híbrido. No domínio ITSM, o ajuste fino supervisionado sintético elevou o Pass@1 médio de 18,77% para 27,18%.

Esses são ganhos reais em um benchmark específico, o que não é o mesmo que um resultado geral. A dependência central do pipeline é honesta e vale declarar claramente: ele precisa de um modelo professor significativamente mais forte para demonstrar comportamento correto, e de um ambiente de simulação preciso para testar. Em uma empresa sem um sandbox de alta fidelidade e verificadores determinísticos confiáveis, construir a camada de execução é, por si só, um sério projeto de engenharia. O AutoSynthData não elimina esse trabalho. Ele muda o propósito do trabalho.

A armadilha do modelo professor

Há uma dependência neste design que merece uma frase própria. Todo o pipeline funciona na lacuna entre um modelo fraco e um forte. Nos experimentos, o professor era um modelo muito maior que o alvo. Isso funciona quando você tem um sistema de fronteira para tomar emprestado. Funciona menos bem quando você é a fronteira, ou quando a tarefa é tão especializada que não existe um modelo mais forte para demonstrá-la. Nesse caso, o pipeline não tem de onde aprender, e a lacuna de capacidade da qual ele depende é simplesmente um muro. A pesquisa sobre geração de dados de treinamento sempre esbarra nisso eventualmente: o método escala desde que alguém, em algum lugar, já tenha resolvido o problema.

Por que este é o formato da IA empresarial

O interessante neste lançamento é o que ele admite sobre onde a IA empresarial realmente está. O gargalo não é mais obter um modelo capaz. O gargalo é fazer um modelo capaz operar corretamente dentro de uma organização específica, com suas ferramentas e regras particulares, onde as falhas são sutis e o espaço de estados é grande.

Durante anos, a resposta foi a anotação manual, que é lenta, cara e difícil de escalar. O AutoSynthData é um argumento de que as próprias falhas contêm o sinal, se você conseguir extraí-las, verificá-las e diversificá-las sem vazar o conjunto de avaliação. O pipeline está disponível para pesquisa no Hugging Face, e a equipe diz que o aprendizado por reforço usando a mesma metodologia é o próximo passo.

Se funcionar de forma ampla, a implicação é que a habilidade escassa em IA empresarial muda. Deixa de ser sobre adquirir dados e passa a ser sobre construir ambientes bons o suficiente para gerar dados confiáveis dentro deles. Esse é um problema mais difícil, e mais duradouro, porque o ambiente de uma empresa é aquilo que nenhum concorrente consegue copiar.