Российские LLM 2026: GigaChat, YandexGPT, Salut и их ниши
Сравнивать отечественные модели с мировыми флагманами по общим бенчмаркам — занятие с предсказуемым результатом и небольшой пользой. Выбор в их пользу чаще определяется не качеством генерации, а тремя вещами: где физически обрабатываются данные, как оформлен договор и есть ли поддержка на русском языке с понятным SLA.
Если эти три пункта для вас не критичны, выбирайте по качеству на своих задачах. Если критичны хотя бы один — вопрос сравнения качества становится вторичным, и обсуждать надо применимость.
Где отечественные модели объективно сильны
| Область | Почему |
|---|---|
| Русский язык в бытовых и деловых текстах | Большая доля русскоязычных данных в обучении |
| Локальный контекст | Реалии, документооборот, форматы, принятые здесь |
| Интеграция с местными сервисами | Готовые связки с распространённой инфраструктурой |
| Юридическая определённость | Договор по знакомому праву, счета, закрывающие документы |
| Доступность | Нет вопросов с оплатой и блокировками |
Где ожидаемо слабее
- Сложный код. Разрыв с флагманами на нетривиальных задачах программирования заметен.
- Длинные рассуждения. Многошаговые задачи с накоплением ошибки.
- Английский и редкие языки. Не основной приоритет обучения.
- Длинный контекст. Заявленное окно и фактическое удержание деталей — разные вещи, проверяйте.
- Экосистема инструментов. Меньше готовых библиотек, примеров и решений типовых проблем.
Как проверить под свою задачу
Соберите 30 запросов из вашей реальной работы, разложив по типам: - 10 бытовых или деловых текстов на русском; - 5 задач на извлечение данных из ваших документов; - 5 задач на следование сложной инструкции с несколькими условиями; - 5 задач на предметную область, в которой вы работаете; - 5 заведомо трудных: длинный контекст, неоднозначность, требование признать незнание. Прогоните через отечественную модель и через привычную вам. Считайте отдельно: качество на русском, соблюдение формата, долю выдуманных фактов.
Третья метрика особенно важна для отраслевых задач: модель, уверенно называющая несуществующий пункт регламента, опаснее модели, которая честно говорит, что не знает.
Вопросы, которые надо задать до внедрения
- Где обрабатываются и хранятся запросы и что об этом сказано в договоре, а не в маркетинговых материалах.
- Используются ли ваши данные для обучения и есть ли режим, где не используются.
- Что с персональными данными — если в запросах они есть, это отдельный разговор с юристом, а не техническое решение.
- Гарантии доступности и лимиты. Что происходит при превышении, есть ли очередь, какой SLA.
- Как меняются версии. Предупреждают ли об обновлении модели и можно ли зафиксировать версию — для встроенного в процесс решения это критично.
- Стоимость на вашем объёме — по счётчику после тестовой сотни запросов, а не по прайсу.
Разумная схема для компании
Практика, которая себя оправдывает: разделить поток по чувствительности данных. Всё, что содержит персональные данные и коммерческую тайну, идёт в решение с понятной юрисдикцией и договором. Всё остальное — туда, где качество выше. Такая схема требует классификации запросов на входе, но эта классификация нужна и сама по себе — независимо от выбора модели.
Отдельно стоит держать в уме локальный запуск открытых моделей: для части задач он снимает вопрос юрисдикции полностью, а качество малых открытых моделей на узких задачах бывает достаточным. Сравнивать стоит все три варианта, а не два.
Конкретные версии, тарифы и результаты замеров здесь намеренно не приводятся — они меняются, а список вопросов к провайдеру и методика проверки на тридцати запросах остаются применимыми.