En este documento se proporciona una arquitectura de referencia que puedes usar para diseñar la infraestructura que te permita ejecutar una aplicación de inteligencia artificial (IA) generativa con generación aumentada de recuperación (RAG). Este documento está dirigido a desarrolladores y administradores de aplicaciones de IA generativa, así como a arquitectos de la nube. En este documento se presupone que tienes conocimientos básicos sobre los conceptos de IA, aprendizaje automático y modelos de lenguaje extensos. 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 los siguientes componentes interconectados:
| Componente | Finalidad | Interacciones |
|---|---|---|
| Subsistema de ingestión de datos | Prepara y procesa los datos externos que se usan para habilitar la función de RAG. | El subsistema de ingestión de datos interactúa con los demás subsistemas de la arquitectura a través de la capa de base de datos. |
| Subsistema de servicio | Gestionar el flujo de solicitud-respuesta entre la aplicación de IA generativa y sus usuarios. | El subsistema de servicio interactúa con el subsistema de ingestión de datos a través de la capa de base de datos. |
| Subsistema de evaluación de la calidad | Evalúa la calidad de las respuestas que genera el subsistema de publicación. | El subsistema de evaluación de la calidad interactúa directamente con el subsistema de servicio y con el subsistema de ingestión de datos a través de la capa de base de datos. |
| Bases de datos | Almacena los siguientes datos:
|
Todos los subsistemas de la arquitectura interactúan con las bases de datos. |
En el siguiente diagrama se muestra una vista detallada de la arquitectura:
En las siguientes secciones se describen en detalle los componentes y el flujo de datos de cada subsistema de la arquitectura.
Subsistema de ingestión de datos
El subsistema de ingestión de datos ingiere datos de fuentes externas, como archivos, bases de datos y servicios de streaming. Los datos subidos incluyen peticiones para evaluar la calidad. El subsistema de ingestión de datos proporciona la función RAG en la arquitectura. En el siguiente diagrama se muestran los detalles del subsistema de ingestión de datos de la arquitectura:
Estos son los pasos del flujo de ingestión de datos:
- Los datos se suben a un segmento de Cloud Storage. La fuente de datos puede ser un usuario de una aplicación que suba datos, los ingiera en una base de datos o los transmita.
- Cuando se suben datos, se envía una notificación a un tema de Pub/Sub.
- Pub/Sub activa una tarea de Cloud Run para procesar los datos subidos.
- Cloud Run inicia el trabajo usando los datos de configuración almacenados en una base de datos de AlloyDB para PostgreSQL.
- La tarea de Cloud Run usa Document AI para preparar los datos para su posterior tratamiento. Por ejemplo, la preparación puede incluir analizar los datos, convertirlos al formato necesario y dividirlos en fragmentos.
La tarea de Cloud Run usa el modelo Embeddings for Text de Vertex AI para crear inserciones vectorizadas de los datos ingeridos.
Cloud Run almacena las inserciones en una base de datos de AlloyDB para PostgreSQL que tiene habilitada la extensión
pgvector. Como se describe en la sección siguiente, 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
El subsistema de servicio gestiona el flujo de solicitud-respuesta entre la aplicación de IA generativa y sus usuarios. En el siguiente diagrama se muestran los detalles del subsistema de servicio de la arquitectura:
Estos son los pasos del flujo de solicitud y respuesta en el subsistema de servicio:
- Los usuarios envían solicitudes a la aplicación de IA generativa a través de un frontend (por ejemplo, un chatbot o una aplicación móvil).
La aplicación de IA generativa convierte la petición en lenguaje natural en incrustaciones.
La aplicación completa la parte de recuperación del enfoque RAG:
- La aplicación realiza una búsqueda semántica del embedding en el almacén de vectores de AlloyDB para PostgreSQL que mantiene el subsistema de ingesta de datos. La búsqueda semántica ayuda a encontrar embeddings basados en la intención de una petición en lugar de en su contenido textual.
- La aplicación combina la solicitud original con los datos sin procesar que se obtienen en función de la inserción coincidente para crear una petición contextualizada.
La aplicación envía la petición contextualizada a una pila de inferencia de LLM que se ejecuta en Vertex AI.
La pila de inferencia de LLM usa un LLM de IA generativa, que puede ser un LLM base o un LLM personalizado, y genera una respuesta que se limita al contexto proporcionado.
- La aplicación puede almacenar registros de la actividad de solicitud y respuesta en Cloud Logging. Puede ver y usar los registros para la monitorización con Cloud Monitoring. Google no accede a los datos de registro ni los usa.
- La aplicación carga las respuestas en BigQuery para realizar análisis sin conexión.
La aplicación analiza las respuestas mediante filtros de IA responsable.
La aplicación envía las respuestas filtradas a los usuarios a través del frontend.
Subsistema de evaluación de la calidad
En el siguiente diagrama se muestran los detalles del subsistema de evaluación de la calidad de la arquitectura:
Cuando el subsistema de evaluación de la calidad recibe una solicitud, hace lo siguiente:
- Pub/Sub activa un trabajo de Cloud Run.
- Cloud Run inicia el trabajo usando los datos de configuración almacenados en una base de datos de AlloyDB para PostgreSQL.
- El trabajo de Cloud Run extrae las peticiones de evaluación de una base de datos de AlloyDB para PostgreSQL. Las peticiones se subían anteriormente a la base de datos mediante el subsistema de ingestión de datos.
El trabajo de Cloud Run usa las peticiones de evaluación para valorar la calidad de las respuestas que genera el subsistema de servicio.
El resultado de esta evaluación consiste en puntuaciones de evaluación de métricas, como la precisión de los datos y la relevancia.
Cloud Run carga las puntuaciones de evaluación, las peticiones y las respuestas evaluadas en BigQuery para analizarlas más adelante.
Productos usados
A continuación, se muestra un resumen de todos los Google Cloud productos que utiliza la arquitectura anterior:
- Vertex AI: una plataforma de aprendizaje automático que te permite entrenar y desplegar modelos de aprendizaje automático y aplicaciones de IA, así como personalizar LLMs para usarlos con aplicaciones basadas en IA.
- Cloud Run: una plataforma de computación sin servidor que te permite ejecutar contenedores directamente en la infraestructura escalable de Google.
- BigQuery: un almacén de datos empresariales que te ayuda a gestionar y analizar tus datos con funciones integradas como el aprendizaje automático, el análisis geoespacial y la inteligencia empresarial.
- 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.
- AlloyDB para PostgreSQL: servicio de bases de datos totalmente gestionado y compatible con PostgreSQL diseñado para las cargas de trabajo más exigentes, incluido el procesamiento híbrido transaccional y analítico.
- Document AI: una plataforma de procesamiento de documentos que toma datos no estructurados de documentos y los transforma en datos estructurados.
- Pub/Sub: un servicio de mensajería asíncrono y escalable que desacopla los servicios que producen mensajes de los que los procesan.
- Cloud Logging: un sistema de gestión de registros en tiempo real con funciones de almacenamiento, búsqueda, análisis y alertas.
- Cloud Monitoring: un servicio que ofrece visibilidad sobre el rendimiento, la disponibilidad y el estado de tus aplicaciones e infraestructura.
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.
Herramientas y modelos de código abierto
Si quieres crear y desplegar rápidamente aplicaciones de IA generativa compatibles con RAG con las herramientas y los modelos de código abierto Ray, Hugging Face y LangChain, consulta el artículo sobre la infraestructura para una aplicación de IA generativa compatible con RAG que use GKE y Cloud SQL.
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 una arquitectura de IA generativa con capacidad de RAG en Google Cloud 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 de IA generativa y de los Google Cloud productos y funciones que utilices, es posible que tengas que tener en cuenta otros factores de diseño y compensaciones.
Seguridad 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 y cumplimiento.
| Producto | Factores del diseño |
|---|---|
| Vertex AI | Vertex AI admite Google Cloud controles de seguridad que puedes usar para cumplir tus requisitos de residencia de datos, cifrado de datos, seguridad de red y transparencia de acceso. Para obtener más información, consulta Controles de seguridad de Vertex AI y Controles de seguridad de la IA generativa. |
| Cloud Run |
De forma predeterminada, Cloud Run encripta los datos mediante una Google-owned and Google-managed encryption key. Para proteger tus contenedores con una clave que controles, puedes usar claves de cifrado gestionadas por el cliente (CMEK). Para obtener más información, consulta el artículo Usar claves de cifrado gestionadas por el cliente. Para asegurarte de que solo se desplieguen imágenes de contenedor autorizadas en los trabajos de Cloud Run, puedes usar la autorización binaria. Cloud Run te ayuda a cumplir los requisitos de residencia de datos. Las instancias de contenedor de Cloud Run se ejecutan en la región que selecciones. |
| AlloyDB for PostgreSQL |
De forma predeterminada, los datos almacenados en AlloyDB para PostgreSQL se cifran con Google-owned and Google-managed encryption keys. Si necesitas usar claves de cifrado que controles y gestiones, puedes usar CMEKs. Para obtener más información, consulta el artículo Información sobre las claves de cifrado gestionadas por el cliente. Para mitigar el riesgo de filtración de datos de las bases de datos de AlloyDB para PostgreSQL, puedes crear un perímetro de servicio con Controles de Servicio de VPC. De forma predeterminada, una instancia de AlloyDB para PostgreSQL solo acepta conexiones que usen SSL. Para proteger aún más las conexiones a tus bases de datos de AlloyDB para PostgreSQL, puedes usar el conector de proxy de autenticación de AlloyDB para PostgreSQL. El conector Auth Proxy proporciona autorización de conexión basada en gestión de identidades y accesos (IAM) y usa una conexión TLS 1.3 con un cifrado AES de 256 bits para verificar las identidades de cliente y servidor, así como para cifrar el tráfico de datos. Para obtener más información, consulta Información sobre el proxy de autenticación de AlloyDB para PostgreSQL. En el caso de las conexiones creadas con Java, Python o Go, utiliza el conector de lenguaje correspondiente en lugar del conector de proxy de autenticación. AlloyDB para PostgreSQL te ayuda a cumplir los requisitos de residencia de datos. Los datos se almacenan o replican en las regiones que especifiques. |
| BigQuery |
BigQuery ofrece muchas funciones que puedes usar para controlar el acceso a los datos, proteger los datos sensibles y asegurar la precisión y la coherencia de los datos. Para obtener más información, consulta la introducción al gobierno de datos en BigQuery. BigQuery te ayuda a cumplir los requisitos de residencia de datos. Los datos se almacenan en la región que especifiques. |
| 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 conceder acceso a los usuarios a tus segmentos y objetos: gestión de identidades y accesos (IAM) y listas de control de acceso (LCA). 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. Cloud Storage te ayuda a cumplir los requisitos de residencia de datos. Los datos se almacenan o replican en las regiones que especifiques. |
| Pub/Sub |
De forma predeterminada, Pub/Sub cifra todos los mensajes, tanto en reposo como en tránsito, mediante Google-owned and Google-managed encryption keys. Pub/Sub admite el uso de CMEKs para cifrar mensajes en la capa de aplicación. Para obtener más información, consulta Configurar el cifrado de mensajes. Si tienes requisitos de residencia de datos, puedes configurar políticas de almacenamiento de mensajes para asegurarte de que los datos de los mensajes se almacenan en ubicaciones específicas. |
| Document AI | De forma predeterminada, los datos en reposo se cifran con claves de cifrado gestionadas por Google. Si necesitas usar claves de cifrado que controles y gestiones, puedes usar CMEKs. Para obtener más información, consulta el artículo Seguridad y cumplimiento de Document AI. |
| Cloud Logging |
Los registros de auditoría de actividad de administración están habilitados de forma predeterminada en todos los servicios Google Cloud que se usan en esta arquitectura de referencia. Estos registros registran las llamadas a la API u otras acciones que modifican la configuración o los metadatos de los recursos de Google Cloud . Los registros de auditoría de acceso a los datos están habilitados de forma predeterminada en BigQuery. En el caso de los demás servicios que se usan en esta arquitectura, puedes habilitar los registros de auditoría de acceso a datos. Los registros te permiten monitorizar las llamadas a la API que leen la configuración o los metadatos de los recursos, o bien las solicitudes de los usuarios para crear, modificar o leer datos de recursos proporcionados por los usuarios. Para cumplir los requisitos de residencia de datos, puedes configurar Cloud Logging para que almacene los datos de registro en la región que especifiques. Para obtener más información, consulta Regionalizar los registros. |
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 |
|---|---|
| Cloud Run |
Cloud Run es un servicio regional. Los datos se almacenan de forma síncrona en varias zonas de una región. El tráfico se balancea de carga automáticamente entre las zonas. Si se produce una interrupción de la zona, los trabajos de Cloud Run seguirán ejecutándose y no se perderán datos. Si se produce una interrupción en una región, las tareas de Cloud Run dejarán de ejecutarse hasta que Google resuelva la interrupción. Es posible que fallen tareas o trabajos de Cloud Run concretos. Para gestionar estos errores, puedes usar reintentos de tareas y puntos de control. Para obtener más información, consulta las prácticas recomendadas para los reintentos y los puntos de control de los trabajos. |
| AlloyDB for PostgreSQL |
De forma predeterminada, los clústeres de AlloyDB para PostgreSQL ofrecen alta disponibilidad (HA) con conmutación por error automática. La instancia principal tiene nodos redundantes que se encuentran en dos zonas diferentes de una región. Esta redundancia asegura que los clústeres sean resistentes a los fallos de zona. Para planificar la recuperación tras interrupciones en una región, puedes usar la réplica entre regiones. |
| BigQuery |
Los datos que cargas en BigQuery se almacenan de forma síncrona en dos zonas de la región que especifiques. Esta redundancia ayuda a asegurarse de que no se pierdan datos cuando se produzca una interrupción en una zona. Para obtener más información sobre las funciones de fiabilidad de BigQuery, consulta Información sobre la fiabilidad. |
| 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. |
| Pub/Sub |
Para gestionar los picos transitorios en el tráfico de mensajes, puede configurar el control de flujo en los ajustes del editor. Para gestionar las publicaciones fallidas, ajusta las variables de reintento de solicitud según sea necesario. Para obtener más información, consulta la sección Reintentar solicitudes. |
| Document AI |
Document AI es un servicio regional. Los datos se almacenan de forma síncrona en varias zonas de una región. El tráfico se balancea de carga automáticamente entre las zonas. Si se produce una interrupción en una zona, no se pierden datos. Si se produce una interrupción en una región, Document AI no estará disponible hasta que Google resuelva el problema. |
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 |
|---|---|
| Cloud Run |
Cuando creas trabajos de Cloud Run, especificas la cantidad de memoria y CPU que se asignará a la instancia de contenedor. Para controlar los costes, empieza con las asignaciones predeterminadas (mínimas) de CPU y memoria. Para mejorar el rendimiento, puedes aumentar la asignación configurando el límite de CPU y el límite de memoria. Si puedes predecir los requisitos de CPU y memoria de tus trabajos de Cloud Run, puedes ahorrar dinero obteniendo descuentos por uso confirmado. Para obtener más información, consulta la página sobre los descuentos por uso confirmado de Cloud Run. |
| AlloyDB for PostgreSQL |
De forma predeterminada, una instancia principal de un clúster de AlloyDB para PostgreSQL tiene alta disponibilidad. La instancia tiene un nodo activo y un nodo de espera. Si el nodo activo falla, AlloyDB para PostgreSQL se conmutará automáticamente al nodo de reserva. Si no necesitas la alta disponibilidad para las bases de datos, puedes reducir los costes convirtiendo la instancia principal del clúster en una instancia básica. Una instancia básica no es robusta frente a las interrupciones de la zona y tiene un tiempo de inactividad más largo durante las operaciones de mantenimiento. Para obtener más información, consulta Reducir costes con instancias básicas. Si puedes predecir los requisitos de CPU y memoria de tu instancia de AlloyDB para PostgreSQL, puedes ahorrar dinero obteniendo descuentos por uso confirmado. Para obtener más información, consulta Descuentos por compromiso de uso de AlloyDB para PostgreSQL. |
| BigQuery | BigQuery te permite estimar el coste de las consultas antes de ejecutarlas. Para optimizar los costes de las consultas, debe optimizar el almacenamiento y las operaciones de computación de las consultas. Para obtener más información, consulta Estimar y controlar los costes. |
| 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 en función de los requisitos de conservación de datos y frecuencia de acceso de tus cargas de trabajo. Por ejemplo, puedes elegir la clase de almacenamiento Estándar y usar la gestión del ciclo de vida de los objetos para controlar los costes de almacenamiento. Para ello, puedes cambiar 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. |
| Cloud Logging |
Para controlar el coste de almacenar registros, puedes hacer lo siguiente:
|
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.
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 |
|---|---|
| Cloud Run | De forma predeterminada, a cada instancia de contenedor de Cloud Run se le asigna una CPU y 512 MiB de memoria. En función de los requisitos de rendimiento de tus trabajos de Cloud Run, puedes configurar el límite de CPU y el límite de memoria. |
| AlloyDB for PostgreSQL |
Para ayudarte a analizar y mejorar el rendimiento de las consultas de las bases de datos, AlloyDB para PostgreSQL proporciona la herramienta Estadísticas de las consultas. Puede usar esta herramienta para monitorizar el rendimiento y rastrear la fuente de una consulta problemática. Para obtener más información, consulta el artículo Descripción general de Estadísticas de consultas. Para obtener una vista general del estado y el rendimiento de sus bases de datos, así como para ver métricas detalladas, como las conexiones máximas y el desfase de replicación máximo, puede usar el panel de control Estadísticas del sistema. Para obtener más información, consulta el artículo Monitorizar una instancia con el panel de control Estadísticas del sistema de AlloyDB para PostgreSQL. Para reducir la carga de tu instancia principal de AlloyDB para PostgreSQL y ampliar la capacidad para gestionar las solicitudes de lectura, puedes añadir instancias de grupo de lectura al clúster. Para obtener más información, consulta Nodos e instancias de AlloyDB para PostgreSQL. |
| BigQuery |
BigQuery proporciona un gráfico de ejecución de consultas que puedes usar para analizar el rendimiento de las consultas y obtener estadísticas sobre problemas como la contención de ranuras y la cuota de aleatorización insuficiente. Para obtener más información, consulta el artículo Obtener estadísticas sobre el rendimiento de las consultas. Una vez que hayas solucionado los problemas que hayas identificado con las estadísticas de rendimiento de las consultas, puedes optimizar aún más las consultas usando técnicas como la reducción del volumen de datos de entrada y salida. Para obtener más información, consulta Optimizar las operaciones de computación de las consultas. |
| 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. Las subidas compuestas paralelas pueden ser más rápidas que las operaciones de subida normales cuando el ancho de banda de la red y la velocidad del disco no son factores limitantes. 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 empezar a crear infraestructura en Google Cloud para aplicaciones de IA generativa compatibles con RAG y experimentar con ella, puedes usar la solución de inicio rápido: RAG de IA generativa con Cloud SQL. Esta solución implementa una aplicación de chat basada en Python en Cloud Run y usa una base de datos de Cloud SQL totalmente gestionada para la búsqueda de vectores. El código de muestra de esta solución está disponible en GitHub.
que te permite realizar búsquedas vectoriales en una base de datos PostgreSQL.Siguientes pasos
- Consulta cómo crear aplicaciones empresariales de IA generativa con Google Cloud bases de datos.
- Consulta cómo la nueva aplicación de recuperación de bases de datos de IA generativa ayuda a mejorar las respuestas de los LLMs.
- Prueba el codelab para crear una aplicación de chat basada en LLM y RAG con AlloyDB para PostgreSQL AI y LangChain.
- Prueba la resumir documentos con IA generativa.
- Consulta información sobre la generación aumentada de recuperación para tareas de PLN que requieren muchos conocimientos.
- Consulta información sobre la generación aumentada por recuperación para modelos de lenguaje extenso.
- 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:
- Andrew Brook | Director de Ingeniería
- Anna Berenberg | Ingeniera
- Assaf Namer | Arquitecto principal de seguridad en la nube
- Balachandar Krishnamoorthy | Ingeniero de software principal
- Daniel Lees | Arquitecto de seguridad en la nube
- Derek Downey | Ingeniero de relaciones con desarrolladores
- Eran Lewis | Responsable de producto sénior
- Geoffrey Anderson | Responsable de producto
- Gleb Otochkin | Cloud Advocate, Databases
- Hamsa Buvaraghan | Responsable de producto de IA
- Irina Sigler | Responsable de producto
- Jack Wotherspoon | Ingeniero de software
- Jason Davenport | Developer Advocate
- Jordan Totten | Ingeniero de clientes
- Julia Wiesinger | Responsable de producto
- Kara Greenfield | Ingeniera de clientes
- Kurtis Van Gent | Ingeniero de software
- Per Jacobsson | Ingeniero de software
- Pranav Nambiar | Director
- Richard Hendricks | Personal del Architecture Center
- Safiuddin Khaja | Cloud Engineer
- Sandy Ghai | Responsable de grupo de productos
- Vladimir Vuskovic | Director de Gestión de Productos
- Steren Giannini | Responsable de producto
- Wietse Venema | Ingeniero de relaciones con desarrolladores