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

Для разовой подготовки текста может хватить готового AI-чата. Для поиска по корпоративным документам понадобится другая архитектура. Для автоматической обработки заявок — интеграция с бизнес-системами. А сложный процесс иногда требует нескольких моделей, базы знаний и AI-агентов одновременно.

Сначала выбираем способ применения ИИ. И только затем — конкретную модель.

Сначала определите, что именно вы выбираете

Модель и AI-сервис — не одно и то же.

ChatGPT, Claude, Gemini, GigaChat и другие пользовательские продукты — это сервисы. Помимо самой модели там есть интерфейс, работа с файлами, поиск, память, проекты, инструменты, ограничения тарифа и другие функции.

Языковая модель — вычислительное ядро. К ней можно обращаться через готовый чат, API или собственную систему.

Но для бизнеса есть ещё один уровень выбора.

Компания может выбирать не только сервис или модель, но и целый класс решения:

• AI-чат для сотрудников;
• готовый специализированный AI-сервис;
• модель через API;
• AI-ассистента;
• AI-агента;
• корпоративный поиск и RAG;
• систему обработки документов;
• AI-автоматизацию процесса;
• индивидуальную систему, объединяющую несколько подходов.

Поэтому вопрос «какую нейросеть купить?» обычно появляется слишком рано.

Сначала стоит сформулировать, какую работу должен выполнять ИИ. Если пока непонятно даже это, полезнее сначала выбрать первую задачу для внедрения ИИ, а уже потом сравнивать технологии.

Какой ИИ может понадобиться бизнесу

Один и тот же пользовательский интерфейс с полем ввода может скрывать совершенно разные системы.

Например, если сотруднику нужно несколько раз в неделю анализировать письмо или готовить черновик ответа, отдельная разработка может вообще не потребоваться.

Если же ИИ должен получить заявку, определить её тип, проверить данные, обратиться в CRM, подготовить ответ, создать задачу и передать результат дальше, одного чата уже недостаточно.

Это уже архитектурная задача.

Именно здесь появляются AI-агенты для бизнеса и автоматизированные AI-системы.

Как выбрать ИИ под конкретную бизнес-задачу

Начинать удобнее не со списка моделей, а с нескольких типовых сценариев.

Для корпоративных документов отдельно стоит разобраться, как работает RAG. Здесь важна уже не только модель, но и качество поиска, структура базы знаний, актуальность источников и права доступа.

А если нужен не один сценарий, а расширенный список вариантов применения, на сайте есть отдельный материал: 48 бизнес-задач, которые уже можно отдать ИИ.

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

Когда готового AI-сервиса достаточно

Не каждый рабочий сценарий нужно превращать в проект по внедрению.

Готового AI-чата или специализированного сервиса обычно достаточно, если задача возникает нерегулярно, её выполняет один или несколько сотрудников, данные не нужно автоматически получать из внутренних систем, а результат всё равно проверяет человек.

Например, сотрудник может вручную:

• подготовить черновик письма;
• суммировать документ;
• сравнить несколько вариантов текста;
• структурировать заметки;
• проанализировать таблицу;
• получить идеи для дальнейшей работы.

Если на задачу уходит десять минут несколько раз в месяц, подключение API, CRM и собственной базы данных может оказаться великолепным способом автоматизировать то, что автоматизировать пока незачем.

У готового сервиса есть важное преимущество: гипотезу можно проверить практически сразу.

Если сотрудник уже использует инструмент и получает стабильную пользу, можно наблюдать за процессом дальше. Возможно, со временем появится объём, повторяемость или необходимость интеграции — и тогда архитектура изменится.

Но начинать с разработки только потому, что «у всех сейчас ИИ», необязательно.

Когда компании нужен не AI-чат, а AI-система

Граница становится заметной, когда сотрудники начинают вручную изображать интеграцию.

Например:

• данные копируются из CRM в AI-чат;
• один и тот же промт используется десятки раз;
• ответ модели вручную переносится обратно;
• несколько сотрудников должны получать результат в одинаковом формате;
• для ответа нужны внутренние документы;
• модель должна учитывать данные клиента из нескольких источников;
• после анализа нужно создать задачу, изменить статус или вызвать другой сервис.

В этот момент схема «сотрудник открыл чат и что-то спросил» перестаёт масштабироваться.

