The Patron Who Doesn't Need to Memorize the Library
why a good librarian, not a photographic memory, is what actually lets someone answer questions accurately from an enormous, ever-changing collection.
Giving an LLM a library card instead of asking it to memorize everything.
why a good librarian, not a photographic memory, is what actually lets someone answer questions accurately from an enormous, ever-changing collection.
the two genuinely distinct steps behind every RAG system: finding the right material, and then actually writing an answer from it.
what relying purely on a model's memorized training looks like, and exactly where that approach genuinely falls short.
why documents have to be broken into smaller, well-sized pieces before retrieval can work well at all, and how getting that sizing wrong quietly breaks everything downstream.
how embeddings let a system find content based on what it actually means, not just which exact words happen to appear in it.
how a vector database stores millions of embeddings and finds the closest matches to a query fast enough to be actually useful.
the actual indexing techniques behind approximate nearest neighbor search, and why the specific algorithm choice involves a genuine, tunable tradeoff.
how many retrieved chunks actually belong in a model's context window, and why more retrieved content isn't automatically better.
why raw similarity scores alone don't always identify the genuinely most useful material, and what a librarian's actual judgment adds on top of a catalog search.
the specific, well-documented ways retrieval can fail, and why diagnosing exactly which failure occurred matters enormously for fixing it.
how a reranking model applies a slower, more careful pass over an initial retrieval to catch mistakes the first, faster search missed.
how to make a model actually ground its answer in retrieved content, and cite it verifiably, rather than quietly drifting back to unverified pretrained knowledge.
how a RAG system keeps its knowledge source current through incremental updates, rather than a slow, disruptive full rebuild every time something changes.
how RAG systems handle retrieval across tables, images, and structured data, not just plain, uniform prose.
why some questions need one quick lookup and others need a genuine, multi-step research process — and why RAG systems need both modes.
how a RAG system should handle retrieved sources that genuinely disagree, rather than confidently picking one and ignoring the conflict.
why a good RAG system needs to gracefully admit when its knowledge source genuinely doesn't contain an answer, rather than fabricating one anyway.
how to evaluate a RAG system rigorously across both retrieval quality and generation quality, rather than relying on a vague sense that it 'seems fine.'
what it actually takes to run a RAG system reliably in production, across many users, many documents, and real, ongoing operational demands.
reassembling the whole system, from a patron who no longer needs to memorize anything to a fully operational, evaluated, production-grade library service.