Aprendizado com a experiência do mundo real

Como os usuários interagem com nossos produtos no mundo real é uma fonte valiosa para o treinamento de modelos. Os dados são abundantes, refletem a distribuição real das tarefas dos usuários e capturam correções de usuários e falhas de ferramentas que os ambientes sintéticos podem perder.

Uma maneira comum de aprender com dados do mundo real é o ajuste fino por amostragem de rejeição: julgar o resultado de cada sessão, manter as bem-sucedidas e treinar o modelo para imitá-las. Mas um resultado bem-sucedido não significa que cada etapa estava correta, portanto, imitar toda a trajetória corre o risco de reforçar maus comportamentos intermediários, além dos bons. Descartar sessões sem sucesso também perde evidências críticas de onde o modelo falha.

Combinamos o ajuste fino por amostragem de rejeição com a autodestilação guiada por dicas para aprender com sessões bem-sucedidas e malsucedidas. Uma dica é uma instrução corretiva curta baseada em informações que o modelo já tinha quando cometeu o erro. As etapas úteis de sessões bem-sucedidas continuam sendo alvos de imitação, enquanto as dicas baseadas em fatos transformam erros evitáveis em alvos de correção.

Correções de usuários e erros de ferramenta adicionam supervisão sobre o que deu errado ao longo do caminho, além de verificar se a tarefa foi bem-sucedida no final. Aplicamos este estágio após o aprendizado por reforço em ambientes sintéticos para ajudar a fechar a lacuna entre esses ambientes e o uso no mundo real.

Em uso real, um ponto de verificação posterior de pós-treinamento do GLM-5.2 reduziu as falhas em chamadas de ferramentas em 21,2% em relação a um ponto de verificação treinado anteriormente. Para o GLM-5.3, o pós-treinamento reduziu as falhas em chamadas de ferramentas em 33,0% e a probabilidade média estimada de insatisfação média ou alta do usuário em 17,2% em relação ao modelo original.

Tarefas sintéticas nos permitem criar problemas controlados com resultados fáceis de verificar, mas normalmente são limitadas a um único prompt e só podem cobrir os cenários que projetamos explicitamente.

Em contraste, os usuários em sessões do mundo real trazem instruções, contexto e combinações de ferramentas diversos para sessões que se desenrolam ao longo de vários turnos de interação. Esse uso no mundo real produz naturalmente dois sinais valiosos de erros: as correções do usuário revelam onde o agente falhou em entregar o que queriam, e os erros de ferramenta mostram onde suas ações falharam em ambientes reais. Nosso pipeline de amostragem respeita a privacidade e as escolhas de treinamento dos usuários ao excluir sessões com informações de identificação pessoal (PII) e de usuários que optaram por não participar.

Os dados do mundo real, portanto, nos fornecem casos de falha que um ambiente sintético pode não expor e frequentemente vêm com o local onde a falha ocorreu já embutido.

Ao treinar com dados do mundo real, o ajuste fino por amostragem de rejeição (RFT) padrão seleciona sessões bem-sucedidas com base em seus resultados finais, sem usar explicitamente o feedback do usuário e de ferramentas para distinguir ações intermediárias boas de ruins. Um agente pode se recuperar de uma chamada de ferramenta incorreta ou corrigir um erro após o feedback do usuário e ainda entregar a saída correta no final.

Descartar sessões com falha também limita a eficiência de amostras. Uma sessão que nunca atinge um bom resultado ainda pode revelar um erro claro e evitável como sinais úteis de treinamento.

Abordamos essas limitações separando duas decisões: quais sessões contêm comportamento que vale a pena imitar e quais turnos contêm erros que vale a pena corrigir. O pipeline de dados toma essas decisões separadamente e, em seguida, atribui aos turnos do modelo um dos três tratamentos:

Imitar: turnos sem erro em sessões bem-sucedidas recebem a perda de entropia cruzada (CE) comum, aumentando a probabilidade dos tokens registrados.
Correto: em sessões bem-sucedidas e sem sucesso, os turnos de erro com uma dica válida recebem uma perda de divergência de Kullback–Leibler (KL), movendo o modelo em direção às previsões do próximo token que ele faz quando vê a dica.
Manter como contexto: turnos em sessões sem sucesso que carecem de uma dica validada, e turnos ruins marcados sem uma dica validada em qualquer tipo de sessão, servem como contexto, mas não recebem nenhuma das perdas.

