Compreendendo a arquitetura de aplicativos de IA
Como é realmente uma aplicação de IA? Depois de construir alguns, parece um bom momento para dividi-los em suas (muitas) partes e explorar as implicações operacionais.
Já exploramos anteriormente o que é igual (muito) e o que é diferente (muito) nas aplicações de IA . É bastante fácil definir uma aplicação de IA como “uma aplicação que aproveita a IA, seja preditiva ou generativa ”.
Isso é verdade, mas para as pessoas que precisam construir, implantar, entregar, proteger e operar esses novos tipos de aplicativos, o que isso significa?
Isso significa novas peças móveis, por exemplo. E não apenas serviços de inferência . Há outros novos componentes que estão se tornando adições padrão à arquitetura do aplicativo, como bancos de dados vetoriais. Isso também significa maior dependência de APIs .
Também é verdade que a maioria desses componentes são conteinerizados. Quando configuro um novo projeto de aplicativo de IA, inicio um contêiner executando PostgreSQL para usar como um armazenamento de dados vetoriais. Isso é para dar suporte ao RAG (Retrieval Augmented Generation), que uma porcentagem significativa de aplicativos de IA está usando, de acordo com vários relatórios do setor ( este da Databricks, por exemplo) . Isso porque posso ampliar um modelo de IA de estoque usando quaisquer dados que eu quiser, sem precisar ajustar ou treinar um modelo sozinho. Para um número significativo de casos de uso, essa é a melhor maneira de implementar um aplicativo de IA.
Também posso iniciar um gráfico de conhecimento, normalmente executando um banco de dados de gráficos em contêiner, como o Neo4J. Bancos de dados gráficos são particularmente úteis ao trabalhar com dados afins de gráficos, como redes sociais, dados de mecanismos de recomendação e detecção de fraudes. Acontece que elas também são úteis para mitigar alucinações relacionadas à geração de políticas, como aprendemos no início do ano . A inclusão de um banco de dados gráfico pode adicionar um novo protocolo, GraphQL, à lista de "novas coisas que precisam ser protegidas".
Então vou decidir qual serviço de inferência quero usar. Eu tenho opções. Eu poderia usar um serviço de provedor de nuvem ou IA como serviço (como o ChatGPT) ou poderia executar um serviço local . Por exemplo, minha última tentativa usou Ollama e phi3 no meu MacBook. Nesse caso, estou executando apenas uma cópia do servidor de inferência porque, bem, executar várias delas consumiria mais recursos do que tenho. Na produção, é claro, é provável que haja mais instâncias para garantir que seja possível atender à demanda.
Como vou usar o phi3, escolhi o phidata como minha estrutura para acessar o serviço de inferência. Também usei o langchain ao aproveitar a IA como serviço, uma escolha popular, e a boa notícia é que, de uma perspectiva operacional, a estrutura não é algo que opera fora do próprio aplicativo principal de IA.
Impacto operacional de aplicações de IA
Ainda não escrevi uma linha de código e já tenho vários componentes em execução, cada um acessado via API e executado em seus próprios contêineres. É por isso que partimos da premissa de que um aplicativo de IA é um aplicativo moderno e traz consigo todos os mesmos desafios familiares de entrega, segurança e operação. É também por isso que acreditamos que a implantação de modelos de IA aumentará radicalmente o número de APIs que precisam de entrega e segurança.
As aplicações de IA acrescentam outro nível a um ambiente já complexo, o que, obviamente, aumenta a complexidade. O que significa que a arquitetura de aplicativos de IA aumentará a carga em todas as funções operacionais, da segurança ao SRE e à rede. Cada um desses componentes também tem seu próprio perfil de dimensionamento; ou seja, alguns componentes precisarão ser dimensionados mais rapidamente do que outros e a forma como as solicitações são distribuídas variará simplesmente porque a maioria deles está aproveitando diferentes APIs e, em alguns casos, protocolos.
Além disso, a arquitetura do aplicativo de IA será altamente variável internamente. Ou seja, o aplicativo de IA que eu criar provavelmente apresentará características e necessidades de tráfego local diferentes do aplicativo de IA que você criar. E mais heterogeneidade significa naturalmente maior complexidade porque é o oposto da padronização, que promove a homogeneidade.
A padronização tem sido, por décadas, o meio pelo qual as empresas aceleram a entrega de novos recursos ao mercado e alcançam maiores eficiências operacionais, ao mesmo tempo em que liberam os recursos humanos necessários para lidar com a variabilidade nas arquiteturas de aplicativos de IA.
É por isso que vemos alguns serviços compartilhados — particularmente a segurança de aplicativos e APIs — migrando para a borda, à la segurança como serviço . Esse conjunto de serviços compartilhados pode não apenas proteger melhor as cargas de trabalho em todos os ambientes (núcleo, nuvem e borda), mas também fornecer um conjunto comum de serviços que podem servir como padrão em todos os aplicativos de IA.
Entender a anatomia dos aplicativos de IA ajudará a determinar não apenas os tipos de entrega de aplicativos e serviços de segurança de que você precisa, mas também onde você precisa deles.