Este modelo de 150M afirma ser o número 1. Eu o testei.

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: This 150M Model Claims #1. I Tested It. · Canal: Prompt Engineer 48 · 07:56 · Assistir no YouTube

Tópicos: Avaliação e benchmarks de IA, Dados, bancos de dados e embeddings, Modelos locais e open source, RAG, busca e recuperação de informação

Resumo

O vídeo examina as alegações do UltraERT Embed 150M, um modelo de embeddings que afirma alcançar 67,24 no MTEB, e analisa os resultados publicados em seu model card. O apresentador testa o modelo localmente em uma GPU de laptop com 8 GB de VRAM e compara sua busca com GTE ModernBERT Base e BGE Base. No teste pequeno, com 11 perguntas sobre 21 trechos curtos, o UltraERT não supera os concorrentes e é mais lento. O apresentador ressalta que o teste não avaliou os pontos fortes alegados do modelo — documentos longos e busca de código — e recomenda testar com os próprios dados.

Pontos-chave

O UltraERT Embed 150M é um modelo de embeddings, não um modelo de chat: transforma texto em vetores para busca, classificação e agrupamento.
O model card informa média de 67,24 no MTEB English v2, mas os resultados são relatados pelos autores e as entradas na tabela de classificação não estão verificadas.
O modelo tem 768 dimensões, aceita até 32 mil tokens e é distribuído sob licença Apache 2.0.
Em um teste local com 11 perguntas e 21 trechos, o UltraERT acertou o trecho correto em primeiro lugar em 5 casos, contra 6 para GTE ModernBERT Base e BGE Base.
O UltraERT teve os maiores tempos medianos por consulta no teste, embora o apresentador não tenha investigado a causa da diferença.
O teste usou trechos curtos e limitou os trechos maiores a 512 tokens; por isso, não avaliou adequadamente o suporte alegado a documentos longos.
A busca de código também não foi testada, embora o apresentador destaque os resultados do modelo nessa tarefa.
A recomendação é experimentar o modelo nos próprios dados, especialmente se o corpus contiver documentos longos ou código.

Capítulos

Início	Capítulo	Resumo
00:01	A alegação de liderança e o model card	O vídeo apresenta a pontuação divulgada para o UltraERT Embed 150M e explica suas características e os resultados nas tabelas.
03:45	Treinamento e configuração do teste local	O apresentador resume as alegações sobre o treinamento do modelo e descreve como o carregou em uma GPU de laptop.
04:49	Comparação de busca com outros modelos	Um teste com 11 perguntas compara o UltraERT com GTE ModernBERT Base e BGE Base em precisão e velocidade.
06:24	Limitações e para quem o modelo pode servir	O apresentador explica por que o teste não avaliou documentos longos nem código e recomenda validar o modelo nos próprios dados.

Citações

O maior resultado de qualquer modelo denso com menos de 200 milhões de parâmetros. — 00:01

Os números são os resultados relatados pelos próprios autores. — 03:13

Neste teste, o Ultra não venceu. — 05:54

Se seus documentos forem longos ou você buscar código, este é o modelo que eu testaria primeiro com seus próprios dados. — 06:55

Conceitos e entidades

UltraERT Embed 150M (modelo): Modelo de embeddings com 150 milhões de parâmetros apresentado como capaz de lidar com busca, classificação e documentos de até 32 mil tokens.
MTEB (conceito): Benchmark de embeddings usado no vídeo para contextualizar a pontuação de 67,24 informada no model card.
GTE ModernBERT Base (modelo): Modelo de embeddings comparado ao UltraERT no teste local de recuperação de trechos.
BGE Base (modelo): Modelo de embeddings que, junto com GTE ModernBERT Base, obteve mais acertos em primeiro lugar que o UltraERT no teste apresentado.
Sentence Transformers (ferramenta): Biblioteca indicada no model card como requisito para carregar e usar o modelo.
DMEIL Lab (empresa): Laboratório ao qual o vídeo atribui o artigo comunitário que apresenta o modelo.
RunPod (empresa): Serviço de GPU mencionado pelo apresentador ao final do vídeo.

Tradução completa (pt-BR)

00:01 Este é o cartão do modelo de um modelo de embedding com 150 milhões de parâmetros, e ele indica 67,24 no MTEB, o maior resultado entre todos os modelos densos com menos de 200 milhões de parâmetros. Certo, neste vídeo vamos conferir essa afirmação na página original. Depois, fiz meu próprio teste de busca nesta GPU de laptop com 8 GB — e vale dizer que o resultado não foi o que o cartão sugere. Vamos conferir. Este é o artigo do blog no Hugging Face, intitulado “Ultraert: um encoder para classificação e recuperação”. É um

