HNSW Explained: How Vector Search Finds Relevant Grocery Content at Scale (2026 Guide)

Q: What is kNN?

kNN in vector search generally refers to finding:

Q: Why use approximate search?

Because exhaustive vector comparison can become:

Q: What does efSearch control?

In implementations that expose it, it affects:

Grocery Growth

Aug 30

20 min read

Imagine a grocery AI system has:

5 million embedded pieces of information.

Those vectors might represent:

Products
Product descriptions
Grocery departments
Store locations
Services
Recipes
Weekly-ad offers
FAQs
Educational articles
Individual passages from webpages

A shopper asks:

What cheese melts well on burgers but isn't too sharp?

The system converts that query into an embedding.

Now it needs to find:

vectors representing semantically similar information.

One theoretically straightforward approach would be:

compare the query against every vector.

If there are five million vectors, that could mean evaluating similarity against:

five million candidates.

At sufficiently large scale, exhaustive comparison can become computationally expensive.

This is the problem addressed by approximate nearest neighbor search, or ANN.

And one of the most important ANN algorithms used in modern vector-search infrastructure is:

HNSW — Hierarchical Navigable Small World.

HNSW organizes vectors into a multilayer proximity graph. Search begins in sparse upper layers, makes relatively large movements through the vector space, and progressively descends into denser layers where the search becomes more local.

The original HNSW research by Yu. A. Malkov and D. A. Yashunin describes a hierarchical collection of proximity graphs where upper layers provide longer-range navigation and lower layers provide increasingly fine-grained search.

The intuition is remarkably simple:

Do not inspect every destination. Build a navigable map that helps you reach promising neighborhoods quickly.

For grocery AI search, that could mean moving efficiently through an enormous collection of product, department, location, recipe, and service embeddings until the system reaches:

semantically nearby candidates.

But HNSW needs to be understood correctly.

HNSW does not:

Understand grocery businesses by itself
Create embeddings
Determine whether information is true
Know whether inventory is current
Resolve every entity
Generate an AI answer
Decide which source deserves citation

HNSW solves a much narrower infrastructure problem:

How can a system efficiently search a large collection of vectors for nearby candidates without exhaustively comparing the query against every stored vector?

That is the central principle of this guide:

Embeddings create the semantic space. HNSW builds roads through that space.

What Is HNSW?
What Does HNSW Stand For?
The Problem HNSW Solves
Exact Nearest Neighbor Search
Approximate Nearest Neighbor Search
Why Approximation Matters
HNSW as a Graph
Nodes and Edges
The “Small World” Idea
Why HNSW Is Hierarchical
Upper Layers vs Lower Layers
How HNSW Search Works
Step 1: Enter the Graph
Step 2: Navigate the Upper Layers
Step 3: Descend Through the Hierarchy
Step 4: Explore Local Neighbors
Step 5: Return Candidate Neighbors
Grocery Product Search Example
Grocery Content Retrieval Example
Location Search Example
Department Search Example
Recipe Search Example
HNSW vs Brute-Force Vector Search
HNSW vs Vector Embeddings
HNSW vs Cosine Similarity
HNSW vs Vector Databases
HNSW vs Dense Retrieval
HNSW vs Sparse Retrieval
HNSW and Hybrid Retrieval
HNSW and Bi-Encoders
HNSW and Cross-Encoders
HNSW and Multi-Stage Retrieval
HNSW and RAG
HNSW and Context Selection
HNSW Recall
Search Speed and Recall
The M Parameter
The efConstruction Parameter
The efSearch Parameter
Memory Requirements
Filtering
Dynamic Grocery Data
Product Inventory
Weekly Ads and Promotions
The Grocery HNSW Navigation Model
The Grocery Vector Search Stack
The SCALE Framework
What HNSW Cannot Determine
What Grocery Marketers Can Control
What Grocery Marketers Cannot Control
Does Google Use HNSW?
Does ChatGPT Search Use HNSW?
Common HNSW Myths
Grocery Vector Retrieval Checklist
Frequently Asked Questions
Final Thoughts

What Is HNSW?

HNSW is a graph-based algorithm for:

approximate nearest neighbor search.

It is designed to efficiently find vectors that are:

close to a query vector

according to a chosen distance or similarity measure.

The original HNSW paper describes the algorithm as a fully graph-based approach using a hierarchy of proximity graphs. Elements can appear across multiple layers, with upper layers providing coarser navigation and lower layers providing finer neighborhood search.

Today, HNSW is implemented in major vector-search technologies.

For example, OpenSearch currently supports HNSW through engines including Lucene and Faiss, with supported similarity spaces depending on the implementation.

Elastic also uses HNSW for approximate k-nearest-neighbor vector search.

What Does HNSW Stand For?

Hierarchical

The graph contains:

multiple layers.

Navigable

The connections allow the search process to:

move through the graph toward promising regions.

Small World

The graph structure is inspired by navigable small-world networks, where:

strategically connected nodes can make distant areas reachable through relatively few hops.

