Series · 5 posts
A curated reading path (not a serialized course): rethinking RAG, vector vs reasoning retrieval, and the context-rot / compression problem.
The LLM Wiki isn't a query tool—it's an architecture that lets knowledge compound over time. The LLM actively builds and maintains a markdown knowledge base, instead of re-fetching from raw documents on every single query.
Over the past two years RAG evolved from a 'linear pipeline' to 'loop-based reasoning'. It maps cleanly to five stages: Naive, Advanced, Modular, Graph, Agentic. The real inflection point is control moving from pipeline to agent — a System 1 → System 2 shift. Looking back at engineer-news's own RAG stack, it's stuck at the Naive edge — so this post also lays out what to fix next.
The previous post zoomed out for a five-stage panorama of RAG. This one zooms in on the five infra lessons any real RAG has to face: document ingestion, contextualized chunking, three-lane hybrid search, tensor reranker, and GraphRAG's semantic gap. Each lesson is checked against engineer-news's current stack, ending with a priority list for a personal site.
PageIndex swaps the vector DB for a hierarchical tree index plus an LLM Agent that reasons over it, and it shines on long structured documents (98.7% on FinanceBench). This site's Hybrid RAG instead runs vector search with a keyword fallback on the Cloudflare edge — a completely different set of tradeoffs.
Headroom compresses tool outputs, logs, and RAG chunks by 60–95% locally, before the request reaches your provider. The part worth stealing isn't the ratio — it's how it decides whether to compress at all using 'mask extraction + cache-mutation economics' — plus a reminder that its docs run ahead of its code.