Model behaviour
Detecting model drift and provider-driven quality regressions that infrastructure monitoring does not show.
Model behaviour can degrade while requests still return 200 in their normal latency range. Detecting that change requires a quality measure alongside infrastructure monitoring.
Sources of behaviour change
A provider update can change the model behind an existing name. The effect on specific prompts may be positive or negative, and notice may appear only in a changelog.
An updated retrieval corpus or chunking strategy changes the material available to the model.
A shared system prompt, policy header, or tool description may change in another team's service and affect dependent applications.
Input distribution changes when users ask new questions or phrase familiar questions differently. Existing tests may not cover those requests.
Evaluation suites
An evaluation suite is a fixed set of inputs with explicit output criteria. Run it on a schedule and for each relevant change.
Add cases from production failures during incident follow-up.
Version the suite with the prompt or application it tests so a coordinated change is visible in review.
Keep a change-gating suite small enough to run for every update. Larger suites can run on a schedule.
Score specific properties such as document citation, valid JSON, required refusals, or language constraints.
Run the suite against a pinned model version as a control. A divergence from the floating endpoint helps isolate a provider change.
Controlled model updates
An unversioned model name lets the provider choose the update time.
Pin the version where the provider supports it. Compare a new version with the current route in the evaluation suite before changing production.
Pinning can delay improvements and requires a plan for deprecation. Schedule version review and migration through the routing policy.
Production canaries
Send a small set of known inputs through the production path several times an hour and compare the results with expected properties. Use this canary to detect a step change between full evaluation runs.
A small canary has low model cost and works when production traffic is too sparse or varied for a stable trend. It can reveal provider incidents and configuration mistakes.
Failure mode O
The update that agreed with everyone
OpenAI shipped a GPT-4o update on April 25, 2025 that made the default model conspicuously sycophantic: it validated doubts, fed anger, and endorsed impulsive decisions. The rollback began three days later, and OpenAI published two postmortems explaining how it got through.
The skipped letter. Observe. The service stayed available while answer quality declined. Provider evals missed the change, so downstream teams need a pinned eval suite and canary.
OpenAI: Sycophancy in GPT-4o, what happened and what we're doing about it / OpenAI: Expanding on what we missed with sycophancy
Questions to ask your vendor, or your own team
- Does your application specify a model version, or just a model name?
- Do you have an eval suite? How many cases, and when did it last run?
- Does every production incident end with a new eval case?
- Would you find out about a quality regression from your own measurements or from a user?
- Who else can change a prompt your application depends on?
- What is your canary, and how often does it run?