Преодоление пропасти искусственного интеллекта Как OpenAI превратило LLM в успешный продукт массового спроса

От искусственного интеллекта к массовому успеху как OpenAI превратил LLM в востребованный продукт

И почему LLMOps подвергнутся той же участи, что и MLOps

Я всегда была настороженной скептиком относительно целесообразности инструментов разработки машинного обучения (в широком смысле MLOps) как самостоятельных бизнесов, и, за очень немногими исключениями, мне удалось это подтвердить. Отсутствие доминирующего дизайна привело к фрагментации «микро-рынков» с очень низким захватом стоимости, в основном из-за альтернатив открытого исходного кода и облачных поставщиков, предоставляющих свои инструменты машинного обучения бесплатно (взимая плату за инфраструктуру). Так что привело к тому, чтобы LLMs превратились, уйдя от этих проблем, привлекли взоры СМИ и получили широкое распространение? И что случится с множеством стартапов, которые реализовывают МО-бизнес-план, переучиваясь как LLMOps?

В этой статье я воспользуюсь теорией «распространения инноваций», а также концепцией «преодоления бездны», чтобы объяснить мои оптимистические ожидания от поставщиков LLM, как, например, OpenAI или Anthropic, и почему я скептически отношусь к попытке возродить MLOps как LLMOps.

Принятие инноваций и бездна

Согласно «Теории распространения инноваций» Эверетта Роджерса, инновационные продукты постепенно принимаются различными группами пользователей с различными характеристиками. Инноваторы, которые готовы рисковать и имеют высокую толерантность к неудачам, первыми пробуют новый продукт. Старомодные люди, которые не любят изменения, – последние. Знаменитый график в форме колокола показывает процент пользователей в каждой категории, а соответствующий график кумулятивного принятия напоминает знакомую «S-кривую» доли рынка инновации со временем.

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

• Подробное руководство по созданию и публикации пакета данных R с использованием Devtools.
• Являются ли предварительно обученные модели основы будущего молекулярного машинного обучения? Представляем беспрецедентные наборы данных и библиотеку машинного обучения Graphium.
• Декораторы Python Полное руководство

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

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

Мур предлагает несколько рекомендаций по преодолению бездны, с которыми я полностью согласна только отчасти. Одно из наблюдений состоит в том, что, по его собственным словам, его книга в основном рассматривает бездну «как проблему развития рынка» и фокусируется на «стратегиях и тактике маркетинга для ее преодоления». Он касается идеи «управления всей продукцией», но, исходя из его чтения труда Теодора Левитта «Маркетинговая фантазия», концепция ограничена преодолением разрыва между маркетинговым сообщением и предоставляемой продукцией с помощью «услуг и вспомогательных продуктов». Он не затрагивает фактическую эволюцию продукта. Фактически, инновация (также называемая основным продуктом) рассматривается как постоянная.

Принимая во внимание конкретные характеристики программного обеспечения (особенно инструментов разработчика), я предлагаю две стратегии (“эволюция” и “пропуск”) для избежания пропасти и гипотезирую, как их применение способствовало быстрому развитию LLM.

Два продукт-центричных способа избежать пропасти

Развивайте (упрощайте) ваши инструменты разработчика со временем

Ограничение, что продукт является постоянным, в то время как все другие аспекты “всего продукта” (такие как мессив, дистрибуция, ценообразование) меняются для привлечения разных групп пользователей, в основном обуславливается физическими продуктами. Если ваш бизнес заключается в производстве и продаже изделий, изменение поставщиков или переоборудование заводов – это несложная задача. Однако это совершенно история другая с продуктами, которые полностью представляют собой программное обеспечение. Неэволюция вашего программного продукта – это практически всегда рецепт неудачи.

