Data 360
Tuning Data 360 hybrid search: fusion rankers and the knobs that move recall
Your agent is grounded and still misses the right paragraph. Before you swap the fusion model, fix chunk size and the retriever's result count. This is what Data 360's three fusion rankers actually do, when RRF beats a linear weighting, and the tuning order that moves recall the most.
An agent that says ‘I don’t have that information’ when the article exists is rarely a model problem. It’s a retrieval problem, and the fix sits upstream of the prompt. The right paragraph is there. The search ranked it eighth, and your retriever only passes the top three.
Data 360’s hybrid search decides what the model gets to read, and it has more tuning surface than most teams touch. My advice before you go near the fusion model: fix chunk size and the retriever’s result count first. Config changes at that layer moved one Salesforce benchmark from 62.5% to 92.5% answer accuracy on the same data, with no model change. The wins live there.
This post is the fusion-ranking layer specifically: what the three rankers do, which one to reach for, and the knobs around them that matter more than the ranker choice itself.
What hybrid search is fusing
Hybrid search runs two queries against your indexed content and combines them. One is a vector (dense, semantic) search that matches on meaning, so ‘cancel my plan’ finds an article titled ‘terminating a subscription.’ The other is a keyword (sparse, lexical) search that matches on the actual tokens, so a part number or an error code lands exactly.
Each search returns its own ranked list. The fusion ranker is the referee that merges those two lists into the single ordering your retriever reads from.
The referee matters because the two searches disagree constantly. Vector search loves a paragraph that is topically close but wrong on the specific. Keyword search nails the specific and misses the paraphrase.
A good fusion keeps the document both methods rank highly and breaks ties sensibly. A bad one lets one method drown the other, so you get either fuzzy near-misses or brittle exact-match-only results.
The three fusion rankers, and when each earns its place
Data 360 gives you three fusion models. They are not tiers, they are different trade-offs.
Reciprocal Rank Fusion (RRF) is the industry-standard default and the one I start with. It ignores the raw similarity scores and works on rank position alone. It applies a reciprocal-rank transform with a decay constant of 60 to each list, then sums them. A document ranked first contributes 1/(60+1), second 1/(60+2), and so on, from both the keyword and the vector list.
Throwing away the raw scores is the point. Cosine similarity and keyword scores live on completely different scales, and neither is a clean measure of relevance, so ranking by position sidesteps both problems. You can still weight the two indexes if one is more trustworthy for your content. For most knowledge-grounding jobs, RRF with the defaults is a baseline that is hard to beat by fiddling.
Linear Fusion Ranking is a customizable weighted sum of the transformed dense and sparse scores. Its headline knob is alpha, which sets how much the keyword (sparse) side counts in a convex combination, with the vector side taking the remaining weight.
Push alpha up when users search in precise language your content uses verbatim: SKUs, policy codes, API names. Pull it down when queries are conversational and the exact words rarely match. Linear fusion gives you the dial and asks you to own it: set alpha once, never revisit it against real queries, and you have taken on a number you are not measuring.
Deep Fusion Ranking is the newest and the heaviest. Instead of a fixed formula, it uses a transformer to jointly score records. It folds in vector similarity, keyword matches, and two signals the other rankers treat as optional extras: popularity and recency. It captures interactions a linear model can’t, at the cost of being a model you don’t fully see into.
Reach for it when relevance depends on more than text similarity. A support corpus where the freshest, most-viewed article is usually the right one is the classic fit. Confirm its availability and any credit cost in your own org before you design around it, because a transformer in the ranking path is not free.
Two transformation functions sit underneath this and are worth knowing by name. The query max scaler normalizes scores against the top hit. The reciprocal rank transform (the one RRF leans on) converts scores to rank-based values with a configurable decay.
Tuning that decay changes how steeply rank position matters. A smaller decay makes the top few results dominate; a larger one flattens the curve so deeper results still contribute.
Vector search decides what is roughly about the query. Keyword search decides what is exactly about it. The fusion ranker decides which of those two you trust when they disagree, and that is a business decision, not a default.
Popularity and recency are weights, not magic
Both the linear and deep rankers can factor in how popular and how recent a record is, on top of pure text relevance. The idea is sound: an outdated article that matches the words perfectly should not outrank the current one everyone reads.
These are tunable weights with small default values. I would read the exact defaults straight from your index configuration rather than trust them from memory. The principle to hold onto: popularity and recency are tie-breakers on top of relevance, not a substitute for it. Turn them up too far and your agent starts preferring the trendy article over the correct one.
Tune in this order, because the ranker is rarely the bottleneck
The part teams skip is the order. The fusion ranker is the last thing to tune, not the first, because two settings around it move recall far more.
Chunk size comes first. Indexing splits your documents into chunks, and the chunk is the unit that gets embedded and retrieved. Chunks that are too small shred a multi-step procedure across three fragments, and no fusion model reassembles them.
For content with tables or step-by-step instructions, Salesforce’s guidance is to start at a chunk size of 512 tokens or higher so a procedure stays whole. Getting this wrong is the most common cause of an agent that can’t find something plainly in the source.
Result count comes second. Your retriever returns the top N chunks, and N is a direct lever on both recall and cost. Set it too low and the right chunk gets ranked out of the window your fusion just ordered.
Set it too high and you stuff the model’s context with near-misses. That dilutes the answer, and on the Agentforce side it can push a single retrieval action over its token ceiling into multiple billed actions. Three to five well-ordered chunks beats ten noisy ones almost every time. Getting the retriever’s filters and result count right is where most of the answer-quality gain lives.
Only after those two do you A/B the fusion ranker. Even then, two indexing features usually beat a ranker swap. Enriched indexing generates extra chunks during indexing to improve recall and precision, so more phrasings of the same fact become retrievable.
Intelligent parsing keeps tables intact and preserves section hierarchy while chunking. That stops the classic failure where a table becomes an unreadable run of numbers the moment it is embedded. Both features act on the content before the ranker sees it, and a ranker cannot rescue content that was mangled on the way in.
How this sits in the wider grounding stack
Fusion ranking is one decision inside a chain, and it pays off only if the decisions around it are right. The index type you built on decides what fusion is even possible: RRF and the rest apply to a hybrid search index, not a keyword-only one.
The retriever reads the fused list and hands chunks to the prompt, so its configuration bounds everything downstream. All of it runs on Data 360 credits for indexing and search, which is why retrieval discipline is also cost discipline. A bloated top-K and an oversized chunk cost you twice: once in answer quality, once on the meter.
There is a measurement gap here too. You cannot tune what you are not scoring. Build a small ground-truth set of real user questions, each paired with the chunk that should answer it, and measure how often retrieval puts that chunk in the returned window before and after a change.
Without that, every tuning decision is a guess, and you will fix retrieval three times without knowing which change helped. The same discipline keeps an agent grounded rather than guessing: the grounding is only as good as your evidence that it works.
What I would do
Start by reading, not tuning. Pull ten questions your agent gets wrong, find the chunk that should have answered each, and check whether it was even in the retrieved set. If it wasn’t, the ranker is innocent, and your chunk size or result count is the culprit.
Raise chunk size to 512 or higher for procedural and tabular content. Set the retriever to return three to five chunks, turn on intelligent parsing and enriched indexing, and re-measure against those ten questions.
Then, and only then, touch the fusion ranker. Keep RRF as your baseline. Move to linear fusion when users search in your content’s exact vocabulary and you want to lead with keyword matches, tuning alpha against real queries rather than a guess.
Consider deep fusion when recency and popularity clearly predict the right answer and you can afford a heavier ranker. Change one thing at a time, and let the ground-truth set, not the demo, tell you whether it worked.
Understanding the basics
What is hybrid search in Salesforce Data 360?
Hybrid search runs a vector (semantic) query and a keyword (lexical) query against your indexed content at the same time, then merges the two ranked result lists into one. The vector side matches on meaning and the keyword side matches on exact tokens, so together they catch both paraphrased questions and precise identifiers like part numbers. A fusion ranker combines the lists, and a retriever passes the top results to your agent or prompt template as grounding.
What is the difference between RRF, Linear Fusion, and Deep Fusion ranking?
RRF merges the two lists by rank position (a reciprocal-rank transform with a decay of 60), ignoring raw scores, which makes it a resilient default. Linear Fusion Ranking is a weighted sum of the transformed scores, with an alpha parameter setting how much keyword search counts. Deep Fusion Ranking uses a transformer to jointly score records, weighing popularity and recency alongside text relevance at higher cost.
Why does my Agentforce agent fail to find an answer that exists?
The most common cause is retrieval, not the model. Either the content was chunked so small that a procedure was split across fragments, or the retriever’s result count is too low and the right chunk was ranked just outside the returned window. Raise the chunk size for procedural and tabular content, return three to five chunks rather than one or two, and confirm the search index status is ready before blaming the fusion ranker or the language model.
Which fusion ranker should I start with?
Start with RRF and leave it there unless you have a measured reason to change. It needs no tuning, tolerates the different score scales of keyword and vector search, and is a strong baseline for knowledge grounding. Move to Linear Fusion when users query in your exact terminology and you want to weight keyword matches up, and only consider Deep Fusion when recency or popularity clearly predicts the right result and you can absorb the extra credit cost.
Grounding an agent that keeps missing answers it should find, or trying to get retrieval trustworthy before you scale topics? Talk to us. Getting the Data 360 foundation right so an agent retrieves cleanly instead of guessing is the work we do.
