Infraestrutura para um aplicativo de IA generativa com capacidade para RAG usando o GKE

Last reviewed 2024-04-02 UTC

Neste documento, apresentamos uma arquitetura de referência que pode ser usada para projetar a infraestrutura para executar um aplicativo de IA generativa com geração aumentada por recuperação (RAG, na sigla em inglês) usando o Google Kubernetes Engine (GKE), Cloud SQL e ferramentas de código aberto, como Ray, Hugging Face e LangChain. Para ajudar você a testar essa arquitetura de referência, um aplicativo de exemplo e a configuração do Terraform são fornecidos no GitHub.

Este documento é destinado a desenvolvedores que querem criar e implantar rapidamente aplicativos de IA generativa capazes de usar RAG usando ferramentas e modelos de código aberto. Ele pressupõe que você tenha experiência com o GKE e o Cloud SQL e que tenha uma compreensão conceitual de IA, machine learning (ML) e modelos de linguagem grandes (LLMs). Neste documento, não fornecemos orientações sobre como projetar e desenvolver um aplicativo de IA generativa.

Arquitetura

O diagrama a seguir mostra uma visão de alto nível de uma arquitetura para um aplicativo de IA generativa com capacidade de RAG no Google Cloud:

Uma arquitetura de alto nível para um aplicativo de IA generativa com capacidade de RAG no Google Cloud.

A arquitetura contém um subsistema de exibição e um de embedding.

  • O subsistema de disponibilização lida com o fluxo de solicitação-resposta entre o aplicativo e os usuários. O subsistema inclui um servidor de front-end, um servidor de inferência e um serviço de IA responsável (RAI, na sigla em inglês). O subsistema de disponibilização interage com o de embedding por um banco de dados de vetores.
  • O subsistema de incorporação ativa o recurso RAG na arquitetura. Esse subsistema faz o seguinte:
    • Ingestão de dados de fontes de dados no Google Cloud, no local e em outras plataformas de nuvem.
    • Converte os dados ingeridos em embeddings vetoriais.
    • Armazena os embeddings em um banco de dados de vetores.

O diagrama a seguir mostra uma visão detalhada da arquitetura:

Uma arquitetura detalhada para um aplicativo de IA generativa com capacidade de RAG no Google Cloud.

Conforme mostrado no diagrama anterior, o servidor de front-end, o servidor de inferência e o serviço de incorporação são implantados em um cluster regional do GKE no modo Autopilot. Os dados para RAG são ingeridos por meio de um bucket do Cloud Storage. A arquitetura usa uma instância do Cloud SQL para PostgreSQL com a extensão pgvector como banco de dados de vetores para armazenar embeddings e realizar pesquisas semânticas. Os bancos de dados vetoriais são projetados para armazenar e recuperar vetores de alta dimensão com eficiência.

As seções a seguir descrevem os componentes e o fluxo de dados dentro de cada subsistema da arquitetura.

Subsistema de embedding

Este é o fluxo de dados no subsistema de embedding:

  1. Os dados de fontes externas e internas são enviados para o bucket do Cloud Storage por usuários humanos ou de maneira programática. Os dados enviados podem estar em arquivos, bancos de dados ou dados transmitidos.
  2. Essa opção não está no diagrama da arquitetura. A atividade de upload de dados aciona um evento que é publicado em um serviço de mensagens como o Pub/Sub. O serviço de mensagens envia uma notificação ao serviço de embedding.
  3. Quando o serviço de embedding recebe uma notificação de um evento de upload de dados, ele faz o seguinte:
    1. Recupera dados do bucket do Cloud Storage por meio do driver CSI do Cloud Storage FUSE.
    2. Lê os dados enviados e os pré-processa usando dados do Ray. O pré-processamento pode incluir fragmentar os dados e transformá-los em um formato adequado para a geração de embedding.
    3. Executa um Trabalho do Ray para criar embeddings vetorizados dos dados pré-processados usando um modelo de código abertointfloat/multilíngue-e5-pequeno implantados no mesmo cluster.
    4. Grava os embeddings vetorizados no banco de dados de vetores do Cloud SQL para PostgreSQL.

