Rules, discriminative models, generative models

There are three ways to put behaviour into software. The table on the slide compares them on where the behaviour comes from, what the component models, how you test it, and how it fails. The last two columns are the ones that reach production.

Rules

An expert writes the logic. The same input gives the same output, exact asserts work, and every wrong answer traces back to one rule. Rules are brittle on cases nobody wrote down, and they fail loudly, which is a feature. An eligibility rules engine is the typical example.

Discriminative models

A discriminative model learns P(y | x), the probability of a label given an input: a fraud score, a spam score, a document class. You test it on a held-out set, then you monitor it, because its failure is silent. When live traffic drifts away from the training data, accuracy decays and nothing throws. Watch the input distribution and the score distribution after launch, not only at launch.

Generative models

A pretrained language model learns P(x), the probability of the data itself, factored into next-token probabilities, each conditioned on the tokens before it. Output is sampled, so it can change between runs and between model versions.

Post-training is where instruction following comes from. In the InstructGPT work, human raters preferred the outputs of a 1.3 billion parameter post-trained model over the 175 billion parameter GPT-3 (Ouyang et al., 2022). Your prompt is the last layer of that stack. The failure mode is plausible but wrong, so you test with graded evals first and with sampled review of live output after.

Build or train

The order of work has changed. Prompt a model first and you have a baseline with no training labels. Once volume and labels justify it, train a small classifier and compare the two on one test set for accuracy and cost per call. Many classification tasks end up on the small model. The prompted baseline is a day of work rather than a quarter.

Where it goes wrong

A suite of exact-match snapshot tests written against a sampled model. It passes for months, then fails in full on the first model upgrade, and nobody can tell a real regression from a rephrasing.

What to do

• Validate the structure of every generated response in code, on every call.
• Gate releases on eval scores, not on a green snapshot run.
• Baseline with a prompted model before you train anything.