Aprendendo com a experiência do mundo real

A forma como os utilizadores interagem com os nossos produtos no mundo real é uma fonte valiosa para o treino de modelos. Os dados são abundantes, refletem a distribuição real das tarefas dos utilizadores e capturam correções de utilizadores e falhas de ferramentas que os ambientes sintéticos podem ignorar.

Uma forma comum de aprender a partir de dados do mundo real é o fine-tuning por amostragem de rejeição: avaliar o resultado de cada sessão, manter as bem-sucedidas e treinar o modelo para as imitar. Mas um resultado bem-sucedido não significa que todos os passos tenham sido corretos, pelo que imitar toda a trajetória corre o risco de reforçar maus comportamentos intermédios para além dos bons. Descartar sessões sem sucesso também faz perder evidências críticas sobre onde o modelo fica aquém.

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 breve instrução corretiva fundamentada 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 fundamentadas transformam erros evitáveis em alvos de correção.

As correções dos utilizadores e os erros de ferramentas adicionam supervisão sobre o que correu mal ao longo do processo, para além de saber se a tarefa acabou por ser bem-sucedida. Aplicamos esta etapa após a aprendizagem por reforço em ambientes sintéticos para ajudar a reduzir a lacuna entre esses ambientes e a utilização no mundo real.

Em uso real, um ponto de verificação posterior de GLM-5.2 treinado reduziu as falhas de 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 de chamadas de ferramentas em 33,0% e a probabilidade estimada média de insatisfação do usuário média ou alta em 17,2% em relação ao modelo base.

As tarefas sintéticas permitem-nos criar problemas controlados com resultados fáceis de verificar, mas tipicamente limitam-se a um único prompt e apenas conseguem cobrir os cenários que concebemos explicitamente.

Em contrapartida, os utilizadores 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 múltiplos turnos de interação. Essa utilização no mundo real produz naturalmente dois sinais valiosos de erros: as correções dos utilizadores revelam onde o agente falhou em entregar o que pretendiam, e os erros de ferramentas mostram onde as suas ações falharam em ambientes reais. O nosso pipeline de amostragem respeita a privacidade e as escolhas de treino dos utilizadores, excluindo sessões com informações de identificação pessoal (PII) e de utilizadores que optaram por não participar.

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

Ao treinar com dados do mundo real, o fine-tuning por amostragem de rejeição (RFT) standard seleciona sessões bem-sucedidas com base nos seus resultados finais, sem utilizar explicitamente o feedback do utilizador e das ferramentas para distinguir boas ações intermédias de más. Um agente pode recuperar de uma chamada de ferramenta incorreta ou corrigir um erro após o feedback do utilizador e ainda assim entregar a saída correta no final.

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

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

Imitar: as interações sem erros em sessões bem-sucedidas recebem a perda de entropia cruzada (CE) normal, aumentando a probabilidade de tokens registados.
Corrigir: tanto em sessões bem-sucedidas como sem sucesso, as interações com erros 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 token seguinte que este faz quando vê a dica.
Manter como contexto: as interações em sessões sem sucesso que não têm uma dica validada, e interações marcadas como incorretas sem uma dica validada em qualquer tipo de sessão, servem como contexto, mas não recebem nenhuma das perdas.

Como resultado, as sessões bem-sucedidas podem fornecer alvos de imitação e de correção, enquanto as sessões sem sucesso fornecem apenas alvos de correção. Todas as interações restantes, incluindo a saída do sistema, do utilizador e da ferramenta, permanecem como contexto.

Diagrama de encaminhamento de sessões: sessões bem-sucedidas fornecem imitação CE e correções com dicas elegíveis; sessões sem sucesso fornecem apenas correções elegíveis. — Encaminhamento da sessão atual e máscaras de conteúdo do assistente. As sessões bem-sucedidas contribuem com alvos de imitação; os registos 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. As sessões incompletas são excluídas. A exceção CE de yield/stop-token não final não é desenhada, e este diagrama não estabelece a mistura utilizada por um ponto de controlo anterior.

A parte da imitação utiliza o RFT standard. A parte corretiva utiliza On-Policy Self-Distillation (OPSD): o mesmo modelo atua como professor e aluno, sendo fornecida informação privilegiada ao professor. Aqui, essa informação privilegiada é uma dica curta que explica um erro evitável. Treinamos o aluno para corresponder às previsões do token seguinte do professor sem receber a dica.

