Перевод: Чему мы научились за год построения проектов с LLM. Часть 3

https://www.oreilly.com/radar/what-we-learned-from-a-year-of-building-with-llms-part-iii-strategy/

Первые части статьи:

• Перевод: Чему мы научились за год построения проектов с LLM. Часть 1

• Чему мы научились за год построения проектов с LLM. Часть 2 (оригинал)

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

Но откуда берутся эти цели? Это сфера стратегии. Стратегия отвечает на вопросы "что" и "почему" за "как" тактики и эксплуатации.

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

1. Разработка или покупка: когда следует обучать собственные модели, а когда следует использовать существующие API? Ответ, как всегда, "все зависит от ситуации". Обсудим далее, от чего это зависит.

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

3. ИИ с фокусом на человеке: как эффективно интегрировать LLM в рабочие процессы с участием человека, чтобы увеличить его производительность и удовлетворенность? Мы подчеркиваем важность создания ИИ-инструментов, которые поддерживают и улучшают человеческие возможности, а не пытаются полностью их заменить.

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

5. Будущее недорогой когнитивной способности: как быстро снижающиеся затраты и растущие возможности ЛЛР будут формировать будущее приложений ИИ? Мы опишем исторические тенденции и опишем простой метод оценки того, когда определенные приложения могут стать экономически целесообразными.

6. От Демо к Продукту: что нужно, чтобы перейти от убедительной демонстрации к надежному, масштабируемому продукту? Мы подчеркнём необходимость тщательной инженерии, тестирования и доработки для устранения разрыва между прототипом и продуктивом.

Чтобы ответить на эти сложные вопросы, давайте будем рассуждать пошагово...

Стратегия: создание продуктов на основе LLM без потери маневренности

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

No GPU before PMF

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

Разрабатывать или покупать

Обучение с нуля (почти) никогда не имеет смысла

Для большинства организаций предварительное обучение LLM с нуля является непрактичным отвлечением от создания продуктов.

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

Рассмотрим случай BloombergGPT, LLM специально обученной для финансовых задач. Модель была предварительно обучена на 363 миллиарда токенов и потребовала героических усилий со стороны девяти сотрудников, четырех из отдела инженерии ИИ и пяти из отдела ML Product and Research. Несмотря на эти усилия, она была превзойдена gpt-3.5-turbo и gpt-4 на этих финансовых задачах в течение года.

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

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

Не приступайте к fine-tuning до тех пор, пока не убедитесь, что это необходимо

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

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

Год назад многие команды говорили нам, что они с энтузиазмом относятся к fine-tuning. Немногие нашли соответствие продукт-рынок, и большинство сожалеют о своем решении. Если вы собираетесь заниматься fine-tuning, вы должны быть действительно уверены, что у вас есть возможности для повторного fine-tuning базовых моделей по мере их улучшения — см. «Модель — это не продукт» и «Внедрение LLMOps» ниже.

Когда fine-tuning действительно может быть правильным решением? Если задача требует данных, недоступных в масштабных наборах данных, используемых для обучения существующих моделей и если вы уже создали MVP, демонстрирующий, что существующие модели недостаточны. Но будьте осторожны: если качественные данные для обучения недоступны даже создателям моделей, откуда они появились у вас ?

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

Начните с API инференса, но не бойтесь самостоятельного хостинга

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

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

Кроме того, самостоятельный хостинг позволяет обойти ограничения, установленные провайдерами инференса, такие как ограничения скорости, устаревание моделей и ограничения сценариев использования. Кроме того, самостоятельный хостинг дает вам полный контроль над моделью, что упрощает создание дифференцированной, высококачественной системы вокруг нее. Наконец, самостоятельный хостинг, особенно для fine-tuning, может сократить расходы в больших масштабах. Например, BuzzFeed поделился опытом fine-tuning открытых LLM, чтобы сократить расходы на 80%.

Модель — это не продукт, продукт - это система вокруг модели

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

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

Вместо этого сосредоточьте свои усилия на том, что будет обеспечивать долгосрочную ценность, например:

• Оценочная платформа: для надежного измерения производительности по вашей задаче в разных моделях

• Ограничители: для предотвращения нежелательных результатов независимо от модели

• Кэширование: для сокращения задержки и затрат путем обхода вызова модели

• Датчик полета: для итеративного улучшения всего вышеперечисленного

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

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

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

Стройте доверие, начиная с малого

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

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

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

Создавайте LLMOps, но не в качестве самоцели, а для достижения более быстрого цикла итераций

DevOps заключается в сокращении циклов обратной связи между работой и ее результатами, чтобы накапливались улучшения, а не ошибки. Его корни уходят в движение Lean Startup, а также в Lean систему производства Toyota, с ее акцентом на принципе Kaizen.

MLOps адаптировал DevOps к ML. У нас есть воспроизводимые эксперименты, у нас есть комплексные решения, которые расширяют возможности создателей моделей для развертывания. И, конечно же, у нас есть файлы YAML.

Но как отрасль, MLOps не адаптировал функцию DevOps. Он не сократил разрыв в обратной связи между моделями, их инференсом и изменениями в продуктиве.

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

