Classificação de NCM: motor por tokens com LLM só na dúvida

Auditar nota fiscal significa conferir, item a item, se o código NCM declarado corresponde ao produto descrito. Um escritório de contabilidade de porte médio processa dezenas de milhares desses itens por mês.

A solução ingênua é chamar um modelo de linguagem para cada item. Funciona, e a conta explode: o custo cresce linearmente com o volume, e volume é exatamente a razão de o problema existir. Pior — a resposta do modelo é difícil de auditar depois, e auditoria é o produto.

O padrão: caminho comum barato, exceção cara

O que construímos inverte a ordem. Cada item passa primeiro por um classificador determinístico que roda dentro do banco de dados, comparando os tokens da descrição do produto com a base de descrições oficiais de NCM. Esse classificador devolve duas coisas: uma sugestão e uma medida de confiança.

Quando a confiança está acima do limite, a resposta é aceita e nenhum modelo é chamado. Quando está abaixo, e só nesse caso, o item vai para um modelo de linguagem.

item da nota
     ↓
classificador por tokens (Postgres)
     ↓
confiança ≥ limite ?
     ├── sim → resposta aceita        ← caminho comum, custo zero
     └── não → modelo de linguagem    ← exceção, custo por chamada
                     ↓
            resposta realimenta a base

Na prática, a esmagadora maioria dos itens de um escritório se repete mês a mês. Depois das primeiras rodadas, o caminho comum absorve quase tudo e o modelo é acionado apenas no que é genuinamente novo ou mal descrito.

O ganho que não é o óbvio

A economia de custo é real, mas não é o benefício principal. O principal é a auditabilidade.

Quando a classificação vem do motor determinístico, dá para mostrar ao contador exatamente por que aquele NCM foi sugerido: quais tokens casaram, com qual entrada da base, com qual pontuação. Isso é defensável numa fiscalização. "O modelo classificou assim" não é.

O caminho comum ser determinístico não é economia de dinheiro. É economia de explicação.

A base que se alimenta sozinha

Quando o modelo é acionado e o resultado é confirmado por revisão humana, aquele par descrição-NCM volta para a base de tokens. O classificador determinístico fica melhor com o uso, e a proporção de chamadas ao modelo cai com o tempo.

Vale registrar o que decidimos não usar: não há banco vetorial nem embeddings nessa etapa. Descrição de produto em nota fiscal é curta, cheia de abreviação e de código interno — terreno em que busca literal por token bate busca semântica com folga, e sem a infraestrutura extra.

Como escolher o limite de confiança

É a única decisão realmente delicada do desenho, e ela não é técnica: é de negócio. Limite muito baixo aceita classificação ruim e mina a confiança no relatório inteiro. Limite muito alto joga volume demais para o modelo e devolve o problema de custo.

O caminho que funcionou foi começar conservador — limite alto, muita coisa indo para o modelo — e baixar aos poucos, medindo a taxa de acerto do classificador contra as revisões humanas. Chutar o limite no início é o que faz esse tipo de sistema nascer desacreditado.

Onde mais esse padrão serve

A forma é geral e vale para praticamente qualquer classificador em produção:

1. 1Resolva o caminho comum com regra determinística, barata e explicável.
2. 2Meça a confiança dessa resposta — sem medida de confiança, não há como decidir quando escalar.
3. 3Chame o modelo caro só quando a confiança for baixa.
4. 4Realimente a base com o que foi confirmado, para o caminho comum crescer.

Triagem de chamado, roteamento de e-mail, categorização de despesa, deduplicação de cadastro: todos têm a mesma característica de cauda longa, em que poucos casos são difíceis e a maioria se repete. Tratar todos como se fossem difíceis é o desperdício mais comum em projeto de IA aplicada.