Adaptation, fine-tuning, and post-training decisions

What you will be able to do

1. Choose among prompting, retrieval, tools, tuning, and replacement.
2. Audit adaptation data rights and contamination.
3. Compare tuning against simpler baselines.

Prerequisites: Builder-level interface validation, Python, testing, metadata logging and state-transition tracing. Hardware benchmarks and model accounts are not required.

This curriculum runs self-study on VetsLearn. Where the text calls for an instructor, peer or formal review, use the stated acceptance criteria for self-review. Reflection questions support reflection; they do not replace independent assessment. A peer review is optional unless your actual organization requires it.

Part 1 Technical instruction

Fine-tuning changes model behavior; it does not automatically add fresh knowledge, authorization, or factual grounding. Start with the failure mechanism. Prompting may fix instruction clarity; retrieval may supply changing evidence; tools may supply deterministic computation; tuning may improve stable behavior or format. Adaptation data needs provenance, rights, consent where applicable, purpose limitation, deduplication, contamination analysis, and deletion obligations. Compare on held-out cases and safety slices, keep a rollback model, and record a defensible no-tune decision when simpler controls win.

Mechanism and implementation

SFT uses targets; DPO uses preferred/rejected pairs with a preference objective, rather than being interchangeable with online RL. Reinforcement fine-tuning uses reward/grader machinery where supported. LoRA is an update technique, not a universal choice. Diagnose changing facts versus stable behavior before adaptation.

Constructed offline example

Save as topic_example.py and run python topic_example.py with an installed Python 3.11+ interpreter. This standard-library construction uses synthetic values; its checks are not provider measurements.

failures = ["stale_policy", "stable_style", "arithmetic"]
route = {"stale_policy": "versioned_lookup", "stable_style": "prompt_then_evaluate_tuning",
         "arithmetic": "validated_calculator"}
assert [route[f] for f in failures] == ["versioned_lookup", "prompt_then_evaluate_tuning", "validated_calculator"]
print("three mechanisms, three candidate interventions")

Engineering decisions

• Diagnose the error before choosing adaptation.
• Approve data rights and purpose before training.
• Require value over baselines and no critical safety regression.

Worked example

A simulated scorecard shows tuning improves style but degrades abstention and adds no retrieval accuracy. The decision record rejects tuning and retains retrieval plus schema validation.

Diagnose the failure

RAG is not mandatory before tuning when retrieval cannot address the defect. A gain requires held-out and retained-capability evidence; critical leaks still fail the gate.

Part 2 Guided practice

Justify interventions from failure evidence. Make a train/validation/test manifest with no source or ID overlap. Independently write a no-tune decision and data rights, retention and deletion plan.

Answer criteria and feedback: RAG is not mandatory before tuning when retrieval cannot address the defect. A gain requires held-out and retained-capability evidence; critical leaks still fail the gate.

Continue with the downloadable pack below. If the pack or interpreter is unavailable, trace this self-contained example by hand in an input/expected-status/controlling-rule table and label execution unverified. Do not invent passing output. No account, credential, paid call, purchase or actual deployment is required.

Part 3 Remediation

Separate requirements into knowledge, behavior, latency, privacy, and maintenance. Do not aggregate a critical safety regression into an average benefit. After repair, reassess with the alternate scenario in scenario_alt.json. A critical authorization, data-handling, evidence-integrity, or prohibited-action failure cannot be averaged into successful practice; it requires targeted remediation.

Part 4 Sources and currency

• https://csrc.nist.gov/pubs/sp/800/218/a/final
• https://huggingface.co/docs/peft/index

Use the workflow decision reference for model/deployment/harness distinctions and controlled comparisons. Source currency must be checked before each cohort. Provider/product behavior is illustrative where mocked; resolve current interfaces only from official documentation in an authorized environment.