Как выбрать модель ИИ (AI) для бизнеса: YandexGPT, GigaChat или зарубежные

С какой задачи начинать выбор языковой модели

Языковая модель — это программа, которая работает с текстом: читает запрос, учитывает переданные ей материалы и формирует ответ. YandexGPT, GigaChat, OpenAI, Claude и Gemini — это разные семейства таких моделей, и у каждого поставщика свои условия подключения, тарифы и ограничения.

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

Прежде чем сравнивать модели, ответьте на вопросы: какой результат вы хотите получить, какие данные модель будет видеть, кто проверяет её ответы и что происходит, если она ошиблась. Эти ответы сразу отсекают часть вариантов и избавляют от лишних сравнений.

YandexGPT и GigaChat для бизнеса или зарубежные модели

Вопрос «российская модель или зарубежная» на практике распадается на несколько проверяемых критериев. Пока их не проверили, фразы вроде «YandexGPT точнее» или «Claude удобнее» остаются мнениями, а не основанием для решения. Характеристики моделей, их цены, лимиты и версии меняются, поэтому сравнивать нужно на своих задачах и по актуальным условиям поставщика.

Российские модели для бизнеса — YandexGPT и GigaChat — стоит включать в сравнение наравне с OpenAI, Claude и Gemini. Ниже критерии, которые компания может проверить самостоятельно. Каждый из них разобран в следующих разделах. На практике для разных процессов нередко подходят разные модели, и это нормально.

• Данные: где обрабатываются запросы, хранит ли их поставщик и допустимо ли передавать ему ваши материалы.
• Качество: как модель справляется с вашими реальными примерами, включая сложные и нестандартные.
• Стоимость: из чего складывается оплата и как она меняется при росте нагрузки.
• Развёртывание: можно ли запустить модель в своей инфраструктуре или согласованном облаке.
• Зависимость: насколько тяжело перейти на другую модель, если условия изменятся.
• Подключение: как оплачивать сервис и устраивают ли его условия ваших юристов и финансистов.

Данные и персональные данные: что проверить в первую очередь

Это самый жёсткий фильтр: он может исключить модель независимо от её качества. Сначала выясните, какие данные модель будет получать. Если в запросах есть фамилии, телефоны, паспортные или иные сведения о людях, это персональные данные, и на их обработку распространяется 152-ФЗ.

Дальше нужны ответы поставщика и вашего юриста. Условия работы с данными у разных поставщиков отличаются и меняются, поэтому опирайтесь на актуальные документы, а не на пересказы. Если передача данных внешнему сервису вызывает сомнения, есть два пути: обезличить данные до отправки в модель или запускать модель в закрытом контуре.

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

• Где физически обрабатываются и хранятся запросы и ответы?
• Используются ли ваши данные для дообучения моделей поставщика?
• Как долго хранятся журналы запросов и можно ли их отключить или удалить?
• Какие договорные условия и ответственность предусмотрены при обработке персональных данных?
• Можно ли убрать персональные данные из запроса до отправки — например, обезличиванием?

Как проверить качество модели на своих задачах

Рейтинги и демонстрации показывают, как модель справляется с чужими задачами. Ваши обращения, договоры и регламенты могут вести себя иначе: специфическая терминология, сокращения, ошибки в исходных данных. Поэтому проверка на своих примерах — главный этап выбора.

Типичные ошибки: выбирать по одному удачному диалогу, проверять только лёгкие примеры, оценивать «на глаз» без критерия и не продумывать, что делает человек, когда модель ошиблась. Ошибки модели полностью не исчезают, поэтому в процессе нужны контроль человеком и журнал ответов. Порядок проверки:

• Соберите реальные примеры — обращения, документы, вопросы к базе знаний — и при необходимости обезличьте их.
• Включите не только типовые случаи, но и редкие: пустые поля, нестандартные формулировки, противоречивые данные.
• Опишите критерий правильного ответа до проверки, а не после неё.
• Прогоните один и тот же набор через несколько моделей на одинаковых условиях.
• Попросите сотрудников, знающих процесс, оценить результаты, не сообщая, какая модель что ответила.
• Отдельно изучите ошибки: какие они, насколько опасны и можно ли их поймать правилом или проверкой человека.
• Повторяйте проверку при смене версии модели или условий поставщика.

Стоимость и развёртывание: что считать кроме цены запроса

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

Отдельный вопрос — где работает модель. Возможны варианты: сервис поставщика по API, российское облако или ваша собственная инфраструктура. Чем выше требования к данным, тем чаще рассматривают закрытый контур, но он требует серверов, мониторинга и людей, которые это сопровождают. Размещение внутри своей инфраструктуры возможно не для каждой модели: уточняйте у поставщика, предоставляется ли такая возможность и на каких условиях. В расчёт стоит включить:

• вызовы к модели при текущей и ожидаемой нагрузке;
• инфраструктуру: собственные серверы или облако;
• интеграции с 1С, CRM и другими рабочими системами;
• проверку качества и доработку при смене версий модели;
• поддержку и мониторинг после запуска.

Как не зависеть от одного поставщика: модель должна заменяться

Условия поставщиков, тарифы, доступность и сами модели меняются. Если решение жёстко привязано к одной модели, любое изменение превращается в переделку всей системы. Поэтому разумно сразу проектировать так, чтобы модель была заменяемым компонентом.

На практике это несколько решений. Между вашими системами и моделью стоит отдельный слой, который отвечает за обращение к ней: сменить поставщика — значит поправить этот слой, а не весь продукт. Инструкции модели (промпты), правила и справочники хранятся у вас, а не внутри сервиса поставщика. Есть набор тестовых примеров, который можно прогнать на новой модели и сравнить результат с прежним. Работа модели логируется, чтобы видеть, что изменилось после замены.

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

• Как устроена замена модели и что придётся переписывать при смене поставщика?
• Кому принадлежат промпты, правила, конфигурации и дообученные веса и что вы получите по договору?
• На каких данных вы проверите качество и по какому критерию примете результат?
• Где будет работать решение и как учтены требования 152-ФЗ?
• Что входит в постоянные расходы после запуска?
• Как организованы контроль человеком и журнал ответов модели?

Как мы подходим к выбору модели

Мы работаем с OpenAI, Claude, Gemini, YandexGPT и GigaChat и подбираем модель под задачу и требования к данным, а не наоборот. Начинаем с бесплатного разбора одного вашего процесса: за 3–5 рабочих дней готовим письменный документ с картой процесса, границами решения, критерием приёмки и оценкой объёма работ.

Если задача оказывается не для AI, пишем об этом прямо: часть задач дешевле закрыть регламентом или готовым сервисом. Если AI подходит, делаем первый прототип на ваших данных — от 3 недель — и сравниваем модели на ваших примерах. Результат принимаем по критерию, который фиксируем письменно до начала работ.

Решение разворачиваем в вашей инфраструктуре или российском облаке — выбор за вами — с учётом требований 152-ФЗ. После запуска остаёмся с решением: мониторинг, разбор инцидентов и доработки, когда меняются процесс или условия по модели. Режим поддержки фиксируется договором.