A16Z: развивающаяся архитектура для приложений больших моделей

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

Источник изображения: сгенерировано Unbounded AI

Большие языковые модели (LLM) — это новые мощные примитивы для разработки программного обеспечения. Но поскольку LLM настолько нов и ведет себя так иначе, чем обычные вычислительные ресурсы, не всегда очевидно, как использовать LLM.

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

Эта работа основана на беседах с основателями и инженерами ИИ-стартапов. В частности, мы полагаемся на мнение таких людей, как Тед Бенсон, Харрисон Чейз, Бен Фиршман, Али Годси, Раза Хабиб, Андрей Карпати, Грег Коган, Джерри Лю, Мойн Надим, Диего Оппенгеймер, Шрея Раджпал, Ион Стойка, Деннис Сюй, Матей Захария и Джаред Зонраич. Спасибо за вашу помощь!

Стек технологий LLM

Текущая версия стека приложений LLM выглядит так:

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

Ниже приведен список ссылок на каждый элемент для быстрого ознакомления:

, общие инструменты/системы для каждого ключевого компонента стека приложений

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

В следующем разделе кратко объясняется этот шаблон проектирования.

Шаблон проектирования: контекстное обучение

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

Например, допустим, вы разрабатываете чат-бота для ответов на вопросы о ряде юридических документов. Самый простой способ: вы можете вставить все документы в приглашение ChatGPT или GPT-4, а затем задать соответствующие вопросы. Это может работать для очень маленьких наборов данных, но не масштабируется. Самые большие модели GPT-4 могут обрабатывать только около 50 страниц входного текста, а производительность (измеряемая временем вывода и точностью) сильно ухудшается при приближении к этому так называемому пределу окна контекста.

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

На очень высоком уровне этот рабочий процесс можно разбить на три этапа:

• Предварительная обработка/встраивание данных: на этом этапе сохраняются личные данные (в данном случае юридические документы) для последующего извлечения. Как правило, документы делятся на фрагменты, передаются модели встраивания и хранятся в специальной базе данных, называемой векторной базой данных.
• Создание/извлечение подсказки: когда пользователь отправляет запрос (в данном случае юридический вопрос), приложение создает серию подсказок, которые затем передаются языковой модели. Скомпилированные подсказки часто комбинируются с шаблонами подсказок, жестко запрограммированными разработчиком; примеры допустимого вывода называются примерами с несколькими выстрелами; вся необходимая информация извлекается через внешний API; а набор связанных документов извлекается из векторной базы данных.
• Выполнение/вывод подсказок: после того, как подсказки скомпилированы, они передаются предварительно обученным LLM для вывода, включая проприетарные API-интерфейсы моделей, а также модели с открытым исходным кодом или самообучаемые модели. На этом этапе некоторые разработчики также добавляют операционные системы, такие как ведение журнала, кэширование и проверка.

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

Один из самых больших вопросов в контекстном обучении: что произойдет, если мы просто изменим базовую модель, чтобы увеличить окно контекста? Это действительно возможно, и это активная область исследований. Но это связано с некоторыми компромиссами - в основном стоимость и время вывода масштабируются квадратично с длиной подсказки. Сегодня даже линейное масштабирование (лучший теоретический результат) слишком затратно для многих приложений. При текущих тарифах API один запрос GPT-4 на 10 000 страниц будет стоить сотни долларов. Поэтому мы не предвидим крупномасштабных изменений в стеке на основе расширенных окон контекста, но подробнее об этом поговорим позже.

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

Обработка/встраивание данных

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

Контекстные данные для приложений LLM включают текстовые документы, PDF-файлы и даже структурированные форматы, такие как таблицы CSV или SQL. Решения для загрузки и преобразования данных (ETL), используемые разработчиками, с которыми мы беседовали, сильно различались. Большинство из них используют традиционные инструменты ETL, такие как Databricks или Airflow. Некоторые также используют загрузчики документов, встроенные в структуру оркестровки, такие как LangChain (на платформе Unstructed) и LlamaIndex (на платформе Llama Hub). Однако мы считаем, что эта часть технологического стека относительно слаборазвита, и есть возможность разработать решение для репликации данных специально для приложений LLM.

