Keyword, vector, or hybrid

You built the agent, pointed it at your knowledge, and it answers fluently and wrong. A customer asks whether motor XYZ-123 is compatible with a hydraulic pump, and the agent confidently cites the manual for XYZ-125. The model didn’t hallucinate from nowhere — it faithfully summarised the chunk it was handed. The mistake happened one layer earlier, in retrieval: the search returned a semantically similar document instead of the one with the exact part number, and no amount of prompt-tuning downstream can fix a wrong chunk fed in as fact.

This is the retrieval-quality problem, and in Data 360 it’s decided largely by one choice most teams make on autopilot: which type of search index you build. We’ve written about the one-click Data Library path that hides this decision behind defaults, and about Intelligent Context, the workspace for tuning the chunking that feeds an index. This post is the layer between them — the index type itself. Keyword, vector, hybrid: what each one is genuinely good and bad at, how hybrid combines them, and how the choice lands on both your answer accuracy and your credit bill.

What a search index is, and where it sits

Quick orientation, because the vocabulary trips people up. To ground an agent on unstructured data — PDFs, knowledge articles, transcripts — Data 360 does three things: it chunks each document into passages, embeds those chunks (for vector search) into numerical vectors, and stores them in a search index. At runtime a retriever — the link between the prompt and the index — takes the user’s query, searches the index, and returns the most relevant chunks to the LLM to reason over. Retrievers are created in the AI Models workspace and then wired into prompt templates and agents.

Everything in this post is about that middle box, the index, because the kind of index you build determines what “most relevant” means — and “most relevant” is exactly what went wrong in the XYZ-123 example.

Keyword (lexical) search is the classic approach: it matches on the words themselves and their statistical importance across the corpus. Ask about “XYZ-123” and a keyword index will surface the chunks that literally contain “XYZ-123,” ranking by term frequency and rarity. For exact identifiers — SKUs, part numbers, error codes, contract numbers, proper nouns — this is precisely what you want. A part number is a token, not a concept; there’s no “meaning” to be semantically near, and vector search’s whole strategy works against you here.

Keyword search’s weakness is the mirror image of its strength: it’s blind to paraphrase. A customer who asks “the login keeps kicking me out” won’t match an article titled “session timeout errors” if the two share no words, no matter how obviously they’re about the same thing. Keyword search matches strings, not intent.

Vector search: semantic, forgiving, and prone to confident near-misses

Vector (semantic) search embeds both the query and the chunks into a shared vector space and returns the chunks whose vectors are nearest to the query’s — nearest meaning “closest in meaning,” as learned by the embedding model. “The login keeps kicking me out” lands near “session timeout errors” even with zero shared words, which is exactly the paraphrase problem keyword search can’t touch. For natural-language questions over prose, vector search is the reason RAG works at all.

Its failure mode is the one that bit us at the top: it retrieves things that are similar when you needed things that are exact. “XYZ-123” and “XYZ-125” are near-neighbours in vector space — almost the same string, almost the same product — so a pure vector search will happily return the wrong manual with high confidence. Semantic similarity has no notion that a single transposed digit is the whole point of the question. Vector search is forgiving in a way that is a feature for prose and a bug for identifiers.

In Data 360, the vector index is built with a hosted embedding model. A commonly used option is Salesforce’s Embedding V2 Small model (SFR-v2-small), which supports chunk sizes up to 1,200 tokens — large enough to keep meaningful context in a chunk without diluting the embedding. Data 360 hosts multiple out-of-the-box models and supports pluggable ones; if your chunking strategy needs smaller passages (say 512 tokens), you match it to a model with the appropriate sequence length. The embedding model and the chunk size are a joined decision, and getting them wrong quietly caps retrieval quality no matter which index type you pick — which is why the chunking workspace exists as its own tuning surface.

Hybrid search: run both, then merge and re-rank

Hybrid search is Data 360’s answer to the fact that most real queries need both strategies at once — the compatibility question above contains an exact identifier (“XYZ-123”) and a semantic concept (“compatible with hydraulic pumps”). When you create a hybrid search index, Data 360 generates content chunks and vector embeddings and builds two indexes side by side: a vector index for semantic similarity and a keyword index for lexical precision. At query time it searches both, then merges and re-ranks the combined results, so a chunk that scores well on either dimension surfaces — and a chunk that scores well on both rises to the top.

That’s why the XYZ-123 query resolves correctly under hybrid: the keyword side pins the exact part number, the vector side understands “compatible with hydraulic pumps,” and the merge rewards the chunk that satisfies both. Salesforce’s own guidance uses almost exactly this example — a query like “Does Acme motor XYZ123 use hydraulic pumps?” — to show why adding keyword matching lifts the genuinely relevant chunk above the merely similar one.

A useful way to hold the three options in your head:

	Keyword	Vector	Hybrid
Matches on	Exact terms, term rarity	Semantic meaning	Both, merged and re-ranked
Best at	SKUs, codes, part numbers, names	Paraphrase, natural questions, synonyms	Real queries that mix identifiers and intent
Fails at	Paraphrase — misses synonyms	Exact strings — returns near-misses	Costs more to build and store
Typical use	Structured-ish lookups	Prose knowledge bases	Most production agent grounding

