Nearly one in five on-site searches at this retailer returned zero results, and every one of those empty result pages was a customer walking out of a store that had the product in stock. The client, a leading multi-category ecommerce enterprise processing several million search queries a day, was quietly losing revenue at the exact moment shoppers signalled the highest intent. Their search box was powered by lexical keyword matching and a decade of hand-curated synonym dictionaries, and it simply could not understand what people were actually asking for. When KriraAI engaged, the mandate was direct: apply our AI development services to rebuild product discovery so that AI-powered ecommerce search became a growth engine rather than a leakage point.

This blog is the full account of that engagement. We walk through the operational problem the client was living with, the neural search platform KriraAI designed and shipped to production, the complete solution architecture layer by layer, the technology stack and the reasoning behind each choice, the implementation journey including the challenges we hit, and the measurable results the client achieved in the first ninety days after go-live. It is written for engineers and executives who have read shallow AI content before and want to see how a hardened system is actually built.

The Problem KriraAI Was Called In To Solve

The client sold across dozens of product categories, from apparel to electronics to home goods, with a catalogue exceeding two million active SKUs. Search drove roughly 43 percent of their online revenue, which meant the search box was one of the most commercially important surfaces in the entire business. Yet that surface was running on an Elasticsearch cluster configured almost entirely around BM25 lexical scoring, a large synonym file, and a growing pile of manual merchandising rules layered on top.

The core failure was semantic. A shopper searching for a warm winter coat would receive nothing if the product titles said parka, and a query like shoes for standing all day returned noise because the engine matched tokens rather than meaning. Long-tail and natural-language queries, which made up a rising share of traffic as customers shifted to conversational phrasing, were exactly where the system was weakest. The data to fix this existed, sitting in years of clickstream and conversion logs, but it was being discarded rather than used to teach the ranking function what shoppers valued.

Why Keyword Search Was Quietly Losing Revenue

The measurable symptom was a zero-results rate hovering around 18 percent and a search-to-purchase conversion rate that had flatlined for six consecutive quarters. Each empty result page carried a compounding cost because a customer who fails to find a product once is far less likely to search again in the same session. Internal analysis had already tied a meaningful portion of cart abandonment back to poor discovery rather than pricing or availability. The business understood the leakage was real but had no engineering path to close it with the existing Lexical stack.

The Hidden Cost of Manual Merchandising

Behind the search box sat a team of merchandisers maintaining synonym lists, promoting products, and burying others through handwritten rules. This work was slow, brittle, and impossible to scale across a two-million-SKU catalogue that changed daily as inventory turned over. Every new product category or seasonal shift required fresh rules, and conflicting rules frequently produced ranking behaviour that no single person could fully explain. The competitive pressure made this unsustainable because newer entrants were already investing in retail technology solutions built around learned ranking, and the client's discovery experience was visibly falling behind.

What KriraAI Built

KriraAI designed and delivered a production neural search and ranking platform that replaced lexical-only retrieval with a hybrid system combining dense semantic retrieval, learned re-ranking, and real-time personalization. The platform is the reason the client can now interpret intent rather than match tokens, and it is the foundation on which their entire discovery experience now runs. As an AI solutions company that ships production systems rather than proofs of concept, KriraAI built this to handle full catalogue scale from day one, not to demonstrate feasibility in a sandbox.

At the heart of the system is a two-tower architecture. A fine-tuned transformer bi-encoder converts both the shopper query and every product in the catalogue into dense vector embeddings that live in the same semantic space, so that a query and a relevant product sit close together even when they share no literal words. This is the mechanism that lets semantic search for e-commerce understand that a warm winter coat and an insulated parka are the same intent. Product embeddings are precomputed and indexed, while query embeddings are generated at request time in single-digit milliseconds.

The end-to-end flow was designed as a staged funnel so that quality and latency could both be honoured. Retrieval, ranking, and personalization each operate on a progressively smaller candidate set, which keeps expensive models off the hot path.

How a Query Becomes a Ranked Result

When a shopper submits a query, the platform executes a precise sequence rather than a single lookup. The following stages describe exactly how an incoming query becomes a personalized, ranked result page.

