A16Z: uma arquitetura emergente para aplicações de modelos grandes

Nota do editor: A explosão da inteligência artificial generativa tem o potencial de causar disrupção em muitos setores, um dos quais é o de software. A ascensão do modelo de linguagem grande (LLM) deu início à explosão de aplicativos relacionados. Gigantes da tecnologia e startups lançaram vários aplicativos LLM. Então, que tipo de ferramentas e padrões de design esses aplicativos usam? Este artigo resume. O artigo é de compilação.

Fonte da imagem: Gerada por Unbounded AI

Modelos de linguagem grande (LLMs) são novas primitivas poderosas para o desenvolvimento de software. Mas como o LLM é tão novo e se comporta de maneira tão diferente dos recursos de computação normais, nem sempre é óbvio como usar o LLM.

Neste artigo, compartilharemos uma arquitetura de referência para a pilha de aplicativos LLM emergente. A arquitetura mostrará os sistemas, ferramentas e padrões de design mais comuns que vimos sendo usados por startups de IA e empresas de tecnologia de ponta. Essa pilha de tecnologia ainda é relativamente primitiva e pode sofrer grandes mudanças à medida que a tecnologia subjacente avança, mas esperamos que possa fornecer uma referência útil para desenvolvedores que trabalham no desenvolvimento de LLM hoje.

Este trabalho é baseado em conversas com fundadores e engenheiros de startups de IA. Em particular, contamos com contribuições de pessoas como 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 e Jared Zoneraich. Obrigado pela ajuda!

Pilha de tecnologia LLM

A versão atual da pilha de aplicativos LLM tem esta aparência:

As caixas cinzas são os principais componentes e as com setas representam diferentes fluxos de dados: a linha pontilhada preta são os dados de contexto fornecidos pelo desenvolvedor do aplicativo para limitar a saída, a linha sólida preta é o prompt e alguns exemplos de amostra passados para o LLM , e a linha sólida azul é a consulta do usuário, a linha sólida vermelha é a saída retornada ao usuário

Abaixo está uma lista de links para cada item para referência rápida:

, ferramentas/sistemas comuns para cada componente-chave da pilha de aplicativos

Há muitas maneiras de desenvolver com o LLM, incluindo modelos de treinamento desde o início, ajuste fino de modelos de código aberto ou alavancagem de APIs gerenciadas. A pilha de tecnologia que apresentamos aqui é baseada no aprendizado no contexto, um padrão de design que observamos que a maioria dos desenvolvedores está começando a aproveitar (e atualmente só é possível com modelos básicos).

A próxima seção explica resumidamente esse padrão de projeto.

Padrão de Design: Aprendizagem Contextual

A ideia central do aprendizado contextual é alavancar LLMs prontos para uso (ou seja, sem qualquer ajuste fino) e, em seguida, controlar seu comportamento por meio de dicas inteligentes e condicionamento de dados de "contexto" privados.

Por exemplo, digamos que você esteja desenvolvendo um chatbot para responder a perguntas sobre uma série de documentos legais. A maneira simples, você pode colar todos os documentos no prompt ChatGPT ou GPT-4 e, em seguida, fazer perguntas relacionadas. Isso pode funcionar para conjuntos de dados muito pequenos, mas não é dimensionável. Os maiores modelos GPT-4 podem lidar apenas com cerca de 50 páginas de texto de entrada, e o desempenho (medido pelo tempo de inferência e precisão) diminui drasticamente ao se aproximar do chamado limite da janela de contexto.

O aprendizado de contexto resolve esse problema com um truque bacana: em vez de enviar todos os documentos toda vez que um prompt do LLM é inserido, ele envia apenas os poucos mais relevantes. Quem ajudará a decidir quais são os documentos mais relevantes? Você adivinhou... LLM.

Em um nível muito alto, esse fluxo de trabalho pode ser dividido em três fases:

