Topic
13 articles on RAG, written from production systems rather than documentation.
Benchmark rankings measure averages over corpora that are not yours. Four practical constraints narrow the field faster than any leaderboard position.
Chunk size is treated as a tuning parameter and behaves like an architectural decision. It sets the best answer your system can possibly retrieve.
A surprising share of what matters in an AI feature is mechanically checkable. Those checks are fast, free and boring, which is why teams skip past them.
Below a few hundred thousand vectors, a dedicated database mostly adds a system to operate. The threshold is higher than the tooling implies.
Teams reach for fine-tuning to make a model know their data. It is much better at teaching behaviour, and facts have a cheaper home.
Vector search handles paraphrase well and exact terms badly. Keyword search is the reverse, and users send both kinds of query in the same session.
Most RAG systems are built against a snapshot and then quietly decay. Indexing is a pipeline with a freshness target, not a one-off import script.
Conversation history, retrieved knowledge and learned state all get called memory. They have different lifetimes, and conflating them is why agents drift.
Real queries are never purely semantic. They are scoped to a tenant, a status and a date, and where that filter runs changes the results you get.
Storing embeddings beside the rows they describe removes a sync problem and makes filtering a join. That is worth more than raw index throughput.
Retrieval optimises for recall and the model needs precision. A reranker sits between them and fixes the mismatch without touching the index.
Embeddings capture how text is used, not what it means. That distinction explains most of the retrieval failures that look inexplicable from the outside.
Whether it needs designing from scratch or rescuing from its own success, tell me what you’re building and I’ll tell you how I’d architect it.
Open to remote and hybrid work worldwide