The query understanding layer runs spell correction, intent classification, and named entity recognition to extract brands, categories, price signals, and attributes from the raw text.
A hybrid retrieval stage runs dense vector search alongside a BM25 lexical pass, then fuses the two candidate lists using reciprocal rank fusion so that neither semantic nor exact-match signals are lost.
A transformer cross-encoder re-ranks the top few hundred candidates by scoring each query-product pair jointly, which captures fine-grained relevance that the bi-encoder cannot.
A gradient-boosted learning-to-rank model produces the final ordering by blending relevance scores with personalization features, margin, inventory depth, and conversion likelihood.
The ranked results are returned to the storefront through a low-latency service contract, with the whole pipeline completing well inside the client's latency budget.

This staged design is what allowed KriraAI to deliver both accuracy and speed, because the heavy cross-encoder only ever sees a few hundred candidates rather than two million. The learned ranker also absorbed the business logic that merchandisers used to encode by hand, turning static rules into signals the model optimises against outcomes. The result is a system that improves as it observes more behaviour rather than one that decays as rules accumulate.

Solution Architecture: Inside the AI-Powered Ecommerce Search Platform

The architecture of this AI-powered ecommerce search platform was built as six connected layers, each with a specific engineering responsibility and a clear contract with the layers around it. We designed every layer to fail independently, scale independently, and be observed independently, because production search cannot afford a monolith where one slow component stalls the entire request path. The sections below walk through each layer, the decisions behind it, and how it connects to the rest of the system.

[Suggested visual: high-level architecture diagram showing ingestion, ML core, serving, and integration layers]

Data Ingestion and Pipeline

The ingestion layer had to keep a two-million-SKU catalogue and a high-volume clickstream continuously synchronised with the search index. KriraAI implemented change data capture from the client's operational product database using Debezium, streaming catalogue mutations into Apache Kafka so that new products and price or stock changes were propagated to the index within seconds rather than nightly batches. Clickstream events, including searches, clicks, add-to-carts, and purchases, were ingested through the same Kafka backbone and processed in real time by Apache Flink to compute session and behavioural features. Full catalogue extraction from the client's PIM and ERP systems ran as scheduled batch jobs for reprocessing and backfill.

Transformation logic in this layer went well beyond loading rows. We implemented schema normalisation across inconsistent category feeds, entity resolution to collapse duplicate SKUs listed by different suppliers, and embedding generation at ingestion time so that every new product entered the vector index already vectorised. Batch orchestration ran on Apache Airflow, with each pipeline expressed as a versioned DAG covering catalogue enrichment, embedding regeneration, and model retraining. Warehouse-side transformations were managed in dbt to keep the offline feature definitions consistent with what served online.

The AI and Machine Learning Core

The machine learning core, built on the same principles behind KriraAI's custom machine learning development services, was the technical centrepiece, combining several model families rather than relying on one. The bi-encoder was a transformer sentence-embedding model fine-tuned on the client's own query and catalogue corpus using contrastive learning, with in-batch negatives supplemented by hard negatives mined directly from click logs where shoppers saw a product but did not engage. This hard-negative mining was decisive because it taught the encoder the subtle distinctions between products that look similar lexically but satisfy different intents. Distributed fine-tuning ran across an A100 GPU cluster using PyTorch with mixed-precision training and FSDP sharding to fit larger batch sizes.

Dense vectors were served through vector search for e-commerce built on an HNSW index, which gave sub-millisecond approximate nearest neighbour retrieval at catalogue scale while keeping recall high. For memory efficiency on the largest category partitions, we evaluated IVF-PQ quantisation and applied it selectively where the recall tradeoff was acceptable. The cross-encoder re-ranker and the query understanding models were served through Triton Inference Server, with encoders compiled to TensorRT and quantised to reduce p99 latency. A separate LLM-based enrichment pipeline, served with vLLM, generated normalised structured attributes from unstructured product descriptions, grounded against the client's category taxonomy so the model filled gaps rather than inventing values.

Integration Layer

The integration layer connected the search platform to a headless storefront and to the client's downstream merchandising and analytics systems. The primary search contract was exposed over gRPC for low-latency internal service communication, wrapped by a GraphQL gateway that the frontend consumed, with strict API versioning so the storefront and the search service could evolve independently. Ranking outcomes, model decisions, and search analytics were published back onto Kafka topics, and webhook-based triggers pushed relevant events into the merchandising console and the client's data warehouse. This event-driven design meant the AI outputs reached the people and systems that acted on them without tight coupling that would have made either side fragile.

Monitoring and Observability

