AI Search vs Faceted Filters: A CTO’s Decision Framework

TL;DR: Which approach wins, by catalog and query type

Neither AI search nor faceted navigation wins universally, the right answer depends on catalog size and query entropy. For structured catalogs under ~50k SKUs with predictable query patterns, well-tuned faceted navigation still outperforms most semantic search setups on precision and latency. For large, long-tail catalogs where users search by intent rather than attribute, think ‘something cozy for a winter wedding’, AI-powered semantic search closes gaps that BM25 and inverted-index filters can’t. Our team saw this directly with Otodom, where shifting to an AI-driven search and discovery layer drove a 21% conversion lift. If your zero-results rate exceeds 5%, that’s your signal to audit query intent handling before touching anything else.

Why the AI search vs. filters framing is slightly wrong

The question ‘AI search or filters?’ assumes these two things compete. They don’t, they operate at different levels of the stack.

Faceted navigation is a UI layer. It surfaces pre-indexed attribute values: brand, size, price range, material, and lets users narrow a result set by applying Boolean constraints against an inverted index. The mechanics are deterministic: a filter for color:blue returns exactly the documents tagged blue, nothing more.

Semantic search is a relevance layer. It sits upstream of what the user ever sees, transforming a raw query string into a vector embedding, running an ANN lookup against your product index, and scoring candidates before any UI interaction begins. Query intent classification can happen here too, routing ‘waterproof hiking boots under $150’ to a structured attribute query while sending ‘something for a mountain weekend’ through a dense retrieval pipeline.

These two mechanisms can, and usually should, coexist inside a search and discovery layer. Algolia’s NeuralSearch, Bloomreach’s semantic search stack, and Elasticsearch’s hybrid retrieval all reflect the same architectural conclusion: use semantic search to find the right candidate set, then let faceted navigation let users refine it.

The real architectural question is where query intent classification happens, how re-ranking pipelines weigh semantic relevance against business rules, and when to fall back from vector retrieval to BM25. That’s where the meaningful design decisions live, not in a binary choice between AI and filters.

When faceted filters outperform AI search

Faceted navigation outperforms AI search when queries are attribute-dense and the intent is refinement, not discovery. A user searching for “men’s Gore-Tex hiking boots, size 11, under $200” isn’t asking for interpretation, they’re applying constraints. BM25’s exact-match precision and Boolean filter execution handle this faster and more predictably than a vector embedding pipeline that may surface semantically adjacent results the user didn’t ask for.

Three patterns consistently favor filters over AI search:

Small, high-attribute catalogs. A catalog under ~5,000 SKUs with well-structured attributes, size, color, material, price, gives users more signal through faceted navigation than through a query box. Every SKU is discoverable through filtering alone; semantic search adds latency without adding recall.

B2B configurators. When buyers are selecting parts, materials, or specifications with hard compatibility constraints, deterministic filtering is the only safe choice. A vector search that returns “similar” components to a specific bolt spec is a liability, not a feature.

Merchandising-rule-heavy environments. If your team actively manages product ranking, boosting margin items, pinning seasonal stock, suppressing out-of-stock SKUs, faceted navigation with explicit merchandising rules in Algolia, Elasticsearch, or Bloomreach gives you deterministic control. Re-ranking pipelines fed by ML models can conflict with those rules in ways that are difficult to audit.

The triage signal we return to repeatedly in our projects is zero-results rate by query type. Structured, attribute-heavy queries almost never return zero results through a well-built faceted index, the failure mode is over-filtering, not missed recall. That’s a solvable UI problem, not a search architecture problem. When you see zero-results climbing on short, ambiguous queries, that’s the signal that AI search earns its place in the stack.

When AI search wins on conversion

AI-powered search earns its place when your zero-results rate exceeds 5–8% of sessions. At that threshold, your inverted index is telling you something: users are phrasing queries in ways your keyword pipeline can’t resolve, and you’re losing them before they see a single product. In 2026, the same shift is driving deeper AI ecommerce personalization that actually moves conversion, where search relevance, recommendations, and on-site experiences share the same intent signals.

The clearest signal is long-tail and natural language query patterns. Queries like “gifts for someone who hates clutter” or “office chair that won’t hurt my back after six hours” carry intent that BM25 can’t map to SKUs, there’s no shared token between the query and the product catalog. Vector embeddings trained on query-product interaction data close that gap by encoding semantic proximity rather than lexical overlap. Bloomreach’s NLP-based query intent classification goes a step further, routing navigational, transactional, and exploratory queries through different ranking logic before results are assembled.

