Adaptation & Evaluation

Inside a Production-Grade Fine-Tuning Pipeline

Follow authorized examples through data isolation, SFT strategy selection, held-out gates and compatible model or adapter serving.

Reference architecture - illustrative, not a client deployment

Distinguish SFT objectives, full updates, LoRA adapters and QLoRA.

Complexity
Advanced
Drawing
Supplied
  • Fine-tuning
  • SFT
  • LoRA
  • QLoRA
  • MLOps

Overview

This reference architecture is illustrative. It is not a record of a client deployment.

Supervised fine-tuning (SFT) describes the learning objective: train on examples of desired inputs and outputs. It does not prescribe how many parameters change. Full-parameter SFT updates the base model. Parameter-efficient fine-tuning (PEFT) is a family of methods that updates a smaller set of parameters; LoRA keeps the pretrained weights frozen and trains low-rank adapter matrices. QLoRA backpropagates through a frozen quantized base into trainable LoRA adapters.

The pipeline begins with authorized, reviewed examples. Deduplication must happen before partitioning so near-identical records do not leak across training and held-out sets. Preserve a baseline and keep the final evaluation cases outside optimization. The selected base revision, tokenizer, training configuration and adapter targets form one versioned experiment.

A concrete example

A team wants consistent extraction of three fields from internal maintenance notes. It first measures the unchanged model. It then trains LoRA and QLoRA candidates on the same training split while preserving one held-out test set. Only a candidate that passes quality and safety gates is registered together with its exact base-model and tokenizer compatibility. A failed candidate has no deployment path.

Common misconception

"LoRA and SFT are competing objectives." SFT is the objective; LoRA is one way to implement parameter updates efficiently. QLoRA is not a fully trainable four-bit base: the quantized base stays frozen while adapters are trained.

Diagram & Walkthrough

Choose a declared scenario and step, or select a component by pointer, touch or keyboard. Playback starts only when you press Play and pauses when this panel leaves the screen.

100%
Inside a Production-Grade Fine-Tuning Pipeline A production fine-tuning pipeline comparing full-parameter supervised fine-tuning, LoRA adapters, and QLoRA adapters before held-out quality and safety evaluation, registry approval, and compatible serving. Inside a Production-Grade Fine-Tuning Pipeline One SFT objective, three update strategies, and a shared release gate. DATA PREPARATION TRAINING STRATEGY SFT is the objective · PEFT is a method family RELEASE Clean examples Train split Train split Train split Trainable base parameters Frozen base parameters Frozen quantized base Updated full model Adapter candidate Adapter candidate Approved version + compatibility Model or base + adapter DATA Authorized examples documented provenance DETERMINISTIC Deduplicate + split + baseline train ≠ held-out test VERSIONED INPUT Base model + tokenizer record both revisions with the run MODEL · SFT Full-parameter SFT all base parameters trainable MODEL · PEFT LoRA: frozen base + adapters train low-rank adapters only MODEL · PEFT QLoRA: quantized base + adapters quantized base stays frozen DETERMINISTIC GATE Held-out quality + safety gate compare with baseline failed candidates stop here PASS → REGISTER DATA · APPROVED Versioned model or adapter config + compatibility recorded MODEL · RELEASE Compatible inference runtime Flow legend Shared preparation / approved release Training data or candidate Approval / deployment control LoRA is one PEFT method. QLoRA trains adapters through a frozen quantized base. Rejection has no deployment arrow.

Main walkthrough, step 1 of 6: Authorize, clean and partition examples. idle.

Main walkthrough

The primary path through this reference architecture.

Active parts: Authorized examples, Deduplicate + split + baseline

Text walkthrough

This vertical reference remains readable without the interactive controls.

  1. 01Authorize, clean and partition examples

    Review provenance, remove duplicates and isolate held-out cases before any candidate is trained.

    Active parts: Authorized examples, Deduplicate + split + baseline

  2. 02Choose a baseline and training strategy

    Pin the base and tokenizer, then compare full updates with frozen-base LoRA and QLoRA strategies.

    Active parts: Base model + tokenizer, Full-parameter SFT, LoRA: frozen base + adapters, QLoRA: quantized base + adapters

  3. 03Train only on the training partition

    Feed the same authorized training partition to the chosen candidate strategies without exposing held-out cases.

    Active parts: Deduplicate + split + baseline, Full-parameter SFT, LoRA: frozen base + adapters, QLoRA: quantized base + adapters

  4. 04Evaluate candidates on held-out data

    Measure each artifact against the unchanged baseline and defined quality and safety gates.

    Active parts: Full-parameter SFT, LoRA: frozen base + adapters, QLoRA: quantized base + adapters, Held-out quality + safety gate

  5. 05Register compatible artifacts

    Register only an approved candidate with complete base, tokenizer and runtime compatibility metadata.

    Active parts: Held-out quality + safety gate, Versioned model or adapter

  6. 06Deploy an approved package

    Load the registered full model or exact base-and-adapter package in a compatible runtime.

    Active parts: Versioned model or adapter, Compatible inference runtime

Connections

  • Clean examplesAuthorized examples to Deduplicate + split + baselinedata
  • Train splitDeduplicate + split + baseline to Full-parameter SFTdata
  • Train splitDeduplicate + split + baseline to LoRA: frozen base + adaptersdata
  • Train splitDeduplicate + split + baseline to QLoRA: quantized base + adaptersdata
  • Trainable base parametersBase model + tokenizer to Full-parameter SFTdata
  • Frozen base parametersBase model + tokenizer to LoRA: frozen base + adaptersdata
  • Frozen quantized baseBase model + tokenizer to QLoRA: quantized base + adaptersdata
  • Updated full modelFull-parameter SFT to Held-out quality + safety gatedata
  • Adapter candidateLoRA: frozen base + adapters to Held-out quality + safety gatedata
  • Adapter candidateQLoRA: quantized base + adapters to Held-out quality + safety gatedata
  • Approved version + compatibilityHeld-out quality + safety gate to Versioned model or adaptercontrol
  • Model or base + adapterVersioned model or adapter to Compatible inference runtimecontrol