Conforme descrito na seção a seguir, quando o subsistema de disponibilização processa solicitações de usuários, ele usa os embeddings no banco de dados de vetores para recuperar dados relevantes específicos do domínio.

Subsistema de disponibilização

Veja a seguir o fluxo de solicitação/resposta no subsistema de exibição:

  1. Um usuário envia uma solicitação em linguagem natural para um servidor de front-end por meio de uma interface de chat baseada na Web. O servidor de front-end é executado no GKE.
  2. O servidor de front-end executa um processo do LangChain que faz o seguinte:
    1. Converte a solicitação de linguagem natural em embeddings usando o mesmo modelo e parâmetros usados pelo serviço de embedding.
    2. Recupera dados de embasamento relevantes realizando uma pesquisa semântica para os embeddings no banco de dados de vetores. A pesquisa semântica ajuda a encontrar embeddings com base na intent de um comando no lugar do conteúdo textual dele.
    3. Constrói um comando contextualizado combinando a solicitação original com os dados de embasamento que foram recuperados.
    4. Envia o prompt contextualizado para o servidor de inferência, que é executado no GKE.
  3. O servidor de inferência usa o framework de veiculação Hugging Face TGI para exibir um LLM de código aberto, como Mistral-7B-Instruct ou um modelo aberto do Gemma.

  4. O LLM gera uma resposta ao prompt, e o servidor de inferência envia a resposta ao servidor de front-end.

    É possível armazenar e ver registros da atividade de solicitação-resposta no Cloud Logging e configurar o monitoramento com base em registros usando o Cloud Monitoring. Também é possível carregar as respostas geradas no BigQuery para análise off-line.

  5. O servidor de front-end invoca um serviço RAI para aplicar os filtros de segurança necessários à resposta. Use ferramentas como a Proteção de Dados Sensíveis e a API Cloud Natural Language para descobrir, filtrar, classificar e desidentificar conteúdo sensível nas respostas.

  6. O servidor de front-end envia a resposta filtrada para o usuário.

Produtos usados

Veja a seguir um resumo do Google Cloud e dos produtos de código aberto que a arquitetura anterior usa:

Produtos do Google Cloud

  • Google Kubernetes Engine (GKE): um serviço do Kubernetes que pode ser usado para implantar e operar aplicativos conteinerizados em escala usando a infraestrutura do Google.
  • Cloud Storage: um armazenamento de objetos de baixo custo e sem limite para diversos tipos de dados. Os dados podem ser acessados de dentro e fora do Google Cloud e são replicados entre locais para redundância.
  • Cloud SQL: um serviço de banco de dados relacional totalmente gerenciado que ajuda a provisionar, operar e gerenciar seus bancos de dados MySQL, PostgreSQL e SQL Server no Google Cloud.

Produtos de código aberto

  • Hugging Face Text Generation Inference (TGI): um kit de ferramentas para implantar e disponibilizar LLMs.
  • Ray: framework de computação unificada de código aberto que ajuda a escalonar cargas de trabalho de IA e Python.
  • LangChain: um framework para desenvolvimento e implantação de aplicativos com LLMs.

Casos de uso

A RAG é uma técnica eficaz para melhorar a qualidade da saída gerada por um LLM. Nesta seção, apresentamos exemplos de casos de uso em que é possível usar aplicativos de IA generativa com capacidade de RAG.

Recomendações de produtos personalizada

