Page 4 - Elasticsearch

Dense vector search requires an embedding model, an inference pipeline, and usually its own GPU infrastructure before the very first semantic query can even be answered. For many teams that exact hurdle is the reason semantic search gets shelved despite its benefits. ELSER, short for Elastic Learned Sparse EncodeR, takes a different approach: instead of turning text into a dense vector of several hundred numbers, the model produces a weighted list of relevant terms, comparable to an automatically expanded and weighted word list. The result can be searched with the same inverted index structures Elasticsearch already uses for classic text search. This article explains how ELSER works technically, how sparse vectors differ from dense vectors, and what practical product search adoption looks like without in-house machine learning infrastructure.

A search that finds "laptop" but returns nothing for "notebook", or that treats "running" and "ran" as completely different words, loses users before the first click. Synonyms and stemming solve exactly this problem when combined correctly in the analyzer, but the details of synonym_graph, stemmer type and language selection decide whether the search becomes more precise or just fuzzier.

"Why does product B rank above product A, even though A is the better match?" is one of the most common questions in day-to-day relevance work, and without a systematic tool the answer remains guesswork. The Explain API exposes exactly which individual terms, weights and boosts make up a BM25 score, turning scoring debugging from guessing into analysis.

The Magento CatalogSearch architecture looks like a black box from the outside: you update an attribute, wait for the reindex, and hope search returns the right result. Understanding how the indexer, fulltext scope tables and the Elasticsearch adapter work together lets you debug, extend and fix performance issues at the right place instead of chasing symptoms.

The default Layered Navigation filters are fine for simple catalogs, but quickly hit their limits with range sliders, multi-level AND/OR logic, or category specific facets. Truly customizing Layered Navigation in Magento 2 requires understanding FilterList, FilterableAttributeList and the OpenSearch aggregation layer before writing any custom code.

One store view per language is not enough to truly run clean multilingual search in Magento. Only store-view-based index naming combined with language-specific Elasticsearch analyzers prevents German compound words from being split incorrectly or English stemming rules from being applied to French text.

Every filter option in Magento layered navigation, from brand selection to the price slider, is the result of an Elasticsearch aggregation computed in the background alongside the actual search request. Understanding how terms and range aggregations are built lets you add your own facets and fix navigation performance issues at the right place.

For businesses with a physical location or a regional service area, visibility often depends less on classic domain authority and more on a well-maintained Google Business Profile combined with local ranking factors. Businesses that manage both systematically tend to dominate the local results snippet many users see first.

A shared Elasticsearch index often contains documents that not every user role should see in full. A product document, alongside public fields like name and description, frequently carries internal data such as purchase prices, supplier terms, or margin calculations meant only for certain departments. Maintaining separate indices for every visibility level is costly to operate and error-prone whenever roles or data models change. The Elasticsearch security API solves this directly at the role level with two complementary mechanisms: field-level security hides individual fields from the response for certain roles, while document-level security makes entire documents invisible through a query filter before they ever reach the result list. How both mechanisms are configured, how they combine, and which pitfalls lurk around aggregations and performance is what this article covers using a practical example with role-dependent purchase prices.

Classic text search finds documents that contain the same words as the query. It does not recognize that a search for waterproof jacket should also match a product called weatherproof outdoor coat, even though not a single word overlaps. Vector search solves exactly this problem: text is represented as embeddings, points in a high dimensional space, and similar meaning translates into spatial closeness. The real challenge starts afterward, because finding the nearest neighbor across millions of vectors is expensive. Approximate kNN with the HNSW algorithm solves this scaling problem by trading a small accuracy loss for enormous speed gains. This article explains how HNSW works technically, where exact kNN still has its place, and how the two central levers, num_candidates and the similarity metric, are configured in practice.