Together:

Hierarchical + Navigable + Small World

describes the algorithm's central architecture.

The Problem HNSW Solves

Suppose a grocery retailer builds an AI shopping assistant with:

2,000,000 embedded product and content passages.

The shopper asks:

What can I use instead of heavy cream in pasta?

The query becomes:

Query Vector Q

Now the system needs to find vectors near Q.

The naïve approach:

compare Q against every stored vector.

Conceptually:

Query Vector

↓

Compare with Vector 1

Compare with Vector 2

Compare with Vector 3

...

Compare with Vector 2,000,000

↓

Sort

↓

Nearest Results

That can produce strong exact results.

But:

the computational work grows with the collection.

HNSW attempts to avoid evaluating:

every vector.

Instead, it navigates:

a graph connecting nearby vectors.

Exact Nearest Neighbor Search

Exact nearest-neighbor search asks:

Which vectors are mathematically closest to this query?

A brute-force implementation can compare the query against:

every vector in the collection.

That has an important advantage:

it can identify the true nearest neighbors under the chosen distance metric.

But it can become expensive at:

large scale.

Approximate Nearest Neighbor Search

Approximate nearest neighbor search changes the problem slightly.

Instead of demanding:

exhaustive comparison against every possible vector,

the system tries to find:

high-quality nearby candidates efficiently.

The keyword is:

approximate.

ANN algorithms trade some possibility of missing the mathematically exact nearest neighbors for:

Lower latency
Fewer comparisons
Better scalability

HNSW is one such ANN method.

Why Approximation Matters

Imagine searching:

100 vectors.

Brute force may be perfectly reasonable.

Now imagine:

100 million vectors.

The economics change.

Large-scale retrieval systems often care about the tradeoff between:

search quality and computational cost.

Elastic describes HNSW as offering a tradeoff between the quality of k-nearest-neighbor results and the associated computational cost.

That tradeoff is fundamental.

Exactness costs computation. Approximation buys speed.

HNSW as a Graph

Imagine every vector is represented by:

a node.

Nearby vectors can be connected by:

edges.

Conceptually:

     ●────●
    /      \
   ●──●────●
      │
      ●────●

The system does not need to ask:

“How similar is the query to every node?”

Instead, it can ask:

“From where I am now, which connected node moves me closer to the query?”

That turns vector retrieval into:

graph navigation.

Nodes and Edges

In a simplified HNSW model:

Node

Represents:

a stored vector.

Edge

Represents:

a graph connection to another vector.

These edges create:

navigable neighborhoods.

Elastic describes HNSW similarly: vectors are represented as graph nodes, while edges connect nearby vectors.

The “Small World” Idea

Imagine a road network.

If every road connected only:

one house to the house immediately next door,

traveling across the city could require:

thousands of tiny steps.

Now add:

Main roads
Highways
Local streets

You can travel:

long distances quickly

and then:

narrow into the correct neighborhood.

HNSW applies a related idea to:

vector-space navigation.

This analogy is especially useful:

Upper layers behave like highways. Lower layers behave like neighborhood streets.

Why HNSW Is Hierarchical

A single dense graph could still require:

substantial local navigation.

HNSW adds:

multiple graph layers.

Conceptually:

LAYER 3        ●────────────●

LAYER 2        ●────●───────●

LAYER 1      ●──●──●──●──●──●

LAYER 0    ●●●●●●●●●●●●●●●●●●

The original paper explains that elements are distributed across hierarchical layers, with the probability of appearing in higher layers decreasing exponentially.

The result is:

sparse upper layers

and:

dense lower layers.

Upper Layers vs Lower Layers

Upper Layers

Contain:

fewer nodes.

Useful for:

large movements through vector space.

Think:

interstate highways.

Lower Layers

Contain:

more nodes.

Useful for:

fine-grained neighborhood exploration.

Think:

local streets.

The bottom layer contains:

the full vector collection.

Elastic's current explanation likewise notes that all vectors are represented in the bottom HNSW layer.

How HNSW Search Works

At a high level:

Enter → Navigate → Descend → Explore → Return

Suppose the query is:

good cheese for grilled cheese

The embedding might occupy a semantic neighborhood related to:

Melting cheese
American cheese
Cheddar
Havarti
Fontina
Sandwich cheese

HNSW attempts to navigate:

toward that region.

Step 1: Enter the Graph

Search begins from:

an entry point in an upper graph layer.

The entry point does not need to be:

close to the query.

Its purpose is to provide:

a place to begin navigating.

Step 2: Navigate the Upper Layers

The system compares nearby connected nodes and moves toward:

vectors closer to the query.

Conceptually:

Entry → Better Neighbor → Better Neighbor → Better Region

Because upper layers are sparse:

relatively large regions can be traversed efficiently.

Step 3: Descend Through the Hierarchy

Once the search cannot improve sufficiently at one layer:

it descends.

The search becomes:

progressively more local.

Think:

Highway → Major Road → Street → Store Aisle

That is the intuitive power of the hierarchy.

Step 4: Explore Local Neighbors

At the bottom layer:

every indexed vector is represented.

The search explores a set of nearby candidates.

Instead of traversing:

the entire collection,

it focuses on:

a promising semantic neighborhood.

Step 5: Return Candidate Neighbors

The algorithm ultimately returns:

approximate nearest neighbors.

Those candidates might then proceed to:

Filtering
Hybrid fusion
Reranking
Cross-encoder evaluation
Evidence evaluation
Context selection

HNSW does not necessarily determine:

the final result.

It can serve as:

candidate-generation infrastructure.

Grocery Product Search Example

Suppose a grocery vector index contains:

500,000 products.

Query:

mild cheese that melts well for quesadillas

Potential semantic neighborhood:

Monterey Jack
Oaxaca cheese
Mild cheddar
Chihuahua cheese
Quesadilla cheese blends

HNSW does not need to compare the query with:

every product vector.

Instead:

it navigates toward the relevant vector neighborhood.

Candidate results can then be:

filtered and reranked.

Grocery Content Retrieval Example

Now imagine the index contains:

website passages rather than products.

Query:

Can the butcher slice meat thin for Korean BBQ?

Potential vector neighborhood:

Custom meat cutting
Butcher services
Beef short ribs
Korean BBQ
Thin slicing
Specialty meat preparation

HNSW helps the retrieval system reach:

that semantic region efficiently.

Location Search Example

Query:

grocery store with fresh seafood and prepared sushi

Semantic retrieval may identify pages discussing:

Seafood departments
Sushi counters
Fresh fish
Japanese prepared foods

But HNSW alone does not determine:

which store is geographically closest.

Location may need to be handled through:

Metadata
Filters
Geographic search
Additional ranking stages

This gives us an important rule:

Semantic proximity and geographic proximity are different things.

Department Search Example

Query:

store that makes custom birthday cakes

Potential HNSW candidates might include:

Bakery department
Custom cakes
Birthday cakes
Photo cakes
Dessert catering

Again:

HNSW finds vector neighbors.

It does not itself verify:

whether the service is currently offered.

Recipe Search Example

Query:

easy dinner using chicken thighs and rice

A recipe vector index could contain:

Chicken-and-rice recipes
One-pot chicken meals
Baked chicken thighs
Rice bowls
Weeknight chicken dinners

HNSW can efficiently identify:

semantically related recipes.

That makes it useful not only for web retrieval but potentially for:

Retailer-owned search
Recipe recommendation
Product discovery
Shopping assistants

HNSW vs Brute-Force Vector Search

	Brute Force	HNSW
Searches every vector	Typically yes	No
Result type	Exact nearest neighbors	Approximate nearest neighbors
Graph index	No	Yes
Large-scale speed	Can become expensive	Designed for efficient ANN
Memory/index overhead	Lower structure overhead	Graph adds overhead
Recall	Exact under chosen metric	Tunable/approximate
Main strength	Accuracy	Speed-quality tradeoff

The critical distinction:

Brute force searches the space. HNSW navigates the space.

HNSW vs Vector Embeddings

These are not competing technologies.

Embedding Model

Creates:

vector representations.

HNSW

Indexes those vectors for:

efficient nearest-neighbor retrieval.

Conceptually:

Content → Embedding Model → Vector → HNSW Index

Then:

Query → Embedding → HNSW Search → Candidates

So:

Embeddings create the coordinates. HNSW creates the navigation system.

HNSW vs Cosine Similarity

Again, different layers.

Cosine Similarity

Defines:

how similarity between vectors can be measured.

HNSW

Defines:

how the search system navigates the indexed vector collection efficiently.

OpenSearch, for example, supports HNSW with similarity spaces including cosine similarity, L2 distance, and inner product depending on the selected engine.

Therefore:

Cosine similarity = measurement

HNSW = navigation

HNSW vs Vector Databases

A vector database can provide infrastructure for:

Vector storage
Indexing
Search
Filtering
Metadata
Retrieval

HNSW can be:

one indexing/search algorithm inside that infrastructure.

So:

Vector Database → may implement HNSW

rather than:

HNSW = vector database.

HNSW vs Dense Retrieval

Dense retrieval describes:

retrieving content using dense vector representations.

HNSW describes:

one method for efficiently searching those vectors.

So:

Dense Retrieval = retrieval paradigm

HNSW = ANN search/indexing method

A dense retrieval system does not:

inherently require HNSW.

HNSW vs Sparse Retrieval

Sparse retrieval operates on:

sparse representations.

HNSW is most commonly associated with:

dense vector ANN search.

These can coexist.

For example:

Sparse Retrieval + HNSW Dense Retrieval

can produce:

separate candidate sets.

Those candidates can then be:

fused.

HNSW and Hybrid Retrieval

This creates the connection to the earlier hybrid retrieval article.

A conceptual hybrid system might use:

Lexical/Sparse Retrieval

