Выбор модели стал отдельной архитектурной задачей. Команды сравнивают Kimi, Qwen, DeepSeek и другие LLM не в вакууме, а в связке с задержкой, стоимостью токена, длиной контекста, качеством на русском языке и политиками размещения данных.
Этот материал — практический каркас решения: как не купить «самую умную» модель там, где хватает быстрой и дешёвой, и как переключать маршруты без переписывания приложений через AI Gateway. Актуальный список смотрите в каталоге моделей.
Сначала класс задачи, потом бренд модели
Разделите нагрузку на типы: короткая классификация, генерация ответов клиенту, разбор длинных документов, код, RAG-ответы со ссылками, агентные сценарии с инструментами. Для каждого типа свои требования к качеству и допустимой цене ошибки.
Зафиксируйте SLA по latency и бюджет на 1000 успешных операций. Без этих рамок сравнение моделей превращается в субъективные демо.
Составьте матрицу «класс задачи → must-have свойства»: формат JSON, длина контекста, устойчивость к jailbreak, качество цитирования, стоимость. Уже на этом шаге отсеивается половина кандидатов.
- Классификация / извлечение полей — приоритет стабильности и цены
- Диалог с клиентом — тон, безопасность, отказ от выдумок
- Длинные документы — контекст, структура, цитирование
- Код и SQL — точность, тестируемость, политика секретов
Kimi: когда смотреть в сторону длинного контекста
Kimi часто рассматривают для задач с большим объёмом входного текста: пакеты документов, длинные треды переписки, многостраничные регламенты. В корпоративном контуре это полезно для юридического разбора, внутренних расследований и подготовки саммари по «толстым» материалам.
Проверяйте на ваших файлах: не только «влезло ли в контекст», но и сохраняется ли внимание к нужным разделам в середине документа. Длинный контекст не отменяет хороший retrieval — см. корпоративный RAG.
Для пилота заложите кейсы с «иголкой в стоге сена»: факт в середине длинного PDF, противоречие между разделами, необходимость сослаться на конкретный пункт. Именно они отличают полезный длинный контекст от маркетингового.
Qwen: универсальный рабочий конь для многих бизнес-сценариев
Линейка Qwen часто хорошо показывает себя как универсальный вариант для ассистентов сотрудника, генерации черновиков, поддержки в service desk и контакт-центре. Важно гонять eval на русском языке и на ваших шаблонах ответов.
Для операторских подсказок критичны управляемость формата (JSON/поля CRM) и устойчивость к провокациям пользователя. Связка с политиками шлюза обязательна.
Проверьте поведение на tone of voice: отказ от запрещённых обещаний, корректные дисклеймеры, эскалация вместо выдуманной компенсации клиенту.
DeepSeek: сильная сторона — рассуждение и цена/качество
DeepSeek часто выбирают там, где нужны более глубокие рассуждения, разбор многошаговых задач, код и аналитические цепочки при контроле бюджета. На пилоте сравните не только «красивость» ответа, но и стабильность структуры и число галлюцинаций на вашем домене.
Для финансово чувствительных сценариев закладывайте обязательную проверку человеком или правилами до действия в учётной системе.
Отдельно измерьте стоимость достижения целевого качества: иногда более «дорогая» модель оказывается дешевле за счёт меньшего числа ретраев и правок оператора.
Как провести корпоративный bake-off
Сделайте одинаковый прогон 3–5 моделей на одном наборе кейсов. Оценивайте слепым методом: эксперт не знает, какая модель ответила. Считайте стоимость и p95 latency параллельно с качеством.
Фиксируйте версию промпта, температуру и параметры tool-calling. Иначе сравнение будет о промпт-инженерии, а не о моделях.
- 50–200 реальных промптов с эталоном
- Рубрика: точность, полнота, тон, безопасность, формат
- Стоимость на эталонный объём и прогноз на прод
- Поведение при отсутствии данных (должен отказываться, а не выдумывать)
- Совместимость с вашим tool-calling / JSON-схемами
Метрики выбора модели для совета директоров и ИТ
Бизнесу нужны понятные метрики, а не leaderboard. Переведите результаты bake-off в язык процессов.
- Доля ответов, принятых без правки оператором/агентом
- Стоимость 1000 успешных операций сценария
- p50/p95 latency в целевом канале
- Доля безопасных отказов vs галлюцинаций
- Трудозатраты на смену модели (если нет gateway — обычно высоки)
Маршрутизация вместо мономодели
Зрелая схема: классификатор сложности или правила на уровне gateway направляют запрос в подходящую модель. Простой FAQ — в экономичный маршрут; спорный юридический вопрос — в более сильный, возможно с RAG и human review.
Так вы получаете лучший TCO, не жертвуя качеством на критичных кейсах. Биллинг при этом должен показывать расход по маршрутам — см. AI-кредиты.
Начните с двух маршрутов: standard и premium. Уже это даёт 20–40% экономии на смешанной нагрузке без заметной потери качества на простых задачах.
Риски, которые нельзя игнорировать
Качество на общем бенчмарке не гарантирует качество на ваших договорах и заявках. Отдельно проверяйте утечки инструкций, устойчивость к jailbreak в клиентских каналах и работу DLP — материал по 152-ФЗ.
Фиксируйте в договоре с AIaaS-провайдером: запрет обучения на ваших данных, контур размещения, сроки хранения логов.
Риск «тихой деградации»: новый релиз модели меняет стиль ответа. Держите регрессионный eval и canary-трафик перед полным переключением.
Антипаттерны выбора LLM
Выбор по хайпу и бенчмаркам без своих кейсов. Одна модель на все контуры. Смена модели без gateway. Оптимизация только цены при падении CSAT. Игнорирование русского языка и доменной терминологии.
Не менее вредно «заморозить» выбор на год. Рынок обновляется быстрее вашего контрактного цикла — закладывайте процедуру пересмотра в эксплуатацию платформы.
Связь с продуктовыми сценариями
Для контакт-центра важны скорость и тон; для Document AI — извлечение полей и длинный контекст; для ITSM — точность по базе знаний и аккуратные отказы.
Не назначайте одну модель «чемпионом компании» на год. Пересматривайте маршруты раз в квартал по мере появления новых релизов в каталоге.
Чеклист перед промоушеном модели в prod
Даже если модель выиграла bake-off, промоушен в prod — отдельное решение. Ниже минимальные ворота качества и риска.
- Eval на доменных кейсах не хуже текущего чемпиона
- p95 latency укладывается в SLA канала
- Стоимость единицы результата приемлема для FinOps
- Пройдены тесты jailbreak/DLP для клиентских контуров
- Есть rollback-маршрут на предыдущую модель в gateway
- Canary на 5–10% трафика минимум несколько дней
Сравнение моделей: шаблон внутренней таблицы
Чтобы bake-off не растворился в мнениях, сведите результат к одной таблице для архитектурного комитета. Колонки должны быть одинаковы для всех кандидатов.
Минимальные колонки: качество (среднее по рубрике), доля критичных ошибок, p95 latency, стоимость 1000 операций, compliance-ограничения, готовность к tool-calling, рекомендация маршрута (standard/premium/reject).
Храните сырые ответы и оценки в репозитории eval. Через квартал вы сможете доказать, почему сменили маршрут, а не опираться на память участников демо.
Практический вывод
Выбирайте модель набором eval + стоимости + latency + compliance, а не по названию из новостей. Держите переключение на уровне платформы — это и есть смысл корпоративного AIaaS.
Начать можно с пилотного bake-off через платформу и единый API. Если нужна помощь с матрицей выбора под ваши сценарии — свяжитесь с AI Cloud.
Зафиксируйте в операционной модели: владелец маршрутов, календарь bake-off, пороги автопереключения и процедуру аварийного отката. Тогда каталог моделей становится активом, а не источником хаоса.
Частые вопросы
Нет. Для классификации и коротких ответов часто выгоднее экономичная модель; для длинного контекста и сложного рассуждения — более мощная. Оптимальная стратегия — маршрутизация через gateway.
Соберите набор реальных промптов из ваших процессов, зафиксируйте рубрику качества и стоимость. Публичные бенчмарки полезны как ориентир, но не заменяют корпоративный eval.
Минимум раз в квартал или при появлении нового релиза в каталоге, который обещает выигрыш по цене/качеству. Пересмотр — это повторный bake-off на том же eval, а не смена «по настроению».
Зависит от канала. В онлайн-диалоге оператора p95 latency критична; в ночном разборе документов можно пожертвовать скоростью ради точности. Фиксируйте SLA до сравнения моделей.