Em Homens de Preto II, o Agente J visita K em um correio aparentemente comum. Ele abre uma máquina de triagem de correspondências e revela um alienígena lá dentro, separando as cartas rapidamente.
É uma ceninha ridícula, mas que também nos dá uma forma útil de pensar sobre IA.
Entre receber algo e fazer alguma coisa com isso, geralmente há uma decisão menor a ser tomada: onde isso se encaixa?
Se você acertar essa decisão logo no início, o resto do sistema pode seguir o caminho adequado.
Tenho pensado naquele pequeno alienígena enquanto desenvolvo software de IA.
Um aplicativo recebe uma dúvida sobre faturamento, um relato de bug, a foto de um produto e um pedido para agendar uma demonstração. Cada um exige um tratamento diferente. Ainda assim, acabamos pedindo ao mesmo modelo de linguagem grande para analisar tudo e descobrir o que acontece em seguida. Nada eficiente nem econômico.
É por isso que acredito que modelos especializados terão um papel muito maior no futuro da IA. Por exemplo: o Jev foi criado para decisões estruturadas nas quais o software pode agir. A Coinbase adaptou o Qwen3.5-9B especificamente para detecção de fraudes em seu serviço Onramp. Cada um foca em uma tarefa definida, com resultados que podem ser medidos.
https://x.com/brian_armstrong/status/2109412046244913643
Estou construindo a camada de triagem
Solicitações conhecidas podem ir direto para um fluxo de trabalho definido. Solicitações que exigem mais raciocínio seguem para outro modelo. As ambíguas são sinalizadas para esclarecimento ou revisão.
A economia potencial vem de dar a cada solicitação exatamente a quantidade de processamento que ela precisa. Depois, precisamos medir se o classificador acerta decisões suficientes para justificar sua existência.
Nosso ponto de partida foi o CludeMem. Estávamos tentando decidir o que uma IA deveria lembrar, o que deveria recuperar e o que estava consumindo tokens desnecessariamente. Uma preferência permanente, uma instrução temporária e uma pergunta não resolvida merecem tratamentos diferentes. Antes de tomar essas decisões, precisávamos classificar a informação.
Isso virou a ideia por trás de uma camada de classificação mais ampla. A mesma etapa poderia ajudar a organizar uma solicitação de suporte, rotear um documento ou escolher qual especialista deve lidar com uma tarefa.
GIF
À medida que surgem mais modelos especializados, os aplicativos precisarão decidir quais entradas merecem sua atenção. É essa parte que estamos construindo: classificar o que chega, tratar casos conhecidos localmente e passar os mais difíceis para o modelo ou processo de revisão adequado.
Apresento o Clude Cat (Cat de categorização 😉)
Antes de armazenar uma memória, recuperar um documento, chamar uma ferramenta ou gerar uma resposta, geralmente há uma decisão sobre com que tipo de informação estamos lidando.
Essas decisões estão em toda parte.
Imagine que alguém escreva para uma empresa de software:
“Onde posso baixar minha fatura?”
Um agente de IA poderia ler a mensagem, inspecionar suas ferramentas, considerar a intenção do cliente e decidir procurar uma fatura.
Um fluxo de trabalho mais direto seria assim:
Mensagem → solicitação de documento de cobrança → verificação de conta → recuperação da fatura.
Um modelo de linguagem ainda poderia escrever a resposta. A decisão inicial de roteamento poderia ser tratada localmente.
Agora mude a mensagem:
“Fui cobrado duas vezes, minha conta está bloqueada e quero cancelar.”
Enviar isso com confiança para um único fluxo de faturas só criaria mais trabalho. Há vários problemas a resolver, e a resposta certa pode exigir esclarecimentos ou uma pessoa real.
O classificador precisa ter permissão para dizer: “Não consigo enquadrar isso com segurança”.
Essa é uma parte essencial do produto. Um sistema que envia solicitações com confiança para o destino errado pode apagar sua vantagem de velocidade com o trabalho necessário para corrigir seus erros.
Para o cliente, o benefício esperado é menos espera e menos repetição.
Para o desenvolvedor, é uma decisão explícita que ele pode inspecionar, testar e alterar. Ele consegue ver a categoria selecionada, a versão do modelo, o tempo de processamento e se o sistema se recusou a tomar uma decisão.
Por baixo dos panos, a implementação em texto começa com um pequeno modelo pré-treinado chamado encoder.
Ele converte uma mensagem em uma lista de números que representam aspectos do seu significado. Os desenvolvedores chamam essa representação de embedding.
“Onde está minha fatura?” e “Preciso de uma cópia da minha conta” usam palavras diferentes. Suas representações numéricas ainda podem ser parecidas o suficiente para o sistema reconhecer o mesmo tipo de solicitação.
Uma camada de classificação usa essas representações para pontuar categorias definidas pelo desenvolvedor.
Implementamos duas abordagens. Uma compara a mensagem recebida com exemplos de cada categoria. A outra aprende as fronteiras entre as categorias a partir de exemplos rotulados.
Na abordagem ajustada (fitted), mantemos o encoder fixo e treinamos uma camada de decisão menor acima dele. Não precisamos treinar um novo modelo de base para cada aplicativo.
O desenvolvedor ainda precisa definir o que as categorias significam e conectá-las a ações úteis. O classificador não pode inventar os departamentos da empresa, a política de reembolso ou as permissões de conta.
Ele também precisa de uma política de aceitação.
A categoria com maior pontuação ainda pode ser uma correspondência ruim. Duas categorias podem estar quase empatadas. Uma solicitação desconhecida pode se parecer com algo familiar.
Nossas pontuações locais atuais não são probabilidades calibradas. Uma pontuação de 0,92 não significa automaticamente “92% de chance de estar correta”.
Temos que testar o que acontece quando essas pontuações controlam as decisões.
Portanto, a saída distingue entre uma categoria aceita, uma solicitação que precisa de revisão e uma falha técnica. Timeouts, cancelamentos e erros de modelo também precisam de um tratamento previsível.
Essa é a engenharia por trás do classificador. Ela determina se outro aplicativo pode usar o resultado de forma segura e consistente.
Fizemos um experimento com 770 solicitações bancárias para ver se essa abordagem poderia reduzir o trabalho do modelo generativo.
A primeira configuração enviava todas as solicitações para um modelo Qwen2.5 7B rodando localmente para classificação.
A segunda usava nosso classificador local primeiro e enviava apenas as solicitações não resolvidas para o Qwen.
Os resultados foram:
- As chamadas ao Qwen caíram de 770 para 227.
- As classificações corretas aumentaram de 535 para 642.
- A precisão em todas as entradas subiu de 69,5% para 83,4%.
- A soma dos tempos de consulta medidos caiu de 299,7 segundos para 87,7 segundos.
A etapa local evitou 543 chamadas ao Qwen, uma redução de 70,5%.
O cache permaneceu ativado, e a abordagem direta rodou antes da combinada. Os números de tempo excluem configuração e aquecimento. Medimos a classificação, sem gerar respostas finais para o cliente ou pagar um provedor de modelo.
Esses números descrevem esta configuração. Eles não estabelecem uma vantagem sobre todos os LLMs nem comprovam economia para o cliente.
Um experimento posterior e separado testou um classificador local ajustado em 24 intenções de viagens e ambiente de trabalho.
De 720 solicitações, ele aceitou 688 localmente. Dessas, 681 estavam corretas e sete erradas. Deixou 32 para revisão.
Isso nos dá duas medições diferentes:
- Cobertura: ele tratou 95,6% das solicitações localmente.
- Precisão das aceitas: ele acertou em 99,0% das decisões que aceitou.
Ambas devem constar no resultado. Um classificador poderia alcançar uma precisão impressionante aceitando apenas um punhado de solicitações fáceis.
Também testamos 100.000 entradas desconhecidas que deveriam ficar fora de suas categorias suportadas. Ele foi preciso em mais de 94% das vezes.
Reconhecer o que o sistema não sabe continua fazendo parte do trabalho.
A velocidade exige o mesmo cuidado. Em um teste separado com CPU aquecida, o classificador bancário completo levou cerca de 1,8 milissegundos por solicitação na mediana, no M4 Max. Isso incluiu tokenização, embedding e pontuação.
Excluiu o download e a inicialização do modelo. É uma medição de classificação, não o tempo necessário para resolver a solicitação inteira do usuário. Também não garante o mesmo desempenho em um celular ou notebook comum.
O Jev entra nessa discussão porque já lida com uma classe semelhante de decisões.
A TypeSafe documenta o Jev como um modelo para julgamentos delimitados, incluindo escolher entre opções fornecidas e rotear solicitações para código comum, modelos especialistas ou humanos. \Documentação de roteamento de intenção do Jev\
O papel que vejo para o Jev é um caminho opcional de escalonamento para solicitações que o classificador local não consegue resolver com segurança.
A arquitetura que buscamos é simples:
Solicitação recebida → classificação local → solicitações conhecidas seguem um caminho definido; solicitações incertas vão para o Jev, outro modelo ou revisão humana.
Sem o Jev, a mesma etapa de classificação local pode devolver as solicitações não resolvidas ao LLM existente do aplicativo, à etapa de esclarecimento ou ao processo de revisão.
O desenvolvedor controla as categorias, os limites de aceitação e o fallback. Ele pode introduzir o classificador local em um fluxo de trabalho existente e medir quais decisões ele consegue assumir.
Hoje, a integração com o Jev opera em modo sombra, comparando decisões em cinco grandes tópicos sem alterar o comportamento do aplicativo. O próximo passo é testar se o escalonamento seletivo melhora o fluxo de trabalho completo. Os resultados do Qwen acima não são um benchmark do Jev.
É isso que precisamos medir: menos chamadas desnecessárias ao modelo, tratamento mais rápido de solicitações conhecidas e um caminho explícito para casos que exigem mais atenção.
Começamos a estender a mesma abordagem para imagens.
Imagine uma empresa recebendo um recibo, um print de erro e a foto de um produto. Cada um precisa de um caminho de processamento diferente.
Um recibo poderia ir para a extração de recibos. Um print poderia entrar em um fluxo de suporte. A foto de um produto poderia entrar em um fluxo de catálogo. Uma imagem duvidosa iria para revisão.
O classificador escolhe o destino. Ler o total da compra, diagnosticar o erro e identificar detalhes do produto continuam sendo tarefas separadas.
Nossa implementação experimental de imagens usa um encoder CLIP pré-treinado para produzir uma representação numérica da imagem.
Um candidato de pesquisa ajustado classificou corretamente 19 de 20 fotografias de produtos alimentícios em um pequeno teste diagnóstico. Também enviou todas as 30 imagens de folhas de feijão para revisão.
O erro foi classificar o painel nutricional e o código de barras de uma garrafa como um recibo.
Dá para entender o problema. Ambos podem conter texto denso, números e layouts retangulares. Precisamos de exemplos que ensinem a fronteira que importa para o nosso aplicativo.
Essa amostra é pequena demais para uma afirmação de produção. Os rótulos vieram do dataset, em vez de serem avaliados de forma independente, e não havia exemplos novos de recibos ou prints no teste. A demonstração pública usa uma linha de base separada, então o resultado do candidato ajustado não deve ser atribuído a ela.
O processamento de imagens também foi mais pesado que a classificação de texto. O processamento mediano com aquecimento levou aproximadamente 36 milissegundos no Node e 197 milissegundos no Chromium, no M4 Max. O navegador primeiro precisa de cerca de 85 MiB de assets do modelo, além do seu runtime.
A execução local ainda tem custos. Tamanho do download, memória, tempo de inicialização e desempenho do dispositivo devem entrar na avaliação.
O produto que tenho em mente se encaixa em um aplicativo existente, onde decide o que acontece em seguida.
Um desenvolvedor define categorias, fornece exemplos representativos, conecta os destinos e escolhe o que deve acontecer quando a classificação for incerta.
A primeira implantação deve observar o fluxo de trabalho atual sem alterar seu resultado. Podemos então comparar as decisões propostas com resultados verificados antes de permitir que o classificador controle o roteamento.
Precisamos inspecionar os erros aceitos com o mesmo cuidado das solicitações rejeitadas. Caso contrário, uma decisão errada, mas confiante, pode desaparecer atrás de uma pontuação tranquilizadora.
Treinamento, calibração e testes também precisam de dados separados. O treinamento ensina as categorias. A calibração seleciona as regras de aceitação. Um teste protegido verifica o resultado congelado.
Assim que um erro de teste influencia o próximo modelo, aquele exemplo vira dado de desenvolvimento. A próxima avaliação precisa de um teste novo.
O pequeno alienígena na máquina de triagem dá às pessoas uma forma de visualizar o trabalho. Construir uma versão útil significa descobrir exatamente quais entradas ele consegue tratar, quando deve pedir ajuda e quanto custam seus erros.
O próximo passo é um fluxo de trabalho representativo com rótulos independentes e um registro de cada resultado. Precisamos medir quantas solicitações seguem pela rota local, quantas chegam a outro modelo, quantas dão errado e se o aplicativo completo fica mais rápido ou mais barato depois de contabilizar esses erros.
Hora de escalar e dar uns esteroides para esse modelo local.