Ambas as partes são importantes. O treino apenas de correção pode expor um atalho: o professor e o aluno podem concordar ignorando o contexto em vez de aprenderem a correção. O termo CE ancora o treino a um comportamento útil, ajudando a desincentivar acordos que resultem da ignorância do contexto.

O aluno pós-treinado torna-se então uma opção de modelo no Computer. Novas sessões de utilização em direto passam pelos mesmos filtros de elegibilidade e privacidade antes de entrarem noutro ciclo do pipeline de treino.

A seguir, analisamos um exemplo concreto que contém tanto a imitação como a correção.

Considere uma sessão eventualmente bem-sucedida em que o utilizador pede uma comparação das alterações ao asyncio no Python 3.13 utilizando a documentação oficial. A nossa documentação de ferramentas indica que search.web devolve uma lista de resultados (hits), cada um com um campo url.

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

No entanto, a chamada de execução de código seguinte trata incorretamente essa lista como um dicionário. A ferramenta de código devolve 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. Pode ser gerada uma dica com a chamada correta para corrigir essa ação.

Sessão de programação ilustrativa: a entrada do sistema e do utilizador e os erros de ferramentas permanecem como contexto; as chamadas de pesquisa e recuperação registadas úteis recebem CE numa sessão bem-sucedida; uma consulta de lista errónea marcada recebe KL em direção a um professor com uma dica fundamentada. — Uma sessão de programação ilustrativa mostra três funções de treino: entradas apenas de contexto e saídas de ferramentas (cinzento), imitação CE de chamadas registadas úteis (escuro) e correção KL de um erro marcado (verde-azulado). Aqui, o modelo trata incorretamente uma lista de resultados de pesquisa como um dicionário; uma dica exclusiva do professor fundamentada na documentação de ferramentas anterior orienta a correção. Os alvos CE aplicam-se apenas quando a sessão concluída é considerada bem-sucedida, enquanto uma sessão sem sucesso ainda pode fornecer um alvo de correção KL elegível.

O pipeline de treino tem quatro etapas: selecionar sessões e avaliar os seus resultados, identificar erros e criar dicas a partir do feedback do utilizador e de erros de ferramentas, gerar probabilidades de token seguinte a partir do professor e do aluno, e treinar o modelo com uma perda CE e KL combinada.

O pipeline de amostragem extrai de um subconjunto elegível para treinamento de sessões reais do Computer atendidas pelo GLM 5.2. As exclusões relacionadas a PII e as exclusões do pipeline de opt-out de treinamento são aplicadas antes de selecionar exemplos para este fluxo de trabalho.

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

O grupo de feedback do utilizador contém sessões com um seguimento genuíno do utilizador ou um sinal de insatisfação de média a alta. Consideramos estes seguimentos de alta intenção especialmente úteis para a aprendizagem: os utilizadores estão a tentar ativamente concluir uma tarefa e as suas correções apontam com precisão o que o modelo falhou.
O grupo de erros de ferramentas contém sessões com chamadas falhadas sinalizadas por verificações baseadas em regras, excluindo falhas de infraestrutura reconhecidas e autorizações recusadas.

Dois juízes LLM avaliam então a entrega final em relação ao pedido do utilizador; ambos os juízes devem dar um Veredito positivo para classificar a sessão como "bem-sucedida". No caso de entregas que incluam artefactos, a etapa de resultado pode reconstruir e inspecionar a entrega, recorrendo às suas avaliações baseadas em texto se essa etapa falhar. As sessões classificadas como incompletas, como o trabalho à espera do utilizador, são excluídas.

Este passo identifica potenciais fontes de sinais de aprendizagem; no entanto, nem todos os erros são atribuíveis ao modelo, uma vez que alguns decorrem de instruções ambíguas ou falhas na infraestrutura. A anotação posterior determina quais os erros candidatos que são efetivamente evitáveis e adequados para o treino.

Considere uma sessão de exemplo no grupo de feedback do utilizador, onde o utilizador pergunta: "How do I find my w3 on paychex". O modelo trata "w3" como um erro ortográfico de W-2, pesquisa instruções para W-2 e explica como encontrar esse formulário. A pergunta seguinte do utilizador, "I meant the W-3 transmittal form,", identifica o erro, mesmo que a sessão acabe por ser bem-sucedida.

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

