← back to writing

Jul 10, 2026 · 2 min read

Grounding a chat widget in a CV instead of a vector DB

LLMSystem Design

Most "chat with my resume" widgets reach for a vector database on day one. For a single CV's worth of content, that's usually the wrong first move.

The actual constraint

Retrieval exists to solve one problem: your context window can't hold everything, so you retrieve the slice that's relevant to the current question. A CV, a summary, five roles, and six projects fit comfortably in a few thousand tokens. There's no retrieval problem to solve yet.

So the console on this page does the boring thing: it renders profile.ts into a structured system prompt on every request and asks the model to answer strictly from that. No embeddings, no index to keep in sync, no retrieval step that can silently return the wrong chunk.

Where the line is

That changes the moment the corpus outgrows a single system prompt: a blog with fifty posts, transcripts, a wiki. At that point retrieval stops being premature and starts being the only way to keep both latency and accuracy in check, and Pinecone (which shows up elsewhere in this stack) earns its place.

The rule of thumb

Reach for RAG when you can't fit the source of truth in a prompt, not because "AI chat feature" implies vector search by default. Grounding data in code that's already the single source of truth for the rendered page has a nice side effect too: the site and the chat can't drift out of sync, because they read the same file.