00:32 artigo da comunidade do DMEIL Lab, publicado em 14 de outubro de 2026. À direita, dá para ver que ele tem 37 votos positivos. No TLDDR, dizem que é uma família de encoders em inglês, com 150M e 380M, contexto nativo de 32K, além do Ultra Embed 150M, um modelo de embedding pronto para uso, construído sobre essa base. Tudo está sob a licença Apache 2.0. Este é um encoder, não um modelo de chat. Ele não escreve texto. Transforma texto em um vetor para que você possa fazer buscas, classificações e agrupamentos. É por isso que ele é

01:04 pequeno e também por isso consegue rodar em um laptop como este. Agora vamos abrir o cartão do modelo Ultraert Embed 150M. À direita, dá para ver o tamanho do modelo, 0,2B de parâmetros, o arquivo SafeTensors e, no alto, a licença Apache 2.0. Se você olhar a tabela no meio, o modelo de embedding tem dimensão oculta de 768 e contexto de 32K. O texto diz que ele mapeia o texto para um vetor de 768 dimensões e aceita entradas de até 32.000 tokens. Só que há algo a

01:36 observar: ele é muito novo. Dá para ver que esta página tem 125 downloads e 27 curtidas. Então, quase ninguém o testou de forma independente ainda. E o próprio cartão é a fonte desses números. Na aba de arquivos e versões, dá para ver que tudo consiste em um único arquivo SafeTensors com cerca de 151 milhões de parâmetros. Então, carregá-lo é simples. Guardem o número 67,24, porque vou voltar a ele. Vamos ler a tabela de fato. Esta é a versão em inglês do MTEB, com 41 tarefas. Na primeira linha, Ultra Bird Embed 150M, média de 67,24.

02:10 O próximo é Tarka Embedding 150M V1, com 66,39. Depois vem GTE Modern Bird Base, com 66,26. Então, a vantagem é de menos de um ponto sobre o segundo colocado e de 1,0 sobre o terceiro. Ele está na frente, mas não por uma grande margem. Agora, olhe as colunas de classificação. O Ultra marca 81,74, enquanto o Distilled F2 LLM V2 160M marca 87,13, que é o número em negrito nessa

02:41 coluna. O Tarka marca 86,28. Então, em classificação, ele fica para trás. Onde vence é em recuperação, com 57,20, e em sumarização, com 34,89. Agora, desça até a tabela de código. Na versão 1 do MTEB Code, a média é 73,430, e o KOR marca 72,73. Na coluna Apps, ele marca 68,5, enquanto o GTE Modern Bird Base marca 57,72. Então, há uma grande diferença em busca de código. E

03:13 este é o resultado que me interessa. O Long Embed tem média de 79,30, e o Pascal Retrieval marca 99,00 com documentos de até 32.768 tokens. O próximo, Beco, só aceita até 8192 e marca 73,19. Mais uma observação importante: o cartão diz que esses números foram informados pelos próprios autores. O indicador de verificação nas entradas do leaderboard está marcado como falso. Então, é preciso conferi-los com seus próprios dados. Foi exatamente isso que fiz.

03:45 O artigo está no arXiv: 2610.1528, “Ultra Beyond the Limit of Bird Pre-Training”. No blog, eles fazem duas afirmações. Aqui, dá para ver que os encoders param de melhorar depois de 1 a 2 trilhões de tokens, mesmo enquanto a perda continua diminuindo. E a proporção de masking determina em que o encoder é bom. Uma proporção baixa de masking vence em classificação; uma alta vence em recuperação. O blog diz que eles misturam masking de 5% e 50% em cada lote. E o cartão diz que o modelo de embedding é treinado apenas com perdas contrastivas em pares públicos, sem destilação

04:16 de um modelo de embedding maior. Agora vamos executá-lo. Vale dizer que tudo aqui está no meu sistema local, em uma GPU de laptop RTX 4060 com 8 GB, e quase 7 GB já estavam sendo usados por outras coisas. O cartão diz que você precisa do Sentence Transformers 6 ou mais recente, do Transformers 5 ou mais recente e de trust code igual a true. Então, configurei um ambiente virtual limpo. Só que o pip me instalou uma versão do torch apenas para CPU. Então, troquei pela versão com CUDA. Depois disso, ele carrega em FP16

