A prototype is a line; a system is a loop

The RAG you met in Module 1 is a straight line: embed some docs, search, answer. That's perfect for learning and useless in production, because it has no way to stay fresh, no way to know if it's any good, and no way to improve.

A production RAG is two pipelines and a feedback loop:

  OFFLINE  ┌──────────────────────────────────────────────┐
  sources ►│ parse → chunk → embed → upsert (with metadata)│► INDEX
           └──────────────────────────────────────────────┘   (vector +
                                                                keyword)
  ONLINE            ┌───────────────────────────────────┐        │
  user query ─────► │ rewrite → retrieve → re-rank →     │◄───────┘
                    │ assemble context → generate → cite │──► answer
                    └───────────────────────────────────┘        │
  LOOP                            eval set ◄── feedback / logs ◄──┘

• The offline pipeline turns your ever-changing sources into a searchable index. It runs on a schedule (or on document change), not per request. Modules 4–5 build it.
• The online pipeline answers a query in real time against that index. It's what your users hit. Modules 6–7 build it.
• The evaluation loop measures whether the whole thing actually works, and feeds failures back in. Module 8 builds it — and it's what turns RAG from guesswork into engineering.

The mental model to hold

Everything in the rest of this course slots into one of those three boxes. When a RAG system misbehaves, the first diagnostic question is always: which box? Did ingestion prepare the data badly, did retrieval fetch the wrong thing, did generation ignore what it was given — or did evaluation never catch it? Knowing the box narrows the fix enormously.