Uma nova arquitetura para aplicações com LLM
(a16z.com)- A a16z organizou a "arquitetura de referência para a stack de apps com LLM"
Emerging LLM App Stack
Dados contextuais
- Data Pipelines: Databricks, Airflow, Unstructured,..
- Embedding Model: OpenAI, Cohere, Hugging Face
- Vector Database: Pinecone, Weaviate, Chroma, pgvector
Exemplos few-shot de prompt
- Playground: OpenAI, nat.dev, Humanloop
- Orchestration: Pytion/DIY, LangChain, LlamaIndex, ChatGPT
- APIs/Plugins: Serp, Wolfram, Zapier,...
Consulta e saída
- App Hosting: Vercel, Steamship, Streamlit, Modal
- LLM Cache: Redis, SQLite, GPTCache
- Logging/LLMops: Weights & Biases, MLflow, PromptLayer, Helicone
- Validation: Guardrails, Rebuff, Guidance, LMQL
APIs de LLM e hospedagem
- Proprietary API: OpenAI, Anthropic
- Open API: Hugging Face, Replicate
- Cloud Provider: AWS, GCP, Azure, Coreweave
- Opinionated Cloud: Databricks, Anyscale, Mosaic, Modal, Runpod,...
Padrão de design: In-context Learning
- In-Context Learning: usar o LLM como está, sem fine-tuning, aproveitando prompting inteligente e condições baseadas em alguns dados "contextuais"
- Ex.) ao criar um chatbot que responde sobre documentos jurídicos, uma abordagem ingênua seria simplesmente colocar todos os documentos no ChatGPT e fazer a pergunta, mas isso só funciona com datasets pequenos. Até o maior modelo do ChatGPT só consegue processar cerca de 50 páginas
No In-Context Learning, adota-se a abordagem de enviar apenas os documentos relevantes e obter a resposta a partir deles - Por isso, ele é composto pelo seguinte fluxo de trabalho em 3 etapas
- Etapa 1. pré-processamento dos dados / embedding
- Etapa 2. criação do prompt / retrieval de documentos relevantes no banco vetorial
- Etapa 3. execução do prompt / inferência
- Pode parecer que dá muito trabalho, mas ainda assim é muito mais fácil do que treinar e fazer fine-tuning do próprio LLM
Etapa 1. [Pré-processamento de dados / embedding]
→ Os dados contextuais passam por um Data Pipeline, depois por um Embedding Model, e são armazenados em um Vector Database
Dados contextuais
- Documentos de texto, PDFs, CSVs e tabelas SQL
- Na maioria dos casos, o carregamento e a transformação dos dados continuam usando ferramentas ETL existentes (Databricks, Airflow)
- Em alguns casos, usa-se o document loader embutido em frameworks de orquestração como LangChain e LlamaIndex
- Considera-se que esta parte da stack ainda está relativamente menos desenvolvida, e há oportunidade para soluções de replicação de dados feitas especificamente para apps com LLM
Embeddings
- A maioria dos desenvolvedores usa a API da OpenAI (
text-embedding-ada-002)- É fácil de usar, entrega resultados razoavelmente bons e vem ficando cada vez mais barata
- Algumas empresas maiores estão explorando a Cohere. Em certos cenários, ela oferece desempenho melhor
- Desenvolvedores que preferem open source costumam adotar a biblioteca Sentence Transformers, da Hugging Face, como padrão
- Também é possível gerar vários tipos de embeddings adequados ao caso de uso
- Esse é um caso mais de nicho, mas é uma área promissora de pesquisa
Banco vetorial
- A parte mais importante do pipeline de pré-processamento é o banco de dados vetorial
- Ele é responsável por armazenar, comparar e pesquisar com eficiência até dezenas de bilhões de embeddings (vetores)
- A escolha mais comum no mercado é o Pinecone
- É totalmente hospedado em nuvem, então é fácil começar
- Tem muitos recursos necessários para produção em grandes empresas (bom desempenho, SSO, SLA de uptime etc.)
- Mas existe uma enorme quantidade de bancos vetoriais disponíveis. Em especial:
- Open source como Weaviate, Vespa e Qdrant
- Oferecem excelente desempenho em nó único e podem ser ajustados para apps específicos
- São populares entre equipes de IA experientes que preferem construir plataformas sob medida
- Bibliotecas locais de gerenciamento vetorial como Chroma e Faiss
- Oferecem ótima experiência para desenvolvedores
- São fáceis de operar para apps pequenos e experimentos de desenvolvimento
- Não servem para substituir um banco de dados completo em grande escala
- Extensões OLTP como pgvector
- São uma boa solução de suporte vetorial para desenvolvedores que querem encaixar o Postgres em todas as necessidades de banco de dados, ou para empresas que compram a maior parte da infraestrutura de dados de um único provedor de nuvem
- No longo prazo, não está claro se faz sentido acoplar de forma tão rígida workloads vetoriais e escalares
- Open source como Weaviate, Vespa e Qdrant
- Olhando para frente, a maioria das empresas de banco vetorial open source está desenvolvendo produtos em nuvem
- Segundo nossa pesquisa, é muito difícil entregar ótimo desempenho na nuvem para casos de uso variados
- Por isso, essa escolha pode não mudar no curto prazo, mas há grande chance de mudar no longo prazo
- A pergunta central é se os bancos vetoriais vão se consolidar em um ou dois sistemas famosos, como aconteceu nos casos de OLTP e OLAP
- Outra questão é como embeddings e bancos vetoriais vão evoluir à medida que a janela de contexto disponível na maioria dos modelos aumentar
- É tentador dizer que embeddings deixarão de ser necessários, já que seria possível colocar todos os dados contextuais no prompt,
- mas o feedback de especialistas é que o pipeline de embeddings pode se tornar ainda mais importante
- Janelas de contexto grandes são uma ferramenta poderosa, mas trazem custo computacional considerável. Por isso, o mais importante é usá-las com eficiência
- Agora começaremos a ver vários tipos de modelos de embedding se popularizarem, sendo treinados diretamente com relevância do modelo, além de bancos vetoriais capazes de ativá-los e aproveitá-los de forma eficiente
Etapa 2. [Construção do prompt / retrieval]
- As estratégias para integrar prompting de LLM com dados adequados ao contexto estão ficando cada vez mais complexas e se tornando cada vez mais importantes como fonte de diferenciação de produto
- A maioria dos desenvolvedores começa novos projetos com prompts simples, compostos por instruções diretas (zero-shot prompting) ou com alguns exemplos incluídos (few-shot prompting)
- Esses prompts às vezes produzem bons resultados, mas não alcançam o nível de precisão necessário para implantação em produção
- O próximo estágio do prompting é projetar o sistema para ancorar a resposta do modelo em alguma fonte de verdade e fornecer contexto externo no qual o modelo não foi treinado
- O Prompt Engineering Guide resume 12 estratégias avançadas de prompt
- É aqui que frameworks de orquestração como LangChain e LlamaIndex brilham
- Eles abstraem muitos detalhes do prompt chaining
- como integração com APIs externas, busca de dados contextuais em bancos vetoriais e manutenção de memória entre múltiplas chamadas ao LLM
- Também oferecem templates para muitos programas comuns
- A saída deles é um prompt, ou vários prompts, a serem enviados ao modelo de linguagem
- Entre startups e desenvolvedores hobby, o LangChain é o mais usado
- O LangChain ainda é um projeto novo (versão atual 0.0.220)
- Mas já começa a aparecer app em produção construído com ele
- Alguns desenvolvedores, especialmente early adopters de LLM, preferem migrar para Python puro em produção para remover dependências
- Mas acreditamos que essa abordagem DIY vai diminuir gradualmente, como aconteceu na stack de apps web (a maioria acaba usando frameworks)
- Leitores atentos devem ter notado que há ChatGPT na caixa de orquestração
- Em geral, o ChatGPT não é uma ferramenta de desenvolvedor, e sim um app, mas pode ser acessado por API
- De certa forma, ele realiza operações parecidas com essas frameworks de orquestração (abstração de prompt, manutenção de estado, busca de dados contextuais via plugins etc.)
- Não é um concorrente direto das ferramentas discutidas aqui, mas o ChatGPT pode ser considerado uma solução alternativa. Pode ser uma alternativa simples, rápida de configurar e usar
Etapa 3. [Execução do prompt / inferência]
- No momento, a OpenAI é líder entre os modelos de linguagem
- Quase todos os desenvolvedores começam a criar apps com LLM usando GPT-4 e GPT-4-32k
- São fáceis de usar, aplicáveis a vários domínios e não exigem fine-tuning nem self-hosting
- Quando entram em produção e ganham escala, várias opções passam a ser possíveis
- Migrar para
gpt-3.5-turbo:- É mais de 50 vezes mais barato e muito mais rápido que o GPT-4
- É a escolha quando não é necessário o nível de precisão do GPT-4, quando é preciso resposta rápida ou suporte eficiente para usuários gratuitos
- Experimentar modelos de outros fornecedores (especialmente Claude, da Anthropic)
- O Claude oferece inferência rápida, precisão no nível do GPT-3.5, mais opções de customização e janela de contexto de até 100k (embora a precisão caia quando ela fica longa)
- Direcionar algumas requisições para modelos open source
- Isso pode ser eficiente em casos de uso B2C em larga escala, como busca/chat, com diferentes níveis de complexidade de consulta ou necessidade de atender usuários gratuitos a baixo custo
- Migrar para
- Os modelos open source ainda estão correndo atrás das soluções proprietárias, mas a diferença começa a diminuir
- O modelo LLaMA, da Meta, estabeleceu um novo padrão de precisão em open source e levou ao surgimento de várias derivações
- A LLaMA foi liberada apenas para pesquisa, mas muitos fornecedores passaram a participar do treinamento de modelos-base alternativos (Together, Mosaic, Falcon, Mistral)
- A Meta está em discussão para lançar o modelo LLaMa 2 como open source de verdade
- Quando os LLMs open source alcançarem um nível de precisão semelhante ao GPT-3.5, podemos esperar no texto algo equivalente ao momento do Stable Diffusion
- experimentação em larga escala, compartilhamento e produção de modelos ajustados de forma fina
- Empresas de hospedagem como a Replicate já estão adicionando ferramentas para facilitar o uso desses modelos pelos desenvolvedores
- Cresce entre os desenvolvedores a crença de que modelos menores, mas ajustados de forma fina, podem alcançar a precisão de modelos de ponta
- A maioria dos desenvolvedores com quem conversamos ainda não entrou a fundo em ferramentas operacionais para LLM
- Caching é comum e normalmente é feito com Redis (porque melhora tempo de resposta e custo)
- Ferramentas como Weights & Biases, MLFlow, PromptLayer e Helicone também são muito usadas
- Elas permitem registrar, rastrear e avaliar saídas de LLM para criação rápida de prompts, tuning de pipelines e escolha de modelos
- Também estão surgindo bastante ferramentas para validar saídas de LLM (Guardrails) ou detectar prompt injection (Rebuff)
- Como a maioria dessas ferramentas operacionais recomenda usar seu próprio cliente Python para fazer chamadas ao LLM, será interessante observar como vão coexistir no futuro
- Por fim, a parte estática do LLM (tudo exceto o modelo) também precisa ser hospedada em algum lugar
- As soluções mais comuns são Vercel e os principais provedores de nuvem
- Mas duas novas categorias estão surgindo
- A Steamship oferece hospedagem end-to-end para apps com LLM, com recursos como orquestração (LangChain), contexto de dados multi-tenant, tarefas assíncronas, vector store, gerenciamento de chaves etc.
- Anyscale e Modal permitem que desenvolvedores hospedem ao mesmo tempo o modelo e o código Python
E os agentes?
- O elemento mais importante que falta nessa arquitetura de referência é o framework de AI agents
- O AutoGPT foi o repositório do GitHub com crescimento mais rápido da história nesta primavera, como um "experimento open source para tornar o GPT-4 totalmente autônomo"
- Hoje em dia, todo projeto de IA inclui agentes de alguma forma
- A maioria dos desenvolvedores com quem conversamos está extremamente empolgada com o potencial dos agentes
- O padrão de in-context learning descrito neste texto dá melhor suporte a tarefas de geração de conteúdo e é útil para resolver problemas de alucinação e atualização de dados
- Já os agentes oferecem capacidades fundamentalmente novas para apps de IA
- como resolver problemas complexos, agir sobre o mundo externo ou aprender com a experiência mesmo após o deploy
- fazem isso por meio da combinação de raciocínio/planejamento avançado, uso de ferramentas, memória/recursão/self-reflection etc.
- Os agentes têm potencial para se tornar a parte central da arquitetura de apps com LLM (e, se você acreditar em autoaperfeiçoamento por recursão, podem até ocupar a stack inteira)
- Frameworks como LangChain já incorporaram o conceito de agentes
- Há apenas um problema: os agentes ainda não funcionam direito
- Atualmente, a maioria dos frameworks de agentes está na fase de PoC — demos impressionantes são possíveis, mas ainda não são estáveis nem reproduzíveis
- Estamos observando atentamente como eles vão evoluir
Olhando para frente
- Modelos de IA pré-treinados representam a mudança arquitetural mais importante do software desde a internet
- Com isso, cada desenvolvedor pode construir em poucos dias apps de IA que superam projetos de machine learning supervisionado que grandes equipes levariam meses para criar
- As ferramentas e os padrões apresentados aqui provavelmente não são o estado final, mas apenas o ponto de partida para a integração de LLMs
6 comentários
Parece um texto com profundidade e bons insights.
Acho que isso vai ajudar bastante no desenho da arquitetura de aplicações com LLM com base nesse conteúdo.
Como ainda não há vencedores claramente definidos por área no ecossistema, muitas soluções acabam coexistindo,
o que aumenta os dilemas de escolha, e parece que estamos chegando a um ponto em que a capacidade de encontrar a combinação certa para as suas necessidades passa a ser uma competência em si.
Este texto é muito rico em conteúdo. Estou lendo com calma.
Será que, se treinarmos o GN no LLM, até o Guru vai ficar mais à vontade? ^^;
Obrigado.
Ah, então vocês criaram o GN+ :-o
Acho que vai ficar mais conveniente, mas esse tipo de texto eu provavelmente vou continuar lendo como forma de estudo. hehe
Se o GN⁺ processar todas as outras notícias, isso pode até fazer com que apareçam ainda mais textos assim!
Obrigado pelo ótimo texto e pelo resumo.