Что касается встраивания, большинство разработчиков используют OpenAI API, особенно модель text-embedding-ada-002. Эта модель проста в использовании (особенно если вы уже используете другие API OpenAI), дает достаточно хорошие результаты и становится дешевле. Некоторые крупные предприятия также изучают Cohere, чья работа над продуктом больше сосредоточена на встраивании и имеет более высокую производительность в некоторых сценариях. Для разработчиков, предпочитающих открытый исходный код, библиотека Hugging Face Sentence Transformers является стандартом. Также возможно создавать разные типы вложений в зависимости от варианта использования, это сегодня относительно нишевая практика, но перспективная область исследований.

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

Однако существует также большое количество доступных векторных баз данных. Известные из них включают:

• Системы с открытым исходным кодом, такие как Weaviate, Vespa и Qdrant: эти системы обычно обладают превосходной производительностью на одном узле и могут быть настроены для конкретных приложений, что делает их популярными среди опытных команд искусственного интеллекта, которым нравится разрабатывать собственные платформы.
• Faiss et al Родные библиотеки управления векторами: Эти библиотеки имеют большой опыт разработки и просты в запуске для небольших приложений и экспериментов по разработке. Но они не обязательно могут заменить полные базы данных в больших масштабах.
• Расширения OLTP, такие как pgvector: отлично подходит для разработчиков, которые видят дыры в каждой форме базы данных и пытаются подключиться к Postgres, или для предприятий, покупающих большую часть своей инфраструктуры данных у одного поставщика облачных услуг. Хорошее решение для поддержки векторов. Неясно, имеет ли в долгосрочной перспективе смысл тесная связь между векторными и скалярными рабочими нагрузками.

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

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

Подскажите построить и получить

Срочно построить и получить

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

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

Здесь на помощь приходят такие фреймворки оркестровки, как LangChain и LlamaIndex. Эти структуры абстрагируются от многих деталей цепочки подсказок, взаимодействия с внешними API (включая определение того, когда требуется вызов API), извлечения данных контекста из векторной базы данных и поддержания памяти при вызовах между несколькими LLM. Они также предоставляют шаблоны для многих распространенных приложений, упомянутых выше. Его вывод представляет собой подсказку или серию подсказок, представленных языковой модели. Эти фреймворки широко используются любителями, а также стартапами, стремящимися разрабатывать приложения, причем LangChain является лидером.

LangChain все еще является относительно новым проектом (в настоящее время это версия 0.0.201), но мы уже начинаем видеть, как приложения, разработанные с его помощью, поступают в производство. Некоторые разработчики, особенно ранние последователи LLM, предпочитают переходить на необработанный Python в производственной среде, чтобы удалить дополнительные зависимости. Но мы ожидаем, что этот подход «сделай сам» сократится для большинства случаев использования, как это было с традиционными стеками веб-приложений.

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

Выполнение/обоснование подсказки

Подсказка исполнения/рассуждения

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

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

• Переключиться на gpt-3.5-turbo: это примерно в 50 раз дешевле GPT-4 и значительно быстрее. Многим приложениям не требуется точность уровня GPT-4, но они нужны для логического вывода с малой задержкой и экономичной поддержки для бесплатных пользователей. *Эксперименты проводились с другими проприетарными поставщиками (особенно с моделью Claude от Anthropic): Claude предлагает быстрый вывод, точность на уровне GPT-3.5, дополнительные параметры настройки для крупных клиентов и контекстные окна до 100 000 (хотя мы обнаружили, что точность снижается с увеличением длины ввода). .
• Классифицировать частичные запросы для моделей с открытым исходным кодом: это особенно эффективно для случаев использования больших объемов B2C, таких как поиск или чат, где сложность запросов сильно различается, а бесплатные пользователи должны обслуживаться дешево:

1. Обычно это имеет смысл в сочетании с тонкой настройкой базовой модели с открытым исходным кодом. Мы не будем углубляться в этот стек инструментов в этой статье, но такие платформы, как Databricks, Anyscale, Mosaic, Modal и RunPod, все чаще используются инженерными группами.

