A municipal animal-control desk wants answers assembled from this week’s stray-hold PDFs rather than from the model’s training memory. Which application architecture is that?
Select an answer to reveal the explanation.
Short Explanation
Think of answering from this week's stray-hold PDFs, not from last year's memory. That is RAG: retrieve the passages, then write from them. It is not a training job and not every chatbot.
Full Explanation
The municipal animal-control desk wants answers assembled from this week’s stray-hold PDFs rather than from the model’s training memory. That requirement is retrieval-augmented generation: retrieve relevant passages from the current documents, then generate the answer from those passages. RAG is an application architecture that keeps operational facts outside model weights and injects them at request time so the desk can cite this week’s holds.
A training job that bakes last year’s hold rules into new model weights fails because training freezes older knowledge into parameters and does not give a live path to this week’s PDFs. Treating RAG as a synonym for any chatbot fails because chatbots can run ungrounded; retrieval is what makes the architecture RAG. A dashboard that only charts last year’s call volume fails because analytics visualization neither retrieves hold passages nor generates grounded answers for staff.
Exam caveat: RAG is not fine-tuning and not “any LLM app”—the defining steps are retrieve-then-generate from retrieved text. Operational check: index this week’s stray-hold PDFs, ask a desk question whose answer appears only in those PDFs, and verify the response uses retrieved passages rather than pretrained memory alone.