Необходимость развития должна быть очевидной, основываясь на том, как большинство программных стартапов начинают свою работу в наши дни. Чаще всего инструменты разработчика (особенно в области искусственного интеллекта) рождаются и развиваются в кругу сильной и преданный пользовательской базы экспертов в определенной области. Неудивительно, что эти ранние пользователи обычно являются инноваторами и, как таковые, не являются представителями широкого рынка. Очень легко для основателей потратить всё свое время и энергию на этот сегмент и настраивать свои продукты на основе их обратной связи. К сожалению, коммерческий успех редко обретается в тех первых группах. Инноваторы являются очень продвинутыми и часто предпочитают строить вместо покупки. Даже если они решат купить, они не представляют достаточно большого рынка.

Один из способов решить эту проблему – это со временем развивать продукт для разных целевых аудиторий. С хорошо спроектированными инструментами разработчика это означает внедрение новых уровней абстракции и/или поддержку более широко используемых языков. Давайте воспользуемся примером моего предыдущего работодателя – непрерывный успех Spark, который (по крайней мере, по моему мнению) частично обусловлен тем, что поверхность продукта непрерывно упрощалась для привлечения более широкого круга пользователей (позволю ли я сказать, раннее большинство?). Spark начал с RDD (Resilient Distributed Datasets) и языка программирования Scala в качестве основного. Затем была добавлена поддержка языка Python с помощью PySpark (открывшегося для широкого круга программных инженеров) и были введены более простые API, такие как DataFrame и SparkSQL (открытые для аналитиков SQL). Недавно Spark добавил совместимый с Pandas API (открывающийся для Data Scientists) и даже ввел «English SDK» с использованием LLMs (открывающийся для всех, кто знает английский). Если бы Spark не эволюционировал таким образом, он бы застрял в сегменте инноваторов, которые знают, как писать сложные программы MapReduce на Scala.

Эта стратегия кажется вполне очевидной, но не многие технологические продукты (особенно в инструментах разработчика) делают это правильно. Иногда они “упрощают” продукт, удаляя некоторые регуляторы, но не вводят новые уровни абстракции, которые не протекают.

Пропустить пропасть полностью

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

Как уже упоминалось ранее, это более важно в случае с оборудованием, где итерации продукта медленнее, дороже, и, как результат, его основной продукт не может так легко эволюционировать. iPhone – это прекрасный пример продукта, который часто критикуют инноваторы (даже в свежей модели iPhone 15 и его USB-C порт, который оказался «разочарованием»), но достигает быстрого успеха с ранним большинством, которым не важны эти технические детали. Фактически, Apple неоднократно учит промышленность уроку мастерства с помощью своей коммуникации. Наверное, самый знаменитый пример – это кампания “1,000 песен в вашем кармане“, которая была направлена на раннее большинство, а не на инноваторов, которым важны технические характеристики.

Это кажется ненормальным для многих технологических стартапов (особенно тех, которые сосредоточены на инструментах разработчика), потому что достичь раннего успеха с инноваторами и ранними принимателями – это слишком легко. Инструменты разработчика искусственного интеллекта начинаются с раннего рынка, по определению, так как обычно строятся и разрабатываются передовыми исследователями ИИ или инженерами машинного обучения. Практика «доказательства соответствия продукта и рынка», измеряемая звездами на GitHub, основанная на открытом коде проекта, только подтверждает это.

Общие неудачные стратегии коммерциализации открытых исходных кодовых проектов

Мне приходилось видеть достаточно «проектов с открытым исходным кодом, ставших стартапами», чтобы иметь хотя бы некоторое «узнавание образцов» для общих типов неудач. Эти стартапы находят ранний успех (и финансирование), когда они обнаруживают рост принятия, измеряемый звездами на GitHub или загрузками с PyPI. Затем они трагически следуют похожим путям, даже если есть опытный основатель, который «уже делал это раньше» (потому что они на самом деле не понимают, почему их предыдущие компании были успешными).

