Este documento fornece uma arquitetura de referência que pode usar para criar a infraestrutura para executar uma aplicação de inteligência artificial (IA) generativa com geração aumentada de recuperação (RAG). O público-alvo deste documento inclui programadores e administradores de aplicações de IA generativa e arquitetos de nuvem. O documento pressupõe uma compreensão básica dos conceitos de IA, aprendizagem automática (AA) e modelo de linguagem (conteúdo extenso) (MDI/CE). Este documento não fornece orientações sobre como criar e desenvolver uma aplicação de IA generativa.
Arquitetura
O diagrama seguinte mostra uma vista de alto nível de uma arquitetura para uma aplicação de IA generativa com capacidade de RAG em Google Cloud:
A arquitetura contém os seguintes componentes interligados:
| Componente | Finalidade | Interacções |
|---|---|---|
| Subsistema de carregamento de dados | Prepare e processe os dados externos usados para ativar a capacidade de RAG. | O subsistema de carregamento de dados interage com os outros subsistemas na arquitetura através da camada da base de dados. |
| Subsistema de publicação | Processar o fluxo de pedido-resposta entre a aplicação de IA generativa e os respetivos utilizadores. | O subsistema de publicação interage com o subsistema de carregamento de dados através da camada de base de dados. |
| Subsistema de avaliação de qualidade | Avalie a qualidade das respostas que o subsistema de publicação gera. | O subsistema de avaliação da qualidade interage diretamente com o subsistema de publicação e com o subsistema de carregamento de dados através da camada de base de dados. |
| Bases de dados | Armazenar os seguintes dados:
|
Todos os subsistemas na arquitetura interagem com as bases de dados. |
O diagrama seguinte mostra uma vista detalhada da arquitetura:
As secções seguintes fornecem descrições detalhadas dos componentes e do fluxo de dados em cada subsistema da arquitetura.
Subsistema de carregamento de dados
O subsistema de obtenção de dados obtém dados de origens externas, como ficheiros, bases de dados e serviços de streaming. Os dados carregados incluem comandos para avaliação da qualidade. O subsistema de carregamento de dados fornece a capacidade de RAG na arquitetura. O diagrama seguinte mostra detalhes do subsistema de carregamento de dados na arquitetura:
Seguem-se os passos no fluxo de carregamento de dados:
- Os dados são carregados para um contentor do Cloud Storage. A origem de dados pode ser um utilizador da aplicação que está a carregar, a introduzir dados numa base de dados ou a fazer streaming de dados.
- Quando os dados são carregados, é enviada uma notificação para um tópico do Pub/Sub.
- O Pub/Sub aciona uma tarefa do Cloud Run para processar os dados carregados.
- O Cloud Run inicia a tarefa através de dados de configuração armazenados numa base de dados do AlloyDB for PostgreSQL.
- A tarefa do Cloud Run usa o Document AI para preparar os dados para processamento adicional. Por exemplo, a preparação pode incluir a análise dos dados, a conversão dos dados para o formato necessário e a divisão dos dados em partes.
A tarefa do Cloud Run usa o modelo Vertex AI Embeddings for Text para criar incorporações vetorizadas dos dados carregados.
O Cloud Run armazena as incorporações numa base de dados do AlloyDB for PostgreSQL que tem a extensão
pgvectorativada. Conforme descrito na secção seguinte, quando o subsistema de publicação processa pedidos de utilizadores, usa as incorporações na base de dados vetorial para obter dados relevantes específicos do domínio.
Subsistema de publicação
O subsistema de publicação processa o fluxo de pedido-resposta entre a aplicação de IA generativa e os respetivos utilizadores. O diagrama seguinte mostra detalhes do subsistema de publicação na arquitetura:
Seguem-se os passos no fluxo de pedido-resposta no subsistema de publicação:
- Os utilizadores enviam pedidos à aplicação de IA generativa através de um front-end (por exemplo, um chatbot ou uma app para dispositivos móveis).
A aplicação de IA generativa converte o pedido de linguagem natural em incorporações.
A aplicação conclui a parte de obtenção da abordagem RAG:
- A aplicação realiza uma pesquisa semântica da incorporação na loja de vetores do AlloyDB for PostgreSQL mantida pelo subsistema de carregamento de dados. A pesquisa semântica ajuda a encontrar incorporações com base na intenção de um comando, em vez do respetivo conteúdo textual.
- A aplicação combina o pedido original com os dados não processados que são obtidos com base na incorporação correspondente para criar um comando contextualizado.
A aplicação envia o comando contextualizado para uma pilha de inferência do GML que é executada no Vertex AI.
A pilha de inferência do MDL/CE usa um MDL/CE de IA generativa, que pode ser um MDL/CE de base ou um MDL/CE personalizado, e gera uma resposta restrita ao contexto fornecido.
- A aplicação pode armazenar registos da atividade de pedido-resposta no Cloud Logging. Pode ver e usar os registos para monitorização através do Cloud Monitoring. A Google não acede nem utiliza dados de registo.
- A aplicação carrega as respostas para o BigQuery para análise offline.
A aplicação filtra as respostas através de filtros de IA responsável.
A aplicação envia as respostas filtradas aos utilizadores através da interface.
Subsistema de avaliação de qualidade
O diagrama seguinte mostra detalhes do subsistema de avaliação da qualidade na arquitetura:
Quando o subsistema de avaliação da qualidade recebe um pedido, faz o seguinte:
- O Pub/Sub aciona uma tarefa do Cloud Run.
- O Cloud Run inicia a tarefa através de dados de configuração armazenados numa base de dados do AlloyDB for PostgreSQL.
- A tarefa do Cloud Run extrai comandos de avaliação de uma base de dados do AlloyDB para PostgreSQL. Anteriormente, os comandos eram carregados para a base de dados pelo subsistema de obtenção de dados.
A tarefa do Cloud Run usa os comandos de avaliação para avaliar a qualidade das respostas que o subsistema de publicação gera.
O resultado desta avaliação consiste em classificações de avaliação para métricas como a precisão factual e a relevância.
O Cloud Run carrega as classificações de avaliação e os comandos e as respostas que foram avaliadas para o BigQuery para análise futura.
Produtos usados
Segue-se um resumo de todos os Google Cloud produtos que a arquitetura anterior usa:
- Vertex AI: uma plataforma de ML que lhe permite preparar e implementar modelos de ML e aplicações de IA, bem como personalizar MDIs/CE para utilização em aplicações com tecnologia de IA.
- Cloud Run: uma plataforma de computação sem servidor que lhe permite executar contentores diretamente na infraestrutura escalável da Google.
- BigQuery: um armazém de dados empresariais que ajuda a gerir e analisar os seus dados com funcionalidades integradas, como aprendizagem automática, análise geoespacial e Business Intelligence.
- Cloud Storage: um serviço de armazenamento de objetos de baixo custo e sem limite para diversos tipos de dados. Os dados podem ser acedidos a partir do interior e do exterior Google Cloud, e são replicados em várias localizações para redundância.
- AlloyDB para PostgreSQL: um serviço de base de dados totalmente gerido e compatível com PostgreSQL concebido para as suas cargas de trabalho mais exigentes, incluindo o processamento transacional e analítico híbrido.
- Document AI: uma plataforma de processamento de documentos que recebe dados não estruturados de documentos e os transforma em dados estruturados.
- Pub/Sub: um serviço de mensagens assíncrono e escalável que desassocia os serviços que produzem mensagens dos serviços que processam essas mensagens.
- Cloud Logging: um sistema de gestão de registos em tempo real com armazenamento, pesquisa, análise e alertas.
- Cloud Monitoring: um serviço que oferece visibilidade do desempenho, da disponibilidade e do estado das suas aplicações e infraestrutura.
Exemplos de utilização
A RAG é uma técnica eficaz para melhorar a qualidade do resultado gerado a partir de um LLM. Esta secção apresenta exemplos de utilização para os quais pode usar aplicações de IA generativa com capacidade de RAG.
Recomendações personalizadas de produtos
Um site de compras online pode usar um chatbot com tecnologia de MDIs para ajudar os clientes a encontrar produtos ou receber ajuda relacionada com compras. As perguntas de um utilizador podem ser melhoradas através da utilização de dados do histórico sobre o comportamento de compra do utilizador e os padrões de interação com o Website. Os dados podem incluir críticas e feedback dos utilizadores armazenados num arquivo de dados não estruturado ou métricas relacionadas com a pesquisa armazenadas num data warehouse de estatísticas da Web. A pergunta aumentada pode ser processada pelo MDG para gerar respostas personalizadas que o utilizador pode considerar mais apelativas e convincentes.
Sistemas de assistência clínica
Os médicos nos hospitais precisam de analisar e diagnosticar rapidamente o estado de saúde de um paciente para tomar decisões sobre os cuidados e a medicação adequados. Uma aplicação de IA generativa que usa um MDI/CE médico, como o Med-PaLM, pode ser usada para ajudar os médicos no respetivo processo de diagnóstico clínico. As respostas que a aplicação gera podem basear-se em registos de pacientes históricos, contextualizando os comandos dos médicos com dados da base de dados de registos de saúde eletrónicos (RSE) do hospital ou de uma base de conhecimentos externa, como o PubMed.
Investigação jurídica eficiente
A pesquisa jurídica baseada em IA generativa permite que os advogados consultem rapidamente grandes volumes de estatutos e leis de casos para identificar precedentes legais relevantes ou resumir conceitos jurídicos complexos. O resultado desta pesquisa pode ser melhorado através do aumento dos comandos de um advogado com dados obtidos do conjunto de dados proprietário de contratos, comunicações legais anteriores e registos de casos internos do escritório de advogados. Esta abordagem de design garante que as respostas geradas são relevantes para o domínio jurídico em que o advogado se especializa.
Alternativas de design
Esta secção apresenta abordagens de design alternativas que pode considerar para a sua aplicação de IA generativa com capacidade de RAG no Google Cloud.
Pesquisa vetorial totalmente gerida
Se precisar de uma arquitetura que use um produto de pesquisa vetorial totalmente gerido, pode usar a Vertex AI e a pesquisa vetorial, que fornece uma infraestrutura de publicação otimizada para a pesquisa vetorial em grande escala. Para mais informações, consulte o artigo Infraestrutura de RAG para IA generativa com a Vertex AI e a pesquisa vetorial.
Modelos e ferramentas de código aberto
Se quiser criar e implementar rapidamente aplicações de IA generativa com capacidade de RAG usando ferramentas e modelos de código aberto Ray, Hugging Face e LangChain, consulte o artigo Infraestrutura de RAG para IA generativa com o GKE e o Cloud SQL.
Outras opções
Para ver informações sobre outras opções de infraestrutura, modelos suportados e técnicas de fundamentação que pode usar para aplicações de IA generativa noGoogle Cloud, consulte o artigo Escolha modelos e infraestrutura para a sua aplicação de IA generativa.
Considerações de design
Esta secção fornece orientações para ajudar a desenvolver uma arquitetura de IA generativa com capacidade de RAG que cumpra os seus requisitos específicos de segurança e conformidade, fiabilidade, custo e desempenho. Google Cloud As orientações nesta secção não são exaustivas. Consoante os requisitos específicos da sua aplicação de IA generativa e os Google Cloud produtos e funcionalidades que usa, pode ter de considerar fatores de design e compromissos adicionais.
Segurança e conformidade
Esta secção descreve os fatores que deve considerar quando cria e desenvolve uma aplicação de IA generativa com capacidade de RAG que Google Cloud cumpra os seus requisitos de segurança e conformidade.
| Produto | Considerações de design |
|---|---|
| Vertex AI | O Vertex AI suporta Google Cloud controlos de segurança que pode usar para cumprir os seus requisitos de residência de dados, encriptação de dados, segurança de rede e transparência de acesso. Para mais informações, consulte Controlos de segurança para a Vertex AI e Controlos de segurança para a IA generativa. |
| Cloud Run |
Por predefinição, o Cloud Run encripta os dados através de uma Google-owned and Google-managed encryption key. Para proteger os seus contentores através de uma chave que controla, pode usar chaves de encriptação geridas pelo cliente (CMEK). Para mais informações, consulte o artigo Usar chaves de encriptação geridas pelo cliente. Para garantir que apenas as imagens de contentores autorizadas são implementadas nos trabalhos do Cloud Run, pode usar a Autorização binária. O Cloud Run ajuda a cumprir os requisitos de residência dos dados. As instâncias de contentores do Cloud Run são executadas na região que selecionar. |
| AlloyDB para PostgreSQL |
Por predefinição, os dados armazenados no AlloyDB for PostgreSQL são encriptados através de Google-owned and Google-managed encryption keys. Se precisar de usar chaves de encriptação que controla e gere, pode usar CMEKs. Para mais informações, consulte Acerca das CMEK. Para mitigar o risco de exfiltração de dados das bases de dados do AlloyDB for PostgreSQL, pode criar um perímetro de serviço através dos VPC Service Controls. Por predefinição, uma instância do AlloyDB for PostgreSQL só aceita ligações que usam SSL. Para proteger ainda mais as ligações às suas bases de dados do AlloyDB for PostgreSQL, pode usar o conetor do proxy Auth do AlloyDB for PostgreSQL. O conetor do proxy Auth fornece autorização de ligação baseada na gestão de identidade e de acesso (IAM) e usa uma ligação TLS 1.3 com uma cifra AES de 256 bits para validar as identidades do cliente e do servidor, bem como encriptar o tráfego de dados. Para mais informações, consulte o artigo Acerca do proxy de autorização do AlloyDB para PostgreSQL. Para ligações criadas através de Java, Python ou Go, use o conetor de idioma apropriado em vez do conetor de proxy Auth. O AlloyDB para PostgreSQL ajuda a cumprir os requisitos de residência dos dados. Os dados são armazenados ou replicados nas regiões que especificar. |
| BigQuery |
O BigQuery oferece muitas funcionalidades que pode usar para controlar o acesso aos dados, proteger dados confidenciais e garantir a precisão e a consistência dos dados. Para mais informações, consulte a Introdução à administração de dados no BigQuery. O BigQuery ajuda a cumprir os requisitos de residência dos dados. Os dados são armazenados na região que especificar. |
| Cloud Storage |
Por predefinição, os dados armazenados no Cloud Storage são encriptados através de Google-owned and Google-managed encryption keys. Se necessário, pode usar CMEKs ou as suas próprias chaves que gere através de um método de gestão externo, como chaves de encriptação fornecidas pelo cliente (CSEKs). Para mais informações, consulte Opções de encriptação de dados. O Cloud Storage suporta dois métodos para conceder aos utilizadores acesso aos seus contentores e objetos: IAM e listas de controlo de acesso (ACLs). Na maioria dos casos, recomendamos a utilização da IAM, que lhe permite conceder autorizações ao nível do contentor e do projeto. Para mais informações, consulte a vista geral do controlo de acesso. Os dados que carrega para o subsistema de carregamento de dados através do Cloud Storage podem incluir dados confidenciais. Para proteger esses dados, pode usar a Proteção de dados confidenciais para descobrir, classificar e desidentificar os dados. Para mais informações, consulte o artigo Usar a proteção de dados confidenciais com o Cloud Storage. O Cloud Storage ajuda a cumprir os requisitos de residência dos dados. Os dados são armazenados ou replicados nas regiões que especificar. |
| Pub/Sub |
Por predefinição, o Pub/Sub encripta todas as mensagens, tanto em repouso como em trânsito, através da Google-owned and Google-managed encryption keys. O Pub/Sub suporta a utilização de CMEKs para a encriptação de mensagens na camada de aplicação. Para mais informações, consulte o artigo Configurar a encriptação de mensagens. Se tiver requisitos de residência de dados, para garantir que os dados das mensagens são armazenados em localizações específicas, pode configurar políticas de armazenamento de mensagens. |
| Document AI | Por predefinição, os dados em repouso são encriptados com chaves de encriptação geridas pela Google. Se precisar de usar chaves de encriptação que controla e gere, pode usar CMEKs. Para mais informações, consulte o artigo Segurança e conformidade da IA Documental. |
| Cloud Logging |
Os registos de auditoria da atividade do administrador estão ativados por predefinição para todos os Google Cloud serviços usados nesta arquitetura de referência. Estes registos registam chamadas API ou outras ações que modificam a configuração ou os metadados dos recursos Google Cloud . Os registos de auditoria de acesso aos dados estão ativados por predefinição para o BigQuery. Para os outros serviços usados nesta arquitetura, pode ativar os registos de auditoria de acesso a dados. Os registos permitem-lhe: Monitorizar chamadas API que leem a configuração ou os metadados de recursos ou Pedidos de utilizadores para criar, modificar ou ler dados de recursos fornecidos pelos utilizadores. Para ajudar a cumprir os requisitos de residência dos dados, pode configurar o Cloud Logging para armazenar dados de registo na região que especificar. Para mais informações, consulte o artigo Regionalize os seus registos. |
Para ver princípios e recomendações de segurança específicos das cargas de trabalho de IA e ML, consulte o artigo Perspetiva de IA e ML: segurança no Well-Architected Framework.
Fiabilidade
Esta secção descreve os fatores de design que deve considerar para criar e operar uma infraestrutura fiável para uma aplicação de IA generativa com capacidade de RAG noGoogle Cloud.
| Produto | Considerações de design |
|---|---|
| Cloud Run |
O Cloud Run é um serviço regional. Os dados são armazenados de forma síncrona em várias zonas numa região. O tráfego é automaticamente balanceado por carga nas zonas. Se ocorrer uma indisponibilidade da zona, as tarefas do Cloud Run continuam a ser executadas e os dados não são perdidos. Se ocorrer uma indisponibilidade regional, as tarefas do Cloud Run param de ser executadas até que a Google resolva a indisponibilidade. As tarefas ou os trabalhos individuais do Cloud Run podem falhar. Para lidar com essas falhas, pode usar novas tentativas de tarefas e pontos de verificação. Para mais informações, consulte o artigo Práticas recomendadas para repetições e pontos de verificação de tarefas. |
| AlloyDB para PostgreSQL |
Por predefinição, os clusters do AlloyDB for PostgreSQL oferecem alta disponibilidade (HA) com comutação por falha automática. A instância principal tem nós redundantes localizados em duas zonas diferentes numa região. Esta redundância garante que os clusters são robustos contra falhas de zona. Para planear a recuperação de interrupções de regiões, pode usar a replicação entre regiões. |
| BigQuery |
Os dados que carrega para o BigQuery são armazenados de forma síncrona em duas zonas na região que especificar. Esta redundância ajuda a garantir que os seus dados não são perdidos quando ocorre uma indisponibilidade de zona. Para mais informações sobre as funcionalidades de fiabilidade no BigQuery, consulte Compreender a fiabilidade. |
| Cloud Storage | Pode criar contentores do Cloud Storage num de três tipos de localização: regional, em duas regiões ou multirregional. Os dados armazenados em contentores regionais são replicados de forma síncrona em várias zonas numa região. Para uma maior disponibilidade, pode usar contentores de duas regiões ou multirregionais, em que os dados são replicados de forma assíncrona entre regiões. |
| Pub/Sub |
Para gerir picos temporários no tráfego de mensagens, pode configurar o controlo de fluxo nas definições do publicador. Para processar publicações com falhas, ajuste as variáveis de pedido de repetição conforme necessário. Para mais informações, consulte a secção Voltar a tentar pedidos. |
| Document AI |
O Document AI é um serviço regional. Os dados são armazenados de forma síncrona em várias zonas numa região. O tráfego é automaticamente equilibrado entre as zonas. Se ocorrer uma indisponibilidade da zona, não se perdem dados. Se ocorrer uma indisponibilidade da região, o Document AI fica indisponível até que a Google resolva a indisponibilidade. |
Para ver princípios e recomendações de fiabilidade específicos das cargas de trabalho de IA e ML, consulte o artigo Perspetiva de IA e ML: fiabilidade no Well-Architected Framework.
Otimização de custos
Esta secção fornece orientações para ajudar a otimizar o custo de configuração e funcionamento de uma aplicação de IA generativa com capacidade de RAG no Google Cloud.
| Produto | Considerações de design |
|---|---|
| Cloud Run |
Quando cria tarefas do Cloud Run, especifica a quantidade de memória e CPU a atribuir à instância do contentor. Para controlar os custos, comece com as atribuições de CPU e memória predefinidas (mínimas). Para melhorar o desempenho, pode aumentar a atribuição configurando o limite de CPU e o limite de memória. Se conseguir prever os requisitos de CPU e memória das suas tarefas do Cloud Run, pode poupar dinheiro ao receber descontos por utilização garantida. Para mais informações, consulte o artigo Descontos por utilização garantida do Cloud Run. |
| AlloyDB para PostgreSQL |
Por predefinição, uma instância principal de um cluster do AlloyDB for PostgreSQL está altamente disponível (HA). A instância tem um nó ativo e um nó de reserva. Se o nó ativo falhar, o AlloyDB para PostgreSQL faz failover para o nó de reserva automaticamente. Se não precisar de HA para as bases de dados, pode reduzir o custo tornando a instância principal do cluster numa instância básica. Uma instância básica não é robusta contra falhas de zonas e tem um tempo de inatividade mais longo durante as operações de manutenção. Para mais informações, consulte Reduza os custos com instâncias básicas. Se conseguir prever os requisitos de CPU e memória da sua instância do AlloyDB for PostgreSQL, pode poupar dinheiro ao receber descontos por utilização comprometida. Para mais informações, consulte o artigo Descontos por utilização garantida do AlloyDB para PostgreSQL. |
| BigQuery | O BigQuery permite-lhe estimar o custo das consultas antes de as executar. Para otimizar os custos das consultas, tem de otimizar o armazenamento e o cálculo das consultas. Para mais informações, consulte o artigo Estime e controle os custos. |
| Cloud Storage | Para o contentor do Cloud Storage que usa para carregar dados no subsistema de carregamento de dados, escolha uma classe de armazenamento adequada com base nos requisitos de retenção de dados e frequência de acesso das suas cargas de trabalho. Por exemplo, pode escolher a classe de armazenamento Standard e usar a Gestão do ciclo de vida de objetos para controlar os custos de armazenamento através da mudança automática de objetos para uma classe de armazenamento de custo inferior ou da eliminação de objetos com base nas condições que definir. |
| Cloud Logging |
Para controlar o custo do armazenamento de registos, pode fazer o seguinte:
|
Para ver princípios e recomendações de otimização de custos específicos das cargas de trabalho de IA e ML, consulte o artigo Perspetiva de IA e ML: otimização de custos no Well-Architected Framework.
Desempenho
Esta secção descreve os fatores que deve considerar quando cria e desenvolve uma aplicação de IA generativa com capacidade de RAG que Google Cloud satisfaça os seus requisitos de desempenho.
| Produto | Considerações de design |
|---|---|
| Cloud Run | Por predefinição, a cada instância de contentor do Cloud Run é atribuída uma CPU e 512 MiB de memória. Consoante os requisitos de desempenho dos seus trabalhos do Cloud Run, pode configurar o limite de CPU e o limite de memória. |
| AlloyDB para PostgreSQL |
Para ajudar a analisar e melhorar o desempenho das consultas das bases de dados, o AlloyDB para PostgreSQL fornece uma ferramenta Query Insights. Pode usar esta ferramenta para monitorizar o desempenho e rastrear a origem de uma consulta problemática. Para mais informações, consulte a Vista geral das estatísticas de consultas. Para obter uma vista geral do estado e do desempenho das suas bases de dados e ver métricas detalhadas, como as ligações de pico e o atraso de replicação máximo, pode usar o painel de controlo Estatísticas do sistema. Para mais informações, consulte o artigo Monitorize uma instância através do painel de controlo do AlloyDB for PostgreSQL System Insights. Para reduzir a carga na sua instância principal do AlloyDB for PostgreSQL e aumentar a capacidade para processar pedidos de leitura, pode adicionar instâncias do conjunto de leitura ao cluster. Para mais informações, consulte o artigo Nós e instâncias do AlloyDB para PostgreSQL. |
| BigQuery |
O BigQuery fornece um gráfico de execução de consultas que pode usar para analisar o desempenho das consultas e obter estatísticas de desempenho para problemas como a contenção de slots e a quota de mistura insuficiente. Para mais informações, consulte Obtenha estatísticas de desempenho das consultas. Depois de resolver os problemas que identificar através das estatísticas de desempenho das consultas, pode otimizar ainda mais as consultas usando técnicas como a redução do volume de dados de entrada e saída. Para mais informações, consulte Otimize o cálculo de consultas. |
| Cloud Storage | Para carregar ficheiros grandes, pode usar um método denominado carregamentos compostos paralelos. Com esta estratégia, o ficheiro grande é dividido em partes. Os fragmentos são carregados para o Cloud Storage em paralelo e, em seguida, os dados são recompostos na nuvem. Os carregamentos compostos paralelos podem ser mais rápidos do que as operações de carregamento normais quando a largura de banda da rede e a velocidade do disco não são fatores limitativos. No entanto, esta estratégia tem algumas limitações e implicações de custos. Para mais informações, consulte o artigo Carregamentos compostos paralelos. |
Para ver princípios e recomendações de otimização do desempenho específicos das cargas de trabalho de IA e ML, consulte o artigo Perspetiva de IA e ML: otimização do desempenho no Well-Architected Framework.
Implementação
Para começar e experimentar a criação de infraestrutura Google Cloud para aplicações de IA generativa com capacidade de RAG, pode usar a solução de início rápido: IA generativa RAG com o Cloud SQL. Esta solução implementa uma aplicação de chat baseada em Python no Cloud Run e usa uma base de dados do Cloud SQL totalmente gerida para a pesquisa vetorial. O código de exemplo para esta solução está disponível no GitHub.
O que se segue?
- Escolha modelos e infraestrutura para a sua aplicação de IA generativa
- Crie uma aplicação de chat baseada em LLM e RAG com o AlloyDB para PostgreSQL e o LangChain
- Infraestrutura RAG para IA generativa com a Vertex AI e a pesquisa vetorial
- Infraestrutura de RAG para IA generativa com o GKE e o Cloud SQL
- Infraestrutura de RAG para IA generativa com o Google Agentspace e o Vertex AI
- Infraestrutura GraphRAG para IA generativa com o Vertex AI e o Spanner Graph
- Para uma vista geral dos princípios e recomendações de arquitetura específicos das cargas de trabalho de IA e ML no Google Cloud, consulte aperspetiva de IA e ML no Well-Architected Framework.
- Para ver mais arquiteturas de referência, diagramas e práticas recomendadas, explore o Centro de arquitetura na nuvem.
Colaboradores
Autor: Kumar Dhanagopal | Cross-Product Solution Developer
Outros colaboradores:
- Andrew Brook | Engineering Director
- Anna Berenberg | Engineering Fellow
- Assaf Namer | Principal Cloud Security Architect
- Balachandar Krishnamoorthy | Principal Software Engineer
- Daniel Lees | Arquiteto de segurança da nuvem
- Derek Downey | Developer Relations Engineer
- Eran Lewis | Senior Product Manager
- Geoffrey Anderson | Gestor de produtos
- Gleb Otochkin | Cloud Advocate, Databases
- Hamsa Buvaraghan | AI Product Manager
- Irina Sigler | Product Manager
- Jack Wotherspoon | Consultor de programadores
- Jason Davenport | Consultor de programadores
- Jordan Totten | Customer Engineer
- Julia Wiesinger | Product Manager
- Kara Greenfield | Customer Engineer
- Kurtis Van Gent | Staff Software Engineer
- Per Jacobsson | Engenheiro de software
- Pranav Nambiar | Director
- Richard Hendricks | Architecture Center Staff
- Safiuddin Khaja | Engenheiro da nuvem
- Sandy Ghai | Gestor de produtos de grupo
- Vladimir Vuskovic | Product Management Director
- Steren Giannini | Group Product Manager
- Wietse Venema | Developer Relations Engineer