Notes on implementation choices, architecture tradeoffs, and lessons learned while building AI systems.
Everything before this was proven and in production. This is the edge — two bets on what comes after naive retrieval. Recursive language models that compute over the corpus in code instead of retrieving from it, and Google's Open Knowledge Format standardizing the curated substrate. Their potential, their limits, and an honest snapshot as of mid-2026. Part eight of eight.
A mid-size industrial company, one messy corpus, forty real questions. The whole method from this series run once, in order: golden set, histogram, substrate work, typed tools, hybrid search — and an evaluation that can actually fail. Part seven of eight.
A decision framework that starts from the shape of your questions rather than the size of your corpus, the cases where the right answer is to retrieve nothing at all, and the production half nobody writes about: citations you can't fake, permissions inside retrieval, freshness, injection, and measuring retrieval separately from generation. Part six of eight.
The routing dimension, realized: instead of retrieving once before generating, the model decides when to retrieve, which tool to use, and whether what came back was good enough. The core loop, the named patterns — decomposition, active retrieval, self-correction, routing — and the costs nobody mentions. Part five of eight.
The index is not your documents — it's what you chose to put in it, in the shape you chose. Parsing, tables, images through a vision model, chunking as a design decision, metadata as retrieval infrastructure. The upstream half of RAG that decides most of the quality and gets the least attention. Part four of eight.
Three retrieval families that abandon similarity altogether — structured queries that return exact answers, graphs that traverse relationships, and summary trees that manufacture answers the corpus never contained. The less popular half of the design space, and the one that fixes the failures the popular half can't. Part three of eight.
Inlining, lexical search, dense vectors, and hybrid with reranking — the four families most teams actually choose between. What each is genuinely good at, and the specific way each one fails. Part two of eight.
Most teams hear "answer questions from our knowledge base" and immediately start optimizing the knowledge base. That's the wrong end of the problem. RAG isn't the vector-database diagram everyone draws — it's five independent decisions, and the right settings depend on the shape of the question, not the size of the corpus. Part one of eight.