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. Авторы подчёркивают, что стек ещё очень молод и будет существенно меняться.
Emerging Architectures for LLM Applications
Развивающиеся архитектуры для LLM-приложений
Large language models are a powerful new primitive for building software. But since they are so new—and behave so differently from normal computing resources—it’s not always obvious how to use them.
Большие языковые модели — это мощный новый примитив для разработки ПО. Но поскольку они появились недавно и ведут себя совсем не так, как привычные вычислительные ресурсы, не всегда очевидно, как их использовать.
In this post, we’re sharing a reference architecture for the emerging LLM app stack. It shows the most common systems, tools, and design patterns we’ve seen used by AI startups and sophisticated tech companies. This stack is still very early and may change substantially as the underlying technology advances, but we hope it will be a useful reference for developers working with LLMs now.
В этой статье мы делимся референсной архитектурой для формирующегося стека LLM-приложений. Она показывает наиболее распространённые системы, инструменты и паттерны проектирования, которые мы видели у AI-стартапов и продвинутых техкомпаний. Этот стек пока находится на очень ранней стадии и может существенно измениться по мере развития базовых технологий, но мы надеемся, что он будет полезным ориентиром для разработчиков, работающих с LLM сегодня.
This work is based on conversations with AI startup founders and engineers. We relied especially on input from: 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, and Jared Zoneraich. Thank you for your help!
Эта работа основана на разговорах с основателями и инженерами 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. Спасибо за вашу помощь!
Note: A living and more comprehensive version of these components is available in our LLM App Stack repo on GitHub.
Примечание: Живая и более полная версия этих компонентов доступна в нашем LLM App Stack repo на GitHub.
The stack
Стек
Here’s our current view of the LLM app stack (click to enlarge):
Вот наш текущий взгляд на стек LLM-приложений (нажмите, чтобы увеличить):
And here’s a list of links to each project for quick reference:
А вот список ссылок на каждый проект для быстрого ознакомления:
There are many different ways to build with LLMs, including training models from scratch, fine-tuning open-source models, or using hosted APIs. The stack we’re showing here is based on in-context learning, which is the design pattern we’ve seen the majority of developers start with (and is only possible now with foundation models).
Существует множество способов разработки с LLM, включая обучение моделей с нуля, дообучение open-source моделей или использование хостируемых API. Стек, который мы показываем здесь, основан на in-context learning — паттерне проектирования, с которого, как мы наблюдаем, начинает большинство разработчиков (и который стал возможен только сейчас, благодаря foundation-моделям).
The next section gives a brief explanation of this pattern; experienced LLM developers can skip this section.
В следующем разделе кратко объясняется этот паттерн; опытные разработчики LLM могут его пропустить.
Design pattern: In-context learning
Паттерн проектирования: In-context learning
The core idea of in-context learning is to use LLMs off the shelf (i.e., without any fine-tuning), then control their behavior through clever prompting and conditioning on private “contextual” data.
Основная идея in-context learning — использовать LLM «как есть» (то есть без какого-либо дообучения), а затем управлять их поведением с помощью продуманных промптов и подмешивания приватных «контекстных» данных.
For example, say you’re building a chatbot to answer questions about a set of legal documents. Taking a naive approach, you could paste all the documents into a ChatGPT or GPT-4 prompt, then ask a question about them at the end. This may work for very small datasets, but it doesn’t scale. The biggest GPT-4 model can only process ~50 pages of input text, and performance (measured by inference time and accuracy) degrades badly as you approach this limit, called a context window.
Например, допустим, вы создаёте чат-бота для ответов на вопросы по набору юридических документов. При наивном подходе вы могли бы вставить все документы в промпт ChatGPT или GPT-4, а затем задать вопрос в конце. Это может сработать для очень маленьких датасетов, но не масштабируется. Самая большая модель GPT-4 может обработать только ~50 страниц входного текста, и производительность (измеряемая временем инференса и точностью) сильно деградирует при приближении к этому пределу, называемому context window.
In-context learning solves this problem with a clever trick: instead of sending all the documents with each LLM prompt, it sends only a handful of the most relevant documents. And the most relevant documents are determined with the help of . . . you guessed it . . . LLMs.
In-context learning решает эту проблему с помощью изящного трюка: вместо того чтобы отправлять все документы с каждым промптом LLM, он отправляет только несколько самых релевантных. А самые релевантные документы определяются с помощью… вы угадали… LLM.
At a very high level, the workflow can be divided into three stages:
На очень высоком уровне рабочий процесс можно разделить на три этапа:
Предобработка данных / эмбеддинги: Этот этап включает хранение приватных данных (юридических документов в нашем примере), которые позже нужно будет извлекать. Обычно документы разбиваются на чанки, прогоняются через embedding-модель, а затем сохраняются в специализированной базе данных, называемой векторной БД. Сборка промпта / retrieval: Когда пользователь отправляет запрос (юридический вопрос в нашем случае), приложение собирает серию промптов для отправки в языковую модель. Скомпилированный промпт обычно объединяет: шаблон промпта, жёстко закодированный разработчиком; примеры валидных выходов, называемые few-shot examples; любую необходимую информацию, полученную из внешних API; и набор релевантных документов, извлечённых из векторной БД. Выполнение промпта / инференс: После того как промпты скомпилированы, они отправляются в предобученную LLM для инференса — включая как проприетарные модельные API, так и open-source или самостоятельно обученные модели. Некоторые разработчики на этом этапе также добавляют операционные системы — логирование, кэширование и валидацию.
This looks like a lot of work, but it’s usually easier than the alternative: training or fine-tuning the LLM itself. You don’t need a specialized team of ML engineers to do in-context learning. You also don’t need to host your own infrastructure or buy an expensive dedicated instance from OpenAI. This pattern effectively reduces an AI problem to a data engineering problem that most startups and big companies already know how to solve. It also tends to outperform fine-tuning for relatively small datasets—since a specific piece of information needs to occur at least ~10 times in the training set before an LLM will remember it through fine-tuning—and can incorporate new data in near real time.
Это выглядит как большой объём работы, но обычно это проще, чем альтернатива — обучение или дообучение самой LLM. Для in-context learning не нужна специализированная команда ML-инженеров. Также не нужно хостить собственную инфраструктуру или покупать дорогой выделенный инстанс у OpenAI. Этот паттерн фактически сводит AI-задачу к задаче data engineering, которую большинство стартапов и крупных компаний уже умеют решать. Он также, как правило, превосходит дообучение для относительно небольших датасетов — поскольку конкретный фрагмент информации должен встретиться в обучающей выборке хотя бы ~10 раз, прежде чем LLM запомнит его через дообучение, — и может включать новые данные практически в реальном времени.
One of the biggest questions around in-context learning is: What happens if we just change the underlying model to increase the context window? This is indeed possible, and it is an active area of research (e.g., see the Hyena paper or this recent post). But this comes with a number of tradeoffs—primarily that cost and time of inference scale quadratically with the length of the prompt. Today, even linear scaling (the best theoretical outcome) would be cost-prohibitive for many applications. A single GPT-4 query over 10,000 pages would cost hundreds of dollars at current API rates. So, we don’t expect wholesale changes to the stack based on expanded context windows, but we’ll comment on this more in the body of the post.
Один из главных вопросов вокруг in-context learning: что произойдёт, если мы просто изменим базовую модель, чтобы увеличить context window? Это действительно возможно и является активной областью исследований (см., например, статью Hyena или этот недавний пост). Но это сопряжено с рядом компромиссов — прежде всего тем, что стоимость и время инференса растут квадратично с длиной промпта. Сегодня даже линейное масштабирование (лучший теоретический результат) было бы непомерно дорогим для многих приложений. Один запрос к GPT-4 по 10 000 страниц стоил бы сотни долларов по текущим тарифам API. Поэтому мы не ожидаем кардинальных изменений в стеке из-за расширения context window, но прокомментируем это подробнее в основной части поста.
If you’d like to go deeper on in-context learning, there are a number of great resources in the AI canon (especially the “Practical guides to building with LLMs” section). In the remainder of this post, we’ll walk through the reference stack, using the workflow above as a guide.
Если вы хотите глубже погрузиться в in-context learning, есть множество отличных ресурсов в AI canon (особенно в разделе «Practical guides to building with LLMs»). В оставшейся части поста мы пройдёмся по референсному стеку, используя вышеописанный workflow в качестве ориентира.
Contextual data for LLM apps includes text documents, PDFs, and even structured formats like CSV or SQL tables. Data-loading and transformation solutions for this data vary widely across developers we spoke with. Most use traditional ETL tools like Databricks or Airflow. Some also use document loaders built into orchestration frameworks like LangChain (powered by Unstructured) and LlamaIndex (powered by Llama Hub). We believe this piece of the stack is relatively underdeveloped, though, and there’s an opportunity for data-replication solutions purpose-built for LLM apps.
Контекстные данные для LLM-приложений включают текстовые документы, PDF и даже структурированные форматы, такие как CSV или SQL-таблицы. Решения для загрузки и преобразования этих данных сильно различаются среди разработчиков, с которыми мы общались. Большинство использует традиционные ETL-инструменты вроде Databricks или Airflow. Некоторые также используют document loaders, встроенные в фреймворки оркестрации, такие как LangChain (работающий на базе Unstructured) и LlamaIndex (работающий на базе Llama Hub). Тем не менее мы считаем, что эта часть стека относительно слабо развита, и есть возможность для решений по репликации данных, специально созданных для LLM-приложений.
For embeddings, most developers use the OpenAI API, specifically with the text-embedding-ada-002 model. It’s easy to use (especially if you’re already already using other OpenAI APIs), gives reasonably good results, and is becoming increasingly cheap. Some larger enterprises are also exploring Cohere, which focuses their product efforts more narrowly on embeddings and has better performance in certain scenarios. For developers who prefer open-source, the Sentence Transformers library from Hugging Face is a standard. It’s also possible to create different types of embeddings tailored to different use cases; this is a niche practice today but a promising area of research.
Для эмбеддингов большинство разработчиков использует OpenAI API, в частности модель text-embedding-ada-002. Её легко использовать (особенно если вы уже используете другие API OpenAI), она даёт достаточно хорошие результаты и становится всё дешевле. Некоторые крупные предприятия также изучают Cohere, которые сильнее фокусируют свои продуктовые усилия именно на эмбеддингах и показывают лучшую производительность в определённых сценариях. Для разработчиков, предпочитающих open-source, стандартом является библиотека Sentence Transformers от Hugging Face. Также возможно создавать разные типы эмбеддингов, адаптированных под разные сценарии использования; сегодня это нишевая практика, но многообещающая область исследований.
The most important piece of the preprocessing pipeline, from a systems standpoint, is the vector database. It’s responsible for efficiently storing, comparing, and retrieving up to billions of embeddings (i.e., vectors). The most common choice we’ve seen in the market is Pinecone. It’s the default because it’s fully cloud-hosted—so it’s easy to get started with—and has many of the features larger enterprises need in production (e.g., good performance at scale, SSO, and uptime SLAs).
Самый важный компонент конвейера предобработки с системной точки зрения — это векторная БД. Она отвечает за эффективное хранение, сравнение и извлечение до миллиардов эмбеддингов (то есть векторов). Чаще всего на рынке мы видим Pinecone. Она стала выбором по умолчанию, потому что полностью облачная — то есть с ней легко начать — и обладает многими функциями, которые нужны крупным предприятиям в продакшене (например, хорошей производительностью при масштабировании, SSO и SLA по аптайму).
There’s a huge range of vector databases available, though. Notably:
Однако существует огромный спектр векторных БД. В частности:
Open-source системы вроде Weaviate, Vespa и Qdrant: Они, как правило, дают отличную производительность на одном узле и могут быть адаптированы под конкретные приложения, поэтому популярны среди опытных AI-команд, которые предпочитают строить собственные платформы. Локальные библиотеки управления векторами вроде Chroma и Faiss: У них отличный developer experience, их легко поднять для небольших приложений и экспериментов в разработке. Они не обязательно заменяют полноценную БД в масштабе. OLTP-расширения вроде pgvector: Для разработчиков, которые видят каждую дыру в форме БД и пытаются вставить туда Postgres, — или для предприятий, которые покупают большую часть своей data-инфраструктуры у одного облачного провайдера, — это хорошее решение для поддержки векторов. В долгосрочной перспективе неясно, имеет ли смысл тесно связывать векторные и скалярные нагрузки.
Looking ahead, most of the open source vector database companies are developing cloud offerings. Our research suggests achieving strong performance in the cloud, across a broad design space of possible use cases, is a very hard problem. Therefore, the option set may not change massively in the near term, but it likely will change in the long term. The key question is whether vector databases will resemble their OLTP and OLAP counterparts, consolidating around one or two popular systems.
Заглядывая вперёд, большинство компаний, разрабатывающих open-source векторные БД, создают облачные предложения. Наши исследования показывают, что достичь высокой производительности в облаке, в широком пространстве возможных сценариев использования, — очень сложная задача. Поэтому в ближайшей перспективе набор опций может не сильно измениться, но в долгосрочной — изменится наверняка. Ключевой вопрос: будут ли векторные БД похожи на свои OLTP- и OLAP-аналоги, консолидируясь вокруг одной-двух популярных систем.
Another open question is how embeddings and vector databases will evolve as the usable context window grows for most models. It’s tempting to say embeddings will become less relevant, because contextual data can just be dropped into the prompt directly. However, feedback from experts on this topic suggests the opposite—that the embedding pipeline may become more important over time. Large context windows are a powerful tool, but they also entail significant computational cost. So making efficient use of them becomes a priority. We may start to see different types of embedding models become popular, trained directly for model relevancy, and vector databases designed to enable and take advantage of this.
Ещё один открытый вопрос — как эмбеддинги и векторные БД будут эволюционировать по мере роста доступного context window у большинства моделей. Заманчиво сказать, что эмбеддинги станут менее актуальны, поскольку контекстные данные можно будет просто бросать прямо в промпт. Однако отзывы экспертов по этой теме говорят об обратном — что embedding-конвейер со временем может стать важнее. Большие context windows — мощный инструмент, но они влекут существенные вычислительные затраты. Поэтому эффективное их использование становится приоритетом. Мы можем начать видеть, как становятся популярными разные типы embedding-моделей, обученных специально под model relevancy, и векторные БД, спроектированные так, чтобы использовать это.
Strategies for prompting LLMs and incorporating contextual data are becoming increasingly complex—and increasingly important as a source of product differentiation. Most developers start new projects by experimenting with simple prompts, consisting of direct instructions (zero-shot prompting) or possibly some example outputs (few-shot prompting). These prompts often give good results but fall short of accuracy levels required for production deployments.
Стратегии промптинга LLM и включения контекстных данных становятся всё сложнее — и всё важнее как источник дифференциации продукта. Большинство разработчиков начинает новые проекты с экспериментов с простыми промптами, состоящими из прямых инструкций (zero-shot prompting) или, возможно, нескольких примеров выходов (few-shot prompting). Эти промпты часто дают хорошие результаты, но не дотягивают до уровней точности, необходимых для продакшен-развёртываний.
The next level of prompting jiu jitsu is designed to ground model responses in some source of truth and provide external context the model wasn’t trained on. The Prompt Engineering Guide catalogs no fewer than 12 (!) more advanced prompting strategies, including chain-of-thought, self-consistency, generated knowledge, tree of thoughts, directional stimulus, and many others. These strategies can also be used in conjunction to support different LLM use cases like document question answering, chatbots, etc.
Следующий уровень промптингового джиу-джитсу нацелен на то, чтобы привязать ответы модели к какому-то источнику истины и предоставить внешний контекст, на котором модель не обучалась. Prompt Engineering Guide каталогизирует не менее 12 (!) более продвинутых стратегий промптинга, включая chain-of-thought, self-consistency, generated knowledge, tree of thoughts, directional stimulus и многие другие. Эти стратегии также могут использоваться вместе, чтобы поддерживать различные сценарии использования LLM, такие как вопросно-ответные системы по документам, чат-боты и т. д.
This is where orchestration frameworks like LangChain and LlamaIndex shine. They abstract away many of the details of prompt chaining; interfacing with external APIs (including determining when an API call is needed); retrieving contextual data from vector databases; and maintaining memory across multiple LLM calls. They also provide templates for many of the common applications mentioned above. Their output is a prompt, or series of prompts, to submit to a language model. These frameworks are widely used among hobbyists and startups looking to get an app off the ground, with LangChain the leader.
Именно здесь блистают фреймворки оркестрации, такие как LangChain и LlamaIndex. Они абстрагируют многие детали prompt chaining; взаимодействие с внешними API (включая определение того, когда вызов API необходим); извлечение контекстных данных из векторных БД; и поддержание памяти между несколькими вызовами LLM. Они также предоставляют шаблоны для многих распространённых приложений, упомянутых выше. Их выход — это промпт или серия промптов для отправки в языковую модель. Эти фреймворки широко используются среди энтузиастов и стартапов, которые хотят поднять приложение, причём LangChain — лидер.
LangChain is still a relatively new project (currently on version 0.0.201), but we’re already starting to see apps built with it moving into production. Some developers, especially early adopters of LLMs, prefer to switch to raw Python in production to eliminate an added dependency. But we expect this DIY approach to decline over time for most use cases, in a similar way to the traditional web app stack.
LangChain пока относительно новый проект (сейчас на версии 0.0.201), но мы уже начинаем видеть, как приложения, построенные на нём, выходят в продакшен. Некоторые разработчики, особенно ранние адоптеры LLM, предпочитают переходить на чистый Python в продакшене, чтобы устранить лишнюю зависимость. Но мы ожидаем, что этот DIY-подход со временем будет сокращаться для большинства сценариев, аналогично тому, как это произошло с традиционным стеком веб-приложений.
Sharp-eyed readers will notice a seemingly weird entry in the orchestration box: ChatGPT. In its normal incarnation, ChatGPT is an app, not a developer tool. But it can also be accessed as an API. And, if you squint, it performs some of the same functions as other orchestration frameworks, such as: abstracting away the need for bespoke prompts; maintaining state; and retrieving contextual data via plugins, APIs, or other sources. While not a direct competitor to the other tools listed here, ChatGPT can be considered a substitute solution, and it may eventually become a viable, simple alternative to prompt construction.
Внимательные читатели заметят, казалось бы, странную запись в блоке оркестрации: ChatGPT. В своём обычном воплощении ChatGPT — это приложение, а не инструмент разработчика. Но к нему также можно обращаться как к API. И, если присмотреться, он выполняет некоторые те же функции, что и другие фреймворки оркестрации, например: абстрагирует необходимость в специализированных промптах; поддерживает состояние; и извлекает контекстные данные через плагины, API или другие источники. Не являясь прямым конкурентом другим перечисленным здесь инструментам, ChatGPT можно считать решением-заменителем, и со временем он может стать жизнеспособной простой альтернативой сборке промптов.
Today, OpenAI is the leader among language models. Nearly every developer we spoke with starts new LLM apps using the OpenAI API, usually with the gpt-4 or gpt-4-32k model. This gives a best-case scenario for app performance and is easy to use, in that it operates on a wide range of input domains and usually requires no fine-tuning or self-hosting.
Сегодня OpenAI — лидер среди языковых моделей. Почти каждый разработчик, с которым мы общались, начинает новые LLM-приложения с использования OpenAI API, обычно с модели gpt-4 или gpt-4-32k. Это даёт лучший сценарий по производительности приложения и легко в использовании — модель работает на широком спектре входных доменов и обычно не требует дообучения или самостоятельного хостинга.
When projects go into production and start to scale, a broader set of options come into play. Some of the common ones we heard include:
Когда проекты выходят в продакшен и начинают масштабироваться, в игру вступает более широкий набор опций. Вот некоторые из распространённых, которые мы слышали:
- This usually makes the most sense in conjunction with fine-tuning open source base models. We don’t go deep on that tooling stack in this article, but platforms like Databricks, Anyscale, Mosaic, Modal, and RunPod are used by a growing number of engineering teams.
- A variety of inference options are available for open source models, including simple API interfaces from Hugging Face and Replicate; raw compute resources from the major cloud providers; and more opinionated cloud offerings like those listed above.
Переход на 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 models trail proprietary offerings right now, but the gap is starting to close. The LLaMa models from Meta set a new bar for open source accuracy and kicked off a flurry of variants. Since LLaMa was licensed for research use only, a number of new providers have stepped in to train alternative base models (e.g., Together, Mosaic, Falcon, Mistral). Meta is also debating a truly open source release of LLaMa 2.
Open-source модели сейчас отстают от проприетарных предложений, но разрыв начинает сокращаться. Модели LLaMa от Meta установили новую планку точности для open-source и запустили волну производных. Поскольку LLaMa лицензировалась только для исследовательского использования, появился ряд новых провайдеров, обучающих альтернативные базовые модели (например, Together, Mosaic, Falcon, Mistral). Meta также обсуждает по-настоящему open-source релиз LLaMa 2.
When (not if) open source LLMs reach accuracy levels comparable to GPT-3.5, we expect to see a Stable Diffusion-like moment for text—including massive experimentation, sharing, and productionizing of fine-tuned models. Hosting companies like Replicate are already adding tooling to make these models easier for software developers to consume. There’s a growing belief among developers that smaller, fine-tuned models can reach state-of-the-art accuracy in narrow use cases.
Когда (не «если») open-source LLM достигнут уровней точности, сопоставимых с GPT-3.5, мы ожидаем увидеть момент в духе Stable Diffusion для текста — включая массовое экспериментирование, обмен и продуктовизацию дообученных моделей. Хостинговые компании вроде Replicate уже добавляют инструментарий, чтобы разработчикам ПО было проще использовать эти модели. Среди разработчиков растёт уверенность, что меньшие, дообученные модели могут достигать state-of-the-art точности в узких сценариях.
Most developers we spoke with haven’t gone deep on operational tooling for LLMs yet. Caching is relatively common—usually based on Redis—because it improves application response times and cost. Tools like Weights & Biases and MLflow (ported from traditional machine learning) or PromptLayer and Helicone (purpose-built for LLMs) are also fairly widely used. They can log, track, and evaluate LLM outputs, usually for the purpose of improving prompt construction, tuning pipelines, or selecting models. There are also a number of new tools being developed to validate LLM outputs (e.g., Guardrails) or detect prompt injection attacks (e.g., Rebuff). Most of these operational tools encourage use of their own Python clients to make LLM calls, so it will be interesting to see how these solutions coexist over time.
Большинство разработчиков, с которыми мы общались, ещё не сильно углубились в операционный тулинг для LLM. Кэширование относительно распространено — обычно на базе Redis — потому что улучшает время отклика приложения и стоимость. Инструменты вроде Weights & Biases и MLflow (перенесённые из традиционного machine learning) или PromptLayer и Helicone (созданные специально под LLM) также довольно широко используются. Они могут логировать, отслеживать и оценивать выходы LLM, обычно с целью улучшения сборки промптов, тюнинга пайплайнов или выбора моделей. Также разрабатывается ряд новых инструментов для валидации выходов LLM (например, Guardrails) или обнаружения атак prompt injection (например, Rebuff). Большинство этих операционных инструментов поощряют использование собственных Python-клиентов для вызова LLM, поэтому будет интересно посмотреть, как со временем эти решения сосуществуют.
Finally, the static portions of LLM apps (i.e. everything other than the model) also need to be hosted somewhere. The most common solutions we’ve seen so far are standard options like Vercel or the major cloud providers. However, two new categories are emerging. Startups like Steamship provide end-to-end hosting for LLM apps, including orchestration (LangChain), multi-tenant data contexts, async tasks, vector storage, and key management. And companies like Anyscale and Modal allow developers to host models and Python code in one place.
Наконец, статические части LLM-приложений (т. е. всё, кроме модели) тоже нужно где-то хостить. Самые распространённые решения, которые мы видели до сих пор, — это стандартные опции вроде Vercel или крупных облачных провайдеров. Однако появляются две новые категории. Стартапы вроде Steamship предоставляют end-to-end хостинг для LLM-приложений, включая оркестрацию (LangChain), мультитенантные контексты данных, асинхронные задачи, векторное хранилище и управление ключами. А компании вроде Anyscale и Modal позволяют разработчикам хостить модели и Python-код в одном месте.
What about agents?
А что насчёт агентов?
The most important components missing from this reference architecture are AI agent frameworks. AutoGPT, described as “an experimental open-source attempt to make GPT-4 fully autonomous,” was the fastest-growing Github repo in history this spring, and practically every AI project or startup out there today includes agents in some form.
Самые важные компоненты, отсутствующие в этой референсной архитектуре, — это фреймворки AI-агентов. AutoGPT, описанный как «экспериментальная open-source попытка сделать GPT-4 полностью автономным», стал этой весной самым быстрорастущим репозиторием Github в истории, и практически каждый AI-проект или стартап сегодня в той или иной форме включает агентов.
Most developers we speak with are incredibly excited about the potential of agents. The in-context learning pattern we describe in this post is effective at solving hallucination and data-freshness problems, in order to better support content-generation tasks. Agents, on the other hand, give AI apps a fundamentally new set of capabilities: to solve complex problems, to act on the outside world, and to learn from experience post-deployment. They do this through a combination of advanced reasoning/planning, tool usage, and memory / recursion / self-reflection.
Большинство разработчиков, с которыми мы общаемся, невероятно воодушевлены потенциалом агентов. Паттерн in-context learning, который мы описываем в этом посте, эффективен в решении проблем галлюцинаций и устаревания данных, чтобы лучше поддерживать задачи генерации контента. Агенты же дают AI-приложениям принципиально новый набор возможностей: решать сложные задачи, действовать во внешнем мире и учиться на опыте после развёртывания. Они делают это благодаря комбинации продвинутого рассуждения/планирования, использования инструментов и памяти / рекурсии / саморефлексии.
So, agents have the potential to become a central piece of the LLM app architecture (or even take over the whole stack, if you believe in recursive self-improvement). And existing frameworks like LangChain have incorporated some agent concepts already. There’s only one problem: agents don’t really work yet. Most agent frameworks today are in the proof-of-concept phase—capable of incredible demos but not yet reliable, reproducible task-completion. We’re keeping an eye on how they develop in the near future.
Поэтому у агентов есть потенциал стать центральным элементом архитектуры LLM-приложений (или даже захватить весь стек, если вы верите в рекурсивное самоулучшение). И существующие фреймворки вроде LangChain уже включили некоторые концепции агентов. Есть только одна проблема: агенты пока толком не работают. Большинство фреймворков агентов сегодня находятся на стадии proof-of-concept — они способны на впечатляющие демо, но пока не на надёжное, воспроизводимое выполнение задач. Мы следим за тем, как они будут развиваться в ближайшем будущем.
Looking ahead
Заглядывая вперёд
Pre-trained AI models represent the most important architectural change in software since the internet. They make it possible for individual developers to build incredible AI apps, in a matter of days, that surpass supervised machine learning projects that took big teams months to build.
Предобученные AI-модели представляют собой самое важное архитектурное изменение в ПО со времён интернета. Они позволяют отдельным разработчикам за считанные дни создавать невероятные AI-приложения, превосходящие проекты на основе обучения с учителем, на которые большие команды тратили месяцы.
The tools and patterns we’ve laid out here are likely the starting point, not the end state, for integrating LLMs. We’ll update this as major changes take place (e.g., a shift toward model training) and release new reference architectures where it makes sense. Please reach out if you have any feedback or suggestions.
Инструменты и паттерны, которые мы изложили здесь, — скорее отправная точка, чем конечное состояние интеграции LLM. Мы будем обновлять это по мере крупных изменений (например, при сдвиге в сторону обучения моделей) и публиковать новые референсные архитектуры там, где это имеет смысл. Пожалуйста, свяжитесь с нами, если у вас есть отзывы или предложения.
Matt Bornstein
Matt Bornstein
is a general partner at Andreessen Horowitz focused on AI and data systems.
— генеральный партнёр Andreessen Horowitz, фокусирующийся на AI и системах данных.
Rajko Radovanovic
Rajko Radovanovic
is an investing partner on the infrastructure team at Andreessen Horowitz, where he focuses on AI and infrastructure.
— инвестиционный партнёр в инфраструктурной команде Andreessen Horowitz, где он фокусируется на AI и инфраструктуре.
Want More Infra?
Хотите больше про инфру?
Analysis and news covering the latest trends reshaping AI and infrastructure.
Аналитика и новости о последних трендах, меняющих AI и инфраструктуру.
Views expressed in “posts” (including podcasts, videos, and social media) are those of the individual a16z personnel quoted therein and are not the views of a16z Capital Management, L.L.C. (“a16z”) or its respective affiliates. a16z Capital Management is an investment adviser registered with the Securities and Exchange Commission. Registration as an investment adviser does not imply any special skill or training. The posts are not directed to any investors or potential investors, and do not constitute an offer to sell — or a solicitation of an offer to buy — any securities, and may not be used or relied upon in evaluating the merits of any investment.
Мнения, выраженные в «постах» (включая подкасты, видео и социальные сети), принадлежат отдельным сотрудникам a16z, цитируемым в них, и не являются мнениями a16z Capital Management, L.L.C. («a16z») или её соответствующих аффилированных лиц. a16z Capital Management — инвестиционный консультант, зарегистрированный в Комиссии по ценным бумагам и биржам. Регистрация в качестве инвестиционного консультанта не подразумевает каких-либо особых навыков или подготовки. Посты не адресованы каким-либо инвесторам или потенциальным инвесторам и не являются предложением о продаже — или приглашением сделать предложение о покупке — каких-либо ценных бумаг, и не могут использоваться или приниматься во внимание при оценке достоинств любых инвестиций.
The contents in here — and available on any associated distribution platforms and any public a16z online social media accounts, platforms, and sites (collectively, “content distribution outlets”) — should not be construed as or relied upon in any manner as investment, legal, tax, or other advice. You should consult your own advisers as to legal, business, tax, and other related matters concerning any investment. Any projections, estimates, forecasts, targets, prospects and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Any charts provided here or on a16z content distribution outlets are for informational purposes only, and should not be relied upon when making any investment decision. Certain information contained in here has been obtained from third-party sources, including from portfolio companies of funds managed by a16z. While taken from sources believed to be reliable, a16z has not independently verified such information and makes no representations about the enduring accuracy of the information or its appropriateness for a given situation. In addition, posts may include third-party advertisements; a16z has not reviewed such advertisements and does not endorse any advertising content contained therein. All content speaks only as of the date indicated.
Содержимое здесь — и доступное на любых связанных платформах распространения и любых публичных онлайн-аккаунтах, платформах и сайтах a16z в социальных сетях (совместно — «каналы распространения контента») — не должно толковаться или приниматься во внимание каким-либо образом как инвестиционная, юридическая, налоговая или иная консультация. Вам следует консультироваться с собственными советниками по юридическим, деловым, налоговым и другим связанным вопросам, касающимся любых инвестиций. Любые проекции, оценки, прогнозы, цели, перспективы и/или мнения, выраженные в этих материалах, могут быть изменены без уведомления и могут отличаться от мнений, выраженных другими, или противоречить им. Любые графики, предоставленные здесь или на каналах распространения контента a16z, носят исключительно информационный характер и не должны приниматься во внимание при принятии каких-либо инвестиционных решений. Определённая информация, содержащаяся здесь, была получена из сторонних источников, включая портфельные компании фондов, управляемых a16z. Хотя она взята из источников, считающихся надёжными, a16z не проверяла такую информацию независимо и не делает заявлений о её устойчивой точности или применимости в данной ситуации. Кроме того, посты могут включать рекламу третьих сторон; a16z не рассматривала такую рекламу и не одобряет какой-либо рекламный контент, содержащийся в ней. Весь контент актуален только на указанную дату.
Under no circumstances should any posts or other information provided on this website — or on associated content distribution outlets — be construed as an offer soliciting the purchase or sale of any security or interest in any pooled investment vehicle sponsored, discussed, or mentioned by a16z personnel. Nor should it be construed as an offer to provide investment advisory services; an offer to invest in an a16z-managed pooled investment vehicle will be made separately and only by means of the confidential offering documents of the specific pooled investment vehicles — which should be read in their entirety, and only to those who, among other requirements, meet certain qualifications under federal securities laws. Such investors, defined as accredited investors and qualified purchasers, are generally deemed capable of evaluating the merits and risks of prospective investments and financial matters.
Ни при каких обстоятельствах любые посты или иная информация, предоставленная на этом сайте — или на связанных каналах распространения контента — не должны толковаться как предложение, побуждающее к покупке или продаже какой-либо ценной бумаги или доли в любом объединённом инвестиционном инструменте, спонсируемом, обсуждаемом или упомянутом сотрудниками a16z. Также это не должно толковаться как предложение по предоставлению услуг инвестиционного консультирования; предложение инвестировать в объединённый инвестиционный инструмент, управляемый a16z, будет сделано отдельно и исключительно посредством конфиденциальных предлагаемых документов конкретных объединённых инвестиционных инструментов, которые должны быть прочитаны полностью и только теми, кто, среди прочих требований, соответствует определённым квалификациям согласно федеральному законодательству о ценных бумагах. Такие инвесторы, определяемые как аккредитованные инвесторы и квалифицированные покупатели, как правило, считаются способными оценить достоинства и риски потенциальных инвестиций и финансовых вопросов.
There can be no assurances that a16z’s investment objectives will be achieved or investment strategies will be successful. Any investment in a vehicle managed by a16z involves a high degree of risk including the risk that the entire amount invested is lost. Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by a16z and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by a16z is available here: https://a16z.com/investments/. Past results of a16z’s investments, pooled investment vehicles, or investment strategies are not necessarily indicative of future results. Excluded from this list are investments (and certain publicly traded cryptocurrencies/ digital assets) for which the issuer has not provided permission for a16z to disclose publicly. As for its investments in any cryptocurrency or token project, a16z is acting in its own financial interest, not necessarily in the interests of other token holders. a16z has no special role in any of these projects or power over their management. a16z does not undertake to continue to have any involvement in these projects other than as an investor and token holder, and other token holders should not expect that it will or rely on it to have any particular involvement.
Не может быть никаких гарантий того, что инвестиционные цели a16z будут достигнуты или что инвестиционные стратегии будут успешны. Любые инвестиции в инструмент, управляемый a16z, сопряжены с высоким уровнем риска, включая риск потери всей вложенной суммы. Любые упомянутые, указанные или описанные инвестиции или портфельные компании не являются репрезентативными для всех инвестиций в инструменты, управляемые a16z, и не может быть никакой гарантии, что инвестиции будут прибыльными или что другие инвестиции, сделанные в будущем, будут иметь аналогичные характеристики или результаты. Список инвестиций, сделанных фондами, управляемыми a16z, доступен здесь: https://a16z.com/investments/. Прошлые результаты инвестиций a16z, объединённых инвестиционных инструментов или инвестиционных стратегий не обязательно указывают на будущие результаты. Из этого списка исключены инвестиции (и определённые публично торгуемые криптовалюты/цифровые активы), для которых эмитент не предоставил разрешения a16z раскрывать публично. В отношении своих инвестиций в любой криптовалютный или токен-проект a16z действует в своих собственных финансовых интересах, не обязательно в интересах других держателей токенов. a16z не играет особой роли ни в одном из этих проектов и не имеет власти над их управлением. a16z не обязуется продолжать участвовать в этих проектах кроме как в качестве инвестора и держателя токенов, и другие держатели токенов не должны ожидать, что она будет это делать, или полагаться на её какое-либо конкретное участие.
With respect to funds managed by a16z that are registered in Japan, a16z will provide to any member of the Japanese public a copy of such documents as are required to be made publicly available pursuant to Article 63 of the Financial Instruments and Exchange Act of Japan. Please contact compliance@a16z.com to request such documents.
В отношении фондов, управляемых a16z, зарегистрированных в Японии, a16z предоставит любому члену японской общественности копию документов, которые требуется сделать публично доступными согласно статье 63 Закона Японии о финансовых инструментах и биржах. Пожалуйста, свяжитесь по адресу compliance@a16z.com, чтобы запросить такие документы.
For other site terms of use, please go here. Additional important information about a16z, including our Form ADV Part 2A Brochure, is available at the SEC’s website: http://www.adviserinfo.sec.gov.
Для других условий использования сайта, пожалуйста, перейдите сюда. Дополнительная важная информация о a16z, включая нашу Form ADV Part 2A Brochure, доступна на сайте SEC: http://www.adviserinfo.sec.gov.