Short answer: Recall is how much of the relevant set you found; precision is how much of what you returned was relevant.
High precision with low recall means clean results that miss important memories. High recall with low precision means broad coverage plus noise. You cannot maximize both at once; chunking, alpha, and reranking all move this balance. Favor recall when missing a fact is costly, and precision when the context window needs a tight, focused set. Engram exposes that tuning for memory search.
Chunking, embedding models, and retrieval strategies have all been covered as separate technical decisions throughout this Part, but they all ultimately serve the same two underlying goals, and those two goals genuinely pull against each other. Recall and precision are the formal names for those goals, and nearly every tuning decision covered so far in this Part, from chunk size to hybrid search’s alpha parameter to reranking, is really a decision about how to balance the two.
What Do Recall and Precision Actually Measure, Stated Precisely?
Precision measures what fraction of what a search actually returned was genuinely relevant, out of everything handed back. Recall measures what fraction of everything genuinely relevant across the whole collection actually got returned, out of everything that should have been found. These are answering two different questions: precision asks “of what I got, how much was actually useful,” while recall asks “of what was actually out there to find, how much did I actually get.” A search can score well on one of these while scoring poorly on the other, and a system tuned exclusively for one without regard for the other will eventually produce a specific, predictable kind of failure.
What Does It Actually Look Like When a Search Has High Precision but Low Recall?
A search returning only a small handful of results, every single one of them genuinely relevant, has excellent precision, nothing wasted, nothing irrelevant handed back. But if that same search missed several other memories that were just as genuinely relevant and simply never got returned, its recall is poor, since a meaningful fraction of what actually existed and mattered never made it into the result set at all. This failure is subtle precisely because it doesn’t look like a failure from the results themselves, everything returned looks great, the problem is entirely in what never got returned in the first place, invisible unless someone specifically goes looking for what was missed.
What Does It Look Like in the Opposite Direction, High Recall but Low Precision?
A search that casts an extremely wide net, returning nearly everything even remotely related to a query, will likely capture most or all of the genuinely relevant memories somewhere within that large result set, giving it strong recall. But that same wide net also pulls in a large amount of tangential, weakly related material alongside the genuinely relevant content, diluting the result set with noise and forcing whatever consumes those results, a person or a model, to sort through considerably more material than actually mattered. This connects directly back to the context-rot and pollution failure modes covered earlier in this knowledge base: a search optimized purely for high recall, with no corresponding attention to precision, tends to produce exactly the kind of bloated, low-signal context those chapters warned against.
Why Can’t a System Simply Maximize Both Recall and Precision at Once?
These two goals sit in genuine tension because they respond to the exact same lever, how much a search actually returns, in opposite directions. Returning more tends to raise recall, since a broader net is more likely to capture everything genuinely relevant, but it simultaneously tends to lower precision, since that broader net also captures more irrelevant material along with it. Returning less tends to raise precision by keeping the result set tightly focused, but at the direct cost of recall, since some genuinely relevant material inevitably gets left outside that narrower net. This tradeoff is fundamental to how ranked retrieval works, not a flaw specific to any one particular search technique covered elsewhere in this Part.
How Should a System Actually Decide Which Side of This Tradeoff to Favor for a Given Task?
The right balance depends entirely on what the actual cost of each kind of mistake looks like for the specific task at hand. A task where missing a genuinely relevant piece of information carries serious consequences should lean toward favoring recall, accepting some extra noise in exchange for confidence that nothing important got left out. A task where sorting through irrelevant material wastes meaningful time or actively risks confusing whatever consumes the results should lean toward favoring precision instead, accepting the risk of occasionally missing something in exchange for a cleaner, more focused result set. Neither answer is universally correct, the right balance is a judgment call specific to what a particular search is actually being used for.
How Does Weaviate Engram Let This Balance Be Tuned Deliberately for Memory Retrieval?
Weaviate Engram’s retrieval limit and relevance threshold together give a search direct control over exactly this tradeoff, letting a task that genuinely can’t afford to miss something lean toward recall, while a task that needs a clean, focused result set leans toward precision instead. Consider an insurance fraud-investigation assistant helping investigators review a claimant’s history, where missing a genuinely relevant prior pattern carries real, serious consequences:
from engram import EngramClient
client = EngramClient(api_key=os.environ["ENGRAM_API_KEY"])
client.memories.add(
"Claimant filed three separate water-damage claims across two different addresses within an eighteen-month window, each involving a different insurer, a pattern flagged during a prior cross-referencing review.",
properties={"claimant_id": "claimant-7734"},
)
An investigator’s initial search deliberately favors recall, since missing a genuinely relevant prior flag here carries real consequences:
broad_review = client.memories.search(
query="Any prior flags, patterns, or concerns associated with this claimant?",
properties={"claimant_id": "claimant-7734"},
retrieval_config=HybridRetrieval(limit=20),
)
A different, later search, specifically confirming one exact prior claim detail an investigator has already identified as relevant, can reasonably favor precision instead, since at that point the investigator already knows roughly what they’re looking for and just needs the exact, focused answer:
specific_confirmation = client.memories.search(
query="What were the exact dates of the two water-damage claims at different addresses?",
properties={"claimant_id": "claimant-7734"},
retrieval_config=HybridRetrieval(limit=3),
)
The first search’s wider limit deliberately favors recall, accepting some extra, less relevant material in exchange for confidence that no genuinely important flag on this claimant got missed, given how costly that kind of miss would actually be in this context. The second search’s narrower limit favors precision instead, since the investigator’s need at that specific moment is a clean, focused answer rather than broad coverage. Neither setting is correct for both situations, which is exactly the deliberate, task-aware tuning this chapter has been describing.
Recall and precision describe a fundamental tradeoff in what gets returned from a fixed, already-indexed collection. A related but distinct tradeoff shows up specifically when deciding whether a search should check every single stored item exactly, or accept some approximation in exchange for speed at genuinely large scale. Our next chapter, When should you use approximate vs exact vector search?, turns to exactly that question.