04:49 e dá para ver que o pico de VRAM foi de 0,68 GB. Então, o modelo em si é minúsculo. O código é simples. Para as consultas, você passa o prefixo de instrução “Instruct: Given a question, retrieve passages that answer it” — ou seja, “Dada uma pergunta, recupere trechos que a respondam” — e os documentos entram sem prefixo. Aqui está meu teste. Peguei o próprio cartão do modelo, dividi-o em 21 partes e escrevi 11 perguntas cujas respostas sei em qual parte estão. Coisas como: qual é o

05:20 comprimento máximo de entrada em tokens? Ou como habilito o Flash Attention? Rodei três modelos: Ultra Bird Embed 150M, GTE Modern Bird Base e BGE Base v1.5. E vale dizer que este é um teste pequeno, com 11 perguntas. Aqui estão os resultados. O Ultra Bird encontrou a parte certa em primeiro lugar em cinco das 11 perguntas. Então, o recall em primeiro lugar é 0,455. O recall entre os três primeiros é 0,727. O GTE Modern Bird Base encontrou a resposta em primeiro lugar em seis das 11 perguntas: 0,545, e recall entre os três primeiros de 0,818. O BGE

05:54 Base teve os mesmos resultados: 0,545 e 0,818, e o melhor MR, 0,727, contra 0,647 do Ultraert. Então, neste teste, o Ultra não venceu. Ficou uma pergunta atrás no primeiro lugar e também foi o mais lento por consulta. Rodei tudo duas vezes. A mediana do Ultra Bird foi de 55 e 74 milissegundos; a do GTE, 36 e 44; e a do BGE, 22 e 25. Então, o que isso significa? Não significa que

06:24 o cartão esteja errado. Meu corpus tem 21 partes, 17 delas com menos de 200 tokens. E as quatro partes grandes com tabelas foram cortadas no limite de 512 tokens que defini. Então, o recurso para o qual o Ultra Bird foi desenvolvido — contexto longo — nem chegou a ser usado. Também não testei código. A afirmação do cartão é mais forte justamente nas duas coisas que não pus à prova: documentos de 32K e recuperação de código. E não analisei a diferença de velocidade. Então, não posso dizer por que ele é mais lento aqui. Meu código precisa de trust code, pois usa código personalizado do modelo. Portanto, se você busca parágrafos curtos em

06:55 inglês, o BGE Base ou o GTE Modern Base dão conta e foram mais rápidos no meu teste. Se seus documentos forem longos ou você fizer buscas em código, este é o primeiro modelo que eu testaria com seus próprios dados. E, como os números são dos próprios autores, teste-o com seus dados antes de confiar no 67,24. Então, para quem ele serve? Você tem um laptop ou uma máquina com CPU. Seus documentos são longos, e você quer um modelo que dê conta de recuperação, classificação e similaridade, usando uma instrução na consulta. É isso que

07:25 este cartão descreve. Se você tem documentos curtos, pode continuar com o que já usa. O próximo passo que eu daria seria criar um repo com meu próprio código e incorporar arquivos inteiros com 8K e 16K tokens, comparando os três novamente. Se quiserem isso, me contem nos comentários. Se estiver procurando GPUs baratas e confiáveis, eu uso o RunPod, e o link está na descrição. Então, neste vídeo, vimos o cartão real do modelo, as tabelas reais, e fiz meu próprio teste pequeno de busca. Teste-o nos seus próprios documentos e me conte como foi. Modelo usado: DMS

07:56 Lab Ultraird Embed 150M. Vejo vocês em outro vídeo.

Transcrição original

[00:01] This is the model card of a 150 million parameter embedding model and it says 67.24 on MTEB, the highest of any dense model under 200 million parameters. All right, in this video we will check that claim on the real page and then I ran my own search test on this 8GB laptop GPU and mind you the result was not what the card suggests. Let’s go ahead and see. So this is the blog post on hugging face titled Ultraert one encoder for classification and retrieval. It’s a

[00:32] community article from DMEIL lab published October 14th, 2026. And you can see it has 37 upvotes on the right. In the TLDDR they say it is a family of English encoders 150M and 380M with a native 32K context plus ultra embed 150M, a readytouse embedding model built on top. Everything is Apache 2.0. Now this is an encoder not a chat model. It does not write text. It turns text into a vector so that you can search, classify and cluster. That is why it’s

[01:04] small and that is why it can run on a laptop like this one. Now let’s open the model card for Ultraert Embed 150M. On the right you can see the model size 0.2B parms, the safe tensors file and the license Apache 2.0 up on top. If you look at the table in the middle, the embedding model has 768 hidden size and a 32k context. The text says it maps text to a 768 dimensional vector and takes inputs up to 32,000 tokens. Here’s the thing to

