De 6,75% Para 99,8%: O Que Verificação Com Restrições de Tipo Entrega

Qwen 3.5 consegue chamar funções corretamente na primeira tentativa em 6,75% dos casos.

Esse número deveria encerrar qualquer conversa sobre colocar chamadas de função de LLMs em produção sem verificação. Mas não encerra a conversa sobre chamadas de função em si. Porque com um harness de restrições de tipo envolvendo o mesmo modelo, esse número vira 99,8%.

Não é um modelo diferente. Não é fine-tuning. Não é uma janela de contexto maior. É um compilador.

Já documentamos a oscilação de 42% para 78% causada por diferenças de harness em tarefas gerais de programação. Já demos nome à disciplina e traçamos sua linhagem. Este artigo estende ambos com uma afirmação específica e mensurável: para chamadas de função, o custo do harness é negativo. A camada de verificação custa menos do que as falhas que ela previne.

Os Dados do AutoBe

Jeongho Nam e a equipe da Wrtn Technologies rodaram cinco modelos Qwen em um benchmark de chamadas de função. Os resultados de base são brutais. Qwen 3.5 com 6,75% de sucesso na primeira tentativa. Os outros modelos não foram muito melhores.

A solução não foi prompt engineering. Não foram exemplos few-shot. Foi um sistema de tipos TypeScript que funciona simultaneamente como definição de schema, validador em tempo de execução e prompt estruturado.

O tipo é o schema. O tipo é o validador. O tipo é o prompt. Um artefato, três funções.

Quando o LLM gera uma chamada de função, o harness compila contra o schema de tipos. Se falha na compilação, a mensagem de erro volta ao modelo como feedback estruturado. O modelo tenta de novo com a saída do compilador como contexto. Esse ciclo roda até a chamada compilar ou um limite de tentativas ser atingido.

O resultado nos cinco modelos Qwen: 99,8%+ de sucesso.

Isso não é uma melhoria incremental. É uma mudança de categoria. O modelo passou de inutilizável para pronto para produção sem nenhuma alteração nos seus pesos.

Por Que Isso Funciona Melhor Que Prompt Engineering

O instinto quando chamadas de função falham é adicionar mais instruções. Mais exemplos. System prompts mais longos. Descrições detalhadas de parâmetros. Essa abordagem tem um teto, e o teto é baixo.

O NESTFUL, publicado no EMNLP 2025, testou o GPT-4o em chamadas de ferramenta aninhadas. Taxa de sucesso: 28%. O JSONSchemaBench no ICLR 2025 testou modelos de fronteira na geração de JSON schema complexo. Cobertura: 3% a 41%. Esses são os melhores modelos disponíveis, com os melhores prompts que seus criadores conseguiram escrever. As taxas de falha continuam catastróficas para uso em produção.

O motivo é que prompt engineering trata o modelo como o sistema inteiro. Você está pedindo a um gerador probabilístico de texto para produzir saída estruturada deterministicamente correta. Às vezes ele consegue. Na maioria das vezes, não.

Verificação com restrições de tipo trata o modelo como um componente em um pipeline. O modelo propõe. O compilador verifica. Propostas que falham recebem feedback estruturado. O modelo propõe de novo. Cada iteração estreita o espaço de erro porque a saída do compilador é específica: “parâmetro X esperava tipo Y, recebeu tipo Z.”

Compare com uma instrução de prompt: “certifique-se de que todos os parâmetros estão corretamente tipados.” Uma é acionável. A outra é um desejo.

O Padrão Pretext

A análise de Nikola Balic sobre o Pretext, uma ferramenta TypeScript de medição de texto construída por Cheng Lou, revela um princípio complementar: restrições arquiteturais como verificação.

O Pretext separa a computação em duas fases. A função prepare() pode ser custosa. Ela acessa o DOM, mede fontes, faz cálculos de layout. A função layout() deve ser apenas aritmética. Sem acesso ao DOM. Sem efeitos colaterais. Computação pura sobre números.

Isso não é uma sugestão. É imposto pelo sistema de tipos. Se layout() tenta acessar o navegador, o código não compila.

A restrição cria uma camada de verificação invisível em tempo de execução, mas absoluta em tempo de compilação. Você não consegue enviar código que viole a fronteira arquitetural. Os tipos impedem.

A observação de Balic é precisa: “A IA não torna a engenharia rigorosa. O ciclo torna.” O ciclo de restringir-medir-isolar-classificar-testar produz saída confiável independentemente de quem escreve o código, humano ou LLM. O rigor mora no sistema, não no autor.

