Continuous Post-Training (2025) › Limitations
History of Language AIAll chapters Continuous Post-Training (2025) › LimitationsOne section · Sections in this chapter6 / 8 ↓
Reading tools Definitions & inline links
Choose your expertise level to adjust how many terms are explained. Beginners see more tooltips, experts see fewer to maintain reading flow. Hover over underlined terms for instant definitions.
Article links
Make inline references clickable
The first limitation is regression risk. Evaluations sample behavior; they cannot prove that every unaffected capability stayed fixed. More releases create more chances for interactions between updates, especially after adapters are merged or composed.
The second is provenance. Training from deployment feedback can reproduce private data or reinforce the preferences of whichever users generate the most logs. Removing identifiers is not enough if an example itself contains sensitive context.
The third is operational cost. PEFT reduces training and storage costs, but a reliable pipeline still needs dataset review, reproducible jobs, evaluation capacity, version tracking, rollout controls, and monitoring. The surrounding system can cost more engineering time than the adapter run.
Repeated updates also fragment a model fleet. If customers pin versions or adapters differ by application, the organization must know which base and which updates served every response. That record is necessary for incident analysis.
Finally, an incremental update cannot change the base architecture. Large domain shifts may expose tokenizer, context-window, or objective limitations that require a new base model. Periodic consolidation or full retraining may also be simpler than maintaining a long chain of interacting adapters.