A public-health department wants LoRA-adapted clinical-policy phrasing without owning a full model-training operations stack. What customization approach fits best?
Select an answer to reveal the explanation.
Short Explanation
They want the policy voice tuned, not a second full-time model-training circus. Parameter-efficient adapters like LoRA give that customization with a sane deploy lifecycle—without standing up scratch training clusters for every wording tweak.
Full Explanation
A public-health department that wants LoRA-adapted clinical-policy phrasing without owning a full model-training operations stack should select parameter-efficient customization such as LoRA adapters with a deployment lifecycle—not full retraining ops. LoRA (and similar PEFT methods) attaches small trainable adapters to a base FM so policy voice and phrasing can be specialized while the heavy base model remains managed. The department still needs versioning, evaluation, and rollback for adapters, but not a from-scratch foundation-model training cluster for every policy wording update.
Building and operating a from-scratch FM training cluster for every policy update maximizes MLOps cost against a narrow customization goal. Abandoning customization for unrelated consumer chat products gives up controlled clinical-policy phrasing and weakens data governance. Hand-editing tokenizer vocabulary files on production hosts during business hours is an unsafe, non-reproducible anti-pattern that is not a supported customization lifecycle.
Exam caveat: when the stem names LoRA or asks for customization without full training ops, parameter-efficient fine-tuning plus managed deployment is the intended answer—not pretraining a new FM.
Operational check: produce adapters from approved policy text, evaluate on held-out clinical-policy prompts, register adapter versions, deploy through the normal change process, and verify rollback to the previous adapter if phrasing regresses.