What is fetch-based retrieval for bounded memories?

The first chapter of this Part introduced fetch retrieval briefly, alongside the other three retrieval types, as the option that skips relevance ranking entirely. This chapter looks at fetch retrieval more closely on its own, because it works on a genuinely different principle from vector, keyword, and hybrid search, and understanding that difference clarifies exactly when it’s actually the right tool to reach for.

Why Does Fetch Retrieval Not Need to Rank Anything Against a Query in the First Place?

Vector, keyword, and hybrid retrieval all exist to answer a version of the same question, out of everything stored, what’s actually most relevant to this specific query. Fetch retrieval answers a different question entirely: given a specific topic and a specific scope, what’s the one memory that already, definitionally, exists there. There’s nothing to rank because there’s nothing to compare against, a bounded topic guarantees at most one memory per scope, so retrieving it is a matter of direct lookup rather than search.

What Does It Actually Take for a Memory to Be Eligible for This Kind of Direct, Unranked Lookup?

The memory has to live in a bounded topic, one configured to hold at most a single memory for any given scope, with that single memory’s identifier derived deterministically from the topic and scope themselves rather than generated freshly for every new fact. This is exactly what makes fetch retrieval reliable, since the lookup isn’t guessing which memory might be the right one among several candidates, it’s retrieving the one memory a bounded topic guarantees can exist at that specific scope, full stop.

Why Does Skipping Relevance Ranking Actually Matter for the Kind of Content a Bounded Topic Typically Holds?

A running profile or a running summary is meant to be comprehensive by design, capturing the complete current state of something rather than one isolated fact among many similar ones. Applying relevance ranking to content like this doesn’t actually make sense, there’s no meaningful sense in which a single, comprehensive profile is “more” or “less” relevant to a given query, it’s either the current profile or it isn’t. Fetch retrieval respects this by treating the memory as a known, singular object to retrieve directly, rather than forcing it through a ranking mechanism built for comparing among genuinely distinct alternatives.

How Does a Caller Actually Know in Advance That Fetch Retrieval Is the Right Choice for a Given Search?

The deciding signal is whether a caller already knows precisely which memory it wants before the search even runs, rather than needing the search itself to figure that out. If a caller can name the exact topic and scope in advance, a specific user’s profile, a specific conversation’s running summary, fetch retrieval is the right, more direct choice. If a caller genuinely doesn’t know in advance which memory, out of several candidates, will actually turn out to be relevant, that’s exactly the situation vector, keyword, or hybrid retrieval exists to handle instead.

Does Fetch Retrieval Actually Save Meaningful Cost Compared to Simply Running an Ordinary Search and Hoping the Right Memory Comes Back on Top?

It does, in more than one way. A search that ranks candidates against a query does real computational work comparing that query against everything eligible, work that’s entirely unnecessary when the target memory is already known with certainty. Beyond raw efficiency, fetch retrieval is also simply more reliable for this specific case, since an ordinary ranked search always carries some small risk that an unrelated candidate edges out the intended one, a risk that doesn’t exist at all when the lookup is direct rather than comparative.

How Does Weaviate Engram Let a System Use Fetch Retrieval for This Kind of Known, Bounded Memory?

Weaviate Engram’s `FetchRetrieval` mode returns a bounded topic’s memory directly by topic and scope, without any relevance scoring involved. Consider a subscription meal-kit service’s dietary-profile assistant, maintaining one comprehensive, always-current profile per subscriber covering their allergies, preferences, and household size:

from engram import EngramClient
from engram import FetchRetrieval

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

client.memories.add(
    "Subscriber has a shellfish allergy, prefers low-spice meals, and cooks for a household of three.",
    user_id="subscriber-mealkit-6604",
    topics=["DietaryProfile"],
)

profile = client.memories.search(
    query="dietary profile",
    user_id="subscriber-mealkit-6604",
    topics=["DietaryProfile"],
    retrieval_config=FetchRetrieval(limit=1),
)

Because `DietaryProfile` is configured as a bounded topic, every update to this subscriber’s preferences rewrites the same single memory in place rather than accumulating separate, competing entries, and fetching it back requires no relevance comparison at all, just a direct lookup by the subscriber’s own scope. Every time this service selects meal options for that subscriber, it retrieves exactly this one comprehensive profile, reliably and without the small uncertainty an ordinary ranked search would otherwise introduce. This is exactly the value fetch retrieval delivers for a use case like a dietary profile: a single, definitively known memory retrieved directly, precisely because there was never anything genuinely ambiguous to rank in the first place.

Fetch retrieval works cleanly for a single, bounded memory known in advance. Some questions genuinely can’t be answered by retrieving just one memory at all, they require following a connection from one memory to another, and then possibly another, before the full answer actually comes into view. Our next chapter, What is multi-hop retrieval across related memories?, takes up exactly that challenge.