Увеличение инноваторов: Интуитивно (или наивно?), большинство стартапов первоначально пытаются продвигать продукт инноваторам в виде «управляемой» версии открытого исходного кода. Эта стратегия обычно оказывается неэффективной, потому что ранние инноваторы, по определению, очень сложны и предпочитают создавать вместо покупки. Общедоступная стратегия 3S (управляемый OSS + стабильность, масштабируемость, безопасность) недостаточна для того, чтобы оправдать платеж, так как они уже знают, как создавать и запускать службы сами. Инноваторы также боятся «захвата рынка» и потери возможности инновировать независимо.

Противоречие между продуктом и рынком: Следующей попыткой является продажа того же «управляемого OSS» продукта раннему большинству. Обычно это не удается, потому что основное предложение все равно является тем же сложным в использовании продуктом, который был оптимизирован для инноваторов. Простое добавление 3S недостаточно, чтобы стимулировать раннее большинство совершенствовать свои навыки (как планы по подготовке нескольких миллионов инженеров машинного обучения для создания рынка MLOps). И если это не было достаточно, последний гвоздь в гроб, которого не избежать, состоит в том, что никто не превосходит AWS в этой игре (что также является причиной, почему все больше от проектов с открытым исходным кодом переходят на некоммерческие лицензии).

«Полный продукт»: Я называю эту стратегию «полным продуктом» с сарказмом, потому что этот термин был использован не по назначению для заполнения основных пробелов в продукте неподходящими способами. Эта попытка обычно следует за пониманием того, что основной продукт слишком сложен для использования на более широком рынке, и решение часто включает в себя «сдавливание людей для решения проблемы». Это приводит к большой доле услуг в структуре доходов стартапа (что не нравится ни одному инвестору) и раздутым организациям поставки. Честно говоря, некоторое количество этого необходимо, особенно в сегменте предприятия или в федеральном секторе. Но чаще всего стартап начинает напоминать техническую консалтинговую компанию.

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

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

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

1. Используйте свой проект с открытым исходным кодом, чтобы стать популярным среди инноваторов
2. Используйте эту популярность, чтобы собрать деньги
3. Используйте инноваторскую группу, чтобы выяснить, как они создают потоковую ценность и для кого
4. Направить ваш продукт на основную аудиторию

Здесь Диффузия инноваций для программного обеспечения отличается от потребительского аппаратного обеспечения, такого как iPhone: ключевой момент заключается в том, что в цепочке создания ценности программного обеспечения инноваторы часто выступают в качестве посредников для раннего большинства. Другими словами, инноваторы сами не являются конечной точкой цепочки создания ценности. Они используют технологии, чтобы помогать командам по продукту/бизнесу создавать ценность. Иногда это принимает форму «Центра экспертизы» или централизованной «Команды инноваций». Целью технологического стартапа должно быть выяснение, кто находится в цепочке создания ценности после этих инноваторов, в этом месте они найдут ключ к раннему большинству. Критически важно отметить, что я не говорю, что вы должны пытаться вытеснить этих инноваторов в организациях, где они существуют, потому что это обычно приводит к политическому противостоянию. В таких случаях вам нужно сделать их своими «чемпионами».

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

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

1. Более высокий уровень абстракции, чем у исходного проекта OSS, в другом форм-факторе. Несмотря на недостатки, Databricks обеспечивает пример для этого. Прорывным продуктом, который привлек интерес извне группы Инноваторов, не было просто “управляемый Spark”, а управляемый продукт Notebook для Data Scientists и Engineers (что, в тот момент времени, было довольно новаторским). Databricks и сегодня продолжает следовать той же стратегии с продуктами, такими как Databricks SQL.
2. Более фокусированный продукт, ориентированный на вертикаль выше в цепочке создания ценности. Отличным примером является Stripe, который изначально начал с открытой платежной системы и затем добился успеха с продуктами, такими как Checkout (полная платежная форма для веб-сайтов) или Terminal (кассовые аппараты для пунктов продажи).

Как MLOps не смогли эволюционировать, а LLMs пропустили пропасть

MLOps застряли в раннем рынке

