Rag

Pete Johnson — MongoDB’s field CTO of AI and a 30-year database veteran — makes the case across ~95 minutes on The Cognitive Revolution that the interesting frontier in AI has moved back into database territory. His thesis, stated once: agent performance, and especially cost-adjusted agent performance, depends on retrieval — what you choose to put in front of the model, in what order. The thesis Not the model, not the context window, not the prompt — retrieval is what decides whether an agent is good Everything else in the conversation (database history, the Voyage acquisition, vector search) is downstream of that one claim A history of constraints 1970: SQL is born (E.F. Codd, IBM) — storage was the scarce resource, so normalization (store nothing twice) was the right design 2007: MongoDB’s first commit, the year the iPhone ships — after 47 years of Moore’s Law, time became scarce, so denormalize: one JSON document, one disk read instead of three “The problem has faded, but the solution persists” — Johnson agrees, and flags the education system’s “thou shalt always normalize” bias MongoDB’s AI path — it started with keyword search 2020: customers stood up their own Lucene servers for keyword search → MongoDB shipped Atlas Search (lexical, managed) A vector is just an array of floats → to a document DB, that’s just another attribute, so vector search was cheap to add Three levers: pre-filter (metadata) + lexical + vector = hybrid search in one query (rank fusion / score fusion, one API call) 2025: the Voyage acquisition — and the conversation pivots from “database features” to “embeddings actually matter” Embeddings are not commoditized “Most people think embedding models are commoditized — that is not true” Hugging Face’s Rtech benchmark: up to a 14% quality gap vs. the default picks 14% is the difference between a hallucination and a correct answer A reranker on top adds another 5–10% ($re-rank, one-call) Anthropic — no embedding model of its own — recommends Voyage Three Voyage features that remove plumbing Contextualized chunking: send the chunk plus its surrounding context, get one vector back — better retrieval at smaller chunks, inverting the normal tradeoff Matryoshka reasoning: dimensions nest like Russian dolls — embed at 1024, lop off the last 512 to test, no re-embedding your corpus Shared embedding spaces: four sizes of one model share an embedding space; a free open-weight “nano” can run queries locally to kill token cost in dev The memory problem, compressed 2022: query → context window → answer. 2023: the knowledge cutoff + proprietary data → RAG. 2025: tools/MCP + looping → the memory problem Early answer: short-term memory = cram the session; long-term = cram the last three days Two failures: token maxing (Uber burned its entire 2026 budget in 13 weeks) and lost-in-the-middle (the first and last ~7K tokens are what matter; the middle muddies the answer) The fix is selection, not stuffing Stop asking “how do I cram a million tokens in” — ask “how do I choose the right 200K for this loop” Taxonomic memory: a hundred company-specific terms exist, but only five are relevant to this loop — pick those five, re-pick next loop Two responsibilities now: query with a token budget, and write the answer back so the system curates and stores it Write, change, recall, forget Memories have a half-life — recent matters more — and forgetting is the hardest part Nathan’s own memory system (monthly logs → yearly summaries → entity wiki) hits both pain points: the DRY violation and the model keeping a dead project open for months Guidance: a good embedder + reranker makes the forget step workable; graph structure for the top 2–6 levels, vector search in the leaf; don’t run multiple LLM passes to shrink the corpus — that’s just more tokens Memory done well: ElevenLabs’ micro-agents, one per customer Build vs. buy, three camps Camp one: “I bought one tool, I’m done.” Camp two: POC purgatory — usually the wrong problem. Camp three: optimizing sophisticated memory Problem selection: top 10–15 problems, which have good data, which already have metrics — else you can’t tell if AI helped “Bad data quality and bad security posture don’t get solved by AI — they get amplified” Lines of code is a terrible metric; idea-to-production is the one that matters The world outside the US Seven countries, ~100 customers this year — and the two most sophisticated were in Mexico City and São Paulo, both assuming US competitors were ahead Nearly every country has a hyperscaler data center now — the geographic barriers that kept US companies ahead have eroded “We’ve been building databases for 60 years. We’ve been building agents for about 18 months… there’s no LAMP stack for agents yet — no React and Angular, no established right answer an enterprise can confidently buy.” ...

