Back to Blog

Personal RAG: how to build retrieval-augmented generation against your own notes

*May 13, 2026 · 12 min read*

Retrieval-augmented generation — RAG — is the technique that turns a generic language model into one that answers from your data. It's the foundation under every "chat with your docs" product, every enterprise copilot, every AI knowledge base that doesn't hallucinate citations. And as of 2026, the tooling is good enough that you can build a real personal RAG against your own notes in an afternoon — or skip the building and use a product that ships the whole stack for you.

This piece walks through what personal RAG actually is, what the parts cost, what's hard to get right, and where to draw the build-vs-buy line for an individual rather than an engineering team.

TL;DR

Personal RAG = your notes + a search/embeddings index + an AI client that knows how to call the index during a conversation. The simplest working stack today is a markdown vault, embedded into a vector store, exposed over MCP, called by Claude or ChatGPT. You can roll this yourself with LangChain or LlamaIndex, but the maintenance burden is real — you're now operating an embedding pipeline, a vector DB, and an MCP server alongside whatever you actually wanted to do. MindWiki ships the full stack as a managed product for individuals so you can skip the infra and start querying your own notes.

What RAG is doing under the hood

Without RAG, a model answers from its training data. It has no idea what you know, what you've decided, or what's in the document you finished writing yesterday. With RAG, the conversation goes:

  • You ask a question.
  • The system retrieves the top-K relevant passages from your data using keyword search, vector similarity, or both.
  • Those passages get injected into the model's context as "here's what's relevant."
  • The model answers grounded in those passages and cites them.

That's it. The trick is in steps 2 and 3 — choosing what to retrieve, chunking documents intelligently, ranking results, and packing the context window without blowing the budget. Most "build your own RAG" tutorials skip past those problems. They're the ones that actually matter at scale.

The parts of a real personal RAG

Six pieces. Each one has a build option and a buy option.

1. Document store

Where your raw notes live. The minimum bar:

  • Open format (markdown beats proprietary blocks).
  • Per-document properties (frontmatter, tags, areas).
  • Append-only writes that sync across devices.

Roll your own: a folder full of .md files synced via Dropbox or git.

Managed: MindWiki's vault on macOS + web, automatic sync, conflict files instead of silent overwrites.

2. Chunker

Long documents need to be split into passages so embeddings work. Naive chunking (every N characters) breaks semantic boundaries. Smart chunking respects headings, lists, and paragraph structure.

Roll your own: LangChain RecursiveCharacterTextSplitter with a markdown-aware preset.

Managed: MindWiki does heading-aware chunking automatically during indexing.

3. Embeddings model

Turns text into vectors so similar passages cluster.

Roll your own: OpenAI text-embedding-3-small or local models like BGE or E5 via Ollama.

Managed: MindWiki AI handles embeddings transparently; you don't pick a model.

4. Vector index

Stores embeddings, runs nearest-neighbor search.

Roll your own: Pinecone, Weaviate, pgvector, or local Chroma/Qdrant.

Managed: MindWiki ships a managed vector index — you don't run or pick one.

5. Retriever

Combines vector search with keyword search and re-ranks. Pure vector search loses to hybrid search on most personal-data benchmarks because typed queries ("what did I write about X on Tuesday") have keyword hits that vector similarity dilutes.

Roll your own: BM25 (via rank_bm25) + vector score, re-ranked by a cross-encoder.

Managed: MindWiki's mindwiki_search is hybrid out of the box.

6. AI client

What you actually talk to. Needs to call the retriever as a tool, not just stuff retrieved text into a system prompt.

Roll your own: a LangChain agent or a custom tool-calling loop against the OpenAI/Anthropic APIs.

Managed: Claude.ai, Claude Desktop, ChatGPT, Codex, Claude Code, and any other MCP-aware client. All of them call MindWiki's MCP tools transparently.

What's hard to get right

People who've built personal RAG systems run into the same problems, in the same order:

Chunking sucks at scale

Markdown documents with deep heading hierarchies, code blocks, and lists need structure-aware splitting. Most off-the-shelf splitters either over-chunk (every paragraph is its own vector, retrieval surfaces unrelated micro-passages) or under-chunk (whole long pages go in as one vector, retrieval is too coarse). The right answer is hierarchical: chunk by H2/H3 sections, embed each section separately, and store the parent document reference so the retriever can return the section + a pointer to the whole document.