Не сказать о ML то же самое, что история, которую я рассказал о развитии Spark. MLOps-стек выглядит почти так же, как несколько лет назад, и надежда на рынке заключается в том, что все больше и больше инженеров научатся его использовать.

Не вдаваясь в воспоминания о том, как мы пришли к этому, позвольте мне кратко изложить свое мнение о состоянии рынка MLOps:

• Рынок MLOps не сойден на “доминирующем дизайне” и, в результате, каждая “MLOps платформа”, которую вы найдете, отличается по очевидным и скрытым способам.
• На системном уровне рынок MLOps не создал более простого “форм-фактора” или уровней абстракции, поэтому он по-прежнему чрезвычайно сложен и требует нескольких специализированных ролей (Data Engineer, Data Scientist, ML Engineer и т.д.), которые преобладают только в самых продвинутых технологических компаниях.
• Аудитория, которая может использовать эту технологию, то есть Инноваторы и Ранние Пользователи, предпочитает жить на передовой и использовать инструменты с открытым исходным кодом вместо оплаты поставщику.
• Аудитория, которая была бы готова заплатить поставщику, обычно просто использует то, что предлагают основные облачные поставщики услуг. Провайдеры облачных услуг предоставляют “ML платформу” бесплатно и довольствуются сбором дохода с хранения и вычислений.
• Поскольку облачные поставщики не монетизируют явно MLOps, захват рынка в этой области был минимальным.

В итоге, MLOps попал в пропасть, и нет признаков того, что он снова появится на свету.

Привлекательность LLMs для Раннего Большинства

Ввод LLMs. OpenAI, как сообщается, достиг показателя в 1,3 млрд долларов и ожидается дальнейший быстрый рост, что не скажешь о MLOps-стартапах. Фактически, вы, вероятно, сможете сложить выручку топ-10 стартапов MLOps и даже не приблизиться. Не забывайте, что большинство облачных поставщиков фактически не получают доход с этого слоя, кроме оплаты за вычисления и хранение, поэтому их доходы в сфере “ML” на самом деле не учитываются (если вы не хотите заняться бизнесом предоставления облачной инфраструктуры по комодитным ценам).

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

Пропустив пропасть в сегменте разработчиков

Традиционные “дискриминирующие” ML-модели обучаются для очень конкретных задач, таких как предсказание качества сделки с продажей или ранжирование списка продуктов. Для каждой из этих задач нескольким экспертам необходимо сотрудничать, чтобы написать потоки данных, собирать метки, уточнять так называемые “функции”, обучать и настраивать модели, оценивать их, развертывать, отслеживать их производительность, а затем периодически их переобучать. Необходимость повторять это для каждой задачи, а также количество требуемой экспертизы делали возможным это чудо только для немногих избранных.

“Генеративные” языковые модели, с другой стороны, “просто работают” для широкого спектра случаев использования, позволяя каждому, кто может вызвать API, применять искусственный интеллект в своем продукте или проблеме. Практически за одну ночь LLM-модели решают проблему нехватки талантов в области “прикладного искусственного интеллекта”, даруя каждому программисту сверхъестественные способности ИИ. Критически важно, что одна и та же LLM-модель может генерировать стихи, писать код, переводить вопросы на естественном языке в SQL-запросы или проходить различные стандартные тесты. Это работает “из коробки” (zero-shot) или просто давая модели несколько примеров проблемы, которую Вы хотите решить (few-shot), и распространяется на широкий спектр модальностей, не только текст.

Это именно определение обхода пропасти и незамедлительного перехода к раннему большинству.

Именно поэтому LLMOps обречено повторить историю. Думаю, что если у вас есть молоток, то каждая проблема выглядит как гвоздь. Неизбежно возникла отрасль, основанная на идее, что каждому необходимо обучать и донастраивать свои собственные LLM-модели, что упускает суть, из-за которой LLM-модели стали настолько успешными в первую очередь. Возвращение сложности написания систем обработки данных, обучения и настройки моделей, их развертывания и т.д. вновь помещает вас в микро-рынок Иноваторов, которые предпочитают создавать вместо покупки.

