模型會改變，系統不應因此出錯

Why model upgrades should be treated as releases, not configuration changes

Nothing in the code changed.

No new deployment. No new pull request. No failed build.

But on Monday morning, the order-intake workflow started creating tasks with the wrong priority. The extraction step still returned valid JSON. Every field was still there. The values were simply a little different from what they had been on Friday.

The reason was easy to find once someone looked: the application was calling a model alias, and the alias now pointed to a newer model.

The newer model was better on almost every benchmark. It was also better at following instructions. And that was the problem. It followed one ambiguous instruction in the prompt more literally than the old model had, and "urgent" stopped meaning what the business thought it meant.

This is a hypothetical example, but the pattern is real and increasingly common.

We spend a lot of time asking which model to choose.

We spend much less time asking what happens when that model changes.

And it will change.

The Model Is a Dependency You Don't Control

Most enterprise teams already know how to manage dependencies.

We pin library versions. We read release notes. We run tests before upgrading a database driver. We don't let a payment SDK update itself in production on a Sunday night.

But a hosted language model is often treated differently. It is configured, not versioned. A model name sits in an environment variable, and changing it feels like changing a timeout value.

It is not.

A model is one of the most behavior-heavy dependencies an application can have. It interprets input, makes classification decisions, chooses tools, and shapes what the user sees. A change to the model is a change to the logic of the system, even when no line of code moves.

And unlike most dependencies, you don't fully control its lifecycle:

• Providers release new versions on their own schedule.
• Aliases such as "latest" can move to a new model.
• Older versions are deprecated and eventually retired.
• Prices, rate limits, and context windows change.
• Safety behavior is adjusted between versions.

None of this is a criticism of model providers. It is simply how the ecosystem works.

The architectural question is not whether the model will change.

It is whether your system will notice.

A Better Model Can Still Break Your System

It is tempting to assume that a newer model is a safe upgrade. If it scores higher on reasoning, coding, and instruction following, what could go wrong?

Quite a lot.

Benchmarks measure general capability. Your system depends on specific behavior.

Those are not the same thing.

When a model changes, several things can change at the same time:

Notice that most of these failures are quiet.

The system does not crash. It returns a valid response that is slightly different. A priority is one level lower. A summary leaves out a detail the sales team relied on. An agent calls the CRM twice instead of once.

This is what makes model changes dangerous in enterprise software:

They rarely produce errors. They produce drift.

And drift is much harder to detect than an exception.

Pin the Model. Version the Behavior.

The first rule is simple: production should call a specific model version, not an alias.

An alias is convenient during experimentation. In production, it means someone else decides when your system's behavior changes.

But pinning the model is only half of the answer.

The behavior of an AI feature does not come from the model alone. It comes from a combination:

Model version
  + System prompt
  + Tool definitions
  + Output schema
  + Retrieval configuration
  + Model parameters
  = Behavior

Change any one of these, and you may change the result.

That is why I think of them as a single release unit. You could call it an AI configuration version. The name matters less than the discipline:

• Every production call can be traced to one configuration version.
• The configuration lives in source control, not in a dashboard someone edited last Tuesday.
• A prompt change goes through review, just like a code change.
• A model upgrade creates a new configuration version, not an edited one.
• The previous version remains available for rollback.

This sounds like process. It is actually observability.

When a support ticket says "the system started classifying invoices differently last week," the first question is: what changed?

If you can't answer that question in minutes, you don't really operate the system.

You are just running it.

An Upgrade Needs a Gate

In traditional software, the upgrade gate is the test suite. If the tests pass, we have reasonable confidence that behavior has not changed in ways we care about.

With AI features, the equivalent gate is an evaluation set.

Not a benchmark. Your own cases.

A useful regression set for a model upgrade usually contains:

• Golden cases: typical inputs with known correct outputs.
• Edge cases: ambiguous, incomplete, or unusual inputs that the business has already argued about.
• Production failures: every case that went wrong in production, once it has been understood and corrected.
• Safety cases: inputs that should be refused, escalated, or handled with restricted permissions.
• Contract cases: checks that the output still matches the schema, enums, and formats downstream systems expect.

The production failures are the most valuable part. Each one is a lesson the system has already paid for. Turning it into a test case means the next model upgrade has to pass the same exam.

The gate then becomes a comparison, not an absolute score:

Current configuration   → Run evaluation set → Baseline
Candidate configuration → Run evaluation set → Candidate results
Compare → Review differences → Decide

The interesting output is not the average score. It is the list of cases where the answers differ.

