GLiNER2.5-Decide: classificador de texto local de 340M na CPU (comparado a palavras-chave)

Autoria: Prompt Engineer 48 · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: GLiNER2.5-Decide: 340M Local Text Classifier on CPU (Tested vs Keywords) · Canal: Prompt Engineer 48 · 05:44 · Assistir no YouTube

Tópicos: Avaliação e benchmarks de IA, Modelos de IA, Modelos locais e open source, Privacidade e proteção de dados

Resumo

O vídeo testa o GLiNER2.5-Decide, um modelo de 340 milhões de parâmetros que classifica mensagens usando uma lista de rótulos e pode rodar localmente na CPU. Em um teste com 30 tickets de suporte, empatou com um roteador baseado em palavras-chave na classificação de intenção, mas melhorou quando os rótulos receberam descrições. O modo multilabel também identificou categorias úteis, embora o modelo sempre escolha rótulos e não explique suas decisões. O apresentador considera que ele pode servir para roteamento e marcação de mensagens, mantendo uma pessoa ou um modelo maior no processo.

Pontos-chave

O GLiNER2.5-Decide classifica texto em uma única passagem, com base no texto fornecido e em uma lista de rótulos.
O modelo tem 340 milhões de parâmetros e foi testado localmente em uma CPU, sem usar API.
No teste com 30 tickets, acertou a intenção em 25 casos, o mesmo resultado do roteador baseado em palavras-chave.
Adicionar descrições curtas aos rótulos elevou a precisão de intenção de 83% para 93% quando essa tarefa foi feita isoladamente.
Ao classificar intenção, prioridade e sentimento juntos, acertou todas as três tarefas em 57% dos tickets com rótulos descritos.
O modo multilabel pode devolver mais de uma categoria para a mesma mensagem, como entrega e risco de cancelamento.
O modelo sempre escolhe um dos rótulos fornecidos e não explica por que fez essa escolha.
O apresentador recomenda considerar o modelo para roteamento e marcação com rótulos fixos, mantendo supervisão humana ou de um modelo maior.

Capítulos

Início	Capítulo	Resumo
00:03	Apresentação do modelo e configuração do teste	O vídeo apresenta o GLiNER2.5-Decide, explica sua classificação por rótulos e mostra como instalá-lo e executá-lo localmente.
01:33	Comparação com um roteador de palavras-chave	O modelo é avaliado em 30 tickets de suporte, com resultados para intenção, prioridade e sentimento.
02:36	O efeito das descrições nos rótulos	Descrições curtas, especialmente para a categoria de mensagens fora do escopo, melhoram os resultados das classificações.
03:36	Classificação multilabel e limitações	O teste multilabel mostra exemplos de categorias atribuídas, e o apresentador compara a abordagem com a de um LLM maior.
05:13	Velocidade e usos recomendados	O vídeo apresenta tempos de execução e recomenda o modelo para roteamento e marcação, com supervisão humana ou de um modelo maior.

Citações

Você dá a ele um texto e uma lista de rótulos, e ele escolhe o rótulo. — 00:33

No meu teste, o modelo pequeno só empatou com um monte de instruções if. — 02:05

Os rótulos que você escreve importam muito. — 03:36

Ele sempre precisa escolher um dos rótulos. — 04:40

Eu manteria uma pessoa ou um modelo maior no processo. — 05:44

Conceitos e entidades

GLiNER2.5-Decide (modelo): Modelo de 340 milhões de parâmetros apresentado para classificar texto com base em rótulos fornecidos pelo usuário.
Fastino (empresa): Empresa citada como responsável pelo GLiNER2.5-Decide.
DeBERTa V3 (modelo): Encoder mencionado como base do GLiNER2.5-Decide.
classificação de texto (conceito): Tarefa de atribuir a um texto uma ou mais categorias predefinidas.
classificação multilabel (conceito): Modo de classificação que pode atribuir várias categorias ao mesmo texto.
roteador baseado em palavras-chave (conceito): Método de classificação comparado ao modelo, que usa palavras-chave e regras simples.
fine-tune (conceito): Ajuste adicional do modelo mencionado como possibilidade para tarefas como classificação de prioridade.

Tradução completa (pt-BR)