We treated monitoring as a first-class part of the e-commerce AI search implementation rather than an afterthought bolted on before launch. Data drift was tracked using the population stability index and KL divergence across the query distribution and the embedding space, so that a sudden shift in how shoppers phrased searches would raise an alert before it degraded relevance. Model quality was measured offline against a human-judged evaluation set using NDCG at 10 and MRR, and online through search conversion, click-through, and zero-results rate. Latency was tracked at p50, p95, and p99 across every stage of the funnel, and automated retraining triggers fired when relevance metrics crossed defined thresholds. The observability stack combined Prometheus and Grafana for metrics, OpenTelemetry for distributed tracing, Evidently for drift reporting, and MLflow as the experiment tracker and model registry.

Security and Compliance

Security was designed around the reality that clickstream and personalization data are sensitive, and that ecommerce carries regulatory weight. The platform ran inside a private VPC with no public endpoints, service-to-service traffic secured with mutual TLS, and all model inputs and outputs encrypted in transit and at rest. Access followed role-based access control with attribute-level masking, so that personalization features derived from customer behaviour were masked from operators who did not need them. Every ranking decision and configuration change was written to an immutable append-only audit log, and the data handling was aligned with GDPR and CCPA consent requirements alongside PCI DSS boundaries for the surrounding commerce environment.

Merchandising Console and Delivery

The delivery surface for internal users was a React-based merchandising console that gave the client's teams visibility and controlled influence over a learned system. Rather than writing brittle rules, merchandisers could apply boosts, inspect why a product ranked where it did, review search analytics, and configure business constraints that the ranker then optimised around. Every change was routed through an A/B testing framework so that no adjustment reached full traffic without measured evidence that it helped. This kept humans in the loop for strategy while removing them from the slow, manual work that had previously defined their days.

The Technology Stack and Why We Chose It

Every technology in this stack was selected against the client's existing environment, their scale, and their latency and compliance constraints, the same disciplined evaluation KriraAI applies through its deep learning consulting services, not chosen for novelty. The stack below is organised by layer with the rationale for each major decision.

Apache Kafka and Debezium were chosen for ingestion because the client already needed near-real-time catalogue synchronisation, and change data capture avoided the stale-index problem that nightly batch loading had caused.
Apache Flink handled stream processing because behavioural features had to be computed on live sessions, and Flink's stateful streaming outperformed the micro-batch alternatives the team had considered.
A fine-tuned transformer bi-encoder was selected over off-the-shelf embeddings because generic models underperformed badly on the client's domain vocabulary, and contrastive fine-tuning on their own logs closed that gap.
An HNSW vector index was chosen for vector search for e-commerce because it delivered the recall and latency profile the catalogue demanded, with IVF-PQ applied only where memory pressure justified the recall tradeoff.
Triton Inference Server with TensorRT was selected for model serving because compiling and quantising the encoders was the cleanest path to holding p99 latency under the client's strict budget.
Feast backed the feature store with Redis for online serving and the warehouse for offline training, guaranteeing that features seen during training matched those served at inference and eliminating training-serving skew.
Airflow orchestrated batch pipelines because the client's data team already had operational familiarity with it, which lowered the handover cost and shortened the time to independent operation.

This deliberate alignment with the client's existing skills and infrastructure is a core part of how KriraAI reduces long-term operational risk, because a brilliant system nobody on the client side can run is a liability rather than an asset.

How We Delivered It: The Implementation Journey

The engagement ran from the first discovery session to full production rollout across a little over five months, structured into distinct phases so that risk was retired early. KriraAI approaches delivery as a sequence of provable milestones rather than a single big-bang launch, which is why the client saw measured evidence of value long before the system reached full traffic.

Discovery, Data Audit, and Architecture Design

The first phase was a rigorous data audit rather than a whiteboard architecture exercise. We profiled the catalogue, the clickstream, and the existing synonym and merchandising rules to understand exactly what signal was available and what was missing. That audit shaped the architecture design that followed because the discovery of widespread missing and inconsistent product attributes directly informed the decision to build the LLM enrichment pipeline. By the end of this phase, the client had a concrete architecture, a phased delivery plan, and a shared understanding of the offline and online metrics that would define success.

The Challenges We Hit and How We Solved Them

