Como impedir que um erro parcial vire conclusão

Exemplo: Uma unidade trocada, uma data mal reconhecida ou duas versões conflitantes podem alterar a resposta inteira. Ao dividir o trabalho, cada parte precisa carregar também suas dúvidas e referências. Na Veredas, Helena quer identificar esses conflitos antes que uma síntese fluente os transforme em aparente certeza.

Não conter esse erro custa uma resposta errada com tom de certeza. Quando o modelo raiz recebe apenas o resultado parcial, sem consultar o documento, dispõe de menos elementos para detectar um erro da subchamada. Exija referências e permita recuperar a evidência original diante de conflito ou decisão de maior impacto, antes de Helena assinar o relatório. Para um cliente com licença de operação em jogo, uma condicionante dada como cumprida sem estar é o pior erro possível do sistema.

Ao terminar, você conhece os caminhos por onde o erro sobe numa execução recursiva, sabe onde pôr cada verificação (na folha, na agregação e no raiz) e decide o que a resposta faz quando as partes discordam. O caso mostra quanto essas proteções custam e quanto seguram, medido com falhas inseridas de propósito numa cópia do acervo.

Por onde o erro sobe numa árvore de chamadas

Leitura errada na folha é o primeiro caminho. Folha: a subchamada que lê um pedaço do material e não chama mais ninguém, como o estagiário que confere um único laudo. Ela devolve um valor curto, e o raiz, que não viu o documento, não tem como saber se o valor bate com o texto. O desenho que poupa o contexto do raiz é o mesmo que o deixa cego para o erro da folha.

Código com defeito é o segundo. O raiz escreve Python, e um defeito produz variável vazia, lista cortada ou contagem errada sem que nada quebre. Com sub-RLMs, o problema se multiplica: no artigo de Zhang, Kraska e Khattab, o Qwen3-Coder caiu no OOLONG de 48,0 na profundidade 1 para 26,0 na profundidade 2, e os autores atribuem a queda a erros de sintaxe que se propagam para os sub-RLMs. No CodeQA, o mesmo modelo acertou mais sem subchamadas (66,0) do que com qualquer profundidade.

Confundir plano com resposta vem em terceiro. Os autores relatam que distinguir a resposta final do pensamento é frágil: às vezes o modelo entrega o plano como se fosse o resultado. No artigo, a execução termina com FINAL ou FINAL_VAR; no DSPy, com SUBMIT; na biblioteca rlms 0.1.3, quando o código grava a resposta em answer["content"] e marca answer["ready"] = True. Quando o modelo chama o encerramento cedo demais, a resposta sai bem formatada e incompleta, e nada no texto avisa que faltou metade da exploração.

Pensar demais é o quarto caminho. A reprodução de Daren Wang, com 20 amostras por condição e execução única, viu o S-NIAH cair de 100% na base para 85% com RLM de profundidade 1 e 70% com profundidade 2 no DeepSeek v3.2. O Kimi K2 foi de 86,6% no OOLONG para 60,0% e 55,0%. O autor descreve colapso de formato e explosão de latência e de tokens quando a profundidade cresce.

Resta o quinto caminho, o teto. Quando a execução para em max_iters, a extração de fallback monta uma resposta com o que houver nas variáveis, e essa resposta não diz que está incompleta. O SRLM, da Apple, acrescenta uma observação incômoda: dentro da janela nativa do modelo, o RLM com recursão muitas vezes degrada em relação à base, e os autores concluem que a recursão em si não é o principal motor do desempenho.

Parte desses caminhos vem de modelos que não foram feitos para o papel. Quando os autores do artigo montaram dados de treino a partir de trajetórias do RLM com Qwen3-Coder-480B, 16% dos turnos usavam FINAL de forma errada e 13% usavam FINAL_VAR errado, e foi preciso uma correção programática antes de treinar. Se um modelo desse porte erra o encerramento nessa proporção, o sistema em produção precisa contar com o erro em vez de torcer contra ele.

A reação instintiva é acrescentar mais uma camada de modelo para revisar. Armadilha comum: subir a profundidade ou pôr um segundo modelo para conferir o resultado final, que também não vê os documentos. O revisor lê a mesma resposta limpa que o raiz produziu e herda a mesma cegueira. A tabela do artigo mostra que profundidade extra não melhora de forma consistente e, no Qwen3-Coder, piora.

Onde verificar e o que fazer quando as partes discordam

Uma regra organiza a contenção: cada nível só aceita do nível de baixo o que puder conferir. Na folha, isso significa devolver o valor junto com o identificador do documento e o trecho literal que o sustenta. Na agregação, significa contar e comparar com código determinístico, sem pedir a um modelo que some. No raiz, significa entregar a resposta com a lista de evidências, que o processo hospedeiro confere antes de liberar.

Contradição é informação, e o sistema não deve resolvê-la sozinho. Quando dois laudos do mesmo ponto de coleta e da mesma data trazem valores incompatíveis, a resposta certa para Helena mostra os dois, com os documentos, e marca a pergunta como “laudos contraditórios”, exatamente o que a pergunta de negócio da Veredas pede. Pedir ao modelo que escolha o valor mais provável transforma uma dúvida verificável num número com cara de fato.