Cross-category discovery is the other strong case. When a user searches “coastal living room” on a furniture site, the relevant results might span sofas, rugs, lighting, and cushions, none of which match that phrase literally. An ANN search across a joint embedding space surfaces the right products; a faceted filter tree built on product attributes does not. This is the core pattern behind modern hybrid search architectures for ecommerce discovery, where BM25 and vector retrieval work together instead of competing.

We saw this directly with Otodom, a Polish real estate marketplace. After moving to a semantic search layer, the platform recorded a 21% conversion lift (case study), driven largely by users who previously hit dead ends with attribute-only queries finding relevant listings through intent-based matching.

Algolia’s NeuralSearch and Elasticsearch’s approximate nearest neighbor (ANN) kNN API both offer production-grade paths here, with re-ranking pipelines that blend vector similarity scores with business rules like margin weighting or inventory status. The hybrid approach, BM25 plus vector re-ranking, consistently outperforms either in isolation on catalogs above ~50k SKUs — hybrid search delivers 25–40% better relevance scores compared to either lexical or semantic search alone (LinkedIn Pulse (Industry Benchmarks), 2026), which aligns with independent benchmarks of ecommerce search solutions that boost product discovery.

Algolia vs. Elasticsearch vs. Bloomreach: Capability comparison

For large marketplaces, this choice also intersects with taxonomy governance and seller data quality; weak structures can bottleneck any engine, which is why a separate search and discovery optimization playbook for marketplaces focuses so much on taxonomy and attribute hygiene alongside engine selection.

The right vendor depends on where your ops overhead ceiling is and how much catalog ML you need out of the box.

Capability	Algolia	Elasticsearch	Bloomreach
ANN / vector search	NeuralSearch (hosted)	Native HNSW (self-managed)	Embedded, catalog-aware
BM25 baseline	Managed, tunable	Full control via query DSL	Abstracted behind ML layer
Re-ranking pipeline	Rules + AI re-ranking API	Custom (Learning to Rank plugin)	Catalog-ML trained on your SKUs
Merchandising rules	Strong, visual rule builder	DIY via scripted queries	Strong, tied to campaign logic
Zero-results handling	Synonym/fallback rules	Manual configuration	Automated intent fallback
Ops overhead	Low	High	Medium
Time to first result	Hours	Days–weeks	Days

Algolia is the lowest-friction path to hybrid search: BM25 plus vector embeddings via NeuralSearch, with a merchandising UI that non-engineers can operate. The tradeoff is cost at scale and limited control over the underlying ranking model. If your team wants to tune BM25 field weights or build custom re-ranking logic, you’ll hit the ceiling of the hosted abstraction faster than the documentation suggests.

Elasticsearch gives you the most control, HNSW-based ANN, full query DSL, Learning to Rank integration, but that control has a price. Index management, shard tuning, and relevance engineering require dedicated backend resource. We’ve seen teams underestimate this by a factor of two, particularly when adding dense vector fields alongside an existing inverted index; memory overhead climbs quickly.

Bloomreach is the strongest choice when catalog complexity is the core problem. Its ML layer trains on your product graph: attributes, taxonomy, behavioral signals, which means re-ranking improves without manual intervention. The merchandising rules engine connects directly to campaign and promotion logic, which matters for retailers running frequent assortment changes. The tradeoff is less flexibility for teams that want to own the relevance model directly.

For teams already in a composable commerce architecture, Algolia integrates with the fewest moving parts. For catalogs above ~500k SKUs with rich attribute structures, Bloomreach’s catalog-ML advantage compounds over time. If you need help designing this layer end-to-end, our search, discovery, and experience orchestration services focus precisely on these tradeoffs across platforms.

The hybrid architecture: Running both in production

Most production catalogs need both BM25 and vector search running in parallel, the question is what decides which index handles each query.

The pattern we use in our Search & Discovery layer implementations is a query intent classifier sitting upstream of both indexes. The classifier: typically a lightweight model scoring query tokens against intent signals like category terms, attribute patterns, and query length, routes to the BM25 inverted index for navigational and attribute-heavy queries (‘red Nike Air Max 42’), and dispatches to the ANN vector index for semantic or exploratory queries (‘something warm for a winter hike’). Zero-results rate is the fastest triage signal: if a query class returns zero results above a relevance threshold on BM25, the classifier re-routes or fans out to the vector index before the user sees an empty page.

