Mistral открыла публичное превью Mistral Large 4 — модели, которую в компании неофициально называют ML4 и «le Chonk». В API она доступна под идентификатором mistral-large-4. Одновременно вышел плагин llm-mistral 0.16 с поддержкой reasoning-моделей, а обсуждение релиза снова вывело на первый план вопрос, который копился давно: как вообще оценивать фронтирные модели, если привычные бенчмарки дают противоречивые результаты.
Что именно изменилось
Модель заявлена как нативно мультимодальная: она понимает изображения и, по формулировке анонса, «reasons powerfully across complex documents, charts, and natural images». В карточке модели среди возможностей перечислены ответы в заданной схеме, вызов функций, ответы на вопросы по загруженным документам, Chat Completions, пакетная обработка запросов одним заданием, агентные сценарии и работа с диалогами, а также встроенные инструменты, доступные модели без отдельной настройки. Часть из них доступна через /v1/chat/completions и /v1/conversations, пакетная обработка — через /v1/batch, агентные возможности — через /v1/agents.
По архитектуре это Mixture-of-Expertsархитектура, в которой на каждый запрос активируется лишь часть параметров модели. Документация приводит 52B активных параметров, 1.05T общих и визуальный энкодер на 1.6B; контекстное окно — 1M токенов. В анонсе размер округлён до 1 трлн параметров, а число активных параметров в разных источниках расходится: блог Mistral называет 52 миллиарда, отдельные публикации — 49 миллиардов.
Через Mistral API модель работает в одном из двух режимов рассуждений. В режиме «none» она отвечает сразу, без длинной цепочки рассуждений, в режиме «high» тратит больше вычислений на пошаговое обдумывание. В примере с генерацией изображений пеликанов вариант «high» выглядит лучше, но использовал 2 717 выходных токенов против 3 275 у «none».
Предыстория: как оценивали LLM раньше
До этого релиза в ходу было несколько подходов. Статические бенчмарки — неизменный набор вопросов или задач; динамические, такие как LMSYS Chatbot Arena и LiveBench, постоянно пополняются новыми вопросами, что поддерживает релевантность и предотвращает переобучение под конкретный датасет. Применялся и LLM-as-a-Judgeподход, при котором модель получает вопрос, эталон или критерии, ответ тестируемой системы и выставляет оценку. Для смысловых критериев использовали человека или LLM-судью, а всё, что надёжно проверяется кодом, проверяли кодом — детерминированная проверка дешевле, быстрее и воспроизводимее. Существовали и составные бенчмарки с множественными целями и методологиями: AlpacaEval, MT-bench, HELM, BIG-Bench Hard.
Почему это перестало работать
Претензии к этим методам накапливались независимо от конкретного релиза. Data contaminationситуация, когда тестовые примеры могли попасть в обучающую выборку снижает надёжность большинства бенчмарков: разработчики не всегда раскрывают полный состав обучающих данных, и проверить это затруднительно. Существующие методы оценки могут вводить в заблуждение из-за overfitting — модели Mistral и Phi провалили тест, а GPT-4, Claude, Gemini и Llama показали слабые результаты, что подчёркивает необходимость новых тестов, подобных GSM1k.
Отдельно — проблема самого судьи. LLM-as-a-Judge удобен и хорошо масштабируется, но судью тоже нужно тестировать: в исследовании Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena описаны позиционное смещение и предпочтение более подробных ответов. Если судья систематически расходится с людьми на определённом классе вопросов, проблема уже не в тестируемой модели. Эксперимент 2024 года с перестановкой вариантов ответов в тестах с множественным выбором показал заметный разброс качества моделей при такой перестановке.
Есть и более общие ограничения: большинство методов оценки ориентировано на фиксированные бенчмарк-даты и задачи, которые не всегда отражают сложности реального применения; тестирование в контролируемых условиях не всегда масштабируется на динамичные контексты; perplexityметрика, оценивающая, насколько уверенно модель предсказывает следующий фрагмент текста не отражает когерентность, релевантность или понимание контекста; human evaluation субъективен, подвержен искажениям и значительно дороже автоматизированных методов; автоматизированные оценки подвержены предсказуемым bias; метрики вроде BLEUметрика сравнения машинного перевода с эталоном по совпадению n-грамм или ROUGEметрика сравнения текстов с эталоном по перекрытию n-грамм и последовательностей требуют эталонных данных, получение которых затруднительно при множестве корректных ответов; существующие метрики часто не учитывают разнообразие и креативность генераций, а также атаки с использованием adversarial inputнамеренно подобранные входные данные, провоцирующие ошибку модели.
Что это меняет на практике
Для разработчиков переход означает работу с идентификатором mistral-large-4 и поддержку изображений, вызова функций и структурированных ответов. Плагин llm-mistral 0.16 добавляет поддержку reasoning-моделей, таких как Mistral Large 4. Стоимость стандартных API-запросов на момент анонса — $0,68 за миллион входных токенов и $2,09 за миллион выходных, чтение кэшированного входа — $0,07.
Но главный практический сдвиг — в организации оценки. Средняя метрика может скрывать критическую регрессию. В примере с промптами: Prompt v17 даёт Overall 82%, Finance 91%, Support 80%; Prompt v18 — Overall 86%, Finance 73%, Support 92%. Средняя оценка выросла с 82 до 86 процентов, и если смотреть только на неё, новая версия лучше. При этом финансовые сценарии просели с 91 до 73 процентов. Если Finance — критичный раздел продукта, такую версию выпускать нельзя.
Отсюда требования к CI/CD: зафиксированный baselineнабор эталонных результатов, с которым сравнивают новые версии, разбивка метрик по категориям и уровню риска, одинаковый regression dataset для сравниваемых версий и пороги, блокирующие релиз.
Если условия не выполнены, сборка не проходит дальше — только тогда evaluation начинает влиять на качество продукта, а не просто рисовать графики.
Цифры релиза
В слепой оценке качества кода с Surge AI модель заняла второе место среди пяти участников с 3,74 балла из пяти — выше GLM-5.3 и Kimi K3, но ниже Claude Opus 5 с 4,22 балла.
Ограничения и открытые вопросы
Mistral прямо признаёт, что обучение с подкреплением за этим превью ещё не завершено: «The reinforcement learning run behind this preview is still in flight, and the model is showing no signs of saturation». Веса обещают выпустить к концу месяца — в русскоязычном источнике срок конкретизирован как конец октября — вместе с деталями архитектуры, дополнительными бенчмарками и методологией пост-тренировки. До этого модель проходит red-teamingпроверку на устойчивость и безопасность силами внешних специалистов. Пока веса не выпущены, опубликованные результаты относятся именно к preview-версии.
Нерешёнными остаются и проблемы оценки как таковой: слабая обобщаемость на реальные сценарии и уязвимость к adversarial-атакам, которую существующие методы часто не учитывают, — вопрос устойчивости моделей остаётся актуальной областью исследований.
