Title: Quiz 1 — Introduction to Production RAG Architecture and the LLMOps Lifecycle
Course: AIINFRA 301: Production RAG & LLMOps — Observability and Evaluation > Section: Week 01 — Introduction to Production RAG Architecture and the LLMOps Lifecycle

Q: What is the primary reason RAG grounds an LLM's output in retrieved evidence at query time?
- To make the LLM run faster
- To address hallucination, stale parametric knowledge, and lack of access to private data
- To reduce the number of parameters the model needs
- To replace the need for prompt engineering entirely
A: To address hallucination, stale parametric knowledge, and lack of access to private data

Q: A production RAG system consists only of the retrieval-augmentation-generation chain; evaluation, monitoring, and governance are optional add-ons.
- True
- False
A: False

Q: Which of the following is NOT one of the four layers of a production RAG architecture described this week?
- Data pipeline (chunk/embed/index)
- RAG chain (understand, retrieve, augment, generate)
- Model pretraining and fine-tuning infrastructure
- Governance/LLMOps (lineage, access controls)
A: Model pretraining and fine-tuning infrastructure

Q: Name two of the seven stages in the LLMOps lifecycle presented this week.
Feedback: Sample/expected answer: Any two of: use case/model selection; prompt engineering/versioning; deployment + monitoring integration; ongoing monitoring/observability; evaluation/QA; cost/latency optimization; governance/compliance/incident response.

Q: According to RAGOps (arXiv:2506.03401), what should be treated as the primary unit of operations in a RAG system?
- The LLM endpoint alone
- The vector database alone
- The entire RAG pipeline, including the retrieval corpus
- The user interface layer
A: The entire RAG pipeline, including the retrieval corpus

Q: Prompt lifecycle management, evaluation/testing, observability/tracing, cost optimization, and safety guardrails are the five operational pillars that distinguish LLMOps from classic MLOps.
- True
- False
A: True

Q: A team indexes their knowledge base at launch and never revisits it. Six months later, retrieval quality has degraded badly. What is the most likely cause, per this week's lecture?
- The LLM model itself has decayed
- Stale, ungoverned source data — re-indexing and governance were treated as one-time setup instead of ongoing operations
- The vector database ran out of storage
- The users stopped asking good questions
A: Stale, ungoverned source data — re-indexing and governance were treated as one-time setup instead of ongoing operations

Q: Why can a "good vector database + good LLM" still produce a bad RAG system, according to this week's lecture?
Feedback: Sample/expected answer: Because unglamorous fundamentals like data cleaning, parsing correctness, and chunking matter most — a bad parser or poor chunking strategy produces noise that no downstream vector database or LLM can recover from.