An elections office compares two ways to help clerks answer procedure questions about municipal code. What contrast should governance understand between RAG and fine-tuning?
Select an answer to reveal the explanation.
Short Explanation
RAG is like a clerk who keeps the code book open and quotes the right page; fine-tuning is more like sending the clerk to a long training class that changes what they remember. Same elections desk, different architecture—and governance needs that contrast.
Full Explanation
An elections office comparing ways to help clerks answer municipal-code procedure questions should understand that RAG retrieves relevant municipal code at query time while fine-tuning changes model parameters using training examples. Retrieval-augmented generation grounds answers in current documents; fine-tuning embeds patterns into weights. Governance, update cadence, and citation behavior differ accordingly.
Why the other options fail by concept: Treating RAG and fine-tuning as identical because both permanently rewrite base model weights is false—RAG does not inherently rewrite weights at query time. Claiming fine-tuning never uses training data and RAG always edits election statutes automatically misstates both techniques and invents unauthorized statute editing. Asserting only fine-tuning can cite municipal code while RAG cannot ground answers in retrieved documents reverses a primary benefit of RAG.
Exam caveat: Teams often combine both (light fine-tuning plus RAG). For frequently changing election procedures, RAG over an authoritative code corpus is often easier to keep current than repeated fine-tunes—but retrieval quality and access control still need testing.
Operational check: For the clerk assistant, decide whether answers must cite retrieved sections; if yes, implement RAG against a controlled municipal-code index with permissions and freshness checks. Document any fine-tuning dataset separately, and re-validate after code amendments before clerks rely on the tool during election operations.