O nosso pipeline de anotação mapeia a causa e o efeito de forma sistemática dentro de cada sessão de feedback do utilizador. O anotador começa por detetar um requisito falhado ou uma intenção apoiada pelo contexto anterior. Três juízes LLM identificam então as interações responsáveis, exigindo que pelo menos dois concordem sobre uma determinada interação. Por vezes, uma declaração anterior estabelece explicitamente o requisito. Noutros casos, nenhuma declaração anterior isolada o faz, mas múltiplos elementos da conversa precedente tornam conjuntamente o comportamento pretendido inferível. Esta conceção permite ligar uma reclamação a um erro de origem anterior em vez de a atribuir exclusivamente à última resposta.

Antes de aceitar uma dica, o pipeline também verifica se as suas alegações corretivas decorrem de informações disponíveis antes da interação marcada. Estas verificações destinam-se a reduzir o viés de retrospeção (hindsight bias), 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 do W-2, ou para perguntar qual o formulário pretendido pelo utilizador se o pedido for ambíguo. A correção tem como alvo a interpretação anterior e a decisão de pesquisa, e não apenas a resposta final. A interação original permanece inalterada; a anotação adiciona is_bad_turn: true e uma hint não vazia.

Um pedido de W-3 é interpretado incorretamente como W-2; uma reclamação posterior é rastreada até à decisão de pesquisa anterior e verificada em relação a evidências prévias. — Uma sessão real que mostra como uma reclamação é rastreada até um erro anterior, com o procedimento de anotação sobreposto. O utilizador pediu "w3" no Paychex, mas o modelo tratou-o como um erro ortográfico de W-2 e procurou 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 nesse momento. As anotações aceites preservam o texto original e adicionam marcas e dicas, em vez de reescreverem os alvos.

Considere outra sessão no grupo de erro de ferramentas com uma chamada de pesquisa em que o agente pesquisa com recency_filter: "year", mas a ferramenta rejeita-a porque os valores permitidos são “day”, “week” ou “month”. Trata-se de uma violação clara do esquema.

O caminho de erro de ferramentas utiliza regras determinísticas para erros conhecidos e o julgamento do modelo para casos ambíguos. Apenas uma mensagem de erro também não é suficiente para culpar o modelo; uma correção avaliada deve apontar para algo que o modelo poderia ter sabido através do esquema da ferramenta, das instruções do sistema ou da conversa anterior.

Uma chamada de pesquisa utiliza o valor inválido year de recency_filter; uma dica fundamentada instrui o modelo a utilizar um valor listado ou a omitir um campo opcional. — O argumento de pesquisa inválido do relatório ilustra o procedimento atual de erro de ferramentas. O esquema torna este erro evitável; uma interrupção por si só não o tornaria. A chamada original permanece no registo e recebe uma dica fundamentada. A dica permite um valor listado ou a omissão se o campo for opcional; não exige "month" para todos os pedidos.

Aqui, a dica nomeia a chamada falhada, inclui o erro de validação e instrui o modelo a utilizar um valor permitido ou a omitir o campo se este for opcional.

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

Ambas as passagens utilizam teacher forcing, onde fornecemos ao modelo a sessão registada em vez de permitir que este escolha novos tokens. A passagem direta ainda produz uma distribuição completa do token seguinte em cada passo, mas está sempre condicionada ao prefixo fixo da gravação, e não aos tokens de rollout.

Para o exemplo de pesquisa, o mesmo modelo atribui uma probabilidade muito maior a "month" e menor a "year" quando recebe a dica. O treino utiliza este desvio de distribuição como um alvo suave.

O mesmo modelo pontua uma interação registada com e sem uma dica; as probabilidades do professor desconectado fornecem alvos KL, enquanto o CE ancora a imitação. — Duas passagens, um conjunto de pesos. Ambas as passagens pontuam a continuação registada; apenas o professor recebe dicas. As suas probabilidades de token seguinte desconectadas guiam o aluno através da divergência KL direta. Alvos CE separados ancoram a imitação. Ambas as perdas alimentam uma atualização de peso. As dicas anteriores podem permanecer no segmento atual do professor; nenhuma das passagens gera uma resposta de treino de substituição.