Рабочий контур начинает выглядеть иначе:

бизнес-система → данные → ИИ → проверка → действие → бизнес-система

Например, заявка может поступить с сайта, пройти классификацию, дополниться информацией из CRM, попасть в модель, после проверки результата создать задачу менеджеру и сохранить итог обратно.

Когда ИИ требуется доступ к CRM, 1С, ERP, базам данных или внешним API, речь уже идёт об интеграции ИИ в системы компании.

Если основная задача — работа с внутренними регламентами, инструкциями и другими знаниями компании, применяется корпоративный AI-поиск и RAG.

А когда несколько таких этапов связываются в один рабочий контур, появляется автоматизация бизнес-процессов с ИИ.

И только после того, как понятна архитектура решения, имеет смысл переходить к следующему уровню — выбору конкретной модели.

Если компании требуется уже не отдельный инструмент, а системное внедрение ИИ в бизнес, начинать всё равно стоит с процесса, данных и требований, а не с названия LLM.

Как выбрать конкретную ИИ-модель

Теперь вопрос «какая модель лучше?» становится осмысленным.

Сначала опишите повторяющийся сценарий: что поступает на вход, какой результат требуется и какую ошибку нельзя допустить.

Изображения, видео, речь и другие мультимодальные задачи стоит оценивать отдельно. Высокое качество текстовой LLM ничего не говорит о том, насколько хорошо соседний сервис генерирует изображения или распознаёт аудио.

Также не обязательно выбирать одну модель на всю компанию.

В реальной системе разные операции могут выполняться разными моделями.

Как оценить качество модели на своей задаче

Публичные рейтинги и бенчмарки полезны для первичного отбора. Они помогают сократить десятки вариантов до нескольких кандидатов.

Но место в общем рейтинге ещё не доказывает, что модель аккуратно обработает именно ваш договор, техническое описание, карточку клиента или отраслевую терминологию.

Для окончательного выбора нужен собственный тест.

Возьмите 10–20 реальных заданий: обычных, сложных и пограничных.

Запустите их на двух-трёх моделях в сопоставимых условиях. Чат нужно сравнивать с чатом, API — с API, одинаковые системные инструкции — с одинаковыми.

Проверяйте не ощущение «ответ выглядит умно», а конкретные признаки:

• правильность;
• полноту;
• соблюдение формата;
• фактические ошибки;
• возможность проверки результата;
• время обработки;
• необходимость ручных исправлений.

Для извлечения данных можно считать долю правильно заполненных полей. Для текстов — использовать редакционные критерии. Для программирования — запускать тесты. Для исследований — проверять источники и даты.

Важные задания полезно повторять несколько раз. Генеративная модель не обязана выдавать идентичный результат при каждом запуске.

Отдельно проверяйте русский язык и профессиональную лексику. Хороший результат на английском benchmark не гарантирует такую же аккуратность в российском договоре, отраслевом регламенте или внутренней документации.

Большое контекстное окно тоже не заменяет тестирование. Возможность принять длинный документ не означает, что модель одинаково внимательно обработает каждую его часть.

Цена модели — это не только тариф или токены

Для сотрудника стоимость может включать подписку, количество пользователей, ограничения тарифа и время проверки результата.

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

Но даже этого недостаточно.

Полезнее считать не стоимость одного запроса, а стоимость принятого результата:

стоимость результата = модель или подписка + повторы + проверка человеком + инфраструктура

Представим два варианта обработки 100 документов.

Первая модель стоит дешевле, но после неё специалист два часа исправляет ошибки.

Вторая обходится дороже по API, зато проверка занимает полчаса.

Более дешёвая модель в таком сценарии легко становится более дорогим решением.

Отдельно стоит учитывать, что пользовательское сообщение и один AI-сценарий — не одно и то же. Один запрос клиента может запускать классификацию, поиск, генерацию, проверку и форматирование.

Как считать такую нагрузку, подробнее разобрано в материале «Стоимость токенов в API».

Какие ограничения проверить до выбора

Доступность и эксплуатация

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

Тарифы, модели и функции меняются. Проверять их нужно перед пилотом, а не по сравнительной таблице полугодовой давности.

Лимиты и скорость

Для ручной работы задержка в несколько десятков секунд иногда не имеет значения.

В клиентской поддержке, массовой классификации или автоматизированном процессе она уже влияет на работу системы.

