Resumo Técnico: Geração de JSON com Autocorreção em Pequenos Modelos de Linguagem

Declaração do Problema

Pequenos modelos de linguagem (SLMs) oferecem uma alternativa de baixo custo e preservação de privacidade para a extração de informações estruturadas, particularmente para aplicações em dispositivos locais. No entanto, seus outputs frequentemente falham em atender aos requisitos rigorosos de validação de JSON Schema. Essas falhas manifestam-se como sintaxe impossível de processar (ex: falta de colchetes, aspas incorretas) ou não conformidade semântica (ex: tipos de dados errados, campos obrigatórios ausentes).

Embora a decodificação restrita (restringir a geração de tokens a uma gramática) seja uma solução conhecida, ela requer acesso aos logits do modelo, o que muitas vezes não está disponível em APIs hospedadas ou ambientes de execução embarcados. Além disso, forçar uma geração estrita pode distorcer a distribuição de probabilidade do modelo e degradar o desempenho da tarefa. Consequentemente, há uma necessidade de uma abordagem pós-geração que repare os outputs de JSON sem modificar o decodificador do modelo ou exigir infraestrutura adicional.

Metodologia

O artigo propõe um pipeline de "autocorreção" de três camadas, agnóstico ao modelo, que opera sequencialmente sobre o texto gerado. O processo é projetado para minimizar chamadas adicionais ao modelo enquanto maximiza a validade do esquema.

Camada 1: Reparo Sintático Leniente (L1)

Esta camada opera puramente na string de texto antes do parsing. Ela emprega um lexer tolerante e um parser de pilha de colchetes para lidar com desvios comuns do JSON estrito:

• Remoção de wrappers: Remove cercas de código Markdown (```json) e textos introdutórios.
• Flexibilidade lexical: Aceita aspas simples, aspas tipográficas, comentários (//, /* */) e literais não padronizados (ex: True, None, NaN).
• Reparo estrutural: Utiliza um montador baseado em pilha para inserir vírgulas ausentes, remover vírgulas residuais/duplicadas, fornecer null para chaves seguidas por colchetes de fechamento e fechar contêineres truncados.
• Sinalização: Cada modificação é registrada para categorizar o tipo de erro de sintaxe.

Camada 2: Coerção Guiada pelo Esquema (L2)

Uma vez que o texto é processado em um objeto, a L2 tenta coagir os valores para corresponder ao JSON Schema alvo sem inventar novo conteúdo. As operações incluem:

• Conversão de tipo: Converter strings numéricas (com símbolos de moeda) para números, "sim/não" para booleanos e floats integrais para inteiros.
• Normalização: Correspondência de enum de caso insensível e renomeação de chaves (ex: orderId para order_id).
• Ajustes estruturais: Envolver escalares em arrays, dividir strings separadas por vírgula e remover propriedades proibidas por additionalProperties: false.
• Parsing conservador: Reescrever strings em padrões exigidos (ex: datas, horários de 24 horas) apenas quando o parsing for inequívoco. Crucialmente, a L2 não cria informação ausente, exceto por adicionar null explícito para propriedades anuláveis.

Camada 3: Re-prompting Guiado pelo Validador (L3)

Se o objeto falhar na validação após L1 e L2, o sistema inicia uma tentativa de reprocessamento. As mensagens de erro do validador (caminho do campo e descrição do erro) são anexadas ao prompt, solicitando ao modelo que corrija os problemas específicos. O novo output é então reprocessado através de L1 e L2. Este loop continua até um orçamento de tentativas ($K=2$).

Configuração Experimental

O autor avaliou este pipeline em 120 tarefas de texto-para-JSON em quatro famílias de esquemas (contato, pedido, evento, artigo) usando três SLMs ajustados por instrução:

• SmolLM2-360M
• Qwen2.5-0.5B
• Qwen2.5-1.5B

Seis condições experimentais foram testadas, variando desde o output bruto até o pipeline completo de autocorreção, incluindo um baseline de "tentativa cega" (reamostragem sem feedback) para isolar o valor dos erros do validador.

Resultados Principais

1. Eficácia do Reparo Determinístico

Os ganhos mais significativos foram alcançados sem quaisquer chamadas adicionais ao modelo.

• Validade Bruta: Apenas 16,7% das respostas brutas satisfizeram o esquema.
• Impacto L1 + L2: Aplicar reparo sintático e coerção de esquema elevou a validade para 67,8% em média.
• Variância do Modelo:
  • Qwen2.5-1.5B: Alcançou 99,2% de validade apenas com L1+L2; as tentativas adicionais agregaram valor negligenciável.
  • Qwen2.5-0.5B: A validade saltou de 3,3% (bruto) para 72,5% após L1 (principalmente pela remoção de cercas de código Markdown) e subiu para 83,3% após adicionar L2.
  • SmolLM2-360M: L1 não teve efeito (a validade permaneceu em 9,2%), mas L2 elevou a validade para 20,8%.

2. O Papel do Feedback do Validador (L3)

• Feedback vs. Tentativa Cega: O pipeline completo de autocorreção (L1+L2+L3) alcançou 78,1% de validade com uma média de 1,57 chamadas por tarefa. Isso foi estatisticamente comparável à reamostragem cega (74,4%, $p=0,060$).
• Especificidade do Modelo: O feedback foi altamente eficaz para o SmolLM2-360M, melhorando a validade de 32,5% (tentativa cega) para 46,7% ($p=0,003$). Em contraste, não ofereceu benefício para o Qwen2.5-0.5B, que continuou a envolver os outputs em cercas de código mesmo após o feedback.
• Modos de Falha: O feedback falhou em corrigir "hábitos de formatação" (como cercas de código) que o modelo persistiu em repetir. Foi mais útil para erros semânticos (ex: campos obrigatórios ausentes).

3. Validade Não é Igual a Correção

Uma descoberta crítica é que a validade do esquema não garante a precisão factual.

• Taxa de Erro: Entre os outputs válidos e autocorrigidos, 45,6% continham pelo menos um campo incorreto.
• Erros Comuns:
  • Placeholders Vazios: Os modelos preencheram campos de string obrigatórios com strings vazias ("") para satisfazer as restrições de tipo.
  • Valores Fabricados: Os modelos inventaram dados plausíveis, mas falsos (ex: números de telefone como "123-456-7890").
  • Enums Padrão: Os modelos selecionaram o primeiro valor do enum (ex: "pendente") independentemente do contexto.
• Conclusão: Mesmo com um pipeline perfeito, os pequenos modelos frequentemente alucinam conteúdo para satisfazer as restrições estruturais.

Significância e Contribuições

O artigo apresenta quatro contribuições principais:

1. Um Pipeline Preciso: Define um fluxo de trabalho de autocorreção de três camadas (L1, L2, L3) que é agnóstico ao modelo e não requer acesso aos logits do modelo.
2. Ablação de Camadas Determinísticas: Demonstra que o reparo determinístico (L1 e L2) responde pela maioria dos ganhos de validade (83,3% dos outputs reparados não exigiram chamadas extras), tornando-o o passo mais econômico.
3. Taxonomia de Falhas: Identifica dois regimes de falha distintos:
   • Hábitos de Formatação: Trivial de reparar via código (ex: cercas de código).
   • Incompreensão do Esquema: Difícil de reparar (ex: copiar a estrutura do esquema, tipos errados), muitas vezes exigindo intervenção semântica.
4. Distinção entre Validade e Correção: Fornece evidências de que o feedback do validador pode levar a outputs "válidos, mas errados". O autor argumenta que as avaliações de saída estruturada devem medir a precisão do campo juntamente com a validade do esquema, pois os pequenos modelos podem priorizar passar no validador em detrimento da extração de informações precisas.

Recomendações Práticas

Com base nos achados, o autor sugere:

• Sempre aplicar reparo determinístico e coerção primeiro, pois é gratuito e resolve a maioria dos problemas.
• Usar feedback do validador apenas para modelos onde os erros restantes são semânticos; para erros estocásticos, a reamostragem cega é igualmente eficaz.
• Implementar validação de conteúdo (ex: rejeitar strings vazias para campos obrigatórios) junto com a validação de esquema.
• Projetar esquemas que espelhem a estrutura superficial do texto de origem para minimizar a necessidade de transformações semânticas complexas.