Um site de compras on-line pode usar um chatbot com tecnologia de LLM para ajudar os clientes a encontrar produtos ou receber ajuda relacionada a compras. As perguntas de um usuário podem ser aumentadas usando dados históricos sobre os padrões de interação no site e o comportamento de compra do usuário. Os dados podem incluir avaliações e feedback de usuários armazenados em um repositório de dados não estruturados ou métricas relacionadas à pesquisa que são armazenadas em um data warehouse de análise da Web. A pergunta aumentada pode ser processada pelo LLM para gerar respostas personalizadas que o usuário pode achar mais relevantes e convincentes.

Sistemas de assistência clínica

Médicos em hospitais precisam analisar e diagnosticar rapidamente a condição de saúde de um paciente para tomar decisões sobre tratamentos e medicamentos apropriados. Um aplicativo de IA generativa que usa um LLM médico, como o Med-PaLM, pode ser usado para ajudar médicos no processo de diagnóstico clínico. As respostas que o aplicativo gera podem ser fundamentadas por históricos dos pacientes contextualizando os comandos dos médicos com dados do banco de dados dos históricos de saúde eletrônicos (EHR, na sigla em inglês) do hospital ou de uma base de conhecimento externa, como o PubMed:

A pesquisa jurídica com tecnologia de IA generativa permite que advogados consultem rapidamente grandes volumes de estatutos e jurisprudência para identificar precedentes legais relevantes ou resumir conceitos jurídicos complexos. O resultado dessa pesquisa pode ser aprimorado aumentando os comandos de um advogado com dados extraídos das comunicações legais anteriores, dos registros de casos internos e do corpus reservado de contratos do escritório de advocacia. Essa abordagem de desenvolvimento garante que as respostas geradas sejam relevantes para o domínio jurídico em que o advogado é especializado.

Considerações sobre o design

Nesta seção, fornecemos orientações para ajudar você a desenvolver e executar uma arquitetura de IA generativa compatível com RAG e hospedada pelo GKE que atenda aos requisitos específicos de segurança e conformidade, confiabilidade, custo e desempenho. As orientações desta seção não são completas. Dependendo dos requisitos específicos do seu aplicativo e dos produtos e recursos do Google Cloud que você usa, pode ser necessário considerar outros fatores de desenvolvimento e compensações.

Para orientações de design relacionadas às ferramentas de código aberto nesta arquitetura de referência, como Hugging Face TGI, consulte a documentação dessas ferramentas.

segurança, privacidade e conformidade

Nesta seção, descrevemos fatores que você precisa considerar ao projetar e criar um aplicativo de IA generativa com capacidade de RAG no Google Cloud que atenda aos seus requisitos de segurança, privacidade e conformidade.

Produto Considerações sobre o design
GKE;

No modo de operação Autopilot, o GKE pré-configura o cluster e gerencia nós de acordo com as práticas recomendadas de segurança. Assim, você pode se concentrar na segurança específica da carga de trabalho. Para ver mais informações, consulte os seguintes tópicos:

Para garantir o controle de acesso aprimorado para seus aplicativos em execução no GKE, use o Identity-Aware Proxy (IAP). O IAP se integra ao recurso Entrada do GKE e garante que apenas usuários autenticados com o papel correto de gerenciamento de identidade e acesso (IAM) possam acessar os aplicativos. Para mais informações, consulte Como ativar o IAP para GKE.

Por padrão, os dados no GKE são criptografados em repouso e em trânsito usando chaves de criptografia gerenciadas pelo Google. Como uma camada extra de segurança para dados confidenciais, é possível criptografar dados na camada do aplicativo usando uma chave que você tem e gerencia com o Cloud KMS. Para mais informações, consulte Criptografar secrets na camada do aplicativo.

Se você usa um cluster padrão do GKE, é possível usar os seguintes recursos extras de criptografia de dados:

Cloud SQL