Для API также важны лимиты запросов, токенов и параллельной обработки.

Файлы, контекст и инструменты

Нужно проверить не только интеллект модели, но и среду вокруг неё:

• поддерживаемые форматы файлов;
• таблицы и сканы;
• структурированный JSON;
• вызов инструментов;
• веб-поиск;
• выполнение кода;
• работу через API;
• подключение корпоративных источников.

Иногда модель с более скромным результатом в общем benchmark оказывается удобнее в реальном процессе благодаря нужным инструментам.

Данные и конфиденциальность

Рабочие документы не стоит переносить в случайный личный AI-чат только потому, что он уже открыт в браузере.

У пользовательского сервиса, корпоративной версии и API могут различаться условия обработки, хранения и использования данных.

До запуска нужно проверить:

• какие данные отправляются провайдеру;
• где они обрабатываются;
• сколько хранятся;
• кто имеет доступ;
• можно ли отключить отдельные механизмы хранения;
• нужно ли маскирование чувствительной информации.

Для закрытых сценариев иногда рассматривают локальные или самостоятельно размещённые модели. Но локальная инфраструктура тоже имеет стоимость: серверы, развёртывание, обновления, мониторинг и поддержку.

Обновления моделей

Модели обновляются, переименовываются и выводятся из эксплуатации.

После смены версии может измениться стиль ответа, структура JSON, скорость или качество на конкретном сценарии.

Поэтому для рабочей системы желательно иметь тестовый набор, отслеживать изменения и заранее понимать, какая модель будет резервной.

Надежда на вечную жизнь однажды написанного промпта — стратегия довольно смелая. Обычно продакшен предпочитает менее азартные варианты.

Когда нужна сильная модель, а когда достаточно быстрой

Самую мощную доступную модель необязательно использовать для каждой операции.

Сложный анализ, неоднозначные документы, программирование и сценарии с дорогой ошибкой действительно могут требовать модели верхнего уровня.

Но применять её для определения категории каждой входящей заявки — примерно как развозить небольшие посылки на спортивном автомобиле. Технически задача решена. Экономист слегка нервничает.

В рабочей AI-системе могут одновременно использоваться:

• сильная модель — для сложных случаев;
• сбалансированная — для основной нагрузки;
• быстрая и недорогая — для классификации и массовых операций;
• локальная или открытая — когда критичен контроль инфраструктуры;
• специализированная — для изображений, речи, поиска или других отдельных задач.

Система может определять тип запроса и направлять его нужной модели. Такой подход называют роутингом.

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

Матрица выбора ИИ-модели

После тестирования кандидатов удобно оценить их по единой матрице.

Вес критериев нужно менять под задачу.

Для юридических документов важнее точность и контроль данных.

Для массовой классификации — скорость, стоимость и стабильность формата.

Для контента — язык, стиль и соблюдение редакционных требований.

Универсальная матрица полезна как основа, но не как автоматический судья.

Матрица выбора ИИ-модели

Оцените каждый критерий по пятибалльной шкале и умножьте на вес.

Вес критериев нужно менять под задачу.

Для юридических документов важнее точность и контроль данных.

Для массовой классификации — скорость, стоимость и стабильность формата.

Для контента — язык, стиль и соблюдение редакционных требований.

Универсальная матрица полезна как основа, но не как автоматический судья.

Так какой ИИ лучше для бизнеса

Универсально лучшего ИИ для бизнеса нет.

Для одного сотрудника лучшим решением окажется готовый AI-чат.

Для команды, работающей с внутренними инструкциями, — система корпоративного поиска.

Для потока документов — специализированная обработка с моделью через API.

Для процесса, где нужно получать данные из нескольких систем и выполнять действия, — AI-автоматизация или агентная архитектура.

И уже внутри выбранного класса решения можно сравнивать конкретные модели по качеству, стоимости, скорости, работе с русским языком, безопасности и доступным инструментам.

Поэтому выбирать стоит не по формуле:

«какая нейросеть сейчас первая в рейтинге?»

а по другой:

задача → тип решения → требования → модель → тест → измеримый результат

Рейтинг помогает найти кандидатов.

Модель помогает выполнить отдельную интеллектуальную операцию.

А полезный для бизнеса результат появляется только тогда, когда всё это соответствует реальному рабочему процессу.