Construya una base de conocimiento justo a tiempo con el lecho de roca de Amazon

Las empresas de software como servicio (SaaS) que administran múltiples inquilinos enfrentan un desafío crítico: extraer eficientemente ideas significativas de grandes colecciones de documentos mientras controlan los costos. Los enfoques tradicionales a menudo conducen a un gasto innecesario en recursos de almacenamiento y procesamiento no utilizados, afectando tanto la eficiencia operativa como la rentabilidad. Las organizaciones necesitan soluciones que escalen de manera inteligente los recursos de procesamiento y almacenamiento basados ​​en patrones de uso reales de los inquilinos mientras mantienen el aislamiento de datos. Los sistemas de generación aumentada de recuperación tradicional (RAG) consumen recursos valiosos al ingerir y mantener integrados para documentos que nunca podrían ser consultados, lo que resulta en costos de almacenamiento innecesarios y una eficiencia reducida del sistema. Los sistemas diseñados para manejar grandes cantidades de inquilinos pequeños a medianos pueden exceder la estructura de costos y los límites de infraestructura o pueden necesitar usar implementaciones de estilo silo para mantener la información y el uso de cada inquilino separado. Además de esta complejidad, muchos proyectos son de naturaleza transitoria, y el trabajo se completa de manera intermitente, lo que lleva a datos que ocupan espacio en sistemas de base de conocimiento que podrían ser utilizados por otros inquilinos activos.

Para abordar estos desafíos, esta publicación presenta una solución de base de conocimiento justo a tiempo que reduce el consumo no utilizado a través del procesamiento inteligente de documentos. La solución procesa documentos solo cuando es necesario y elimina automáticamente los recursos no utilizados, para que las organizaciones puedan escalar sus repositorios de documentos sin aumentar los costos de infraestructura proporcionalmente.

Con una arquitectura de múltiples inquilinos con límites configurables por inquilino, los proveedores de servicios pueden ofrecer modelos de precios escalonados al tiempo que mantienen un estricto aislamiento de datos, lo que lo hace ideal para aplicaciones SaaS que atienden a múltiples clientes con necesidades variables. La expiración automática del documento a través del tiempo de vida (TTL) asegura que el sistema permanezca delgado y enfocado en el contenido relevante, al tiempo que actualiza el TTL para documentos a acceso frecuentes mantiene un rendimiento óptimo para la información que importa. Esta arquitectura también permite limitar el número de archivos que cada inquilino puede ingerir en un momento específico y la velocidad a la que los inquilinos pueden consultar un conjunto de archivos. Esta solución utiliza tecnologías sin servidor para aliviar la sobrecarga operativa y proporcionar una escala automática, para que los equipos puedan centrarse en la gestión de la infraestructura de la infraestructura en lugar de la lógica comercial. Al organizar los documentos en grupos con filtrado basado en metadatos, el sistema permite una consulta contextual que ofrece resultados más relevantes al tiempo que mantiene límites de seguridad entre los inquilinos. La flexibilidad de la arquitectura respalda la personalización de las configuraciones de los inquilinos, las tasas de consultas y las políticas de retención de documentos, lo que lo hace adaptable a la evolución de los requisitos comerciales sin una importancia significativa.

Descripción general de la solución

Esta arquitectura combina varios servicios de AWS para crear una solución de base de conocimiento múltiple y rentable que procesa documentos a pedido. Los componentes clave incluyen:

• Base de conocimiento basada en vectores – usa Roca madre de Amazon y Amazon OpenSearch Servidor sin ser Para un procesamiento y consulta de documentos eficientes
• Ingestión de documentos a pedido -Implementa el procesamiento justo a tiempo utilizando la roca madre de Amazon COSTUMBRE Tipo de fuente de datos
• Gestión de TTL – Proporciona limpieza automática de documentos no utilizados utilizando el Característica TTL en Amazon Dynamodb
• Aislamiento de múltiples inquilinos – Haga cumplir la separación segura de datos entre usuarios y organizaciones con límites de recursos configurables

La solución permite el control granular a través del filtrado basado en metadatos en el nivel de usuario, inquilino y de archivo. El sistema de seguimiento TTL Dynamodb admite estructuras de precios escalonadas, donde los inquilinos pueden pagar diferentes duraciones de TTL, límites de ingestión de documentos y tasas de consulta.

El siguiente diagrama ilustra los componentes clave y el flujo de trabajo de la solución.