• Pré-processamento/incorporação de dados: Esta fase armazena dados privados (documentos legais neste caso) para recuperação posterior. Em geral, os documentos são divididos em blocos, passados para o modelo de incorporação e armazenados em um banco de dados especial chamado banco de dados vetorial.
• Construção/recuperação de prompt: quando um usuário envia uma consulta (neste caso, uma questão legal), o aplicativo constrói uma série de prompts, que são então submetidos ao modelo de linguagem. As dicas compiladas geralmente são combinadas com modelos de dica codificados pelo desenvolvedor; exemplos de saída válida são chamados de exemplos de poucos disparos; qualquer informação necessária é recuperada por meio de uma API externa; e um conjunto de documentos relacionados é recuperado de um banco de dados vetorial.
• Execução/inferência de dica: depois que as dicas são compiladas, elas são enviadas para LLMs pré-treinados para inferência, incluindo APIs de modelo proprietário, bem como modelos de código aberto ou autotreinados. Durante esta fase, alguns desenvolvedores também adicionam sistemas operacionais, como log, cache e validação.

Isso pode parecer muito trabalhoso, mas geralmente é mais fácil de implementar do que as alternativas: treinar o LLM ou ajustar o próprio LLM é realmente mais difícil. Você não precisa de uma equipe dedicada de engenheiros de aprendizado de máquina para fazer o aprendizado contextual. Você também não precisa hospedar sua própria infraestrutura ou comprar instâncias dedicadas caras da OpenAI. Esse modelo efetivamente reduz os problemas de IA a problemas de engenharia de dados que a maioria das startups e grandes corporações já sabem como resolver. Ele também tende a superar o ajuste fino para conjuntos de dados relativamente pequenos, uma vez que informações específicas precisam ter ocorrido pelo menos cerca de 10 vezes no conjunto de treinamento antes que o LLM possa ser ajustado para lembrar informações específicas, e o aprendizado contextual também pode incorporar novas informações dados quase em tempo real.

Uma das maiores questões no aprendizado de contexto é: o que acontece se apenas mudarmos o modelo subjacente para aumentar a janela de contexto? É de fato possível e é uma área ativa de pesquisa. Mas isso vem com algumas compensações - principalmente o custo e o tempo das escalas de inferência quadraticamente com o comprimento da dica. Hoje, mesmo o escalonamento linear (o melhor resultado teórico) é muito caro para muitas aplicações. Nas taxas atuais da API, uma única consulta GPT-4 em 10.000 páginas custaria centenas de dólares. Portanto, não prevemos mudanças em grande escala na pilha com base em janelas de contexto estendidas, mas detalharemos isso mais tarde.

No restante deste artigo, percorreremos essa pilha de tecnologia usando o fluxo de trabalho acima como guia.

Processamento/incorporação de dados

Parte de processamento/incorporação de dados: passe os dados para o modelo incorporado por meio do pipeline de dados para vetorização e, em seguida, armazene-os no banco de dados de vetores

Dados de contexto para aplicativos LLM incluem documentos de texto, PDFs e até mesmo formatos estruturados como CSV ou tabelas SQL. As soluções de carregamento e transformação de dados (ETL) empregadas pelos desenvolvedores que entrevistamos variaram muito. A maioria usa ferramentas ETL tradicionais, como Databricks ou Airflow. Alguns também aproveitam os carregadores de documentos incorporados à estrutura de orquestração, como LangChain (desenvolvido por Unstructed) e LlamaIndex (desenvolvido por Llama Hub). No entanto, acreditamos que esta parte da pilha de tecnologia é relativamente subdesenvolvida e há uma oportunidade de desenvolver uma solução de replicação de dados especificamente para aplicativos LLM.

Quanto à embedding, a maioria dos desenvolvedores usa a API OpenAI, especialmente o modelo text-embedding-ada-002. Esse modelo é fácil de usar (especialmente se você já estiver usando outras APIs OpenAI), oferece resultados razoavelmente bons e está ficando mais barato. Algumas empresas maiores também estão explorando o Cohere, cujo trabalho de produto é mais focado na incorporação e tem melhor desempenho em alguns cenários. Para desenvolvedores que preferem código aberto, a biblioteca Sentence Transformers do Hugging Face é o padrão. Também é possível criar diferentes tipos de embeddings dependendo do caso de uso; esta é uma prática relativamente de nicho hoje, mas uma área de pesquisa promissora.

