Emerging Architectures for LLM Applications | Andreessen Horowitz
Статья a16z описывает референсную архитектуру для приложений на основе LLM, сложившуюся в практике AI-стартапов и продвинутых техкомпаний. Основной паттерн — in-context learning: вместо дообучения модели разработчики управляют её поведением через продуманные промпты и подмешивание приватных контекстных данных. Рабочий процесс делится на три стадии: предобработка данных и эмбеддинги (с хранением в векторных БД, чаще всего Pinecone), сборка промптов и retrieval (через оркестраторы вроде LangChain и LlamaIndex), и инференс (преимущественно через OpenAI API с gpt-4 или gpt-3.5-turbo, а также Anthropic Claude и open-source модели на базе LLaMa). Авторы Matt Bornstein и Rajko Radovanovic отмечают слабое развитие операционного тулинга (кэширование на Redis, логирование через Weights & Biases, PromptLayer, Helicone; валидация Guardrails; защита от prompt injection Rebuff). Отдельно обсуждаются AI-агенты (AutoGPT) как самый быстрорастущий GitHub-репозиторий весны, но пока находящиеся в стадии proof-of-concept. Авторы подчёркивают, что стек ещё очень молод и будет существенно меняться.
Развивающиеся архитектуры для LLM-приложений
Большие языковые модели — это мощный новый примитив для разработки ПО. Но поскольку они появились недавно и ведут себя совсем не так, как привычные вычислительные ресурсы, не всегда очевидно, как их использовать.
В этой статье мы делимся референсной архитектурой для формирующегося стека LLM-приложений. Она показывает наиболее распространённые системы, инструменты и паттерны проектирования, которые мы видели у AI-стартапов и продвинутых техкомпаний. Этот стек пока находится на очень ранней стадии и может существенно измениться по мере развития базовых технологий, но мы надеемся, что он будет полезным ориентиром для разработчиков, работающих с LLM сегодня.
Эта работа основана на разговорах с основателями и инженерами AI-стартапов. Особенно мы опирались на вклад: Ted Benson, Harrison Chase, Ben Firshman, Ali Ghodsi, Raza Habib, Andrej Karpathy, Greg Kogan, Jerry Liu, Moin Nadeem, Diego Oppenheimer, Shreya Rajpal, Ion Stoica, Dennis Xu, Matei Zaharia и Jared Zoneraich. Спасибо за вашу помощь!
Примечание: Живая и более полная версия этих компонентов доступна в нашем LLM App Stack repo на GitHub.
Стек
Вот наш текущий взгляд на стек LLM-приложений (нажмите, чтобы увеличить):
А вот список ссылок на каждый проект для быстрого ознакомления:
Существует множество способов разработки с LLM, включая обучение моделей с нуля, дообучение open-source моделей или использование хостируемых API. Стек, который мы показываем здесь, основан на in-context learning — паттерне проектирования, с которого, как мы наблюдаем, начинает большинство разработчиков (и который стал возможен только сейчас, благодаря foundation-моделям).
В следующем разделе кратко объясняется этот паттерн; опытные разработчики LLM могут его пропустить.
Паттерн проектирования: In-context learning
Основная идея in-context learning — использовать LLM «как есть» (то есть без какого-либо дообучения), а затем управлять их поведением с помощью продуманных промптов и подмешивания приватных «контекстных» данных.
Например, допустим, вы создаёте чат-бота для ответов на вопросы по набору юридических документов. При наивном подходе вы могли бы вставить все документы в промпт ChatGPT или GPT-4, а затем задать вопрос в конце. Это может сработать для очень маленьких датасетов, но не масштабируется. Самая большая модель GPT-4 может обработать только ~50 страниц входного текста, и производительность (измеряемая временем инференса и точностью) сильно деградирует при приближении к этому пределу, называемому context window.
In-context learning решает эту проблему с помощью изящного трюка: вместо того чтобы отправлять все документы с каждым промптом LLM, он отправляет только несколько самых релевантных. А самые релевантные документы определяются с помощью… вы угадали… LLM.
На очень высоком уровне рабочий процесс можно разделить на три этапа:
Предобработка данных / эмбеддинги: Этот этап включает хранение приватных данных (юридических документов в нашем примере), которые позже нужно будет извлекать. Обычно документы разбиваются на чанки, прогоняются через embedding-модель, а затем сохраняются в специализированной базе данных, называемой векторной БД. Сборка промпта / retrieval: Когда пользователь отправляет запрос (юридический вопрос в нашем случае), приложение собирает серию промптов для отправки в языковую модель. Скомпилированный промпт обычно объединяет: шаблон промпта, жёстко закодированный разработчиком; примеры валидных выходов, называемые few-shot examples; любую необходимую информацию, полученную из внешних API; и набор релевантных документов, извлечённых из векторной БД. Выполнение промпта / инференс: После того как промпты скомпилированы, они отправляются в предобученную LLM для инференса — включая как проприетарные модельные API, так и open-source или самостоятельно обученные модели. Некоторые разработчики на этом этапе также добавляют операционные системы — логирование, кэширование и валидацию.
Это выглядит как большой объём работы, но обычно это проще, чем альтернатива — обучение или дообучение самой LLM. Для in-context learning не нужна специализированная команда ML-инженеров. Также не нужно хостить собственную инфраструктуру или покупать дорогой выделенный инстанс у OpenAI. Этот паттерн фактически сводит AI-задачу к задаче data engineering, которую большинство стартапов и крупных компаний уже умеют решать. Он также, как правило, превосходит дообучение для относительно небольших датасетов — поскольку конкретный фрагмент информации должен встретиться в обучающей выборке хотя бы ~10 раз, прежде чем LLM запомнит его через дообучение, — и может включать новые данные практически в реальном времени.
Один из главных вопросов вокруг in-context learning: что произойдёт, если мы просто изменим базовую модель, чтобы увеличить context window? Это действительно возможно и является активной областью исследований (см., например, статью Hyena или этот недавний пост). Но это сопряжено с рядом компромиссов — прежде всего тем, что стоимость и время инференса растут квадратично с длиной промпта. Сегодня даже линейное масштабирование (лучший теоретический результат) было бы непомерно дорогим для многих приложений. Один запрос к GPT-4 по 10 000 страниц стоил бы сотни долларов по текущим тарифам API. Поэтому мы не ожидаем кардинальных изменений в стеке из-за расширения context window, но прокомментируем это подробнее в основной части поста.
Если вы хотите глубже погрузиться в in-context learning, есть множество отличных ресурсов в AI canon (особенно в разделе «Practical guides to building with LLMs»). В оставшейся части поста мы пройдёмся по референсному стеку, используя вышеописанный workflow в качестве ориентира.
Контекстные данные для LLM-приложений включают текстовые документы, PDF и даже структурированные форматы, такие как CSV или SQL-таблицы. Решения для загрузки и преобразования этих данных сильно различаются среди разработчиков, с которыми мы общались. Большинство использует традиционные ETL-инструменты вроде Databricks или Airflow. Некоторые также используют document loaders, встроенные в фреймворки оркестрации, такие как LangChain (работающий на базе Unstructured) и LlamaIndex (работающий на базе Llama Hub). Тем не менее мы считаем, что эта часть стека относительно слабо развита, и есть возможность для решений по репликации данных, специально созданных для LLM-приложений.
Для эмбеддингов большинство разработчиков использует OpenAI API, в частности модель text-embedding-ada-002. Её легко использовать (особенно если вы уже используете другие API OpenAI), она даёт достаточно хорошие результаты и становится всё дешевле. Некоторые крупные предприятия также изучают Cohere, которые сильнее фокусируют свои продуктовые усилия именно на эмбеддингах и показывают лучшую производительность в определённых сценариях. Для разработчиков, предпочитающих open-source, стандартом является библиотека Sentence Transformers от Hugging Face. Также возможно создавать разные типы эмбеддингов, адаптированных под разные сценарии использования; сегодня это нишевая практика, но многообещающая область исследований.
Самый важный компонент конвейера предобработки с системной точки зрения — это векторная БД. Она отвечает за эффективное хранение, сравнение и извлечение до миллиардов эмбеддингов (то есть векторов). Чаще всего на рынке мы видим Pinecone. Она стала выбором по умолчанию, потому что полностью облачная — то есть с ней легко начать — и обладает многими функциями, которые нужны крупным предприятиям в продакшене (например, хорошей производительностью при масштабировании, SSO и SLA по аптайму).
Однако существует огромный спектр векторных БД. В частности:
Open-source системы вроде Weaviate, Vespa и Qdrant: Они, как правило, дают отличную производительность на одном узле и могут быть адаптированы под конкретные приложения, поэтому популярны среди опытных AI-команд, которые предпочитают строить собственные платформы. Локальные библиотеки управления векторами вроде Chroma и Faiss: У них отличный developer experience, их легко поднять для небольших приложений и экспериментов в разработке. Они не обязательно заменяют полноценную БД в масштабе. OLTP-расширения вроде pgvector: Для разработчиков, которые видят каждую дыру в форме БД и пытаются вставить туда Postgres, — или для предприятий, которые покупают большую часть своей data-инфраструктуры у одного облачного провайдера, — это хорошее решение для поддержки векторов. В долгосрочной перспективе неясно, имеет ли смысл тесно связывать векторные и скалярные нагрузки.
Заглядывая вперёд, большинство компаний, разрабатывающих open-source векторные БД, создают облачные предложения. Наши исследования показывают, что достичь высокой производительности в облаке, в широком пространстве возможных сценариев использования, — очень сложная задача. Поэтому в ближайшей перспективе набор опций может не сильно измениться, но в долгосрочной — изменится наверняка. Ключевой вопрос: будут ли векторные БД похожи на свои OLTP- и OLAP-аналоги, консолидируясь вокруг одной-двух популярных систем.
Ещё один открытый вопрос — как эмбеддинги и векторные БД будут эволюционировать по мере роста доступного context window у большинства моделей. Заманчиво сказать, что эмбеддинги станут менее актуальны, поскольку контекстные данные можно будет просто бросать прямо в промпт. Однако отзывы экспертов по этой теме говорят об обратном — что embedding-конвейер со временем может стать важнее. Большие context windows — мощный инструмент, но они влекут существенные вычислительные затраты. Поэтому эффективное их использование становится приоритетом. Мы можем начать видеть, как становятся популярными разные типы embedding-моделей, обученных специально под model relevancy, и векторные БД, спроектированные так, чтобы использовать это.
Стратегии промптинга LLM и включения контекстных данных становятся всё сложнее — и всё важнее как источник дифференциации продукта. Большинство разработчиков начинает новые проекты с экспериментов с простыми промптами, состоящими из прямых инструкций (zero-shot prompting) или, возможно, нескольких примеров выходов (few-shot prompting). Эти промпты часто дают хорошие результаты, но не дотягивают до уровней точности, необходимых для продакшен-развёртываний.
Следующий уровень промптингового джиу-джитсу нацелен на то, чтобы привязать ответы модели к какому-то источнику истины и предоставить внешний контекст, на котором модель не обучалась. Prompt Engineering Guide каталогизирует не менее 12 (!) более продвинутых стратегий промптинга, включая chain-of-thought, self-consistency, generated knowledge, tree of thoughts, directional stimulus и многие другие. Эти стратегии также могут использоваться вместе, чтобы поддерживать различные сценарии использования LLM, такие как вопросно-ответные системы по документам, чат-боты и т. д.
Именно здесь блистают фреймворки оркестрации, такие как LangChain и LlamaIndex. Они абстрагируют многие детали prompt chaining; взаимодействие с внешними API (включая определение того, когда вызов API необходим); извлечение контекстных данных из векторных БД; и поддержание памяти между несколькими вызовами LLM. Они также предоставляют шаблоны для многих распространённых приложений, упомянутых выше. Их выход — это промпт или серия промптов для отправки в языковую модель. Эти фреймворки широко используются среди энтузиастов и стартапов, которые хотят поднять приложение, причём LangChain — лидер.
LangChain пока относительно новый проект (сейчас на версии 0.0.201), но мы уже начинаем видеть, как приложения, построенные на нём, выходят в продакшен. Некоторые разработчики, особенно ранние адоптеры LLM, предпочитают переходить на чистый Python в продакшене, чтобы устранить лишнюю зависимость. Но мы ожидаем, что этот DIY-подход со временем будет сокращаться для большинства сценариев, аналогично тому, как это произошло с традиционным стеком веб-приложений.
Внимательные читатели заметят, казалось бы, странную запись в блоке оркестрации: 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, больше опций кастомизации для крупных клиентов и context window до 100k (хотя мы обнаружили, что точность ухудшается с длиной входа). Перенаправление части запросов в open-source модели: Это может быть особенно эффективно в высоконагруженных B2C-сценариях вроде поиска или чата, где есть широкая вариативность сложности запросов и потребность обслуживать бесплатных пользователей дёшево. Обычно это имеет наибольший смысл в сочетании с дообучением open-source базовых моделей. В этой статье мы не углубляемся в этот стек инструментов, но платформы вроде Databricks, Anyscale, Mosaic, Modal и RunPod используются растущим числом инженерных команд. Для open-source моделей доступно множество вариантов инференса, включая простые API-интерфейсы от Hugging Face и Replicate; сырые вычислительные ресурсы от крупных облачных провайдеров; и более готовые облачные предложения вроде перечисленных выше.
Open-source модели сейчас отстают от проприетарных предложений, но разрыв начинает сокращаться. Модели LLaMa от Meta установили новую планку точности для open-source и запустили волну производных. Поскольку LLaMa лицензировалась только для исследовательского использования, появился ряд новых провайдеров, обучающих альтернативные базовые модели (например, Together, Mosaic, Falcon, Mistral). Meta также обсуждает по-настоящему open-source релиз LLaMa 2.
Когда (не «если») open-source LLM достигнут уровней точности, сопоставимых с GPT-3.5, мы ожидаем увидеть момент в духе Stable Diffusion для текста — включая массовое экспериментирование, обмен и продуктовизацию дообученных моделей. Хостинговые компании вроде Replicate уже добавляют инструментарий, чтобы разработчикам ПО было проще использовать эти модели. Среди разработчиков растёт уверенность, что меньшие, дообученные модели могут достигать state-of-the-art точности в узких сценариях.
Большинство разработчиков, с которыми мы общались, ещё не сильно углубились в операционный тулинг для LLM. Кэширование относительно распространено — обычно на базе Redis — потому что улучшает время отклика приложения и стоимость. Инструменты вроде Weights & Biases и MLflow (перенесённые из традиционного machine learning) или PromptLayer и Helicone (созданные специально под LLM) также довольно широко используются. Они могут логировать, отслеживать и оценивать выходы LLM, обычно с целью улучшения сборки промптов, тюнинга пайплайнов или выбора моделей. Также разрабатывается ряд новых инструментов для валидации выходов LLM (например, Guardrails) или обнаружения атак prompt injection (например, Rebuff). Большинство этих операционных инструментов поощряют использование собственных Python-клиентов для вызова LLM, поэтому будет интересно посмотреть, как со временем эти решения сосуществуют.
Наконец, статические части LLM-приложений (т. е. всё, кроме модели) тоже нужно где-то хостить. Самые распространённые решения, которые мы видели до сих пор, — это стандартные опции вроде Vercel или крупных облачных провайдеров. Однако появляются две новые категории. Стартапы вроде Steamship предоставляют end-to-end хостинг для LLM-приложений, включая оркестрацию (LangChain), мультитенантные контексты данных, асинхронные задачи, векторное хранилище и управление ключами. А компании вроде Anyscale и Modal позволяют разработчикам хостить модели и Python-код в одном месте.
А что насчёт агентов?
Самые важные компоненты, отсутствующие в этой референсной архитектуре, — это фреймворки AI-агентов. AutoGPT, описанный как «экспериментальная open-source попытка сделать GPT-4 полностью автономным», стал этой весной самым быстрорастущим репозиторием Github в истории, и практически каждый AI-проект или стартап сегодня в той или иной форме включает агентов.
Большинство разработчиков, с которыми мы общаемся, невероятно воодушевлены потенциалом агентов. Паттерн in-context learning, который мы описываем в этом посте, эффективен в решении проблем галлюцинаций и устаревания данных, чтобы лучше поддерживать задачи генерации контента. Агенты же дают AI-приложениям принципиально новый набор возможностей: решать сложные задачи, действовать во внешнем мире и учиться на опыте после развёртывания. Они делают это благодаря комбинации продвинутого рассуждения/планирования, использования инструментов и памяти / рекурсии / саморефлексии.
Поэтому у агентов есть потенциал стать центральным элементом архитектуры LLM-приложений (или даже захватить весь стек, если вы верите в рекурсивное самоулучшение). И существующие фреймворки вроде LangChain уже включили некоторые концепции агентов. Есть только одна проблема: агенты пока толком не работают. Большинство фреймворков агентов сегодня находятся на стадии proof-of-concept — они способны на впечатляющие демо, но пока не на надёжное, воспроизводимое выполнение задач. Мы следим за тем, как они будут развиваться в ближайшем будущем.
Заглядывая вперёд
Предобученные AI-модели представляют собой самое важное архитектурное изменение в ПО со времён интернета. Они позволяют отдельным разработчикам за считанные дни создавать невероятные AI-приложения, превосходящие проекты на основе обучения с учителем, на которые большие команды тратили месяцы.
Инструменты и паттерны, которые мы изложили здесь, — скорее отправная точка, чем конечное состояние интеграции LLM. Мы будем обновлять это по мере крупных изменений (например, при сдвиге в сторону обучения моделей) и публиковать новые референсные архитектуры там, где это имеет смысл. Пожалуйста, свяжитесь с нами, если у вас есть отзывы или предложения.
Matt Bornstein
— генеральный партнёр Andreessen Horowitz, фокусирующийся на AI и системах данных.
Rajko Radovanovic
— инвестиционный партнёр в инфраструктурной команде Andreessen Horowitz, где он фокусируется на AI и инфраструктуре.
Хотите больше про инфру?
Аналитика и новости о последних трендах, меняющих AI и инфраструктуру.
Мнения, выраженные в «постах» (включая подкасты, видео и социальные сети), принадлежат отдельным сотрудникам a16z, цитируемым в них, и не являются мнениями a16z Capital Management, L.L.C. («a16z») или её соответствующих аффилированных лиц. a16z Capital Management — инвестиционный консультант, зарегистрированный в Комиссии по ценным бумагам и биржам. Регистрация в качестве инвестиционного консультанта не подразумевает каких-либо особых навыков или подготовки. Посты не адресованы каким-либо инвесторам или потенциальным инвесторам и не являются предложением о продаже — или приглашением сделать предложение о покупке — каких-либо ценных бумаг, и не могут использоваться или приниматься во внимание при оценке достоинств любых инвестиций.
Содержимое здесь — и доступное на любых связанных платформах распространения и любых публичных онлайн-аккаунтах, платформах и сайтах a16z в социальных сетях (совместно — «каналы распространения контента») — не должно толковаться или приниматься во внимание каким-либо образом как инвестиционная, юридическая, налоговая или иная консультация. Вам следует консультироваться с собственными советниками по юридическим, деловым, налоговым и другим связанным вопросам, касающимся любых инвестиций. Любые проекции, оценки, прогнозы, цели, перспективы и/или мнения, выраженные в этих материалах, могут быть изменены без уведомления и могут отличаться от мнений, выраженных другими, или противоречить им. Любые графики, предоставленные здесь или на каналах распространения контента a16z, носят исключительно информационный характер и не должны приниматься во внимание при принятии каких-либо инвестиционных решений. Определённая информация, содержащаяся здесь, была получена из сторонних источников, включая портфельные компании фондов, управляемых a16z. Хотя она взята из источников, считающихся надёжными, a16z не проверяла такую информацию независимо и не делает заявлений о её устойчивой точности или применимости в данной ситуации. Кроме того, посты могут включать рекламу третьих сторон; a16z не рассматривала такую рекламу и не одобряет какой-либо рекламный контент, содержащийся в ней. Весь контент актуален только на указанную дату.
Ни при каких обстоятельствах любые посты или иная информация, предоставленная на этом сайте — или на связанных каналах распространения контента — не должны толковаться как предложение, побуждающее к покупке или продаже какой-либо ценной бумаги или доли в любом объединённом инвестиционном инструменте, спонсируемом, обсуждаемом или упомянутом сотрудниками a16z. Также это не должно толковаться как предложение по предоставлению услуг инвестиционного консультирования; предложение инвестировать в объединённый инвестиционный инструмент, управляемый a16z, будет сделано отдельно и исключительно посредством конфиденциальных предлагаемых документов конкретных объединённых инвестиционных инструментов, которые должны быть прочитаны полностью и только теми, кто, среди прочих требований, соответствует определённым квалификациям согласно федеральному законодательству о ценных бумагах. Такие инвесторы, определяемые как аккредитованные инвесторы и квалифицированные покупатели, как правило, считаются способными оценить достоинства и риски потенциальных инвестиций и финансовых вопросов.
Не может быть никаких гарантий того, что инвестиционные цели a16z будут достигнуты или что инвестиционные стратегии будут успешны. Любые инвестиции в инструмент, управляемый a16z, сопряжены с высоким уровнем риска, включая риск потери всей вложенной суммы. Любые упомянутые, указанные или описанные инвестиции или портфельные компании не являются репрезентативными для всех инвестиций в инструменты, управляемые a16z, и не может быть никакой гарантии, что инвестиции будут прибыльными или что другие инвестиции, сделанные в будущем, будут иметь аналогичные характеристики или результаты. Список инвестиций, сделанных фондами, управляемыми a16z, доступен здесь: https://a16z.com/investments/. Прошлые результаты инвестиций a16z, объединённых инвестиционных инструментов или инвестиционных стратегий не обязательно указывают на будущие результаты. Из этого списка исключены инвестиции (и определённые публично торгуемые криптовалюты/цифровые активы), для которых эмитент не предоставил разрешения a16z раскрывать публично. В отношении своих инвестиций в любой криптовалютный или токен-проект a16z действует в своих собственных финансовых интересах, не обязательно в интересах других держателей токенов. a16z не играет особой роли ни в одном из этих проектов и не имеет власти над их управлением. a16z не обязуется продолжать участвовать в этих проектах кроме как в качестве инвестора и держателя токенов, и другие держатели токенов не должны ожидать, что она будет это делать, или полагаться на её какое-либо конкретное участие.
В отношении фондов, управляемых a16z, зарегистрированных в Японии, a16z предоставит любому члену японской общественности копию документов, которые требуется сделать публично доступными согласно статье 63 Закона Японии о финансовых инструментах и биржах. Пожалуйста, свяжитесь по адресу compliance@a16z.com, чтобы запросить такие документы.
Для других условий использования сайта, пожалуйста, перейдите сюда. Дополнительная важная информация о a16z, включая нашу Form ADV Part 2A Brochure, доступна на сайте SEC: http://www.adviserinfo.sec.gov.