How do you combine multiple retrieval strategies in one query?

Every retrieval type covered so far in this Part has been treated as a choice made on its own, vector, keyword, hybrid, or fetch, picked once for a given search and used as-is. Real requests are often less clean than that, carrying a mix of a genuine relevance question alongside a hard, non-negotiable constraint at the same time. This chapter looks at combining a relevance-based search with a strict filter in a single query, rather than treating those two demands as if they had to be handled separately.

Why Doesn’t a Relevance Search Alone Handle a Request That Also Carries a Hard Constraint?

A relevance search, whether vector, keyword, or hybrid, ranks candidates by how well they match a query, but ranking assumes every candidate is at least eligible to be considered in the first place. A hard constraint, only memories from a specific customer account, only records created after a specific date, only items belonging to a specific category, isn’t a matter of degree the way relevance is. A memory either meets that constraint or it doesn’t, and no amount of semantic closeness to the query should let an ineligible memory past a requirement like that.

What Actually Happens When a Filter and a Relevance Search Run Together in the Same Query?

A filter narrows the pool of eligible candidates down to only those meeting its exact condition, and the relevance search then ranks only within that narrowed pool, never considering anything the filter already excluded. This ordering matters: applying the filter first means the relevance search’s own ranking work happens over a smaller, already-qualified set, rather than ranking everything first and only discovering afterward that many of the top-ranked results actually violate the constraint and have to be thrown out.

Why Does the Order in Which a Filter and a Search Are Applied Actually Matter for the Quality of a Result Set?

Applying a search first and filtering its output afterward risks a genuinely broken outcome: if the search’s own limit returns only a handful of top candidates and none of them happen to satisfy the filter, the final result set ends up empty or badly undersized, even though plenty of genuinely matching, filter-satisfying memories exist further down in the full collection that the search never got to consider. Applying the filter first avoids this failure mode entirely, since the relevance search only ever sees the already-eligible candidates it needs to rank in the first place.

Can More Than One Filter Condition Be Combined Together, and Does That Combination Get More Complicated to Reason About?

Yes, filter conditions can be combined with logical AND and OR, nested as needed to express something like “belongs to this specific project AND was created after a certain date” or “flagged as urgent OR assigned to this particular team.” Each individual condition stays simple to reason about on its own, and the logical combination determines how those individually simple conditions interact, without requiring the relevance search itself to somehow understand or express any of that structured logic directly.

Does Combining Multiple Vector Fields Within a Single Object Work the Same Way as Combining a Filter With a Search?

It’s a related but distinct kind of combination. Rather than narrowing a pool of candidates down by a hard, binary condition, searching across multiple vectors on the same object, one built from a title, another built from a longer description, blends the similarity scores from each of those vectors together into one combined ranking. This is still a relevance-based combination throughout, unlike a filter, but it lets a single query draw on more than one representation of what an object actually is, weighting each representation’s contribution according to how much it should count toward the final ranking.

How Does Weaviate Engram Let a System Combine a Relevance Search With a Hard, Non-Negotiable Constraint in One Request?

Weaviate Engram’s search method accepts scoped properties alongside a relevance-based retrieval configuration, applying the property match as a hard filter before the relevance ranking runs. Consider a corporate expense-approval assistant, helping a finance reviewer find prior justifications for similar expenses, but only ever within the specific cost center that reviewer is actually responsible for approving:

from engram import EngramClient
from engram import HybridRetrieval

client = EngramClient(api_key=os.environ["ENGRAM_API_KEY"])

results = client.memories.search(
    query="Justification for a client-dinner expense exceeding the standard per-meal limit",
    properties={"cost_center": "cost-center-4471", "status": "approved"},
    retrieval_config=HybridRetrieval(limit=5),
)

The two scoped properties, cost center and approval status, act as a hard filter, narrowing the search down to only previously approved expenses from this specific reviewer’s own cost center, before the hybrid relevance search ranks those narrowed-down candidates by how closely they actually resemble the current expense under review. A justification from a different cost center, however semantically similar its wording might be to the current expense, never enters into the ranking at all, since it never passes the filter in the first place. This is exactly the value combining a filter with a relevance search delivers for a use case like expense approval, where a reviewer genuinely needs both things at once: a search that understands the meaning of a specific justification, and an absolute guarantee that results never cross a boundary that should never be crossed regardless of how relevant a result from elsewhere might otherwise look.

Combining a filter with a relevance search handles a request carrying both a hard constraint and a genuine question of relevance within the same lookup. A different concern shapes how well any of these combined queries actually feel to use in practice, and that concern is simply how fast a search comes back with an answer. Our next chapter, How does retrieval latency affect agent responsiveness?, takes up exactly that question.