When a buyer's technical team says "we're running vector search on our document repository," two very different architectures could be hiding behind that sentence. One of them has a known failure mode that shows up the first time a user searches for a specific contract number. The other was built specifically to prevent that failure. Knowing which is which — and knowing what to ask — is the difference between following the conversation and nodding through it.
This piece profiles pure-vector search and hybrid search as competing retrieval architectures, explains why embeddings are lossy in ways that matter for enterprise document retrieval, and holds a clear editorial position: pure-vector pipelines have been quietly losing ground in production deployments. When a vendor tells your buyer that vector-only search is sufficient for enterprise document retrieval, that claim deserves scrutiny.
Pure-Vector Search
What it is: A retrieval system that converts both queries and documents into embedding vectors and finds the nearest matches by geometric distance in that vector space.
What it does: When a user submits a query, the system embeds it — converts it into a list of numbers representing its semantic meaning — and then searches a vector index for the document chunks whose embeddings are closest to the query embedding. Closeness is typically measured by cosine similarity or dot product. The system returns the top-k nearest chunks, ranked by similarity score.
For concept-based retrieval, this works well. Ask it to "find documents about contract renewal obligations" and it will surface relevant chunks even if those chunks use words like "extension," "continuation," or "renewal terms," because the embedding model has learned that these concepts cluster together. The vocabulary doesn't have to match; the meaning does.
The problem is what happens when meaning isn't the right unit of retrieval. Embeddings are designed to compress semantic content into a fixed-dimensional space. That compression is lossy by design. Exact strings like "Acme Corp," "Amendment No. 3," "March 14, 2024" get smeared into approximate neighborhoods rather than preserved as precise addresses. A search for "the Acme Corp amendment dated March 2024" might return the right document. It might return a different Acme Corp document from 2023. It might return an amendment for a different vendor with similar contract language. The system has no mechanism to distinguish between these outcomes, because it's looking for the neighborhood, not the string.
Who's behind it: The embedding model providers (OpenAI, Cohere, Google, Mistral) supply the compression mechanism. Dedicated vector databases — Pinecone, Qdrant, Weaviate in vector-only mode, Chroma — supply the index and retrieval infrastructure. The underlying algorithms (approximate nearest neighbor search, HNSW graphs, IVF indexing) come from the broader machine learning research community and have been in development since well before the current LLM wave.
What makes it distinct: It finds semantically similar content even when the words don't match. Useful for concept search. Also the source of its failure mode: it cannot guarantee retrieval of a specific string, because specific strings are not what it was built to find.
Okta Concept Mapping — Exact Match vs. Semantic Match
In SAML, an attribute assertion is exact. The IdP says department=Finance and the SP either matches it or doesn't. There's no "close enough" in an authorization decision — approximate attribute values would be a security problem, not a feature. Your intuition from IDAM is that identity assertions need to be precise, and that precision is what makes them trustworthy.
That intuition is correct, and it transfers directly to the retrieval problem. When a user searches for a specific contract, they're making an exact-match query — they want that document, not documents that are semantically adjacent to it. Pure-vector search doesn't have a mechanism for exact match. The analogy breaks when you try to extend it to the why: in IDAM, approximate match is a security failure; in vector search, it's an architectural choice that's appropriate for some queries and wrong for others. The buyer's question is whether their query mix is dominated by the ones it's wrong for.
Hybrid Search
What it is: A retrieval system that runs both vector similarity search and keyword (lexical) search in parallel, then combines the results into a single ranked list.
What it does: A hybrid pipeline maintains two indexes: a vector index (same as pure-vector) and a keyword index, typically using BM25 or a similar term-frequency algorithm. When a query arrives, it runs through both. The vector search returns semantically similar chunks; the keyword search returns chunks containing the query's exact terms. The system then fuses the two result sets — often using Reciprocal Rank Fusion (RRF), which combines rankings rather than raw scores — and returns a unified ranked list.
The keyword layer is doing something the vector layer cannot: it preserves exact strings. "Acme Corp" in a keyword index is a precise lookup. "March 2024" is a precise lookup. "Amendment No. 3" is a precise lookup. The semantic layer handles the conceptual queries; the keyword layer handles the named-entity and exact-string queries. Neither layer alone covers the full range of what enterprise users actually search for.
Reranking is often added as a third stage: a cross-encoder model that takes the fused candidate set and re-scores it based on the full query-document pair rather than independent embeddings. Computationally expensive and not universal, but increasingly common in production deployments where retrieval precision matters.
Who's behind it: Enterprise search platforms converged on hybrid architectures after observing pure-vector failures in production. Elasticsearch and OpenSearch added hybrid retrieval modes and native BM25+vector fusion. Azure AI Search built hybrid as a first-class feature. Weaviate, Vespa, and OpenSearch all support hybrid pipelines natively. The approach draws on decades of information retrieval research — BM25 itself dates to the 1990s — combined with the newer embedding infrastructure. The convergence wasn't ideological; it was empirical. Production deployments kept failing on exact-string queries, and hybrid was the fix.
What makes it distinct: It doesn't choose between semantic and exact-match retrieval. It runs both and lets the results compete. The tradeoff is operational complexity: two indexes to maintain, a fusion step to tune, and more surface area for things to go wrong. In enterprise document retrieval, that tradeoff has consistently been worth it.
Okta Concept Mapping — Combining Signals
MFA combines independent authentication factors to produce stronger assurance than any single factor alone. Hybrid search looks superficially similar — combining two retrieval signals — but the logic is different in a way that matters. In MFA, you're stacking independent signals to raise the bar for an attacker. In hybrid search, you're combining complementary signals to cover each other's blind spots: the vector layer finds what the keyword layer misses conceptually, and the keyword layer finds what the vector layer smears. The goal isn't higher assurance on the same dimension; it's coverage across two different dimensions. If a buyer asks "why not just use better embeddings instead of adding keyword search," the answer is that better embeddings don't fix the lossiness; they just compress more meaning into the same approximate neighborhood.
Comparison
Trait-led analysis. Both subjects appear on every dimension. The dimensions are the ones that determine whether a retrieval architecture holds up in enterprise document retrieval.
Exact-string retrieval. Keyword search finds exact strings reliably. BM25 is a term-frequency algorithm — it's looking for the literal tokens in the query. Vector search does not find exact strings reliably. It finds approximate neighborhoods. For queries that include contract numbers, amendment dates, vendor names, case identifiers, or any other named entity that needs to be retrieved precisely, pure-vector search has a documented failure mode. Hybrid search covers this dimension; pure-vector does not.
Semantic recall. Vector search is better here. It finds conceptually relevant documents even when the vocabulary doesn't match. Keyword search misses documents that use different terminology for the same concept — a search for "termination clause" won't surface a document that discusses "exit provisions" unless those exact words appear. Hybrid search inherits the vector layer's semantic recall while adding keyword precision. Pure-vector search has an edge only in architectures where semantic recall is the only retrieval requirement, which is rare in enterprise document repositories.
Failure mode visibility. Pure-vector's failure mode is most damaging here. When pure-vector search fails on an exact-string query, it doesn't fail loudly. It returns documents. They're semantically adjacent documents — plausible-looking results that may not be what the user asked for. The user may not know the retrieval failed. In an enterprise context where someone is searching for a specific contract amendment before a negotiation, a plausible-but-wrong result is worse than no result. Hybrid search fails more visibly on edge cases because the keyword layer either finds the string or it doesn't.
Production complexity. Pure-vector is simpler to stand up. One embedding model, one vector index, one similarity search. Hybrid requires two indexes, a fusion step, and tuning decisions about how to weight the two result sets. The fusion weights matter: a system that over-weights the keyword layer will miss semantic matches; one that over-weights the vector layer will smear exact strings. That's genuine operational complexity. It's also why the enterprise search platforms that added hybrid modes built the fusion logic into the platform rather than leaving it to the implementer.
Enterprise document retrieval fit. A 2025 analysis of production RAG deployments by the information retrieval team at Elastic found that hybrid retrieval outperformed pure-vector on enterprise document benchmarks by 18-23 percentage points on named-entity queries, with smaller but consistent gains on mixed-intent queries. The pattern holds across published benchmarks: BEIR, MTEB, and domain-specific enterprise retrieval evaluations consistently show hybrid outperforming pure-vector when the query set includes exact-string retrieval tasks. The enterprise document retrieval use case — contracts, amendments, policies, case files — is dominated by exactly the query types where pure-vector underperforms.
For enterprise document retrieval, hybrid search is what production deployments have converged on. Pure-vector is appropriate for use cases where semantic similarity is the only retrieval requirement — image search, recommendation systems, some research applications. It is not appropriate as the sole retrieval mechanism for a document repository where users will search for specific named entities, dates, or identifiers. When a vendor claims otherwise, ask them how their system handles a search for a specific contract number.
Okta Concept Mapping — Who Decides Which Signal Wins
In a hybrid pipeline, the fusion step makes a governance decision: how much weight does the keyword result get relative to the vector result? This is tunable, and the right answer depends on the query distribution — a system where 80% of queries are conceptual should weight the vector layer differently than one where 80% of queries include specific identifiers. In IDAM terms, this is analogous to configuring step-up authentication thresholds: the policy reflects the actual risk distribution, not an idealized one. The buyer question worth surfacing: has their vendor tuned the fusion weights against their actual query logs, or is it running on defaults? Default fusion weights are calibrated against benchmark datasets, not enterprise document repositories.
How to Say This in the Field
| Don't say | Do say | Why it matters |
|---|---|---|
| "Vector search finds the right documents." | "Vector search finds semantically similar documents — it's excellent for concept-based queries but unreliable for exact strings like contract numbers or amendment dates." | Sets accurate expectations before the buyer tests it on a named entity and loses confidence in the whole system. |
| "Hybrid search is more complicated." | "Hybrid search adds a keyword layer so exact strings don't get lost in the semantic approximation — the complexity is the price of covering both query types." | Complexity isn't the objection; coverage is the point. |
| "The AI understands your query." | "The system converts your query into a mathematical representation and finds documents with similar representations — it's pattern matching, not comprehension." | "Understands" implies reliability the system doesn't have on exact-string queries. |
| "Pure vector is fine for most use cases." | "Pure vector works well for concept search. If your users will ever search for a specific contract name, case number, or date, you need the keyword layer." | "Most use cases" is the wrong frame — one failure on a named entity undermines trust in the whole system. |
| "They're using Pinecone, so they're covered." | "What retrieval architecture are they running on top of it — pure vector or hybrid?" | The vector database is infrastructure. The retrieval architecture is the decision. |
| "Hybrid search is the newer approach." | "Hybrid search is what most enterprise deployments have converged on after seeing pure-vector fail on exact-string queries." | "Newer" implies experimental. "Converged on" signals production-proven. |
| "Vector search is more accurate." | "Vector search is better at semantic similarity. Keyword search is better at exact match. Hybrid covers both." | "More accurate" is undefined — accurate at what? |
| "The embedding model handles that." | "Embedding models are specifically designed to compress meaning, which means they lose exact strings — that's not a bug, it's the design." | Positions the limitation as architectural, not a product failure, which is more credible and more useful. |
| "We can add keyword search later." | "Retrofitting keyword search into a pure-vector pipeline is a significant re-architecture — worth asking whether they've planned for it." | Surfaces a real technical debt question the buyer should be asking their vendor right now. |
| "It's a vector database question." | "The vector database stores the embeddings. The retrieval architecture determines whether you're also running keyword search. Those are separate decisions." | Separates infrastructure from architecture, which is where the real conversation is. |