Como resultado, sessões bem-sucedidas podem fornecer alvos de imitação e correção, enquanto sessões sem sucesso fornecem apenas alvos de correção. Todos os turnos restantes, incluindo saída de sistema, usuário e ferramenta, permanecem como contexto.

Diagrama de roteamento de sessões: sessões bem-sucedidas fornecem imitação por CE e correções com dicas elegíveis; sessões sem sucesso fornecem apenas correções elegíveis. — Roteamento de sessões atual e máscaras de conteúdo do assistente. Sessões bem-sucedidas contribuem com alvos de imitação; registros de feedback retidos podem contribuir com correções com dicas, mesmo quando a sessão não é bem-sucedida. Outro conteúdo permanece como contexto. Sessões incompletas são excluídas. A exceção de CE de rendimento/token de parada não final não é desenhada, e este diagrama não estabelece a mistura usada por um ponto de verificação anterior.

A parte de imitação usa o RFT padrão. A parte corretiva usa On-Policy Self-Distillation (OPSD): o mesmo modelo atua como professor e aluno, com o professor recebendo informações privilegiadas. Aqui, essa informação privilegiada é uma dica curta explicando um erro evitável. Treinamos o aluno para corresponder às previsões do próximo token do professor sem receber a dica.

Ambas as partes importam. O treinamento apenas com correção pode expor um atalho: professor e aluno podem concordar ignorando o contexto em vez de aprender a correção. O termo CE ancora o treinamento a um comportamento útil, ajudando a desestimular a concordância proveniente de ignorar o contexto.

O aluno pós-treinado torna-se então uma opção de modelo no Computer. Novas sessões de uso ao vivo passam pelos mesmos filtros de elegibilidade e privacidade antes de entrar em outra rodada do pipeline de treinamento.

Em seguida, passamos por um exemplo concreto que contém tanto imitação quanto correção.

Considere uma eventual sessão bem-sucedida em que o usuário solicita uma comparação de alterações do asyncio no Python 3.13 usando a documentação oficial. Nossa documentação de ferramentas afirma que search.web retorna uma lista de ocorrências (hits), cada uma com um campo url.

O modelo primeiro executa uma pesquisa válida para uma versão como parte da coleta de evidências para a comparação, o que é um bom comportamento a ser imitado.

No entanto, a próxima chamada de execução de código trata incorretamente essa lista como um dicionário. A ferramenta de código retorna TypeError: list indices must be integers or slices, not str. Como o tipo de retorno foi documentado antes da chamada, é um erro que o modelo deveria ter conseguido evitar. Uma dica com a chamada correta pode ser gerada para corrigir essa ação.

Sessão de programação ilustrativa: entrada de sistema e de usuário e erros de ferramenta permanecem como contexto; chamadas de pesquisa úteis e de recuperação registradas recebem CE em uma sessão bem-sucedida; uma consulta de lista errônea marcada recebe KL em direção a um professor que recebeu uma dica fundamentada. — Uma sessão de programação ilustrativa mostra três funções de treinamento: entradas apenas de contexto e saídas de ferramenta (cinza), imitação por CE de chamadas registradas úteis (escuro) e correção por KL de um erro marcado (verde-água). Aqui, o modelo trata incorretamente uma lista de ocorrências de pesquisa como um dicionário; uma dica exclusiva do professor fundamentada na documentação anterior da ferramenta orienta a correção. Os alvos de CE aplicam-se apenas quando a sessão concluída é julgada como bem-sucedida, enquanto uma sessão sem sucesso ainda pode fornecer um alvo de correção por KL elegível.

O pipeline de treinamento tem quatro estágios: selecionar sessões e julgar seus resultados, identificar erros e criar dicas a partir do feedback do usuário e erros de ferramenta, gerar probabilidades do próximo token tanto do professor quanto do aluno, e treinar o modelo com uma perda combinada de CE e KL.

O pipeline de amostragem obtém de um subconjunto elegível para treinamento de sessões reais do Computer atendidas pelo GLM 5.2. Opt-outs de treinamento e as exclusões relacionadas a PII do pipeline são aplicados antes de selecionar exemplos para este fluxo de trabalho.

