RAG

RAG (Retrieval-Augmented Generation) feeds relevant retrieved knowledge
into an LLM’s context at answer time, grounding it in documents outside its
training data. A RAG pipeline has three moving parts: chunking (splitting
documents into embeddable pieces), embeddings (mapping chunks to vectors
so meaning, not keywords, is compared), and retrieval (vector similarity
search, often + keyword/hybrid + re-ranking) feeding the generation step.

Local RAG for a markdown second brain

Retrieval over an Obsidian-style vault is a special case where the corpus is
already clean, linked, and frontmatter-structured — chunking can be
markdown-aware (split on headings, keep code blocks intact) and the wikilink
graph itself is retrieval signal, not just content.

Two reference points:

• QMD — the path this garden took: one local binary bundling BM25 +
  embeddings + re-ranking (RAG-class retrieval with zero infrastructure).
  See qmd (OSS).
• Local LM roadmap (homelab) — the DIY path: own embedding model
  (PolDense-68M lean, BGE-M3 fallback), vector DB choice (Qdrant/LanceDB/
  pgvector), chunking strategy — the decisions QMD pre-made.

Related resources

• Building an Obsidian RAG with DuckDB and MotherDuck
  (Simon Späti, ssp.sh) — local-first knowledge assistant over an Obsidian
  vault: DuckDB VSS extension (HNSW index) as the vector store, BGE-M3
  embeddings (1024-dim — the same model our Local LM roadmap comparison
  already settled on as multilingual fallback; his pick matches Qdrant’s
  recommendation, independently confirming that row of the table),
  markdown-aware
  chunking (~512 chars, heading boundaries, code blocks intact, title +
  section prepended as semantic anchor), wikilink graph + two-hop neighbors,
  then a serverless web app (MotherDuck WASM in-browser, no DB server).
  Retrieval-only by design — no LLM in the loop yet. Full text ingested to
  _research/references/ssp-obsidian-rag-duckdb.md.

Cross-refs: QMD, Local LM roadmap, Digital gardens,
How this garden works.