Short answer: Vector, keyword, hybrid, and direct fetch each match different questions against the same store.
Vector finds meaning without exact wording. Keyword wins on precise terms and identifiers. Hybrid blends both and is a sensible default for mixed query styles. Direct fetch skips ranking and loads a known memory by topic and scope, such as a profile or running summary. Engram lets callers choose the type that fits each search.
The previous Part followed memory all the way from raw input to a durable, indexed store ready to be searched. Getting a memory into that store is only half the story, the other half is actually retrieving it well. This Part turns to retrieval itself, starting with the most fundamental decision a caller makes every time it searches: which retrieval type to actually use.
Why Does a Memory System Offer More Than One Way to Search the Exact Same Stored Content?
Different questions genuinely call for different kinds of matching. Some questions are best answered by meaning, finding a memory that’s conceptually related to a query even if it never uses the query’s exact wording. Others are best answered by exact terms, finding a memory that contains a specific word or phrase precisely as written. Still others don’t need any matching at all, a caller already knows exactly which memory it wants and simply needs it returned directly. A single retrieval mechanism can’t serve all of these well at once, which is exactly why a memory system offers several distinct retrieval types rather than forcing every search through one universal approach.
What Does Vector Retrieval Actually Do Differently from the Other Types?
Vector retrieval compares a query’s meaning against a memory’s meaning, both represented as embeddings, surfacing memories that are conceptually related to a query even when the specific words don’t overlap at all. This makes vector retrieval genuinely strong at handling natural, loosely phrased questions, tolerating synonyms, paraphrasing, and even queries in a different language than the memory itself was originally recorded in. Its corresponding weakness is a lack of exact-match guarantees, a specific term a caller genuinely needs matched precisely isn’t something vector retrieval is actually built to promise.
When Does Keyword Retrieval Actually Outperform the More Flexible Semantic Approach?
Keyword retrieval, built on exact term matching rather than meaning, excels precisely where vector retrieval struggles, situations where a specific, exact term genuinely needs to appear in a result, an identifier, a precise technical term, a specific name that shouldn’t be diluted by semantic approximation. This predictability is itself a real strength, a caller can understand exactly why a keyword result matched, something vector retrieval’s more approximate, meaning-based matching doesn’t offer nearly as transparently.
Why Does Hybrid Retrieval Serve as the Reasonable Default for Most Everyday Searches?
Hybrid retrieval runs both the semantic and keyword comparisons together, blending their results so that a search benefits from vector retrieval’s tolerance for loose, natural phrasing while still rewarding exact-term matches the way keyword retrieval alone would. This combination handles the genuinely unpredictable mix of query styles a real caller actually produces, sometimes precise, sometimes loosely worded, without requiring a caller to correctly guess in advance which single retrieval type would have worked best for that specific query. This versatility is exactly why hybrid retrieval is the sensible starting point for most general-purpose search rather than an exotic, specialized choice.
What Does Direct Fetch Retrieval Actually Do, and Why Doesn’t It Fit the Same Pattern as the Other Three?
Fetch retrieval skips relevance ranking entirely, returning a specific memory directly by its known topic and scope rather than comparing a query against stored content at all. This fits naturally with the bounded topics covered earlier in this knowledge base, a running conversation summary or a per-user profile, where a caller already knows precisely which single memory it wants and has no actual need to rank it against alternatives that, by definition, don’t even exist for that exact scope. Fetch retrieval isn’t a weaker or more limited version of the other three types, it’s answering a genuinely different kind of question, “give me the one thing I already know exists here” rather than “find me whatever’s most relevant.”
How Does Weaviate Engram Let a Caller Choose the Right Retrieval Type for a Specific Search?
Weaviate Engram exposes all four retrieval types directly through its search configuration, letting a caller match the retrieval approach to what a specific query actually needs. Consider a corporate onboarding assistant helping new hires navigate company policies and their own personalized onboarding checklist:
from engram import EngramClient
from engram import VectorRetrieval, BM25Retrieval, HybridRetrieval, FetchRetrieval
client = EngramClient(api_key=os.environ["ENGRAM_API_KEY"])
benefits_context = client.memories.search(
query="How does the company handle time off for new parents?",
user_id="employee-onboarding-2291",
retrieval_config=VectorRetrieval(limit=5),
)
policy_code = client.memories.search(
query="POL-4471",
user_id="employee-onboarding-2291",
retrieval_config=BM25Retrieval(limit=5),
)
general_search = client.memories.search(
query="What do I need to set up before my first day?",
user_id="employee-onboarding-2291",
retrieval_config=HybridRetrieval(limit=10),
)
checklist = client.memories.search(
query="onboarding checklist",
user_id="employee-onboarding-2291",
topics=["OnboardingChecklist"],
retrieval_config=FetchRetrieval(limit=1),
)
The parental leave question benefits from vector retrieval’s tolerance for a naturally phrased, conceptual question, the exact policy code benefits from keyword retrieval’s precision, the general first-day question benefits from hybrid retrieval’s balance of both, and the onboarding checklist, a single bounded memory the assistant already knows exists for this specific new hire, gets returned directly through fetch retrieval without any relevance ranking at all. Choosing correctly among these four options, rather than defaulting reflexively to just one, is exactly what lets this assistant serve genuinely different kinds of questions well.
Choosing the right retrieval type matches how a search actually works to what a specific question actually needs. A related but distinct question sits just as close to the surface: not which retrieval type to use, but when retrieval should actually happen in the first place, whether a system should search on its own initiative or only in direct response to an explicit request. Our next chapter, What is proactive recall vs reactive recall?, takes up exactly that question.