On the Algolia side, NeuralSearch handles this routing internally, which reduces orchestration complexity but limits control over re-ranking pipelines. Elasticsearch gives you full control over the HNSW graph parameters and query DSL, but you own the ops. Bloomreach abstracts both behind its catalog-aware ML layer, useful when your merchandising team needs to tune without touching index config. In parallel, some teams layer a conversational AI product discovery assistant on top of these engines, turning the same semantic and catalog signals into guided, chat-style journeys.

The tradeoff we hit during the L’Occitane Shopify Plus migration: their existing faceted navigation was tightly coupled to product taxonomy IDs, which meant vector embeddings trained on product descriptions couldn’t reliably surface the same facet groupings. We had to maintain parallel facet indexes during transition and build a reconciliation step before the semantic results could feed the same Discovery layer facet rail.

In a composable commerce architecture, the Search & Discovery layer sits between the catalog service and the storefront. Keeping the query router stateless makes it portable across Algolia, Elasticsearch, or Bloomreach backends without rewriting frontend contracts.

Diagnose before you migrate: Search metrics that matter

Before you even shortlist platforms, treat this as an AI vendor decision problem: the same due-diligence steps you’d use to evaluate AI vendors as a CTO apply to search providers, from data governance to model update cadence.

Before migrating to semantic search or redesigning your faceted navigation, pull four numbers from your analytics stack. These tell you where the problem actually lives.

Metric	Threshold	What it signals
Zero-results rate	>8%	Query vocabulary mismatch, BM25 failing on long-tail or synonym-heavy queries
Query reformulation rate	>15%	Users aren’t finding intent-matched results on first try
Filter click depth	>3 facets applied per session	Shoppers compensating for weak ranking with manual narrowing
Revenue-per-search	Declining vs. last quarter	Ranking or relevance degrading as catalog grows

A zero-results rate above 8% is our first triage signal in any Search & Discovery layer audit. We saw this consistently in projects before introducing vector embeddings, users were searching with natural language that the inverted index had no term overlap for. On the Otodom engagement — where the platform ultimately achieved 116% growth in subscription rate to saved search notifications — high reformulation rate was the early indicator that query intent classification was missing, not that the underlying index was wrong.

Filter click depth is the metric most teams underweight. When users apply four or more facets in sequence, they’re doing the ranking job your search layer should handle. That’s not a faceted navigation success story, it’s evidence the first-page results weren’t trusted.

Product catalog size adds a compounding factor: above roughly 50,000 SKUs, approximate nearest neighbor (ANN) recall degradation becomes measurable in A/B tests, and BM25 long-tail coverage gaps widen. Below that threshold, well-tuned Elasticsearch or Algolia relevance rules often outperform a semantic layer with insufficient training signal. Treat any major change in this area like an application migration process: plan cutovers, rollback paths, and data backfills as carefully as you would for core transactional systems.

Implementation complexity and migration cost realities

Before committing to a platform, size the engineering work honestly. These are rough estimates based on our team’s delivery experience, not vendor sales decks.

Platform	Time to first results	Ops overhead	Onboarding complexity	Best fit
Algolia	2–4 weeks	Low (fully managed)	Low, REST API, pre-built UI components	Teams that need fast time-to-value
Elasticsearch (self-hosted)	6–12 weeks	High, cluster tuning, index management, vector ANN config	Medium-High	Teams with dedicated infra capacity
Bloomreach	10–16 weeks	Medium (SaaS, but config-heavy)	High, merchandising rules, catalog taxonomy, ML model warm-up	Enterprises with complex catalog logic

Algolia is the fastest path to a working search and discovery layer, but you trade control for convenience, custom re-ranking pipelines and vector embedding strategies hit the ceiling of their API surface quickly. Elasticsearch gives you full control over BM25 weighting, hybrid retrieval, and ANN index tuning, but the ops cost is real: we’ve seen self-hosted clusters consume a third of a sprint just in maintenance during high-traffic periods.

Bloomreach’s onboarding length isn’t a flaw, it reflects how deeply the platform models catalog relationships. On a Shopify Plus migration, that configuration investment pays back in faceted navigation accuracy and zero-results rate reduction, but only after month three. Marketplaces in particular benefit when this work is paired with disciplined search and discovery optimization for multi-seller catalogs, where taxonomy and attribute cleanup power the ML gains.