As previsões do professor são desconectadas ou stop-gradient: fornecem um alvo, mas não recebem uma atualização através da passagem do professor. Após a passagem do aluno, um passo do otimizador atualiza o modelo partilhado.

A perda CE trata os tokens registados selecionados para imitação como alvos de verdade absoluta (ground-truth) e penaliza o modelo por lhes atribuir probabilidades baixas. Isto 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$ no vocabulário completo $V$ . O token seguinte registado na resposta ou chamada de ferramenta é $y_i$ , e a distribuição-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 registado. Com um alvo one-hot, reduz-se à 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 das posições selecionadas resulta na perda de imitação.

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

Em vez disso, a perda KL utiliza a distribuição de probabilidade completa do token seguinte 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 treino; o contexto do aluno está 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 CE e KL não se sobrepõem. Nestas posições, a divergência KL direta penaliza a divergê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 partilham um denominador em vez de serem normalizados separadamente. Este denominador conta o total de tokens selecionados para imitação em todo o lote de treino global. O peso $\lambda$ controla a contribuição do treino corretivo em relação à imitação.

Esta normalização partilhada adapta-se à interface de denominador único da nossa infraestrutura de treino e recupera a perda SFT standard quando $\lambda=0$ , simplificando as comparações de base. Como os tokens CE são muito mais abundantes do que os tokens KL, a utilização de um denominador partilhado também evita atribuir pesos desproporcionalmente grandes a tokens KL individuais 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, as interações que contêm a mistura W-3/W-2 e a chamada de pesquisa inválida recebem KL. Outro conteúdo de assistente não marcado numa sessão bem-sucedida continua a receber CE. Outro conteúdo de assistente numa sessão sem sucesso é retido como contexto, mas não recebe nem CE nem KL.

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

Testamos a primeira pergunta antes de executar o treino para garantir que as dicas conseguem de facto afastar o modelo dos erros.

Regenerámos as interações de feedback do utilizador marcadas com e sem uma dica, utilizando o mesmo modelo base GLM-5.2 à temperatura zero. Um juiz cego vê a reclamação posterior, mas nem a dica nem a condição que produziu a resposta.

No exemplo W-3, a dica desvia a probabilidade do token seguinte para "3" e afasta-a de "2" após o prefixo "W-".

As probabilidades do token seguinte após W- deslocam-se para 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 token seguinte em oito passagens diretas; as linhas indicam o intervalo observado, e não um intervalo de confiança. Ambas as condições utilizam o modelo base inalterado.

Numa amostra reservada maior de 40 interações apoiadas por evidências anteriores explicitamente declaradas, a proporção considerada corrigida ou no caminho certo sobe de 40,0% sem uma dica para 75,0% com uma. Noutras 40 interações apoiadas por intenção inferida, sobe de 32,5% para 80,0%.

Validação de dicas: as taxas fixas ou no caminho certo aumentam de 40,0% para 75,0% para evidências explícitas e de 32,5% para 80,0% para intenções inferidas. — Validação de dicas, e não avaliação de pós-treino. As mesmas 40 interações marcadas em cada grupo de evidências são regeneradas com e sem uma dica, utilizando o GLM-5.2 inalterado à 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 dimensões das amostras do relatório; os intervalos de confiança não são reportados.

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

Uma dica desvia as probabilidades de token seguinte do modelo base inalterado de year para o valor permitido month. — Uma dica desvia a probabilidade para um valor permitido. As barras mostram as probabilidades médias do token seguinte em oito passagens diretas; as linhas indicam o intervalo observado, e não um intervalo de confiança. Ambas as condições utilizam o mesmo modelo base; nenhum ponto de controlo treinado é comparado.

Numa amostra reservada maior de 985 interações, regeneramos cada interação quatro vezes com e sem uma dica, utilizando o mesmo modelo base a temperatura zero. Um juiz cego avalia se cada regeneração evita a falha original. As dicas aumentam a prevençã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 por si só tem dificuldade em corrigir.

Em 985 interações com erros de ferramentas marcadas e reservadas, as dicas aumentam a prevenção de falhas de 75,1% para 93,7% e as taxas de ações corrigidas de 60,6% para 82,3%. — Validação de dicas de erro de ferramentas em 985 interações marcadas e reservadas, com quatro regenerações por condição. As barras mostram a prevenção de falhas e as taxas de ações corrigidas para o modelo base inalterado, com e sem dicas. Evitar o erro visado não garante 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 ferramentas e menor insatisfação dos usuários.