A instância do Cloud SQL na arquitetura não precisa ser acessível pela Internet pública. Se for necessário acesso externo à instância do Cloud SQL, criptografe conexões externas usando SSL/TLS ou o conector Proxy do Cloud SQL Auth. O conector do proxy de autenticação fornece autorização de conexão usando o IAM. O conector usa uma conexão TLS 1.3 com uma criptografia AES de 256 bits para verificar as identidades do cliente e do servidor e criptografar o tráfego de dados. Para conexões criadas com Java, Python, Go ou Node.js, use o Conector de linguagem apropriado, em vez do conector de proxy de autenticação.

Por padrão, o Cloud SQL usa chaves de criptografia de dados (DEK) gerenciadas pelo Google e chaves de criptografia de chaves (KEK) para criptografar dados em repouso. Se for necessário usar as KEKs controladas e gerenciadas por você, utilize as chaves de criptografia gerenciadas pelo cliente (CMEKs).

Para impedir o acesso não autorizado à API Cloud SQL Admin, é possível criar um perímetro de serviço usando o VPC Service Controls.

Para informações sobre como configurar o Cloud SQL para atender aos requisitos de residência de dados, consulte Visão geral da residência de dados.

Cloud Storage

Por padrão, os dados armazenados no Cloud Storage são criptografados com chaves gerenciadas pelo Google. Se necessário, use CMEKs ou suas próprias chaves gerenciadas utilizando um método de gerenciamento externo, como chaves de criptografia fornecidas pelo cliente (CSEKs). Para mais informações, consulte Opções de criptografia de dados.

O Cloud Storage é compatível com dois métodos para controlar o acesso dos usuários aos buckets e objetos: IAM e listas de controle de acesso (Access Control Lists). Na maioria dos casos, recomendamos usar o IAM, que permite conceder permissões no nível do bucket e para envolvidos no projeto. Para mais informações, consulte Visão geral do controle de acesso.

Os dados carregados no subsistema de ingestão de dados pelo Cloud Storage podem incluir dados sensíveis. Para proteger esses dados, use a Proteção de Dados Sensíveis para descobrir, classificar e desidentificar os dados. Para mais informações, acesse Como usar a Proteção de Dados Sensíveis com o Cloud Storage.

Para reduzir o risco de exfiltração de dados do Cloud Storage, crie um perímetro de serviço usando o VPC Service Controls.

O Cloud Storage ajuda você a atender aos requisitos de residência de dados. Os dados são armazenados ou replicados nas regiões especificadas.

Todos os produtos desta arquitetura

Os registros de auditoria de atividades do administrador são ativados por padrão para todos os serviços do Google Cloud usados nesta arquitetura de referência. É possível acessar os registros pelo Cloud Logging e usá-los para monitorar chamadas de API ou outras ações que modifiquem a configuração ou os metadados dos recursos do Google Cloud.

Os registros de auditoria de acesso a dados também são ativados por padrão para todos os serviços do Google Cloud nessa arquitetura. É possível usar esses registros para monitorar o seguinte:

  • Chamadas de API que leem a configuração ou os metadados dos recursos.
  • Solicitações do usuário para criar, modificar ou ler dados de recursos fornecidos pelo usuário.

Para ver orientações gerais sobre os princípios de segurança a considerar para aplicativos de IA, consulte Introdução ao framework de IA segura do Google.

Confiabilidade

Nesta seção, descrevemos os fatores de desenvolvimento que você precisa considerar ao criar e operar uma infraestrutura confiável para um aplicativo de IA generativa com capacidade de RAG no Google Cloud.

Produto Considerações sobre o design
GKE;

Com o modo de operação Autopilot usado nesta arquitetura, o GKE fornece os seguintes recursos integrados de confiabilidade:

  • Sua carga de trabalho usa um cluster regional do GKE. O plano de controle e os nós de trabalho são distribuídos por três zonas diferentes dentro de uma região. Suas cargas de trabalho são resistentes a interrupções de zona. Os clusters regionais do GKE têm um SLA de tempo de atividade mais alto do que os clusters zonais.
  • Não é preciso criar nós ou gerenciar pools de nós. O GKE cria os pools de nós e os escalona automaticamente com base nos requisitos das cargas de trabalho.

