Ozon: a transformer in search suggestions — honest fractions of a percent at trillion-ruble scale

• Ozon Tech: генеративный трансформер в поисковых подсказках (архитектура, обучение на событиях, RPS, лимит 300 мс, итерации, риски генерации) — Habr (блог Ozon Tech), n/a
• Как Ozon ускорил расчёт факторов ранжирования динамической компиляцией (трёхуровневый поиск, CPU 15%+ → 5–6%, −10 мс) — Habr (блог Ozon Tech), n/a
• Ozon открыто рассказал об алгоритмах рекомендаций (пресс-брифинг о прозрачности, Алексей Минаев; >1000 признаков, вес персонализации ≈10%) — Телеспутник, 2022-04
• Принцип работы поиска на Ozon (5 шагов ранжирования, до 2000 кандидатов, нейросеть вероятности покупки) — SellerMoon, n/a
• Ozon задумался о создании ИИ-ассистента для помощи в поиске товаров (оценка +3–5% GMV за 1–2 года) — Forbes Russia, n/a
• GMV Ozon по годам (2024 ≈ 2,9 трлн ₽) — Smart-Lab (по отчётности компании), n/a

Background

Ozon is one of Russia's two largest marketplaces, with GMV of about 2.9 trillion rubles in 2024. At that scale the search bar is not a 'site feature' but the main distribution channel: a large share of orders starts with a query, and every fraction of a percent of search conversion is measured in billions of rubles of turnover.

The Ozon Tech team runs a detailed engineering blog on Habr and — rare for this market — publishes not just its ML system architectures but actual metric gains, including modest ones. The company is unusually open about algorithms in general: back in April 2022, at a press briefing on recommender-service transparency, Ozon deputy managing director Alexey Minaev publicly explained how the marketplace's search and recommendations work — against the backdrop of a State Duma bill on regulating recommendation algorithms. Per the company's official description, offer selection and sorting pass through five stages within fractions of a second (Telesputnik).

For the industry this openness is not cosmetic. The retail AI-case market is flooded with vendor decks touting double-digit 'conversion gains' with no methodology; an engineering blog that discloses architecture, constraints, and exact per-iteration A/B gains is nearly the only genre against which one can calibrate one's own expectations.

Ozon's search is a complex multi-tier system: the base tier runs full-text retrieval across millions of products, the middle tier precisely ranks thousands of selected candidates, and the top tier applies personalization (Habr, Ozon Tech blog). Over a thousand features participate in ranking; per the company's public account, personalization weighs about 10% (item popularity 29%, sales 17%, price 5%), with the weights revised regularly. This case is assembled from such primary sources: it covers a generative transformer in search suggestions — and what real recommender-impact numbers look like when the engineering team, not the marketing department, publishes them.

Problem

Search is the purchase entry point on a marketplace. Weak suggestions mean a longer path to the product and empty result pages that kill conversion: a user who hits 'nothing found' twice leaves for a competitor. The economics of suggestions are simple: most shoppers type queries on a phone, where every extra character is friction and every typo risks an empty page; a good suggestion cuts typing to a few characters while steering the user into a query whose results are guaranteed non-empty.

Classic suggestions assembled from a dictionary of popular queries handle marketplace specifics poorly: millions of products, brand names and SKU codes, typos, transliteration ('xiaomi' in three spellings), and a long tail of rare queries where a dictionary simply stays silent. This is exactly the specificity Ozon Tech cites as the reason for moving to a generative model trained on the marketplace's domain data (Habr).

The engineering constraints are strict: suggestions must be served at tens of thousands of requests per second within a 300-millisecond budget — otherwise the user types the query faster than the system can suggest it, and the feature's whole value collapses. That constraint immediately rules out large language models with billions of parameters: at this traffic, their inference either misses the latency budget or demands an unaffordable GPU fleet.

Finally, the generative approach adds its own class of risks that dictionary suggestions never had: the model can produce a grammatically broken phrase, a semantic duplicate of a neighboring suggestion, a query leading to an empty result page, a toxic phrasing from the training data — or an outright invented brand and nonexistent product. Each of these failure modes had to be closed with its own post-processing loop.

Solution

Ozon Tech built a generative decoder-only transformer of several hundred million parameters, trained not on ordinary text but on tokens of user actions.

Training ran in two stages. First, pretraining on chains of user events — queries, clicks, filters, product views; a single sequence can span months of a user's interactions with the marketplace. Then fine-tuning on the target task: generating a suggestion from session context and the typed prefix. This approach lets the model 'know' brands, SKUs, typos, and transliteration from real shopper behavior rather than an external corpus (Habr, Ozon Tech blog).

Inference runs on a GPU cluster via TensorRT-LLM, sustaining tens of thousands of requests per second within the 300 ms budget. Candidates are generated with beam search — the model tracks several continuation variants simultaneously and picks the best, yielding a diverse suggestion list instead of one 'most probable' answer. Candidates are then post-processed: deduplication, filtering of banned phrasings, and a check that the suggestion does not lead to an empty result page. This 'boring' plumbing is what closes the generative approach's specific risks — from grammar errors to invented brands: a generated but nonexistent product is cut at the non-empty-results check before it ever reaches the user.

