# Lab Specification — Module FT10: Full FT vs PEFT: The Decision **Course**: Course 3 — LLM Fine-Tuning Masterclass **Module**: FT10 — Full FT vs PEFT: The Decision **Duration**: 30–45 minutes (the judgment lab — paper, not GPU) **Environment**: None. This lab has no code and no compute. A text editor or a sheet of paper. --- ## Learning objectives By the end of this lab you will have: 1. **Produced one decision card per scenario** — for six realistic adaptation tasks, a defensible FT-vs-PEFT-and-which-PEFT call with a one-sentence defense. 2. **Applied the decision rule** — default to PEFT; full FT only under one of the three conditions (new reasoning, extreme domain shift, large-batch degradation), and only after checking RAG for knowledge tasks. 3. **Justified each call with the structural argument**, not the cost argument alone — naming whether the task is steering (low-rank correct) or higher-rank, and which geometry fits. 4. **Distinguished defensible from indefensible reasoning** — recognizing where the solution key offers a defensible choice, not a single right answer, and where one answer is clearly wrong. This lab is deliberately code-free. The point of FT10 is the judgment — *which method, and why*. The deliverable is the reasoning, in your own words, applied to scenarios that will recur across the rest of the course. Get this right and every subsequent training module (FT11 onward) starts from the correct rung of the escalation ladder. --- ## The decision template For each scenario, fill in a decision card. Five fields. The defense is the gradeable part — a card without a defense is incomplete. ``` SCENARIO: DECISION: GEOMETRY: CONDITION (if full FT): DEFENSE (one sentence): ``` The card forces three things: (1) a concrete method, not "fine-tune"; (2) an explicit statement of the task's geometry (steering vs higher-rank vs knowledge), which is the part most teams skip; (3) a one-sentence defense grounded in structure, not cost alone. --- ## The six scenarios Read each scenario fully, including the constraints. The constraints are often what determine the call. ### Scenario 1 — Medical chatbot formatting You are building a medical-assistant chatbot on a 7B base. The model is already knowledgeable about medicine (it has seen medical text in pretraining). Your goal: every response must be structured as a differential diagnosis, must cite the source it is drawing from, and must flag uncertainty explicitly. You have 5,000 high-quality examples of this output format. Compute budget is a single 24GB GPU. ### Scenario 2 — A new programming language Your team has created a new domain-specific programming language for internal use. The base model has never seen it — prompting it produces syntax errors and hallucinated constructs. You want the model to write correct code in this language. You have the language spec, a compiler, and ~50,000 lines of example code. Compute budget is flexible but you must justify any large spend. ### Scenario 3 — Brand voice and style transfer You want the model to consistently write in a specific brand voice — a particular cadence, vocabulary register, and rhetorical style — across all its outputs. The base model can already produce the underlying content; it just does not sound like your brand. You have 2,000 examples of on-brand writing. Budget is a consumer GPU. ### Scenario 4 — Reliable tool-use formatting You are building a tool-use agent. The base model already understands function-calling conceptually (it saw tool-use examples in pretraining), but it produces schema violations ~15% of the time — wrong JSON, missing required fields, hallucinated parameters. You need this under 1%. You have 10,000 correctly-formatted tool-call examples. Budget is a single 24GB GPU. ### Scenario 5 — Uncensoring an authorized-use agent You are building an agent for authorized security research. The base model refuses legitimate requests (writing exploit code for an authorized pentest, analyzing malware samples). The capability is clearly present — with jailbreak prompts it complies — but it refuses by default. You want it to comply with legitimate, in-scope requests without degrading its other capabilities (especially code reasoning). Budget is a consumer GPU; you must avoid capability loss. ### Scenario 6 — Domain QA over a proprietary knowledge base Your company has a proprietary knowledge base — 200,000 internal documents (policies, procedures, technical specs). You want the model to answer employee questions accurately, grounded in this corpus. The knowledge changes monthly (policies update, new docs are added). Budget is flexible. The key requirement: answers must be accurate and *current*. --- ## Deliverables Submit `ft10-lab-report.md` containing six decision cards (one per scenario), each with all five fields filled in. The defense field is the gradeable part. Acceptable defenses: - Reference the task's **geometry** (steering / higher-rank / knowledge). - Reference the **decision rule** (default to PEFT; the three conditions for full FT). - Reference the **constraints** in the scenario (budget, data volume, the "changes monthly" property). - Reference the **structural argument** (low-rank correct for steering; full FT over-parameterized for steering). Unacceptable defenses: - "Full FT is better / more powerful" with no structural reasoning. - "LoRA because it's cheaper" with no reasoning about why cheap is *correct* here. - Ignoring the constraints (e.g., recommending full FT on a consumer GPU for a steering task). - Skipping the RAG check on a knowledge task. --- ## Solution key These are defensible choices with reasoning — not single right answers. Where a scenario admits more than one defensible call, the alternative is noted. Where one call is clearly wrong, that is flagged too. ### Scenario 1 — Medical chatbot formatting - **Decision**: PEFT (DoRA or QLoRA). QLoRA on the 24GB GPU is the natural fit. - **Geometry**: Steering — the model already knows medicine; you are shaping presentation (differential structure, citation, uncertainty flagging). - **Defense**: *Pure steering — the base already has the medical knowledge; you are redirecting how it presents retrieved content. A low-rank adapter is the correct representation of a format/structure change, and 5,000 examples on a 24GB GPU is a textbook QLoRA job.* - **Clearly wrong**: Full FT. Over-parameterized for a formatting task; ~30× the cost for no quality gain on a steering problem. Also risks more catastrophic forgetting of the medical knowledge the base already has. - **Note**: RAG supplies the source the model cites; PEFT shapes the *behavior* of citing. The two compose — they are not alternatives. ### Scenario 2 — A new programming language - **Decision**: Full FT or CPT (after confirming the compiler-in-the-loop / RAG approach is insufficient). Likely CPT on the 50K lines plus spec, then steering on top. - **Geometry**: Knowledge — the base genuinely lacks the language's semantics; this is not a format problem. - **Defense**: *Genuine knowledge gap — the base has never seen the language, so no steering update can install its semantics. Low-rank updates are too constrained. First confirm RAG (retrieve the spec + examples into context) is insufficient; if the language is voluminous enough in use that retrieval is intractable, CPT on the corpus is the rare exception.* - **Defensible alternative**: RAG-first — for many internal-DSL use cases, retrieving the language spec and examples into context is cheaper and sufficient. Full FT is defensible only if you can show RAG underperforms and you have the corpus. - **Clearly wrong**: QLoRA expecting it to "learn the language." A steering method cannot install new syntactic/semantic knowledge reliably — it would memorize surface patterns and fail on novel programs. ### Scenario 3 — Brand voice and style transfer - **Decision**: PEFT (LoRA or DoRA). - **Geometry**: Steering — archetypal. The content capability is present; you are redirecting surface generation (cadence, register, rhetoric). - **Defense**: *The purest steering task in the set — the base already produces the content; a low-rank adapter redirecting the style is exactly correct. 2,000 examples on a consumer GPU is a standard LoRA/DoRA job. Full FT is overkill and would buy more drift for no style benefit.* - **Clearly wrong**: Full FT "to really learn the voice." Style is low-rank by nature; full FT is over-parameterized and risks forgetting the content capabilities the brand voice rides on top of. ### Scenario 4 — Reliable tool-use formatting - **Decision**: PEFT (QLoRA). - **Geometry**: Steering — the model understands tools conceptually; you are making the output format deterministic. - **Defense**: *Steering — the model already understands function-calling; the 15% schema-violation rate is a reliability/format problem, exactly what SFT-via-QLoRA fixes. A low-rank update on 10,000 correct examples on a 24GB GPU drives violations well under 1%. The structural non-equivalence finding cuts in PEFT's favor here: the low-rank solution is the correct geometry for a format change.* - **Clearly wrong**: Full FT. A formatting reliability problem is low-rank; full FT is overkill on a 24GB budget. ### Scenario 5 — Uncensoring an authorized-use agent - **Decision**: PEFT (LoRA) or abliteration — with a hard requirement to avoid capability loss and to deploy inside an eval'd harness (FT23). - **Geometry**: Steering — you are steering *away* from a refusal direction; this is a low-rank operation by definition (abliteration deletes a single direction). - **Defense**: *Steering away from refusal is a low-rank operation — abliteration deletes a residual-stream direction; a LoRA adapter steers toward compliance. Full FT is overkill and, per the entanglement finding, risks MORE capability loss (more degrees of freedom to drift). The constraint 'avoid capability loss' rules out the over-parameterized option. Then the model must go inside a harness that bounds what it may do (Layer 5).* - **Defensible alternative**: DPO-toward-compliance (FT18) instead of abliteration, if you have preference data. Still PEFT-class. - **Clearly wrong**: Full FT for uncensoring. More parameters updated = more entanglement = more capability degradation, against the explicit constraint. ### Scenario 6 — Domain QA over a proprietary knowledge base - **Decision**: RAG first. PEFT (QLoRA) only for the *behavior* of using retrieval — never to memorize the KB. - **Geometry**: Knowledge — the answers live in the 200K documents, not in the weights. - **Defense**: *Knowledge problem — and the 'changes monthly' constraint is decisive: any weight-based memorization is stale within 30 days. RAG retrieves current docs at query time, is updateable without retraining, and is auditable. Fine-tune at most for the BEHAVIOR (always cite the source doc, structure the answer, flag when retrieval is insufficient) — that is a steering task for QLoRA. Do not fine-tune to memorize the KB.* - **Clearly wrong**: Full FT (or CPT) to "teach the model the knowledge base." Violates the cardinal error (FT00), and the monthly-change constraint makes it operationally impossible to keep current. Also wrong: any fine-tuning that tries to put the 200K docs into the weights. --- ## Grading rubric (per card) | Element | Full credit | Partial | No credit | | --- | --- | --- | --- | | **Decision** | Concrete, defensible method matching the geometry | Vague ("fine-tune") | Wrong method for the task | | **Geometry** | Correctly classified (steering / higher-rank / knowledge) | Inconsistent with decision | Missing | | **Defense** | Structural reasoning (geometry + rule + constraints) | Cost-only or generic | "Because it's better" / missing | | **Constraints** | Explicitly addressed (budget, data, change-frequency) | Implied | Ignored | A passing submission gets full credit on at least four of six cards, with no card committing a "clearly wrong" error. The two knowledge scenarios (2 and 6) are the discriminating ones — a team that recommends weight-based memorization on either has not internalized the steering thesis. --- ## Stretch goals 1. **Add a seventh scenario of your own** — a real adaptation task from your work. Classify it, decide it, defend it. Bring it to a colleague and see if they can find the flaw in your reasoning. (The point of FT10 is that the reasoning transfers to *your* tasks.) 2. **Construct the counter-argument.** For each scenario, write the strongest case for the *opposite* decision (the full-FT case for Scenario 1; the PEFT case for Scenario 2). Then rebut it. If you cannot rebut it, your original decision may be wrong. This is the discipline that separates a defensible call from a reflexive one. 3. **Map to the escalation ladder.** For Scenario 4 (tool-use), trace the escalation: if QLoRA gets violations to 3% but not under 1%, what is the next rung (DoRA? GaLore? Full FT?), and what *evidence* would justify taking it? Write the decision rule for when to escalate. (Sets up FT11 — the training loop.)