Este documento fornece uma arquitetura de referência que pode usar para estruturar a infraestrutura para executar uma aplicação de IA generativa com geração aumentada de obtenção (RAG) usando o Google Kubernetes Engine (GKE), o Cloud SQL e ferramentas de código aberto, como o Ray, o Hugging Face e o LangChain. Para ajudar a experimentar esta arquitetura de referência, é fornecida uma aplicação de exemplo e uma configuração do Terraform no GitHub.
Este documento destina-se a programadores que querem criar e implementar rapidamente aplicações de IA generativa com capacidade de RAG usando ferramentas e modelos de código aberto. Presupõe que tem experiência na utilização do GKE e do Cloud SQL, e que tem uma compreensão conceptual da IA, da aprendizagem automática (AA) e dos modelos de linguagem (conteúdo extenso) (MDLs/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 um subsistema de publicação e um subsistema de incorporação.
- O subsistema de publicação processa o fluxo de pedido-resposta entre a aplicação e os respetivos utilizadores. O subsistema inclui um servidor de front-end, um servidor de inferência e um serviço de IA responsável (RAI). O subsistema de publicação interage com o subsistema de incorporação através de uma base de dados vetorial.
- O subsistema de incorporação ativa a capacidade de RAG na arquitetura. Este subsistema faz o seguinte:
- Carrega dados de origens de dados no local e noutras plataformas na nuvem. Google Cloud
- Converte os dados carregados em incorporações vetoriais.
- Armazena as incorporações numa base de dados vetorial.
O diagrama seguinte mostra uma vista detalhada da arquitetura:
Conforme mostrado no diagrama anterior, o servidor de front-end, o servidor de inferência e o serviço de incorporação são implementados num cluster do GKE regional no modo Autopilot. Os dados para a RAG são carregados através de um contentor do Cloud Storage. A arquitetura usa uma instância do Cloud SQL para PostgreSQL com a extensão pgvector como base de dados vetorial para armazenar incorporações e realizar pesquisas semânticas.
As bases de dados vetoriais
são concebidas para armazenar e obter vetores de alta dimensão de forma eficiente.
As secções seguintes descrevem os componentes e o fluxo de dados em cada subsistema da arquitetura.
Subsistema de incorporação
Segue-se o fluxo de dados no subsistema de incorporação:
- Os dados de origens externas e internas são carregados para o contentor do Cloud Storage por utilizadores humanos ou através de programação. Os dados carregados podem estar em ficheiros, bases de dados ou dados transmitidos em streaming.
- (Não apresentado no diagrama de arquitetura.) A atividade de carregamento de dados aciona um evento que é publicado num serviço de mensagens como o Pub/Sub. O serviço de mensagens envia uma notificação ao serviço de incorporação.
- Quando o serviço de incorporação recebe uma notificação de um evento de carregamento de dados, faz o seguinte:
- Obtém dados do contentor do Cloud Storage através do controlador CSI do FUSE do Cloud Storage.
- Lê os dados carregados e pré-processa-os através do Ray Data. O pré-processamento pode incluir a divisão dos dados em partes e a sua transformação num formato adequado para a geração de incorporações.
- Executa uma tarefa do Ray para criar incorporações vetorizadas dos dados pré-processados usando um modelo de código aberto como intfloat/multilingual-e5-small implementado no mesmo cluster.
- Escreve as incorporações vetorizadas na base de dados de vetores do Cloud SQL para PostgreSQL.
Conforme descrito na secção seguinte, quando o subsistema de publicação processa os pedidos dos utilizadores, usa as incorporações na base de dados vetorial para obter dados específicos do domínio relevantes.
Subsistema de publicação
Segue-se o fluxo de pedido-resposta no subsistema de publicação:
- Um utilizador envia um pedido em linguagem natural a um servidor de front-end através de uma interface de chat baseada na Web. O servidor de front-end é executado no GKE.
- O servidor de front-end executa um processo do
LangChain
que faz o seguinte:
- Converte o pedido de linguagem natural em incorporações através do mesmo modelo e parâmetros que o serviço de incorporação usa.
- Obtém dados de fundamentação relevantes através da realização de uma pesquisa semântica das incorporações na base de dados vetorial. A pesquisa semântica ajuda a encontrar incorporações com base na intenção de um comando, em vez do respetivo conteúdo textual.
- Constrói um comando contextualizado combinando o pedido original com os dados de fundamentação obtidos.
- Envia o comando contextualizado para o servidor de inferência, que é executado no GKE.
- O servidor de inferência usa a estrutura de publicação Hugging Face TGI para publicar um LLM de código aberto, como o Mistral-7B-Instruct ou um modelo aberto Gemma.
O MDG gera uma resposta ao comando e o servidor de inferência envia a resposta ao servidor de front-end.
Pode armazenar e ver registos da atividade de pedido-resposta no Cloud Logging e configurar a monitorização baseada em registos através do Cloud Monitoring. Também pode carregar as respostas geradas no BigQuery para análise offline.
O servidor de front-end invoca um serviço RAI para aplicar os filtros de segurança necessários à resposta. Pode usar ferramentas como a proteção de dados confidenciais e a API Cloud Natural Language para descobrir, filtrar, classificar e desidentificar conteúdo confidencial nas respostas.
O servidor de front-end envia a resposta filtrada ao utilizador.
Produtos usados
Segue-se um resumo dos Google Cloud e produtos de código aberto que a arquitetura anterior usa:
Google Cloud produtos
- Google Kubernetes Engine (GKE): um serviço Kubernetes que pode usar para implementar e operar aplicações em contentores em grande escala através da infraestrutura da Google.
- 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.
- Cloud SQL: um serviço de base de dados relacional totalmente gerido que ajuda a aprovisionar, operar e gerir as suas bases de dados MySQL, PostgreSQL e SQL Server no Google Cloud.
Produtos de código aberto
- Hugging Face Text Generation Inference (TGI): um conjunto de ferramentas para implementar e servir MDIs.
- Ray: uma framework de computação unificada de código aberto que ajuda a dimensionar cargas de trabalho de IA e Python.
- LangChain: uma framework para desenvolver e implementar aplicações baseadas em MDIs.
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.
Base de dados Google Cloud com vetores
Se quiser tirar partido das capacidades de armazenamento de vetores de uma base de dados Google Cloud totalmente gerida, como o AlloyDB para PostgreSQL ou o Cloud SQL, para a sua aplicação RAG, consulte o artigo Infraestrutura RAG para IA generativa com a Vertex AI e o AlloyDB para PostgreSQL.
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 e executar uma arquitetura de IA generativa com capacidade de RAG alojada no GKE que cumpre os seus requisitos específicos de segurança e conformidade, fiabilidade, custo e desempenho. As orientações nesta secção não são exaustivas. Consoante os requisitos específicos da sua aplicação e os produtos e funcionalidades que usa, pode ter de considerar fatores de design e compromissos adicionais. Google Cloud
Para orientações de design relacionadas com as ferramentas de código aberto nesta arquitetura de referência, como o Hugging Face TGI, consulte a documentação dessas ferramentas.
Segurança, privacidade e conformidade
Esta secção descreve os fatores que deve ter em consideração quando cria e desenvolve uma aplicação de IA generativa com capacidade de RAG que Google Cloud cumpra os seus requisitos de segurança, privacidade e conformidade.
| Produto | Considerações de design |
|---|---|
| GKE |
No modo de funcionamento do Autopilot, o GKE pré-configura o cluster e gere os nós de acordo com as práticas recomendadas de segurança, o que lhe permite focar-se na segurança específica da carga de trabalho. Para mais informações, consulte o seguinte: Para garantir o controlo de acesso melhorado para as suas aplicações em execução no GKE, pode usar o Identity-Aware Proxy (IAP). O IAP integra-se com o recurso Ingress do GKE e garante que apenas os utilizadores autenticados com a função de gestão de identidade e de acesso (IAM) correta podem aceder às aplicações. Para mais informações, consulte Ativar o IAP para o GKE. Por predefinição, os seus dados no GKE são encriptados em repouso e em trânsito através de Google-owned and Google-managed encryption keys. Como uma camada adicional de segurança para dados sensíveis, pode encriptar dados na camada de aplicação através de uma chave que detém e gere com o Cloud KMS. Para mais informações, consulte o artigo Encriptar segredos na camada de aplicação. Se usar um cluster do GKE padrão, pode usar as seguintes capacidades de encriptação de dados adicionais:
|
| Cloud SQL |
A instância do Cloud SQL na arquitetura não tem de ser acessível a partir da Internet pública. Se for necessário acesso externo à instância do Cloud SQL, pode encriptar as ligações externas através de SSL/TLS ou do conetor do proxy Auth do Cloud SQL. O conetor do proxy Auth fornece autorização de ligação através da IAM. O conetor 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 ligações criadas através de Java, Python, Go ou Node.js, use o conetor de linguagem adequado em vez do conetor do proxy Auth. Por predefinição, o Cloud SQL usa chaves de encriptação de dados (DEK) e chaves de encriptação de chaves (KEK) pertencentes e geridas pela Google para encriptar dados em repouso. Se precisar de usar KEKs que controla e gere, pode usar chaves de encriptação geridas pelo cliente (CMEKs). Para impedir o acesso não autorizado à API Cloud SQL Admin, pode criar um perímetro de serviço através dos VPC Service Controls. Para ver informações sobre a configuração do Cloud SQL para ajudar a cumprir os requisitos de residência dos dados, consulte a Vista geral da residência dos dados. |
| 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 controlar o acesso dos utilizadores 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. Para mitigar o risco de exfiltração de dados do Cloud Storage, pode criar um perímetro de serviço através dos VPC Service Controls. 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. |
| Todos os produtos nesta arquitetura |
Os registos de auditoria da atividade de administrador estão ativados por predefinição para todos os Google Cloud serviços usados nesta arquitetura de referência. Pode aceder aos registos através do Cloud Logging e usá-los para monitorizar chamadas API ou outras ações que modifiquem a configuração ou os metadados dos Google Cloud recursos. Os registos de auditoria de acesso a dados também estão ativados por predefinição para todos os Google Cloud serviços nesta arquitetura. Pode usar estes registos para monitorizar o seguinte:
|
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 |
|---|---|
| GKE |
Com o modo de funcionamento do Autopilot usado nesta arquitetura, o GKE oferece as seguintes capacidades de fiabilidade incorporadas:
Para garantir que existe capacidade de GPU suficiente quando necessário para a criação de uma escala automática do cluster do GKE, pode criar e usar reservas. Uma reserva oferece capacidade garantida numa zona específica para um recurso especificado. Uma reserva pode ser específica de um projeto ou partilhada por vários projetos. Incorre em custos pelos recursos reservados, mesmo que os recursos não sejam aprovisionados ou usados. Para mais informações, consulte o artigo Consumir recursos zonais reservados. |
| Cloud SQL |
Para garantir que a base de dados vetorial é robusta contra falhas da base de dados e interrupções de zonas, use uma instância do Cloud SQL configurada com HA. Em caso de falha da base de dados principal ou de uma indisponibilidade de zona, o Cloud SQL faz failover automaticamente para a base de dados em espera noutra zona. Não precisa de alterar o endereço IP do ponto final da base de dados. Para garantir que as suas instâncias do Cloud SQL estão abrangidas pelo contrato de nível de serviço, siga as diretrizes operacionais recomendadas. Por exemplo: certifique-se de que a CPU e a memória têm o tamanho adequado para a carga de trabalho e ative os aumentos automáticos de armazenamento. Para mais informações, consulte as Diretrizes operacionais. |
| 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, onde os dados são replicados de forma assíncrona em regiões. |
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 |
|---|---|
| GKE |
No modo Autopilot, o GKE otimiza a eficiência da infraestrutura do seu cluster com base nos requisitos da carga de trabalho. Não precisa de monitorizar constantemente a utilização de recursos nem gerir a capacidade para controlar os custos. Se conseguir prever a utilização da CPU, da memória e do armazenamento efémero do cluster do GKE Autopilot, pode poupar dinheiro recebendo descontos por utilização comprometida. Para mais informações, consulte Descontos por utilização garantida do GKE. Para reduzir o custo de execução da sua aplicação, pode usar VMs de instância pré-emptível para os seus nós do GKE. As VMs de capacidade instantânea têm um preço inferior ao das VMs padrão, mas não oferecem qualquer garantia de disponibilidade. Para ver informações sobre as vantagens dos nós que usam VMs de spot, como funcionam no GKE e como agendar cargas de trabalho nesses nós, consulte o artigo VMs de spot. Para mais orientações sobre a otimização de custos, consulte o artigo Práticas recomendadas para executar aplicações Kubernetes otimizadas em termos de custos no GKE. |
| Cloud SQL |
Uma configuração de alta disponibilidade (HA) ajuda a reduzir o tempo de inatividade da sua base de dados do Cloud SQL quando a zona ou a instância fica indisponível. No entanto, o custo de uma instância configurada com HA é superior ao de uma instância autónoma. Se não precisar de HA para a base de dados vetorial, pode reduzir o custo usando uma instância autónoma, que não é robusta contra falhas de zonas. Pode detetar se a sua instância do Cloud SQL tem provisionamento excessivo e otimizar a faturação através das estatísticas de custos e recomendações do Cloud SQL com tecnologia do Active Assist. Para mais informações, consulte o artigo Reduza as instâncias do Cloud SQL com aprovisionamento excessivo. Se conseguir prever os requisitos de CPU e memória da sua instância do Cloud SQL, pode poupar dinheiro ao receber descontos por utilização comprometida. Para mais informações, consulte o artigo Descontos por utilização garantida do Cloud SQL. |
| 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. Quando escolher a classe de armazenamento, tenha em atenção 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, pode escolher a classe Standard e usar a Gestão do ciclo de vida de objetos. Ao fazê-lo, permite a mudança automática de objetos para uma classe de armazenamento de custo inferior ou a eliminação de objetos com base nas condições que definir. |
Para estimar o custo dos seus Google Cloud recursos, use a Google Cloud calculadora de preços.
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.
Otimização do 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 |
|---|---|
| GKE |
Escolha as
classes de computação adequadas para os seus 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 incorporação, recomendamos que use um
tipo de máquina de GPU, como nvidia-l4.
|
| Cloud SQL |
Para otimizar o desempenho da sua instância do Cloud SQL, certifique-se de que a CPU e a memória alocadas à instância são adequadas para a carga de trabalho. Para mais informações, consulte o artigo Otimize instâncias do Cloud SQL com aprovisionamento insuficiente. Para melhorar o tempo de resposta da pesquisa de vetores de vizinhos mais próximos aproximados (ANN), use o índice de ficheiros invertidos com compressão simples (IVFFlat) ou o índice de hierarquia navegável de pequeno mundo (HNSW) Para ajudar a analisar e melhorar o desempenho das consultas das bases de dados, o Cloud SQL oferece 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 o artigo Use as estatísticas de consultas para melhorar o desempenho das 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 a utilização do disco, pode usar o painel de controlo Estatísticas do sistema. Para mais informações, consulte Use as estatísticas do sistema para melhorar o desempenho do sistema. |
| 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. Quando a largura de banda da rede e a velocidade do disco não são fatores limitativos, os carregamentos compostos paralelos podem ser mais rápidos do que as operações de carregamento normais. 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 implementar uma topologia baseada nesta arquitetura de referência, pode transferir e usar o código de exemplo de código aberto disponível num repositório no GitHub. O código de exemplo não se destina a exemplos de utilização em produção. Pode usar o código para experimentar a configuração da infraestrutura de IA para uma aplicação de IA generativa com RAG.
O exemplo de código faz o seguinte:
- Aprovisiona uma instância do Cloud SQL para PostgreSQL para servir como base de dados de vetores.
- Implementa o Ray, o JupyterHub e o Hugging Face TGI num cluster do GKE que especificar.
- Implementa uma aplicação de chatbot baseada na Web de exemplo no seu cluster do GKE para lhe permitir validar a capacidade de RAG.
Para obter instruções sobre como usar o código de exemplo, consulte o ficheiro README do código. Se ocorrerem erros quando usar o código de exemplo e não existirem problemas no GitHub para esses erros, crie problemas no GitHub.
O exemplo de código implementa recursos Google Cloud faturáveis. Quando terminar de usar o código, remova todos os recursos de que já não precisa.
O que se segue?
- Reveja os seguintes guias de práticas recomendadas do GKE:
- Apresente modelos abertos Gemma com GPUs no GKE com o TGI do Hugging Face.
- Crie uma infraestrutura RAG para IA generativa com a Vertex AI e a pesquisa vetorial.
- Crie uma infraestrutura RAG para IA generativa com o Vertex AI e o AlloyDB para PostgreSQL.
- Crie uma infraestrutura RAG para IA generativa com o Google Agentspace e a Vertex AI.
- Crie uma infraestrutura GraphRAG para IA generativa com a 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:
- Anna Berenberg | Engineering Fellow
- Ali Zaidi | Solutions Architect
- Bala Narasimhan | Group Product Manager
- Bill Bernsen | Engenheiro de segurança
- Brandon Royal | Outbound Product Manager
- Cynthia Thomas | Product Manager
- Geoffrey Anderson | Gestor de produtos
- Gleb Otochkin | Cloud Advocate, Databases
- Jack Wotherspoon | Consultor de programadores
- Julie Amundson | Senior Staff Software Engineer
- Kent Hua | Solutions Manager
- Kavitha Rajendran | Especialista em IA/AM, arquiteta de soluções
- Mark Schlagenhauf | Redator técnico, redes
- Megan O'Keefe | Consultora de programadores
- Mofi Rahman | Google Cloud Advocate