ML Env

Use casesSearch & discovery

Handle misspellings, synonyms and mixed-language queries without maintaining dictionaries

Multilingual embeddings put 'trui', 'pullover' and 'jumper' near each other, cutting the need for hand-maintained synonym lists in an EU shop.

How it works
The embedding model is multilingual, so 'trui', 'pullover', 'jumper' and 'sweter' land near each other in the same vector space. That reduces the need for the hand-maintained synonym list an EU shop otherwise builds when customers search in Dutch, German, French or English against a catalogue written in one language. Many misspellings and colloquial phrasings also land near the right products instead of returning nothing.
Data you need
Your catalogue in at least one language, plus a short list of your known problem queries to test against — from search logs if your platform keeps them. If it does not (many small shops don't), assemble one by hand from support emails and memory before judging the results.
What to expect
It handles the long tail of variant spellings and cross-language phrasing well without any dictionary maintenance. But cross-language matching is noticeably weaker than same-language matching, especially for niche category vocabulary — it reduces the dictionary burden, it does not eliminate it. Misspelling tolerance is real but uneven: common typos usually work, garbled or very rare terms may not. Very short, ambiguous one-word queries remain hard for any approach. Without search logs, budget time to build a test set first — evaluating without one is guesswork.
Where people stay involved
Keep a small manual override list for brand names, house jargon and deliberate redirects — the model handles the long tail, humans handle the head terms that matter commercially. Spot-check the top queries after launch rather than trusting the first demo.

Which model, and what it costs to run

Qwen3-8B

No public benchmark ranks this particular job, so this is not a leaderboard pick — it is where we would start: small, permissively licensed, and strong wherever it has been measured. We prove it on your own content before anything ships.

Licence
Apache-2.0
Weights at 4-bit
5 GB
Context
32K tokens
Publisher
Alibaba (Qwen Team)

What the hardware costs

One 48 GB card holds it

Rent in the EU
$1.60/hrScaleway, Paris (PAR2)
Buy the card
$7,569new, one-off
Or rent it by the token
$0.04 / $0.04per M in / out · DeepInfra

Hardware only, third-party prices from 2026-07. The figure excludes the KV cache, which grows with context length and how many people use it at once — sized properly in a conversation, not guessed here. Renting by the token is cheaper up front; why our customers still self-host is below.

Search over your own catalogue

No benchmark measures this

MTEB and BEIR rank embedding models, but their evaluation sets sit inside the models' training data. Scores fall by double-digit nDCG on a private corpus, so the ranking does not transfer to your catalogue.

So we do not show a chart here. We measure it on your own content, in the first week, and you see the result before anything ships.

The API is cheaper per token. Here is why our customers don't use it.

We will not pretend otherwise: renting a model by the token from a serverless API costs less per million tokens than a card we run for you. We show that price on every use-case page. What it does not include is the part a shop with a customer database actually pays for.

  1. 01

    Your data never leaves hardware you can point at

    A serverless "we don't retain your data" is a clause in a contract. Running the model on a card in Amsterdam is a fact of architecture: your catalogue, tickets and customer records are never sent to a third party at all. For a GDPR audit, that is the difference between a promise and a floor plan.

  2. 02

    The price cannot move without your say-so

    A serverless rate card is somebody else's lever. The provider can raise the price, retire the model, or change the terms, and your cost moves with it. The same model on the same card costs the same next year — you own the number.

  3. 03

    The model cannot be taken away

    Hosted APIs deprecate models on their own schedule; the one you built on can be gone in a quarter. An open-weight model on your own hardware runs for as long as you keep the lights on. No vendor can end-of-life it out from under you.

And the price gap closes with volume: past a card you keep busy — very roughly four billion tokens a month — owning is cheaper outright, even before the three reasons above.

Getting a case like this one from a conversation to production takes about two months, and you can stop at the end of any phase.

Also in search & discovery

All 12 →

Next

Tell us what your team does by hand

Describe the process that takes the most time. We will say plainly whether a model is the right tool for it.