MIT Technology Review (не опять, а снова) разбирает «графики масштабирования» популярных ИИ-моделей и показывает, как компании вроде OpenAI создают иллюзию непрерывного прогресса. Они используют логарифмические шкалы и выбирают метрики, которые рисуют ровную восходящую кривую, хотя на практике каждый следующий процент качества требует экспоненциального роста вычислительных ресурсов.
Объясню проще
Представьте, что вы печёте пироги. Добавляете больше муки, сахара и времени в духовку, чтобы сделать их вкуснее. Сначала каждая новая порция ингредиентов сильно улучшает вкус, но потом добавляешь всё больше и больше, а вкус растёт всё медленнее. В итоге для крошечного улучшения приходится тратить тонны муки и электричества.
Я решил взглянуть на эту закономерность в контексте "внедрения ИИ в бизнес-процессы".
Когда компания автоматизирует рутину с помощью ИИ, это выглядит как магия. На пилоте ИИ-решение за месяц экономит компании несколько сотен тысяч рублей на поддержке.
Все довольны.
Кажется, что дальше нужно просто «масштабировать». Но как только этот же подход пытаются развернуть на всю цепочку поставок, картинка резко меняется. Эффект сжимается до +1–2%, а годовые расходы на компьютерные ресурсы и инфраструктуру улетают в космос.
Это не ошибка команды. И не «плохая модель». Это - закон масштабируемости - закон убывающей отдачи, о который бизнес регулярно бьётся головой.
Как это проявляется в бизнесе
Ритейл
Чат-бот окупается быстро. Персонализация на миллион клиентов - миллиарды токенов ради +1–3% продаж.
Логистика
Анализ отчётов и Excel - отличный эффект. Полная оптимизация цепочки приводит к мобилизации компьютерных ресурсов на уровне промышленного объекта и прирост маржи в районе 0.5%.
Я, конечно, намеренно утрирую, но на таком контрасте легче понять проблему. По данным последних лет, порядка 70% компаний при масштабировании ИИ-решений упираются в ROI ниже 2x. Не потому что ИИ «переоценён». А потому что экономика перестаёт сходиться.
Что с этим делают сами разработчики моделей
Когда стало понятно, что просто увеличивать модель дальше слишком дорого, разработчики пошли другим путём. Вместо того чтобы делать одну огромную систему, они стали работать над эффективностью.
Например, теперь модель может «думать» дольше над конкретным вопросом, не становясь при этом больше в размерах. Другой подход — создавать небольшие, узкоспециализированные модели, которые дешевле и проще контролировать, потому что они заточены под одну конкретную задачу.
И наконец, появились гибридные схемы, когда тяжёлые, мощные модели используют только в самых критичных местах, где без них действительно не обойтись, а всё остальное отдают более лёгким и дешёвым решениям.
Фокус сместился с «давайте сделаем модель умнее любой ценой» на «давайте сделаем её умнее там, где это действительно нужно, и дешевле в остальном».
Что делать бизнесу сейчас
- Начинать с пилотов. Узкий контур, понятная задача, быстрый эффект.
- Считать точку отсечки. Если следующий процент качества стоит x10 - это повод остановиться и пересобрать архитектуру.
- Работать с данными, а не с объёмом. Качество данных часто даёт прирост без роста мощностей и затрат.
- Думать "гибридно". Большая часть задач не требует «топ-моделей».
Личный комментарий
Я пока не работал с масштабами уровня федеральных сетей, в основном пилоты и SMB. Но законы масштабирования держу в голове всегда, особенно когда разговор заходит о росте и «давайте ещё добавим ИИ». Без этого понимания очень легко слить бюджет на иллюзию прогресса.
Пишите, если у вас есть задачи для ИИ или столкнулись с проблемой масштабирования ИИ-решений
mail@askerych.ru
mail@askerych.ru