The query's onward journey is documented too. The chosen suggestion enters the search pipeline: the system gathers candidates by keywords and synonyms, selects up to 2,000 relevant items, a neural network scores each one's purchase probability from 0 to 1, then boosts and de-boosts apply — and only then does the user see results; per industry write-ups, the whole pipeline fits into fractions of a second (SellerMoon). The suggestion is thus the first filter of a giant funnel, and its quality defines the quality of input to every subsequent stage.

The rollout proceeded in iterations with A/B measurement at each — and the sequence itself is instructive. Iteration one — basic generation of short suggestions: +10% suggestion CTR; the model simply started covering queries where the dictionary suggester stayed silent. Iteration two — multi-word suggestions with longer fragments: another +10%; users began seeing a fully formed query rather than just 'TV'. Iteration three — typo handling: another +3% CTR, a 3% drop in empty result pages, and +0.3% in the share of users finishing a session with an order — the first time the effect reached the final business metric. The team states the key observation of these iterations directly: CTR grows more easily than business metrics — suggestion clickability can be lifted quickly, while carrying the effect through to an order is much harder.

Suggestions are only the visible part of the search stack. In the same blog, Ozon Tech describes the ranking machinery: a three-tier system (full-text retrieval across millions of products → precise ranking of thousands of candidates → personalization) with thousands of deeply nested ranking factors. When recursive interpretation of factor formulas began consuming over 15% of the whole service's CPU, the team wrote a compiler generating JVM bytecode at runtime: CPU usage fell to 5–6% and total query time dropped by 10 milliseconds. Industry write-ups complete the picture: up to 2,000 candidate items are selected, a neural network scores each one's purchase probability from 0 to 1, then boosts and de-boosts apply (SellerMoon). Keep that in mind when reading about '+10% CTR': behind every percent stands infrastructure where 10 milliseconds is a visible win.

Result

Published gains by iteration: search-suggestion CTR +10%, then another +10% and +3%; the share of empty result pages fell 3%; the share of users finishing a session with an order grew 0.3%. Every figure comes from an A/B experiment on live traffic and was published by the team itself in its engineering blog — with the honest admission that clickability grows more easily than order conversion.

Modest at first glance — but at trillions of rubles in GMV, fractions of a percent are a material business effect, and this is what real recommender-system numbers look like. A further, less visible result is infrastructural: dynamic compilation of ranking formulas cut the search service's CPU consumption roughly threefold (from 15%+ to 5–6%) and shaved 10 ms off query time — at tens of thousands of RPS, that is both hardware savings and a direct contribution to result speed.

Credibility framing: all figures are the company's self-reported numbers with no independent audit. But this is self-reporting of a particular kind — published by engineers with the A/B methodology described and weak spots admitted (diminishing returns, the CTR-to-order gap), which sharply lowers the risk of marketing embellishment. Separately (a forecast, not a result): per an estimate cited by Forbes, a future AI search assistant could add 3–5% GMV for Ozon within one to two years. This estimate must not be conflated with the measured +0.3% — they are different genres of numbers.

In our view, the case's main value is calibrational. It sets the market a benchmark of honest reporting: the +10% → +10% → +3% sequence shows not only the effect but its decay, and the '+0.3% users with an order' metric shows how expensive each fraction of a percent is on a mature product. When a vendor or integrator promises '+15% conversion from AI in search', this case is a ready-made ruler: one of the country's strongest ML teams, with its own GPU cluster and trillion-ruble GMV, documents an effect an order of magnitude more modest.

The second observation is architectural: in our view, choosing a model of hundreds of millions of parameters over a fashionable 'multi-billion LLM' is exactly what engineering maturity looks like. Ozon picked the minimal architecture that solves the task within a hard latency budget, instead of the maximal one that would solve it in a slide deck.

Lessons learned

1. Real recommender gains are measured in fractions and single percents: +0.3% users with an order at Ozon's scale is a win, while '+14% GMV from personalization' is a fabrication red flag.
2. Latency drives architecture: a 300 ms budget at tens of thousands of RPS dictates both model size (hundreds of millions of parameters, not billions) and the inference stack (TensorRT-LLM).
3. Iterative rollout with measurement at each step (+10% → +10% → +3%) is more honest than one loud release: you see both the effect and its diminishing returns.
4. CTR grows more easily than business metrics: suggestion clickability lifts fast, while carrying the effect through to an order is separate, harder work (Ozon Tech's own observation).
5. Generative suggestions bring new risk classes — broken grammar, duplicates, toxic phrasings, invented brands, suggestions into empty results — and must not ship without a post-processing loop.
6. Personalization is only ≈10% of Ozon's ranking weight: basic signals (popularity, sales, price) still decide more.
7. Publishing modest numbers signals engineering-culture maturity: such sources can be trusted on the rest, too.

Frequently asked questions