Я не хочу сказать, что я был ярым отрицателем глубокого обучения, но я упорно держался, чтобы не попасть в ажиотаж вокруг LLM. Хотя я нахожу интересными почти все исследования ML, я действительно очарован исследованиями систем ML, посвященными практической реализации моделей ML. И казалось, что генеративный ИИ рекламировался больше как забавная игрушка, чтобы «посмотреть, на что он способен», чем что-то, что можно запустить в производство.

Как обычно, сообщения LinkedIn начали поступать. Однако только недавно, когда те же самые сообщения начали меняться от «Вау, посмотрите на этот ответ» на «Вау, посмотрите на это приложение, которое я создал», я понял, что больше не могу держать голову в песке. Я понял, что раньше, чем я ожидал, эти приложения станут частью работы систем машинного обучения, которая меня так интересует. Поэтому я потратил некоторое время, пытаясь выяснить, чем разработка этих моделей отличается от типичных моделей машинного обучения.

Как выглядит традиционный жизненный цикл машинного обучения?

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

На диаграмме мы видим два основных конвейера, которые работают для запуска моделей ML в производство (и один уровень с контролем версий, который помогает ими управлять). Первый конвейер разработки — это место, где специалисты по данным и исследовательские группы работают над созданием модели. Во втором конвейере инженеры и разработчики машинного обучения работают над тем, чтобы взять свою модель на заключительном этапе разработки и преобразовать ее в нечто, что можно использовать для прогнозирования в реальном мире.

Как выглядит жизненный цикл LLM?

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

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

Модели фундамента

Слева мы видим самый известный аспект этих новых LLM-систем — базовые модели. Базовые модели — это большие предварительно обученные языковые модели, способные понимать и генерировать текст на естественном языке. Эта способность хорошо выполнять общие языковые задачи позволяет этим моделям служить отправной точкой для различных задач НЛП, таких как языковой перевод, обобщение текста и ответы на вопросы.

Базовые модели — это наиболее значительный отход от традиционного жизненного цикла машинного обучения. Доступ через API к базовым моделям упростил для команд использование НЛП в своих операциях, независимо от отрасли или размера. Они могут реализовать только API в качестве своей производственной модели, пропустив большую часть рабочего процесса жизненного цикла машинного обучения, если им нужны только возможности общих языковых задач.

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

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

Разработка

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

Определение варианта использования

Хотя это и не указано явно на приведенной выше диаграмме, первым шагом к созданию любой полезной модели ML для производства, LLM или нет, является определение и понимание вашего варианта использования. Команды должны будут провести время с заинтересованными сторонами бизнеса и продукта, чтобы понять цель модели, которую они запускают в производство.

Курирование данных и тонкая настройка модели

Команды по науке о данных должны курировать и очищать данные для конкретных вариантов использования, чтобы создавать LLM для конкретных вариантов использования. Эти данные будут использоваться для обучения/точной настройки понимания языка базовой модели в соответствии с требованиями их задачи.

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

Качественная проверка с подсказками

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

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

Схема приложения

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

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

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

Шаблон подсказки

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

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

Быстрая оркестровка

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

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

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

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

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

Отзывы пользователей

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

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

Заключение и взгляд вперед

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

  • Базовые модели: служат отправной точкой для команд в разработке надежных базовых моделей НЛП.
  • Разработка: все та же необходимость тонкой настройки и оценки моделей для конкретной конечной задачи, даже если есть новые методы и названия должностей.
  • Схема приложения: процесс запуска LLM в производство, который все еще нуждается в проверке и мониторинге, даже если он зависит от новых инструментов / подсказок.

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

Этот пост изначально был размещен в блоге Артур.