Neste documento, apresentamos uma arquitetura de referência que pode ser usada para projetar a infraestrutura a fim de executar um aplicativo de inteligência artificial (IA) generativa com geração aumentada de recuperação (RAG, na sigla em inglês). O público-alvo deste documento inclui desenvolvedores e administradores de aplicativos de IA generativa e arquitetos de nuvem. Este documento considera uma compreensão básica dos conceitos de IA, machine learning (ML) e modelo de linguagem grande (LLM). 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:
A arquitetura contém os seguintes componentes interconectados:
| Componente | Finalidade | Interações |
|---|---|---|
| Subsistema de ingestão de dados | Preparar e processar os dados externos usados para ativar o recurso RAG. | O subsistema de ingestão de dados interage com os outros subsistemas na arquitetura pela camada de banco de dados. |
| Subsistema de disponibilização | Lidar com o fluxo de solicitação/resposta entre o aplicativo de IA generativa e os usuários. | O subsistema de disponibilização interage com o subsistema de ingestão de dados pela camada do banco de dados. |
| Subsistema de avaliação de qualidade | Avaliar a qualidade das respostas geradas pelo subsistema de disponibilização. | O subsistema de avaliação de qualidade interage diretamente com o subsistema de disponibilização e com o subsistema de ingestão de dados pela camada do banco de dados. |
| Bancos de dados | Armazenar os seguintes dados:
|
Todos os subsistemas da arquitetura interagem com os bancos de dados. |
O diagrama a seguir mostra uma visão detalhada da arquitetura:
As seções a seguir contêm descrições detalhadas dos componentes e do fluxo de dados dentro de cada subsistema da arquitetura.
Subsistema de ingestão de dados
O subsistema de ingestão de dados ingere dados de fontes externas, como arquivos, bancos de dados e serviços de streaming. Os dados enviados incluem comandos para avaliação da qualidade. O subsistema de ingestão de dados fornece o recurso RAG na arquitetura. O diagrama a seguir mostra detalhes do subsistema de ingestão de dados na arquitetura:
Confira a seguir as etapas do fluxo de ingestão de dados:
- É feito upload dos dados para um bucket do Cloud Storage. A fonte de dados pode ser um usuário do aplicativo que realiza upload, ingestão de banco de dados ou streaming de dados.
- Quando é feito o upload dos dados, uma notificação é enviada para um tópico do Pub/Sub.
- O Pub/Sub aciona um job do Cloud Run para processar os dados enviados.
- O Cloud Run inicia o job usando dados de configuração armazenados em um banco de dados do AlloyDB para PostgreSQL.
- O job do Cloud Run usa a Document AI para preparar os dados para processamento adicional. Por exemplo, a preparação pode incluir a análise dos dados, a conversão deles no formato necessário e a divisão dos dados em fragmentos.
O job do Cloud Run usa o modelo de embeddings da Vertex AI para texto para criar embeddings vetorizados dos dados ingeridos.
O Cloud Run armazena os embeddings em um banco de dados do AlloyDB para PostgreSQL que tem a extensão
pgvectorativada. 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
O subsistema de disponibilização lida com o fluxo de solicitação/resposta entre o aplicativo de IA generativa e os usuários. O diagrama a seguir mostra detalhes do subsistema de disponibilização na arquitetura:
Estas são as etapas do fluxo de solicitação/resposta no subsistema de disponibilização:
- Os usuários enviam solicitações ao aplicativo de IA generativa por um front-end (por exemplo, um chatbot ou app para dispositivos móveis).
O aplicativo de IA generativa converte a solicitação de linguagem natural em embeddings.
O aplicativo conclui a parte de recuperação da abordagem RAG:
- O aplicativo realiza uma pesquisa semântica do embedding no repositório de vetores do AlloyDB para PostgreSQL, que é mantido pelo subsistema de ingestão de dados. A pesquisa semântica ajuda a encontrar embeddings com base na intent de um comando no lugar do conteúdo textual dele.
- O aplicativo combina a solicitação original com os dados brutos que são recuperados com base no embedding correspondente para criar um comando contextualizado.
O aplicativo envia o comando contextualizado para uma pilha de inferência do LLM que é executada na Vertex AI.
A pilha de inferência do LLM usa um LLM de IA generativa, que pode ser um LLM de fundação ou personalizado, e gera uma resposta restrita ao contexto fornecido.
- O aplicativo pode armazenar registros da atividade de solicitação/resposta no Cloud Logging. É possível ver e usar os registros para monitoramento com o Cloud Monitoring. O Google não acessa nem usa dados de registro.
- O aplicativo carrega as respostas no BigQuery para análises off-line.
O aplicativo filtra as respostas usando filtros de IA responsável.
O aplicativo envia as respostas filtradas aos usuários pelo front-end.
Subsistema de avaliação de qualidade
O diagrama a seguir mostra detalhes do subsistema de avaliação de qualidade na arquitetura:
Quando o subsistema de avaliação de qualidade recebe uma solicitação, ocorrem as seguintes ações:
- O Pub/Sub aciona um job do Cloud Run.
- O Cloud Run inicia o job usando dados de configuração armazenados em um banco de dados do AlloyDB para PostgreSQL.
- O job do Cloud Run extrai solicitações de avaliação de um banco de dados do AlloyDB para PostgreSQL. Os comandos foram previamente enviados ao banco de dados pelo subsistema de ingestão de dados.
O job do Cloud Run usa as solicitações de avaliação para avaliar a qualidade das respostas geradas pelo subsistema de disponibilização.
O resultado dessa avaliação consiste em pontuações de avaliação de métricas como relevância e acurácia factual.
O Cloud Run carrega as pontuações de avaliação e os comandos e as respostas que foram avaliadas no BigQuery para análise futura.
Produtos usados
Veja a seguir um resumo de todos os produtos do Google Cloud que a arquitetura anterior usa:
- Vertex AI: uma plataforma de ML que permite treinar e implantar modelos de ML e aplicativos de IA, além de personalizar LLMs para uso em aplicativos com tecnologia de IA.
- Cloud Run: uma plataforma de computação sem servidor que permite executar contêineres diretamente na infraestrutura escalonável do Google.
- BigQuery: um data warehouse corporativo que ajuda a gerenciar e analisar seus dados com recursos integrados, como análise geoespacial de machine learning e Business Intelligence.
- 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.
- AlloyDB para PostgreSQL: um serviço de banco de dados totalmente gerenciado e compatível com PostgreSQL, projetado para as cargas de trabalho mais exigentes, incluindo processamento analítico e transacional híbrido.
- Document AI: uma plataforma de processamento de documentos que transforma dados não estruturados de documentos em dados estruturados.
- Pub/Sub: um serviço de mensagens assíncrono e escalonável que separa os serviços que produzem mensagens daqueles que processam essas mensagens.
- Cloud Logging: um sistema de gerenciamento de registros em tempo real com armazenamento, pesquisa, análise e alertas.
- Cloud Monitoring: um serviço que fornece visibilidade do desempenho, da disponibilidade e da integridade dos aplicativos e da infraestrutura.
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:
Pesquisa jurídica eficiente
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
Esta seção contém orientações para ajudar você a desenvolver uma arquitetura de IA generativa com capacidade de RAG no Google Cloud que atenda aos seus 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 de IA generativa e dos produtos e recursos do Google Cloud que você usa, pode ser necessário considerar outros fatores de desenvolvimento e compensações.
Segurança 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 e conformidade.
| Produto | Considerações sobre o design |
|---|---|
| Vertex AI | A Vertex AI é compatível com os controles de segurança do Google Cloud que podem ser usados para atender aos seus requisitos de residência de dados, criptografia de dados, segurança de rede e transparência no acesso. Para mais informações, consulte Controles de segurança para a Vertex AI e Controles de segurança para IA generativa. |
| Cloud Run |
Por padrão, o Cloud Run criptografa os dados usando uma chave gerenciada pelo Google. Para proteger os contêineres usando uma chave controlada por você, use chaves de criptografia gerenciadas pelo cliente (CMEK). Para mais informações, consulte Como usar chaves de criptografia gerenciadas pelo cliente. Para garantir que apenas imagens de contêiner autorizadas sejam implantadas nos jobs do Cloud Run, use a autorização binária. O Cloud Run ajuda você a atender aos requisitos de residência de dados. As instâncias de contêiner do Cloud Run são executadas na região selecionada. |
| AlloyDB para PostgreSQL |
Por padrão, os dados armazenados no AlloyDB para PostgreSQL são criptografados usando chaves de criptografia gerenciadas pelo Google. Se precisar usar chaves de criptografia controladas e gerenciadas por você, use CMEKs. Para mais informações, acesse Sobre CMEK. Para reduzir o risco de exfiltração de dados dos bancos de dados do AlloyDB para PostgreSQL, crie um perímetro de serviço usando o VPC Service Controls. Por padrão, uma instância do AlloyDB para PostgreSQL aceita apenas conexões que usam SSL. Para proteger ainda mais as conexões com os bancos de dados do AlloyDB para PostgreSQL, use o conector do proxy de autenticação do AlloyDB para PostgreSQL. O conector do proxy de autenticação fornece autorização de conexão com base no Identity and Access Management (IAM) e usa uma conexão TLS 1.3 com uma criptografia AES de 256 bits para verificar as identidades de cliente e servidor e criptografar o tráfego de dados. Para mais informações, consulte Sobre o proxy de autenticação do AlloyDB para PostgreSQL. Para conexões criadas com Java, Python ou Go, use o Conector de linguagem apropriado, em vez do conector de proxy de autenticação. O AlloyDB para PostgreSQL ajuda você a atender aos requisitos de residência de dados. Os dados são armazenados ou replicados nas regiões especificadas. |
| O BigQuery |
O BigQuery oferece muitos recursos que podem ser usados para controlar o acesso a dados, proteger dados sensíveis e garantir a acurácia e consistência dos dados. Para mais informações, consulte Introdução à governança de dados no BigQuery. O BigQuery ajuda você a atender aos requisitos de residência de dados. Os dados são armazenados na região especificada. |
| 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 conceder aos usuários acesso 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. 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. |
| Pub/Sub |
Por padrão, o Pub/Sub criptografa todas as mensagens, em repouso e em trânsito, usando chaves de criptografia gerenciadas pelo Google. O Pub/Sub pode usar CMEKs para criptografia de mensagens na camada do aplicativo. Para mais informações, consulte Como configurar a criptografia de mensagens. Se você tiver requisitos de residência de dados, para garantir que os dados das mensagens sejam armazenados em locais específicos, configure políticas de armazenamento de mensagens. |
| Document AI | Por padrão, os dados em repouso são criptografados com chaves de criptografia gerenciadas pelo Google. Se precisar usar chaves de criptografia controladas e gerenciadas por você, use CMEKs. Para mais informações, consulte Segurança e conformidade da Document AI. |
| Cloud Logging |
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. Esses registros gravam chamadas de API ou outras ações que modificam a configuração ou os metadados de recursos do Google Cloud. Os registros de auditoria de acesso a dados estão ativados por padrão para o BigQuery. Para os outros serviços usados nesta arquitetura, é possível ativar os registros de auditoria de acesso a dados. Com os registros, é possível rastrear chamadas de API que leem a configuração ou os metadados de recursos ou solicitações de usuários para criar, modificar ou ler dados de recursos fornecidos pelo usuário. Para ajudar a atender aos requisitos de residência de dados, configure o Cloud Logging para armazenar dados de registro na região especificada. Para mais informações, consulte Regionalizar seus registros. |
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 |
|---|---|
| Cloud Run |
O Cloud Run é um serviço regional. Os dados são armazenados de forma síncrona em várias zonas dentro de uma região. É feito o balanceamento de carga automático no tráfego entre as zonas. Em caso de interrupção do serviço na zona, os jobs do Cloud Run continuam em execução e os dados não são perdidos. Se ocorrer uma interrupção do serviço na região, os jobs do Cloud Run deixarão de ser executados até que o Google resolva essa interrupção. Jobs ou tarefas individuais do Cloud Run podem falhar. Para lidar com essas falhas, use novas tentativas de tarefa e checkpoints. Para mais informações, consulte Práticas recomendadas de novas tentativas de jobs e checkpoints. |
| AlloyDB para PostgreSQL |
Por padrão, os clusters do AlloyDB para PostgreSQL oferecem alta disponibilidade (HA, na sigla em inglês) com failover automático. A instância principal tem nós redundantes localizados em duas zonas diferentes dentro de uma região. Essa redundância garante que os clusters fiquem resistentes a interrupções dos serviços na zona. Para se planejar para recuperação de interrupções dos serviços na região, use a replicação entre regiões. |
| O BigQuery |
Os dados carregados no BigQuery são armazenados de maneira síncrona em duas zonas na região especificada. Essa redundância ajuda a garantir que seus dados não sejam perdidos quando ocorrer uma interrupção do serviço na zona. Para mais informações sobre recursos de confiabilidade no BigQuery, consulte Entenda a confiabilidade. |
| 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 forma 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 forma assíncrona entre regiões. |
| Pub/Sub |
Para gerenciar picos transitórios no tráfego de mensagens, configure o controle de fluxo nas configurações do editor. Para lidar com publicações que falharam, ajuste as variáveis de solicitação de nova tentativa conforme necessário. Para mais informações, consulte Repetir solicitações. |
| Document AI | A Document AI é um serviço regional. Os dados são armazenados de forma síncrona em várias zonas dentro de uma região. É feito o balanceamento de carga automático no tráfego entre as zonas. Se ocorrer uma interrupção do serviço na zona, os dados não serão perdidos. Se ocorrer uma interrupção do serviço na região, a Document AI ficará indisponível até que o Google resolva essa interrupção. |
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 |
|---|---|
| Cloud Run |
Ao criar jobs do Cloud Run, você especifica a quantidade de memória e CPU que será alocada para a instância do contêiner. Para controlar os custos, comece com as alocações padrão (mínimas) de CPU e memória. Para melhorar o desempenho, aumente a alocação configurando o limite de CPU e o limite de memória. Se você conseguir prever os requisitos de CPU e memória dos jobs do Cloud Run, será possível economizar dinheiro com descontos por compromisso de uso. Para mais informações, consulte Descontos por compromisso de uso do Cloud Run. |
| AlloyDB para PostgreSQL |
Por padrão, uma instância principal de um cluster do AlloyDB para PostgreSQL é altamente disponível (HA, na sigla em inglês). A instância tem um nó ativo e um nó em espera. Se o nó ativo falhar, o AlloyDB para PostgreSQL fará automaticamente o failover para o nó em espera. Se você não precisar de alta disponibilidade para os bancos de dados, reduza o custo tornando a instância principal do cluster uma instância básica. Uma instância básica não é resistente a interrupções dos serviços na zona e apresenta inatividade maior durante as operações de manutenção. Para mais informações, consulte Reduzir custos usando instâncias básicas. Se você conseguir prever os requisitos de CPU e memória da instância do AlloyDB para PostgreSQL, será possível economizar dinheiro com descontos por compromisso de uso. Para mais informações, consulte Descontos por compromisso de uso do AlloyDB para PostgreSQL. |
| O BigQuery | O BigQuery permite estimar o custo das consultas antes de executá-las. Para otimizar os custos de consulta, é preciso otimizar o armazenamento e a computação de consultas. Para mais informações, consulte Estimar e controlar custos. |
| Cloud Storage | Para o bucket do Cloud Storage usado para carregar dados no subsistema de ingestão de dados, escolha uma classe de armazenamento apropriada com base nos requisitos de frequência de acesso e retenção de dados das cargas de trabalho. Por exemplo, é possível escolher a classe de armazenamento Standard e usar o Gerenciamento do ciclo de vida de objetos para controlar os custos de armazenamento fazendo downgrade automático dos objetos para uma classe de armazenamento mais barata ou excluindo objetos com base nas condições definidas. |
| Cloud Logging |
Para controlar o custo de armazenamento de registros, faça isto:
|
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 |
|---|---|
| Cloud Run | Por padrão, cada instância de contêiner do Cloud Run recebe uma única CPU e 512 MiB de memória. Dependendo dos requisitos de desempenho dos jobs do Cloud Run, é possível configurar o limite de CPU e o limite de memória. |
| AlloyDB para PostgreSQL |
Para ajudar você a analisar e melhorar o desempenho de consulta dos bancos de dados, o AlloyDB para PostgreSQL oferece a ferramenta Query Insights. Use essa ferramenta para monitorar o desempenho e rastrear a origem de uma consulta problemática. Para mais informações, consulte a visão geral do Query Insights. 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 atraso máximo de replicação, use o painel "Insights do sistema". Para mais informações, consulte Monitorar uma instância usando o painel "Insights do sistema" do AlloyDB para PostgreSQL. Para reduzir a carga na instância principal do AlloyDB para PostgreSQL e escalonar horizontalmente a capacidade de processar solicitações de leitura, adicione instâncias do pool de leitura ao cluster. Para mais informações, consulte Instâncias e nós do AlloyDB para PostgreSQL. |
| O BigQuery |
O BigQuery oferece um gráfico de execução de consulta que pode ser usado para analisar o desempenho da consulta e receber insights de desempenho sobre problemas como contenção de slots e cota de embaralhamento insuficiente. Para mais informações, acesse Receber insights de desempenho de consulta. Depois de resolver os problemas identificados com os insights de desempenho de consulta, 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 Otimizar a computação de consultas. |
| 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. Os uploads compostos paralelos podem ser mais rápidos do que as operações de upload normais quando a largura de banda da rede e a velocidade do disco não são fatores limitantes. No entanto, essa estratégia tem algumas limitações e implicações de custo. Para mais informações, consulte Uploads compostos paralelos. |
A seguir
- Saiba como criar aplicativos de IA generativa com a API PaLM da Vertex AI e o LangChain.
- Saiba como criar aplicativos empresariais de IA generativa com bancos de dados do Google Cloud.
- Saiba como o novo aplicativo de recuperação de bancos de dados de IA generativa ajuda a melhorar as respostas do LLM.
- Teste o codelab para criar um aplicativo de chat baseado em LLM e RAG usando a IA do AlloyDB para PostgreSQL e o LangChain.
- Teste o resumo de documentos de IA generativa.
- Leia sobre a Geração aumentada de recuperação para tarefas de PLN com uso intenso de conhecimentos.
- Leia sobre a Geração aumentada de recuperação para modelos de linguagem grandes.
- Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.
Colaboradores
Autor: Kumar Dhanagopal | Desenvolvedor de soluções de vários produtos
Outros colaboradores:
- Andrew Brook | Diretor de engenharia
- Anna Berenberg | Pesquisadora de engenharia
- Assaf Namer | Arquiteto principal de segurança de nuvem
- Balachandar Krishnamoorthy | Engenheiro principal de software
- Daniel Lees | Arquiteto de segurança do Cloud
- Derek Downey | Engenheiro de relações com desenvolvedores
- Geoffrey Anderson | Gerente de produtos
- Gleb Otochkin Mediador da nuvem, bancos de dados
- Hamsa Buvaraghan | Gerente de produtos de IA
- Irina Sigler | Gerente de produtos
- Jack Wotherspoon | Engenheiro de software
- Jason Davenport | Mediador de desenvolvedores
- Julia Wiesinger | Gerente de produtos
- Kara Greenfield | Engenheira de clientes
- Kurtis Van Gent | Engenheiro de software de equipe
- Por Jacobsson | Engenheiro de software
- Pranav Nambiar | Diretor
- Richard Hendricks | Equipe do centro de arquitetura
- Safiuddin Khaja | Engenheiro do nuvem
- Vladimir Vuskovic | Diretor de gerenciamento de produtos
- Steren Giannini | Gerente de produto do grupo
- Wietse Venema | Engenheiro de relações com desenvolvedores