Muchas empresas cuentan con grandes volúmenes de documentos en papel o electrónicos que contienen inteligencia empresarial sin explotar. Con el avance de la IA generativa, se pueden utilizar varios modelos de lenguaje grandes para extraer con precisión datos relevantes de estos documentos. Esta publicación demuestra un proceso de procesamiento de documentos inteligente que consta de opciones de inferencia bajo demanda e inferencia por lotes en Amazon Bedrock para permitir la flexibilidad en el tiempo y el costo del procesamiento de documentos. Para solicitudes urgentes, se puede utilizar la opción de inferencia bajo demanda, mientras que la opción de inferencia por lotes es la que optimiza más los costos. También explica cómo especificar dinámicamente el modelo de lenguaje grande y las indicaciones a nivel de documento, lo que le permite extraer datos de múltiples tipos de documentos utilizando las mismas canalizaciones.
Descripción general de la solución
Si usted, como uno de nuestros clientes, tiene cientos de millones de documentos de arrendamiento de terrenos en formato PDF escaneado (PDF que contiene solo imágenes sin texto editable, por ejemplo, en este caso, arrendamiento de terrenos escaneado guardado como PDF) en el trabajo pendiente, y cada día se siguen acumulando nuevos documentos, esta es una solución que puede utilizar para extraer datos de manera efectiva de estos documentos. Como se muestra en el siguiente diagrama, esta solución crea dos canales de inferencia, bajo demanda y por lotes, con un mecanismo para invocarlos dinámicamente. Al utilizar indicaciones diseñadas eficazmente y administradas en Amazon Bedrock Prompt Management, los datos se pueden extraer y estandarizar de archivos PDF escaneados, que a menudo tienen diferentes formatos y convenciones, o de archivos de texto.
El canal de la izquierda es el canal bajo demanda que extrae datos de los documentos uno por uno y arroja resultados en segundos. Esto lo hace adecuado para solicitudes urgentes.
La canalización de la derecha es la canalización de inferencia por lotes que procesa varias solicitudes de documentos en un único trabajo de inferencia por lotes de Amazon Bedrock, donde la invocación de su modelo se procesará de forma asincrónica. Los usuarios pueden especificar el ID y la versión del mensaje en la solicitud en ambas canalizaciones, y el texto del mensaje correspondiente se recuperará de Amazon Bedrock Prompt Management.
Las siguientes secciones proporcionan descripciones detalladas de ambas tuberías.
1. Canal de inferencia bajo demanda
Se crea una cola AWS SQS First-In, First-Out (FIFO) en la canalización de inferencia bajo demanda. Cuando llega un mensaje de cola que contiene el ID del documento, el ID del modelo LLM, el ID/versión del mensaje y el ID/versión del mensaje del sistema, se activa una función AWS Lambda. Esta función recupera el documento PDF del depósito de Amazon S3 especificado, convierte las páginas PDF en imágenes PNG, recupera las indicaciones relevantes de Amazon Bedrock Prompt Management, redacta el mensaje para llamar al LLM y guarda el resultado en una tabla de Amazon DynamoDB.
1.1. Cola AWS SQS FIFO
Se utiliza una cola AWS SQS FIFO para activar la inferencia de Amazon Bedrock cuando llega un solo documento. Las razones clave para utilizar una cola FIFO son:
Entrega confiable de mensajes: garantiza que cada mensaje se entregue exactamente una vez. Procesamiento primero en entrar, primero en salir (FIFO): mantiene un orden estricto, lo que proporciona una mejor previsibilidad para el procesamiento. Agrupación de mensajes: el atributo ID de grupo de mensajes garantiza que los mensajes se procesen en orden dentro de cada grupo. Cada productor puede utilizar un ID de grupo de mensajes único para mantener el orden de los mensajes relacionados.
¿Cómo se crea un mensaje en cola?
Los mensajes de la cola se pueden crear externamente con AWS CLI o AWS SDK API. El siguiente es un ejemplo de comando de AWS CLI:
El archivo message_txt.txt en este ejemplo es un archivo JSON que contiene los atributos de mensaje necesarios para la aplicación. Consulte los detalles en la sección Prueba de las tuberías a continuación.
La función Lambda eliminará el mensaje de la cola después de que Amazon Bedrock haya devuelto los datos extraídos.
1.2. Función Lambda: procesamiento e inferencia de mensajes en cola
1.2.1 Recuperar documentos, convertirlos a imágenes y dividir archivos grandes
La función Lambda descarga el documento utilizando el atributo s3_location en el mensaje de la cola. Si el documento es un PDF escaneado, luego se convierte en imágenes para que el modelo multimodal las comprenda.
Al momento de escribir este artículo, el modelo Claude 4 Sonnet solo permite un máximo de 20 imágenes por invocación multimodal. Por lo tanto, si un documento contiene más de 20 páginas de imágenes, debe dividirse en partes de 20 páginas. doc_id, chunk_count y chunk_id se almacenan en una tabla de Amazon DynamoDB, junto con los resultados extraídos y las métricas de rendimiento del modelo.
doc_id: el identificador del documento chunk_count: el número total de fragmentos para ese documento chunk_id: el identificador de cada fragmento del documento
1.2.2. Recuperación de indicaciones de Amazon Bedrock Prompt Management
Los documentos de arrendamiento de terrenos varían en formato: algunos presentan atributos de terrenos en listas numeradas, otros en tablas y algunos incluso en dibujos de terrenos. Por lo tanto, el uso de diferentes indicaciones adaptadas a cada formato de documento mejora la precisión de la extracción.
Las indicaciones utilizadas en la llamada LLM se almacenan en Amazon Bedrock Prompt Management. Cada mensaje tiene una identificación única y está versionado. Los mensajes SQS deben especificar el ID y la versión del mensaje relevante, que luego se utilizan para recuperar el cuerpo del mensaje durante la ejecución de Lambda.
Nota: Hay un límite de servicio de 50 mensajes por región y 10 versiones por mensaje.
1.2.3 Redacción de mensajes para llamadas LLM y procesamiento de la respuesta
La función Lambda continúa con los siguientes pasos:
Redacte los mensajes para LLM concatenando el cuerpo del mensaje y las imágenes. Envíe solicitudes a Amazon Bedrock mediante la API de Converse.
El LLM devolverá los datos del extracto en una cadena JSON; puede examinar el resultado en su tabla de DynamoDB como se ilustra en la siguiente sección de prueba de canalizaciones.
1.2.4 Guardar los resultados
Finalmente, la función Lambda completa el proceso:
Analizar el JSON y almacenar los atributos del terreno en la tabla de DynamoDB. Si el documento se procesó exitosamente y se almacenan los resultados, el mensaje SQS se elimina de la cola.
2. Canalización de inferencia por lotes
Se utiliza una cola AWS SQS estándar para la canalización de inferencia por lotes debido a su alto rendimiento. Los mensajes de la cola se crean de manera similar a la canalización bajo demanda, excepto que el atributo message-group-id no es necesario.
Los componentes principales del proceso de inferencia por lotes incluyen:
Programador de Amazon EventBridge. Inferencia por lotes Función AWS Lambda para preprocesar los archivos PDF escaneados, crear archivos JSONL y enviar el trabajo de inferencia por lotes. Regla de Amazon EventBridge. Función AWS Lambda de posprocesamiento.
Las siguientes secciones describen los detalles del proceso de inferencia por lotes.
2.1. Programador de Amazon EventBridge
Un programador de Amazon EventBridge inicia la función Lambda de inferencia por lotes según una programación.
2.2. Función Lambda de inferencia por lotes
La función primero verifica si hay suficientes mensajes en la cola antes de continuar. Al momento de escribir este artículo, existe una cantidad mínima de registros de 100 para el trabajo de inferencia por lotes de Amazon Bedrock.
2.2.1 Recibir mensajes en cola
La función Lambda recorre los mensajes en la cola y extrae el ID del documento, el ID del modelo LLM, el ID/versión del mensaje y el ID/versión del mensaje del sistema.
2.2.2 Recuperar documentos sin duplicados, convertirlos a imágenes y dividir archivos grandes
Luego, la función Lambda recupera los documentos, los convierte en imágenes si son PDF escaneados y divide los archivos grandes si es necesario, tal como en el proceso bajo demanda. Debido a que las colas SQS estándar no garantizan la entrega de mensajes exactamente una vez, la función también garantiza que se ignoren los mensajes duplicados.
2.2.3 Permitir diferentes indicaciones en un trabajo de inferencia por lotes
De manera similar al proceso bajo demanda, los diferentes formatos de documentos requieren diferentes indicaciones para el usuario para una extracción de datos más efectiva.
El ID del mensaje deseado y la versión de cada documento se especifican en los mensajes SQS. Durante la ejecución de Lambda, la función recupera el cuerpo del mensaje de Amazon Bedrock Prompt Management.
2.2.4 Creación de artefactos JSONL para trabajos de inferencia por lotes
Luego, la función Lambda maneja las siguientes tareas:
Crear un metadata.json en el depósito S3 de Batch Inference Data para almacenar los atributos del mensaje, incluido el ID del mensaje SQS, doc_id, ID/versión del mensaje, ID/versión del mensaje del sistema y otros atributos relacionados con el proyecto. Posteriormente, Lambda de posprocesamiento utiliza este archivo para completar la tabla de DynamoDB. Procesar los documentos para crear los archivos JSONL necesarios para el trabajo de inferencia por lotes de Amazon Bedrock. Este proceso se paraleliza utilizando el módulo de multiprocesamiento de Python para mayor eficiencia. Los archivos JSONL se cargan en el depósito Batch Inference Data S3. Eliminar los mensajes SQS después de que los documentos se hayan preparado y cargado en el depósito S3. Esto requiere establecer un tiempo de espera de visibilidad grande para la cola.
2.2.5 Redactar mensajes y enviar trabajos de inferencia por lotes
Finalmente, la función Lambda de inferencia por lotes crea el trabajo de inferencia por lotes de Amazon Bedrock utilizando los artefactos JSONL del paso anterior. Tenga en cuenta que cada trabajo por lotes solo puede procesar documentos utilizando un modelo, lo que significa que los mensajes SQS dentro del mismo trabajo por lotes deben especificar el mismo ID de modelo. Si hay más de un ID de modelo especificado en los mensajes entrantes, la función Lambda utiliza un mecanismo de sondeo que selecciona el ID de modelo especificado con más frecuencia para usar.
2.3. El trabajo de inferencia por lotes de Amazon Bedrock
Cuando Amazon Bedrock recibe el trabajo de inferencia por lotes, lo coloca en una cola. Una vez que comienza el trabajo, se procede con los siguientes pasos.
2.3.1 Recuperar artefactos JSONL para un trabajo de inferencia por lotes
Amazon Bedrock recupera los artefactos JSONL especificados durante la creación del trabajo.
2.3.2 Almacenamiento de resultados de inferencia por lotes
Al finalizar, Amazon Bedrock almacena los resultados en el depósito Batch Inference Data S3, que también se especifica en la creación del trabajo.
2.3.3 Notificación de Amazon EventBridge
Una vez finalizado el trabajo, Amazon Bedrock envía un evento de cambio de estado del trabajo a Amazon EventBridge, que es capturado por una regla de EventBridge.
2.4. La regla de Amazon EventBridge activa la función Lambda posterior a la inferencia
La regla EventBridge activa la función Lambda de posprocesamiento para manejar el procesamiento adicional de la salida del modelo.
2.5. Función Lambda de posprocesamiento
2.5.1 Recuperar el JSONL de salida
La función Lambda obtiene la salida de inferencia JSONL del depósito S3 de datos de inferencia por lotes.
2.5.2 Guardar la salida de inferencia
La función analiza los archivos JSONL y guarda los atributos del terreno extraídos en una tabla de DynamoDB.
Requisitos previos
Si desea probar este ejemplo usted mismo, asegúrese de cumplir estos requisitos previos:
Una cuenta de AWS con acceso a la Consola de administración de AWS Permisos de IAM adecuados para crear y administrar pilas de CloudFormation, que normalmente incluyen: cloudformation:CreateStack cloudformation:DescribeStacks cloudformation:UpdateStack cloudformation:DeleteStack
Implementación de las pilas de CloudFormation
Implemente la canalización bajo demanda:
Cuando elija el enlace Iniciar pila, se le dirigirá a AWS CloudFormation para iniciar la pila de CloudFormation:
En la página Crear pila, elija Siguiente. En la página Especificar detalles de la pila, elija Siguiente. En la página Configurar opciones de pila, elija Siguiente. En la página Revisar y crear, seleccione Reconozco que AWS CloudFormation podría crear recursos de IAM. Elija Enviar.
Una vez enviado, puede observar algunos detalles sobre la pila, como información de la pila, eventos, recursos y más. La siguiente captura de pantalla son los eventos para su referencia:
También puede implementar la canalización por lotes siguiendo los mismos pasos.
Probando las tuberías
Los siguientes pasos le guiarán para probar la canalización bajo demanda. La canalización por lotes también se puede probar en pasos similares si tiene al menos 100 documentos.
Descargue los datos a su entorno local. Hay tres documentos de tierras del condado de Winkler, el condado de Andrews y el condado de Sutton que se compran en el sitio web de Texas Land Records y County Records. Cargue los archivos PDF descargados en el depósito de artefactos S3 ondemand-data-pipeline-bucket-${account_id} que se crea en la pila de CloudFormation. Cree un archivo de texto message_txt.json usando el siguiente ejemplo reemplazando el ID del mensaje, el ID del mensaje del sistema y el depósito S3 que se crean a partir de su pila de CloudFormation.
Cree un script de shell send2queue.sh utilizando el ejemplo de AWS CLI anterior reemplazando el nombre de la cola y ejecútelo. Verá un mensaje en su cola SQS ondemand-data-pipeline-queue.fifo. El mensaje de la cola activará la función Lambda ondemand-data-pipeline-queue-processor. Examine el registro Lambda en Amazon CloudWatch, el grupo de registros es /aws/lambda/ondemand-data-pipeline-queue-processor. Examine el resultado de inferencia de Amazon Bedrock en la tabla ondemand-data-pipeline-table de DynamoDB. El resultado JSON en la columna model_response para el ejemplo del condado de Winkler debería verse similar al siguiente:
Limpieza
Para limpiar los recursos:
Inicie sesión en la Consola de administración de AWS Navegue hasta el servicio CloudFormation En el panel de CloudFormation, busque y seleccione la pila que desea eliminar Elija el botón "Eliminar" en la parte superior de la página Confirme la eliminación cuando se le solicite
CloudFormation eliminará automáticamente los recursos que se crearon como parte de la pila en el orden correcto, manejando las dependencias de manera adecuada.
La eliminación de las pilas de CloudFormation no elimina los depósitos de S3 y DynamoDB porque su política de eliminación está configurada para conservar para ayudar a evitar la pérdida de datos. Para eliminar estos recursos, vaya a la página de cada servicio en la Consola de administración de AWS y elimínelos.
Conclusión
Los canales de inferencia de Amazon Bedrock por lotes y bajo demanda presentados en esta publicación explican cómo se pueden procesar documentos dinámicamente en función de la sensibilidad temporal y el volumen de datos. También debe considerar los factores de costos al decidir qué tubería utilizar. Con la canalización por lotes, como se encontró en nuestras pruebas, el costo de Amazon Bedrock es un 50% menor en comparación con la canalización bajo demanda.
Otra característica clave de esta solución es la capacidad de especificar el modelo de lenguaje grande (para canales bajo demanda) y solicitar mensajes a nivel de documento individual, lo que permite que estos canales admitan varios tipos de procesamiento inteligente de documentos.
Con el paralelismo habilitado mediante el módulo de multiprocesamiento de Python, ambas funciones Lambda del canal de inferencia por lotes pueden procesar 1000 documentos en 15 minutos.
Llamado a la acción
Amazon Bedrock puede permitirle crear muchas aplicaciones de IA generativa. Recomendamos seguir el inicio rápido en el siguiente repositorio de GitHub y familiarizarse con la creación de aplicaciones de IA generativa. Para los lectores avanzados, pueden investigar cómo ampliar aún más la solución. Una idea es ejecutar el código Lambda en AWS Batch, lo que permitirá procesar decenas de miles de documentos en un solo trabajo de inferencia por lotes de Amazon Bedrock.
Sobre los autores
Tim Shear
Tim Shear es arquitecto senior de aplicaciones en la nube y consultor de IA generativa en Amazon Web Services (AWS). Le gusta ayudar a los clientes a navegar por el panorama de la nube en AWS y aplicar GenAI a diversos casos de uso. Fuera del trabajo, le encanta viajar, leer y aprender cosas nuevas.
Cecilia Li
Cecilia es científica de datos en AWS Professional Services y se especializa en la creación de soluciones escalables de IA/ML en AWS. Le apasiona permitir que los clientes desarrollen y optimicen sus cargas de trabajo de IA/ML utilizando tecnologías en la nube.
Said Benallal
Said es un ingeniero profesional certificado en DevOps apasionado por la automatización de la infraestructura en la nube y la implementación de CI/CD, las metodologías GitOps, la arquitectura basada en eventos y el aprovechamiento de los servicios de AWS como CodePipeline, CloudFormation y Lambda para crear soluciones de implementación sin intervención.