RAG → GraphRAG migrations, hybrid retrieval, security, and the patterns that ship when the vector DB stops being enough.
Plain vector RAG hits a ceiling around 100K documents. This is where graph-augmented retrieval becomes the right tool — and how to know if you need it.
Ordered by chapter. Each post stands alone but builds on the one before it.
Why filtering after RRF fusion loses the right chunks, and how a "drop trait → mode → grade" progressive relaxation ladder keeps narrow queries answerable without dropping retrieval quality.
A single retrieval surface over Slack, Confluence, Loom, and meeting transcripts — with cross-source ranking and source attribution that survives ingestion.
A startup-loaded domain vocabulary the generator must match against, plus framework rules baked into every prompt — a low-cost pattern that catches hallucinated terminology before the user sees it.
A team comes to us with a GraphRAG system that gives wrong answers, and they have spent three weeks on retrieval. It will not help. The retrieval is fine. The graph it is retrieving over was built by a loose extraction prompt that produced three copies of every company and edges nobody typed. In GraphRAG, answer quality is decided at construction, not retrieval, because a graph is a stateful artifact where one wrong edge corrupts every query that traverses it, and multi-hop traversal compounds the error. Design the schema before you extract, run extraction as a staged pipeline rather than one prompt, resolve entities at write time so one entity is one node, make provenance first-class so every claim traces to a source span, and validate at insertion so bad data never lands. Test it with a real three-hop query: build the graph right and multi-hop just works, build it wrong and no retriever recovers it. You cannot retrieve your way out of a bad graph.