Британский AI Security Institute и американский Center for AI Standards and Innovation опубликовали результаты независимой оценки Kimi K3 — флагмана Moonshot AI — на задачах offensive cyber. Модель набрала 32% на ExploitBench, тогда как ведущие американские модели показывают 76%. При этом встроенные фильтры безопасности не заблокировали ни разработку эксплоитов, ни имитацию реальных атак.
Контекст
Moonshot AI — китайский стартап, чья серия Kimi набирает очки на стандартных бенчмарках — MMLU, coding, math — наравне с топовыми западными конкурентами. Именно это делает провал в кибер-оценке особенно резким: модель, которая «умная» по общим метрикам, оказывается вдвое слабее в специализированной задаче. ExploitBench — это не академическая синтетика. Он измеряет реальные offensive cyber способности: анализ уязвимостей, написание функционирующих эксплоитов, имитацию атак на тестовые системы.
Тестирование провели государственные регуляторы, а не академики и не маркетологи. AISI (Великобритания) и CAISI при NIST (США) смотрят на модели через призму национальной безопасности — что принципиально меняет вопрос: не «насколько умна модель», а «чем она опасна и что умеет на самом деле».
Параллельно с публикацией существуют обвинения в том, что Moonshot AI дистиллировал Kimi K3 с моделей Anthropic. Исследователи указывают: характерная слабость именно в кибер-домене хорошо объясняется именно этой гипотезой. Дистилляция копирует то, что есть в учителе — включая его пробелы.
Аналитика
Разрыв 32% vs 76% — двукратное отставание, не погрешность. Но важнее не сами цифры, а что за ними стоит. Если дистилляционная гипотеза верна, то Kimi K3 унаследовала от Anthropic не только способности, но и архитектурные паттерны — включая те области, где модель-учитель намеренно не обучалась на агрессивных кибер-задачах. Это не баг дистилляции, это её фундаментальное свойство: копируешь профиль способностей, а не только параметры.
Провал встроенных фильтров добавляет отдельный уровень. Модель не блокирует запросы на разработку эксплоитов — но и не выдаёт их качественно. Технически это «лучший» исход с точки зрения безопасности, но для регуляторов это тревожный сигнал: safety-дизайн несогласован. Либо блокируй — либо умей. Когда не блокируешь и не умеешь одновременно, значит, безопасность проектировалась не как первый приоритет.
Разрыв между высоким общим рейтингом и слабой domain-specific оценкой — системная проблема индустрии, а не отдельная история про одну модель.
Более широкий урок: MMLU, HumanEval, GPQA — плохие прокси для реальных возможностей в специализированных областях. Это знали давно, но публичные данные государственных регуляторов по конкретным моделям — редкость. Теперь есть прецедент, к которому будут апеллировать при оценке следующих релизов.
Кейсы применения в бизнесе
B2B SaaS с security-компонентом. Строите продукт с анализом уязвимостей, code review или автоматизацией пентеста — выбор модели критичен. История Kimi K3 показывает: топовая позиция в общем лидерборде не означает пригодности для domain-specific задачи. Перед интеграцией запустите собственный eval на сценариях вашего продукта. Разрыв в качестве ответов может быть двукратным — и вы лучше обнаружите это на тестах, чем на клиентском пайплайне.
Корпорация с legacy-инфраструктурой. Всё больше SOC-команд экспериментируют с AI-ассистентами для анализа инцидентов. Если модель встраивается в security operations — важно понимать её реальные возможности, а не маркетинговые бенчмарки. Дополнительно: фильтры безопасности у разных провайдеров ведут себя по-разному в corporate-контексте. Тестируйте отдельно — не доверяйте системному промпту как единственному барьеру.
SMB / локальный бизнес в КР и СНГ. Offensive cyber — не ваша тема, но паттерн «сильные общие бенчмарки, слабая специализация» применим шире. Выбирая AI для конкретного сценария — бухгалтерия, юридический анализ, клиентский сервис — запрашивайте у провайдеров domain-specific показатели. Красивые цифры в презентации и реальная точность в вашем кейсе — разные вещи.
Кейсы в личной жизни
Разработчик / security engineer. Используете AI для security research или CTF — разница между моделями реальна и измерима. Попробуйте запустить одну и ту же задачу на нескольких frontier-моделях: разрыв в качестве ответов будет очевиден без всяких бенчмарков. Это и есть личный ExploitBench.
Контент-мейкер и аналитик. Этот кейс — готовый материал для контента про AI-грамотность: «высокий общий рейтинг ≠ лучший инструмент для вашей задачи». Аудитория всё чаще задаёт правильный вопрос. Дайте им язык, чтобы его формулировать.
Студент / исследователь AI. Методология ExploitBench и государственные evaluation frameworks — хорошая база для понимания того, как проектируются domain-specific тесты. Публикации AISI и CAISI открыты. Навык чтения таких отчётов будет востребован в любой AI-роли — это не академика, это практика регуляторного мышления.
Как применить сегодня
- При выборе модели для конкретной задачи — ищите domain-specific бенчмарки, не MMLU. Для security: ExploitBench и публикации AISI/CAISI.
- Перед интеграцией AI в продукт с security-контекстом — запустите собственный eval на типичных сценариях. Не доверяйте позиции в общем лидерборде.
- Встроенные фильтры безопасности проверяйте вручную на граничных кейсах вашего продукта. Они часто не работают так, как написано в документации.
- Добавляйте независимый слой валидации поверх модели там, где ставки высоки — системный промпт не барьер, а рекомендация.
- Следите за публикациями AISI (Великобритания) и NIST/CAISI (США) — наиболее авторитетные источники независимых оценок frontier-моделей без маркетинговых фильтров.