No honest ecommerce AI search implementation is free of friction, and this one had three challenges worth naming. The first was data quality, where roughly a third of the catalogue had sparse or inconsistent attributes that crippled both retrieval and faceting, which we solved by shipping the taxonomy-grounded LLM enrichment pipeline that normalised attributes at ingestion. The second was latency, because the cross-encoder that gave us the largest relevance gains was too slow at full candidate volume, which we resolved by strictly capping it to the top few hundred candidates, compiling it to TensorRT, and caching results for high-frequency queries. The third was integration rework, since the legacy search was tightly coupled to the storefront in ways that only surfaced during shadow testing, and untangling that coupling required an additional service boundary we had not originally scoped.

Delivery moved through shadow deployment before any customer saw a change. We ran the new platform in parallel against live traffic, comparing its rankings to production without serving them, which let us catch quality regressions safely. Only after the shadow numbers held did we begin a staged A/B rollout, expanding traffic in controlled increments while watching conversion and latency. Final handover included full MLOps runbooks, retraining automation, and hands-on enablement so the client's team could operate and evolve the platform independently.

Results the Client Achieved

The results were measured over the first ninety days after full go-live, compared against the ninety days immediately preceding rollout. The zero-results rate fell from around 18 percent to 3.2 percent, an 82 percent reduction that recovered a large volume of previously lost sessions. Search-to-purchase conversion rose 34 percent, and search-driven revenue increased 27 percent over the same window, delivering the ee-commerceconversion optimization with AI that had motivated the entire engagement.

The relevance gains showed up clearly in the offline metrics as well as the commercial ones. NDCG at 10 on the human-judged evaluation set improved from 0.61 to 0.83, and the add-to-cart rate from search results climbed 41 percent. On the operational side, the manual effort spent maintaining synonym lists and merchandising rules dropped by roughly 70 percent, which let the client redeploy experienced merchandisers from repetitive rule-writing onto higher-value assortment and pricing strategy. Serving performance held throughout, with p95 search latency staying under 120 milliseconds even at peak traffic.

Taken together, these outcomes moved search from a source of quiet revenue leakage to a compounding growth surface. Because the ranker now learns continuously from behaviour, the improvement did not plateau at launch but continued as the model observed more interactions. This is the difference between a static rules engine that decays and a learned system that strengthens with use.

What This Architecture Makes Possible Next

The platform was engineered as a foundation rather than a point solution, which means the client can extend it without rebuilding. When catalogue and query volume grow, the vector index and the serving layer scale horizontally, and the ingestion pipeline already handles change data capture at the rate the business generates it. Adding a new product category requires no new hand-written rules, because the encoder and ranker generalise from behaviour and the enrichment pipeline normalises new attributes automatically.

The same embedding and ranking foundation directly enables adjacent use cases the client is now pursuing. Personalized recommendations, similar-item discovery, and semantic merchandising all reuse the vector search for e-commerce infrastructure that already exists, which turns each new capability into an extension rather than a fresh project. The client's roadmap over the next two to three years builds conversational shopping and visual search on top of this core, since both are natural additions once queries and products share a learned semantic space. KriraAI structured the handover and the MLOps automation specifically so the client's own team can drive that roadmap.

Other ecommerce businesses can take a clear lesson from this architecture. The highest-leverage move is usually not a chatbot bolted onto the storefront but a rebuilt discovery layer, because search and recommendations sit closest to purchase intent and respond fastest to better modelling. A hybrid retrieval and learned ranking design, combined with disciplined MLOps and honest offline evaluation, is a repeatable pattern that generalises across catalogues and categories.

Conclusion

Three insights define this engagement. Technically, the decisive move was hybrid retrieval paired with a staged learned ranker, because it delivered both the semantic understanding that keyword search lacked and the sub-120-millisecond latency that production traffic demanded. Operationally, the system converted a slow, manual merchandising function into a learned one, cutting rule-maintenance effort by roughly 70 percent and freeing experienced people for strategic work. Strategically, treating search as a foundation rather than a feature is what turned a single project into a platform the client now extends toward recommendations, visual search, and conversational shopping.

This is how KriraAI works on every engagement, combining principal-level AI engineering with the delivery discipline that gets hardened systems into production and keeps them there. We build for the realities of enterprise scale, existing infrastructure, and regulatory constraint, and we hand over systems that the client's own team can operate and evolve with confidence. The rigour you have read here, from contrastive fine-tuning and drift monitoring to private VPC deployment and staged rollout, is our standard rather than our exception. If your discovery layer, or any part of your operation, is losing value that an AI-powered ecommerce search or a similar system could recover, bring that challenge to KriraAI, and we will architect the solution with you.

AI-Powered Ecommerce Search: A Real Case Study in Results