What We're Going to Cover

In the required Day 3 exercises, you grounded FitPath's workout-plan prompt in NotebookLM and checked whether the grounding held up. That worked — but NotebookLM made every architectural decision for you. It chose how to chunk your documents, which embedding model to use, how many chunks to retrieve. You never saw any of it.

This is where you build the thing yourself. Same FitPath documents, same question — but this time you assemble the pipeline node by node: document loader, text splitter, embedding model, vector store, retriever, LLM. Every knob from Slides 10, 14, and 16–17 becomes something you actually set, not something a product decided for you.

By the end you will have:

• Built a working RAG pipeline from scratch and watched it answer a question using your own retrieved chunks
• Changed chunk size and retrieval count and watched the actual retrieved chunks change — not just the final answer
• Compared what a transparent pipeline exposes that a black-box tool like NotebookLM doesn't

Overview

• Time: ~75–90 minutes total, across three exercises
• Difficulty: Moderate-to-high — first-time tool setup takes longer than the exercise itself
• Format: Individual, after hours
• Setup: Your own Flowise Cloud account (free tier) + your own OpenAI API key. See below.

Relevant Day 3 Material

How Vector Search Works (Slide 10), Data Ingestion (Slide 14), Chunking / Chunking Tradeoffs (Slides 16–17), Basic RAG Flow (Slide 20), Retrieval Quality Is Crucial (Slide 23).

Setup — Read Before You Start

This setup takes 15–20 minutes the first time. Budget for it separately from the exercise time above.

1. Create your own Flowise Cloud account at flowise.ai — sign up individually, don't share an account with a classmate. The free tier gives you 100 predictions/month and 2 flows, which is enough for this exercise, but only if it's yours alone.
2. Get an OpenAI API key at platform.openai.com/api-keys. You'll need to add a payment method, but the entire exercise — embeddings plus a handful of chat completions — will cost a few cents, not dollars.
3. Reuse the three FitPath source documents from the required exercises:
   • FitPath_Source_1_Exercise_Library_and_Programming_Guide.md
   • FitPath_Source_2_Safety_and_Injury_Guidelines_CURRENT.md
   • FitPath_Source_3_Safety_and_Injury_Guidelines_OUTDATED.md (not needed until you're done — set it aside)
4. Use the same user profile from the required exercises: 29-year-old, first week on FitPath, gym access, mild recurring knee pain, no medical clearance on file.

What You're Building

A minimal but real RAG pipeline: Document Loader → Text Splitter → Embeddings → Vector Store → Retriever → LLM. You don't need a dedicated vector database for this — Flowise's in-memory vector store is enough for a document set this size and avoids a third signup.

How to Run It

1. In Flowise, start a new blank chatflow (not a template — you're assembling this yourself so you know what each piece does).
2. Add a Document Loader node (Text File or PDF File type). Upload Source 1 and Source 2.
3. Add a Text Splitter node (Recursive Character Text Splitter is the standard choice). Set chunk size to 500 characters and chunk overlap to 50. Connect it after the loader.
4. Add an Embeddings node (OpenAI Embeddings). Paste in your API key. Connect it to the vector store.
5. Add an In-Memory Vector Store node. Connect the splitter's output and the embeddings node into it.
6. Add a Retriever node off the vector store. Set it to retrieve the top 4 most similar chunks.
7. Add a Conversational Retrieval QA Chain (or equivalent RAG chain node in your Flowise version) that ties the retriever to a Chat Model node (OpenAI, same API key).
8. Save the flow. Open the chat panel and ask the same question you asked NotebookLM in the required exercises: generate a workout plan for today's user profile.

Paste your full pipeline's answer here:

Flowise (unlike NotebookLM) can show you the raw retrieved chunks, not just the final answer — look for a "view sources" or similar option on the response. List the actual chunks that were retrieved, not just which document they came from:

Compare this answer to your NotebookLM grounded answer from the required exercises. Same conclusions, or different? If different, is that a chunking difference, a retrieval-count difference, or something else?

Look at the retrieved chunks you listed. Did the retriever pull in the right section of Source 2 for the knee-pain rule (Section 2), or did it also — or instead — retrieve something less relevant, like the pregnancy section?

What You're Testing

Slide 16 gave you the small-chunk-vs-large-chunk tradeoff as a table. Now you get to run both settings against the same question and see which one actually happens.

How to Run It

1. Duplicate your flow (or just edit the Text Splitter node — Flowise will let you re-run after any node change).
2. Set chunk size to 150 characters, overlap 20. Re-run the same workout-plan question. Record the retrieved chunks and the answer.
3. Reset and set chunk size to 1500 characters, overlap 100. Re-run the same question. Record the retrieved chunks and the answer.

At the small chunk size, did retrieval fragment a rule across multiple chunks in a way that lost meaning — for example, splitting the knee-pain rule from its exception or its reasoning?

At the large chunk size, did the retriever pull in a chunk so broad it included irrelevant rules alongside the relevant one (e.g., knee guidance bundled with unrelated shoulder guidance)?

Based on what you saw, what chunk size would you actually recommend for Source 2 in production — and why? Tie your answer to the specific failure mode you observed, not the general tradeoff from the slide.

What You're Testing

Slide 23 says retrieval quality is the biggest determinant of RAG quality — and that RAG evaluation must test retrieval, not just final answers. You now have a tool that shows you retrieval directly. Use it.

How to Run It

Reset your Text Splitter back to your Exercise 1 settings (500/50). Run each of these three tests, and for each one, check the actual retrieved chunks, not just whether the final answer sounded reasonable.

Test A — Right question, wrong top-k. Set your retriever's top-k down to 1. Ask: "What's the session length rule for a beginner, and what should I know about this user's knee?" — a question that needs information from two different places in Source 2. Does one chunk retrieval starve the answer of half of what it needs?

Test B — The boundary question. Ask something outside both documents entirely: "Should this user also change their diet to support the training plan?" Does your pipeline correctly have nothing relevant to retrieve — and if so, does the LLM say so, or does it answer anyway from general knowledge?

Test C — Your own adversarial question. Write one question designed to expose a retrieval weakness you'd expect based on Exercise 2's findings. State your hypothesis before you run it.

hypothesis:

what happened:

In Test A, was low top-k a real problem for this question, or did one chunk happen to be enough? What does that tell you about setting top-k for a real feature, where you can't hand-pick easy questions?

In Test B — compare this to what happened when you asked NotebookLM an out-of-scope question in the required exercises. Same behavior, or different? If different, what's the architectural reason — is it the retrieval design, the LLM's own instructions, or something you didn't set at all?

Closing the Loop

You've now seen the same FitPath grounding problem solved three ways: no grounding at all (Day 2's ungrounded prompt), a black-box grounded tool (NotebookLM), and a pipeline where you set every parameter yourself (Flowise). None of the three is automatically "best" — that's exactly the decision the RAG Readiness Review (Slide 36) and the Prompt-Only vs. RAG vs. Fine-Tuning framework (Slide 31) are for. Keep your Flowise flow and your NotebookLM notebook both intact — you may need to compare them again.