Em resumo.
Há duas maneiras de dar uma regra ao modelo que escreve um rascunho. Pode escrever a regra nas instruções e confiar que o modelo a segue. Ou o software pode verificar o rascunho acabado e recusá-lo quando a regra não é cumprida.
No nosso exemplo mais claro, a regra escrita não se aguentou. Durante cerca de duas semanas, as instruções disseram ao modelo exatamente como fechar a mensagem. Dos 178 rascunhos desse período, 40 tinham o fecho exatamente como indicado, 93 tinham um fecho diferente e 45 não tinham nenhum.
Por isso, as regras que importam são agora verificações que recusam, e cada recusa fica registada com a regra que a causou. Este artigo mostra o que essas verificações apanharam. Não mostra que as mensagens ficaram melhores, e o exemplo é uma única configuração, não uma taxa geral.
Uma instrução, 14 dias sem verificação.
Um espaço de trabalho pode definir como terminam as suas mensagens: as palavras de despedida e o nome. É a regra mais simples que temos. Não exige critério, só copiar.
Mais ou menos de 7 a 20 de setembro, as instruções ao modelo indicavam o fecho, e nada verificava o resultado. Analisámos os rascunhos escritos pelo modelo nesse período e comparámos o final com o fecho definido.
Estes números vêm com três limites. Todos os rascunhos contados como «diferentes» vêm de uma única configuração e diferem da mesma pequena maneira. Comparámos rascunhos antigos com o fecho tal como está definido hoje. E o início do período é a data em que a instrução foi escrita, não a data em que entrou em uso. Isto mostra, portanto, uma configuração a desviar-se. Não é uma taxa geral de quantas vezes um modelo ignora uma instrução.[1]
Na noite de 20 de setembro, o fecho passou a ser uma verificação. Um rascunho sem o fecho certo é recusado. Desde então, a verificação recusou 46 vezes: 44 porque faltava o fecho e duas porque era diferente.
Estas 46 recusas não se podem comparar com os 178 rascunhos. Uma recusa é um evento, e o mesmo rascunho pode ser recusado várias vezes. As duas contagens medem coisas diferentes em períodos diferentes.
O que foi recusado.
O SYNC escreve por dois percursos. No primeiro, foram registadas 527 recusas entre 7 e 29 de setembro. A tabela ordena-as pelo motivo da recusa.
| O que a verificação recusou | Recusas | 1.ª vez |
|---|---|---|
| O texto não tem parágrafos | 86 | 11 set. |
| A mensagem indica a sua fonte, ou diz que alguém foi ver | 65 | 7 set. |
| Um número sobre o remetente que a própria descrição do remetente não contém | 63 | 9 set. |
| A pergunta final pede uma hora ou um formato que as regras de escrita não permitem | 60 | 7 set. |
| Falta o fecho | 44 | 20 set. |
| Um seguimento repete a mensagem anterior depois da abertura | 42 | 9 set. |
| Frases que repetem um email já enviado | 39 | 7 set. |
| O rascunho voltou com uma parte em falta | 25 | 11 set. |
| Uma data que a pesquisa sobre a conta não sustenta | 24 | 11 set. |
| Uma primeira palavra que as regras de escrita proíbem | 22 | 9 set. |
| Não foi possível ler a resposta como rascunho | 20 | 7 set. |
| O mesmo argumento de mensagens recentes a outras contas | 11 | 20 set. |
| A mensagem dá lições ao leitor | 8 | 9 set. |
| Uma expressão que as regras de escrita proíbem | 7 | 21 set. |
| A mensagem alterna entre tratamento formal e informal | 5 | 25 set. |
| O fecho é diferente do definido | 2 | 23 set. |
| Outros | 4 | várias |
Isto não é uma classificação dos erros do modelo. As verificações foram sendo acrescentadas semana a semana, como mostra a última coluna. Uma verificação que existe há três semanas teve mais tempo para recusar do que uma que existe há quatro dias. Um erro para o qual não existe verificação não aparece de todo.
O segundo percurso regista cada tentativa de escrita, a partir de 21 de agosto. Mostra para onde vai o esforço.
| Segundo percurso de escrita | Número |
|---|---|
| Tentativas de escrever um rascunho | 221 |
| Rascunhos aceites | 54 |
| Tentativas que falharam uma verificação | 133 |
| Destas, travadas primeiro pela verificação do formato | 122 |
| Destas, travadas primeiro por uma verificação de estilo | 11 |
| Tentativas em que a ligação falhou | 34 |
Pelas nossas contas, são cerca de quatro tentativas por cada rascunho aceite. A maior parte das falhas não tem nada a ver com o conteúdo. Em 122 das 133 verificações falhadas, o modelo não devolveu a resposta no formato pedido, pelo que não havia rascunho para avaliar.
O que dizem outros estudos.
Não encontrámos nenhum estudo sobre esta questão aplicado a emails de vendas. A investigação mais próxima pergunta se um modelo a quem se pede que sustente as suas afirmações com fontes o faz de facto. Dois estudos mediram-no.
«mesmo os melhores modelos não têm suporte completo de citações em 50% dos casos»
Esse resultado diz respeito a um único conjunto de perguntas de resposta longa. Um segundo estudo verificou quatro motores de pesquisa públicos que respondem em frases completas, com fontes. Concluiu que, em média, «apenas 51,5% das frases geradas estão totalmente sustentadas por citações».[3]
Dar ao modelo o material de origem ajuda. Um estudo concluiu que os modelos que consultam passagens antes de escrever produzem uma linguagem mais factual do que os que não o fazem.[4] Outro concluiu que consultar passagens reduz substancialmente os factos inventados em conversas.[5] Ambos relatam uma redução. Nenhum relata que o problema desapareceu.
O que mudámos no produto.
- 01Uma regra que importa é uma verificação do rascunho acabado. Quando o rascunho viola a regra, o software recusa-o.
- 02Cada recusa fica registada com a regra que a causou. É desse registo que vêm as tabelas deste artigo.
- 03A 20 de setembro, o fecho passou das instruções para uma verificação.
O que pesa contra.
Não conseguimos demonstrar que as verificações melhoraram as mensagens. Contamos recusas, e uma recusa só diz que um padrão coincidiu. Um rascunho recusado podia estar bem aos olhos de uma pessoa, e um rascunho que passou pode continuar a ser fraco.
Uma verificação só pode testar o que um software consegue testar. Parágrafos, um fecho e uma palavra proibida são fáceis. Saber se uma mensagem é relevante para quem a lê, não. As qualidades mais importantes de uma mensagem continuam a ser conselhos, e, pela nossa própria conclusão, os conselhos não se aguentam.
As verificações custam tentativas. No segundo percurso, as 221 tentativas pertencem a 98 execuções, e 44 dessas execuções nunca produziram um rascunho aceite. Cada tentativa recusada custa tempo e dinheiro, e um conjunto de verificações rigoroso pode deixar uma conta sem mensagem.
O nosso exemplo mais claro é estreito. Os números do fecho vêm de muito poucas configurações, e todos os rascunhos diferentes vêm de uma delas. O início do período é aproximado: é a data em que a instrução foi acrescentada, não uma data registada com cada rascunho. Todas as nossas contagens vêm de três espaços de trabalho e de poucas semanas.
Os estudos externos tratam de responder a perguntas e de conversas. Nenhum estudou emails de vendas, e nenhum comparou uma regra escrita com uma regra verificada. Usamo-los como a evidência mais próxima, não como prova.
Contámos as recusas no registo de cada rascunho e do que lhe aconteceu: 527 no primeiro percurso de escrita, de 7 a 29 de setembro, e 133 verificações falhadas no segundo, de 21 de agosto a 29 de setembro. Apresentamos todos os espaços de trabalho em conjunto. Não damos uma taxa de recusa, porque as recusas são eventos e o mesmo rascunho pode ser recusado mais de uma vez.
As categorias da primeira tabela resultam da correspondência de padrões no texto do motivo registado com cada recusa. Para o fecho, analisámos os rascunhos escritos pelo modelo no primeiro percurso de escrita, nos espaços de trabalho que definiram um fecho. Ficaram de fora: os rascunhos do segundo percurso, os rascunhos escritos depois de a verificação começar e os anteriores a 7 de setembro, porque o início do período é aproximado e não sabemos com que instruções foram escritos.
Os números valem para o momento em que foram recolhidos. Medimos de novo no dia da publicação.
- [1]iSyncSO. Decisões sobre rascunhos, recusas por regra e tentativas de escrita, até 29 de setembro de 2026. Medido a 29 de setembro de 2026.medição própriaum pequeno número de espaços de trabalho
- [2]Gao, T., Yen, H., Yu, J. & Chen, D. (2023). Enabling large language models to generate text with citations. arXiv:2305.14627.só o resumolido no arXiv; resposta a perguntas, não email de vendas
- [3]Liu, N. F., Zhang, T. & Liang, P. (2023). Evaluating verifiability in generative search engines. arXiv:2304.09848.só o resumolido no arXiv; quatro motores de pesquisa, não email de vendas
- [4]Lewis, P. et al. (2020). Retrieval-augmented generation for knowledge-intensive NLP tasks. NeurIPS 2020. arXiv:2005.11401.só o resumolido no arXiv
- [5]Shuster, K., Poff, S., Chen, M., Kiela, D. & Weston, J. (2021). Retrieval augmentation reduces hallucination in conversation. arXiv:2104.07567.só o resumolido no arXiv