Components

Authorized examplesdata

Provides reviewed input-output examples with provenance, usage rights and sensitive-data handling defined.

Responsibilities

  • Preserve authorization and provenance for each example

Inputs

  • Approved task examples
  • Data handling rules

Outputs

  • Versioned example corpus

Risks

  • Unauthorized personal data
  • Poisoned or low-quality labels
Deduplicate + split + baselinedeterministic

Deduplicates before partitioning, fixes training and held-out membership and records an unchanged-model baseline.

Responsibilities

  • Prevent leakage and preserve a comparable baseline

Inputs

  • Versioned examples
  • Partition rules

Outputs

  • Training split
  • Held-out set
  • Baseline results

Risks

  • Near-duplicate leakage
  • Unrepresentative held-out cases
Base model + tokenizerdata

Pins the pretrained model revision and tokenizer required by training and serving.

Responsibilities

  • Supply immutable compatible training inputs

Inputs

  • Approved model revision
  • Tokenizer revision

Outputs

  • Versioned base package

Risks

  • Unreviewed model provenance
  • Tokenizer mismatch
Full-parameter SFTmodel

Runs supervised fine-tuning while allowing all selected base-model parameters to update.

Responsibilities

  • Produce a reproducible full-model candidate

Inputs

  • Trainable base parameters
  • Training split
  • SFT configuration

Outputs

  • Updated full model

Risks

  • High resource use
  • Catastrophic forgetting
LoRA: frozen base + adaptersmodel

Trains low-rank adapter parameters while keeping the pretrained base weights frozen.

Responsibilities

  • Produce a versioned adapter against a pinned base

Inputs

  • Frozen base
  • Training split
  • LoRA configuration

Outputs

  • LoRA adapter candidate

Risks

  • Insufficient adaptation capacity
  • Wrong target modules
QLoRA: quantized base + adaptersmodel

Backpropagates through a frozen quantized base into trainable low-rank adapters.

Responsibilities

  • Train adapters with a pinned quantization configuration

Inputs

  • Frozen quantized base
  • Training split
  • Adapter configuration

Outputs

  • QLoRA adapter candidate

Risks

  • Quantization-sensitive quality loss
  • Runtime incompatibility
Held-out quality + safety gatedeterministic

Evaluates candidates on unseen cases and rejects any version that fails defined quality or safety criteria.

Responsibilities

  • Compare candidates with the baseline and enforce release thresholds

Inputs

  • Held-out set
  • Full-model candidate
  • Adapter candidates

Outputs

  • Approval or rejection decision
  • Evaluation report

Risks

  • Test contamination
  • Thresholds that hide critical failures
Versioned model or adapterdata

Stores only approved artifacts with lineage and explicit base, tokenizer and serving compatibility.

Responsibilities

  • Preserve provenance, versions and rollback references

Inputs

  • Approved artifact
  • Evaluation report
  • Compatibility manifest

Outputs

  • Releaseable model or adapter package

Risks

  • Incomplete lineage
  • Ambiguous compatibility
Compatible inference runtimemodel

Loads the approved full model or the exact base-and-adapter combination for inference.

Responsibilities

  • Serve the registered package and expose its version

Inputs

  • Registered model or base plus adapter
  • Runtime configuration

Outputs

  • Versioned inference responses

Risks

  • Loading the wrong base
  • Serving drift from evaluated settings

Scenario reference

Full-parameter SFT

Full-parameter SFT updates the base parameters.

  1. 01Train and release a full model

    Prepare data, update the pinned base, pass evaluation and deploy the registered full artifact.

    Active parts: Authorized examples, Deduplicate + split + baseline, Base model + tokenizer, Full-parameter SFT, Held-out quality + safety gate, Versioned model or adapter, Compatible inference runtime

LoRA

Train low-rank adapters while the base remains frozen.

  1. 01Train and release a LoRA adapter

    Train an adapter against the frozen pinned base, evaluate it and deploy the registered compatible pair.

    Active parts: Authorized examples, Deduplicate + split + baseline, Base model + tokenizer, LoRA: frozen base + adapters, Held-out quality + safety gate, Versioned model or adapter, Compatible inference runtime

QLoRA

Train adapters through a frozen quantized base; the quantized base is not trainable.

  1. 01Train and release a QLoRA adapter

    Train adapters through the frozen quantized base, evaluate the candidate and deploy only the compatible package.

    Active parts: Authorized examples, Deduplicate + split + baseline, Base model + tokenizer, QLoRA: quantized base + adapters, Held-out quality + safety gate, Versioned model or adapter, Compatible inference runtime

Design Decisions

  • Version dataset provenance, split membership and deduplication rules.
  • Choose full updates, LoRA or QLoRA through measured quality and resource constraints.
  • Register the base revision, tokenizer, adapter configuration and runtime compatibility together.
  • Require held-out quality and safety results before promotion.

Risks & Trade-offs

Training data can contain sensitive material, licensing restrictions or poisoned examples. Leakage makes evaluation misleading. PEFT reduces trainable state but does not guarantee equal quality for every task. Quantization changes memory and numerical behavior, while an incompatible runtime can load an adapter incorrectly or not at all.

When to Use / Not Use

Use a fine-tuning pipeline when a stable, repeated behavior cannot be achieved reliably with prompting and representative authorized data exists. Do not train to store frequently changing facts, when the held-out set is too small to support a release decision, or when operational ownership for versioning and rollback is missing.

Sources