Do ponto de vista do sistema, a parte mais importante do pipeline de pré-processamento é o banco de dados de vetores. Um banco de dados vetorial é responsável por armazenar, comparar e recuperar com eficiência até bilhões de incorporações (também conhecidas como vetores). A opção mais comum que vemos no mercado é a Pinha. É o padrão, é fácil começar porque é totalmente hospedado na nuvem e tem muitos dos recursos que as grandes empresas precisam na produção (por exemplo, bom desempenho em escala, logon único e SLA de tempo de atividade).

No entanto, também há um grande número de bancos de dados de vetores disponíveis. Os notáveis incluem:

• Sistemas de código aberto, como Weaviate, Vespa e Qdrant: esses sistemas geralmente têm excelente desempenho de nó único e podem ser personalizados para aplicativos específicos, tornando-os populares entre equipes de IA experientes que gostam de desenvolver plataformas personalizadas.
• Faiss et al Bibliotecas nativas de gerenciamento de vetores: essas bibliotecas têm ampla experiência de desenvolvedor e são fáceis de iniciar para pequenos aplicativos e experimentos de desenvolvimento. Mas estes podem não necessariamente substituir bancos de dados completos em grande escala.
• Extensões OLTP como pgvector: Ótimo para desenvolvedores que veem falhas em cada forma de banco de dados e tentam se conectar ao Postgres, ou empresas que compram a maior parte de sua infraestrutura de dados de um único provedor de nuvem Ótima solução de suporte a vetores. Não está claro se o acoplamento rígido de cargas de trabalho de vetor versus escalar faz sentido a longo prazo.

No futuro, a maioria das empresas de banco de dados de vetores de código aberto está desenvolvendo produtos em nuvem. Nossa pesquisa mostra que alcançar um desempenho robusto na nuvem é um problema muito difícil no amplo espaço de design de possíveis casos de uso. Portanto, o conjunto de opções pode não mudar drasticamente no curto prazo, mas pode mudar no longo prazo. A questão principal é se os bancos de dados vetoriais serão consolidados em torno de um ou dois sistemas populares semelhantes aos bancos de dados OLTP e OLAP.

Há também a questão em aberto de como os bancos de dados vetoriais e incorporados evoluirão à medida que a janela de contexto disponível para a maioria dos modelos se expande. Você poderia facilmente argumentar que a incorporação se torna menos importante porque os dados contextuais podem ser colocados diretamente no prompt. O feedback de especialistas sobre o assunto, no entanto, sugere que o oposto é o caso - que os pipelines incorporados podem se tornar mais importantes com o tempo. Grandes janelas de contexto são de fato ferramentas poderosas, mas também requerem um custo computacional significativo. Portanto, é imperativo fazer uso eficaz desta janela. Podemos começar a ver diferentes tipos de modelos de incorporação se tornando populares, treinando diretamente na correlação de modelos e bancos de dados vetoriais surgindo projetados para permitir e alavancar isso.

Prompt build and get

Prompt build and get

As estratégias que estimulam o LLM e incorporam dados contextuais estão se tornando mais sofisticadas e também usadas como fonte de diferenciação de produtos, e seu papel está crescendo em importância. A maioria dos desenvolvedores inicia novos projetos experimentando com dicas simples que incluem instruções diretas (dicas de tiro zero) ou saída que pode conter alguns exemplos (dicas de poucos tiros). Essas dicas geralmente produzem bons resultados, mas não o nível de precisão necessário para implantações de produção.

O próximo nível de truques de dicas é basear as respostas do modelo em alguma fonte de verdade e fornecer contexto externo no qual o modelo não foi treinado. O Guia de Engenharia de Sugestão lista nada menos que uma dúzia (!) de estratégias de sugestão mais avançadas, incluindo cadeias de pensamento, autoconsistente, conhecimento generativo, árvores de pensamento, estímulos direcionais e muito mais. Essas estratégias podem ser combinadas para oferecer suporte a diferentes casos de uso do LLM, como perguntas e respostas sobre documentos, chatbots, etc.

É aqui que entram as estruturas de orquestração como LangChain e LlamaIndex. Essas estruturas abstraem muitos dos detalhes do encadeamento de dicas; interagindo com APIs externas (incluindo determinar quando uma chamada de API é necessária); recuperando dados de contexto de um banco de dados de vetores; e mantendo a memória entre chamadas em vários LLMs. Eles também fornecem modelos para muitos dos aplicativos comuns mencionados acima. Sua saída é uma dica ou uma série de dicas submetidas ao modelo de linguagem. Essas estruturas são amplamente utilizadas por amadores, bem como por startups que buscam desenvolver aplicativos, sendo a LangChain a líder.

