Um encoder de 17 milhões de parâmetros escolhe a ferramenta certa em 14 ms numa CPU

O último passo de muitos pipelines de LLM parece modesto: escolher uma opção dentro de um conjunto já conhecido. Qual ferramenta chamar, sob qual rótulo classificar uma consulta, para qual rota enviá-la. Normalmente isso é feito com um prompt a um modelo grande, o que é lento, caro e sensível à ordem das opções. Tardelli Ronan Coelho Stekel testou o quão pequeno um encoder pode ser para essa tarefa e lançou em código aberto a família Crivo, com seis modelos entre 17 milhões e 1 bilhão de parâmetros.

Os números principais. Os modelos de 68M e 150M superam o classificador zero-shot DeBERTa-v3 de 435M de parâmetros por 4,9 e 5,9 pontos de precisão em 209 tarefas do System1-Arena, auditadas quanto à sobreposição com dados de treinamento. Em 145 tarefas que os modelos nunca viram durante o treinamento, eles se mantêm no mínimo equivalentes ao DeBERTa. O menor modelo, de 17M, responde a uma consulta em uma mediana de 14 ms com 16 threads de CPU. O classificador DeBERTa, nas mesmas condições, tem mediana de 728 ms.

Ler as opções juntas ou uma a uma?

A segunda questão da pesquisa importa mais para quem projeta sistemas. Um encoder pode receber todas as opções de uma vez (joint) ou avaliar cada opção separadamente, pareada com a consulta (per-option). O autor realizou um estudo com três seeds em um modelo de 32M de parâmetros, usando um recorte de validação de um conjunto de 37 benchmarks.

O esquema per-option vence por 5,8 pontos de habilidade ajustada ao acaso com o mesmo número de passos de otimização. Com custo computacional de treinamento aproximadamente igual, a diferença cai para 2,8 pontos. Dois benchmarks externos confirmam a direção do efeito, mas em tarefas não vistas a diferença não é estatisticamente significativa.

A vantagem não aparece sempre. Ela só surge quando se inicializa a partir de um reranker: sua entrada no formato de par consulta-candidato combina com a forma como o esquema per-option lê as opções. Partindo de um encoder bruto, as duas abordagens são indistinguíveis.

O preço da precisão e o ponto fraco do joint

O per-option exige de 5 a 13 vezes mais passagens pelo encoder. Na latência mediana, isso representa uma perda de no máximo o dobro, mas na latência média já passa de quatro vezes: listas longas de opções pesam na cauda da distribuição. Por isso os modelos joint entraram no lançamento.

O esquema joint tem uma falha medida: embaralhar a ordem das opções muda entre 12% e 23% das respostas. O esquema per-option não tem essa dependência — suas respostas não mudam nada. Para produção, esse é um argumento sério: a ordem das ferramentas em uma lista não deveria influenciar a escolha, mas aqui influencia.

Até 68M de parâmetros, os modelos Crivo lideram sua faixa de tamanho no leaderboard público. A avaliação é feita com testes privados, em sua maioria próximos da distribuição de treinamento, então é um resultado forte para tarefas parecidas com as de treinamento, mas não uma garantia de generalização.

O que está no lançamento

• A família Crivo: seis encoders joint abertos entre 17M e 1 bilhão de parâmetros, coleção no Hugging Face (tardellirs/crivo).
• 68M e 150M: +4,9 e +5,9 pontos de precisão sobre o DeBERTa-v3 (435M, zero-shot) em 209 tarefas do System1-Arena.
• 145 tarefas não vistas: paridade com o DeBERTa-v3 no mínimo.
• 17M: mediana de 14 ms com 16 threads de CPU contra 728 ms do DeBERTa-v3.
• Estudo com 32M: per-option supera joint por 5,8 pontos com passos iguais e 2,8 com cômputo igual, três seeds, 37 benchmarks.
• Custo do per-option: de 5 a 13 vezes mais passagens, até 2 vezes na latência mediana e mais de 4 vezes na latência média.
• Sensibilidade à ordem: entre 12% e 23% das respostas joint mudam ao se embaralhar as opções.
• Código e resultados publicados no repositório crivo-decision-encoders no GitHub.

Onde isso será útil

Para rotear consultas entre modelos, seleção de ferramentas por um agente e classificação em um conjunto fechado de rótulos, esses encoders oferecem uma alternativa barata a chamar um LLM. O modelo de 17M cabe em 14 ms em uma CPU comum, sem GPU, e isso muda a economia: a decisão pode ser tomada em cada passo de um ciclo agêntico, em vez de ser acumulada em uma chamada separada e cara.

As conclusões práticas são estas. Se a estabilidade importa, vale randomizar e tirar a média da ordem das opções, ou usar o esquema per-option aceitando o aumento de latência na cauda. Se você treina seu próprio seletor, comece a partir de um reranker: a partir de um encoder bruto não há ganho em ler as opções uma a uma. Antes de colocar em produção, é preciso testar o modelo nas próprias tarefas: paridade em dados não vistos significa "não pior que o DeBERTa", não superioridade, e as maiores vantagens aparecem onde a distribuição está próxima da de treinamento.