Dense HNSW Retrieval

↓

Fusion

↓

Combined Candidates

↓

Reranking

HNSW therefore may power:

the dense side of a hybrid retrieval system.

HNSW and Bi-Encoders

Bi-encoders can produce:

query embeddings and document embeddings.

Those document embeddings can be stored in:

an HNSW index.

Then:

Query → Bi-Encoder → Query Vector → HNSW → Candidate Vectors

This is a common conceptual architecture for:

scalable semantic retrieval.

HNSW and Cross-Encoders

HNSW and cross-encoders solve:

completely different stages.

HNSW

Efficiently generates:

candidate neighbors.

Cross-Encoder

Can evaluate:

query + candidate together.

So:

HNSW → Candidate Generation → Cross-Encoder → Reranking

This reinforces the earlier principle:

Fast retrieval first. Expensive evaluation later.

HNSW and Multi-Stage Retrieval

Now HNSW fits cleanly into the full architecture from the previous article.

Question↓Embedding↓HNSW Candidate Generation↓Hybrid Fusion↓Filtering↓Entity Resolution↓Reranking↓Evidence Evaluation↓Context Selection↓Grounding↓Generation

HNSW occupies:

one specific stage.

This distinction is essential.

HNSW and RAG

A RAG application needs:

relevant information.

HNSW can support the retrieval component by efficiently searching:

vectorized knowledge.

Conceptually:

Question → Embedding → HNSW → Retrieved Passages → RAG Context → LLM

But RAG does not require:

HNSW.

Other retrieval methods can be used.

Therefore:

HNSW can power retrieval inside RAG. HNSW is not RAG.

HNSW and Context Selection

Suppose HNSW returns:

100 candidates.

Those candidates may still undergo:

Filtering
Deduplication
Reranking
Freshness evaluation
Source-quality evaluation

Perhaps only:

a small subset

eventually enters the model's context.

Therefore:

HNSW retrieval ≠ context selection.

And:

HNSW retrieval ≠ citation.

HNSW Recall

Recall is critical when discussing approximate retrieval.

Conceptually:

Did HNSW retrieve the relevant neighbors that an ideal search should have found?

Because HNSW is approximate:

some true nearest neighbors can potentially be missed.

This is why HNSW configuration involves:

tradeoffs.

OpenSearch notes that denser HNSW graphs and larger search candidate queues can improve recall, but generally at the expense of memory, throughput, indexing cost, or latency.

Search Speed and Recall

The HNSW tradeoff can be simplified as:

More Search Effort → Potentially Higher Recall → More Computational Cost

versus:

Less Search Effort → Faster Search → Potentially Lower Recall

This is not unique to grocery search.

It is:

an infrastructure engineering tradeoff.

The M Parameter

One important HNSW parameter is commonly called:

M

Broadly, M controls:

graph connectivity.

OpenSearch describes M as controlling the number of bidirectional links created for each new element, with significant implications for memory usage.

Conceptually:

Higher M

Potentially:

More connections
Better navigation opportunities
Higher memory usage
Higher indexing cost

Lower M

Potentially:

Fewer connections
Less memory
Faster/cheaper construction
Lower recall in some configurations

But there is no universal:

best M for grocery search.

The efConstruction Parameter

efConstruction affects:

graph construction.

OpenSearch describes it as the size of the dynamic candidate list used while building the k-NN graph; increasing it can improve graph quality but slows indexing.

Simplified:

Higher efConstruction → more effort building the graph → potentially better search quality

but:

more indexing cost.

The efSearch Parameter

efSearch broadly controls:

how extensively the graph is explored during querying

in HNSW implementations that expose it.

OpenSearch describes larger efSearch values as potentially improving search quality while increasing search latency.

But implementation details matter.

For example, OpenSearch's current Lucene HNSW implementation does not expose efSearch in the same way; its documentation says Lucene dynamically sets the search behavior relative to k.

So do not write:

“Every HNSW system has the same efSearch control.”

It does not.

The HNSW Tradeoff Triangle

This should be one of the article's primary visuals.

SEARCH QUALITY

↕

LATENCY

↕

MEMORY / COMPUTE

Increasing search effort or graph connectivity can improve:

retrieval quality.

But usually increases some combination of:

Memory
Search latency
Indexing time
Infrastructure cost

There is no free setting that maximizes:

everything.

Memory Requirements

HNSW's graph structure requires:

memory.

Elastic currently notes that HNSW works most efficiently when vector data and index structures can be held in memory/page cache and highlights memory as an important consideration when tuning approximate kNN search.

This matters when indexing:

Millions of products
Large content corpora
High-dimensional vectors
Multiple embeddings per item

HNSW is powerful.

But:

speed comes with infrastructure cost.

Filtering

Suppose HNSW retrieves products semantically similar to:

healthy cereal

But the shopper asks:

healthy cereal under $5 at Downtown

HNSW handles:

semantic neighborhood discovery.

Other parts of the system may need to enforce:

Price < $5

and:

Store = Downtown.

OpenSearch supports efficient filtering with k-NN search, illustrating how vector retrieval and metadata constraints can work together.

This gives us:

Vector similarity finds candidates. Metadata enforces constraints.

Dynamic Grocery Data

Grocery information is unusually dynamic.

Consider:

Inventory
Prices
Weekly ads
Promotions
Seasonal items
Store hours
Pickup availability

Embedding and indexing this information introduces:

freshness challenges.

A beautifully constructed HNSW index containing:

yesterday's inventory

can efficiently retrieve:

yesterday's answer.

That is not success.

Product Inventory

Suppose:

Oat Milk Product → Vector → HNSW Index

The shopper asks:

oat milk available at Downtown right now

HNSW can find:

semantically relevant oat milk candidates.

But availability requires:

current inventory state.

Therefore:

Vector relevance cannot substitute for transactional freshness.

Weekly Ads and Promotions

Weekly promotions illustrate the same problem.

Query:

chicken thighs on sale this week

HNSW might retrieve:

chicken-thigh promotional content.

But the system still needs:

Current promotion dates
Price
Location
Eligibility
Offer status

A stale promotion can remain:

semantically perfect.

That makes it:

perfectly retrievable and operationally wrong.

The Grocery HNSW Navigation Model

This should be the article's signature framework.

Imagine grocery vectors as:

a city.

Embeddings

Determine:

where information lives.

HNSW Nodes

Represent:

destinations.

HNSW Edges

Create:

roads between nearby destinations.

Upper Layers

Act like:

highways.

Lower Layers

Act like:

neighborhood streets.

Query Vector

Represents:

the destination the shopper is trying to reach.

HNSW Search

Navigates:

toward the relevant neighborhood.

Reranker

Decides:

which nearby destinations best match the request.

This gives us the defining analogy:

Embeddings create the map. HNSW builds the roads. Retrieval navigates the roads. Reranking chooses among the destinations reached.

The Grocery Vector Search Stack

This should be the second major framework.

LEVEL 1 — SOURCE INFORMATION

Products, locations, departments, services, content

↓

LEVEL 2 — CHUNKING

Divide information into meaningful units

↓

LEVEL 3 — EMBEDDING

Convert meaning into vectors

↓

LEVEL 4 — VECTOR INDEX

Organize vectors for retrieval

↓

LEVEL 5 — HNSW

Navigate the vector space efficiently

↓

LEVEL 6 — CANDIDATE RETRIEVAL

Return approximate nearest neighbors

↓

LEVEL 7 — FILTER / HYBRID FUSION

Apply constraints and other retrieval signals

↓

LEVEL 8 — RERANK

Evaluate candidates more precisely

↓

LEVEL 9 — CONTEXT SELECTION

Choose useful evidence

↓

LEVEL 10 — GROUND / GENERATE

Construct an evidence-supported answer

The critical lesson:

HNSW is infrastructure in the middle of the stack—not the entire AI search system.

The SCALE Framework

This should be the Grocery Growth marketer-facing framework.

It is not an HNSW tuning formula.

It explains how to create grocery information that remains useful when vectorized and retrieved at scale.

S — Specific Information

Avoid:

vague marketing language.

Prefer:

concrete facts.

C — Clear Entity Ownership

Attach each fact to the correct:

Brand
Location
Department
Product
Service

A — Attribute-Rich Context

Include useful attributes such as:

Dietary characteristics
Cuisine
Product type
Service
Occasion
Geography
Availability conditions

L — Logical Semantic Structure

Organize information into:

meaningful sections and relationships.

E — Evidence and Freshness

Keep information:

Accurate
Current
Verifiable
Useful

So:

SCALE = Specific → Clear Entities → Attribute-Rich → Logical Structure → Evidence & Freshness

This is a content-readiness framework.

It is not an HNSW algorithm or ranking factor.

What HNSW Cannot Determine

HNSW cannot inherently determine:

Whether information is true

A false statement can have:

an excellent embedding.

Whether information is current

An expired promotion can remain:

semantically close.

Whether an entity is correct

Wrongly assigned attributes can still be:

retrievable.

Whether a source is trustworthy

Similarity does not equal:

authority.

Whether a product is in stock

Unless that state is supplied elsewhere.

Whether the result should be cited

Citation is:

downstream.

Whether the result should be recommended

Recommendation can involve:

additional ranking and business logic.

This gives us:

Nearest does not mean best. Similar does not mean true. Retrieved does not mean selected.

What Grocery Marketers Can Control

Most grocery marketers should not be tuning HNSW.

Instead, they can control the source material potentially entering retrieval systems:

Product names
Product descriptions
Department information
Store-location information
Service descriptions
Semantic context
Exact terminology
Customer language
Entity relationships
Prices
Promotion dates
Hours
Inventory feeds
Page structure
Internal links
Crawlability
Structured information
Freshness
Accuracy

The strategic rule is:

Do not optimize your grocery website for HNSW. Optimize the information that retrieval systems may eventually represent and search.

What Grocery Marketers Cannot Control

For third-party search and AI platforms, marketers generally cannot control:

Whether HNSW is used
HNSW implementation
Graph structure
M
efConstruction
efSearch
Entry points
Graph layers
Neighbor-selection heuristic
Embedding model
Vector dimensions
Similarity metric
Candidate count
Recall target
Search latency budget
Memory allocation
Quantization
Filtering architecture
Reranking model

These become controllable only when:

you are building or operating your own vector-search infrastructure.

Does Google Use HNSW?

Do not claim:

Google's public Search or AI Overview retrieval universally uses HNSW.

Google uses sophisticated large-scale information-retrieval infrastructure, but marketers are not given a universal public specification stating:

Google Search → HNSW → parameter X → candidate count Y.

Therefore:

HNSW should be explained as an important vector-search algorithm, not as a secret Google ranking mechanism.

Does ChatGPT Search Use HNSW?

The same caution applies.

OpenAI does not provide publishers with a universal technical specification saying:

ChatGPT Search uses HNSW with a particular graph configuration.

So do not claim:

ChatGPT uses HNSW for every search
OAI-SearchBot creates an HNSW index
ChatGPT uses a specific M
ChatGPT uses a specific efSearch
ChatGPT citations come from HNSW neighbors

Those claims are not publicly established.

HNSW is relevant because it explains:

how scalable vector retrieval can work.

Not because OpenAI has disclosed it as:

the ChatGPT Search ranking algorithm.

Common HNSW Myths

“HNSW creates embeddings.”

No.

Embedding models create:

embeddings.

HNSW indexes/searches them.

“HNSW is an embedding model.”

No.

“HNSW is a vector database.”

No.

A vector database may:

implement HNSW.

“HNSW is cosine similarity.”

No.

HNSW is a:

search/index structure.

Cosine similarity is:

a similarity measure.

“HNSW checks every vector.”

No.

Avoiding exhaustive comparison is:

one of its primary benefits.

“HNSW always returns the mathematically exact nearest neighbors.”

No.

It is an:

approximate nearest-neighbor algorithm.

“Approximate means inaccurate.”

Not necessarily.

ANN systems are designed to achieve:

useful recall with much lower search cost.

“HNSW has no tradeoffs.”

False.

Important tradeoffs involve:

Recall
Latency
Memory
Index construction
Update cost

“Higher M is always better.”

No.

Higher connectivity can increase:

memory and construction costs.

“Higher efSearch is always better.”

Not universally.

It can improve retrieval quality in implementations exposing that parameter, but typically costs:

latency/computation.

“Every HNSW implementation uses efSearch identically.”

No.

Implementation behavior differs. OpenSearch's Lucene engine, for example, handles this differently from its Faiss implementation.

“HNSW determines relevance.”

More precisely:

it efficiently finds nearby vectors under the representation and distance function supplied.

Final relevance can involve:

additional stages.

“Nearest vector means best answer.”

No.

“Nearest vector means true.”

No.

“Nearest vector means current.”

No.

“HNSW solves product availability.”

No.

“HNSW solves location filtering.”

Not inherently.

“HNSW solves entity resolution.”

No.

“HNSW replaces reranking.”

No.

“HNSW replaces hybrid retrieval.”

No.

“HNSW replaces RAG.”

No.

“HNSW determines citations.”

No.

“Google has an HNSW ranking factor.”

No such public ranking factor is documented.

“ChatGPT has an HNSW optimization score.”

No such publisher-facing score is documented.

“There is HNSW schema markup.”

No.

“Grocery websites should add HNSW keywords everywhere.”

Absolutely not.

That would have:

nothing to do with how HNSW works.

Grocery Vector Retrieval Checklist

Source Information

Product information specific
Location information specific
Department information specific
Service information specific
Generic marketing copy minimized

Semantic Meaning

Natural customer terminology
Useful product attributes
Cuisine context where appropriate
Use cases where appropriate
Clear semantic relationships

Entity Ownership

Brand clear
Location clear
Department clear
Product clear
Service ownership clear

Operational Data

Price current
Inventory appropriately current
Promotions dated
Hours current
Location availability explicit

Retrieval Readiness

Meaningful content sections
Focused passages
Crawlable information
Important facts not hidden unnecessarily
Internal relationships clear

Infrastructure — If Building Your Own Search

Exact vs ANN requirements evaluated
Vector volume measured
Similarity metric chosen intentionally
HNSW suitability tested
Recall measured
Latency measured
Memory measured
M tested
Construction parameters tested
Search parameters tested
Filtering tested
Update frequency considered
Reranking evaluated

Claims Discipline

No claim Google uses HNSW universally
No claim ChatGPT uses HNSW universally
No invented HNSW ranking factor
No invented similarity threshold
No magic M recommendation
No magic efSearch recommendation
No claim nearest = true
No claim retrieval = citation
No claim HNSW = RAG

