Perplexity treina seu modelo de uso de computador com dados do mundo real

A tese: aprender no nível da decisão, não da sessão

A Perplexity detalha como treina um modelo de uso de computador (o Perplexity Computer) com dados de sessões reais de usuários, em vez de depender apenas de ambientes sintéticos. A motivação: dados reais refletem a distribuição real de tarefas e trazem dois sinais que ambientes controlados não capturam - correções de usuários, que apontam requisitos que o modelo deixou de atender, e erros de ferramenta, que mostram onde as ações quebraram em ambientes reais.

O problema do rejection sampling tradicional

A abordagem comum, o rejection sampling fine-tuning (RFT), julga o resultado final de cada sessão e treina o modelo a imitar as bem-sucedidas. Isso tem duas falhas: uma sessão bem-sucedida pode conter passos intermediários errados (imitar tudo reforça também os erros), e descartar sessões mal-sucedidas joga fora evidências valiosas de onde o modelo falha.

Imitar o que é bom, corrigir o que é ruim

A Perplexity combina RFT com uma técnica de destilação própria guiada por dicas (hint-guided self-distillation). Cada turno do modelo recebe um de três tratamentos:

• Imitar: turnos sem erro em sessões bem-sucedidas recebem perda de cross-entropy (CE), como no RFT padrão.
• Corrigir: turnos com erro marcado, em sessões bem ou mal-sucedidas, recebem perda de divergência KL, aproximando o modelo das predições que ele mesmo faz quando recebe uma dica curta explicando o erro evitável.
• Contexto: turnos de sessões mal-sucedidas sem dica validada não recebem perda, mas ficam disponíveis como contexto.

A dica é uma instrução corretiva curta, fundamentada em informações que o modelo já tinha quando errou - como a documentação do esquema de uma ferramenta. No mecanismo de On-Policy Self-Distillation (OPSD), o mesmo checkpoint de GLM 5.2 serve de professor (com acesso à dica) e aluno (sem a dica), e o aluno aprende a reproduzir as predições do professor. O termo CE é mantido junto porque a correção sozinha pode gerar um atalho degenerado: professor e aluno concordarem ignorando o contexto.

O pipeline de quatro etapas

O fluxo seleciona sessões elegíveis do Computer (respeitando opt-outs e exclusão de PII), filtra por dificuldade avaliada por um juiz LLM e separa dois grupos: feedback de usuário (correções genuínas ou insatisfação) e erros de ferramenta (falhas detectadas por regras, excluindo problemas de infraestrutura). Dois juízes LLM rotulam o resultado final. Na anotação, três juízes identificam os turnos responsáveis pelo erro - com a descoberta de que a última resposta antes da reclamação é a causa raiz apenas cerca de metade das vezes - e verificam se a correção decorre de informação disponível antes do erro, para reduzir viés de retrospectiva. Exemplos: o usuário que pediu "w3" no Paychex e o modelo interpretou como W-2; e uma chamada de busca com recency_filter: "year" quando só "day", "week" ou "month" são válidos.

O que as avaliações mostram

A validação das dicas (antes do treinamento) mostra que elas funcionam: em 985 turnos de erros de ferramenta mantidos fora do treino, a taxa de evitar a falha subiu de 75,1% para 93,7% com dica, e a ação corrigida subiu de 60,6% para 82,3%.

Após o treinamento, a avaliação offline (BrowseComp, Finch, WideSearch, DRACO, DSQA, SpreadsheetBench, HLE e um conjunto de tarefas do Computer) registrou taxa de erro de ferramenta de 2,79% para o GLM 5.2 puro, 1,35% para um checkpoint só com RFT e 0,87% para RFT mais OPSD - embora os checkpoints tenham sido treinados com dados diferentes, o que impede uma ablação controlada, e os resultados por tarefa tenham sido mistos.

Nos testes A/B ao vivo, cada um com cerca de cem mil usuários por condição, um checkpoint inicial teve queda não significativa versus o modelo puro (2,82% contra 2,94%). Na comparação entre dois checkpoints RFT+OPSD, as falhas de chamadas caíram de 2,24% para 1,77% - redução relativa de 21,2%, estatisticamente significativa. Já a insatisfação forte dos usuários não teve diferença significativa (2,58% contra 2,54%).

Limites reconhecidos

Os próprios autores apontam que os juízes podem errar, que corrigir um turno não garante o sucesso da tarefa e que a evidência mais forte é de confiabilidade de ferramentas - os testes online não estabeleceram redução de insatisfação. O objetivo declarado não é apenas um agente que se recupera após uma correção, mas um agente que precise de correções com menos frequência.