Static Embeddings Make Retrieval Speed a Design Choice
Bekko's new multilingual static embedding model highlights a useful retrieval tradeoff: extremely cheap encoding can be valuable even when contextual models retain the quality lead.

Use static embeddings when cheap CPU encoding matters, but compare them with lexical and contextual baselines on language-specific production cases.
Bekko-static-embedding-v1 is a multilingual embedding model built around a deliberately simple operation: look up a fixed vector for every token, then average those vectors into one representation. There are no Transformer layers in the encoder. Its author reports training with roughly 814 million text pairs across 40 languages and a custom tokenizer of about 200,000 tokens. The released model produces vectors as wide as 1,024 dimensions and supports several shorter Matryoshka dimensions.
In the author's comparisons, the model scored 43.76 on the multilingual MNanoBEIR retrieval collection, versus 32.29 and 32.23 for two other multilingual static models. Its reported MMTEB Retrieval score was 49.96, close to multilingual-e5-small at 50.9, although the Transformer model led more clearly on the broader MMTEB mean and the Nano retrieval sets. These are published results from the model's creator, who also develops HAKARI-Bench; they should be validated on an independent workload before driving a deployment decision.
Static and contextual encoders solve different cost problems
A contextual encoder lets the representation of a token change according to its neighbors. That capability helps distinguish meanings and capture word order, negation, and relationships that a bag-like average can blur. It also requires running multiple neural-network layers for every new string. A static encoder replaces that computation with table lookups and aggregation.
That difference changes where retrieval cost appears. If a document collection is stable, its vectors can usually be computed once regardless of encoder type. Query encoding, however, happens on the live path. Static embeddings can therefore be attractive for high-query-volume services, CPU-only environments, offline applications, or an inexpensive first stage that narrows a large collection before a stronger reranker is used.
The tradeoff is not simply speed against one universal quality score. A support search dominated by distinctive product names may need different language understanding from a search system handling short, ambiguous questions. Exact terms may also make a lexical method such as BM25 competitive or complementary. The appropriate baseline set includes lexical retrieval, the static model, and at least one affordable contextual encoder.
Evaluate the failure modes hidden by an average
A benchmark average compresses many decisions: datasets, languages, query types, relevance judgments, and aggregation rules. Bekko's reported results illustrate why the category breakdown matters. The model performed strongly in retrieval and clustering relative to the compared static models, while another static model remained ahead in bitext mining, pair classification, and instruction reranking. A lead for one use case is not a blanket lead for every embedding task.
Build an evaluation set from the traffic the system must serve. Divide it by language, query length, lexical overlap, and intent. Include difficult contrasts: negated requirements, reordered phrases, multiple meanings of the same word, spelling variations, and queries whose best result shares few surface words. Record recall at the candidate limit used by the downstream system, not only a ranking metric over a convenient benchmark. If a reranker receives 50 candidates, a relevant document omitted from those 50 cannot be recovered later.
For multilingual applications, inspect each important language separately. A single average can conceal a serious regression in a lower-volume language. Cross-language retrieval deserves its own slice too: finding a French document from an English query is different from matching French queries to French documents. Tokenization coverage and the composition of training data can affect these cases differently.
Vector width is an operational variable
The model supports truncation from 1,024 dimensions to smaller predefined widths. The author reports that reducing it to 512 dimensions lowered the average retrieval result by about 0.9 points in the stated comparison. That is useful evidence for a quality-versus-footprint curve, not a guarantee of the same change elsewhere.
Dimension affects more than the model file. It changes the memory occupied by every indexed vector, the bandwidth required to move vectors, and the work performed during similarity search. For one million documents, 1,024 float32 values represent about 4.1 GB of raw vector data, while 512 represent about 2.0 GB, before index structures and metadata. Alternative numeric formats can reduce those figures further, with another potential accuracy tradeoff.
Test width and numeric precision independently. First compare full-width and truncated vectors under the same index settings. Then compare floating-point and quantized storage at a chosen width. This makes it possible to attribute a regression instead of bundling two changes together. Measure index build time, resident memory, query latency, recall, and downstream answer quality for every candidate configuration.
A sensible deployment ladder
Start with a small, reproducible retrieval experiment. Freeze a document snapshot and relevance set, normalize vectors consistently, and use identical filtering rules. Compare BM25, the static model, and a contextual baseline. Next, test a hybrid that combines lexical and vector candidates. Finally, rerank the merged candidate set if the application can afford it.
Treat encoding throughput and end-to-end latency as separate measurements. A fast encoder cannot compensate for a poorly configured vector index, expensive network round trips, or an oversized reranking stage. Conversely, precomputing document vectors can make model encoding a small share of an offline workflow. Measure on the intended CPU, with realistic batch sizes and input lengths, rather than adopting a general speed multiplier from another machine.
Static embeddings are best understood as a new point on the retrieval design curve, not as a universal replacement for contextual models. Bekko-static-embedding-v1 makes that point especially interesting for multilingual search: it offers a strong reported static baseline, selectable vector widths, and a standard Sentence Transformers interface. The next step is a workload-specific comparison that values memory, latency, language coverage, and failure severity alongside benchmark quality.
Source: bekko-static-embedding-v1: State-of-the-Art Retrieval for Multilingual Static Embeddings ↗. How we write


