Q248 - PEFT_LoRA_definition_example_and_why_it_matters_in_RAIDT
Q248 — PEFT / LoRA — definition, example, and why it matters in RAIDT
← RAIDT · Star S6 - Influence Methods as Governance Interventions · primary item: S6.10 · PEFT / LoRA
F. Governance Interventions | Ordered by mind-map priority: inner circles first, then operational detail.
Appears in sources
workshop_dense_100#slide 71
Answer
PEFT/LoRA is a parameter-efficient way to adapt an LLM by learning a small set of additional weights, and in LoRA specifically those updates are represented as low-rank matrices attached to selected modules while the base model stays frozen. In RAIDT, its importance is that the behavioural change lives in a compact, versionable artefact rather than in a full replacement model. The LoRA paper therefore treats the adapter as a governable configuration item: small enough to hash, document, compare, revoke, and redeploy under controlled conditions. The prompt-governance paper places PEFT/LoRA alongside prompting, RAG, and RLHF as influence methods as governance interventions, each strengthening different parts of the assurance case.
Why it matters in RAIDT is that it usually improves the score profile for Dependability and Auditability, and can also support Responsibility and Interpretability when scope and reviewer criteria are documented. Because run as the unit of governance, the meaningful question is whether a particular run can be tied back to a prompt ID, adapter ID, data slice, reviewer judgement, and output hash. PEFT/LoRA makes that linkage practical. It is not sufficient for full Traceability on its own, since factual grounding still benefits from RAG, but it gives organisations controlled domain fit without the opacity and cost of full fine-tuning. Under anchors 1=missing / 3=partial / 5=audit-ready, PEFT/LoRA helps move a system towards auditable, reversible, and domain-bounded control across the five pillars (Responsibility, Auditability, Interpretability, Dependability, Traceability).
Practical example
In cybersecurity, a security operations centre could attach a LoRA adapter that formats incident summaries into a fixed triage structure: observed indicator, likely impact, immediate containment step, and escalation note. The base model remains unchanged, but the adapter makes outputs more stable across analysts and shifts. Each incident report can be stored with prompt ID, adapter ID, hashes, and reviewer comments in the run-level evidence pack. If a new adapter version becomes too rigid or starts overstating certainty, the team can compare versions and roll back quickly. In RAIDT terms, that is valuable because the control is modular, documented, and reviewable rather than hidden inside an expensive full retrain.
Sources in RAIDT papers
05-RAIDT_LoRA_V204-RAIDT_Prompt_Eng_V2