Leitura dupla é a proteção mais cara e deve entrar só onde decide. Se um valor vai definir que uma condicionante está vencida, uma segunda subchamada lê o mesmo trecho com outro pedido, e o código só aceita o valor quando as duas leituras concordam. Aplicada a tudo, a leitura dupla dobraria o custo das subchamadas; aplicada só aos valores decisivos, custa centavos por pergunta.

Menos código livre também reduz a superfície do erro. O λ-RLM troca o código livre por combinadores prontos (dividir, espiar, mapear, filtrar, reduzir) e deixa o modelo só nas folhas; nos modelos abertos testados, venceu o RLM padrão em 29 de 36 comparações. O RLM padrão ainda ganhou no CodeQA com modelos fortes em código, como o Llama 405B, com 62,1% contra 55,7%. Agregar em código fixo, fora das mãos do modelo, segue a mesma ideia em escala menor.

No processo hospedeiro, a conferência da evidência cabe em poucas linhas. Ela não julga se o valor está certo, só se o trecho citado existe no documento indicado. Parece pouco, e segura dois modos de falha de uma vez: a leitura inventada e o plano entregue como resposta, que chega sem evidência nenhuma.

Aprofundamento de implementação. A sequência a seguir requer Python e um ambiente isolado. Você pode acompanhá-la com a equipe responsável: confira os dados de entrada, o limite de acesso e a evidência produzida, mesmo que não execute o código.

Como a Veredas plantou falhas e mediu o que chegava à resposta

Caio voltou à cópia do acervo e inseriu 20 falhas nos documentos-chave das 30 perguntas de cruzamento que Helena tinha separado. Oito laudos ganharam unidade trocada, de microgramas para miligramas por litro. Seis datas de coleta tiveram o ano alterado, imitando erro de reconhecimento de texto. Seis condicionantes ganharam uma segunda versão, com prazo diferente, em outro documento do mesmo processo. Como alguns documentos eram chave de mais de uma pergunta, as 20 falhas atingiam as 30.

Rodadas com a configuração otimizada e as defesas contra instrução plantada, as 30 perguntas deram um resultado ruim. Em 13, a falha chegou à resposta final sem nenhum sinal: a contagem de condicionantes vencidas mudou, ou um par de laudos contraditórios virou um valor só. Em 9, a resposta ficou certa por acaso, porque a falha estava num documento que o raiz não chegou a usar. Em 8, o modelo notou a divergência e a mencionou, cada vez num formato.

Nem a checagem de evidência da rodada anterior ajudou. Ela confere se o trecho existe, e o trecho existia: estava escrito errado no próprio documento. Essa foi a lição que Helena mais repetiu depois. Verificar a citação prova que o sistema leu o que diz ter lido; a correção do documento fica fora do alcance dessa checagem.

Três proteções entraram. A leitura de cada documento passou a devolver valor, unidade, data e trecho literal, e o código de agregação passou a comparar, para cada ponto de coleta, os valores de todas as fontes antes de contar. Diferença de ordem de grandeza entre laudos do mesmo ponto, típica de unidade trocada, prazos diferentes para a mesma condicionante e datas de coleta posteriores ao protocolo do próprio laudo viram a marca de contradição. Os valores que decidem se uma condicionante está vencida passam por leitura dupla.

Com as proteções, a falha chegou calada à resposta em 3 das 30 perguntas. Em 9, a pergunta saiu marcada como contraditória, com os dois documentos lado a lado para Helena. As outras 18 ficaram corretas, sem marca. As três que escaparam eram datas alteradas dentro de um intervalo plausível, que nenhuma regra de código distinguia de uma data verdadeira sem outro documento para comparar.

A marca de revisão mudou o trabalho de Helena. Cada pergunta marcada chega com os trechos lado a lado e um campo para a decisão dela, que volta ao acervo como anotação e passa a valer nas próximas perguntas. Anotação que vale para as perguntas seguintes já é memória, e por isso só entra assinada por quem revisou; o capítulo Governar o agente contínuo mostra os portões que protegem essa memória. Em duas semanas de uso interno, as marcas somaram 11 de cada 100 perguntas, e Helena levava cerca de 4 minutos em cada uma. Ela fez a conta: 4 minutos de revisão custam menos que uma condicionante dada como cumprida no relatório errado.

Quase nada mudou no custo. A comparação entre fontes e a checagem de datas são código, sem token. A leitura dupla disparou em média 4 vezes por pergunta de cruzamento, no GPT-5-mini, a cerca de US$ 0,0032 cada (8 mil tokens a US$ 0,25 e 600 a US$ 2 por milhão): US$ 0,013 por pergunta de cruzamento. Espalhado pelas 120 perguntas, são US$ 0,003 a mais, e a média foi de US$ 0,409 para US$ 0,412.

Rodado o conjunto limpo das 120 perguntas, a acurácia ficou em 93, e quatro respostas certas passaram a sair com marca de revisão por divergências reais do acervo. Eram dois pares de laudos do mesmo ponto de coleta com valores incompatíveis, que ninguém tinha notado em anos de processo. Helena levou os dois pares ao cliente como achado, e o laboratório reemitiu um dos laudos.

Teste falhas representativas do seu acervo e confira se o sistema sinaliza, pede revisão ou interrompe a resposta. Meça quantas falhas passam despercebidas e o custo de detectá-las. Esse resultado ajuda a decidir se melhorar os dados, a validação ou o modelo trará mais valor.