[01:36] notice though. It’s very new. You can see 125 downloads and 27 likes on this page. So almost nobody has independently tested it yet. And the card itself is the source of these numbers. in the tab files and versions. The whole thing is one safe tensors file of about 151 million parameters. So loading it is simple. Hold on to that number 67.24 because I’m going to come back to it. Let’s read the actual table. This is MTB English version 2 41 tasks. The first row Ultra Bird embed 150M average 67.24.

[02:10] Next one is Tarka embedding 150 MV1 at 66.39. And then GT modern bird base at 66.26. So the lead is under one point over the second and 1.0 over the third. It’s ahead but not by a mile. Now look at the columns in classification. Ultra scores 81.74 and the distilled F2 LLM. V2 160M scores 87.13 which is the bold number in that

[02:41] column. Tarka gets 86.28. So on classification it’s actually behind where it wins is retrieval at 5720 and summarization at 34.89. Now go down to the code table. MTEBB code version 1 average 73430 and KOR is 72.73. On the apps column it’s 685D while GTE modern bird base is 57.72. So that’s a big gap on code search. And

[03:13] this one is the one I care about. Long embed 7930 average and Pascal retrieval 99.00 with documents up to 32,768 tokens. The next one, Beco only goes to 8192 and gets 73.19. One more honest thing, the card says these are the author’s own reported numbers. The verified flag on the leaderboard entries is false. So they should be checked on your own data. That is exactly what I did.

[03:45] The paper is on RXE 2610 1528 ultra beyond the limit of bird pre-training. And in the blog they make two claims. You can see here encoders stop improving after 1 to2 trillion tokens even while the loss keeps going down. And the masking ratio decides what the encoder is good at. Low masking wins classification, high masking wins retrieval. And the blog says they mix five and 50% masking in every batch. And the card says the embedding model is trained with contrastive losses on public pairs only without distillation

[04:16] from a larger embedding model. Now let’s run it. Mind you that everything here is on my local system and RTX 4060 laptop GPU with 8 GB and almost 7 GB of that was already used by other things. The card says you need Sentence Transformers 6 or newer, Transformers 5 or newer and trust code equals true. So I set up a fresh virtual environment and one catch pip gave me a CPU only torch. So I swapped it to the CUDA build. After that it loads in FP16

[04:49] and you can see peak VRAM was 0.68 GB. So the model itself is tiny. The code is simple. For queries you pass the instruction prefix instruct. Given a question retrieve passages that answer it query and the documents go in raw with no prefix. Here is my test. I took the model card itself, cut it into 21 chunks, and wrote 11 questions where I know which chunk has the answer. Things like, what is the

[05:20] maximum input length in tokens or how do I enable flash attention? I ran three models, Ultra Bird, Embed, 150M, GTE, Modern Bird Base, and BGE Base and V1.5. And mind you, it is a small test, 11 questions. Here are the results. Ultra Bird got the right chunk first in five of 11. So recall at one is 0.455. Recall at three is 0.727. GTE modern bird base got six of 11 first. 0.545 and recall at 3 0.818. BG

[05:54] base got the same.545 and 818 and the best MR 0.727 against 0.647 for Ultraert. So on this test Ultra did not win. It was one question behind at rank one and it was also the slowest per query. I ran the whole thing twice. 55 and 74 milliseconds median for Ultra Bird, 36 and 44 GTE, 22 and 25 for BGE. So what does that mean? It doesn’t mean

[06:24] the card is wrong. My corpus is 21 chunks, 17 of them under 200 tokens. And the four big table chunks were cut at the 512 token limit I set. So, the thing ultra bird is built for long context never got used. I also never tested code. The card’s claim is strongest on exactly the two things I did not stress 32k documents and code retrieval. And I did not profile the speed gap. So, I can’t tell you why it is slower here. It needs trust from my code which is custom model code. So, if you search short

[06:55] English paragraphs ABG base or gte modern base is fine and faster in my test. If your documents are long or you search code, this is the one I would test first on your own data. And since the numbers are the author’s own, test it on your own data before you trust the 67.24. So who is it for? You have a laptop or a CPU box. Your documents are long and you want one model that handles retrieval, classification, and similarity with an instruction on the query. That is what

[07:25] this card describes. If you have short documents, you can stay with what you have. The next step I would do is a repo of my own code with whole files embedded at 8K and 16K tokens and compare the three again. If you want that, let me know in the comments. If you’re looking for cheap and reliable GPUs, I use RunPod and the link is in the description. So, in this video, we looked at the real model card, the real tables, and I ran my own small search test. Try it on your own documents and let me know how it goes. Model used DMS

[07:56] Lab Ultraird Embed 150M. I’ll see you in another one.