Unsloth transforma o Qwen3.5-4B em um classificador de 10 intenções em uma única T4

Um grande modelo de linguagem nem sempre precisa conversar. Em muitos produtos, espera-se dele um resultado mais prático: identificar a intenção do cliente, escolher a próxima ferramenta ou decidir se uma mensagem deve seguir adiante. Um LLM convencional pode gerar uma explicação, embora o sistema precise apenas de uma resposta curta—por exemplo, «consulta de saldo» acompanhada de uma pontuação de confiança.

O Machine Learning Mastery mostrou como criar esse tipo de classificador com base no modelo aberto Qwen3.5-4B. A solução combina Unsloth, LoRA de 4 bits e o conjunto de dados CLINC150. A demonstração roda no Google Colab em uma Tesla T4 com 14,6 GB de VRAM e limita a tarefa a dez intenções. Não se trata de um modelo industrial pronto, mas de um ponto de partida claro para o desenvolvedor que deseja substituir uma cadeia de prompts por um mecanismo de seleção independente.

O modelo escolhe em vez de redigir

Imagine a mensagem: «Mostre o saldo da minha conta poupança». Um modelo generativo pode escrever instruções, perguntar qual é o banco ou começar a raciocinar. Um classificador deve fazer outra coisa: selecionar a intenção balance em um conjunto previamente definido e retornar uma pontuação de confiança.

Na Unsloth, o FastDecisionModel é responsável por essa tarefa. Uma cabeça especializada é adicionada ao modelo de linguagem base para pontuar as opções permitidas. Em vez de gerar tokens sequencialmente, o sistema compara decisões fixas. Há suporte à seleção de uma opção, a respostas de sim ou não e à atribuição de notas em uma escala ordenada.

Esse formato é adequado para roteamento de solicitações, moderação, identificação de sentimento e cenários com agentes. Por exemplo, um modelo pequeno pode ser colocado antes do LLM principal para decidir para onde encaminhar a solicitação: busca, base de conhecimento, serviço de pagamentos ou atendimento humano. A saída é limitada por um esquema, o que facilita sua validação e seu envio ao próximo componente.

Como o treinamento é estruturado

O autor carrega o Qwen3.5-4B no modo de 4 bits e conecta adaptadores LoRA de rank 16. A maior parte dos parâmetros originais permanece congelada, enquanto o treinamento altera os adaptadores compactos e a cabeça de tomada de decisões. O checkpointing de gradientes reduz ainda mais o consumo de memória.

Os dados também precisam ser reestruturados. Cada registro contém três partes: o texto do usuário, uma descrição das decisões disponíveis e a opção correta. No exemplo do CLINC150, 10 das 150 intenções são selecionadas aleatoriamente, incluindo data, hora, trajeto, substituição de ingrediente e partida auxiliar de um automóvel com uma bateria externa. Depois, são mantidos apenas os exemplos relacionados a essas intenções.

É justamente a lista de opções que torna a tarefa controlável: o desenvolvedor define antecipadamente quais ações o sistema pode executar. Mas isso também tem um custo. Quanto maior o número de opções, mais longa é a entrada e mais pesado é o treinamento. Dez classes em uma T4 ainda não provam que a mesma configuração conseguirá lidar, sem alterações, com todas as 150 categorias ou com mensagens reais de clientes.

Onde termina a demonstração

O trecho disponível não apresenta a precisão final, uma matriz de confusão nem uma comparação com um classificador convencional. Portanto, não é possível afirmar que o Qwen3.5-4B já supera modelos mais baratos. A qualidade do reconhecimento de solicitações fora do conjunto compatível também não é demonstrada, embora o CLINC150 contenha exemplos separados desse tipo de consulta.

Para produção, a confiança do modelo, por si só, não é suficiente. Ela precisa ser calibrada em um conjunto de validação separado; também é necessário escolher um limiar de rejeição e verificar os erros entre intenções semelhantes. Se duas ações diferem em apenas um detalhe—por exemplo, «bloquear o cartão» e «cancelar o cartão»—, o custo de uma decisão errada pode ser maior que a latência introduzida por uma pergunta de esclarecimento.

A conclusão prática é simples: o FastDecisionModel é interessante como forma de transformar um LLM aberto em um roteador estritamente limitado. Vale a pena começar com um pequeno conjunto de ações fáceis de distinguir, uma classe obrigatória de «não sei» e um registro de erros. Depois, a solução pode ser comparada com um classificador BERT compacto, regras e chamadas a um modelo maior. O que importa aqui não é o impacto visual da arquitetura, mas a proporção de decisões corretas com latência e custo aceitáveis.