LLM для бизнеса: какую выбрать для каких задач

Компании все активнее внедряют большие языковые модели – недавний опрос «Аихаб» выяснил, что каждый четвертый предприниматель готов вложить в ИИ до 5 млн рублей в год, а еще половина – до 1 млн. С их помощью автоматизируют поддержку клиентов, маркетинг, документооборот, операционный учет, подготовку отчетов, работу с базами знаний и многие другие процессы.

Решений на рынке много, у каждого варианта есть свои «но» – от вопросов легальности до безопасности данных.

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

Выбор модели – не то решение, на которое стоит тратить месяцы

Разговор о внедрении ИИ начинается с вопроса «какую модель взять». Компании изучают рейтинги, просят команду сравнить варианты, спорят о том, кто сегодня лидер. На это уходят недели – а устойчивого ответа на вопрос нет.

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

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

Отсюда вывод: выбор конкретной модели – решение обратимое и не самое дорогое: сегодня вы работаете с одной, через полгода перешли на другую, и на большинстве процессов этого даже не заметят. А вот решение о том, где эта модель будет работать – в облаке поставщика или внутри вашего контура, – определяет бюджет, требования к команде, уровень безопасности и то, какие данные вы вообще сможете доверить ИИ. Менять его потом дорого и долго.

Вариант первый: облако

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

Так устроены практически все ведущие модели: они проприетарные. Это значит, что разработчик не раскрывает устройство модели и не отдает ее наружу – ни скачать, ни развернуть у себя нельзя в принципе. Единственный способ работать с такой моделью – обращаться к сервису разработчика. Логика та же, что у любого облачного софта: вы получаете результат, но не получаете сам продукт.

Плюсы

• Скорость. Запуск занимает дни, а не кварталы: зарегистрировались, получили ключ доступа, подключили к своим системам. 

• Бюджетность на первых этапах. Не нужно покупать серверы, не нужна команда, которая будет их обслуживать. Оплата идет по факту использования, поэтому на старте не приходится вкладываться в мощности, которые еще неизвестно, понадобятся ли. 

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

Минусы

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

• Экономика на длинной дистанции. Оплата по использованию удобна, пока запросов немного. Когда ИИ прорастает в массовые процессы и объем вырастает в десятки раз, счет растет вместе с ним линейно и без потолка. Компания, которая начинала с комфортных сумм на пилоте, через год может обнаружить, что платит за инфраструктуру, которой не владеет, больше, чем стоило бы собственное решение.

• Зависимость. Тарифы меняются, версии моделей выводятся из эксплуатации, условия доступа пересматриваются. Процесс, который построен вокруг конкретного облачного сервиса, наследует все риски этого сервиса. Облачный доступ предлагают как зарубежные, так и отечественные вендоры. Если первые могут выигрывать по качеству на сложных задачах, то вторые выигрывают в совместимости с софтом, на котором работает российский бизнес. Готовые коннекторы к 1С, Битрикс24 и популярным CRM позволяют встроить ИИ в существующие процессы без отдельного проекта по интеграции. К тому же обработка данных остается в российской юрисдикции, что снимает часть вопросов с точки зрения законодательства.

Вариант второй: on-premise

Вторая схема – развернуть модель у себя: на собственных серверах или в изолированном сегменте облака, к которому нет доступа ни у кого, кроме компании. Запрос обрабатывается внутри периметра и наружу не выходит вообще.

Это возможно благодаря моделям с открытыми весами – «настройками», заложенными в процессе обучения. Когда разработчик публикует их открыто, любой может скачать модель, запустить на своем железе, настроить под себя и дообучить на собственных данных. Так устроены Qwen, Llama, DeepSeek и ряд других семейств.

За последние два года лучшие открытые модели подошли к проприетарным вплотную. На инженерных задачах их результаты сопоставимы с ведущими закрытыми моделями, а по объему реального использования открытые решения занимают уже около трети рынка. Разрыв сохранился, но сместился в узкую зону самых сложных сценариев.

Плюсы

• Конфиденциальность данных. Главное – данные физически не покидают компанию. Это принципиально иной уровень защиты, чем договорные обязательства. Для персональных данных клиентов, банковской и врачебной тайны, коммерчески чувствительной информации это часто единственный допустимый режим работы, и вопросы соответствия 152-ФЗ снимаются сами собой.

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

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

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

Минусы

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

• Риск неокупаемости. Из-за высоких затрат на запуск, собственный контур окупается только на существенных объемах. Если ИИ используют несколько сотрудников время от времени, облако будет дешевле в разы. Порог, за которым математика разворачивается в другую сторону, наступает при действительно массовой нагрузке – когда модель обслуживает поток запросов постоянно.

• Необходимость поддержания. Ответственность за работоспособность переходит к компании. Сломалось – чинить самим, вышла новая версия модели – обновляться самим.

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

Облако VS on-premise: сравнение

С чего начать

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

1. Какие данные пойдут в модель? Если это персональные сведения клиентов, договоры, медицинская или финансовая информация – вопрос контура решен, и обсуждать остается только реализацию. Если задачи не касаются чувствительных данных, ограничений почти нет.

2. Какой ожидается объем? Несколько десятков запросов в день и массовый поток в сотни тысяч – это принципиально разная экономика, и решение, оптимальное для первого случая, будет разорительным во втором.

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