A city CISO asks the purple team whether a permitting FAQ assistant that retrieves ordinance PDFs is better modeled as retrieval-augmented generation or as a fine-tuned ticket classifier. Which choice best matches the design?
Select an answer to reveal the explanation.
Short Explanation
Picture City Hall’s ordinance binder sitting next to the chatbot. RAG is the assistant that actually opens that binder and quotes today’s pages, while a fine-tuned classifier mostly stamps tickets into buckets.
Full Explanation
A city permitting FAQ assistant that must retrieve ordinance PDF chunks and generate answers grounded in those passages is a retrieval-augmented generation (RAG) design, not a fine-tuned ticket classifier. RAG couples a foundation model with search over a maintained municipal corpus so residents receive answers that can cite today’s code text. That pattern matches City Hall’s need for assurance that chat replies track current ordinances rather than memorized labels alone.
A logistic-regression spam filter trained only on 311 category labels maps inputs to discrete classes; it never opens ordinance PDFs or generates grounded FAQ prose. An unsupervised clustering job that groups resident emails without citing code discovers topical blobs but supplies no authoritative passage for permitting assurance. A static keyword macrosheet that never embeds or retrieves source passages can match brittle strings yet cannot surface semantically related ordinance chunks or produce grounded generation.
Exam caveat: GOAA fundamentals items contrast RAG (retrieve-then-generate over civic documents) with classifiers and unsupervised clustering; pick the pattern that cites maintained ordinance text.
Operational check for municipal FAQ pilots: chunk and embed current ordinance PDFs into a governed vector store, require citation of retrieved passages in assistant answers, version the corpus when council amends code, and keep pure ticket-classification models on a separate workflow where labels—not legal quotes—are the product.