LLMStructBench: Benchmarking Large Language Model Structured Data Extraction

Resumo Técnico: LLMStructBench

1. O Problema

A extração de informações estruturadas a partir de texto natural é uma necessidade crítica em domínios como recursos humanos, finanças, logística e comércio eletrônico, frequentemente integrada em fluxos de trabalho de ETL (Extract, Transform, Load). Embora os Grandes Modelos de Linguagem (LLMs) sejam amplamente utilizados para essa tarefa, sua confiabilidade em gerar saídas que sejam simultaneamente sintaticamente válidas (JSON correto) e semanticamente precisas (valores corretos) permanece insuficientemente compreendida.

Desafios existentes incluem:

• Modelos de ponta frequentemente falham em gerar JSONs totalmente compatíveis com o esquema (schema-compliant).
• Sistemas downstream dependem de objetos completos e precisos na primeira tentativa.
• Há uma lacuna na avaliação de como estratégias de prompting e o tamanho do modelo afetam a confiabilidade da extração, especialmente para modelos de código aberto que precisam ser implantados localmente devido a restrições de privacidade de dados.

2. Metodologia

A. Dataset e Cenários (LLLMStructBench)
Os autores criaram um conjunto de dados aberto e verificado manualmente, composto por 995 amostras distribuídas em 5 casos de uso realistas inspirados em fluxos de trabalho baseados em e-mail:

1. Tickets de suporte (IT).
2. Solicitações de licença médica.
3. Extensão de projetos.
4. Registro em conferências.
5. Solicitações de empréstimo de equipamentos.

O dataset varia em complexidade estrutural, indo de pares chave-valor simples até estruturas aninhadas profundas com arrays de objetos. Cada caso de uso possui um esquema JSON pré-definido, exemplos de entrada/saída e mensagens de texto natural geradas sinteticamente (e depois verificadas) para garantir que a informação no texto corresponda exatamente ao Ground Truth (GT) JSON.

B. Modelos Avaliados
O estudo focou em 22 modelos de código aberto de cinco famílias principais (Qwen3, Phi, Gemma3, Deepseek-R1, Llama3), variando de 0,6B a 70B parâmetros. O modelo proprietário GPT-4o foi incluído apenas como referência de limite superior (upper-bound), não sendo comparado diretamente nas análises de escala devido à falta de transparência de seus parâmetros.

C. Estratégias de Prompting
Foram testadas 5 configurações de prompting para avaliar o impacto da instrução e da restrição de formato na geração de JSON:

• J: Apenas o parâmetro de formato da API definido como "json".
• P: Instrução explícita no prompt para retornar JSON, sem esquema.
• PJ: Instrução explícita + inclusão de um exemplo de objeto JSON.
• J+: Parâmetro de formato da API definido com o esquema JSON completo.
• PJ+: Parâmetro de formato da API (esquema) + instrução explícita + exemplo de objeto.

D. Métricas de Avaliação
Os autores propuseram métricas compostas para capturar tanto a precisão token a token quanto a validade do documento:

1. $F1_{micro}$ (Precisão Token-level): Avalia a correção de pares chave-valor, penalizando chaves ausentes, valores errados e tipos incorretos, com crédito parcial para correspondências aproximadas (ex: distância de Levenshtein).
2. $DOC_{micro}$ (Validade Documental): Mede a porcentagem de gerações que são JSONs perfeitamente válidos e parseáveis, penalizando falhas catastróficas (JSON quebrado, saída vazia).
3. Score Composto: Uma média ponderada ($Score = 0.5 \times F1_{micro} + 0.5 \times DOC_{micro}$) para classificar os modelos.

3. Principais Contribuições

1. LLMStructBench: Um dataset aberto e rigorosamente verificado para avaliação de extração estruturada, cobrindo cenários complexos e variados.
2. Novas Métricas: Introdução de uma abordagem de avaliação dual que separa a validade sintática ($DOC_{micro}$) da precisão semântica ($F1_{micro}$), permitindo identificar se um modelo falha em criar a estrutura ou em preencher os dados corretamente.
3. Análise de Prompting vs. Escala: Uma avaliação sistemática de 22 modelos, demonstrando que a estratégia de prompting é frequentemente mais determinante para a validade estrutural do que o tamanho do modelo.

4. Resultados Chave

• Importância do Prompting: A escolha da estratégia de prompting é mais crítica do que o tamanho do modelo.
  • A estratégia PJ+ (esquema via API + instrução + exemplo) garantiu a maior validade estrutural ($DOC_{micro}$), eliminando quase totalmente erros de sintaxe e chaves ausentes (MK), mesmo em modelos pequenos.
  • A estratégia P (apenas instrução textual) muitas vezes resultou em falhas de parseamento, especialmente em modelos menores ou menos robustos (ex: família Phi).
• Compensação Estrutura vs. Semântica:
  • Estratégias que forçam a estrutura (como PJ+) garantem que o JSON seja válido, mas podem aumentar os erros semânticos (valores incorretos ou "WV" - Wrong Value). O modelo preenche a estrutura corretamente, mas com dados errados.
  • Estratégias mais flexíveis (como P) podem ter melhor precisão de valor em alguns casos, mas falham frequentemente em gerar um JSON parseável.
• Impacto do Tamanho do Modelo:
  • O aumento do tamanho do modelo melhora consistentemente a precisão semântica ($F1_{micro}$), mas tem um impacto variável na validade documental ($DOC_{micro}$).
  • Modelos menores bem ajustados (ex: Gemma3-12B e Qwen3-1.7B) superaram modelos muito maiores (70B) em pontuação composta quando combinados com a estratégia de prompting adequada.
  • Não há uma relação monotônica estrita entre o número de parâmetros e o desempenho final; a qualidade dos dados de pré-treinamento e o ajuste de instruções são fatores decisivos.
• Tipos de Erro:
  • MK (Chave Ausente): Desaparece em modelos de escala média (>7B) quando usados com prompts estruturados.
  • WV (Valor Errado): Tornou-se o principal gargalo. Mesmo os melhores modelos (incluindo GPT-4o e Gemma3-27B) cometem erros de valor em cerca de 96-98% das gerações imperfeitas. Isso sugere que a fidelidade dos valores é um problema mais difícil de resolver do que a estrutura sintática.

5. Significado e Conclusão

O trabalho demonstra que para aplicações práticas de ETL e extração de informações:

1. Modelos Abertos são Competitivos: Modelos de código aberto (como Gemma3-27B) alcançam desempenho comparável ao GPT-4o em tarefas de extração estruturada quando configurados corretamente.
2. Estratégia > Escala: Para garantir que o sistema não quebre (JSON inválido), a estratégia de prompting (especificamente o uso de esquemas via API e exemplos) é mais importante do que simplesmente usar um modelo maior.
3. Validação Semântica é Necessária: Como os erros de valor (WV) persistem mesmo nos melhores modelos e configurações, sistemas de produção não podem confiar apenas na geração do LLM. É necessária uma camada de validação semântica pós-geração ou fine-tuning específico para corrigir valores incorretos.

Em suma, o LLMStructBench fornece uma base para pesquisadores e praticantes otimizarem a confiabilidade da extração de dados, mostrando que a engenharia de prompts e a seleção de modelos devem ser feitas em conjunto, considerando o equilíbrio entre validade estrutural e precisão de conteúdo.