Generative AI / Advanced: evaluation, reliability, and accountability / Lesson 14

Adaptation and model selection

Choose between instructions, retrieval, parameter adaptation, and a simpler baseline using task evidence rather than assuming one technique solves every gap.

About 5 min readContent reviewed 2026-10-26

On this page

Lesson goals

Explain the assumptions and trust boundaries of adaptation and model selection.
Interpret both examples and distinguish offline fixture results from model or production evidence.
Diagnose the listed failures and justify the worked decisions while preserving task, data, permission, and uncertainty contracts.

Diagnose the missing capability first

An application can fail because evidence is absent, the output format is unclear, the task is outside the model’s capability, retrieval is wrong, or the policy layer is broken. Those causes need different interventions. Updating a prompt cannot fix a missing permission check, and parameter adaptation is not automatically the right way to supply frequently changing private facts. The first synthetic decision matrix compares intervention types without selecting a real model. Evaluate a simple deterministic or extractive baseline where the task permits it. A more complex model or training process needs a justified benefit, ownership, and a recoverable operating contract.

text Synthetic intervention comparison

observed gap                  candidate intervention to evaluate
missing current evidence      authorized retrieval and corpus repair
unclear output contract       prompt and deterministic validation
repeated task-style mismatch  task-specific adaptation with held-out tests
unsafe tool access            application authorization repair
simple exact calculation      deterministic function baseline

The table proposes hypotheses to evaluate, not universal prescriptions or measured improvements. A policy defect remains an application problem regardless of model size.

Separate context from parameter updates

In-context examples condition one inference interaction under the runtime’s state contract; fine-tuning changes selected model parameters through optimization. Retrieval can supply external evidence without necessarily changing those parameters. Each option has data, privacy, cost, versioning, and evaluation implications. The second offline exercise updates one coefficient of a tiny linear function. It demonstrates the concept of parameter adjustment, not language-model fine-tuning, representation learning, or a production training pipeline. Supplying a document to a conversational request is not equivalent to that update and should not be described as permanent model learning without evidence.

python Offline one-parameter adjustment

samples = [(1.0, 2.0), (2.0, 4.0)]
weight = 1.0
def loss(value):
    return sum((value * x - y) ** 2 for x, y in samples) / len(samples)
print(weight, loss(weight))
gradient = sum(2 * x * (weight * x - y) for x, y in samples) / len(samples)
weight -= 0.2 * gradient
print(round(weight, 3), round(loss(weight), 3))
print("one-coefficient toy update; not LLM training")

Expected output

1.0 2.5
2.0 0.0
one-coefficient toy update; not LLM training

The invented linear coefficient changes from one to two and fits two points. This is elementary arithmetic, not a neural model, fine-tuning recipe, or performance result.

Understand efficient adaptation as a scoped technique

Parameter-efficient approaches such as low-rank adaptation change a constrained parameterization rather than necessarily updating every original weight. Quantization and adaptation can affect memory, numerical behavior, throughput, and compatibility under a specific implementation. Primary research results apply to their tested settings, not every model, hardware device, or dataset. Keep tokenizer, base model, adapter, precision, preprocessing, and runtime identities together. An adapter trained for one base or revision cannot be assumed interchangeable with another. This course downloads no model or adapter and executes no real training or hardware benchmark.

Select with held-out task and risk evidence

Compare candidates on the same representative cases, source snapshot, access policy, output checks, and operating constraints. Include unsupported questions, rare languages, data privacy, tool denial, latency, and failure recovery rather than only a convenient public benchmark. Training and prompt development must not consume the protected evaluation set. Record data rights and sensitive information handling before adaptation. A smaller or older candidate may be sufficient, while a newly advertised model can introduce schema, cost, context, or security changes. No current vendor ranking, price, context limit, or universal best model is asserted here.

Plan migration and rollback of the whole system

A model change can require re-embedding, prompt revision, validator review, calibration, cache invalidation, and new release evidence. An old candidate may not remain compatible with a changed index or output contract. Keep the previous reviewed bundle and a scoped fallback or abstention policy rather than rolling back one model name alone. The offline examples are public arithmetic and editorial comparison only, with no provider call, credentials, dataset ingestion, external weights, or training service. Selection is successful when the chosen system meets the task and risk contract under maintained evidence, not when a single parameter count or leaderboard position looks impressive.

Common errors and fixes

Fine-tuning is chosen to repair an access violation

Why it happens: Application authority was treated as model behavior only.
How to fix it: Repair deterministic authorization and exposure controls.
Prevent it next time: Classify the failure stage before selecting adaptation.

An adapter is reused with an incompatible base

Why it happens: Model bundle identity was not recorded.
How to fix it: Verify base, adapter, tokenizer, precision, and runtime compatibility.
Prevent it next time: Version and test the whole candidate bundle.

A benchmark winner is assumed best for the workload

Why it happens: Task distribution and operating constraints were ignored.
How to fix it: Evaluate representative held-out cases and relevant risks.
Prevent it next time: Keep selection evidence and known limitations.

Check your understanding

1. The knowledge changes every day but the desired writing style is stable. Which interventions deserve separate consideration?

Show worked solution

Evaluate authorized fresh retrieval for changing evidence and prompt or adaptation methods for the stable behavior requirement. Do not assume retraining is necessary for every document update. Test both against the actual task and privacy contract.

2. Why is the two-point linear example not evidence that an LLM adaptation will generalize?