LoRA: the small adapter that carries your firm's voice

Every quantitative PM has used a factor model. MSCI Barra, Fama-French, an internal risk model - the shape is always the same. There is a large dense object that captures the ambient structure: a covariance matrix of asset returns, validated, slow-changing, treated as ground truth. On top of that ambient object sits a small set of factors - five, ten, maybe fifty - that explain most of the variance you actually care about. The factors are not the world; they are the low-dimensional re-weighting that lets you say "this portfolio is mostly value plus momentum minus a quality tilt" without rewriting the covariance matrix every time you change your view.

LoRA - Low-Rank Adaptation, Hu et al., arXiv:2106.09685, 2021 - is the same architectural move applied to a language model. The base model is the ambient object: a frozen 13B or 70B-parameter slab that has already been trained, evaluated, and (in the regulated case) validated. The adapter is a small set of low-rank matrices bolted on top that re-weight the base for your firm's vocabulary, formats, and house style. The base is the covariance. The adapter is the factor exposure. The base never moves; the adapter is what you actually train, ship, and govern.

This is the misread the article exists to fix. "Fine-tuning" sounds like "retraining the model on your data." In a modern stack it almost never is. It is attaching a low-rank factor to a frozen base.

For any weight matrix W in the base model of shape (d, k), LoRA learns two small matrices A of shape (r, k) and B of shape (d, r), where the rank r is typically 4, 8, 16, or 64 - small compared to d and k. The effective weight at inference is W + BA. The base W is never modified; the only trainable parameters are inside A and B. Number of trainable parameters drops from d times k to r times (d + k), routinely a hundred-fold to thousand-fold reduction. For a 13B-parameter base, an adapter at rank 8 is typically a few million parameters - about 0.05% of the base.

QLoRA (Dettmers et al., 2023) quantises the frozen base to 4-bit and trains the adapter in higher precision, fitting a 65B fine-tune onto a single 48GB GPU. DoRA (Liu et al., 2024) decomposes the update into magnitude and direction for a small quality lift. Multi-LoRA serving routes one base model behind N different adapters at inference - swap the adapter, swap the persona, never touch the base. Everything runs inside the firm perimeter: the base weights, the adapter weights, the training corpus, the inference path. DORA Art. 28-30 third-party risk applies to the inference stack you control, not to a hosted fine-tuning service on someone else's hardware.

What the adapter actually carries is style, format, and vocabulary - your firm's reporting templates, your house tone, the right way to phrase a SFDR disclosure, your internal product taxonomy. What it does not carry is facts. Facts go in RAG, against current sources, with citations. The split is deliberate: facts must change daily, style changes annually; one belongs in a retrieval store, the other in a frozen adapter.

The operational story is governance. A LoRA adapter is a small, named, versioned artefact - typically a few megabytes of weights plus a training-data manifest. It attaches to a base model that has already passed validation; it can be evaluated independently against the firm's eval suite; it can be rolled back; it can be replaced. Compare that to a wholesale fine-tune that produces a fresh multi-gigabyte model variant: every variant is a new artefact to validate, store, and re-validate when the base updates.

The same property makes multi-tenant style work tractable. One frozen base, one validated inference stack, and N adapters - one for German-language IC memos, one for English regulatory narratives, one for the internal research desk - each governed and audited separately. The firm's voice lives in the adapter; the regulator-visible heavy lifting was done once on the base.

SR 11-7 is structurally friendlier to this pattern than to wholesale fine-tuning. A frozen, validated base plus a small auditable adapter maps cleanly onto SR 11-7's model inventory and tiering: the base is the validated model, the adapter is a change subject to its own validation and ongoing monitoring. EU AI Act Annex IV section 6 requires lifecycle changes to be documented; an adapter swap is a single, versioned change with a small documented surface, not a model rewrite.

Pair this with DORA Art. 28-30 and data residency: the base weights, the adapter weights, the training corpus, and the inference path all sit inside the firm's perimeter. Nothing about the firm's house style or proprietary phrasing leaves the boundary in the course of either training or serving. The audit trail for any adapter swap is one row: timestamp, adapter version, base version, validator sign-off.

Do not render this as a generic neural-network diagram with nodes labelled "fine-tuning." That visual carries no structural information and propagates the wrong intuition - the connections of the base network are not being modified. The base is frozen. The whole point of LoRA is that the base is frozen. Show the base as a translucent slab and the adapter as a small bright module beside it; show the training updates flowing only into the adapter; show the base untouched.

Do not pitch fine-tuning as the way to load your firm's facts into the model. It is not. Facts belong in RAG, against current sources, with citations - the moment your house view changes, the RAG retrieval changes too. Facts inside a frozen adapter age out, and the system has no way to know. The right architecture pairs RAG (facts, current, cited) with LoRA (style, format, vocabulary). Pitching fine-tuning as a fact store is the most common and most damaging misread in the buyer's mental model.

Do not market fine-tuning as "a custom GPT" or "your private model" without naming the mechanism. Those phrases conflate system prompting, RAG, tool use, and LoRA into a single black box and the buyer ends up with three years of confused expectations. Be specific: a frozen validated base, a small auditable adapter, a documented training corpus, and an inference path inside your perimeter. That is the description a model-risk team can sign off on.