Уже существуют интерактивные арены для нейтральной, коллективной оценки моделей для чат-ботов и программирования — внешняя петля для коллективного, итеративного улучшения. Такие инструменты, как LangSmith, Log10, LangFuse, W&B Weave, HoneyHive и другие, обещают не только собирать и обобщать данные о результатах системы в продуктиве, но и использовать их для улучшения этих систем, тесно интегрируя их с разработкой. Используйте эти инструменты или создайте собственные.

Не создавайте функции LLM, которые вы можете купить

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

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

Рассмотрим несколько ошибочных направлений, которые потратят время вашей команды:

• Создание собственных text-to-SQL решений

• Создание чат-бота для общения с вашей документацией

• Интеграция базы знаний вашей компании с чат-ботом поддержки клиентов

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

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

Искусственный интеллект в цикле, люди в центре

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

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

“Overall, developers told us they felt more confident because coding is easier, more error-free, more readable, more reusable, more concise, more maintainable, and more resilient with GitHub Copilot and GitHub Copilot Chat than when they’re coding without it.”—Mario Rodriguez, GitHub

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

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

Начните с разработки промптов, оценки и сбора данных

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

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

Инженерия промптов это первый шаг

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

Только если инженерия промптов не может достичь желаемого уровня производительности, следует рассмотреть fine-tuning. Это более вероятно при наличии нефункциональных требований (например, конфиденциальность данных, полный контроль и стоимость), которые блокируют использование проприетарных моделей и, таким образом, требуют самостоятельного размещения. Только убедитесь, что эти же требования конфиденциальности не запрещают вам использование данных пользователей для fine-tuning!

Создавайте оценки и запускайте конвейер данных

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

Эффективные оценки специфичны для ваших задач и отражают предполагаемые сценарии использования. Первый уровень оценок, который мы рекомендуем, — это модульное тестирование (unit-testing). Эти простые утверждения обнаруживают известные или предполагаемые сбои и помогают направлять ранние решения о дизайне. Также см. другие оценки задач для классификации, обобщения и т. д.

Хотя модульное тестирование и оценки на основе моделей полезны, они не заменяют необходимость в оценке человека. Пусть люди используют вашу модель / продукт и предоставляют обратную связь. Это служит двойной цели измерения реальной производительности и уровня ошибок, одновременно собирая высококачественные аннотированные данные, которые можно использовать для fine-tuning будущих моделей. Это создает положительную обратную связь, или данные, которые накапливаются с течением времени:

• Используйте человеческую оценку для оценки производительности модели и / или поиска дефектов

• Используйте аннотированные данные для fine-tuning модели или обновления промптов

• Повторяйте

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

Высокоуровневая тенденция к дешевой когнитивной обработке

В 1971 году исследователи Xerox PARC предсказали будущее: мир сетевых персональных компьютеров, в котором мы сейчас живем. Они помогли появиться этому будущему, сыграв ключевую роль в изобретении технологий, которые это сделали возможным, от Ethernet и графического рендеринга до мыши и окна.

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

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

За четыре года с момента запуска модели OpenAI davinci в качестве API стоимость выполнения модели с эквивалентной производительностью для этой задачи в масштабе одного миллиона токенов (около ста копий этой статьи) снизилась с 20 долларов до менее 1 цента - время сокращения вдвое составило всего шесть месяцев. Аналогичным образом, стоимость запуска Meta LLama 3 8B через поставщика API или самостоятельно составляет всего 20 центов за миллион токенов по состоянию на май 2024 года, и у нее такая же производительность, как у OpenAI text-davinci-003, модели, которая позволила ChatGPT потрясти мир. Эта модель стоила около 20 долларов за миллион токенов при ее выпуске в конце ноября 2023 года. Это два порядка величин всего за 18 месяцев - за такой же временной диапазон закон Мура предсказывает всего двойное увеличение производительности.

Теперь давайте рассмотрим применение LLM, которое очень полезно (обеспечение генеративных персонажей видеоигр, à la Park et al.), но еще экономически не выгодно (их стоимость была оценена в 625 долларов в час) С момента публикации этой статьи в августе 2023 года стоимость снизилась примерно на один порядок величин до 62,50 долларов в час. Мы можем ожидать, что она снизится до 6,25 долларов в час еще через девять месяцев.

Между тем, когда в 1980 году был выпущен Pac-Man, за 1 доллар сегодняшних денег вы могли купить десяток минут игры, т.е. шесть игр в час, или 6 долларов за час игры. Эти расчеты на коленке показывают, что игры с LLM-улучшение станет экономически выгодным примерно в 2025 году.

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

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

Довольно демонстраций, пора создавать продукты

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

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

Возьмем, к примеру, автономные автомобили. Первая машина, управляемая нейронной сетью, была создана в 1988 году. Двадцать пять лет спустя Andrej Karpathy сделал свою первую демонстрационную поездку в Waymo. Еще через десять лет компания получила разрешение на автономное вождение. Это тридцать пять лет тщательной инженерной работы, тестирования, совершенствования и взаимодействия с регулирующими органами, чтобы перейти от прототипа к коммерческому продукту.

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