Confiabilidade de LLMs começa no contrato, não na troca de modelo

Aditya Mulik relata no InfoQ que um sistema de recomendações de estoque passou de aproximadamente 15% para 1,5% de respostas classificadas como alucinações ao longo de seis meses.[3] A principal intervenção descrita não foi trocar o modelo-base, mas organizar a infraestrutura ao redor dele.[3] O indicador inclui falhas de formato ou schema e de fundamentação nas fontes.[3]

Esse último detalhe impede uma leitura apressada: não se trata de uma medida independente de alucinação factual.[3] A história é mais útil como exemplo de desenho operacional do que como promessa de redução de erros para qualquer aplicação.

O que muda para quem desenvolve

A proposta centraliza validação de saída, classificação de falhas, retentativas, versões de instruções, custos e autorização.[3] Cada chamada declara um schema Pydantic, validado antes de o resultado chegar ao consumidor.[3]

Minha leitura é que essa camada deve ser tratada como uma fronteira de integração. O consumidor não deveria precisar adivinhar se recebeu uma resposta utilizável, uma recusa ou um objeto incompleto. Isso vale especialmente quando a saída alimenta outra operação, em vez de terminar numa janela de conversa.

O artigo separa violação de schema, ausência de fundamento ou desvio de intenção e falha de infraestrutura.[3] No exemplo de validação, são permitidas até três tentativas, com erro explícito quando o contrato não é cumprido.[3] Não há motivo para tratar essas categorias como o mesmo problema: repetir uma chamada sem mudar a evidência não é uma estratégia de fundamentação.

Outro ponto importante é a autorização nos próprios servidores MCP, que verificam token e papel antes de executar ferramentas.[3] Como decisão de engenharia, prefiro essa fronteira a uma instrução textual dizendo ao agente para “não acessar produção”. Uma intenção de comportamento não substitui uma barreira técnica.

Como aplicar

Escolha uma tarefa pequena, como responder perguntas sobre uma documentação aprovada. Defina uma saída com resposta, referências e estado: respondido, sem evidência ou fora de escopo. O estado deve permitir que o consumidor tome uma decisão sem interpretar prosa livre.

Monte um experimento com três casos controlados:

1. Uma pergunta cuja resposta existe na documentação. Verifique se a referência sustenta a afirmação.
2. Uma pergunta cuja informação não está disponível. Espere uma recusa explícita, não uma resposta provável.
3. Uma solicitação de ferramenta sem autorização. Confirme que a ferramenta nega a operação mesmo quando o agente tenta executá-la.

Registre versão da instrução, fontes recuperadas, resultado de validação, tentativas e consumo de cada chamada. Compare mudanças com os mesmos casos. Defina previamente um limite de tempo e de gasto por execução e uma resposta terminal para quando o limite for atingido.

Na promoção de uma nova instrução, mantenha a versão anterior recuperável. O objetivo não é construir uma plataforma completa antes do primeiro usuário, mas deixar o comportamento auditável e reversível.

Cuidados e limites

JSON válido não torna uma afirmação verdadeira. Um campo no qual o modelo declara estar fundamentado também não prova que a fonte sustenta a resposta. Verificação estrutural e avaliação de conteúdo precisam continuar separadas.

O registro de instruções em memória apresentado no exemplo não é considerado adequado à produção pelo autor.[3] Há persistência, isolamento entre ambientes e operação a resolver. Copiar a demonstração pode acelerar um piloto; copiar suas simplificações como arquitetura definitiva é outra decisão.

Fonte

[3] Fonte: InfoQ, artigo de Aditya Mulik