Заметьте, я не говорю, что никто не должен настраивать и развертывать собственные LLM-модели. При определенных обстоятельствах (которые редки) это имеет смысл делать. Но в почти всех этих случаях Вы обнаружите себя в группах Иноваторов и Первых Покупателей, и эти группы будут использовать только инструменты с открытым исходным кодом и не будут платить поставщику для получения преимуществ.

Пропуск пропасти в сегменте потребителей

OpenAI представлена на двух очень разных рынках: вышеупомянутый сегмент разработчиков обслуживается с помощью API и выделенных вычислительных мощностей. В то же время, ChatGPT и его мобильные приложения являются преимущественно “потребительскими” продуктами. ChatGPT стал известен как один из самых быстрорастущих продуктов, достигнувший 1 млн пользователей (за 5 дней), и, хотя нет официальных данных о доходе OpenAI, одна оценка указывает на доход от мобильных приложений в размере $3 млн в месяц. Кажется, что это не такой продукт, который медленно вырос в первичном рынке, верно?

Несмотря на свое специфичное название (GPT означает генеративный предварительно обученный трансформер), ChatGPT сразу же перешел к Раннему Большинству, в основном благодаря своей простой и удобной форме использования. Любой, начиная от журналистов до преподавателей или студентов, мог получить бесплатный доступ к нему и сразу же оценить его ценность. Если бы OpenAI просто выпустила модель, которую инженеры могли бы вызывать через REST API, это не привело бы к такому массовому принятию среди широкой аудитории.

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

• Наиболее очевидно, что осведомленность и узнаваемость бренда критичны для любого бизнеса. Хотя OpenAI и LLM-модели уже были хорошо известны в кругах исследователей ИИ, ChatGPT благодаря Раннему Большинству в более широком сегменте разработчиков превратил его в бренд.
• Одной из причин, почему “пропасть” существует в первую очередь, является склонность Раннего Большинства к риску и недоверие к сигналам Иноваторов. Один из способов преодолеть это – предоставить им простой способ испытать продукт. ChatGPT предоставил идеальный опыт “бесплатного пробного периода” для принятия решений неспециалистами из Раннего Большинства.
• Более “типичный” способ достижения роста доходов, как у OpenAI, – это найм команды по продажам предприятий. Оказывается, что традиционное движение с продажами, инициированными покупателем (SLG), значительно выигрывает от проверенных временем методов PLG, таких как безупречный доступ для ознакомления с продуктом. Покупатели корпораций все чаще ожидают “увидеть и оценить ценность продукта перед заключением большого контракта”.

Заключение

Я начал этот пост как естественное продолжение моих предыдущих постов о инструментах разработчика для машинного обучения, потому что я вижу, как история MLOps повторяется с LLMOps. Но, пока я писал о том, как LLM пропускают пропасть, я понял, что эти уроки могут быть применимы в широком смысле.

Для поставщиков LLM, таких как OpenAI, Anthropic и др.: Я не уверен, что эти компании случайно наткнулись на эту стратегию, но если применить ее намеренно, здесь определенно есть уроки о том, как улучшить разработку продукта и GTM. Однако, если вы находитесь в режиме гиперроста, у вас есть мало времени или необходимости для оптимизации.

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

Для стартапов в сфере технологий в целом: Я видел крупные раунды финансирования стартапов на основе открытого исходного кода, где гипотеза была либо “управляемый OSS + масштаб, стабильность и безопасность”, либо “открытый корпус, а монетизацию мы выясним позже”. Я считаю, что идея “пропустить пропасть” здесь ценна и с нетерпением жду отзывов как от основателей, так и от инвесторов!

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

Клеменс – предпринимательский лидер по продукту, который последние 8+ лет внедрял искусственный интеллект для разработчиков и предприятий.