Some answers live in the connections, not the text.

The fourth retrieval signal. Entities as nodes, typed relationships as edges, and the questions only a graph can answer.

Spaced recall: gbrain's retrieval was "vector + BM25 + RRF + graph signals." You now own the first three. This lesson is the fourth, and it is the one your Graphiti setup is built on.

The one idea: Flat retrieval (L2-L4) finds passages that look like the query. A knowledge graph finds facts connected to the query, even when no single passage states them. Different shape of question, different machine.

The question flat RAG cannot answer

"Which of my investors also advise a company that competes with a portfolio founder I met last month?" No document says that. The answer is a path through relationships: investor → advises → company → competes_with → company → founded_by → person → met_on → date. Flat vector search retrieves passages; it has no notion of a path. A graph walks it.

The two pieces: nodes and typed edges

A knowledge graph has just two ingredients:

Nodesentities: people, companies, places, events

Edgestyped relationships between them

The word typed is the whole game. An edge is not just "these two are related," it is works_at, invested_in, attended, competes_with. Typed edges let you ask precise structural questions ("who works at X", "what did Y invest in") that a bag of passages cannot represent.

Where the edges come from

Two strategies, and they define the big design split:

	LLM extraction	Rule / pattern wiring
How	An LLM reads text and emits entities + edges	Detect known entity names, link on write
Cost	An LLM call per ingest, slow, $$	Zero LLM calls, instant
Coverage	Catches novel/implicit relationships	Only what your patterns know
Used by	Graphiti (extraction on write)	gbrain (auto-wires typed edges, 0 LLM calls)

Connect it back: this is the sharpest gbrain-vs-Graphiti difference you've seen yet. gbrain bets that cheap deterministic linking over a huge page count beats expensive extraction. Graphiti bets that LLM extraction captures richer, messier relationships worth the cost. Neither is "correct." It is a cost-vs-richness bet, and which wins depends on your data and budget. Hold that thought, it is the heart of Lesson 7.

Graph "signals" in hybrid retrieval

You rarely use the graph alone. In a hybrid system the graph adds signals to retrieval: boost a chunk because its entity is one hop from the query's entity; pull in a neighbor node the vector search never would have surfaced. The graph does not replace L2-L4, it enriches the candidate set before reranking.

Retrieval practice

Which question is a knowledge graph built to answer?

What makes a graph edge useful for precise questions?

How does gbrain build edges differently from Graphiti?

Read this next (primary source)

★ Graphiti: Knowledge Graph Memory for a Post-RAG Agentic World (Neo4j). Frames why graphs beat flat RAG for agents, using the system you already run. ~12 min.

Ask your teacher. Try: "show me what node and edge types my Graphiti graph actually has", "what entities would a DuckyCutz graph have?", or "if gbrain wires edges with no LLM, how does it know two names are the same entity?" (entity resolution, a real gotcha).

← Lesson 4: Chunking and embeddings Next → Lesson 6: Temporal memory (facts that change)