Italian NLP: Embeddings Beat Keywords for Local AI
Multilingual embeddings for local AI search aren't a nice-to-have optimization — they're the only architecture that actually works, and every hour you spend building a translation pipeline is an hour you're paying to solve a problem that doesn't exist.
I learned this the hard way building Crowdia, an AI-powered event discovery platform for Palermo. The premise was simple: help locals and tourists find events in a city where the cultural calendar is rich, the data is fragmented, and almost none of it is in English. We had scrapers pulling from Sicilian event sites, Facebook pages, local newspapers, and municipal listings. The content was in Italian. Our users searched in Italian. And our first instinct — like most engineering teams — was to translate everything into English before indexing it, run English embeddings, and call it a day.
That instinct was wrong in ways that cost us weeks of infrastructure work and produced measurably worse results. Here's the full breakdown.
The Translation Pipeline Is a Tax on Your Own Ignorance
When we started Crowdia, the conventional wisdom was straightforward: English-language embedding models are better, more thoroughly trained, and more widely supported. Therefore, translate your non-English corpus to English, embed it in English, and search in English. This is the path of least resistance and it feels responsible — you're using "better" models, after all.
The problem is that this logic has a hidden assumption baked into it: that translation is lossless. It isn't. Not even close.
Italian event listings are dense with culturally specific language. A "sagra" isn't just a "festival" — it's a specific type of local food-and-culture fair with connotations that "festival" doesn't carry. "Serata" translates literally to "evening" but in context means an evening event, often with music, and carries a social register that "evening event" completely flattens. When we ran our early corpus through a standard translation API before embedding, we were systematically destroying the semantic signal that made our search useful.
The retrieval quality showed it immediately. Users searching for "sagra del pesce" were getting results ranked below generic "music events" because the translation pipeline had homogenized everything into bland English categories. Our precision at k=5 was around 0.41. That's not a search engine — that's a slot machine.
This is the uncomfortable reality of the translation-first approach: you're not using a better model. You're using a worse representation of your data fed into a slightly better model, and the data quality loss dominates.
What Actually Happened When We Switched to Multilingual Embeddings
We dropped the translation pipeline entirely and switched to multilingual-e5-large from Microsoft, which supports 100 languages including Italian with genuinely strong performance — not the "we technically support it" performance you get from some models where non-English languages are clearly second-class citizens.
The change was surgical. Same indexing infrastructure, same vector database (we were running Qdrant), same query interface. We just stopped calling the translation API and started embedding Italian text directly. The embeddings were generated natively in Italian, stored, and queried against Italian user input.
Precision at k=5 jumped to 0.74 within the first week of testing. That's not a marginal improvement — that's the difference between a product that works and one that doesn't.
But the more interesting finding wasn't the raw accuracy number. It was what kinds of queries improved most dramatically. The gains were concentrated in:
- Culturally specific queries — searches that referenced local Palermitan concepts, neighborhood names, or event types that don't translate cleanly
- Colloquial phrasing — users searching the way they actually talk, not the way a translation model expects them to write
- Partial and misspelled queries — Italian autocorrect is different from English autocorrect, and embedding models trained natively on Italian text handle Italian typo patterns far better than a translation step ever could
The third point surprised me more than the others. Embedding a misspelled Italian word directly still produces a vector that's semantically close to the correct word in a well-trained multilingual model. Translating a misspelled Italian word often produces gibberish or a completely wrong English phrase, which then embeds far from where it should.
The Real Cost Calculation Nobody Is Doing
There's a piece trending on Hacker News right now titled "When AI Costs More Than the Engineer" that's getting a lot of traction in the right circles. The argument is about AI operational spend versus engineering headcount — and it's directionally correct but misses a more granular point for teams building localized AI products.
The question isn't just "does AI cost more than the engineer?" It's "which AI costs are you paying that you don't have to?"
Our translation pipeline, before we killed it, was running approximately 2.1 million tokens per day through a commercial translation API during peak indexing. At standard pricing, that was real money — not startup-killing money, but significant enough to show up in weekly infrastructure reviews. More importantly, it was adding 340-600ms of latency to every indexing operation, which meant our event data was always slightly stale relative to what we could have achieved with direct embedding.
When we cut the translation step, we cut that cost to zero and reduced indexing latency by roughly 60%. The multilingual-e5-large model ran locally on our inference infrastructure — at the time I was doing a lot of the development work on my ASUS ROG Flow Z13 with the Strix Halo, which handles local inference surprisingly well for a machine that fits in a bag. Production inference ran on dedicated GPU instances, but the point stands: the embedding model itself was the cheaper part of the stack. The translation layer we thought was necessary was the expensive part.
This is the cost calculation teams aren't doing. They're evaluating embedding model costs in isolation while ignoring the translation infrastructure they've built around those models to compensate for a problem that multilingual embeddings solve natively.
Machine Learning Teams Systematically Underestimate Multilingual Model Quality
Part of why the translation-first pattern persists is that ML benchmarks are still heavily English-centric. When you look at leaderboards for semantic similarity, retrieval quality, and embedding benchmarks, the top performers are almost always evaluated primarily on English datasets. Non-English performance is reported but rarely highlighted, and the gap between English and non-English performance on the best multilingual models is often smaller than people assume.
Multilingual-e5-large performs within a few percentage points of English-only models on Italian semantic similarity tasks. For most production use cases, that gap is noise compared to the signal you lose in translation. The model was trained on multilingual data from Common Crawl, Wikipedia, and other sources with genuine Italian representation — not synthetic translation of English data.
The MTEB leaderboard has become more rigorous about multilingual evaluation, and if you actually look at the Italian-language retrieval benchmarks, the best multilingual models are competitive with anything you'd get by translating to English first. The engineering community just hasn't internalized this yet because the default assumption — English models are better, therefore translate to English — has a comfortable logic to it that doesn't require you to look at the actual numbers.
We looked at the actual numbers. The translation-first approach lost.
Why LLM-Based Translation Doesn't Fix This Either
The natural counterargument is: "Fine, but what if we use a better translation model? What if we translate with GPT-class LLMs instead of a commercial API?"
I've tested this. It helps with cultural nuance — an LLM will at least attempt to preserve the register of "sagra" rather than just outputting "festival." But it introduces two new problems that make it worse as a system, not better.
First, cost. LLM-based translation of a 2 million token daily corpus is not a production budget line that most products can sustain. The math gets ugly fast, and this is exactly the dynamic the tomtunguz.com piece is gesturing at when it talks about AI spend hitting breakeven against engineering headcount by 2029. You're adding expensive compute to compensate for an architectural choice that you shouldn't have made in the first place.
Second, latency and consistency. LLM translation is non-deterministic. Two runs of the same Italian event description will produce slightly different English translations, which means slightly different embeddings, which means your similarity scores drift over time as you re-index. This is a subtle correctness issue that will haunt your retrieval quality in ways that are hard to debug because the failures are stochastic.
Direct multilingual embedding is deterministic, fast, and cheap. The "better translation" path is expensive, slow, and introduces noise. There is no version of the translation-first architecture that beats native multilingual embedding on all three dimensions simultaneously.
What This Means for Anyone Building Localized AI Products
If you're building AI search for a non-English market — whether that's Italian event discovery, Spanish-language e-commerce, French municipal services, or anything else — the architecture decision tree is shorter than you think:
Does a well-trained multilingual embedding model support your target language with real training data (not just synthetic translation)? For most major world languages in 2026, the answer is yes. Multilingual-e5-large, the mE5 family, and several other models cover this ground. If the answer is yes, you embed natively. Full stop.
The translation pipeline is a legacy pattern from a period when multilingual models were genuinely weak. That period is over. The models caught up. The engineering culture hasn't.
Crowdia's search quality didn't improve because we found a clever trick. It improved because we stopped doing unnecessary work that was actively making our data worse. That's the most satisfying kind of engineering win — not adding something, but removing a layer of complexity that was costing us money, latency, and accuracy simultaneously.
I'm Not Softening This Conclusion
Multilingual embeddings for local AI search aren't an emerging best practice. They're the current best practice, and teams still building translation pipelines around English-only embedding models are paying a three-way tax: infrastructure cost, latency overhead, and retrieval quality degradation. All three are real. All three are measurable. And all three disappear when you embed natively.
The translation-first architecture made sense in 2021. In 2026, with mature multilingual models readily available, it's an expensive mistake dressed up as careful engineering.
We built Crowdia to help people find events in Palermo. The best thing we did for that product wasn't adding a feature — it was deleting an entire pipeline that we thought was making our AI smarter and was actually making it dumber. If you're building anything similar for a non-English market, start there. Measure your retrieval quality in the native language before you write a single line of translation infrastructure. The numbers will tell you what they told us.