Tomcat 11: Lenient vs Strict Defaults, Side by Side
A side-by-side comparison of legacy Tomcat defaults and the strict defaults in Tomcat 11, showing which behaviors change and what to verify before you upgrade a Java web tier.
Loading post…
Stack OverflowSilu PandaProblem & solution
Why model versioning is not enough for production AI
Summary
Model versioning alone is insufficient for production AI because changes in inputs, preprocessing, prompts, retrieval, tool contracts, and serving settings can alter behavior independently. The post proposes a versioned release manifest that captures all interdependent components, including model revision, prompt revision, retrieval index revision, embedding revision, pipeline revision, and runtime revision covering token limits, batching, and timeouts. This manifest enables atomic release testing and rollback, with an evaluation gate that tests the full retrieval-generation path using deterministic checks and semantic rubrics on a versioned dataset. Practical steps include canary deployments that compare candidate and control signals, with explicit stop conditions and rollback procedures that restore compatible dependencies rather than just older model weights. The post concludes that the smallest useful implementation is a manifest, evaluation job, load test, release-aware traces, and a rehearsed rollback, and asks whether the on-call engineer can identify and restore a compatible known-good version.
Context
Production AI applications, particularly retrieval-augmented generation systems, require managing dependencies beyond model weights, including prompts, retrieval indices, and serving configurations.
Approach / What changed
Use a versioned release manifest that captures all interdependent components (model, prompt, retrieval index, runtime config) and an evaluation gate that tests the full retrieval-generation path with deterministic checks and semantic rubrics before promoting a release.
Takeaways
A model version alone is insufficient; changes in preprocessing, prompts, retrieval, tool contracts, and serving settings can independently alter behavior.
A release manifest should include references to all components (model, prompt, retrieval index, runtime config) and be tested as a unit.
Rollback must restore compatible dependencies, not just older model weights; historical snapshots must honor current access revocations.
FAQ
What components should a release manifest include?
It should include app revision, model revision, prompt revision, retrieval index revision, embedding revision, pipeline revision, runtime revision, and evaluation suite, each resolving to retained artifacts.
How should an evaluation gate test a generative AI release?
It should test the full path (retrieval, generation, output validation) with deterministic checks (schema, tool arguments, citations) and semantic rubrics, using a versioned dataset that includes ordinary questions, failures, ambiguous requests, and authorization boundaries.
What is a practical starting point for reliable AI infrastructure?
A versioned release manifest, a meaningful evaluation gate, and a tested rollback path, without requiring a bigger platform.
Source and freshness
- Source
- stackoverflow.blog
- Published
- Added to Yomu
Summaries are generated from the original by a language model. Check the original before relying on it.
See the idea
Visual explainers
Keep reading
Related reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
The best engineering reads, once a week
One useful email. Unsubscribe anytime.