Short answer: Order comes from combining signals such as vector and keyword scores, often with weights, and sometimes a rerank pass.
One similarity score rarely tells the full story across different scales. Fusion methods merge kinds of scores; normalizing preserves strength that rank-position alone loses. Weighting leans lexical or semantic by query type. A second-pass reranker can refine the initial list. Engram lets systems control how surviving memories are ordered.
The previous chapter looked at deciding which retrieved memories are similar enough to keep at all. Even after that filtering happens, whatever survives still needs to come back in some order, and the order genuinely matters, since whatever appears first tends to carry the most weight in however that result actually gets used downstream. This chapter looks at how that ordering gets decided, and why a single similarity score isn’t always the whole story.
Why Isn’t a Single Similarity Score Always Enough to Decide the Right Order for a Set of Results?
A vector search score reflects how semantically close a memory’s meaning is to a query, and a keyword score reflects how directly a memory’s actual wording matches the query’s terms, but these are genuinely different measurements, on genuinely different scales, and neither alone tells the full story of what actually deserves to rank first. A memory can be semantically close to a query’s overall meaning while missing an important exact term the query used, and a different memory can hit that exact term while sitting a little further away in overall meaning. Combining these two different signals into one final ranking is exactly the job a fusion method exists to do.
How Does a Fusion Method Actually Combine Two Different Kinds of Search Scores Into One Ranking?
One common approach ranks each memory purely by its position within each individual search’s own results, rather than by its raw score, then adds those rank-based values together across both searches to arrive at a combined ranking. This approach has a real limitation: it throws away the actual magnitude of a match, treating a memory that barely edged out its closest rival exactly the same as one that dominated by a wide margin, since both simply get “rank one” regardless of how much better that top result actually was.
What Does Normalizing Raw Scores Before Combining Them Actually Preserve That Simple Rank Position Loses?
A newer approach scales each search’s own raw scores so the best result in that search becomes a full one and the weakest becomes a full zero, with everything else falling proportionally in between, before adding the two normalized values together into a final combined score. This preserves something rank position alone discards: if one search’s top few results were all nearly identical in quality, that closeness carries through into the final combined score, and if a different search had one standout result far ahead of the rest, that gap carries through too, rather than being flattened into an undifferentiated first, second, and third place.
Does a System Ever Need to Weight One Kind of Search More Heavily Than the Other When Combining Their Scores?
Yes, and this is a genuine, tunable choice rather than something fixed once and left alone. Some retrieval tasks lean more heavily on catching an exact term, a product code, a specific name, a precise phrase, where keyword matching does most of the real work, while other tasks lean more heavily on capturing an underlying meaning even when the wording differs substantially, where semantic matching does most of the real work. A weighting parameter lets a system lean the combined ranking toward whichever of the two searches actually matters more for a given kind of query, rather than always treating both equally.
Is There a Point Where Ordering the Initial Result Set Isn’t Actually the Final Word on Ranking?
There is. A second, more deliberate pass can take an already-retrieved set of candidates and re-score them using a more careful, more computationally expensive comparison than whatever produced the first ranking, reordering the results based on that closer look. This kind of second pass makes sense precisely because it only has to run against a small, already-narrowed set of candidates rather than an entire collection, letting a system afford a more careful comparison exactly where it matters most, on the handful of results that are actually going to be used.
How Does Weaviate Engram Let a System Control How Retrieved Memories Actually Get Ranked?
Weaviate Engram’s hybrid retrieval combines vector and keyword scores using a normalized fusion approach, with a tunable weighting parameter available for leaning that combination toward whichever signal actually matters more for a given search. Consider a technical documentation search assistant helping engineers find the right internal runbook, where an exact error code sometimes matters more than a runbook’s general topic, and sometimes the reverse is true:
from engram import EngramClient
from engram import HybridRetrieval
client = EngramClient(api_key=os.environ["ENGRAM_API_KEY"])
results = client.memories.search(
query="ERR_DISK_QUORUM_LOST recovery steps for the storage cluster",
properties={"team": "platform-infra"},
retrieval_config=HybridRetrieval(limit=5, alpha=0.25),
)
Lowering the weighting parameter toward the keyword side of the combination means a runbook containing the exact error code climbs to the top of the ranking even if a different runbook discusses storage clusters more broadly in a way that scores slightly higher on pure semantic similarity. A different query, one asking a broader conceptual question like “how does our storage cluster generally handle a lost quorum,” would call for shifting that same weighting parameter back toward the semantic side, since no single exact term is doing the real work of identifying the right runbook there. This is exactly the value tunable ranking delivers for a use case like technical documentation search, where engineers under pressure during an incident need the most relevant runbook to appear first, not somewhere further down a list ordered by a ranking method that wasn’t actually suited to that specific kind of query.
Ranking determines which of the results that survive a similarity threshold actually reach the top of the list, and tuning that ranking to a specific kind of query can matter as much as filtering out weak matches in the first place. Neither of these controls has assumed anything yet about combining more than one kind of retrieval within a single request. Our next chapter, How do you combine multiple retrieval strategies in one query?, takes up exactly that combination.