Ofer Mendelevitch (Vectara; author of Hands-On RAG for Production and, with Jay Alammar, Hands-On Large Language Models) interviewed by Angelina on TwoSetAI — 70 minutes on production RAG and surviving the AI shift. RAG isn’t dead — it just got a loop RAG = retrieval + augmented generation, and retrieval stays essential even with agents; the “RAG is dead” claims every two months are mostly people marketing something new Classic RAG is one-shot: query → top chunks → prompt → answer. Agents add a loop: the LLM plans, calls tools (often the RAG pipeline itself) repeatedly, and synthesizes “Talk to my PDF” demos are not production: millions of documents in every format change the problem completely The pipeline, from ingest to answer Ingest: extract text → chunk → embed → vector store (store the text and page markers too, not just vectors — citations need to point at exact pages) Hybrid search (semantic + BM25/TF-IDF) for what semantic search misses: numbers, product codes, exact strings — “if the source says 90% and your output says 85%, vector search won’t catch it” Query side: top-5/10 results → optional reranking → prompt → grounded answer Tables, images, and the red button problem Tables are first-class citizens: chunked tables lose their column names (common in medical journals) — store whole tables, retrieve them whole Images: store and return as images, don’t flatten to a description Video: transcription alone loses meaning — “in order to avoid catastrophe, never press this button” means nothing without the visual. Today’s fix: VLM descriptions of short clips correlated with the transcript. Dedicated video embedding models exist but aren’t production-ready yet When to bother with knowledge graphs Multi-hop questions (“what else did the director of Inception direct?”) defeat semantic search But graphs are expensive to build and maintain — worth it only for high-stakes use cases where a significant share of queries actually need the relationships Eval: the hard part is the data, not the metric Retrieval eval (did you fetch the right chunks?) needs query→gold-chunk datasets that are brutal to build — and documents keep changing Generation eval compares against curated golden responses Reference-free eval (Jimmy Lin’s Waterloo lab + Vectara): LLM-as-judge scorers like UMBRELLA (0–3 chunk relevance) validated against human correlation — no gold labels required Build, buy, or rent Build with LangChain/LlamaIndex only if it’s your business and you have the team; complexity compounds (multimodal, graphs, maintenance) RAG/agent-as-a-service (e.g. Vectara) outsources the upkeep; vertical tools are fine when they cover your use case — but watch missing features and data-residency constraints DevRel as a growth engine Two jobs: teach developers how to use the product, and carry feedback back to the company PLG over expensive sales teams: self-serve product, events, hackathons, real blog posts — “make it your own voice, don’t produce AI slop” Measure directionally, don’t over-engineer attribution: five customers means it’s not working, ten thousand means it is, a thousand is unknowable — same problem founders face reading PMF The skill that survives Engineers and data scientists become directors, not actors: agents write the code; the remaining critical challenge is deciding what to build and steering where agents are weak (architecture, non-obvious trade-offs) To the high schoolers who feared they made “the most incredibly stupidest mistake” by majoring in CS: graduate with the capability of today’s mid/senior engineer — use college to learn how to wield the AI tools Fundamentals still matter; hiring will have to change — “write Fibonacci in five lines of Python is worthless” — expect AI-augmented interviews His real worry is societal, not technical: how governments and finance distribute the gains “We’re going to end up in engineering and data science being directors as opposed to actors. The coding agents will write the code.” ...

RAG — retrieval-augmented generation — is the technique that lets an AI answer questions about your own documents: it searches them first, then reads the best matches to compose an answer. Most teams build this the hard way, jumping straight to vector databases and reranking pipelines. Rafael Pierre’s essay argues that’s usually backwards: a plain keyword search handles a surprising share of real queries, and you should only climb the complexity ladder when you have data proving you need to. ...

Hamel Husain hosts Marek Galovic, CEO and co-founder of Top-K (ex-Pinecone data plane lead, ex-Shopify), on scaling multi-vector / late-interaction retrieval. ~24 minutes. Why single-vector embeddings fail agents Pooling is a lossy summary — it captures high-level semantics but drops the low-level detail precise queries need Agents issue many specific parallel queries; single-vector retrieval returns the same documents for all of them Agentic retrieval is sequential — noisy retrievals compound errors over multiple hops DeepMind’s limit paper: single vectors can’t capture arbitrary relevance matrices, even with infinite dimensions (embeddings are low-rank) Multi-vector = chop off the pooling layer Keep one embedding per token; score every query token against every document token (max-sim), then aggregate Preserves low-level detail; much better on out-of-domain and long-context retrieval Cost: 10-100x more storage, ~3 orders of magnitude more flops per score Existing workarounds (ColBERT-style compression into IVFPQ indexes) make updates and filtering hard in production Sparse multi-vector encoding (Top-K’s approach) Random projections map token embeddings into tens-of-thousands-dimensional space, then sparsify (keep top-k per token) Aggregating token-level sparse vectors into one document/query vector makes the dot product approximate max-sim Retrieval becomes inverted posting lists like BM25 — cost scales with non-zeros, not ambient dimension Two-stage: prune a billion docs to a few hundred candidates, then re-rank with exact max-sim (1-2 bit quantization, custom kernels, tens of thousands of docs/sec/core) Production numbers Sub-50ms P99 at billion scale; hundreds of QPS; 70MB/s writes with no query-latency impact Object storage as the durable layer + stateless compute; separate read/write pools Quality: a 100M-param multi-vector model outperformed an 8B dense model by ~40% on some video-doc retrieval; on BrowseComp an off-the-shelf 120B open model + multi-vector matched a proprietary GPT-5 setup; OfficeQA Pro went 18% @ $6/query → 42% @ $0.50/query Practical tuning advice Start with evals on your own private data, then hill-climb Dimensions are usually 128; you can prune tokens and quantize without hurting recall Relevance tuning (content score × user signals like distance/popularity) is underrated — e-commerce does it better than RAG teams “If you just vibe it, you can get better vibes from the system, but that’s not systematic. You need evals to know where you stand — and know if you’re improving or regressing.” ...