Dissecting GPT, Part 3: Implicit Knowledge vs. Explicit Memory
Implicit Knowledge vs. Explicit Memory:
Why truly useful AI looks like a “consultant + records room” combo
Preface: When the AI consultant sounds brilliant—but gets the numbers wrong
Let’s start with a situation you’ve probably encountered.
You drop a company slide deck into ChatGPT and ask:
“Help me summarize this company’s growth drivers over the past three years, and add some industry context.”
The AI returns a polished summary:
- Logical and well-structured
- Professional wording, steady tone
- Reads exactly like something a consulting firm manager would write
Until you check the actual figures and notice issues:
- Revenue growth rate is wrong
- EBITDA margin doesn’t match the financials
- The market size it cites isn’t from the year you’d expect
The content “has good sense,” but the details “aren’t reliable.”
If you’ve had this experience, it’s not bad luck—it’s how LLMs are built:
They’re naturally strong at “understanding and expression,”
not at “recalling the newest, most precise facts.”
Which raises two questions:
- How do we give this super “language consultant” a constantly updated records room?
- How do we make it actually read the relevant documents before telling the story?
That’s today’s topic:
Implicit knowledge vs. explicit memory—and the real roles behind RAG and GraphRAG.
1) The LLM’s implicit knowledge: a well-read consultant who won’t memorize your P&L
In Parts 1 and 2, we framed the LLM as:
Not a database, but a “world model” trained on massive text.
Knowledge is compressed into weights as distributed representations—a kind of “digital intuition.”
That intuition has clear strengths:
- Text comprehension: throw it a report and it quickly finds the core ideas
- Synthesis and rewriting: it recombines scattered information into a coherent narrative
- Reasoning ability: it can answer “why” and “what if” questions
- Tone control: it can write like a slide deck, press release, or investor memo on cue
Yet in real work, a few weaknesses show up:
- Poor at “the latest”
The model’s knowledge freezes at its last training cutoff.
It may not know what happened in the past six months.
- Unreliable for exact numbers and legal text
Great at storytelling; risky for “what was 2023 Q4 gross margin?”
- Zero awareness of your internal knowledge
SOPs, internal policies, project docs, internal dashboards—none are in the training data.
So expecting an LLM to “answer everything” in a company
is like hiring a McKinsey consultant
and giving them no internal materials—just “go off your memory.”
They’ll produce thoughtful strategic angles,
but you wouldn’t trust them to “fill in the financial footnotes.”
2) Explicit memory: what’s the difference between full-text search, vector databases, and GraphRAG?
To complement the LLM’s natural blind spots, engineers bring in a whole other universe: explicit memory systems.
The names sound many, but the roles are straightforward.
1. Full-text search: the veteran, keyword-era librarian
This is the classic approach.
- You enter keywords like “rate decision,” “TSMC 2023 earnings call”
- The system finds “textually” matching passages across documents
- Results are ranked by relevance
It’s like an old-school librarian:
you say the topic; they know which shelves to point to.
Pros:
- Fast
- Precise keyword matching
- Mature tools and implementations
Cons:
- You must craft good keywords
- Different phrasings can miss the same concept (semantic equivalents slip by)
2. Vector databases: a modern records room that understands some semantics
Vector DBs add a layer:
- They don’t just compare surface words
- Each passage is embedded into a “semantic vector”
- Similarity is measured by vector distance (semantic closeness)
For example:
“Long-term yen depreciation—what does it mean for exports?”
vs.
“Does a weak exchange rate benefit Japanese exporters?”
Different wording, similar meaning.
Vector search will pull them closer than pure keywords.
Think of it as:
a librarian who doesn’t just read titles—roughly understands what’s inside.
3. GraphRAG: from “a pile of passages” to “entities and relationships”
One level up is GraphRAG.
It cares not only about “which passages are relevant,” but also about:
- The “entities” inside those passages (companies, people, products, events)
- The “relationships” between entities (M&A, partnerships, competition, supply chain)
This turns data from “many paragraphs” into “a graph.”
In business terms:
GraphRAG is like the “industry maps” and “value chain diagrams” a strategy analyst draws.
You move from:
- “Company A mentions Product B X times”
to:
- “Company A is a contract manufacturer for Product B”
- “Product B primarily sells to Brand C”
- “Brand C has recently increased activity with Line D”
For many problems, graph structure is more useful than raw text.
3) Why LLM-only or RAG-only is not enough
LLM-only:
- Great storytelling
- Solid reasoning
- Smooth writing
- But likely to fumble specific facts, years, or numbers
RAG-only (or search-only):
- Finds the right passages
- Guarantees the “original text” is accurate
- But won’t interpret: what matters? what relates to what? what trend does it imply?
In one line:
LLMs excel at “understanding and generating,” not “recording and updating.”
RAG excels at “recording and retrieval,” not “understanding and reasoning.”
The real power emerges when the two are combined.
4) The essence of RAG: make the AI consultant read the materials before speaking
RAG stands for Retrieval-Augmented Generation.
Translate the engineering term into “daily workflow”:
Imagine you’re a strategy consultant preparing an industry brief.
You don’t:
- Sit down and type from memory.
Instead, you:
- Go to the records room (or internal knowledge base)
- Pull prior research reports
- Scan the latest few quarters’ financials
- Review news and key events
- Gather the “most relevant” materials onto your desk
Then you:
- Extract key points
- Compare and contrast
- Draw conclusions
- Write a brief for decision-makers
RAG mirrors those three steps:
- Retrieval:
Use vector DBs, full-text search, GraphRAG, etc.,
to pick the parts most relevant to the question from a large corpus.
- Augmentation:
Feed those passages, graphs, and data
as “context” to the LLM.
- Generation:
After “reading” that context, let the LLM apply its implicit world model to:
interpret, rewrite, reason, and summarize.
In short:
- Without RAG:
“I know common industry templates. I’ll tell you a plausible version.”
- With RAG:
“I reviewed your specified materials first, then used my understanding of the world to produce a tailored analysis.”
5) GraphRAG: when the task isn’t “find some passages,” but “surface the relationship network”
Vanilla RAG often retrieves “a few related documents.”
But many business questions can’t be answered by a single document.
Examples:
- “How do these three companies interact across the supply chain?”
- “Which M&A deals reshaped the industry in recent years?”
- “In our internal project history, which decision points proved pivotal?”
These are about:
- Identifying nodes (companies, projects, products, events)
- Seeing how they connect
- Then having the LLM explain “what the graph implies”
GraphRAG adds a step before RAG:
From a large document pool, it extracts:
- Names (people, companies, projects, products), time, locations
- Relationships (investment, partnership, competition, upstream/downstream, etc.)
It then builds a “graph”:
- Nodes are entities
- Edges are relations
When you query,
it doesn’t just fetch “similar passages,”
it traverses the graph to find the subgraph most relevant to your question.
Finally, it converts that subgraph back into LLM-readable text (or structured data)
for interpretation.
In effect:
- Plain RAG: from a sea of articles, pick the paragraphs you should read.
- GraphRAG: from the entire relationship graph, pick the lines you should focus on now.
6) For enterprises, where does this “consultant + records room” combo land?
With this framing, lots of use cases can be redesigned.
1. Internal knowledge-base Q&A
Scenario:
A new hire asks, “What’s our pricing strategy for this customer segment?”
Approach:
- RAG retrieves relevant content from internal docs, slides, and meeting minutes
- LLM consolidates into a response that is:
- Clearly structured
- Version-aware
- With cautions and notes
Benefit:
The answer isn’t “made up from memory,” but “supported by sources plus interpretation.”
2. Investment research / industry scanning
Scenario:
You want a fast grasp of a new sector, or track its evolution over time.
Combo:
- External: RAG / GraphRAG across news, analyst reports, official sources, earnings calls
- Internal: RAG across your prior memos, models, and meeting notes
- LLM: synthesizes into:
- Industry structure
- Key players
- Critical risks
- Scenario analysis
This is sturdier than using search alone or asking an LLM alone.
3. Compliance, contracts, and policy interpretation
Scenario:
Legal or compliance teams ask, “What concrete impacts does the new regulation have on us?”
Flow:
- RAG finds relevant clauses, local interpretations, trade association commentary, internal compliance docs
- LLM:
- Compares old vs. new requirements
- Lists “internal processes that must change”
- Summarizes for leadership
Key point:
The text of the rules still comes from original documents; the LLM handles interpretation and organization.
7) The most common pitfalls when designing these systems
Teams often hit similar issues when introducing RAG + LLM.
1. Expecting “the LLM will just find it on its own”
Problems:
- You never know whether it “actually saw” the right document
- You can’t control whether it used the latest version
- Errors are hard to trace to the offending source
Healthier design:
- Retrieval (RAG) is explicit and inspectable;
- Generation (LLM) is grounded and traceable.
2. Throwing raw documents into a vector DB without structuring
Plain text works, but some data should be structured:
- Timelines
- Graphs (entities/relationships)
- Tables (headers + fields)
GraphRAG shines here:
organize the “graph” first, then have the LLM interpret the graph—rather than drowning in raw text.
3. Failing to separate “who owns facts” vs. “who owns interpretation”
A simple, crucial rule:
- “Facts” must be traceable (a passage, a document, a table row)
- “Conclusions and recommendations” can be generated by the LLM via its world model
Then when something’s wrong, you can locate which fact needs updating—
instead of the whole system looking like it’s “making things up.”
Conclusion: Truly powerful AI systems look like “teams,” not “single models”
In one line:
The LLM is a well-read, reasoning, articulate consultant;
RAG, GraphRAG, and vector DBs are its records room and research assistants.
- Implicit knowledge (model weights): delivers understanding, reasoning, style, and consistency
- Explicit memory (external retrieval): delivers freshness, precision, and traceability
Together, you get an AI partner that:
- Reads documents
- Finds sources
- Explains meaning
- Communicates clearly
- And offers a clear audit trail when mistakes happen
And that’s just “how to use the model.”
Next, we’ll pivot to “how the model grows”:
- Pretraining as the “accumulation phase”: load up on world regularities, build the base
- Fine-tuning as “consolidation”: adjust style and direction, remove unnecessary noise
- RLHF as “lift-off”: express capabilities aligned with human preferences
We’ll devote a full chapter to telling “Pretrain / Fine-tune / RLHF” as a market-operator’s story.
========
This work is created by Dalishi’s AI World and released under the Creative Commons Attribution–NonCommercial–NoDerivatives 4.0 International license.
留言
張貼留言