Um modelo pequeno melhorou 85% na extração. O teste da Microsoft importa porque a fronteira ainda venceu
Com 17 documentos de treinamento, um avaliador em Python e 100 passos de reforço, a Microsoft elevou o F1 de extração do gpt-oss-20b de 0.44 para 0.81, contra 0.98 dos modelos de fronteira.
Ouça este artigo · 5 min
Narração completa do artigo, gerada por IA.
O número de manchete no experimento da Microsoft de 16 de outubro é uma melhora de 85%. O número mais útil é o que a Microsoft colocou logo ao lado: depois do treinamento, o modelo pequeno ainda cometia várias vezes mais erros de extração que os modelos de fronteira que deveria substituir. Um post de fornecedor que mostra onde a própria abordagem fica aquém merece leitura atenta.
O experimento
A tarefa é extração estruturada de documentos como notas fiscais: encontrar os valores certos, mapeá-los para os campos de um JSON Schema, manter cada registro repetido (uma nota fiscal de validação tinha 37 itens de linha) e retornar JSON válido que o próximo sistema possa usar. O avaliador compara pares campo e valor normalizados com a resposta esperada, e o F1 combina precisão (quantos pares extraídos estão certos) com recall (quantos pares esperados foram encontrados).
Na linha de base, os dois modelos open-weight tiveram dificuldades de formas diferentes. gpt-oss-20b recusou a tarefa ou usou linguagem de desculpa em 25% das respostas, retornou JSON analisável em 63.8% das vezes e cobriu 47.1% dos campos esperados. gpt-oss-120b produziu JSON válido em 96.3% das vezes, mas ainda perdia campos: saída analisável não é saída completa.
A equipe então usou o Foundry Interactive Training, em preview pública, com 17 documentos de treinamento, suas respostas esperadas e um avaliador em Python. O modelo gerou oito respostas candidatas por documento, o avaliador deu crédito parcial para valores corretos e penalizou JSON inválido, e 100 passos de group relative policy optimization (GRPO) reforçaram as melhores respostas. As respostas esperadas foram usadas apenas para avaliação, nunca mostradas ao modelo.
| F1 antes | F1 após treinamento | Preço por 1M de tokens (entrada / saída) | |
|---|---|---|---|
| gpt-oss-20b | 0.4379 | 0.8115 | $0.07 / $0.30 (com fine-tuning, regional) |
| gpt-oss-120b | 0.6816 | 0.8573 | $0.15 / $0.60 (tarifa base) |
| GPT-6-sol | 0.9764 | Referência, não treinado | $2.00 / $10.00 |
| GPT-5.6-sol | 0.9766 | Referência, não treinado | $4.00 / $20.00 |
| GPT-5.5 | 0.9760 | Referência, não treinado | $5.00 / $30.00 |
O que melhorou
O modelo 20B foi de 0.4379 para 0.8115 de F1, o ganho relativo de 85.3% no título. O modelo 120B alcançou a pontuação mais alta, 0.8573. Uma segunda rodada de treinamento com uma seed diferente chegou a 0.8101, perto da primeira. O comportamento mudou tanto quanto a pontuação: a linguagem de recusa caiu para zero, o JSON válido subiu para 98.8% e a cobertura para 94.9%.
Duas ressalvas do próprio post. A avaliação usou 20 documentos, o que basta para ver uma direção e não basta para definir um orçamento de erro. E os modelos de fronteira foram medidos com um protocolo diferente, então a comparação é indicativa.
Como ler o trade-off
Com preços de entrada de $0.07 contra $2.00 por milhão de tokens, o modelo 20B com fine-tuning é cerca de 29 vezes mais barato por token que a referência de fronteira mais barata. Com F1 de 0.81 contra 0.98, ele erra ou deixa de encontrar cerca de um par campo-valor em cada cinco, contra cerca de um em cada quarenta. Se esse trade-off é bom depende inteiramente do que custa um erro depois do modelo: os minutos de um revisor, um pagamento rejeitado, uma carta ao cliente com o valor errado.
É por isso que “modelo mais barato” é o enquadramento errado. Um time que considera esse caminho deve comparar o custo por documento correto, incluindo as verificações humanas ou automatizadas que capturam os erros extras, não o preço por token. A Microsoft faz o mesmo ponto: sua tabela de preços “não é uma análise completa de custo total de propriedade”.
Há também caminhos intermediários. A validade de JSON quase perfeita do modelo com fine-tuning o torna uma primeira passagem previsível. Um pipeline pode aceitar campos que passam em validação determinística (totais que batem, datas que fazem parsing, IDs que existem nos dados mestres) e enviar apenas os documentos com falha para um modelo de fronteira ou uma pessoa, a lógica de roteamento que descrevemos em gerenciar modelos como um portfólio.
O ativo reutilizável é o avaliador automático
A parte mais transferível da receita não é o modelo. É o avaliador automático: um trecho de código que define o que é uma extração correta para o seu schema e atribui crédito parcial. Ele orienta o treinamento, mede a linha de base e continua medindo após o deploy. O conselho da própria Microsoft é medir primeiro e tentar mudanças mais simples, como prompting, antes do treinamento, depois reservar um conjunto de teste intocado com novas fontes e layouts de documento para a checagem final.
Para extração regulada, como sinistros, notas fiscais sujeitas a auditoria ou registros clínicos, o avaliador também vira evidência: uma definição documentada e versionada de “correto” que um revisor pode inspecionar. Um time que o escreve tem algo valioso, quer ele acabe fazendo fine-tuning de um modelo pequeno, quer pagando por um grande.