O processo de triagem inicial seleciona candidatos avaliados com 4 ou 5 em uma escala de dificuldade de tarefa de cinco pontos por um juiz de LLM e os divide em 2 grupos:

O grupo de feedback do usuário contém sessões com um acompanhamento genuíno do usuário ou um sinal de insatisfação de média a alta. Achamos esses acompanhamentos de alta intenção especialmente úteis para o aprendizado: os usuários estão tentando ativamente concluir uma tarefa, e suas correções apontam exatamente o que o modelo perdeu.
O grupo de erro de ferramenta contém sessões com chamadas com falha sinalizadas por verificações baseadas em regras, excluindo falhas de infraestrutura reconhecidas e autorização recusada.

Dois juízes de LLM avaliam então a entrega final em relação à solicitação do usuário; ambos os juízes devem retornar um veredito positivo para rotular a sessão como "bem-sucedida". Para casos que entregam artefatos, o estágio de resultado pode reconstruir e inspecionar a entrega, recorrendo aos seus julgamentos baseados em texto se esse estágio falhar. Sessões classificadas como incompletas, como trabalho aguardando o usuário, são excluídas.

Esta etapa identifica fontes potenciais de sinais de aprendizado; no entanto, nem todo erro é atribuível ao modelo, pois alguns decorrem de instruções ambíguas ou falhas de infraestrutura. A anotação posterior determina quais erros candidatos são realmente evitáveis e adequados para o treinamento.

Considere uma sessão de amostra no grupo de feedback do usuário, onde o usuário pergunta: “Como encontro meu w3 no paychex”. O modelo trata “w3” como um erro de digitação para W-2, pesquisa as instruções do W-2 e explica como encontrar esse formulário. O acompanhamento do usuário, “Eu quis dizer o formulário de transmissão W-3,” identifica o erro, mesmo que a sessão termine com sucesso.

A reclamação ajuda a localizar o erro, mas a causa raiz é a decisão anterior de reinterpretar “w3” como W-2. A solicitação original torna o erro evitável: o modelo poderia ter preservado o W-3 ou pedido esclarecimentos. Acontece que o último turno do assistente antes da reclamação é a causa raiz apenas cerca de metade das vezes.

Nosso pipeline de anotação mapeia causa e efeito sistematicamente dentro de cada sessão de feedback do usuário. O avaliador primeiro rastreia um requisito perdidos ou uma intenção apoiada por contexto anterior. Três juízes de LLM identificam então os turnos responsáveis, exigindo que pelo menos dois concordem em um determinado turno. Às vezes, uma declaração anterior estabelece explicitamente o requisito. Em outros casos, nenhuma declaração anterior isolada faz isso, mas várias partes da conversa precedente tornam conjuntamente inferível o comportamento pretendido. Esse design permite conectar uma reclamação a um erro raiz anterior, em vez de atribuí-la exclusivamente à última resposta.

Antes de aceitar uma dica, o pipeline também verifica se suas alegações corretivas decorrem de informações disponíveis antes do turno marcado. Essas mensagens destinam-se a reduzir o viés de hindsight, em que uma nova preferência revelada na reclamação é tratada como algo que o modelo já deveria saber.

Neste exemplo, a dica diz ao modelo para procurar o formulário de transmissão W-3 no Paychex em vez de W-2, ou perguntar qual formulário o usuário quer dizer se a solicitação for ambígua. A correção tem como alvo a interpretação anterior e a decisão de pesquisa, e não apenas a resposta final. O turno original permanece inalterado; a anotação adiciona is_bad_turn: true e um hint não vazio.

Uma solicitação de W-3 é interpretada erroneamente como W-2; uma reclamação posterior é rastreada até a decisão de pesquisa anterior e verificada com base em evidências anteriores. — Uma sessão real mostrando como uma reclamação é rastreada até um erro anterior, com o procedimento de anotação sobreposto. O usuário pediu por “w3” no Paychex, mas o modelo tratou isso como um erro de digitação para W-2 e pesquisou o formulário errado. O consenso dos proponentes localiza a causa raiz, enquanto duas verificações de fundamentação avaliam se a evidência é anterior ao erro e se as alegações da dica decorrem de informações disponíveis naquele momento. As anotações aceitas preservam o texto original e adicionam marcações e dicas, em vez de reescrever os alvos.