2. Модели с открытым исходным кодом могут использовать несколько вариантов логического вывода, включая простой интерфейс API Hugging Face и Replicate, необработанные вычислительные ресурсы от основных поставщиков облачных услуг и облачные продукты (уверенное облако) с более четкими предпочтениями, подобные перечисленным выше.

В настоящее время модель с открытым исходным кодом отстает от проприетарных продуктов, но разрыв начинает сокращаться. Модель LLaMa от Meta установила новые стандарты точности с открытым исходным кодом и породила ряд вариантов. Поскольку лицензия LLaMa предназначена только для исследовательских целей, многие новые провайдеры начали обучение альтернативным базовым моделям (например, «Вместе», «Мозаика», «Сокол», «Мистраль»). Meta все еще обсуждает, стоит ли запускать настоящую версию LLaMa 2 с открытым исходным кодом.

Когда (а не если) LLM с открытым исходным кодом достигнет уровня точности, сравнимого с GPT-3.5, мы ожидаем, что у текста также будет свой собственный момент стабильного распространения, когда в производство будут запущены широкомасштабные эксперименты, совместное использование и точная настройка моделей. Хостинговые компании, такие как Replicate, начали добавлять инструменты, чтобы сделать эти модели более доступными для разработчиков программного обеспечения. Разработчики все чаще верят в то, что более мелкие и точно настроенные модели могут обеспечить высочайшую точность для узкого диапазона вариантов использования.

Большинство опрошенных нами разработчиков не имели глубокого понимания рабочих инструментов LLM. Кэширование является относительно распространенным явлением (часто основанным на Redis), так как это улучшает время отклика приложения и снижает затраты. Такие инструменты, как Weights & Biases с MLflow (портированные из традиционного машинного обучения) или Layer с Helicone (созданные для LLM), также довольно широко используются. Эти инструменты могут записывать, отслеживать и оценивать выходные данные LLM, часто с целью улучшения конструкции наконечника, настройки конвейеров или выбора моделей. Также разрабатывается множество новых инструментов для проверки выходных данных LLM (например, Guardrails) или обнаружения атак путем внедрения подсказок (например, Rebuff). Большинство этих операционных инструментов поощряют свои собственные клиенты Python выполнять вызовы LLM, поэтому будет интересно посмотреть, как эти решения будут сосуществовать с течением времени.

Наконец, статическую часть приложения LLM (то есть все, кроме модели) тоже нужно где-то размещать. Безусловно, наиболее распространенными решениями, которые мы видели, являются стандартные варианты, такие как Vercel или крупные поставщики облачных услуг. Однако появляются две новые категории. Такие стартапы, как Steamship, предоставляют сквозной хостинг для приложений LLM, включая оркестрацию (LangChain), многопользовательский контекст данных, асинхронные задачи, векторное хранилище и управление ключами. Такие компании, как Anyscale и Modal, позволяют разработчикам размещать модели и код Python в одном месте.

А как насчет прокси?

Одним из наиболее важных компонентов, отсутствующих в этой эталонной архитектуре, является структура агента искусственного интеллекта. AutoGPT был описан как «экспериментальная попытка с открытым исходным кодом полностью автоматизировать GPT-4», и этой весной он стал самым быстрорастущим репозиторием Github в истории, и почти каждый проект или стартап ИИ сегодня включает ту или иную форму. .

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

Таким образом, у агентов есть потенциал стать центральной частью архитектуры приложений LLM (или даже взять на себя весь стек технологий, если вы верите в рекурсивное самосовершенствование). Существующие фреймворки, такие как LangChain, уже включают часть концепции прокси. Есть только одна проблема: прокси еще не работают. Большинство агентских сред сегодня все еще находятся на стадии проверки концепции, предлагая невероятные демонстрации, но не выполняя задачи надежно и воспроизводимо. Мы внимательно следим за тем, как прокси будет развиваться в ближайшее время.

Взгляд в будущее

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

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