Resumo Técnico: Atribuição de Ganhos de Saída Estruturada em Chamada de Função

1. Definição do Problema

Intervenções baseadas em prompts, particularmente a injeção de habilidades derivadas de trajetórias, frequentemente melhoram as pontuações de modelos de linguagem de grande escala (LLMs) em benchmarks de chamada de função (function-calling), como o Berkeley Function Calling Leaderboard (BFCL) e o API-Bank. No entanto, um aumento bruto na pontuação não distingue entre dois mecanismos distintos:

1. Transferência Procedural: O modelo realmente aprendeu um procedimento reutilizável para selecionar as ferramentas e os argumentos corretos.
2. Alinhamento de Interface: O modelo meramente aprendeu a conformar-se ao formato de saída específico (ex: chaves de encapsulamento JSON, sintaxe de esquema) preferido pelo avaliador.

As práticas de avaliação atuais frequentemente confundem esses mecanismos. Um prompt de habilidade pode melhorar as pontuações simplesmente ao instruir o modelo a usar uma chave JSON específica (ex: "name" em vez de "function") que o pontuador aceita, mesmo que a seleção da ferramenta subjacente permaneça inalterada ou degrade. Por outro outro lado, chamadas semanticamente corretas podem ser penalizadas por desvios menores de formatação. O artigo argumenta que, sem atribuir os ganhos às suas causas específicas, as afirmações de "habilidade agêntica transferível" são injustificadas.

2. Metodologia: O Protocolo de Atribuição de Quatro Camadas

Os autores propõem um protocolo rigoroso de quatro camadas para auditar os ganhos de habilidades precedidas por prompts. Este protocolo vai além da simples comparação de pontuação para isolar a fonte da melhoria.

Camada 1: Recalibração Canônica (Canonicalized Rescoring)

Os autores introduzem a recalibração canônica para separar o "aliasing de chave de wrapper" da mudança real de política de tarefa.

• Mecanismo: A pontuação padrão do BFCL trata chaves JSON específicas (ex: "name") como corretas e outras (ex: "function", "function_name") como erros, mesmo que os argumentos sejam idênticos. O protocolo normaliza essas chaves para uma forma canônica antes de avaliar a precisão da Árvore de Sintaxe Abstrata (AST).
• Objetivo: Determinar se um ganho é apenas o resultado do modelo mudar para o alias de chave "correto", em vez de selecionar a ferramenta correta.

Camada 2: Controles de Formato-Apenas (Format-Only Controls)

Esta camada testa se um contrato de interface explícito sozinho pode reproduzir os ganhos observados.

• Mecanismo: Os autores comparam "Habilidades Completas" (contendo tanto instruções procedurais quanto restrições de formato) contra prompts de "Formato-Apenas" (contendo apenas o esquema JSON esperado/instruções de wrapper, destituídos da lógica da tarefa).
• Objetivo: Se um prompt de formato-apenas igualar ou exceder o desempenho de um prompt de habilidade completa, o ganho é atribuído ao alinhamento de interface, não ao aprendizado procedural.

Camada 3: Indução Reparada e Balanceada

Esta camada investiga se os ganhos são artefatos do pipeline de extração (ex: seleção de demonstração enviesada ou estilos específicos de extrator).

• Mecanismo:
  • Extração Reparada: As habilidades são reextraídas usando uma família de modelos diferente (Qwen3-32B) e um pool balanceado de demonstrações de alta/baixa pontuação, em vez da extração original do GPT-4o baseada apenas em alta pontuação.
  • Indução Balanceada: O protocolo testa se os ganhos persistem quando o pool de demonstrações é balanceado, removendo o viés em direção a exemplos conformes ao formato.
• Objetivo: Determinar se a "habilidade" é robusta ou se os ganhos originais foram impulsionados por vieses de demonstração específicos e não generalizáveis.

Camada 4: Verificações de Portabilidade

Esta camada testa a generalização dos ganhos através de diferentes contextos.

• Mecanismo:
  • Cross-Family (Entre Famílias): Testar habilidades extraídas de uma família de modelos (ex: Qwen) em outras (ex: Llama, Gemma).
  • Cross-Benchmark (Entre Benchmarks): Testar no API-Bank (usando sintaxe de colchetes) e em benchmarks de raciocínio (MATH-500, MultiHop-RAG).
  • Controles Genéricos: Comparar habilidades extraídas contra prompts procedurais genéricos de mesmo comprimento.
• Objetivo: Verificar se os ganhos restantes representam um procedimento transferível ou se são específicos do modelo de origem e do contrato.

