TL;DR: Compare the actual data paths, access rules and removal options. Prompting supplies current input but may create persistent copies; retrieval keeps evidence addressable but needs current authorization; fine-tuning changes reusable parameters and requires model lineage and a separate removal assessment.
How to approach it
Ask whether the feature needs changing facts, private records or different behavior. Name the readers and processors allowed to receive each class of information. Then follow the data through storage, generation and reuse before choosing an approach.
A strong answer
Consider an original fictional makerspace assistant. Public manuals can support equipment answers; booking details belong to particular members; staff-only maintenance notes have a separate audience. A consistent answer format is a behavioral requirement. These needs do not require the same mechanism.
- 1
1 · Request context
A selected input for this task
- May be saved in histories, logs or provider state.
- Limit the audience and every processor that receives it.
- 2
2 · Addressable evidence
Records selected under current policy
- Source versions and access can be checked at retrieval.
- Copies and cached answers require their own lifecycle.
- 3
3 · Learned parameters
An update reused in later inference
- A source row is not an independently removable parameter slot.
- Track base models, adapters, merges and training records.
Match the operation to the need
A member’s changing booking is authoritative application state. A permitted instruction manual can be retrieved. A consistent answer format may justify a measured training change; none of these choices eliminates data handling work.
| Choice | What changes | Access and lifecycle work |
|---|---|---|
| Prompt or fetched record | Current model input | Select permitted content; review histories, provider state, logs and recipients |
| Retrieval | Searchable external evidence and selected context | Enforce source policy, track versions and propagate changes through copies |
| Fine-tuning | Some or all effective model parameters | Approve training use, record lineage and evaluate removal and disclosure risks |
These are composable choices. A fine-tuned model can still use retrieval, and a retrieval application still constructs a prompt. There is no universal persistence ordering: an application can retain prompt logs longer than it keeps a carefully managed training artifact. Inventory the implementation rather than relying on the label.
For the makerspace, keep bookings in the authoritative service and fetch only the current member’s permitted records. Use suitable manual passages as evidence with source versions. Start with an evaluated prompt for formatting; consider customization only if measured task needs justify its operational and data costs.
Fine-tuning is not limited to style, and it is not inherently forbidden for all private data. But an ordinary shared model does not expose a row-level authorization predicate for each training example. If audiences differ, do not assume learned parameters enforce those distinctions. Separate models or adapters need correct routing, base-model provenance and lifecycle controls; their existence alone proves none of those properties.
The training concept explains parameter changes. The retrieval concept traces addressable copies. For removal claims, Neel and colleagues’ unlearning work illustrates why the specified state, observable output and comparison with retraining matter. Its formal setting is not a blanket guarantee for a deployed LLM.
Before approval, require an original data-flow record: each source, purpose, processor, store, reader and derived artifact; its access decision; and what happens on withdrawal. Include training datasets, adapters, merged models, conversation state and cached answers. Data not used for training can still be retained or disclosed; data removed from a dataset can still have influenced an existing model.
If a member’s booking appears in another member’s answer, investigate the observed path. It may be retrieval, shared history, cache reuse or training-derived behavior. Do not diagnose memorization solely from the output. Contain the affected access and preserve only the evidence needed for an authorized investigation.
What interviewers probe next
- “Does a no-training promise mean no storage?” No; verify the separate retention, state and logging arrangements.
- “Why not train the booking facts?” They change and require current per-member access; an authoritative lookup better fits this task.
- “Is retrieval automatically cheaper?” No; compare the real ingestion, search, model and operational workload.
What if?
What if · interview follow-ups
Hold your answer as the constraints change
A fictional makerspace wants an assistant to explain public equipment manuals, show each member their bookings and use a consistent answer format. The team proposes training one shared model on all records.
Start here
What if the team puts every booking into a shared system prompt instead?
Follow which request and audience receive the records.
That creates an unnecessary cross-member disclosure risk. Fetch only records permitted for the current member and task. A privileged message role does not conceal its content from the model, and the application must also account for saved conversations and other consumers.
Carry it forwardMessage priority is not a confidentiality control.
Weak answerTreating system-prompt placement as a private store.
Constraint changes
What if the booking is retrieved only for its owner but the answer is cached for the whole tenant?
Continue beyond the generation request.
The initial retrieval check does not authorize reuse for other members. Bind or revalidate cached content against its source dependencies and current audience, or avoid caching it. A tenant boundary may contain many distinct member permissions.
Carry it forwardAuthorization must survive reuse.
Weak answerStopping the review when the model request was allowed.
Constraint changes
What if the team creates a separate adapter for each member?
Which routing and artifact assumptions must now hold?
That can narrow exposure if the base data, adapter selection, serving state and downstream copies are isolated correctly. It does not supply row-level deletion inside the adapter or prove that a shared base never saw the data. Review the full lineage and prevent cross-member adapter selection.
Carry it forwardIsolation is a system property, not an adapter filename.
Weak answerAssuming separate adapters settle access and erasure.
Constraint changes
What if the training examples contain no names but retain unique maintenance incidents?
Does removing one field remove the sensitive content?
No. Indirect identifiers and confidential facts can remain. Review the intended use and audience, minimize the examples, and use suitable synthetic or otherwise permitted material where possible. Do not call the result anonymous solely because names were removed.
Carry it forwardData minimization requires inspecting the remaining information.
Weak answerEquating pseudonymized examples with unrestricted data.
Now defend it
What design would you approve for this feature?
Retrieve permitted manuals and member-specific records through current access checks; keep authoritative bookings in the service of record. Start with a reviewed prompt for format and tune only if a measured need justifies approved training data. Document processors, persistent copies, model lineage and removal limits before rollout.
How it's scored
Weak: Treats prompting as transient by definition or fine-tuning as an access-control system.
Hire: Separates current input, addressable evidence and parameter changes, then recommends a design for the stated data.
Strong Hire: Follows provider and application persistence, adapter routing, authoritative state and removal evidence through the complete lifecycle.
Common mistakes
- Comparing three labels without tracing the actual stores and readers.
- Assuming a system prompt hides private records from its response audience.
- Treating name removal as proof of anonymization.
- Diagnosing every unexpected fact as training-data memorization.