Some of those differences will be improvements. Some will be regressions. Some will be changes that are technically correct but break an assumption somewhere else in the business.

That last category is why a person who understands the process should review the differences, not just the dashboard.

Deterministic checks should come first: schema validity, allowed values, required fields, tool permissions. A model-based judge can help evaluate quality, but it should not be the only thing standing between a new model and production.

Make the Boundary Model-Independent

Evaluation tells you whether a new model behaves differently. Architecture determines how much that difference can hurt.

The most resilient AI systems I have seen share one property: the model's output is never trusted directly by the rest of the system.

There is a boundary between them:

Model
  ↓
Structured Output
  ↓
Schema Validation
  ↓
Business Rules
  ↓
Application Decision

When this boundary is strong, a model change has a limited blast radius. If the new model returns an unexpected enum value, validation rejects it. If it suggests an action the user is not allowed to take, authorization blocks it. If it produces a priority that conflicts with an explicit business rule, the rule wins.

When the boundary is weak, the model's behavior leaks directly into databases, ERP transactions, customer emails, and reports. Then every model upgrade is effectively a change to your business logic.

A few practical rules make the boundary stronger:

• Keep business rules in code, not in the prompt. A prompt can describe a rule. It should not be the only place the rule exists.
• Use closed sets wherever possible. A status field with five allowed values is easier to protect than free text.
• Normalize at the edge. Dates, currencies, and identifiers should be converted into canonical formats before they enter the system.
• Treat missing or uncertain output as a valid state. "Needs review" is better than a confident wrong answer.
• Avoid provider-specific behavior in core logic. If a workflow only works because one model happens to phrase things a certain way, it is fragile.

This is the same principle as any good integration design.

You don't let an external system write directly into your core tables.

A language model is, in practice, an external system.

Roll Out a Model Like a Release

Passing an evaluation set does not mean the new model is ready for all traffic. Evaluation sets are always smaller than reality.

The safer path is a staged rollout:

1. Offline evaluation. Run the candidate configuration against the regression set and review the differences.
2. Shadow mode. Send a copy of real production requests to the new configuration, but don't use its output. Compare results, cost, and latency.
3. Canary. Route a small percentage of real traffic, or one low-risk tenant, to the new configuration.
4. Gradual expansion. Increase traffic while watching the metrics that matter for the workflow, not just error rates.
5. Full rollout. Keep the previous configuration available until the new one has run through a full business cycle.

The metrics to watch are business metrics, not only technical ones: classification distributions, escalation rates, approval rejections, manual corrections, cost per successful outcome.

If the share of "urgent" tasks suddenly doubles after an upgrade, that is a signal, even if every request returned 200 OK.

Rollback should be a configuration switch, not an emergency deployment.

The strongest argument against all of this

There is a fair objection.

Models are improving quickly. Every month a team spends on an older model is a month without better reasoning, lower prices, or new capabilities. Heavy upgrade processes can make a team slow, and a slow team falls behind.

That is a real risk.

But the answer is not to skip the gate. It is to make the gate cheap.

A team with a good regression set, a versioned configuration, and a shadow pipeline can evaluate a new model in days. A team without them either upgrades blindly or doesn't upgrade at all.

Discipline is what makes fast upgrades possible.

The teams that move fastest are usually the ones that can tell, quickly, what a change actually changed.

A Practical Checklist

Before the next model upgrade, it is worth asking:

• Does production call a pinned model version, or an alias?
• Can every AI output be traced to a model, prompt, tool, and schema version?
• Are prompts and tool definitions in source control and reviewed?
• Do we have a regression set built from our own cases, including past production failures?
• Do we compare candidate and current results case by case, not just by average score?
• Are business rules enforced outside the model?
• Can we run a new model in shadow mode before it affects users?
• Do we monitor business metrics that would reveal drift?
• Can we roll back with a configuration change?
• Do we know when our current model version will be deprecated?

If most of the answers are no, the next upgrade is not a technical task.

It is a gamble.

Conclusion

For years, enterprise software has been built on the assumption that behavior changes when code changes.

AI breaks that assumption.

The behavior of an AI feature can change because a provider released a new version, because an alias moved, or because an old model was retired. The code stays the same. The system does not.

That doesn't mean we should avoid upgrades. Newer models are often genuinely better, and staying on an old model forever is its own kind of risk.

It means we should treat a model change for what it is: a change to the logic of the system.

Pin it. Version it. Test it against your own reality. Roll it out gradually. Keep the way back open.

The model will change.

The job of the architecture is to make sure the business doesn't change with it by accident.