00:03 Certo, neste vídeo, veremos um pequeno modelo de 340 milhões de parâmetros que lê uma mensagem de cliente e decide o que fazer com ela. E você pode ver que ele me dá a resposta em uma única passada, usando apenas uma CPU comum. Vale lembrar que tudo aqui está rodando no meu laptop local, sem API e sem tokens. Vamos testar e ver se ele é mesmo tão bom quanto parece. Este é o GLiNER 2.5 Decide, da Fastino. É um modelo de 340 milhões de parâmetros, com licença Apache 2.0, baseado em um encoder grande DeBERTa V3

00:33 e a ideia é bem simples. Ele não conversa, não raciocina e não explica nada. Você fornece um texto e uma lista de rótulos, e ele escolhe o rótulo: intenção, encaminhamento, prioridade, sentimento — tudo em uma única passada forward. Agora, se você olhar o benchmark na própria suíte deles, com 17 domínios e 200 exemplos cada, ele marca 60,2%. A versão maior, de 1 bilhão, chega a 59,6%, então a pequena fica até um pouco à frente. Bem, 60% não é um número que faça você pular da cadeira, então eu

01:03 não queria simplesmente confiar nessa tabela. Fiz meu próprio teste. A configuração é bem simples. Você executa pip install gliner2 e depois carrega o modelo com AutoExtractor.from_pretrained. É só isso. Uma coisa: encontrei alguns pacotes ausentes no meu sistema, transformers e peft; e, no Windows, é bom ativar o modo UTF-8, senão o banner derruba o console. Não tem problema, leva um minuto para corrigir. Depois, você chama classify_text com o texto e um dicionário de rótulos, e pode ver que ele identifica “solicitação de reembolso” logo na primeira tentativa.

01:33 Foi isso que eu fiz. Escrevi 30 chamados de suporte, incluindo alguns casos complicados. Uma pessoa que foi cobrada duas vezes e cujo aluguel vence hoje. Uma pessoa que diz que o suporte é incrível, mas a palavra “reembolso” aparece na frase. Algumas conversas informais que não são sobre suporte. Eu mesmo rotulei cada chamado e pedi ao modelo que respondesse a três perguntas de uma vez: intenção entre oito rótulos, prioridade e sentimento. Para comparar, também criei o roteador mais preguiçoso que você pode imaginar: apenas palavras-chave. E vale lembrar que escrevi essas palavras-chave depois de ver meus próprios chamados, então essa linha de base acaba sendo um pouco

02:05 favorável a si mesma. Certo. Os resultados: intenção, 25 de 30, ou seja, 83%; o roteador por palavras-chave também chegou a 83%. Então, sinceramente, no meu teste, o modelinho só empatou com um monte de instruções if. Não era isso que eu esperava. A prioridade ficou em 63%, e o sentimento, em 73%. E, se você precisa que os três estejam corretos no mesmo chamado, são apenas 12 de 30, ou seja, 40%. Então, para avaliar a urgência, eu não confiaria nele cegamente. Agora, se você olhar os erros, há um padrão. “Vocês têm um escritório em

02:36 Berlim?” Foi encaminhado para falar com uma pessoa. “Qual é sua cor favorita?” Também foi encaminhado para falar com uma pessoa. O modelo precisa escolher alguma coisa e, quando a mensagem não se encaixa, ele força um rótulo. Então, a categoria “outros” é o ponto fraco. Mas aqui vai a dica: o model card diz que os rótulos podem ter uma descrição. Então, em vez de uma lista simples, passo um dicionário com o rótulo e uma frase curta explicando o que significa. Para “outros”, escrevi: qualquer coisa sem relação com suporte, conversa informal, elogios, perguntas gerais. Mesmo modelo, mesmos chamados, e agora a intenção sobe de 83 para

03:06 93%. São 28 de 30 quando faço essa pergunta isoladamente. Depois, fiz o mesmo para a prioridade. “Urgente” significa dinheiro, perda de dados, um prazo ou bloqueio de acesso ainda hoje. “Baixa” significa uma pergunta ou um pequeno incômodo. E a prioridade sobe de 63 para 73%. O sentimento sobe um pouco, de 73 para 77%. Agora, quando peço as três coisas de uma vez, a intenção cai um pouco, para 90%, mas a precisão no chamado completo — os três rótulos corretos — sobe de 40 para 57%. Então, os rótulos que você