O LangChain ainda é um projeto relativamente novo (atualmente na versão 0.0.201), mas já começamos a ver aplicações desenvolvidas com ele entrando em produção. Alguns desenvolvedores, especialmente os primeiros a adotar o LLM, preferem mudar para Python bruto na produção para remover dependências adicionais. Mas esperamos que essa abordagem do tipo "faça você mesmo" diminua na maioria dos casos de uso, como ocorre com as pilhas de aplicativos da Web tradicionais.

Leitores atentos notarão uma entrada de aparência estranha na caixa de layout: ChatGPT. Em circunstâncias normais, o ChatGPT é um aplicativo, não uma ferramenta de desenvolvedor. Mas também pode ser acessado como uma API. E, se você olhar de perto, ele executa algumas das mesmas funções de outras estruturas de orquestração, como: abstrair a necessidade de dicas personalizadas; manter o estado; recuperar dados contextuais por meio de plug-ins, APIs ou outras fontes. Embora o ChatGPT não seja um concorrente direto das outras ferramentas listadas aqui, ele pode ser considerado uma solução alternativa e pode acabar sendo uma alternativa viável e fácil para a criação de prompts.

Execução/raciocínio da dica

Execução/raciocínio da dica

Hoje, a OpenAI é líder no campo de modelos de linguagem. Quase todos os desenvolvedores que entrevistamos lançaram um novo aplicativo LLM usando a API OpenAI, geralmente eles usam o modelo gpt-4 ou gpt-4-32k. Isso fornece o melhor cenário de caso de uso para o desempenho do aplicativo e é fácil de usar porque pode usar uma ampla variedade de domínios de entrada e geralmente não requer ajuste fino ou auto-hospedagem.

Uma vez que um projeto está em produção e começa a escalar, uma gama mais ampla de opções pode entrar em jogo. Algumas perguntas comuns que ouvimos incluem:

• Mude para gpt-3.5-turbo: é cerca de 50 vezes mais barato que o GPT-4 e significativamente mais rápido. Muitos aplicativos não precisam de precisão de nível GPT-4, mas precisam dela para inferência de baixa latência e suporte econômico para usuários gratuitos. *Experimentado com outros fornecedores proprietários (especialmente o modelo Claude da Anthropic): Claude oferece inferência rápida, precisão de nível GPT-3.5, mais opções de personalização para grandes clientes e janelas de contexto de até 100k (embora tenhamos descoberto que a precisão diminui com o aumento do comprimento da entrada) .
• Classifique solicitações parciais para modelos de código aberto: isso é especialmente eficaz para casos de uso B2C de alto volume, como pesquisa ou bate-papo, em que as complexidades das consultas variam amplamente e os usuários gratuitos precisam ser atendidos de forma barata:

1. Isso geralmente faz mais sentido em combinação com o ajuste fino do modelo básico de código aberto. Não vamos nos aprofundar nessa pilha de ferramentas neste artigo, mas plataformas como Databricks, Anyscale, Mosaic, Modal e RunPod estão sendo cada vez mais usadas por equipes de engenharia.

2. Os modelos de código aberto podem usar várias opções de inferência, incluindo a interface API simples do Hugging Face e do Replicate; recursos de computação bruta dos principais provedores de nuvem; e produtos de nuvem (nuvem de opinião) com preferências mais claras, como as listadas acima.

Atualmente, o modelo de código aberto fica atrás dos produtos proprietários, mas a diferença está começando a diminuir. O modelo LLaMa da Meta estabeleceu novos padrões para precisão de código aberto e gerou uma variedade de variantes. Como o LLaMa é licenciado apenas para uso em pesquisa, muitos novos provedores começaram a treinar modelos de base alternativos (por exemplo, Together, Mosaic, Falcon, Mistral). A Meta ainda está discutindo se deve lançar uma verdadeira versão de código aberto do LLaMa 2.