O princípio é o mesmo do harness de chamadas de função do AutoBe, aplicado a um domínio diferente. Tipos como restrições. Compiladores como validadores. Feedback estruturado como mecanismo de correção.

O Custo do Harness É Negativo

Existe uma crença persistente de que adicionar camadas de verificação desacelera o desenvolvimento. Você precisa escrever os tipos. Precisa construir a integração com o compilador. Precisa tratar o ciclo de feedback. Esse é o “custo do harness,” e times o tratam como overhead.

A matemática não confirma isso.

Com 6,75% de sucesso na primeira tentativa, você precisa de aproximadamente 15 tentativas por chamada bem-sucedida. Cada tentativa consome tokens, adiciona latência, e frequentemente requer revisão humana quando a saída parece plausível mas está sutilmente errada. O custo da falha não é só a retentativa. É a depuração quando uma chamada de função malformada produz um erro três passos adiante no pipeline.

Com 99,8%, você precisa de aproximadamente 1,002 tentativas por chamada. O ciclo de verificação adiciona um passo de compilação e ocasionalmente uma segunda chamada ao modelo. O custo líquido é menor que o da base, não maior.

O custo é negativo. Você gasta menos com verificação do que sem ela. O investimento em tipos, schemas e compiladores retorna mais do que custa na primeira chamada de função, não na centésima.

Isso explica por que as organizações com os harnesses mais sofisticados são também as mais rápidas. Como exploramos em O Que É um Agent Harness?, o harness não é um freio. É a superfície da estrada. Superfície melhor, velocidade maior, menos acidentes.

O Que Isso Significa Para Arquitetura de Agentes

Se você está construindo agentes que chamam funções, APIs ou ferramentas, a evidência aponta para uma recomendação arquitetural específica: coloque um sistema de tipos entre o modelo e o mundo exterior.

Não um validador de regex. Não um verificador de JSON schema que roda após a geração. Um sistema de tipos que participa do ciclo de geração. O modelo gera. O sistema de tipos verifica. Falhas produzem mensagens de erro estruturadas. O modelo regenera com esses erros como contexto.

É assim que ciclos gerador-avaliador se parecem quando o avaliador é um compilador. O padrão não é novo. A aplicação a chamadas de função de LLMs é.

Três princípios de implementação emergem dos dados.

Primeiro, tipos devem ser a única fonte de verdade. Não mantenha definições de schema, regras de validação e descrições de prompt separadas. Derive os três do tipo. Quando o tipo muda, tudo muda. Quando o tipo está correto, tudo está correto.

Segundo, erros de compilador são prompts melhores que instruções em linguagem natural. “Esperava string, recebeu number no parâmetro config.timeout” dá ao modelo mais informação acionável do que “por favor certifique-se de que todos os parâmetros correspondam aos tipos esperados.” Precisão supera eloquência em ciclos de feedback.

Terceiro, o orçamento de retentativas deve ser pequeno. Os dados do AutoBe mostram que a maioria das correções acontece em uma ou duas iterações. Se o modelo não consegue produzir uma chamada válida em três tentativas, tentativas adicionais têm retornos decrescentes. Falhe rápido, escale cedo.

A Implicação Desconfortável

O baseline de 6,75% significa que a maioria das chamadas de função em produção hoje está falhando silenciosamente. Organizações que colocam ferramentas alimentadas por LLMs em produção sem verificação com restrições de tipo estão operando com confiabilidade de um dígito. Algumas dessas falhas são capturadas pelo tratamento de erros downstream. Muitas não são.

A correção é conhecida. A correção é mensurada. A correção funciona em múltiplas famílias de modelos. E a correção custa menos do que o problema que ela resolve.

Construir o harness não é a escolha cara. Pular o harness é.

Fontes

Jeongho Nam / Wrtn Technologies. “Function Calling Harness: From 6.75% to 100%.” Março 2026.
Nikola Balic. “What Pretext Reinforced About AI Loops.” Março 2026.
NESTFUL Benchmark. “Nested Tool Calling Evaluation.” EMNLP 2025.
JSONSchemaBench. “JSON Schema Generation Coverage.” ICLR 2025.

Victorino Group constrói as camadas de verificação e governança que transformam saída probabilística de modelos em confiabilidade de produção: contato@victorino.com.br | www.victorino.com.br