En este documento se proporciona una arquitectura de referencia que puedes usar para diseñar la infraestructura que se necesita para ejecutar una aplicación de IA generativa con generación aumentada por recuperación (RAG) mediante Google Kubernetes Engine (GKE), Cloud SQL y herramientas de código abierto como Ray, Hugging Face y LangChain. Para ayudarte a experimentar con esta arquitectura de referencia, se proporcionan una aplicación de ejemplo y una configuración de Terraform en GitHub.
Este documento está dirigido a los desarrolladores que quieran crear y desplegar rápidamente aplicaciones de IA generativa compatibles con RAG usando herramientas y modelos de código abierto. Se da por hecho que tienes experiencia con GKE y Cloud SQL, y que tienes una idea general de la IA, el aprendizaje automático y los modelos de lenguaje extensos (LLMs). En este documento no se explica cómo diseñar y desarrollar una aplicación de IA generativa.
Arquitectura
En el siguiente diagrama se muestra una vista general de la arquitectura de una aplicación de IA generativa compatible con RAG en Google Cloud:
La arquitectura contiene un subsistema de servicio y un subsistema de inserción.
- El subsistema de publicación gestiona el flujo de solicitud-respuesta entre la aplicación y sus usuarios. El subsistema incluye un servidor frontend, un servidor de inferencia y un servicio de IA responsable (RAI). El subsistema de servicio interactúa con el subsistema de incrustación a través de una base de datos de vectores.
- El subsistema de inserción habilita la función RAG en la arquitectura. Este subsistema hace lo siguiente:
- Ingiere datos de fuentes de datos en Google Cloud, entornos on-premise y otras plataformas en la nube.
- Convierte los datos ingeridos en incrustaciones de vectores.
- Almacena las inserciones en una base de datos de vectores.
En el siguiente diagrama se muestra una vista detallada de la arquitectura:
Como se muestra en el diagrama anterior, el servidor frontend, el servidor de inferencia y el servicio de inserción se despliegan en un clúster de GKE regional en modo Autopilot. Los datos de RAG se ingieren a través de un segmento de Cloud Storage. La arquitectura usa una instancia de Cloud SQL para PostgreSQL con la extensión pgvector como base de datos de vectores para almacenar las inserciones y realizar búsquedas semánticas.
Las bases de datos vectoriales se han diseñado para almacenar y recuperar de forma eficiente vectores de gran tamaño.
En las siguientes secciones se describen los componentes y el flujo de datos de cada subsistema de la arquitectura.
Subsistema de inserción
A continuación, se muestra el flujo de datos en el subsistema de inserción:
- Los usuarios o los programas suben datos de fuentes externas e internas al segmento de Cloud Storage. Los datos subidos pueden estar en archivos, bases de datos o datos transmitidos.
- (No se muestra en el diagrama de arquitectura). La actividad de subida de datos activa un evento que se publica en un servicio de mensajería como Pub/Sub. El servicio de mensajería envía una notificación al servicio de inserción.
- Cuando el servicio de inserción recibe una notificación de un evento de subida de datos, hace lo siguiente:
- Obtiene datos del segmento de Cloud Storage a través del controlador CSI de FUSE de Cloud Storage.
- Lee los datos subidos y los preprocesa mediante Ray Data. El preprocesamiento puede incluir la división de los datos en fragmentos y su transformación en un formato adecuado para generar las inserciones.
- Ejecuta un trabajo de Ray para crear incrustaciones vectoriales de los datos preprocesados mediante un modelo de código abierto como intfloat/multilingual-e5-small, que se ha desplegado en el mismo clúster.
- Escribe las inserciones vectorizadas en la base de datos de vectores de Cloud SQL para PostgreSQL.
Como se describe en la siguiente sección, cuando el subsistema de servicio procesa las solicitudes de los usuarios, utiliza las incrustaciones de la base de datos de vectores para obtener datos específicos del dominio pertinentes.
Subsistema de servicio
A continuación, se muestra el flujo de solicitudes y respuestas en el subsistema de servicio:
- Un usuario envía una solicitud en lenguaje natural a un servidor frontend a través de una interfaz de chat basada en web. El servidor frontend se ejecuta en GKE.
- El servidor frontend ejecuta un proceso de LangChain que hace lo siguiente:
- Convierte la solicitud de lenguaje natural en inserciones mediante el mismo modelo y los mismos parámetros que utiliza el servicio de inserciones.
- Recupera datos de fundamentación relevantes realizando una búsqueda semántica de las inserciones en la base de datos de vectores. La búsqueda semántica ayuda a encontrar embeddings en función de la intención de una petición, en lugar de su contenido textual.
- Crea una petición contextualizada combinando la solicitud original con los datos de fundamentación que se han recuperado.
- Envía la petición contextualizada al servidor de inferencia, que se ejecuta en GKE.
- El servidor de inferencia usa el framework de servicio TGI de Hugging Face para servir un LLM de código abierto, como Mistral-7B-Instruct o un modelo abierto de Gemma.
El LLM genera una respuesta a la petición y el servidor de inferencia envía la respuesta al servidor frontend.
Puedes almacenar y ver los registros de la actividad de solicitud-respuesta en Cloud Logging, así como configurar la monitorización basada en registros mediante Cloud Monitoring. También puede cargar las respuestas generadas en BigQuery para realizar análisis sin conexión.
El servidor frontend invoca un servicio de RAI para aplicar los filtros de seguridad necesarios a la respuesta. Puede usar herramientas como Protección de Datos Sensibles y la API Cloud Natural Language para descubrir, filtrar, clasificar y desidentificar contenido sensible en las respuestas.
El servidor frontend envía la respuesta filtrada al usuario.
Productos usados
A continuación se muestra un resumen de los Google Cloud y productos de código abierto que usa la arquitectura anterior:
Google Cloud productos
- Google Kubernetes Engine (GKE): un servicio de Kubernetes que puedes usar para desplegar y operar aplicaciones en contenedores a gran escala con la infraestructura de Google.
- Cloud Storage: un almacén de objetos ilimitado y a un coste bajo para diversos tipos de datos. Se puede acceder a los datos desde dentro y fuera de Google Cloud, y se replican en varias ubicaciones para ofrecer redundancia.
- Cloud SQL: un servicio de bases de datos relacionales totalmente gestionado que te ayuda a aprovisionar, operar y gestionar tus bases de datos MySQL, PostgreSQL y SQL Server en Google Cloud.
Productos de código abierto
- Inferencia de generación de texto (TGI) de Hugging Face: un conjunto de herramientas para implementar y servir LLMs.
- Ray: un framework de computación unificado y de código abierto que te ayuda a escalar cargas de trabajo de IA y Python.
- LangChain: un framework para desarrollar y desplegar aplicaciones basadas en LLMs.
Casos prácticos
La RAG es una técnica eficaz para mejorar la calidad de los resultados que genera un LLM. En esta sección se proporcionan ejemplos de casos prácticos en los que puedes usar aplicaciones de IA generativa compatibles con RAG.
Recomendaciones personalizadas de productos
Un sitio de compras online puede usar un chatbot basado en LLM para ayudar a los clientes a encontrar productos o recibir asistencia relacionada con las compras. Las preguntas de un usuario se pueden mejorar usando datos históricos sobre su comportamiento de compra y sus patrones de interacción con el sitio web. Los datos pueden incluir reseñas y comentarios de usuarios que se almacenan en un almacén de datos no estructurado, o bien métricas relacionadas con las búsquedas que se almacenan en un almacén de datos de analíticas web. El LLM puede procesar la pregunta ampliada para generar respuestas personalizadas que resulten más atractivas y convincentes para el usuario.
Sistemas de asistencia clínica
Los médicos de los hospitales necesitan analizar y diagnosticar rápidamente el estado de salud de un paciente para tomar decisiones sobre la atención y la medicación adecuadas. Una aplicación de IA generativa que utilice un LLM médico como Med-PaLM se puede usar para ayudar a los médicos en el proceso de diagnóstico clínico. Las respuestas que genera la aplicación se pueden basar en el historial de los pacientes contextualizando las peticiones de los médicos con datos de la base de datos de la historia clínica electrónica del hospital o de una base de conocimientos externa, como PubMed.
Investigación jurídica eficiente
La investigación jurídica basada en IA generativa permite a los abogados consultar rápidamente grandes volúmenes de leyes y jurisprudencia para identificar precedentes jurídicos relevantes o resumir conceptos jurídicos complejos. Los resultados de estas investigaciones se pueden mejorar si se complementan las peticiones de los abogados con datos obtenidos del corpus de contratos, las comunicaciones legales anteriores y los registros de casos internos de la firma de abogados. Este enfoque de diseño asegura que las respuestas generadas sean relevantes para el ámbito jurídico en el que se especializa el abogado.
Alternativas de diseño
En esta sección se presentan enfoques de diseño alternativos que puedes tener en cuenta para tu aplicación de IA generativa compatible con RAG en Google Cloud.
Búsqueda vectorial totalmente gestionada
Si necesitas una arquitectura que use un producto de búsqueda de vectores totalmente gestionado, puedes usar Vertex AI y Vector Search, que proporciona una infraestructura de servicio optimizada para la búsqueda de vectores a gran escala. Para obtener más información, consulta Infraestructura para una aplicación de IA generativa compatible con RAG que use Vertex AI y Vector Search.
Base de datos Google Cloud con vectores
Si quieres aprovechar las funciones de almacén de vectores de una base de datos totalmente gestionada, Google Cloud como AlloyDB para PostgreSQL o Cloud SQL, para tu aplicación RAG, consulta Infraestructura para una aplicación de IA generativa compatible con RAG que use Vertex AI y AlloyDB para PostgreSQL.
Otras opciones
Para obtener información sobre otras opciones de infraestructura, modelos admitidos y técnicas de fundamentación que puedes usar en aplicaciones de IA generativa enGoogle Cloud, consulta Elegir modelos e infraestructura para tu aplicación de IA generativa.
Factores del diseño
En esta sección se ofrecen directrices para ayudarte a desarrollar y ejecutar una arquitectura de IA generativa con RAG alojada en GKE que cumpla tus requisitos específicos de seguridad, cumplimiento, fiabilidad, coste y rendimiento. Las directrices de esta sección no son exhaustivas. En función de los requisitos específicos de tu aplicación y de los Google Cloud productos y las funciones que utilices, puede que tengas que tener en cuenta otros factores de diseño y compensaciones.
Para obtener directrices de diseño relacionadas con las herramientas de código abierto de esta arquitectura de referencia, como Hugging Face TGI, consulta la documentación de esas herramientas.
Seguridad, privacidad y cumplimiento
En esta sección se describen los factores que debes tener en cuenta al diseñar y crear una aplicación de IA generativa compatible con RAG en Google Cloud que cumpla tus requisitos de seguridad, privacidad y cumplimiento.
| Producto | Factores del diseño |
|---|---|
| GKE |
En el modo de funcionamiento Autopilot, GKE preconfigura tu clúster y gestiona los nodos según las prácticas recomendadas de seguridad, lo que te permite centrarte en la seguridad específica de las cargas de trabajo. Para obtener más información, consulta las siguientes secciones:
Para asegurarte de que tus aplicaciones que se ejecutan en GKE tengan un control de acceso mejorado, puedes usar Identity-Aware Proxy (IAP). IAP se integra con el recurso Ingress de GKE y se asegura de que solo los usuarios autenticados con el rol de gestión de identidades y accesos (IAM) correcto puedan acceder a las aplicaciones. Para obtener más información, consulta Habilitar IAP para GKE. De forma predeterminada, tus datos en GKE se cifran en reposo y en tránsito mediante Google-owned and Google-managed encryption keys. Para añadir una capa de seguridad adicional a los datos sensibles, puedes encriptarlos en la capa de aplicación con una clave que te pertenezca y que gestiones con Cloud KMS. Para obtener más información, consulta Encriptar secretos en la capa de aplicación. Si usas un clúster de GKE Standard, puedes usar las siguientes funciones adicionales de cifrado de datos:
|
| Cloud SQL |
La instancia de Cloud SQL de la arquitectura no tiene por qué ser accesible desde la red de Internet pública. Si es necesario acceder externamente a la instancia de Cloud SQL, puedes cifrar las conexiones externas mediante SSL/TLS o el conector proxy de autenticación de Cloud SQL. El conector de proxy de autenticación proporciona autorización de conexión mediante la gestión de identidades y accesos. El conector usa una conexión TLS 1.3 con un cifrado AES de 256 bits para verificar las identidades del cliente y del servidor, así como para cifrar el tráfico de datos. En el caso de las conexiones creadas con Java, Python, Go o Node.js, usa el conector de lenguaje adecuado en lugar del conector de proxy de autenticación. De forma predeterminada, Cloud SQL usa claves de cifrado de datos (DEK) y claves de cifrado de claves (KEK) propiedad de Google y gestionadas por Google para cifrar los datos en reposo. Si necesitas usar KEKs que controles y gestiones, puedes usar claves de cifrado gestionadas por el cliente (CMEKs). Para evitar el acceso no autorizado a la API Cloud SQL Admin, puedes crear un perímetro de servicio mediante Controles de Servicio de VPC. Para obtener información sobre cómo configurar Cloud SQL para cumplir los requisitos de residencia de datos, consulta el resumen sobre la residencia de datos. |
| Cloud Storage |
De forma predeterminada, los datos almacenados en Cloud Storage se encriptan mediante Google-owned and Google-managed encryption keys. Si es necesario, puedes usar CMEKs o tus propias claves, que puedes gestionar con un método de gestión externo, como las claves de cifrado proporcionadas por el cliente (CSEKs). Para obtener más información, consulta las opciones de cifrado de datos. Cloud Storage admite dos métodos para controlar el acceso de los usuarios a tus segmentos y objetos: Gestión de Identidades y Accesos (IAM) y listas de control de acceso (LCAs). En la mayoría de los casos, recomendamos usar IAM, que te permite conceder permisos a nivel de segmento y de proyecto. Para obtener más información, consulta Descripción general del control de acceso. Los datos que cargues en el subsistema de ingestión de datos a través de Cloud Storage pueden incluir datos sensibles. Para proteger estos datos, puedes usar Protección de datos sensibles para descubrirlos, clasificarlos y desidentificarlos. Para obtener más información, consulta Usar Protección de Datos Sensibles con Cloud Storage. Para mitigar el riesgo de filtración externa de datos de Cloud Storage, puedes crear un perímetro de servicio con Controles de Servicio de VPC. Cloud Storage te ayuda a cumplir los requisitos de residencia de datos. Los datos se almacenan o replican en las regiones que especifiques. |
| Todos los productos de esta arquitectura |
Los registros de auditoría de actividad de administración están habilitados de forma predeterminada en todos los Google Cloud servicios que se usan en esta arquitectura de referencia. Puedes acceder a los registros a través de Cloud Logging y usarlos para monitorizar las llamadas a la API u otras acciones que modifiquen la configuración o los metadatos de los Google Cloud recursos. Los registros de auditoría de acceso a datos también están habilitados de forma predeterminada para todos los servicios de esta arquitectura. Google Cloud Puedes usar estos registros para monitorizar lo siguiente:
|
Para consultar principios y recomendaciones de seguridad específicos de las cargas de trabajo de IA y aprendizaje automático, consulta la sección Perspectiva de IA y aprendizaje automático: seguridad del framework Well-Architected.
Fiabilidad
En esta sección se describen los factores de diseño que debes tener en cuenta para crear y operar una infraestructura fiable para una aplicación de IA generativa compatible con RAG enGoogle Cloud.
| Producto | Factores del diseño |
|---|---|
| GKE |
Con el modo de funcionamiento Autopilot que se usa en esta arquitectura, GKE proporciona las siguientes funciones de fiabilidad integradas:
Para asegurarte de que haya suficiente capacidad de GPU disponible cuando sea necesario para autoescalar el clúster de GKE, puedes crear y usar reservas. Las reservas proporcionan capacidad asegurada en una zona específica para un recurso concreto. Una reserva puede ser específica de un proyecto o compartirse entre varios proyectos. Se te aplican cargos por los recursos reservados aunque no se aprovisionen o no se utilicen. Para obtener más información, consulta el artículo sobre consumo de recursos de zona reservados. |
| Cloud SQL |
Para asegurarte de que la base de datos de vectores sea resistente a los fallos de la base de datos y a las interrupciones de la zona, usa una instancia de Cloud SQL configurada para alta disponibilidad. En caso de fallo de la base de datos principal o de un corte de la zona, Cloud SQL conmuta automáticamente a la base de datos de reserva de otra zona. No es necesario cambiar la dirección IP del endpoint de la base de datos. Para asegurarte de que tus instancias de Cloud SQL estén cubiertas por el acuerdo de nivel de servicio, sigue las directrices operativas recomendadas. Por ejemplo, asegúrate de que la CPU y la memoria tengan el tamaño adecuado para la carga de trabajo y habilita los aumentos automáticos del almacenamiento. Para obtener más información, consulta las directrices operativas. |
| Cloud Storage | Puedes crear segmentos de Cloud Storage en uno de los tres tipos de ubicación: regional, birregional o multirregional. Los datos almacenados en segmentos regionales se replican de forma síncrona en varias zonas de una región. Para disfrutar de una mayor disponibilidad, puedes usar segmentos birregionales o multirregionales, en los que los datos se replican de forma asíncrona en varias regiones. |
Para consultar los principios y las recomendaciones de fiabilidad específicos de las cargas de trabajo de IA y aprendizaje automático, consulta el artículo Perspectiva de la fiabilidad de la IA y el aprendizaje automático del framework Well-Architected.
Optimización de costes
En esta sección se ofrecen directrices para ayudarte a optimizar el coste de configurar y operar una aplicación de IA generativa compatible con RAG en Google Cloud.
| Producto | Factores del diseño |
|---|---|
| GKE |
En el modo Autopilot, GKE optimiza la eficiencia de la infraestructura de tu clúster en función de los requisitos de las cargas de trabajo. No tienes que monitorizar constantemente la utilización de los recursos ni gestionar la capacidad para controlar los costes. Si puedes predecir el uso de CPU, memoria y almacenamiento efímero de tu clúster de GKE Autopilot, puedes ahorrar dinero obteniendo descuentos por uso comprometido. Para obtener más información, consulta Descuentos por compromiso de uso de GKE. Para reducir el coste de ejecutar tu aplicación, puedes usar máquinas virtuales de acceso puntual en tus nodos de GKE. Las máquinas virtuales de acceso puntual tienen un precio más bajo que las máquinas virtuales estándar, pero no ofrecen ninguna garantía de disponibilidad. Para obtener información sobre las ventajas de los nodos que usan VMs de acceso puntual, cómo funcionan en GKE y cómo programar cargas de trabajo en esos nodos, consulta VMs de acceso puntual. Para obtener más información sobre la optimización de costes, consulta las prácticas recomendadas para ejecutar aplicaciones de Kubernetes de coste optimizado en GKE. |
| Cloud SQL |
Una configuración de alta disponibilidad (HA) ayuda a reducir el tiempo de inactividad de tu base de datos de Cloud SQL cuando la zona o la instancia dejan de estar disponibles. Sin embargo, el coste de una instancia configurada para alta disponibilidad es superior al de una instancia independiente. Si no necesitas alta disponibilidad para la base de datos de vectores, puedes reducir los costes usando una instancia independiente, que no es robusta frente a las interrupciones de la zona. Puedes detectar si tu instancia de Cloud SQL está sobreaprovisionada y optimizar la facturación mediante las estadísticas de costes y las recomendaciones de Cloud SQL basadas en Active Assist. Para obtener más información, consulta Reducir el número de instancias de Cloud SQL con sobreprovisionamiento. Si puedes predecir los requisitos de CPU y memoria de tu instancia de Cloud SQL, puedes ahorrar dinero obteniendo descuentos por uso confirmado. Para obtener más información, consulta el artículo sobre los descuentos por compromiso de uso de Cloud SQL. |
| Cloud Storage | En el segmento de Cloud Storage que uses para cargar datos en el subsistema de ingestión de datos, elige una clase de almacenamiento adecuada. Cuando elijas la clase de almacenamiento, ten en cuenta los requisitos de retención de datos y frecuencia de acceso de tus cargas de trabajo. Por ejemplo, para controlar los costes de almacenamiento, puedes elegir la clase Estándar y usar la gestión del ciclo de vida de los objetos. De esta forma, se podrá degradar automáticamente la clase de almacenamiento de los objetos a una de menor coste o eliminar objetos en función de las condiciones que definas. |
Para estimar el coste de tus Google Cloud recursos, usa la Google Cloud calculadora de precios.
Para consultar los principios y las recomendaciones de optimización de costes específicos de las cargas de trabajo de IA y aprendizaje automático, consulta el artículo Perspectiva de IA y aprendizaje automático: optimización de costes del framework Well-Architected.
Optimización del rendimiento
En esta sección se describen los factores que debes tener en cuenta al diseñar y crear una aplicación de IA generativa con RAG que cumpla tus requisitos de rendimiento. Google Cloud
| Producto | Factores del diseño |
|---|---|
| GKE |
Elige las
clases de computación adecuadas para tus pods en función de los requisitos de rendimiento de las cargas de trabajo. En el caso de los pods que ejecutan el servidor de inferencia y el servicio de inserción, te recomendamos que utilices un
tipo de máquina con GPU, como nvidia-l4.
|
| Cloud SQL |
Para optimizar el rendimiento de tu instancia de Cloud SQL, asegúrate de que la CPU y la memoria asignadas a la instancia sean adecuadas para la carga de trabajo. Para obtener más información, consulta el artículo sobre cómo optimizar las instancias de Cloud SQL con recursos insuficientes. Para mejorar el tiempo de respuesta de la búsqueda vectorial del elemento aproximado más cercano (ANN), usa el índice Inverted File with Flat Compression (IVFFlat) o el índice Hierarchical Navigable Small World (HNSW). Para ayudarte a analizar y mejorar el rendimiento de las consultas de las bases de datos, Cloud SQL ofrece la herramienta Información valiosa sobre las consultas. Puedes usar esta herramienta para monitorizar el rendimiento y rastrear la fuente de una consulta problemática. Para obtener más información, consulta Usar Estadísticas de las consultas para mejorar el rendimiento de las consultas. Para obtener una vista general del estado y el rendimiento de tus bases de datos, así como para ver métricas detalladas, como las conexiones máximas y la utilización del disco, puedes usar el panel de control Estadísticas del sistema. Para obtener más información, consulta el artículo Usar Estadísticas del sistema para mejorar el rendimiento del sistema. |
| Cloud Storage | Para subir archivos grandes, puedes usar un método llamado subidas compuestas paralelas. Con esta estrategia, el archivo grande se divide en fragmentos. Los fragmentos se suben a Cloud Storage en paralelo y, a continuación, los datos se recomponen en la nube. Cuando el ancho de banda de la red y la velocidad del disco no son factores limitantes, las subidas compuestas paralelas pueden ser más rápidas que las operaciones de subida normales. Sin embargo, esta estrategia tiene algunas limitaciones y consecuencias económicas. Para obtener más información, consulta Subidas compuestas paralelas. |
Para consultar los principios y las recomendaciones de optimización del rendimiento específicos de las cargas de trabajo de IA y aprendizaje automático, consulte el artículo Perspectiva de la IA y el aprendizaje automático: optimización del rendimiento del marco de trabajo Well-Architected.
Implementación
Para desplegar una topología basada en esta arquitectura de referencia, puedes descargar y usar el código de muestra de código abierto que está disponible en un repositorio de GitHub. El código de ejemplo no está pensado para casos prácticos de producción. Puedes usar el código para experimentar con la configuración de la infraestructura de IA de una aplicación de IA generativa compatible con RAG.
El código de muestra hace lo siguiente:
- Proporciona una instancia de Cloud SQL para PostgreSQL que actuará como base de datos de vectores.
- Despliega Ray, JupyterHub y Hugging Face TGI en un clúster de GKE que especifiques.
- Despliega una aplicación de chatbot basada en web de ejemplo en tu clúster de GKE para que puedas verificar la función de RAG.
Para obtener instrucciones sobre cómo usar el código de muestra, consulta el archivo README del código. Si se produce algún error al usar el código de ejemplo y no hay incidencias abiertas en GitHub para esos errores, crea incidencias en GitHub.
El código de ejemplo implementa recursos facturables Google Cloud . Cuando termines de usar el código, elimina los recursos que ya no necesites.
Siguientes pasos
- Consulta las siguientes guías de prácticas recomendadas de GKE:
- Consulta cómo servir modelos abiertos de Gemma con GPUs en GKE mediante Hugging Face TGI.
- Consulta las Google Cloud opciones para fundamentar las respuestas de la IA generativa.
- Consulta cómo crear una infraestructura para una aplicación de IA generativa compatible con RAG que use Vertex AI y Vector Search.
- Descubre cómo crear una infraestructura para una aplicación de IA generativa compatible con RAG que use Vertex AI y AlloyDB para PostgreSQL.
- Para obtener una descripción general de los principios y las recomendaciones de arquitectura específicos de las cargas de trabajo de IA y aprendizaje automático en Google Cloud, consulta la sección Perspectiva de IA y aprendizaje automático del framework Well-Architected.
- Para ver más arquitecturas de referencia, diagramas y prácticas recomendadas, consulta el centro de arquitectura de Cloud.
Colaboradores
Autor: Kumar Dhanagopal | Desarrollador de soluciones multiproducto
Otros colaboradores:
- Anna Berenberg | Ingeniera
- Ali Zaidi | Arquitecto de soluciones
- Bala Narasimhan | Responsable de Producto de Grupo
- Bill Bernsen | Ingeniero de seguridad
- Brandon Royal | Responsable de producto saliente
- Cynthia Thomas | Responsable de producto
- Geoffrey Anderson | Responsable de producto
- Gleb Otochkin | Cloud Advocate, Databases
- Jack Wotherspoon | Ingeniero de software
- Julie Amundson | Ingeniera de software sénior
- Kent Hua | Solutions Manager
- Kavitha Rajendran | Especialista en IA y aprendizaje automático, arquitecta de soluciones
- Mark Schlagenhauf | Redactor técnico de redes
- Megan O'Keefe | Directora de Competencia de la Industria, Equipo de Evaluaciones de Cloud Platform
- Mofi Rahman | Google Cloud Advocate