A avaliação offline utiliza BrowseComp, Finch, WideSearch, DRACO, DSQA, SpreadsheetBench, HLE, um conjunto representativo de tarefas do Computer e verifica o carregamento de skills, a revisão de documentos e as citações no texto. Medimos a proporção de chamadas de ferramentas cujos resultados são explicitamente sinalizados como erros nas trajetórias de avaliação.

Nestas avaliações, a taxa de erro de ferramentas registada foi de 2,79% para o GLM 5.2 de base, 1,35% para o ponto de controlo RFT exclusivo e 0,87% para um ponto de controlo RFT-plus-OPSD. Estes pontos de controlo foram treinados com dados diferentes, pelo que esta não é uma ablação de dados emparelhados do OPSD. Os resultados dos benchmarks ao nível das tarefas foram mistos, pelo que menos erros de ferramentas por si só não se traduzem necessariamente numa melhoria ampla no sucesso das tarefas.

Taxas de erro de ferramentas registadas offline: 2,79% para o GLM 5.2 de base, 1,35% para RFT exclusivo e 0,87% para RFT mais OPSD; os dados de treino diferem. — Taxas de erro de ferramentas offline para os pontos de controlo GLM-5.2 de base, RFT exclusivo e RFT-plus-OPSD. Os dados de treino diferem entre os pontos de controlo; esta não é uma ablação de dados emparelhados.

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 controle inicial de RFT com OPSD apresentou 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, comparámos dois pontos de controlo RFT-plus-OPSD: um anterior (ponto de controlo um) e um posterior (ponto de controlo dois). As falhas de chamadas de ferramentas caíram de 2,24% para 1,77% das chamadas com um estado registado. Esta foi uma redução relativa estatisticamente significativa de 21,2%. Não comparámos diretamente o ponto de controlo dois com o GLM 5.2 de base online.

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

Dois testes A/B online separados; apenas a comparação posterior de pontos de controlo apresenta uma redução significativa de falhas de ferramentas, sem alterações significativas na insatisfação com o MID+. — Dois testes A/B reais separados do GLM-5.2. O ponto de controle 1 é comparado com o GLM-5.2 padrão; o ponto de controle 2 é comparado com o ponto de controle 1. Nestes dois testes, apenas a redução posterior de falhas de ferramentas é estatisticamente significativa. As taxas de MID+ representam probabilidades médias estimadas 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-treinado diretamente com o GLM-5.3 base. As falhas de 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 estimada média 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 estimada média 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 base em um teste A/B online separado. As taxas de falha de ferramentas e MID+, alterações relativas e intervalos de confiança sequenciais de 95% usam ajuste CUPED. Ambas as reduções são estatisticamente significativas. As taxas MID+ são probabilidades estimadas médias de insatisfação média ou alta em tópicos de acompanhamento pontuados elegíveis, e 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 ao 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, utilizamos reclamações e erros de ferramentas para identificar falhas evitáveis e treinamos o modelo em direção às previsões que este faz quando esses erros e correções são tornados explícitos. O sucesso fornece comportamento a preservar; a falha fornece direção para a melhoria.

A utilização no mundo real torna esta abordagem especialmente útil. Os utilizadores reais trazem objetivos, restrições e fluxos de trabalho que são difíceis de antecipar num ambiente sintético. As suas correções revelam requisitos que o modelo falhou, enquanto os erros de ferramentas expõem lacunas entre o que o modelo tentou e o que o ambiente permite. Estes sinais complementam o treino baseado em resultados: em vez de perguntar apenas se uma tarefa foi bem-sucedida, podemos perguntar onde o modelo errou e que informação o poderia ter ajudado a tomar uma decisão melhor.

Os limites são igualmente importantes. Os juízes 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 os bons passos, corrigir os maus

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

Como funciona o treino

Selecionar sessões e avaliar o resultado

Encontrar os erros a partir do feedback do utilizador

Encontrar os erros a partir de erros de ferramentas

Duas passagens diretas

A função de perda

A perda CE

Perda KL

Perda combinada

O que as avaliações mostram

As dicas conseguem afastar o modelo dos erros

Feedback do utilizador

Erros de ferramentas

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