Как закрепить версию модели Mistral и перестать ловить неожиданные изменения

Имя mistral-large-latest — это указатель. Оно резолвится в конкретный датированный снапшот, и Mistral двигает указатель каждый раз, когда выходит новая версия. Проблема в том, что обновление происходит тогда, когда решил провайдер, а не ты.

Зачем вообще пинить? Алиас удобен для прототипа, но в проде он создаёт проблемы. И нет, дело не в одном «вдруг что-то сломается».

• Нельзя воспроизвести результат. Баг-репорт за прошлый месяц ссылается на модель, которой уже нет за этим именем. Ты шлёшь тот же random_seed — и получаешь другой ответ, потому что seed фиксирует сэмплер, а не веса.
• Нельзя атрибуцировать регрессию. Качество упало, а изменившихся переменных три: промпт, ретривал и незаметно обновившаяся модель. Без пина не найдёшь виноватого.
• Нельзя выбрать момент риска. Новый снапшот меняет стиль форматирования, длину ответов, отказы и склонность звать инструменты. Это не баг, но это ломает промпты, настроенные под старую версию. С алиасом такое прилетает в невыбранный тобой вторник.
• Плюс меньшая цена: запиненная модель не становится лучше. Снапшоты выходят с улучшениями, и через восемнадцать месяцев ты платишь те же деньги за модель хуже доступной.

Сравнение: алиас или пин

Вывод из таблицы: пин — не вечный режим, а способ контролировать, когда именно ты принимаешь изменения.

Шаг 1. Узнай, на каком снапшоте ты уже работаешь

Не выбирай версию из списка вслепую. Сначала посмотри, какая версия обслуживала твой трафик всё это время. Она — правильная цель для пина, и её не надо заново валидировать.

Вызови эндпоинт моделей со своим API-ключом. В ответе у каждой датированной модели есть поле aliases. Найди строку с алиасом, который ты используешь, и посмотри id — он будет вида mistral-large-2411, где цифры — год и месяц релиза. Это твой кандидат на пин.

Заодно проверь поле deprecation. Если у этого снапшота уже объявлен вывод из эксплуатации, лучше пинить более новую версию и тестировать сейчас, а не через месяц остаться без модели.

Шаг 2. Замени алиас на id снапшота

Положи id в конфиг, а не в вызовы API. Рядом с ним оставь комментарий: когда запинили и почему. Через четыре месяца никто не вспомнит.

MISTRAL_MODEL=mistral-large-2411
# Pinned 2026-08-11. Prompt suite validated against this snapshot.

Читай переменную один раз на границе приложения и передавай дальше. Так изменение займёт одну строчку и деплой, а не поиск по всему коду.

Перед тем как закончить, поищи по репозиторию все вхождения «-latest». Одна забытая ссылка в скрипте оценки или фоновой задаче обнулит весь пин. И это будет именно та ссылка, которая даст самый странный результат.

Шаг 3. Проверь, что пин реально работает

Пина, который молча не действует, хуже, чем отсутствие пина, — потому что ты в него веришь. Поэтому проверь поле model в живом ответе. Напиши тест, который вызывает API и проверяет, что запрошенный id совпадает с тем, что вернул сервер. И кроме того, логируй id модели в каждый запрос вместе с количеством токенов. Через шесть недель, когда кто-то спросит, почему ответы изменились, лог даст ответ: менялась ли модель.

Учти: совпадение строки в ответе — деталь реализации провайдера, а не обещание. Если поле model вдруг не совпадает, проверяй эндпоинт моделей: маппинг алиасов там — источник истины.

Шаг 4. Узнай о выводе модели заранее

Пин безопасен только когда известно, когда он закончится. Mistral публикует даты вывода, эндпоинт моделей их отдаёт. Напиши небольшую проверку, которая падает, если до вывода осталось меньше 60 дней или модель исчезла из списка.

Запускай её по расписанию — ночью или еженедельно в CI. Сервис, который не деплоился два месяца, — именно тот, кого вывод модели застанет врасплох.

Когда проверка предупредила, переезжай осознанно: подними staging на новом снапшоте, прогони промпты, сравни длину ответов, форматирование и желание звать инструменты, и только потом двигай пин. Это полдня работы, которые ты запланировал.

Когда пин не нужен

Для прототипа и эксперимента алиас подходит. Если сломанный ответ — не катастрофа, можно не пинить. Пин добавляет одну операционную издержку: если снапшот отозван или временно недоступен, запросы будут падать, а не тихо деградировать на другую модель. Через шлюз с fallback-списком это лечится: основной остаётся пин, а в резерве — второй датированный снапшот. Тогда сбой превращается в залогированный фолбэк, а не в 5xx для пользователей.

Пин — это не способ остановить прогресс, а способ решать, когда ты готов к изменениям. Двигай его осознанно раз в несколько месяцев, следи за датами вывода и проверяй, что пин реально в силе. Тогда обновление модели перестанет быть сюрпризом.