03:36 escreve fazem muita diferença, e isso é ótimo, porque não custa nada: nenhum treinamento, apenas uma frase melhor. Agora, tem mais uma coisa que eu queria testar. Os chamados reais não tratam de uma coisa só, então há um modo de múltiplos rótulos. Você passa os rótulos, define multi-label como true e escolhe um limiar. Usei 0,4, e ele retorna todos os rótulos acima desse valor. Assim, ele gerou sete tags: cobrança, acesso à conta, entrega, bug de software, ameaça legal, risco de cancelamento e perda de dados. Vamos testar: “Fui cobrado depois de cancelar. Devolvam meu dinheiro ou vou contestar com

04:09 meu banco”. Ele diz “cobrança”. Ótimo. “O aplicativo apagou todos os arquivos do meu projeto.” Ele diz “perda de dados”. Ótimo, embora não tenha acrescentado “bug de software”, o que eu teria feito. E este caso é bom: “O pacote consta como entregue, mas não está na minha porta, e estou prestes a levar meu negócio para outro lugar.” Ele me dá “entrega” e “risco de cancelamento”. Duas tags, e um roteador por palavras-chave nunca detectaria o risco de cancelamento. Isso é realmente incrível para um modelo tão pequeno. Então, qual é a diferença entre isso e simplesmente pedir a um LLM grande para classificar? Bem, um LLM gera tokens; você escreve um prompt,

04:40 você analisa a resposta e, às vezes, ela volta em um formato um pouco diferente. Aqui, não há template de prompt nem texto gerado: você fornece os rótulos e recebe de volta um dos seus rótulos. Sempre um dos seus rótulos — e esse também é o porém. Ele sempre precisa escolher um. É por isso que a categoria “outros” e as descrições são tão importantes. E, como ele tem apenas 340 milhões de parâmetros, você pode executá-lo na sua própria máquina, então o texto dos chamados nunca sai do seu sistema. Vale lembrar que ele não consegue explicar por que escolheu determinada opção. Então, se você precisa de uma justificativa, esse é um trabalho para um modelo maior.

05:13 Agora, quanto à velocidade: na CPU do meu laptop, três perguntas de uma vez levam cerca de 620 ms, e uma pergunta só, cerca de 528 ms. Se eu enviar os 30 chamados em lote, leva cerca de 8,9 segundos. Então, dá aproximadamente 300 ms por chamado. A Fastino diz que são 167 ms em um servidor com 48 núcleos. E acredito nisso; meu laptop simplesmente tem menos núcleos. Não é instantâneo em um laptop, mas é gratuito, privado e dá a mesma resposta todas as vezes. Então, eu usaria isso para encaminhamento e etiquetagem quando você tem uma lista fixa de

05:44 rótulos e milhares de mensagens? Sim, especialmente com descrições. Você também pode fazer fine-tuning dele para prioridade ou qualquer tarefa com mensagens abertas. Eu manteria uma pessoa ou um modelo maior participando do processo. Então, neste vídeo, vimos como um modelo de 340 milhões de parâmetros decide o que fazer com um texto, o que acerta e onde falha. Se tiver interesse, pode conferir e testar no seu próprio sistema também; depois, me conte como foi. O modelo é o GLiNER 2.5 Decide, da Fastino. Vejo você em outro vídeo. Confira o próximo.

Transcrição original

[00:03] All right, in this video, we will see a tiny 340 million parameter model that reads a customer message and decides what to do with it, and you can see that it gives me the answer in one pass on a plain CPU. Now, mind you that everything here is running on my local laptop, no API, no tokens. Let’s go ahead and test this out and see if it is really as good as it sounds. So, this is Gleena 2.5 decide from Fast Tina. It’s a 340 million parameter model I bet 2.0 license built on a Debater V3

[00:33] large encoder, and the idea is very simple. It does not chat, it does not reason, it does not explain anything. You give it a text and a list of labels, and it picks the label intent, routing, priority, sentiment, all in a single forward pass. Now, if you look here at the benchmark on their own suite of 17 domains with 200 examples each, it scores 60.2%. The bigger 1 billion version gets 59.6, so the small one is actually slightly ahead. Now, 60% is not a number that makes you jump out of your chair, so I