Pure vector search loses

If you ask "what did I write about agent-native memory on Tuesday", a pure vector store finds passages semantically similar to "agent-native memory" but ignores the temporal filter. Real personal RAG needs:

  • Vector similarity for fuzzy queries.
  • Keyword search for exact phrases and titles.
  • Property filters for created > date, area = X, tags includes Y.

This is why MindWiki ships mindwiki_search (hybrid keyword + vector), mindwiki_similar (pure vector), and mindwiki_list_pages (property-filtered) as separate tools — the AI picks the right one based on the question.

Embeddings drift

Models change. New embedding models score the same query differently than old ones. If you embed your vault with text-embedding-3-small today and want to switch to a better model in six months, you re-embed everything. This is a chore in a managed system and a real outage in a self-rolled one.

Indexing latency

Every time you write a page, the index needs to reflect it. If indexing happens on a cron job every hour, your AI is querying stale data. If indexing happens synchronously on every write, your save latency goes through the roof. The right answer is event-driven background indexing with read-your-writes consistency for the page you just edited. Most personal-RAG tutorials skip this entirely.

Permissions are a real problem

The moment you connect AI clients to your data, you need scoped credentials. A Claude session that can read your vault shouldn't be able to delete pages. A read-only Zapier integration shouldn't be able to mint API keys. OAuth + scoped API keys solve this — but you have to actually implement them. Personal-RAG demos never do.

Build-vs-buy heuristic

Roll your own personal RAG if:

  • You're building a learning project and the stack itself is the point.
  • You have very specific retrieval requirements (medical records, legal corpus) that need custom logic.
  • You're comfortable operating Pinecone or pgvector at small scale.

Use a managed product if:

  • You want to spend your time writing notes and asking questions, not running infra.
  • You want every major AI client (Claude, ChatGPT, Codex, Claude Code, Claude Desktop) to connect with one URL.
  • You want hybrid search, structure-aware chunking, and event-driven indexing without picking embeddings models.
  • You want a free tier that covers personal use and a paid tier that adds AI/automation features.

For most individuals, the math says buy. The infrastructure cost of a self-hosted personal RAG isn't the OpenAI/embedding-API bill — it's the hours of maintenance and re-tuning that nobody mentions in the demo videos.

The MindWiki version of this stack

MindWiki ships all six parts as one product designed specifically for individuals:

  • Document store — markdown vault on macOS and web, full sync.
  • Chunker — heading-aware, runs automatically on every write.
  • Embeddings — MindWiki-managed, generated automatically on every write.
  • Vector index — MindWiki-managed; you never pick or run one.
  • Retriever — mindwiki_search (hybrid), mindwiki_similar (vector), mindwiki_ask (RAG + synthesis in one call), mindwiki_list_pages (property-filtered), mindwiki_graph (link traversal).
  • AI clients — Claude.ai, Claude Desktop, Claude Code, ChatGPT, Codex, and any other MCP-aware tool. One URL, OAuth flow, done.

The free tier covers the editor, vault, search, and graph. Pro adds MCP and the scheduled vault automations (Auto-Linker, Weekly Classifier, Pattern Detection, Monthly Summary) that keep the vault organized between AI conversations.

Worked example: querying your own writing

Assume the vault contains six months of personal notes, organized loosely. A few prompts that work after the MCP connection is live:

> "Search my MindWiki for everything I've written about onboarding flows and summarize the patterns."

The AI calls mindwiki_search("onboarding flows"), gets back the top hits, calls mindwiki_read_page on the ones that look most relevant, and synthesizes. Citations point back to the actual pages, which you can click to open.

> "Find pages similar to my last meeting note."

The AI calls mindwiki_similar on the most recently updated page. Returns semantic neighbors, regardless of whether they shared keywords.

> "What decisions have we made about pricing in the last quarter?"

The AI calls mindwiki_list_pages with area = decisions and created > 2026-02-13, then reads each result. The temporal filter works because properties are first-class.

None of these prompts work with provider-side "memory" features. All of them work with a real personal RAG behind the AI.

Related reading