Considere outra sessão no grupo de erro de ferramenta com uma chamada de pesquisa onde o agente pesquisa com recency_filter: "year", mas a ferramenta a rejeita porque os valores permitidos são “day”, “week” ou “month”. Esta é uma clara violação de esquema.

O caminho de erro de ferramenta usa regras determinísticas para erros conhecidos e julgamento de modelo para casos ambíguos. Uma mensagem de erro isolada também não é suficiente para culpar o modelo; uma correção julgada deve apontar para algo que o modelo poderia saber a partir do esquema da ferramenta, instruções do sistema ou conversa anterior.

Uma chamada de pesquisa usa o valor inválido year de recency_filter; uma dica fundamentada instrui o modelo a usar um valor listado ou omitir um campo opcional. — O argumento de pesquisa inválido do relatório ilustra o procedimento atual de erro de ferramenta. O esquema torna esse erro evitável; uma interrupção isolada não tornaria. A chamada original permanece no registro e recebe uma dica fundamentada. A dica permite um valor listado ou omissão se o campo for opcional; ela não exige “month” para todas as solicitações.

Aqui, a dica nomeia a chamada com falha, inclui o erro de validação e instrui o modelo a usar um valor permitido ou omitir o campo se ele for opcional.

Uma vez que um turno é marcado, o treinador executa o mesmo ponto de verificação duas vezes: uma vez como professor e outra como aluno. O professor vê a dica; o aluno não.

Ambas as passagens usam o forçamento de professor, onde alimentamos o modelo com a sessão registrada em vez de deixá-lo escolher novos tokens. A passagem direta ainda produz uma distribuição completa do próximo token em cada etapa, mas é sempre condicionada ao prefixo fixo da gravação, e não aos tokens de roll-out.

Para o exemplo de pesquisa, o mesmo modelo atribui probabilidade muito maior a “month” e menor a “year” quando recebe a dica. O treinamento usa esse desvio de distribuição como um alvo suave.

O mesmo modelo pontua um turno registrado com e sem uma dica; probabilidades do professor desconectadas fornecem alvos KL enquanto a CE ancora a imitação. — Duas passagens, um conjunto de pesos. Ambas as passagens pontuam a continuação registrada; apenas o professor recebe dicas. Suas probabilidades desconectadas do próximo token guiam o aluno por KL direto. Alvos CE separados ancoram a imitação. Ambas as perdas alimentam uma única atualização de peso. Dicas anteriores podem permanecer no segmento atual do professor; nenhuma passagem gera uma resposta de treinamento substituta.

As previsões do professor são desconectadas, ou com gradiente interrompido: elas fornecem um alvo, mas não recebem uma atualização por meio da passagem do professor. Após a passagem do aluno, uma etapa do otimizador atualiza o modelo compartilhado.

A perda CE trata os tokens gravados selecionados para imitação como alvos de verdade absoluta e penaliza o modelo por atribuir a eles baixas probabilidades. Isso cria um alvo de imitação rígido.

Na posição de token $i$ , seja $p_i(v)$ a probabilidade do aluno para o token $v$ em todo o vocabulário $V$ . O próximo token registrado na resposta ou na chamada de ferramenta é $y_i$ , e a distribuição de alvo one-hot é $r_i$ .

r_i(v)=\mathbf{1}[v=y_i]

A entropia cruzada mede quão bem o aluno prevê esse token registrado. Com um alvo one-hot, ela se reduz à log-probabilidade negativa atribuída a $y_i$ .

H(r_i,p_i)=-\sum_{v\in V}r_i(v)\log p_i(v)=-\log p_i(y_i)

A máscara CE $m_i^{\mathrm{CE}}$ é $1$ onde o token deve ser imitado e $0$ caso contrário. A somatória sobre as posições selecionadas fornece a perda de imitação.

\mathcal{L}_{\mathrm{CE}}=\sum_i m_i^{\mathrm{CE}}H(r_i,p_i)

A perda KL, em vez disso, usa a distribuição completa de probabilidade do próximo token do professor $q_i$ como um alvo de correção suave. O contexto do professor inclui a dica atual e quaisquer dicas anteriores retidas nesse segmento de treinamento; o contexto do aluno é sempre livre de dicas.

