Continuous improvement: the four loops

The syllabus asks for continuous improvement "including large language
model-as-a-judge frameworks, synthetic data generation, semantic optimization loops,
and user feedback loops". Four mechanisms, and they are not equally informative.

The four

LLM-as-a-judge. A model scores outputs at scale. Cheap, consistent, and wrong
in its own consistent way — which is the important caveat. A judge that
systematically over-rewards fluent answers will do so on every case, and the
resulting scores will look stable and reliable while being systematically off.
Calibrate it against human judgement on a sample, and re-calibrate when you change
the judge model.

Synthetic data generation. Two distinct uses, and it is worth keeping them
apart. One: fill gaps in the evaluation set where you have no real examples.
Two: generate adversarial cases to test guardrails — attacks you have not
received yet.

Semantic optimization loops. Systematically improving prompts and retrieval
against measured outcomes rather than against intuition.

User feedback loops. Where real signal enters the system.

Feedback, ranked by what it actually tells you

Not all feedback is equal, and the ordering is worth internalising because most
teams invest in it backwards.

Overrides. A human changed the answer. This is a labelled expert correction,
produced continuously, at no marginal cost, on exactly the cases where the system
was wrong. It is the best data you will ever get and most teams discard it.

Escalations. The agent gave up. Tells you where the real boundary of its
competence is, as opposed to where you designed it to be.

Re-asks. The user rephrased and asked again. The first answer failed silently —
no complaint, no thumbs-down, just a person quietly working around your system.

Thumbs-down. Least informative, and — in this guide's judgement rather than
Microsoft's — the one most teams build first. It tells you someone was unhappy and
almost nothing about why.

Testing guardrails with synthetic data

The second use of synthetic data, and it deserves its own treatment because you
cannot test defences against attacks you have not received.

Generate the adversarial set — injection attempts, jailbreaks, boundary cases,
domain-specific prohibited requests.

Include the near-misses. Legitimate requests that resemble prohibited ones.
This is the part that gets left out, and without it you are only measuring half the
system.

Version it and re-run it on every change. Guardrails regress silently — a prompt
change can quietly unblock something that used to be caught, and nothing will tell
you.

The trap

False-positive rate belongs beside every guardrail metric.

An Attack Success Rate of zero, achieved by refusing anything that looks
faintly unusual, is not a safe system. It is a broken one that scores well — and it
will show up in your monitoring as a rising refusal rate that somebody explains away
as caution.

A guardrail that blocks everything is not a guardrail. It is an outage with good
intentions.