[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"glossary-model-deprecation::ru":3,"gloss-cluster-model-deprecation::ru":23,"gloss-next-model-deprecation::ru":9},{"slug":4,"category":5,"name":6,"definition":7,"meta_desc":8,"faq":9,"schema_markup":9,"related":10},"model-deprecation","mlops","Прекращение поддержки модели (model deprecation)","Прекращение поддержки модели — это вывод поставщиком конкретной версии модели из эксплуатации, после которого запросы с её именем либо завершаются ошибкой, либо молча обслуживаются преемником. Это самый недооценённый операционный риск при разработке поверх размещённой модели, потому что это единственная зависимость в вашем стеке, способная измениться под вами без единого деплоя с вашей стороны. Передовые поставщики выпускают новые версии с периодичностью в месяцы и выводят старые по графику, измеряемому кварталами, так что у любой функции, выпущенной под именованный снимок модели, есть срок годности — записал его кто-нибудь или нет. Важны два сценария отказа. Громкий: наступает дата отключения, и эндпоинт возвращает ошибку — это неприятно, но очевидно и легко ловится на стенде. Тихий хуже: поставщик привязывает общее имя модели к более новому снимку, и тот же самый запрос попадает в другую модель с другим поведением. Промпты по-прежнему работают, агрегированные метрики оценки по-прежнему в норме, а конкретное форматирование или обработка краевых случаев, под которые вы подстраивались, уплывают, и при этом ничего не падает. Именно поэтому в проде фиксируют датированные идентификаторы моделей, а не плавающий алиас, и поэтому набор оценок, который можно перезапустить по требованию, ценнее разового ревью качества. О чём спросить поставщика, прежде чем на него завязываться: какой срок предупреждения о выводе версии зафиксирован; закреплено ли обязательство в договоре или только в блоге; как долго датированные снимки остаются доступны после выхода преемника; и что происходит с дообученной моделью, когда её базовая модель уходит — обычный ответ в том, что дообучение уходит вместе с ней и его нужно повторять, а значит календарь поставщика превращается в ваш инженерный бэклог.","Прекращение поддержки модели — вывод версии из эксплуатации. Громкий отказ даёт ошибку, тихий подменяет модель через алиас, и качество плывёт незаметно.",null,[11,14,17,20],{"slug":12,"name":13},"fallback-model","Резервная модель (fallback model)",{"slug":15,"name":16},"fine-tuning","Дообучение (Fine-Tuning)",{"slug":18,"name":19},"model-card","Карточка модели",{"slug":21,"name":22},"switching-cost","Стоимость переключения",[24,28,32,35,38,42,45,48,51,54,57,60],{"slug":25,"category":5,"name":26,"updated_at":27},"annotation-guidelines","Инструкции по разметке","2026-08-24T03:30:02+00:00",{"slug":29,"category":5,"name":30,"updated_at":31},"baseline-model","Базовая модель (baseline)","2026-08-24T02:46:38+00:00",{"slug":33,"category":5,"name":34,"updated_at":31},"batch-inference","Батч-инференс",{"slug":36,"category":5,"name":37,"updated_at":31},"canary-prompt","Канареечный промпт",{"slug":39,"category":5,"name":40,"updated_at":41},"champion-challenger","Чемпион–претендент (A\u002FB-тестирование моделей)","2026-08-24T02:46:37+00:00",{"slug":43,"category":5,"name":44,"updated_at":31},"class-imbalance","Дисбаланс классов",{"slug":46,"category":5,"name":47,"updated_at":31},"continuous-batching","Continuous Batching (непрерывная пакетная обработка)",{"slug":49,"category":5,"name":50,"updated_at":31},"cross-validation","Перекрёстная проверка",{"slug":52,"category":5,"name":53,"updated_at":31},"data-labeling","Разметка данных",{"slug":55,"category":5,"name":56,"updated_at":41},"drift-detection","Обнаружение дрейфа (Drift Detection)",{"slug":58,"category":5,"name":59,"updated_at":41},"eval-harness","Испытательный стенд оценки (Eval Harness)",{"slug":61,"category":5,"name":62,"updated_at":41},"experiment-tracking","Трекинг экспериментов (Experiment Tracking)"]