A máscara KL $m_i^{\mathrm{KL}}$ é $1$ onde o token deve ser corrigido e $0$ caso contrário; as máscaras de CE e KL não se sobrepõem. Nessas posições, o KL direto penaliza a discordância entre o professor e o aluno em todo o vocabulário:

\mathcal{L}_{\mathrm{KL}}=\sum_i m_i^{\mathrm{KL}}D_{\mathrm{KL}}(q_i\Vert p_i)=\sum_i m_i^{\mathrm{KL}}\sum_{v\in V}q_i(v)\log\frac{q_i(v)}{p_i(v)}

Ambos os termos compartilham um único denominador em vez de serem normalizados separadamente. Este denominador conta o total de tokens selecionados para imitação em todo o lote de treinamento global. O peso $\lambda$ controla a contribuição do treinamento corretivo em relação à imitação.

Esta normalização compartilhada se ajusta à interface de denominador único da nossa infraestrutura de treinamento e recupera a perda de SFT padrão quando $\lambda=0$ , simplificando comparações de linha de base. Como os tokens de CE são muito mais abundantes do que os tokens de KL, o uso de um denominador compartilhado também evita dar a tokens de KL individuais pesos desproporcionalmente grandes em lotes com poucos tokens marcados.

\mathcal{L}=\frac{\mathcal{L}_{\mathrm{CE}}+\lambda\mathcal{L}_{\mathrm{KL}}}{\sum_i m_i^{\mathrm{CE}}}

Aplicado aos exemplos anteriores, os turnos contendo a confusão W-3/W-2 e a chamada de pesquisa inválida recebem KL. Outro conteúdo de assistente não marcado em uma sessão bem-sucedida ainda recebe CE. Outro conteúdo de assistente em uma sessão sem sucesso é retido como contexto, mas não recebe CE nem KL.

Nossas avaliações respondem a duas perguntas distintas. Primeiro, uma dica realmente ajuda o modelo a corrigir um erro quando a dica está presente? Segundo, o treinamento ajuda o modelo a evitar esse erro mais tarde, sem a dica? A primeira testa se as dicas fornecem sinais de treinamento úteis. A segunda testa se o modelo aprende com elas.

Testamos a primeira pergunta antes da execução do treinamento para garantir que as dicas possam de fato afastar o modelo dos erros.

Regeneramos os turnos de feedback do usuário marcados com e sem uma dica, usando o mesmo modelo base GLM-5.2 na temperatura zero. Um juiz cego vê a reclamação posterior, mas nem a dica nem qual condição produziu a resposta.

No exemplo de W-3, a dica desloca a probabilidade do próximo token em direção a “3” e para longe de “2” após o prefixo “W-”.

As probabilidades do próximo token após W- deslocam-se em direção a 3 em vez de 2 quando o modelo base inalterado recebe uma dica. — Uma dica preserva o formulário W-3 solicitado. As barras mostram as probabilidades médias do próximo token em oito passagens diretas; as linhas verticais mostram o intervalo observado, não um intervalo de confiança. Ambas as condições usam o modelo base inalterado.

Em uma amostra reservada maior de 40 turnos apoiada por evidências anteriores declaradas explicitamente, a proporção julgada como corrigida ou no caminho sobe de 40,0% sem dica para 75,0% com uma. Em outros 40 turnos apoiados por intenção inferida, ela sobe de 32,5% para 80,0%.

Validação de dicas: taxas fixas ou no caminho aumentam de 40,0% para 75,0% para evidências explícitas e de 32,5% para 80,0% para intenção inferida. — Validação de dicas, não avaliação de pós-treinamento. Os mesmos 40 turnos marcados em cada grupo de evidência são regenerados com e sem uma dica usando o GLM-5.2 inalterado na temperatura zero. O juiz vê a reclamação, mas não a dica ou a condição. As contagens são derivadas das taxas e tamanhos de amostra do relatório; intervalos de confiança não são relatados.

No exemplo de erro da ferramenta de pesquisa, uma dica de fato desloca a massa de probabilidade do token year para o token month.