In current Data 360, the index type you select when building an enriched search index is vector or hybrid — keyword matching isn’t usually a standalone product choice you toggle so much as the lexical half that hybrid layers on top of the vector index. The practical decision, then, is usually “vector, or vector-plus-keyword (hybrid)?” — and for any corpus where exact identifiers matter, hybrid is the safer default. Confirm the exact configuration options against current release notes, because this surface has been moving.

The credit and cost math nobody quotes upfront

Retrieval quality isn’t free, and hybrid is the more expensive answer for a reason worth understanding. Building an index consumes Data 360 processing to chunk and embed your corpus; a hybrid index maintains two indexes, so it costs more to build and store than a vector-only index, and re-indexing on document updates costs again. Query-time retrieval consumes credits too, and it scales with how much you retrieve and how often. None of this is a reason to avoid hybrid — the wrong-answer cost of under-indexing dwarfs the storage delta — but it is a reason to be deliberate rather than reflexively indexing everything the richest way.

Three habits keep the bill honest, and they’re the same discipline we lay out in the credit-optimization playbook:

Index what an agent actually retrieves, not your whole document lake. A hybrid index over 50,000 documents an agent never queries is pure cost. Scope the corpus to the knowledge the agent’s subagents genuinely reach.
Match chunk size and top-k to the job. Retrieving 20 chunks when 5 answer the question multiplies both retrieval credits and the tokens you then pay to send to the model.
Right-size the index type per corpus. Your prose knowledge base might be fine on vector-only; the parts catalogue with critical part numbers needs hybrid. You don’t have to make one global choice — different retrievers can point at differently-typed indexes.

The decision, and how it connects to grounding overall

Two questions settle the index type for a given corpus:

Do exact tokens carry meaning that a near-miss would destroy? Part numbers, error codes, legal clause references, account IDs, drug names — if a one-character difference changes the answer, you need the keyword half. Choose hybrid.
Is the corpus mostly conceptual prose queried in natural language? FAQs, how-to articles, policy explanations where users paraphrase freely — vector alone may be enough, and it’s cheaper. Choose vector, and reconsider if you see near-miss retrievals in testing.

And step back to the bigger picture: the search index is only half of grounding. It handles unstructured data — the documents. The structured half — “what was revenue in the West region last quarter,” where the risk is the agent inventing a metric rather than retrieving a passage — is a different mechanism entirely, the semantic layer. A production agent usually needs both: a well-typed search index so it retrieves the right document, and a semantic layer so it computes the right number. Treating retrieval as a single “add my knowledge” step is how teams end up with an agent that’s confidently wrong in two different ways.

Whether any of this belongs in your build at all is worth checking against the honest Data 360 dependency map for Agentforce — not every agent needs a hand-built index, and the Data Library fast path may be enough until it isn’t.

The takeaway

The agent that answers confidently and wrong is almost never a model problem. It’s a retrieval problem, and retrieval is set by the index type you chose — often without choosing. Keyword search nails exact tokens and misses paraphrase; vector search understands intent and returns confident near-misses; hybrid runs both and merges them, at a higher build-and-store cost that’s worth it wherever exact identifiers matter. Pick per corpus, not once globally; match your embedding model and chunk size to the job; scope the index to what an agent actually retrieves; and remember the index only covers your documents — the numbers are the semantic layer’s job. Get the index type right and the model stops being blamed for a mistake it never made.

Understanding the basics

What’s the difference between vector, keyword, and hybrid search in Data 360?

Keyword (lexical) search matches the exact words in a query and ranks by term importance — excellent for SKUs, part numbers, and codes, but blind to paraphrase. Vector (semantic) search embeds the query and chunks into a shared space and returns the nearest in meaning — excellent for natural-language questions and synonyms, but prone to returning confident near-misses on exact identifiers. Hybrid search builds both a vector and a keyword index, searches both, and merges and re-ranks the results, so a chunk that matches on either dimension surfaces and one that matches on both rises to the top. For most production agent grounding, hybrid is the safer default.

Which search index type should I use for Agentforce grounding?

Choose hybrid when exact tokens carry decisive meaning — part numbers, error codes, account IDs, legal clause references — because a semantic near-miss there produces a confident wrong answer. Vector-only can be enough for conceptual prose knowledge bases queried in natural language, and it’s cheaper to build and store. You don’t have to pick one type globally: different retrievers can point at differently-typed indexes, so match the index type to each corpus.

Does search-index type affect Data 360 credit cost?

Yes. Building any index consumes processing to chunk and embed the corpus, and a hybrid index maintains two indexes (vector plus keyword), so it costs more to build and store than vector-only, with re-indexing on updates costing again. Query-time retrieval also consumes credits and scales with how many chunks you retrieve and how often. The wrong-answer cost of under-indexing usually dwarfs the storage delta, so the goal isn’t to avoid hybrid but to scope indexes to what an agent actually retrieves and right-size chunk count per query.

Trying to work out why your grounded agent retrieves the wrong chunk — or which corpora need hybrid search and which can stay vector-only without blowing the credit budget? Talk to us. Getting retrieval right before it reaches the model is exactly the work we do.

Keyword, vector, or hybrid: choosing the Data 360 search index that actually grounds your agent