Instructor note: the answer key below is hidden from students in the Canvas quiz build; remove or lock this section before publishing the student-facing version.
You are building a customer-support assistant for a mid-sized insurance company. The assistant retrieves policy documents via RAG, answers customer questions about coverage, and can draft emails to customers on the agent's behalf. In Weeks 1–7 you learned how to design prompts, build a RAG pipeline, evaluate retrieval quality, and reason about threat models for LLM applications. Scenario: During a demo, a customer support rep pastes a full customer complaint email (containing the customer's name, policy number, and a partial SSN) into the assistant to ask "summarize this and draft a reply." The assistant's reply includes the customer's full SSN, restated verbatim, in the drafted email text. Question: Using what you've learned about RAG architecture, prompt design, and LLM threat modeling (Weeks 1–7), explain (1) at least two distinct points in this pipeline where this failure could have been caught before reaching the rep, and (2) how you would redesign the pipeline's data flow to prevent this specific failure from recurring. Be specific about where in the request/response flow each control sits. → A strong answer identifies: (1) input scanning — the pasted complaint email should have been scanned/anonymized before being included in the prompt, since it contains raw customer PII; and (2) output scanning — even if the SSN entered the prompt, the drafted reply should have been scanned before being shown to the rep or sent, since output must be treated as untrusted per LLM05. A redesigned flow: incoming text → PII analyze/anonymize → assemble prompt with placeholders → LLM call → scan output for PII/regex patterns → block or redact matches → only then surface to the rep or send. This also ties to earlier weeks' point that RAG systems must treat all retrieved and user-supplied content as untrusted, not just the system prompt.
a) To store conversation history b) To set persistent instructions and constraints that guide the model's behavior across a session c) To encrypt user data before sending it to the model d) To replace the need for a retrieval step → b
→ False — the retriever fetches relevant chunks; the generator (LLM) produces the final answer.
→ Fixed-size chunking and semantic/recursive chunking (accept: sentence-based, paragraph-based, or overlap-based chunking).
a) BLEU score b) Recall@k / precision@k c) Perplexity d) Token count → b
→ False — injected instructions can be embedded in retrieved/RAG content just as easily as in user input.
→ An attacker crafts input (direct or indirect, e.g., via a document) that manipulates the LLM into ignoring its intended instructions or performing unintended actions.
a) Measuring model latency b) Identifying trust boundaries and what happens if an attacker controls a specific input surface c) Choosing a chunk size for embeddings d) Selecting a vector database → b
→ False — embeddings from different models are not directly comparable/compatible; mixing them degrades retrieval quality.
→ Because retrieval quality, chunking, and embedding choices materially affect the final answer; evaluating only the prompt misses failures introduced upstream in retrieval.
a) It reduces token costs b) It preserves a clearer trust boundary and makes it harder for user input to override instructions c) It is required by the OpenAI API d) It improves embedding quality → b
→ A boundary marking where data changes from more-trusted (system-controlled) to less-trusted (user- or externally-controlled), which is where validation/controls should be enforced.
→ True.