Uma dica desvia as probabilidades do próximo token do modelo base inalterado para longe de year e em direção ao valor permitido month. — Uma dica desvia a probabilidade em direção a um valor permitido. As barras mostram as probabilidades médias do próximo token em oito passagens diretas; as linhas verticais mostram o intervalo observado, não um intervalo de confiança. Ambas as condições usam o mesmo modelo base; nenhum ponto de verificação treinado é comparado.

Em uma amostra reservada maior de 985 turnos, regeneramos cada turno quatro vezes com e sem uma dica usando o mesmo modelo base. Um juiz cego avalia se cada regeneração evita a falha original. As dicas elevam a evitação de falhas de 75,1% para 93,7%, um ganho emparelhado de 18,6 pontos percentuais, e aumentam a proporção de adoção da ação corrigida de 60,6% para 82,3%. Os ganhos são maiores em erros que a amostragem repetida sozinha tem dificuldade de corrigir.

Em 985 turnos de erro de ferramenta reservados marcados, as dicas elevam a evitação de falhas de 75,1% para 93,7% e as taxas de ação corrigida de 60,6% para 82,3%. — Validação de dicas de erro de ferramenta em 985 turnos marcados reservados, com quatro regenerações por condição. As barras mostram a evitação de falhas e as taxas de ação corrigida para o modelo base inalterado, com e sem dicas. Evitar o erro direcionado não estabelece o sucesso da chamada de ferramenta ou da tarefa.

Em seguida, testamos se o modelo treinado comete menos erros sem receber dicas. Avaliamos o modelo padrão e vários checkpoints pós-treinamento em tarefas de benchmark offline e em sessões reais de usuários, verificando menos falhas de ferramenta e menor insatisfação do usuário.

A avaliação offline usa BrowseComp, Finch, WideSearch, DRACO, DSQA, SpreadsheetBench, HLE, um conjunto de tarefas representativo do Computer e verifica o carregamento de habilidades, revisão de documentos e citações em linha. Medimos a parcela de chamadas de ferramenta cujos resultados são explicitamente sinalizados como erros em todas as trajetórias de avaliação.

Nessas avaliações, a taxa de erro de ferramenta registrada foi de 2,79% para o GLM 5.2 padrão, 1,35% para o ponto de verificação de apenas RFT e 0,87% para um ponto de verificação de RFT com OPSD. Esses pontos de verificação foram treinados em dados diferentes, portanto, esta não é uma ablação de dados combinados do OPSD. Os resultados de benchmark em nível de tarefa foram mistos, de modo que menos erros de ferramenta isolados não se traduzem necessariamente em uma melhoria ampla no sucesso da tarefa.

Taxas de erro de ferramenta registradas offline: 2,79% para GLM 5.2 padrão, 1,35% para apenas RFT e 0,87% para RFT mais OPSD; os dados de treinamento diferem. — Taxas de erro de ferramenta offline para pontos de verificação de GLM-5.2 padrão, apenas RFT e RFT com OPSD. Os dados de treinamento diferem entre os pontos de verificação; esta não é uma ablação de dados combinados.

Para o GLM-5.2, realizamos dois testes A/B separados com cerca de cem mil usuários em cada condição. No primeiro, um ponto de verificação inicial de RFT com OPSD teve uma taxa de falha de ferramenta ligeiramente menor do que o GLM 5.2 padrão, 2,82% versus 2,94%, mas a diferença não foi estatisticamente significativa.

No teste posterior, comparamos dois pontos de verificação de RFT com OPSD: um anterior (ponto de verificação um) e um posterior (ponto de verificação dois). As falhas de chamada de ferramenta caíram de 2,24% para 1,77% das chamadas com um status registrado. Esta foi uma redução relativa estatisticamente significativa de 21,2%. Não comparamos diretamente o ponto de verificação dois com o GLM 5.2 padrão online.

Os resultados de feedback do usuário foram menos conclusivos. No segundo experimento do GLM-5.2, a probabilidade média de insatisfação forte (média ou alta) foi de 2,58% para o ponto de verificação um e de 2,54% para o ponto de verificação dois, sem diferença estatisticamente significativa.

Dois testes A/B online separados; apenas a comparação de pontos de verificação posteriores tem uma redução significativa de falhas de ferramenta, sem alteração significativa na insatisfação com o MID+. — Dois testes A/B reais separados do GLM-5.2. O ponto de verificação 1 é comparado com o GLM-5.2 padrão; o ponto de verificação 2 é comparado com o ponto de verificação 1. Desses dois testes, apenas a redução posterior de falhas de ferramentas é estatisticamente significativa. As taxas MID+ representam probabilidades estimadas médias de insatisfação média ou alta, e não contagens de reclamações.