[01:03] did not want to just trust this table. I wrote my own test. Setup is really simple. You do pip install Gleena 2, and then you load it with auto extractor.from pre-trained. That’s it. Now, one thing I did hit a few missing packages on my side, transformers and paft, and on Windows, you want to set UTF-8 mode, otherwise the banner crashes the console. Doesn’t matter, it’s a minute of fixing. And then you call classify text with the text and a dictionary of labels, and you can see that it says refund request first try.

[01:33] So, here’s what I did. I wrote 30 support tickets myself with tricky ones in them. A person who got charged twice and rent is due today. A person who says the support is amazing, but the word refund is in the sentence. Some small talk that is not support at all. And I labeled every ticket myself, and I asked the model three questions at once, intent from eight labels, priority, and sentiment. For comparison, I also built the laziest router you can think of, plain keywords. And mind you, I wrote those keywords after seeing my own tickets, so that baseline is a bit

[02:05] friendly to itself. All right. So, the results intent 25 out of 30, that is 83%, and the keyword router also got 83%. So, honestly, on my test, the little model only tied with a bunch of if statements. That is not what I was hoping for. Priority was 63%, and sentiment was 73. And if you need all three correct on the same ticket, it is only 12 out of 30, so 40%. So, for urgency, I would not trust it blindly. Now, if you look at the misses, there is a pattern. Do you have an office in

[02:36] Berlin? Got sent to speak to a human. What’s your favorite color? Also went to speak to a human. The model has to pick something, and when the message does not fit, it forces a label. So, the other bucket is the weak spot. But here’s the tip. The model card says labels can carry a description. So, instead of a plain list, I pass a dictionary, the label, and a short sentence that says what it means. And for other, I wrote anything unrelated to support, small talk, compliments, general questions. Same model, same tickets, and now intent goes from 83 to

[03:06] 93%. 28 out of 30 when I ask it alone. Then I did the same for priority. Urgent means money, data loss, a deadline, or a lockout today. Low means a question or a minor annoyance. And priority goes from 63 to 73%. Sentiment moves a little from 73 to 77. Now, when I ask for all three together, intent drops slightly to 90%, but the full ticket, all three correct, goes from 40% to 57%. So, the labels you

[03:36] write matter a lot, and that is really great because it costs nothing, no training, just a better sentence. Now, there is one more thing I wanted to try. Real tickets are not about one thing, so there is a multi-label mode. You pass the labels, you set multi-label to true, and a threshold. I use .4 and it returns every label above that. So, it made seven tags: billing, account access, delivery, software bug, legal threat, churn risk, and data loss. And let’s go ahead and see charged after canceling, refund me or I dispute with

[04:09] my bank, it says billing. Good. The app deleted all my project files, it says data loss. Good, although it did not add software bug, which I would have. And this one is nice, package marked delivered but nothing at my door and I’m about to take my business elsewhere. It gives me delivery and churn risk. Two tags and a keyword router would never catch the churn risk. So, that is really amazing for a model this small. So, how is this different from just asking a big LLM to classify? Well, an LLM writes tokens, you write a prompt,

[04:40] you parse the answer, and sometimes the answer comes back in a slightly different shape. Here, there is no prompt template, no generated text, you give the labels, and you get one of your labels back. Always one of your labels, and that is also the catch. It always has to pick one. That is why the other bucket and the descriptions matter so much. And since it is only 340 million parameters, you can run it on your own machine, so the ticket text never leaves your system. Mind you, it cannot explain why it chose something. So, if you need a reason, that is a job for a bigger model.

[05:13] Now, for speed, on my laptop CPU, three questions at once take about 620 ms and a single question about 528. And if I send all 30 in a batch, it takes about 8.9 seconds. So, roughly 300 ms each. Fast INO says 167 ms on a 48-core server. And I believe it, my laptop just has fewer cores. It’s not instant on a laptop, but it is free, private, and the same answer every time. So, would I use it for routing and tagging where you have a fixed list of

[05:44] labels and thousands of messages? Yes, especially with descriptions, and you can fine-tune it, too, for priority or anything with open-ended messages. I would keep a human or a bigger model in the loop. So, in this video, we have seen how a 340 million parameter model decides what to do with text, what it gets right, and where it fails. If you’re interested, you can go ahead and check this out and try this out on your own system as well, and let me know how it goes. The model is Gleaner 2.5 beside from Fast T know. I’ll see you in another one. Check out the next video.