Хотя малые языковые модели (SLM) преподносятся как простое решение проблем, связанных со стоимостью и сложностью внедрения искусственного интеллекта, использующие их в реальных рабочих процессах CIO обнаруживают, что за этой экономией скрываются определенные нюансы, отмечают опрошенные порталом InformationWeek эксперты.

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

В прошлом году аналитики Gartner спрогнозировали, что в 2027 г. организации будут использовать специализированные модели, предназначенные для решения конкретных задач, в три раза чаще, чем универсальные большие языковые модели (LLM). Этот сдвиг уже отражается в корпоративных бюджетах: в июле Gartner сообщила, что расходы на специализированные ИИ-модели, ориентированные на конкретные предметные области, только в 2026-м вырастут на 210% — это более чем вдвое превышает темпы роста затрат на фундаментальные модели.

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

Когда расчет действительно оправдывается

«Внедрение SLM в корпоративном секторе перешло от стадии пилотных проектов к полноценной архитектуре, и этот процесс набирает обороты», — отмечает Амит Убхаякер, директор по аналитике данных и ИИ компании Protiviti. По его словам, речь не идет о полной замене больших моделей; скорее, формируется многоуровневая архитектура: малые модели используются для маршрутизации, классификации и формирования структурированных ответов, тогда как передовые модели задействуются для решения неоднозначных, многоэтапных задач.

Джейсон Джеймс, будучи CIO в поставщике технологических решений для ритейла Aptos, тестировал три-четыре специализированные модели на локальном оборудовании, а не в облаке. Целью было выяснить, оправданы ли затраты и усилия по поддержке таких моделей онпремис по сравнению с расходами на оплату токенов при использовании передовых моделей.

«По сути, это чистая математика, — говорит Джеймс. — Каковы затраты на внедрение? Каковы расходы на эксплуатацию? Каков объем использования? Если при локальном запуске все эти показатели будут существенно ниже — тогда стоит рассматривать такой вариант. А если экономия незначительна, то зачем вообще что-то менять?».

Хотя он недавно покинул Aptos, чтобы занять должность CIO в Acumatica, показатели тестирования свидетельствовали в пользу SLM — настолько, что в Aptos решили продолжить их пилотное внедрение. При этом, как отмечает Джеймс, такие модели не заменяют передовые инструменты, которые уже использовали команды в Aptos. Напротив, они расширяют выбор, позволяя избежать того, что он называет «банкротством по токенам» — ситуации, когда из-за неправильного подбора модели и некорректных промптов недостаточно подготовленные пользователи расходуют годовой бюджет на токены всего за несколько недель.

По словам Убхаякера, SLM лучше всего проявляют себя в узких, повторяемых и поддающихся проверке задачах — например, при классификации, маршрутизации или извлечении структурированных данных, — особенно в тех случаях, когда существуют строгие требования к границам данных или нормативному соответствию. «Это не означает, что SLM вытесняют передовые модели, — говорит он. — Речь идет о создании многоуровневой архитектуры, а не о полной замене одних решений другими».

Когда данные разрушают бизнес-кейс

Именно с этой проблемой на собственном опыте столкнулся Эрик Пейс, который недавно ушел с руководящей должности в сфере корпоративных ИТ и теперь консультирует компании по вопросам внедрения ИИ. Его команда внедрила для подготовки маркетинговых сообщений небольшой дообученный вариант модели Llama, которая обучалась на исторических данных, размеченных как «хорошие» или «плохие». Результаты тестирования выглядели многообещающе, а путь к промышленной эксплуатации оказался неожиданно быстрым и недорогим. Однако выяснилось, что данные, которые казались надежными на этапе тестирования, не выдержали проверки в реальных масштабах эксплуатации.

«В итоге нам пришлось отказаться от этого решения», — говорит Пейс, добавляя, что по-прежнему считает SLM эффективным инструментом для экономии времени, а вопросы дрейфа модели и управления версиями вполне решаемы в рамках разумного бюджета. Тем не менее, теперь он рассматривает качество данных как гораздо более критичный фактор для дообученных SLM, чем для ИИ-решений общего назначения.

«Мало того, что наборы данных должны точно соответствовать тому, что вы хотите видеть на входе в модель, — нужно еще найти правильный баланс, — отмечает Пейс. — Возможность перестараться с обучением вполне реальна». Его совет: ставьте перед моделью четкие, ограниченные задачи, предусматривайте возможность ретроспективного тестирования и не недооценивайте объем знаний о бизнес-процессах и ответственности за данные, которые потребуются от сотрудников за пределами ИТ-отдела.

Убхаякер уже сталкивался с подобными ситуациями, когда компании оценивали SLM, опираясь на общедоступные бенчмарки, а не на реальные данные и потоки запросов, с которыми им предстояло работать в производственной среде. «Организациям следует ориентироваться на стоимость выполнения одной успешной задачи, а не просто на стоимость одного токена, — отмечает он. — Модель меньшего размера может казаться более дешевой, однако необходимость повторных запусков, проверки результатов человеком или передачи задачи более мощным моделям может быстро свести на нет всю экономию».

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

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

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

Отказ от бинарного подхода

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

Убхаякер считает, что решение о том, использовать ли малую или большую языковую модель для конкретной задачи, должно приниматься индивидуально для каждого случая. При выборе следует учитывать, является ли задача четко ограниченной и поддающейся проверке; обладает ли организация техническими ресурсами для поддержки модели; и способна ли малая модель действительно обеспечить требуемую точность. Ориентироваться исключительно на то, какая архитектура выглядит дешевле «на бумаге», — неверный подход. Ценность SLM относительна: она зависит от характера задачи, используемых данных и того, кто несет ответственность за модель после ее ввода в эксплуатацию.