Quando (não se) o LLM de código aberto atingir níveis de precisão comparáveis ao GPT-3.5, esperamos ver o texto também ter seu próprio momento de difusão estável, com experimentação em larga escala, compartilhamento e modelos de ajuste fino entrando em produção. Empresas de hospedagem como a Replicate começaram a adicionar ferramentas para tornar esses modelos mais acessíveis aos desenvolvedores de software. Os desenvolvedores acreditam cada vez mais que modelos menores e ajustados podem alcançar precisão de ponta para uma faixa estreita de casos de uso.

A maioria dos desenvolvedores que entrevistamos não tinha um conhecimento profundo das ferramentas operacionais do LLM. O armazenamento em cache é relativamente comum (geralmente baseado em Redis), pois melhora o tempo de resposta do aplicativo e reduz os custos. Ferramentas como Weights & Biases com MLflow (portadas do aprendizado de máquina tradicional) ou Layer with Helicone (construídas para LLM) também são amplamente utilizadas. Essas ferramentas podem registrar, rastrear e avaliar a saída do LLM, muitas vezes com a finalidade de melhorar a construção de pontas, ajustar tubulações ou selecionar modelos. Há também muitas novas ferramentas sendo desenvolvidas para validar a saída do LLM (por exemplo, Guardrails) ou detectar ataques de injeção de dicas (por exemplo, Rebuff). A maioria dessas ferramentas operacionais incentiva seus próprios clientes Python a realizar chamadas LLM, portanto, será interessante ver como essas soluções coexistem ao longo do tempo.

Por fim, a parte estática do aplicativo LLM (ou seja, tudo menos o modelo) também precisa ser hospedada em algum lugar. De longe, as soluções mais comuns que vimos são opções padrão como Vercel ou os principais provedores de nuvem. No entanto, duas novas categorias estão surgindo. Startups como Steamship fornecem hospedagem de ponta a ponta para aplicativos LLM, incluindo orquestração (LangChain), contexto de dados multilocatário, tarefas assíncronas, armazenamento vetorial e gerenciamento de chaves. Empresas como Anyscale e Modal permitem que os desenvolvedores hospedem modelos e código Python em um só lugar.

E os proxies?

Um dos componentes mais importantes que faltam nessa arquitetura de referência é a estrutura do agente de inteligência artificial. O AutoGPT foi descrito como "uma tentativa experimental de código aberto para automatizar totalmente o GPT-4" e, nesta primavera, tornou-se o repositório Github de crescimento mais rápido da história, e quase todos os projetos ou startups de IA hoje incorporam alguma forma de O agente entra .

A maioria dos desenvolvedores com quem conversamos estava muito entusiasmada com o potencial dos proxies. O modelo de aprendizagem contextual que descrevemos neste artigo pode efetivamente abordar alucinações e problemas de atualização de dados, suportando melhor as tarefas de geração de conteúdo. Os agentes, por outro lado, fornecem um conjunto totalmente novo de recursos para aplicativos de IA: resolver problemas complexos, atuar no mundo externo e aprender com a experiência pós-implantação. Isso é feito por meio de uma combinação de raciocínio/planejamento avançado, uso de ferramentas e memória/recursão/pensamento autorreflexivo.

Como tal, os agentes têm o potencial de se tornar uma parte essencial da arquitetura do aplicativo LLM (ou até mesmo assumir toda a pilha de tecnologia, se você acredita em autoaperfeiçoamento recursivo). Estruturas existentes como LangChain já incorporam parte do conceito de proxy. Há apenas um problema: os proxies ainda não funcionam de verdade. A maioria das estruturas de agente hoje ainda está no estágio de prova de conceito, oferecendo demonstrações incríveis, mas não realizando tarefas de maneira confiável e repetitiva. Estamos observando de perto como o proxy se desenvolverá no futuro próximo.

Olhando para o futuro

Os modelos de IA pré-treinados representam a mudança mais significativa na arquitetura de software desde a Internet. Eles permitem que desenvolvedores individuais criem aplicativos de IA incríveis em dias, superando até mesmo os projetos de aprendizado de máquina supervisionados que costumavam levar meses para serem desenvolvidos por grandes equipes.

As ferramentas e padrões que listamos aqui podem ser um ponto de partida para a integração do LLM, não um estado final. Também atualizamos quando há alterações importantes (por exemplo, a mudança para treinamento de modelo) e publicamos novas arquiteturas de referência onde faz sentido.