El flujo de trabajo consta de los siguientes pasos:

1. El usuario inicia sesión en el sistema, que adjunta una ID de inquilino al usuario actual para las llamadas a la base de conocimiento de Amazon Bedrock. Este paso de autenticación es crucial porque establece el contexto de seguridad y se asegura de que las interacciones posteriores se asocien correctamente con el inquilino correcto. La ID del inquilino se convierte en la pieza fundamental de metadatos que permite la gestión adecuada de aislamiento y recursos de múltiples inquilinos durante todo el flujo de trabajo.
2. Después de la autenticación, el usuario crea un proyecto que servirá como contenedor para los archivos que desea consultar. Este paso de creación del proyecto establece la estructura organizativa necesaria para administrar documentos relacionados juntos. El sistema genera metadatos apropiados y crea las entradas de base de datos necesarias para rastrear la asociación del proyecto con el inquilino específico, lo que permite el control de acceso adecuado y la gestión de recursos a nivel del proyecto.
3. Con un proyecto establecido, el usuario puede comenzar a cargar archivos. El sistema gestiona este proceso generando URL previas firmadas para la carga de archivos seguros. A medida que se cargan los archivos, se almacenan en Servicio de almacenamiento simple de Amazon (Amazon S3), y el sistema crea automáticamente entradas en DynamoDB que asocian cada archivo con el proyecto y el inquilino. Esta relación de tres vías (File-Project-en-en-inquilino) es esencial para mantener un aislamiento de datos adecuado y permitir una consulta eficiente más adelante.
4. Cuando un usuario solicita crear un chat con una base de conocimiento para un proyecto específico, el sistema comienza a ingerir los archivos del proyecto utilizando la fuente de datos personalizada. Aquí es donde comienza el procesamiento justo a tiempo. Durante la ingestión, el sistema aplica un valor TTL basado en el intervalo TTL específico del nivel del inquilino. El TTL asegura que los archivos del proyecto permanezcan disponibles durante la sesión de chat mientras se configuran el marco para la limpieza automática más adelante. Este paso representa el núcleo de la estrategia de procesamiento a pedido, porque los archivos solo se procesan cuando son necesarios.
5. Cada sesión de chat actualiza activamente el TTL para los archivos del proyecto que se utilizan. Esta gestión dinámica de TTL asegura que los archivos a los que se accede con frecuencia permanezca en la base de conocimiento, al tiempo que permite que los archivos raramente usados ​​caducen naturalmente. El sistema actualiza continuamente los valores TTL en función del uso real, creando un equilibrio eficiente entre la disponibilidad de recursos y la optimización de costos. Este enfoque mantiene un rendimiento óptimo para el contenido utilizado activamente, al tiempo que ayuda a prevenir los desechos de recursos en documentos no utilizados.
6. Después de que finaliza la sesión de chat y el valor TTL expira, el sistema elimina automáticamente archivos de la base de conocimiento. Este proceso de limpieza se activa por Amazon Dynamodb Streams Monitoreo de eventos de vencimiento de TTL, que activan un AWS Lambda función para eliminar los documentos caducados. Este paso final reduce la carga en el clúster sin servidor de OpenSearch subyacente y optimiza los recursos del sistema, asegurándose de que la base de conocimiento permanezca delgada y eficiente.

Requisitos previos

Necesita los siguientes requisitos previos antes de poder continuar con la solución. Para esta publicación, usamos el us-east-1 Región de AWS.

Implementar la solución

Complete los siguientes pasos para implementar la solución:

1. Descargue el proyecto AWS CDK del Repositorio de Github.
2. Instale las dependencias del proyecto:
3. Implementar la solución:
4. Cree un usuario e inicie sesión en el sistema después de validar su correo electrónico.

Validar la base de conocimiento y ejecutar una consulta

Antes de permitir a los usuarios chatear con sus documentos, el sistema realiza los siguientes pasos:

• Realiza una verificación de validación para determinar si los documentos deben ingerirse. Este proceso ocurre transparentemente al usuario e incluye verificar el estado del documento en DynamodB y la base de conocimiento.
• Valida que los documentos requeridos se ingieren con éxito y se indexan correctamente antes de permitir consultas.
• Devuelve las respuestas generadas por IA y las citas relevantes a los documentos de origen, manteniendo la trazabilidad y capacitando a los usuarios para verificar la precisión de las respuestas.