The migration risk that catches teams off guard: index warm-up. A freshly configured semantic search model has no behavioral signal, so conversion rate often dips for the first four to six weeks before the re-ranking pipeline learns from click and purchase data.

Decision framework: Choosing your search architecture

Three variables drive the right architecture: catalog size, query entropy, and your team’s ops maturity. Map your position in the table below.

Catalog size	Query entropy	Ops maturity	Recommended approach
<10k SKUs	Low (structured queries, clear intent)	Any	Faceted navigation + BM25 (Algolia or Elasticsearch)
<10k SKUs	High (natural language, vague intent)	Any	Add semantic search layer; keep filters as fallback
10k–500k SKUs	Mixed	Medium–High	Hybrid: BM25 + vector embeddings with re-ranking pipeline
>500k SKUs	Mixed	High	Full semantic search with query intent classification (Bloomreach or Elasticsearch with ANN)

Zero-results rate is your fastest triage signal. If zero-results rate exceeds 5–8% of sessions, your search and discovery layer is failing on query intent, BM25 alone won’t fix it. Semantic search addresses this directly by matching intent rather than tokens.

For teams on Algolia, NeuralSearch covers the hybrid case without custom infrastructure. Elasticsearch gives more control but requires your team to own the re-ranking pipeline. Bloomreach adds merchandising logic on top of semantic relevance, which matters once catalog complexity outgrows manual rules.

If your faceted navigation conversion rate is healthy but zero-results rate is climbing, the problem is almost always query entropy, not the filter taxonomy.

Frequently asked questions

When should I use AI search instead of faceted filters in e-commerce?

Switch to AI-powered semantic search when your zero-results rate exceeds 5–8% or when query logs show high natural-language and intent-based queries your faceted navigation can’t resolve. For catalogs with low query entropy and well-structured attributes, faceted navigation still converts better.

How does Algolia compare to Elasticsearch and Bloomreach for e-commerce search?

Algolia wins on time-to-production and relevance tuning with minimal ops overhead. Elasticsearch gives you full control over BM25 weighting, vector embeddings, and re-ranking pipelines, but demands dedicated search engineering. Bloomreach targets mid-to-enterprise merchandising teams who need ML-driven personalization baked into the search and discovery layer without custom model work.

What conversion rate improvement can I expect from AI-powered search?

Expect 10–30% lift in search-driven conversion when moving from pure keyword matching to hybrid semantic search, but only if query intent classification and re-ranking are tuned to your catalog. Raw model swaps without relevance tuning routinely underperform. +15% conversion rate lift from GenAI search vs. keyword search (Bloomreach, 2024). Similar lifts show up when generative AI powers personalized product recommendations at scale, because search relevance and recommendations share the same intent and behavior signals.

Can I run semantic search and faceted navigation at the same time?

Yes, hybrid architecture is standard practice. Semantic search handles query understanding via vector embeddings and ANN retrieval; faceted navigation refines the result set post-retrieval. Algolia NeuralSearch and Elasticsearch’s knn + BM25 hybrid both support this natively.

How do I know if my current search is hurting conversion before I migrate?

Pull three metrics from your search analytics: zero-results rate, search exit rate (users who search then leave), and search-to-purchase rate versus browse-to-purchase rate. A zero-results rate above 8% or a search exit rate above 40% are clear signals your current setup is costing you revenue. 12–24% of searches return zero results on many eCommerce sites (Findbar, 2026), which is why independent reviews of ecommerce search platforms that improve product discovery pay so much attention to zero-results handling.

Next steps: Audit your search layer with Netguru

If your zero-results rate is above 5%, your search and discovery layer is actively suppressing conversion rate, and a misconfigured re-ranking pipeline or missing semantic search fallback is usually the cause. Our search, discovery, and experience orchestration services are designed to identify exactly these issues and align your architecture with your growth targets.

Our team has run this audit across multiple commerce platforms, including a search and discovery layer build for Openbooks — a digital ebook distribution platform that reached 84,916 downloads. The patterns repeat: faceted navigation gaps, no vector embedding fallback for long-tail queries, and Elasticsearch or Algolia configurations that were never tuned past initial deployment. For many retailers, tightening search is the fastest lever before replatforming, but if you’re already exploring top ecommerce development partners for 2026 or evaluating order management systems to support growth, bake these search requirements into your vendor and tooling selection from day one.

If you want a structured review of your current search architecture: covering query intent classification, zero-results rate, and hybrid search readiness, we can scope one quickly.