Para o GLM-5.3, comparamos um ponto de verificação pós-treinamento diretamente com o GLM-5.3 original. As falhas em chamadas de ferramentas caíram de 3,56% para 2,38% das chamadas com um status registrado, uma redução relativa de 33,04%. A taxa MID+, a probabilidade média estimada de insatisfação média ou alta, caiu de 4,12% para 3,41%, uma redução relativa de 17,2%. Ambas as reduções foram estatisticamente significativas.

Teste A/B do GLM-5.3: a taxa de falha de ferramentas cai de 3,56% para 2,38% e a taxa MID+, a probabilidade média estimada de insatisfação média ou alta, cai de 4,12% para 3,41%. As reduções relativas ajustadas por CUPED são de 33,04% e 17,16%, respectivamente. Ambos os intervalos sequenciais de 95% excluem zero; a métrica de engajamento principal não é significativa. — GLM-5.3 pós-treinado versus GLM-5.3 original em um teste A/B online separado. As taxas de falha de ferramentas e MID+, as alterações relativas e os intervalos de confiança sequenciais de 95% usam o ajuste CUPED. Ambas as reduções são estatisticamente significativas. As taxas MID+ são probabilidades médias estimadas de insatisfação média ou alta em tópicos de acompanhamento pontuados elegíveis, não contagens de reclamações. As taxas de falha de ferramentas excluem chamadas sem um status de sucesso ou falha registrado.

A ideia central é aprender no nível da decisão, e não apenas da sessão.

Um resultado bem-sucedido pode ocultar erros, e uma sessão sem sucesso ainda pode revelar como melhorar. Mantemos o comportamento útil de sessões bem-sucedidas como uma âncora, usamos reclamações e erros de ferramenta para identificar falhas evitáveis e treinamos o modelo em direção às previsões que ele faz quando esses erros e correções são tornados explícitos. O sucesso fornece comportamento a ser preservado; a falha fornece direção para melhoria.

O uso no mundo real torna essa abordagem especialmente útil. Os usuários reais trazem objetivos, restrições e fluxos de trabalho que são difíceis de antecipar em um ambiente sintético. Suas correções revelam requisitos que o modelo perdeu, enquanto os erros de ferramenta expõem lacunas entre o que o modelo tentou e o que o ambiente permite. Esses sinais complementam o treinamento baseado em resultados: em vez de perguntar apenas se uma tarefa foi bem-sucedida, podemos perguntar onde o modelo errou e quais informações poderiam tê-lo ajudado a tomar uma decisão melhor.

Os limites são igualmente importantes. Os avaliadores podem errar, e corrigir um turno não garante que a tarefa completa seja bem-sucedida. O objetivo não é apenas um agente que se recupera após uma correção. É um agente que precisa de correção com menos frequência.

BibTeX

@online{perplexity2026LearningFromRealWorldExperience,
  author = {{Perplexity} and Senzeyu Zhang and Chuan Wang and Hang Wu and Hao Zhang and Yuan Liang and Yunfan Zhong and Phi Hoang and Claire Beamer and Jeremy Yang and Andrew Wilson and Denis Yarats},
  title = {{Learning from real-world experience}},
  date = {2026-09-21},
  url = {https://www.perplexity.ai/hub/blog/learning-from-real-world-experience}
}

De dados sintéticos para dados do mundo real

Imitar as boas etapas, corrigir as ruins

Um exemplo: uma sessão pode ensinar ambas as lições

Como o treinamento funciona

Selecionar sessões e, em seguida, julgar o resultado

Encontrar os erros a partir do feedback do usuário

Encontrar os erros a partir de erros de ferramenta

Duas passagens diretas

A função de perda

A perda CE

Perda KL

Perda combinada

O que as avaliações mostram

As dicas podem afastar o modelo dos erros

Feedback do usuário

Erros de ferramenta

Confiabilidade de ferramentas e feedback do usuário após o treinamento

Avaliação offline

Avaliação online: GLM-5.2

Avaliação online: GLM-5.3

Conclusão

Citação