What business result is at stake
On a marketplace, search is not a feature but the primary revenue channel. A shopper arrives with a query, and if the first results page does not match their intent, the session ends without an order. The metric search directly moves is the share of successful search sessions: how many queries led to a click, add-to-cart, or purchase. For a catalog with millions of SKUs, even a few percent growth in this metric turns into a noticeable GMV delta.
Below is an open breakdown, not tied to any specific KT.Team implementation, of what Elasticsearch can do for this task. This is a review based on public Elastic sources and independent cases, not a description of our project.
Why one type of search cannot cover a marketplace catalog
Marketplace queries are diverse. Some are exact: SKU, model "WH-1000XM5", brand name. Here BM25 lexical search with exact token matching is needed: SKUs and model codes are out-of-vocabulary tokens that pure vector kNN search fails on. Other queries are intent-driven and conversational: "warm jacket for the city", "what to give a 5-year-old child". Here vector (semantic) search wins because it understands synonyms and intent.
Hybrid search combines both mechanisms in one pipeline. On the public WANDS e-commerce dataset, baseline BM25 and pure kNN are statistically indistinguishable (NDCG 0.6983 versus 0.6953), while a properly tuned hybrid reaches NDCG 0.7497 - about a 7.4% relevance gain over either approach alone (softwaredoug.com).
How this is built in Elasticsearch
The key merging technique is Reciprocal Rank Fusion (RRF). Lexical and vector queries run in parallel, and their results are combined by rank, not raw scores, otherwise different relevance scales would fight each other. In modern Elasticsearch, this is expressed through composable retrievers: `standard` wraps any Query DSL request, `knn` handles vectors, `rrf` merges multiple ranked lists, and `text_similarity_reranker` adds a final cross-encoder reranking pass.
At the scale level, Elastic claims support for more than 200 million SKUs and traffic peaks that "break most SaaS providers," with autoscaling and geo-distributed cluster redundancy (elastic.co). For a marketplace, this means the architecture will not need to be rewritten as the catalog grows - a quality KT.Team calls portability and reliance on a mature international standard instead of a custom-built engine.
Personalized ranking via Learning to Rank
Hybrid search returns a relevant candidate set. Next, it has to be ranked for a specific shopper - that is the job of Learning to Rank (LTR). Instead of manually tuning weights, LTR trains a statistical model, typically XGBoost gradient boosting, to find the optimal balance of factors from judgment lists built from clicks and conversions.
Elastic identifies four groups of ranking factors (elastic.co/search-labs):
- Text similarity: BM25, dense and sparse vectors, cross-encoder across multiple document fields.
- Query properties: language, entities, detected intent.
- Product properties: popularity, price, margin, freshness (via `function_score`).
- User context: geolocation, search history, preferences.
Personalization is built on behavior: historical interactions are aggregated, for example category frequencies, smoothed, and stored in a feature store - a separate Elasticsearch index from which values are fetched via the Get API both during training and at search time.
What public cases show
Travel marketplace Secret Escapes built LTR ranking on top of OpenSearch/Elasticsearch using about 200 features: offer amenities, price range, user activity, and propensity to repurchase. Judgment lists were generated daily through dbt with a 0-4 scale (no response / click / form open / conversion), the model was automatically retrained in Airflow and trained on SageMaker. SHAP analysis showed that the dominant contribution to the gain came from the dot product of latent factors from ALS user-item matrix factorization - more than any explicit feature. The main A/B metric was conversion from "search -> booking" (infinitelambda.com).
Elastic also cites aggregate figures from its implementations: 293% ROI and more than 25% lower total cost of ownership; in the HSE retailer case, website CTR increased by 4% (elastic.co).
An implementation sequence that reduces risk
Elastic explicitly warns that personalization cannot be turned on from scratch. Three prerequisites are needed first: working LTR for general search, reliable collection of behavioral telemetry, and judgment lists built from clicks that you trust. The practical path is to start with a small number of features, measure the effect, and expand the model only after a confirmed gain.
Business process takeaway
Marketplace search turns from a "matching engine" into a managed conversion-growth process. The flow is this: hybrid retrieval (BM25 + vectors merged through RRF) ensures recall and precision of the candidate set, an LTR model ranks it for the shopper's intent and profile, and behavioral telemetry from the feature store closes the loop and retrains the model daily. The key management metric is the share of search sessions that reach the target action, and that is the metric that should be used in the A/B test for every ranking change.