La siguiente captura de pantalla ilustra un ejemplo de chat con los documentos.

Mirando el siguiente método de ejemplo para la ingestión de archivos, tenga en cuenta cómo la información del archivo se almacena en DynamoDB con un valor TTL para la expiración automática. La llamada de los documentos de la base de conocimiento Ingest incluye metadatos esenciales (ID de usuario, ID de inquilino y proyecto), lo que permite un filtrado preciso de los archivos de este inquilino en operaciones posteriores.

# Ingesting files with tenant-specific TTL values
def ingest_files(user_id, tenant_id, project_id, files):
    # Get tenant configuration and calculate TTL
    tenants = json.loads(os.environ.get('TENANTS'))['Tenants']
    tenant = find_tenant(tenant_id, tenants)
    ttl = int(time.time()) + (int(tenant['FilesTTLHours']) * 3600)
    
    # For each file, create a record with TTL and start ingestion
    for file in files:
        file_id = file['id']
        s3_key = file.get('s3Key')
        bucket = file.get('bucket')
        
        # Create a record in the knowledge base files table with TTL
        knowledge_base_files_table.put_item(
            Item={
                'id': file_id,
                'userId': user_id,
                'tenantId': tenant_id,
                'projectId': project_id,
                'documentStatus': 'ready',
                'createdAt': int(time.time()),
                'ttl': ttl  # TTL value for automatic expiration
            }
        )
        
        # Start the ingestion job with tenant, user, and project metadata for filtering
        bedrock_agent.ingest_knowledge_base_documents(
            knowledgeBaseId=KNOWLEDGE_BASE_ID,
            dataSourceId=DATA_SOURCE_ID,
            clientToken=str(uuid.uuid4()),
            documents=[
                {
                    'content': {
                        'dataSourceType': 'CUSTOM',
                        'custom': {
                            'customDocumentIdentifier': {
                                'id': file_id
                            },
                            's3Location': {
                                'uri': f"s3://{bucket}/{s3_key}"
                            },
                            'sourceType': 'S3_LOCATION'
                        }
                    },
                    'metadata': {
                        'type': 'IN_LINE_ATTRIBUTE',
                        'inlineAttributes': [
                            {'key': 'userId', 'value': {'stringValue': user_id, 'type': 'STRING'}},
                            {'key': 'tenantId', 'value': {'stringValue': tenant_id, 'type': 'STRING'}},
                            {'key': 'projectId', 'value': {'stringValue': project_id, 'type': 'STRING'}},
                            {'key': 'fileId', 'value': {'stringValue': file_id, 'type': 'STRING'}}
                        ]
                    }
                }
            ]
        )

Durante una consulta, puede usar los metadatos asociados para construir parámetros que se aseguren de recuperar los archivos que pertenecen a este inquilino específico. Por ejemplo:

    filter_expression = {
        "andAll": [
            {
                "equals": {
                    "key": "tenantId",
                    "value": tenant_id
                }
            },
            {
                "equals": {
                    "key": "projectId",
                    "value": project_id
                }
            },
            {
                "in": {
                    "key": "fileId",
                    "value": file_ids
                }
            }
        ]
    }

    # Create base parameters for the API call
    retrieve_params = {
        'input': {
            'text': query
        },
        'retrieveAndGenerateConfiguration': {
            'type': 'KNOWLEDGE_BASE',
            'knowledgeBaseConfiguration': {
                'knowledgeBaseId': knowledge_base_id,
                'modelArn': 'arn:aws:bedrock:us-east-1::foundation-model/amazon.nova-pro-v1:0',
                'retrievalConfiguration': {
                    'vectorSearchConfiguration': {
                        'numberOfResults': limit,
                        'filter': filter_expression
                    }
                }
            }
        }
    }
    response = bedrock_agent_runtime.retrieve_and_generate(**retrieve_params)

Administre el ciclo de vida del documento con TTL

Para optimizar aún más el uso y los costos de los recursos, puede implementar un sistema de gestión de ciclo de vida de documentos inteligente utilizando la función Dynamodb (TTL). Esto consiste en los siguientes pasos:

1. Cuando se ingiere un documento en la base de conocimiento, se crea un registro con un valor TTL configurable.
2. Este TTL se actualiza cuando se accede al documento.
3. Las transmisiones de DynamodB con filtros específicos para eventos de vencimiento de TTL se usan para activar una función Lambda de limpieza.
4. La función Lambda elimina los documentos caducados de la base de conocimiento.

