Ventures: Learning Plan

You're my AI tutor. I'm building an on-prem AI consulting business. I already understand LLMs, tokens, context windows, and inference (I run models locally on an M3 Ultra via Ollama). Now I need to deeply understand RAG — Retrieval Augmented Generation. I have relevant background: I built a markdown-based knowledge architecture for my own AI agents using CLAUDE.md files and structured memory. I understand context engineering intuitively — I just don't know the formal RAG vocabulary and tools yet. Teach me interactively (question after each concept): 1. **What RAG is** — in plain English, not the academic definition. Use my CLAUDE.md experience as the analogy: "You already do manual RAG — you curate what context the agent sees. Automated RAG does this with a database." 2. **The RAG pipeline** — document → chunks → embeddings → vector database → retrieval → generation. Walk through each step with a concrete example: "A law firm has 10,000 contracts. A paralegal asks 'What are the indemnification terms in the Smith contract?'" 3. **Why chunking matters** — too big = noisy retrieval, too small = lost context. Semantic chunking vs. fixed-size. Why 512-1024 tokens with 20% overlap is the sweet spot. 4. **What embeddings are** — the concept of turning text into numbers that capture meaning. Why "dog" and "puppy" have similar embeddings but "dog" and "contract" don't. Why embedding model quality matters. 5. **What a vector database does** — storing embeddings, similarity search, metadata filtering. Why Qdrant? Dense vs. sparse vs. hybrid search. 6. **Where RAG fails** — the failure modes I need to prevent for my clients: stale embeddings, bad chunking, no metadata, no source attribution, hallucinated context. 7. **RAG vs. fine-tuning vs. context window** — when to use each. Why RAG is usually the right answer for business documents. Quiz me at the end. 7 questions, one per topic.

I want to build a RAG pipeline on this M3 Ultra. I have Ollama running with Qwen3 models. Walk me through building a complete pipeline: 1. Install Qdrant via Docker (vector database) 2. Install Python dependencies: llamaindex, qdrant-client, sentence-transformers 3. Download the BGE-M3 embedding model (run locally, no API calls) 4. Create a Python script that: a. Reads PDF files from a directory b. Extracts text (handle tables and multi-column layouts) c. Chunks the text semantically (512-1024 tokens, 20% overlap) d. Embeds each chunk with BGE-M3 e. Stores embeddings + metadata (filename, page number, chunk index) in Qdrant 5. Create a query script that: a. Takes a user question b. Embeds the question c. Searches Qdrant for the top 5 most relevant chunks d. Passes those chunks + the question to the local Ollama model e. Returns the answer WITH source attribution (which document, which page) For test data, use some of the HOA PDFs or any documents I have locally. I want to see the full loop working end-to-end. After it works, show me how to evaluate retrieval quality — how do I know if the right chunks are being returned?

You're my AI tutor. I'm learning to deploy RAG-based AI systems for business clients. I already built a RAG pipeline (PDF ingestion → chunking → embeddings → Qdrant → retrieval → generation). Now I need to learn the art of context architecture — how to structure a client's knowledge so the AI actually returns good answers. Background: I run my personal life and a design agency using Claude Code with structured markdown files (CLAUDE.md, memory files, agent identity docs, lane-based organization). I know how to curate context — I just need to formalize it into a methodology I can sell. Teach me interactively: 1. **Document taxonomy** — how to categorize a law firm's documents: policies (authoritative), templates (reusable), case files (client-specific), correspondence (ephemeral). Why mixing these without metadata destroys retrieval quality. 2. **Precedence rules** — newer > older, policy > opinion, verified > draft. How to encode these as metadata in the vector DB so retrieval respects priority. 3. **Structured vs. unstructured ingestion** — when to chunk raw PDFs vs. when to manually create structured markdown summaries (like I do with CLAUDE.md). The answer: do both. Structured for critical documents, automated for bulk. 4. **Knowledge base maintenance** — the curation lifecycle. How to detect stale content, resolve conflicts, version documents. This is the retainer service. 5. **System prompt engineering** — how to write system prompts that tell the model "you are [firm name]'s AI assistant, you prioritize internal policies over general knowledge, you cite sources, you say 'I don't know' when retrieval returns low-confidence results." 6. **Testing and validation** — how to build a test suite for a RAG system: golden questions with known correct answers, retrieval accuracy metrics, hallucination detection. After the lesson, give me a hypothetical: "You're onboarding a 20-attorney firm that handles M&A. They have 50,000 documents. Design the knowledge architecture." Let me answer, then critique my design.

I have a working RAG pipeline (Qdrant + BGE-M3 + LlamaIndex) and Open WebUI running on my M3 Ultra. I need to connect them so the web UI automatically searches my document corpus when a user asks a question. Options: 1. Use Open WebUI's built-in RAG feature (simplest — upload docs through the UI) 2. Build a custom RAG API middleware that sits between Open WebUI and Ollama (more control) Walk me through both approaches. I want to understand the tradeoffs. For the demo, the built-in RAG is probably fine. For a production client deployment, I'd want the custom middleware. After setup, help me build a compelling demo scenario: - Create a collection of ~20 sample legal documents (contracts, memos, policies) - Upload them to the system - Write 5 demo questions that show the AI searching and citing specific documents - Show me how it handles "I don't know" when asked about something not in the corpus This is what I'd show a managing partner in a 10-minute demo.