Para garantir que uma capacidade de GPU suficiente esteja disponível quando necessário para o escalonamento automático do cluster do GKE, crie e use reservas. Uma reserva fornece capacidade garantida em uma zona específica para um recurso especificado. Uma reserva pode ser específica para um projeto ou compartilhada entre vários projetos. Você receberá cobranças por recursos reservados mesmo que eles não sejam provisionados ou usados. Para mais informações, consulte Como consumir recursos por zona reservados.

Cloud SQL

Para garantir que o banco de dados vetorial seja robusto contra falhas de banco de dados e interrupções de zona, use uma instância do Cloud SQL configurada com alta disponibilidade. Em caso de falha do banco de dados primário ou uma interrupção na zona, o Cloud SQL faz o failover automaticamente para o banco de dados em espera em outra zona. Não é preciso alterar o endereço IP do endpoint do banco de dados.

Para garantir que suas instâncias do Cloud SQL sejam cobertas pelo SLA, siga as diretrizes operacionais recomendadas. Por exemplo, verifique se a CPU e a memória estão dimensionadas corretamente para a carga de trabalho e ative os aumentos automáticos de armazenamento. Para mais informações, consulte as diretrizes operacionais.

Cloud Storage É possível criar buckets do Cloud Storage em um destes três tipos de local: regional, birregional ou multirregional. Os dados armazenados em buckets regionais são replicados de maneira síncrona em várias zonas dentro de uma região. Para maior disponibilidade, use buckets birregionais ou multirregionais, em que os dados são replicados de maneira assíncrona entre regiões.

Otimização de custos

Esta seção contém orientações para ajudar você a otimizar o custo de configuração e operação de um aplicativo de IA generativa com capacidade de RAG no Google Cloud.

Produto Considerações sobre o design
GKE;

No modo Autopilot, o GKE otimiza a eficiência da infraestrutura do cluster com base nos requisitos da carga de trabalho. Você não precisa monitorar constantemente a utilização de recursos nem gerenciar a capacidade para controlar os custos.

Se for possível prever o uso de CPU, memória e armazenamento temporário do seu cluster do Autopilot do GKE, você poderá economizar com descontos por uso contínuo. Para mais informações, consulte Descontos por uso contínuo do GKE.

Para reduzir o custo da execução do aplicativo, use VMs spot nos nós do GKE. As VMs spot têm um preço menor do que as VMs padrão, mas não oferecem garantia de disponibilidade. Para mais informações sobre os benefícios dos nós que usam VMs spot, como elas funcionam no GKE e como programar cargas de trabalho nesses nós, consulte VMs spot.

Para mais orientações de otimização de custos, consulte Práticas recomendadas para executar aplicativos econômicos do Kubernetes no GKE.

Cloud SQL

Uma configuração de alta disponibilidade (HA, na sigla em inglês) ajuda a reduzir a inatividade do banco de dados do Cloud SQL quando a zona ou instância fica indisponível. No entanto, o custo de uma instância configurada com alta disponibilidade é maior do que o de uma instância independente. Se você não precisa de alta disponibilidade para o banco de dados de vetores, pode reduzir o custo usando uma instância autônoma, que não é robusta contra interrupções de zona.

É possível detectar se a instância do Cloud SQL está provisionada em excesso e otimizar o faturamento usando os insights de custo e as recomendações do Cloud SQL com a tecnologia do Active Assist. Para mais informações, consulte Reduzir instâncias provisionadas do Cloud SQL.

Se você conseguir prever os requisitos de CPU e memória das instâncias do Cloud SQL, será possível economizar dinheiro com descontos por compromisso de uso. Para mais informações, consulte Descontos por uso contínuo do Cloud SQL.

