Short answer: Use rules for predictable patterns; use an LLM when open-ended meaning and flexible phrasing matter.
Rule-based extraction matches fixed formats like IDs or phone numbers cheaply and predictably, but fails when input shape varies. An LLM judges meaning across conversational, inconsistent wording at higher cost and with some misinterpretation risk. The approaches are complementary: rules for rigid fields, models for open content. Engram’s default extraction leans LLM where conversation demands that flexibility.
Every extraction example covered so far in this Part has quietly assumed a large language model is the thing actually doing the extracting. That’s a real design decision, not an inevitability, and it’s worth examining directly. Rule-based extraction, matching patterns and fixed structures, is a genuine alternative that predates language models by decades, and understanding when each approach actually fits better clarifies why this knowledge base treats an LLM as the default rather than the only option.
What Does Rule-Based Extraction Actually Look Like in Practice?
Rule-based extraction relies on fixed patterns, regular expressions, keyword matches, or structural cues, to pull specific pieces of information out of text according to rules written in advance by a person who understood exactly what shape the input would take. A rule built to extract a phone number, an order identifier, or a date from a consistently formatted document can do so quickly and predictably, with no ambiguity about why it matched what it matched. This approach works exceptionally well precisely because it doesn’t try to understand meaning at all, it simply looks for the specific pattern it was told to find.
Why Does This Same Rigidity Become a Genuine Weakness the Moment Input Stops Following a Predictable Shape?
A rule written to match one specific phrasing or format has no ability to recognize the same underlying fact expressed in a genuinely different way, a synonym, a rephrasing, or an unanticipated sentence structure the rule’s author never considered when writing it. Natural conversation is exactly this kind of unpredictable input, the same fact might be stated a dozen different ways across different people and different contexts, and a rule-based system would need a separate, explicitly authored rule for every single one of those variations to catch them all reliably. This is precisely the gap that made rule-based extraction historically difficult to scale to genuinely open-ended, conversational content.
What Does an LLM Actually Bring to Extraction That a Fixed Rule Fundamentally Can’t?
A language model brings genuine understanding of meaning rather than pattern matching alone, recognizing that two very differently worded statements describe the same underlying fact, or that a fact is implied by context even when it’s never stated in an obvious, directly matchable form. This flexibility is exactly what lets extraction handle the kind of unpredictable, conversational phrasing this knowledge base has assumed throughout its discussion of extraction, without needing a human to anticipate and write a separate rule for every possible way a fact might actually get expressed.
Does This Flexibility Come at a Real Cost Compared to Simple, Rule-Based Matching?
It does, on more than one front. An LLM-based extraction step costs more computationally than a simple pattern match, and it introduces a small but real risk of misinterpreting content in ways a rigid rule simply can’t, a rule either matches its exact pattern or it doesn’t, while a model’s judgment about meaning can occasionally be wrong in ways that are harder to predict in advance. This tradeoff isn’t a flaw unique to memory extraction, it’s the same fundamental tradeoff that shows up whenever flexible, meaning-aware processing gets weighed against fast, predictable, but rigid pattern matching.
Are These Two Approaches Actually Mutually Exclusive, or Can a System Reasonably Use Both?
They’re not mutually exclusive at all, and a well-designed system often benefits from combining them rather than committing entirely to one or the other. Content with a genuinely predictable, consistent structure, an identifier that always appears in the same format, a status code drawn from a small fixed set of values, is a strong candidate for a fast, cheap, reliable rule rather than the added cost and interpretive risk of routing it through an LLM. Content that’s genuinely open-ended and conversational, where meaning has to be understood rather than merely matched, is exactly where an LLM’s flexibility earns its cost. The right system uses each approach where it actually fits best, rather than defaulting reflexively to either one for everything.
How Does Weaviate Engram’s Extraction Step Fit into This Broader Landscape of Extraction Approaches?
Weaviate Engram’s extraction step uses an underlying language model specifically because the conversational, open-ended content it’s built to handle doesn’t lend itself to fixed, predictable patterns a simple rule could reliably catch. Consider a customs brokerage’s shipment-documentation intake assistant, processing correspondence from freight forwarders where the same critical detail might be phrased in genuinely different ways from one message to the next:
from engram import EngramClient
client = EngramClient(api_key=os.environ["ENGRAM_API_KEY"])
client.memories.add(
"The forwarder mentioned the harmonized tariff classification on this shipment might need reclassification, since the goods actually contain a higher proportion of synthetic fiber than the original filing indicated.",
properties={"shipment_id": "shipment-hts-review-3391"},
)
A rule built to catch a specific, exact phrasing about tariff classification would likely miss this particular message entirely, since the concern here is expressed indirectly through a fiber-content detail rather than through any single, consistently matchable keyword or pattern:
results = client.memories.search(
query="Are there any pending tariff classification concerns on this shipment?",
properties={"shipment_id": "shipment-hts-review-3391"},
)
Engram’s LLM-powered extraction step recognizes this as a genuine tariff classification concern despite its indirect phrasing, exactly the kind of understanding a fixed rule would need to have been explicitly written to anticipate and would very likely have missed. For a use case like customs documentation, where correspondence rarely uses perfectly consistent phrasing and where missing a genuine compliance concern carries real consequences, this flexibility is exactly why an LLM-powered approach fits the underlying content better than a rigid, rule-based alternative ever could.
Choosing an LLM for extraction trades some cost and predictability for the flexibility conversational, open-ended content genuinely demands. Once extraction identifies what’s actually worth remembering, the pipeline’s next stage takes over, deciding how each newly identified fact should actually integrate with everything a system already knows. Our next chapter, What happens during the transform stage?, takes up exactly that stage.