Frequently Asked Questions

What is HNSW?

HNSW stands for:

Hierarchical Navigable Small World.

It is a graph-based algorithm for:

approximate nearest-neighbor search.

The original research introduced a hierarchy of navigable proximity graphs designed to improve efficient nearest-neighbor search.

What problem does HNSW solve?

It helps efficiently find:

vectors near a query vector

without exhaustively comparing the query with every vector in a large collection.

What is ANN?

ANN means:

Approximate Nearest Neighbor.

The objective is to efficiently find high-quality near neighbors without requiring exhaustive exact search.

What is kNN?

kNN in vector search generally refers to finding:

the k nearest vectors to a query.

Is HNSW exact search?

No.

HNSW is generally used for:

approximate nearest-neighbor search.

Why use approximate search?

Because exhaustive vector comparison can become:

computationally expensive at scale.

How does HNSW work?

At a simplified level:

Enter sparse upper graph → navigate toward query → descend layers → explore dense neighborhood → return nearby candidates.

What are HNSW nodes?

Nodes represent:

indexed vectors.

What are HNSW edges?

Edges connect:

graph neighbors.

Why does HNSW have layers?

Upper layers enable:

coarse navigation.

Lower layers enable:

fine-grained exploration.

What is the bottom HNSW layer?

The bottom layer contains:

all indexed vectors.

What does M control?

Broadly:

graph connectivity.

Increasing it can increase memory usage and potentially improve search quality.

What does efConstruction control?

It affects:

the effort used while constructing the graph.

Higher values can improve graph quality but increase indexing cost.

What does efSearch control?

In implementations that expose it, it affects:

the breadth/effort of search-time graph exploration.

Larger values can improve search quality while increasing latency.

Is there a best M?

No universal value.

It depends on:

Dataset
Embeddings
Scale
Memory
Latency requirements
Desired recall
Implementation

Is there a best efSearch?

No universal value.

Is HNSW memory intensive?

It can be.

Graph connections and vector data create meaningful memory requirements, particularly at large scale. Elastic recommends ensuring adequate memory/page-cache capacity for efficient HNSW approximate kNN operation.

Does HNSW use cosine similarity?

It can.

Implementations may support:

Cosine similarity
L2 distance
Inner product
Other spaces

depending on the engine.

Is HNSW the same as cosine similarity?

No.

HNSW navigates. Cosine similarity measures.

Is HNSW the same as embeddings?

No.

Embeddings represent. HNSW retrieves.

Is HNSW the same as vector search?

No.

HNSW is:

one method for performing approximate vector search.

Is HNSW the same as dense retrieval?

No.

HNSW can:

implement efficient nearest-neighbor search inside a dense retrieval system.

Can HNSW work with hybrid retrieval?

Yes.

A system can combine:

HNSW dense retrieval + lexical/sparse retrieval.

Can HNSW results be reranked?

Yes.

A common conceptual pipeline is:

HNSW → Candidates → Reranker

Can a cross-encoder rerank HNSW results?

Yes.

That is a natural:

retrieve-and-rerank architecture.

Does HNSW work with RAG?

It can.

HNSW can provide:

vector candidate retrieval

for a RAG system.

Does RAG require HNSW?

No.

Does HNSW decide what enters the LLM context?

Not necessarily.

Context selection can occur:

downstream.

Does HNSW verify information?

No.

Does HNSW understand whether inventory is current?

No.

Does HNSW determine which source is trustworthy?

No.

Does Google Search use HNSW?

Google does not provide publishers with a universal public specification establishing HNSW as the retrieval algorithm for all Google Search or AI-search results.

Does ChatGPT Search use HNSW?

OpenAI does not publicly specify HNSW as a universal ChatGPT Search retrieval architecture.

Should grocery stores optimize their websites for HNSW?

Not directly.

Instead:

optimize the quality, specificity, relationships, accessibility, and freshness of the underlying information.

When should a grocery company actually care about HNSW configuration?

When building its own:

Semantic site search
Product search
Recommendation engine
Internal knowledge system
RAG application
Shopping assistant
Large vector retrieval system

At that point:

HNSW becomes an engineering decision rather than an SEO tactic.

Final Thoughts

Vector embeddings create an elegant solution to:

representing meaning mathematically.

But once millions of vectors exist, another problem appears:

How do you search them quickly?

One answer is HNSW.

Instead of exhaustively comparing a query against every vector, HNSW creates:

a hierarchical proximity graph.

Upper layers help the system:

move quickly through broad areas of vector space.

Lower layers help it:

explore promising neighborhoods more precisely.

That is why the highway analogy works so well:

Upper Layer → Highway

Middle Layer → Main Road

Bottom Layer → Neighborhood

The original HNSW research formalized this hierarchical graph approach for approximate nearest-neighbor search, and modern systems including Elastic and OpenSearch continue to implement HNSW for vector retrieval today.

But HNSW occupies:

one specific layer of a much larger AI-search architecture.