Vea el siguiente código:

# Lambda function triggered by DynamoDB Streams when TTL expires items
def lambda_handler(event, context):
    """
    This function is triggered by DynamoDB Streams when TTL expires items.
    It removes expired documents from the knowledge base.
    """
    
    # Process each record in the event
    for record in event.get('Records', []):
        # Check if this is a TTL expiration event (REMOVE event from DynamoDB Stream)
        if record.get('eventName') == 'REMOVE':
            # Check if this is a TTL expiration
            user_identity = record.get('userIdentity', {})
            if user_identity.get('type') == 'Service' and user_identity.get('principalId') == 'dynamodb.amazonaws.com':
                # Extract the file ID and tenant ID from the record
                keys = record.get('dynamodb', {}).get('Keys', {})
                file_id = keys.get('id', {}).get('S')
                
                # Delete the document from the knowledge base
                bedrock_agent.delete_knowledge_base_documents(
                    clientToken=str(uuid.uuid4()),
                    knowledgeBaseId=knowledge_base_id,
                    dataSourceId=data_source_id,
                    documentIdentifiers=[
                        {
                            'custom': {
                                'id': file_id
                            },
                            'dataSourceType': 'CUSTOM'
                        }
                    ]
                )

Aislamiento de múltiples inquilinos con niveles de servicio escalonados

Nuestra arquitectura permite un sofisticado aislamiento de múltiples inquilinos con niveles de servicio escalonados:

• Filtrado de documentos específicos del inquilino -Cada consulta incluye filtros de usuario, inquilino y específicos de archivos, lo que permite que el sistema reduzca el número de documentos que se consultan.
• Valores de TTL configurables – Los diferentes niveles de inquilinos pueden tener diferentes configuraciones TTL. Por ejemplo:
  • Nivel libre: cinco documentos ingeridos con un TTL de 7 días y cinco consultas por minuto.
  • Nivel estándar: 100 documentos ingeridos con un TTL de 30 días y 10 consultas por minuto.
  • Nivel premium: 1,000 documentos ingeridos con un TTL de 90 días y 50 consultas por minuto.
  • Puede configurar límites adicionales, como consultas totales por mes o archivos ingeridos totales por día o mes.

Limpiar

Para limpiar los recursos creados en esta publicación, ejecute el siguiente comando desde la misma ubicación donde realizó el paso de implementación:

Conclusión

La arquitectura de la base de conocimiento justo a tiempo presentada en esta publicación transforma la gestión de documentos en múltiples inquilinos mediante el procesamiento de documentos solo cuando se consulta, reduciendo el consumo no utilizado de los sistemas tradicionales de RAG. Esta implementación sin servidor utiliza Amazon Bedrock, OpenSearch Servidor sin servidor y la función DynamodB TTL para crear un sistema Lean con gestión inteligente del ciclo de vida de documentos, límites configurables de inquilinos y un estricto aislamiento de datos, que es esencial para los proveedores de SaaS que ofrecen modelos de precios nivelados.

Esta solución aborda directamente la estructura de costos y las limitaciones de infraestructura de los sistemas tradicionales, particularmente para implementaciones que manejan numerosos inquilinos pequeños a medianos con proyectos transitorios. Esta arquitectura combina el procesamiento de documentos a pedido con la gestión automatizada del ciclo de vida, ofreciendo un recurso rentable y escalable que faculta a las organizaciones a centrarse en extraer ideas en lugar de administrar la infraestructura, al tiempo que mantiene los límites de seguridad entre los inquilinos.

¿Listo para implementar esta arquitectura? El código de muestra completo está disponible en el Repositorio de Github.

Sobre el autor

Steven Warwick es un arquitecto de soluciones senior en AWS, donde lidera los compromisos de los clientes para impulsar la adopción exitosa de la nube y se especializa en arquitecturas SaaS y soluciones generativas de IA. Produce contenido educativo que incluye publicaciones de blog y código de muestra para ayudar a los clientes a implementar las mejores prácticas, y ha dirigido programas sobre temas de Genai para arquitectos de soluciones. Steven aporta décadas de experiencia tecnológica a su papel, ayudando a los clientes con revisiones arquitectónicas, optimización de costos y desarrollo de prueba de concepto.