3. Resultados Principais

A aplicação deste protocolo ao BFCL e API-Bank em 8 modelos Qwen3 (0.6B–235B) e outras famílias produz várias descobertas contraintuitivas:

• O Alinhamento de Interface Domina: Em muitos casos, prompts de formato-apenas igualam ou excedem os prompts de habilidade completa. Por exemplo, no Qwen3-8B, um prompt de formato-appenas gerou um ganho de 21,3 pontos percentuais (pp), superando o ganho de +11,3 pp da habilidade@235B completa. Isso sugere que a "habilidade" estava principalmente ensinando o modelo como encapsular a saída, não como resolver a tarefa.
• A Recalibração Revela Sensibilidade: A pontuação padrão mostrou grandes ganhos e danos. Após a recalibração canônica, várias células "prejudiciais" tornaram-se neutras, e os ganhos positivos diminuíram significativamente. Por exemplo, o ganho da habilidade@235B do modelo 14B caiu de -11,7 pp para -1,0 pp sob recalibração, indicando que o dano original era amplamente devido à sensibilidade de alias de chave.
• Sensibilidade de Indução: Os maiores ganhos observados (ex: +17,7 pp para 1.7B, +11,3 pp para 8B) desapareceram ou inverteram-se quando utilizando indução reparada/balanceada. Quando a extração foi realizada a partir de um pool balanceado de demonstrações em vez de demonstrações de alta pontuação, os ganhos desapareceram, sugerindo que as melhorias originais foram impulsionadas pelo viés de demonstração, e não por uma extração de habilidade robusta.
• Prompts Genéricos Reproduzem Ganhos: No API-Bank, prompts procedurais genéricos de mesmo comprimento quase reproduziram os ganhos das habilidades extraídas (dentro de 0,5 pp), indicando ainda mais que a redação específica da "habilidade" não era o principal motor do desempenho.
• Falha Cross-Family: Habilidades extraídas do Qwen3 frequentemente falharam ou degradaram o desempenho quando aplicadas aos modelos Llama ou Gemma, enquanto os sinais de formato-apenas às vezes funcionavam melhor. Essa falta de portabilidade mina as alegações de transferência procedural universal.

4. Contribuições

O artigo apresenta três contribuições principais:

1. Formulação: Enquadra a atribuição de ganho de habilidade em chamada de função como um problema de relatório, distinguindo mudanças de política de tarefa e alinhamento de interface em auditorias de saída estruturada.
2. Protocolo: Propõe e instacia um protocolo de atribuição de quatro camadas (recalibração canônica, controles de formato-apenas, extração robusta de indução e verificações de portabilidade) para avaliar rigorosamente a injeção de habilidades.
3. Descobertas Empíricas: Demonstra que, em configurações do tipo BFCL/API-Bank, muitos ganhos aparentes são melhor atribuídos ao alinhamento de interface do que à transferência procedural robusta. O trabalho libera o BFCL-CANONICAL (um conjunto de dados/métricas) e uma receita prática de relatório para futuras afirmações.

5. Significância e Alegações

O artigo não alega que a conformidade de formato seja irrelevante; em vez disso, argumenta que a conformidade de formato é uma capacidade de engenharia distinta do raciocínio procedural.

• Clarificação de Métricas: Os autores afirmam que uma pontuação de saída estruturada sozinha não pode certificar que um modelo aprendeu um procedimento transferível. Uma melhoria na pontuação pode simplesmente refletir que o modelo aprendeu a "falar a língua do avaliador".
• Padrões de Relatório: O artigo recomenda que futuras alegações de "habilidade transferível" devem sobreviver ao protocolo de quatro camadas. Se um ganho desaparece sob recalibração, controles de formato-apenas ou indução balanceada, ele deve ser reportado como alinhamento de interface ou adaptação de contrato de prompt, e não como uma habilidade agêntica reutilizável.
• Diagnóstico Construtivo: As descobertas são apresentadas como um diagnóstico construtivo para o campo. Ao separar o alinhamento de interface da transferência procedural, pesquisadores podem entender melhor o que seus benchmarks medem e evitar superestimar as capacidades de métodos de injeção de habilidade.

Os autores concluem que, embora o alinhamento de interface seja valioso para implantação, atribuir ganhos à transferência procedural sem passar por esses testes rigorosos é um erro de atribuição. O protocolo preserva o valor de engenharia do alinhamento de formato enquanto reserva a afirmação mais forte de transferência procedural apenas para a evidência residual que sobrevive a todos os controles.