Applied GenAI Curriculum for AI PMs · Depth Layer · Architecture Thread
The finetuning landscape at a conceptual level — enough to interrogate a proposal's data requirements and maintenance burden, and make the finetune / don't-finetune call as a business decision.
Unit 05 gave you the reflex to reach for prompting and RAG before finetuning, and Unit 11 covered the data it demands. This unit is for the moment a team seriously proposes changing the model's weights anyway. You won't run the training. Your job is to interrogate the proposal — what data, how much, who maintains it — and make the call as a business decision. The good news: deciding whether to finetune is the hard part; the mechanics are comparatively straightforward.
Finetuning is transfer learning: take a base model that has some of what you need and refine it for your task. It works because the model already learned a huge amount during pre-training, so finetuning transfers that knowledge — the way knowing piano speeds up learning another instrument.
Any training after pre-training counts as finetuning, so it takes several forms. The ones an application team uses:
| Supervised finetuning | Train on labeled (instruction, response) pairs so the model learns to produce the outputs you want. The workhorse. |
| Preference finetuning | Train on comparisons (instruction, better response, worse response) to align outputs with human preference. |
| Continued pre-training | Self-supervised finetuning on cheap, unlabeled domain text (raw legal docs, a big Vietnamese corpus) before the expensive labeled step — a cost-saving warm-up. |
Once the decision is made, execution comes down to picking three things:
Same selection criteria as Unit 07 (size, license, benchmarks). Start with the strongest you can afford to prove feasibility, then work down.
Lightweight adapters (e.g. LoRA/PEFT) vs. full finetuning — a data-and-serving trade (below).
A finetuning API (upload data, get a model) vs. a self-run framework — a control-vs-convenience trade (below).
You don't need the math, just the trade. Adapter methods (LoRA and other PEFT techniques) train a small add-on rather than the whole model: cheaper, work with small datasets (a few hundred examples), run on modest hardware, and — importantly — let you serve many finetuned variants on one shared base model. Full finetuning updates everything: best ceiling on performance, but wants thousands+ of examples and means serving a separate full model each time.
| Adapter (LoRA / PEFT) | Full finetuning | |
|---|---|---|
| Data needed | Small — hundreds can work | Large — thousands and up |
| Performance | Good, usually below full | Highest ceiling |
| Serving | Many variants on one base model | A full model per variant |
| When | Start here; small data | Later, with lots of data |
Practical rule: start with an adapter method, move to full finetuning later if needed. With only a few hundred examples, full finetuning often won't even beat LoRA.
| Finetuning API | Upload data, pick a base model, get a finetuned model back. Quick and easy — but limited to supported base models and the knobs the API exposes. |
| Self-run framework | More flexibility and control (adapter or full), but you provision the compute — a mid-tier GPU suffices for adapters; full finetuning at scale needs distributed training. |
When engineers describe how they'll approach it, it usually maps to one of these:
Recognizing which path a proposal is on tells you what it's optimizing for — the progression path for finding the best cost/quality model, the distillation path for getting a small, cheap production model out of a strong one.
This is the unit's real job. When finetuning is on the table, these are the questions that turn it from an engineering enthusiasm into a business decision:
(instruction, response) pairs, at the quality and volume this method needs — or are we about to fund a big annotation project (Unit 11)? Base capability: can the model almost do this already (a good finetune) or not at all (a long shot)? Alternatives exhausted: did systematic prompting and RAG genuinely fail first (Unit 05)? Maintenance: who owns retraining and monitoring as base models improve — because a better base model can outrun our finetuned one, stranding the investment? Serving: one model or many variants (which points at adapter vs. full)?
Deliberately out of scope here: the memory/quantization and PEFT internals — those are the engineers' implementation depth, not yours. That closes the architecture thread. The remaining DEPTH units cover data (20), monitoring (21), and safety (22).