It does not create embeddings.

It does not understand whether:

FreshTown Downtown actually has oat milk today.

It does not determine:

whether a source deserves trust.

It does not determine:

what evidence enters an LLM's context.

And it does not determine:

which grocery business receives the final recommendation.

Instead:

HNSW solves the navigation problem.

The Grocery Vector Search Stack becomes:

Content → Chunk → Embed → Index → HNSW → Retrieve → Filter/Fuse → Rerank → Select Context → Ground → Generate

The Grocery HNSW Navigation Model becomes:

Embeddings = Map

Nodes = Destinations

Edges = Roads

Upper Layers = Highways

Lower Layers = Neighborhood Streets

Query = Desired Destination

HNSW = Navigation System

The SCALE Framework becomes:

Specific → Clear Entities → Attribute-Rich → Logical Structure → Evidence & Freshness

The critical engineering principle is:

Exact search asks every vector. HNSW navigates toward the promising ones.

The critical marketing principle is:

Do not optimize your grocery content for HNSW. Optimize the information that retrieval systems may eventually represent and search.

And the defining line for this article should be:

Embeddings create the semantic space. HNSW builds the roads that make that space searchable at scale.

Want Your Grocery Content to Be Easier to Retrieve?

Grocery Growth helps grocery retailers improve the underlying information architecture that modern search and AI systems may need to discover, represent, retrieve, evaluate, and use.

Optimization can include:

Semantic content architecture
Entity optimization
Product information
Location pages
Department pages
Service pages
Weekly-ad optimization
Structured data
Content chunking
Passage-level optimization
Information gain
Content freshness
Internal linking
Crawlability
LLM retrieval optimization
GEO
AEO
SEO
AI-search optimization

The goal is not to manipulate:

HNSW graphs, vector coordinates, or hidden similarity thresholds.

It is to build information capable of remaining useful from:

source content → semantic representation → retrieval → evidence.

Explore Grocery Growth's SEO and AI-search optimization services.

Written by Grocery Growth

Grocery Growth helps grocery retailers build clearer digital information architectures for traditional search, semantic retrieval, AI-assisted discovery, and modern grocery shopping experiences.

Vector Foundations: Vector Embeddings Explained for Grocery Store Marketers; Cosine Similarity and Semantic Retrieval; Vector Databases and AI Search.

Retrieval Architecture: Dense vs Sparse Retrieval for LLM Search; Hybrid Retrieval for Grocery AI Search; Multi-Stage Grocery Content Retrieval Pipelines.

Candidate Evaluation: Cross-Encoder Reranking; Bi-Encoders vs Cross-Encoders in LLM Retrieval.

Downstream AI Search: LLM Retrieval Optimization; RAG and Grocery Store Websites; Grounding in AI Search; Citation Optimization.

Table of Contents

What Is HNSW?

What Does HNSW Stand For?

Hierarchical

Navigable

Small World

The Problem HNSW Solves

Exact Nearest Neighbor Search

Approximate Nearest Neighbor Search

Why Approximation Matters

HNSW as a Graph

Nodes and Edges

Node

Edge

The “Small World” Idea

Why HNSW Is Hierarchical

Upper Layers vs Lower Layers

Upper Layers

Lower Layers

How HNSW Search Works

Step 1: Enter the Graph

Step 2: Navigate the Upper Layers

Step 3: Descend Through the Hierarchy

Step 4: Explore Local Neighbors

Step 5: Return Candidate Neighbors

Grocery Product Search Example

Grocery Content Retrieval Example

Location Search Example

Department Search Example

Recipe Search Example

HNSW vs Brute-Force Vector Search

HNSW vs Vector Embeddings

Embedding Model

HNSW

HNSW vs Cosine Similarity

Cosine Similarity

HNSW

HNSW vs Vector Databases

HNSW vs Dense Retrieval

HNSW vs Sparse Retrieval

HNSW and Hybrid Retrieval

HNSW and Bi-Encoders

HNSW and Cross-Encoders

HNSW

Cross-Encoder

HNSW and Multi-Stage Retrieval

HNSW and RAG

HNSW and Context Selection

HNSW Recall

Search Speed and Recall

The M Parameter

Higher M

Lower M

The efConstruction Parameter

The efSearch Parameter

The HNSW Tradeoff Triangle

SEARCH QUALITY

LATENCY

MEMORY / COMPUTE

Memory Requirements

Filtering

Dynamic Grocery Data

Product Inventory

Weekly Ads and Promotions

The Grocery HNSW Navigation Model

Embeddings

HNSW Nodes

HNSW Edges

Upper Layers

Lower Layers

Query Vector

HNSW Search

Reranker

The Grocery Vector Search Stack

LEVEL 1 — SOURCE INFORMATION

LEVEL 2 — CHUNKING

LEVEL 3 — EMBEDDING

LEVEL 4 — VECTOR INDEX

LEVEL 5 — HNSW

LEVEL 6 — CANDIDATE RETRIEVAL