Vector Search vs Graph RAG.
Two ways agents find information. Search by meaning catches similarity. Knowledge graphs catch relationships and time. Most production builds use both. This card is the companion explainer for the technical terms the rest of Stage 03 keeps referring to.
- Plain-English definitions of vector search, embeddings, RAG, and knowledge graphs, in the order they actually matter.
- A side-by-side of strengths and weaknesses so you can tell which tool the question in front of you actually needs.
- The use-both pattern production builds run search-by-meaning and a knowledge graph together. The card explains why one alone falls short.
How this fits in the OS.
A working mental model for the Cairns three tiers, especially the L2 Chain of Density Card Catalog Layer (Card Catalog Layer for short) and L3 raw evidence.
Plain-English definitions of search by meaning, embeddings, and knowledge graphs. No databases to install today.
The ability to read the rest of Stage 04 without bouncing off the technical names, and a real answer to "which one do I need."
Two ways an agent finds information.
When you ask your agent a question, something has to go look. There are two very different ways to do that look-up, and they catch different kinds of questions. The whole point of this card is to give you a working sense of which is which, so the next time someone says "vector store" or "Graph RAG" you know what they mean and when to reach for which.
Here are the plain-English versions first, technical name second.
Search by meaning
Technical name: vector search, sometimes called semantic search or RAG (retrieval-augmented generation).
It finds things that mean the same thing, even if they don't use the same words. Ask it "what did we say about pricing" and it returns a chunk that talks about "rates and packaging" because the meanings overlap.
How it works in one sentence
Every chunk of your text is converted into a list of numbers that represents its meaning (this list is called an embedding). Your question gets the same treatment. The search returns the chunks whose number-fingerprints look most like the question's fingerprint.
Good at
- "Where did we talk about X" across thousands of documents
- Catching paraphrases and synonyms ("rates" finds "pricing")
- Pulling the right paragraph out of a long transcript
Bad at
- Time. It has no idea which mention is the most recent.
- Relationships. It can't tell you which person said it or who it was about.
- Reconstructing a story that changed over time.
Knowledge graph
Technical name: graph database, and when paired with an agent for retrieval, Graph RAG.
It stores the world as things and the connections between them. Sarah is a person. Pinnacle is a company. Sarah works at Pinnacle. The Q3 proposal was for Pinnacle. Sarah replaced the previous Q3 proposal with a new one in October.
How it works in one sentence
People, projects, decisions, and topics are stored as nodes. The connections between them are stored as edges, and edges can carry dates and labels like "replaced" or "supersedes" or "reports to."
Good at
- Time. Which mention came first, what replaced what.
- Relationships. Who said it, about whom, in what context.
- Reconstructing a story arc instead of just matching words.
Bad at
- Fuzzy paraphrase. Asking it "anything about pricing" doesn't fan out the way meaning-search does.
- Cold-start corpus. Someone or something has to extract the entities first.
- Returning the actual prose of a source. You'll usually still want to read the raw evidence afterward.
RAG is short for retrieval-augmented generation. The mechanic is simple: before the agent answers your question, it goes and retrieves the relevant pieces from your knowledge, then writes its answer with those pieces in front of it. Plain vector search is one way to do the retrieving. Graph lookup is another. The "RAG" part isn't a database, it's the pattern of "go look first, then answer."
Why one alone falls short: the shoes example.
The fastest way to feel the difference is a question that drifts over time. Imagine a year of meetings with the same person, and their shoe preference keeps changing:
All three statements are in your transcripts. You ask the agent: "What kind of shoes does this person wear?"
Search by meaning will happily return any of the three. Each one has the same meaning-fingerprint as the question. There's no built-in sense of "which one is current." So you'll get a plausible answer, sometimes the right one, sometimes Nike, sometimes Adidas. The retrieval is correct. The answer is wrong.
A knowledge graph stores the arc. Nike, superseded by, Adidas. Adidas, superseded by, barefoot. The agent can walk the chain and see what's current. Combined with the original meeting transcripts in the back (so it can quote you exactly), it can return the right answer and tell you the full history.
That's the punchline of this card. Search by meaning is great at "where did we talk about this." A knowledge graph is great at "what's true about this now, and how did it change." Production systems use both because real questions are usually both.
When to reach for which.
A working rule of thumb you can keep in your head:
| If the question is... | Reach for... | Why |
|---|---|---|
| "Find me anything about X across my corpus" | Search by meaning | Paraphrase-tolerant. Fans out across thousands of chunks fast. |
| "What's the current status of X, and how did it change?" | Knowledge graph | Time and supersedence are first-class. The graph holds the arc. |
| "What did this person say about that topic in our last few meetings?" | Both | Graph filters to the person and the recent edges. Meaning-search pulls the right paragraphs from those meetings. |
| "Pull the relevant passage from the actual transcript" | Raw evidence (L3) | Neither index is the source. They tell the agent where to go look in the raw record. |
| "Is this a long-term pattern or a one-off?" | Knowledge graph | You're asking about a shape over time, which is exactly what edges capture. |
Most production builds end up running both, because real questions sit on both axes. The system the workshop fleet runs at scale uses Postgres with the pgvector extension for the meaning-search side, and a Neo4j graph database for the relationships and time side. You don't install either of those today. You just need to know they're two different jobs, and that one isn't a strict upgrade of the other.
You don't have to take this on faith. The YouTube Cairns blueprint in your workshop repo ships working implementations of both lookup paths. Open blueprints/youtube-cairns/pipeline/ingest-rag.py for the meaning-search pipeline (Supabase pgvector, OpenAI embeddings, 182 lines). Open blueprints/youtube-cairns/pipeline/ingest-graph.py for the graph pipeline (Neo4j Cypher, 90 lines). Both run against the same YouTube transcript corpus. Read them side by side and the difference between the two approaches becomes concrete in a way prose can't deliver.
How they actually stack together.
In a full Cairns build, search by meaning and the knowledge graph live side by side at the L3 layer, both pointing into the same raw evidence:
- L1 waypoints tell the agent where to start.
- L2 Chain of Density Card Catalog Layer cards tell the agent what exists and what each source is about.
- L3 raw evidence is the source of truth. The transcripts. The exports. The originals.
- Search by meaning sits on top of L3 as one way in: "find me chunks that mean this."
- The knowledge graph sits on top of L3 as another way in: "follow the relationships and time."
For a question that touches both, the agent uses them in turn. It runs a meaning-search to surface candidate chunks. It walks the graph to filter by who, when, and what's current. It then pulls the specific source passages from L3 to verify before answering. Three lookups, three different jobs, one coherent answer.
"I thought I had to reach for fancy retrieval setups, but the LLM has been pretty good about auto-maintaining index files and brief summaries of all the documents and it reads all the important related data fairly easily at this ~small scale." Karpathy's point: at small corpus sizes (roughly 100 articles, 400,000 words), a tidy markdown wiki and good index files often work fine. You don't need search-by-meaning or a knowledge graph on day one. You reach for them when paraphrase misses or temporal drift start producing wrong answers, not before.
That's the real heuristic. Start with files and good cards. Add search by meaning when paraphrase misses start hurting. Add the knowledge graph when time and relationships start producing wrong answers. Use both together when the questions you actually ask need both.
Where to go next.
You now have the working language. The natural next moves: