Quando o objetivo é transformar texto não estruturado em JSON confiável, a pergunta não é apenas qual modelo “sabe mais”, mas qual entrega o formato certo com consistência. Um experimento recente colocou frente a frente um Qwen2.5-1.5B-Instruct ajustado com QLoRA e o Claude Opus 5, usando a mesma pipeline de avaliação para medir extração estruturada em um cenário de domínio específico.
Especialização ainda pesa muito
No teste anterior, o modelo menor já havia mostrado resultados animadores: 62% de acurácia de exact match e 97% de field match. Isso é especialmente relevante porque exact match costuma ser um critério mais rígido, enquanto field match avalia se os campos esperados foram preenchidos corretamente, mesmo que haja pequenas diferenças de formatação.
Ao levar a mesma avaliação para um modelo de fronteira, a expectativa natural era ver um salto expressivo de desempenho. Afinal, modelos maiores e mais generalistas geralmente lidam melhor com ambiguidade, contexto amplo e instruções complexas. Porém, em tarefas com estrutura bem definida e vocabulário de domínio, a especialização pode reduzir erros e aumentar a previsibilidade da saída.
O que esse tipo de comparação ensina
Esse experimento reforça um ponto importante para equipes de engenharia e produto: tamanho não é o único diferencial. Em muitos fluxos corporativos, a saída precisa ser padronizada, auditável e fácil de integrar em sistemas downstream. Quando o modelo retorna JSON inconsistente, mesmo que a resposta “pareça correta”, o custo de correção pode superar o benefício de usar um modelo mais potente.
Para extração estruturada, a melhor escolha nem sempre é o maior modelo; muitas vezes, é o modelo treinado para o seu domínio, com regras claras de entrada, saída e validação.
Outro aprendizado é que avaliações bem definidas fazem toda a diferença. Sem uma métrica objetiva, fica fácil confundir boa redação com boa extração. Já uma pipeline robusta permite comparar soluções em igualdade de condições, revelando onde o ajuste fino realmente compensa e onde um frontier model pode justificar seu custo adicional.
Implicações para projetos reais
Na prática, esse tipo de análise ajuda empresas a decidir entre três caminhos: usar um modelo generalista via API, fine-tunar um modelo menor para tarefas específicas ou adotar uma abordagem híbrida. Em cenários com alto volume, exigência de latência menor e necessidade de controle sobre o formato de saída, o ajuste fino costuma ser uma alternativa muito competitiva.
Também vale considerar governança, custo operacional e manutenção. Modelos menores podem ser mais baratos de servir e mais fáceis de adaptar quando a regra de negócio muda. Já modelos maiores podem ser úteis em casos em que a complexidade do texto é alta demais para um modelo compacto resolver sozinho.
Se a sua empresa precisa extrair dados, classificar documentos ou estruturar informações com IA aplicada ao contexto do negócio, vale contar com especialistas para desenhar a solução certa. Na WK, podemos apoiar desde a estratégia até a implementação; fale com nosso time e descubra como levar esse tipo de automação para o seu ambiente.