Cloud Storage Para o bucket do Cloud Storage usado para carregar dados no subsistema de ingestão de dados, escolha uma classe de armazenamento adequada. Ao escolher a classe de armazenamento, considere os requisitos de retenção de dados e frequência de acesso das suas cargas de trabalho. Por exemplo, para controlar os custos de armazenamento, escolha a classe Standard e use o Gerenciamento do ciclo de vida de objetos. Isso permite o downgrade automático de objetos para uma classe de armazenamento de menor custo ou a exclusão de objetos com base nas condições que você definir.

Para estimar o custo dos seus recursos do Google Cloud, use a calculadora de preços do Google Cloud.

Otimização de desempenho

Nesta seção, descrevemos os fatores que você precisa considerar ao projetar e criar um aplicativo de IA generativa com capacidade de RAG no Google Cloud que atenda aos seus requisitos de desempenho.

Produto Considerações sobre o design
GKE; Escolha as classes de computação apropriadas para os pods com base nos requisitos de desempenho das cargas de trabalho. Para os pods que executam o servidor de inferência e o serviço de embedding, recomendamos usar um tipo de máquina de GPU como nvidia-l4.
Cloud SQL

Para otimizar o desempenho da instância do Cloud SQL, verifique se a CPU e a memória alocadas para a instância são adequadas para a carga de trabalho. Para mais informações, consulte Otimizar instâncias subprovisionadas do Cloud SQL.

Para melhorar o tempo de resposta da pesquisa de vetor de vizinho mais próximo (ANN, na sigla em inglês), use o índice Arquivo invertido com compactação plana (IVFFlat) ou o Hierarchical Navigable Small World (HNSW)

Para ajudar você a analisar e melhorar o desempenho da consulta dos bancos de dados, o Cloud SQL fornece uma ferramenta de insights de consulta. Use essa ferramenta para monitorar o desempenho e rastrear a origem de uma consulta problemática. Para mais informações, acesse Usar insights de consulta para melhorar o desempenho da consulta.

Para ter uma visão geral do status e do desempenho dos seus bancos de dados e ver métricas detalhadas, como picos de conexões e utilização do disco, use o painel "Insights do sistema". Para saber mais, consulte Usar insights do sistema para melhorar o desempenho do sistema.

Cloud Storage Para fazer upload de arquivos grandes, use um método chamado uploads compostos paralelos. Com essa estratégia, o arquivo grande é dividido em fragmentos. Esses fragmentos são transferidos para o Cloud Storage em paralelo e, em seguida, os dados são recompostos na nuvem. Quando a largura de banda da rede e a velocidade do disco não estão limitando os fatores, os uploads compostos paralelos podem ser mais rápidos do que as operações de upload normais. No entanto, essa estratégia tem algumas limitações e implicações de custo. Para mais informações, consulte Uploads compostos paralelos.

Deployment

Para implantar uma topologia baseada nessa arquitetura de referência, faça o download e use o código de exemplo de código aberto disponível em um repositório no GitHub. O exemplo de código não se destina a casos de uso de produção. É possível usar o código para testar a configuração da infraestrutura de IA para um aplicativo de IA generativa ativado para RAG.

O exemplo de código faz o seguinte:

  1. Provisiona uma instância do Cloud SQL para PostgreSQL para servir como banco de dados vetorial.
  2. Implanta o Ray, o JupyterHub e o Hugging Face TGI em um cluster do GKE que você especificar.
  3. Implanta um aplicativo de bot de bate-papo de amostra baseado na Web no cluster do GKE para permitir que você verifique a capacidade do RAG.

Para instruções sobre como usar o exemplo de código, consulte o README do código. Se ocorrer algum erro ao usar o exemplo de código e se problemas abertos do GitHub não existirem para os erros, crie problemas no GitHub.

O exemplo de código implanta recursos faturáveis do Google Cloud. Quando terminar de usar o código, remova todos os recursos que não são mais necessários.

A seguir

Colaboradores

Autor: Kumar Dhanagopal | Desenvolvedor de soluções de vários produtos

Outros colaboradores: