Реализуйте индекс умного поиска документов с помощью Amazon Textract и Amazon OpenSearch.

Реализуйте индекс умного поиска документов с Amazon Textract и OpenSearch.

Для современных компаний, которые имеют дело с огромными объемами документов, такими как контракты, счета, резюме и отчеты, эффективная обработка и извлечение соответствующих данных критично для поддержания конкурентного преимущества. Однако традиционные методы хранения и поиска документов могут занимать много времени и часто требуют значительных усилий для поиска конкретного документа, особенно если в них присутствует почерк. Что если бы был способ обрабатывать документы интеллектуально и делать их искабельными с высокой точностью?

Это становится возможным благодаря Amazon Textract, сервису интеллектуальной обработки документов AWS, в сочетании с быстрыми возможностями поиска OpenSearch. В этой статье мы познакомим вас с быстрым созданием и развертыванием решения по индексации поиска документов, которое поможет вашей организации лучше использовать и извлекать информацию из документов.

Независимо от того, работаете ли вы в отделе кадров и ищете конкретные условия в трудовых договорах, или финансовый аналитик просматривает гору счетов для извлечения данных о платежах, это решение разработано так, чтобы вы имели возможность получать доступ к необходимой информации с беспрецедентной скоростью и точностью.

С предложенным решением ваши документы автоматически загружаются, их содержимое обрабатывается и затем индексируется в высокоотзывном и масштабируемом индексе OpenSearch.

Мы расскажем о том, как технологии, такие как Amazon Textract, AWS Lambda, Amazon Simple Storage Service (Amazon S3) и Amazon OpenSearch Service, могут быть интегрированы в рабочий процесс, который без проблем обрабатывает документы. Затем мы рассмотрим индексацию этих данных в OpenSearch и продемонстрируем возможности поиска, доступные на вашем расстоянии вытянутой руки.

Будь ваша организация только начинает свой путь в эпоху цифровой трансформации или является установленным гигантом, стремящимся ускорить поиск информации, этот руководство будет вашим компасом для навигации по возможностям, которые предлагают AWS Intelligent Document Processing и OpenSearch.

В реализации, использованной в этой статье, используются конструкции Amazon Textract IDP CDK – компоненты AWS Cloud Development Kit (CDK) для определения инфраструктуры рабочих процессов Intelligent Document Processing (IDP) – которые позволяют вам создавать настраиваемые рабочие процессы IDP для конкретных случаев использования. Конструкции и образцы IDP CDK – это набор компонентов, позволяющих определить процессы IDP на AWS и опубликованные на GitHub. Основные используемые концепции – это конструкции AWS Cloud Development Kit (CDK), фактические стеки CDK и AWS Step Functions. Рабочий процесс “Используйте машинное обучение для автоматизации и обработки документов в масштабе” является хорошей отправной точкой для изучения возможностей настройки рабочих процессов и использования других образцовых рабочих процессов в качестве основы для своих собственных.

Обзор решения

В этом решении мы сосредоточимся на индексации документов в индекс OpenSearch для быстрого поиска и извлечения информации и документов. Документы в формате PDF, TIFF, JPEG или PNG помещаются в хранилище Amazon Simple Storage Service (Amazon S3) и затем индексируются в OpenSearch с использованием этого рабочего процесса Step Functions.

Рисунок 1: Рабочий процесс OpenSearch Step Functions

Решение OpenSearchWorkflow-Decider проверяет документ и подтверждает, что документ является одним из поддерживаемых типов MIME (PDF, TIFF, PNG или JPEG). Он состоит из одной функции AWS Lambda.

Разделитель документов DocumentSplitter генерирует максимум 2500-страничный фрагмент из документов. Это означает, что даже если Amazon Textract поддерживает документы до 3000 страниц, вы можете передавать документы с гораздо большим количеством страниц, и процесс все равно будет работать нормально, помещая страницы в OpenSearch и создавая правильные номера страниц. Разделитель документов реализован в виде функции AWS Lambda.

Состояние Map State обрабатывает каждый фрагмент параллельно.

Задача TextractAsync вызывает Amazon Textract с использованием асинхронного интерфейса программирования (API), следуя bewst практикам с использованием уведомлений Amazon Simple Notification Service (Amazon SNS) и OutputConfig для сохранения вывода Amazon Textract в формате JSON в пользовательском хранилище Amazon S3. Она состоит из двух функций Amazon Lambda: одна для отправки документа на обработку и одна, которая запускается по уведомлению Amazon SNS.

Поскольку задача TextractAsync может создавать несколько пагинированных выходных файлов, процесс TextractAsyncToJSON2 объединяет их в один файл JSON.

Контекст Step Functions пополняется информацией, которая также должна быть доступна для поиска в индексе OpenSearch на этапе SetMetaData. В примере реализации добавляются ORIGIN_FILE_NAME, START_PAGE_NUMBER и ORIGIN_FILE_URI. Вы можете добавлять любую информацию для расширения возможностей поиска, такую как информацию из других систем, конкретные идентификаторы или классификационную информацию.

GenerateOpenSearchBatch принимает сгенерированный JSON-вывод Amazon Textract, объединяет его с информацией из контекста, установленного с помощью SetMetaData и подготавливает файл, оптимизированный для пакетной загрузки в OpenSearch.

В OpenSearchPushInvoke этот файл пакетной загрузки отправляется в индекс OpenSearch и становится доступным для поиска. Эта функция AWS Lambda связана с конструкцией aws-lambda-opensearch из библиотеки AWS Solutions, используя экземпляры m6g.large.search, версию OpenSearch 2.7 и настроенный размер тома Amazon Elastic Block Service (Amazon EBS) на General Purpose 2 (GP2) с объемом 200 ГБ. Вы можете изменить конфигурацию OpenSearch в соответствии с вашими требованиями.

Завершающий этап TaskOpenSearchMapping очищает контекст, который иначе может превысить квоту Step Functions для максимального размера ввода или вывода для задачи, состояния или выполнения.

Предварительные требования

Для развертывания образцов вам понадобится учетная запись AWS, AWS Cloud Development Kit (AWS CDK), текущая версия Python и Docker. Вам также потребуются разрешения для развертывания шаблонов AWS CloudFormation, загрузки в Amazon Elastic Container Registry (Amazon ECR), создания ролей Amazon Identity and Access Management (AWS IAM), функций Amazon Lambda, бакетов Amazon S3, шагов Amazon Step Functions, кластера Amazon OpenSearch и пула пользователей Amazon Cognito. Убедитесь, что ваша среда AWS CLI настроена с соответствующими разрешениями.

Вы также можете запустить экземпляр AWS Cloud9 с предустановленными AWS CDK, Python и Docker для инициирования развертывания.

Пошаговое руководство

Развертывание

  1. После настройки предварительных требований вам нужно сначала клонировать репозиторий:
git clone https://github.com/aws-solutions-library-samples/guidance-for-low-code-intelligent-document-processing-on-aws.git
  1. Затем перейдите в папку репозитория и установите зависимости:
cd guidance-for-low-code-intelligent-document-processing-on-aws/

pip install -r requirements.txt
  1. Разверните стек OpenSearchWorkflow:
cdk deploy OpenSearchWorkflow

Развертывание занимает около 25 минут с настройками конфигурации по умолчанию из образцов GitHub и создает рабочий процесс Step Functions, который вызывается, когда документ помещается в бакет/prefix Amazon S3, а затем обрабатывается до тех пор, пока содержимое документа не будет проиндексировано в кластере OpenSearch.

Ниже приведен образец вывода, включающий полезные ссылки и информацию, сгенерированные командойcdk deploy OpenSearchWorkflow:

OpenSearchWorkflow.CognitoUserPoolLink = https://us-east-1.console.aws.amazon.com/cognito/v2/idp/user-pools/us-east-1_1234abcdef/users?region=us-east-1
OpenSearchWorkflow.DocumentQueueLink = https://us-east-1.console.aws.amazon.com/sqs/v2/home?region=us-east-1#/queues/https%3A%2F%2Fsqs.us-east-1.amazonaws.com%2F123412341234%2FOpenSearchWorkflow-ExecutionThrottleDocumentQueueABC1234-ABCDEFG1234.fifo
OpenSearchWorkflow.DocumentUploadLocation = s3://opensearchworkflow-opensearchworkflowbucketabcdef1234/uploads/
OpenSearchWorkflow.OpenSearchDashboard = https://search-idp-cdk-opensearch-abcdef1234.us-east-1.es.amazonaws.com/states/_dashboards
OpenSearchWorkflow.OpenSearchLink = https://us-east-1.console.aws.amazon.com/aos/home?region=us-east-1#/opensearch/domains/idp-cdk-opensearch
OpenSearchWorkflow.StepFunctionFlowLink = https://us-east-1.console.aws.amazon.com/states/home?region=us-east-1#/statemachines/view/arn:aws:states:us-east-1:123412341234:stateMachine:OpenSearchWorkflow12341234

Эта информация также доступна в консоли AWS CloudFormation.

Когда новый документ помещается в OpenSearchWorkflow.DocumentUploadLocation, для этого документа запускается новый рабочий процесс Step Functions.

Чтобы проверить статус этого документа, ссылка OpenSearchWorkflow.StepFunctionFlowLink предоставляет ссылку на список выполнений StepFunction в консоли управления AWS, отображая статус обработки документа для каждого документа, загруженного в Amazon S3. Руководство Просмотр и отладка выполнений в консоли Step Functions предоставляет обзор компонентов и представлений в консоли AWS.

Тестирование

  1. Первый тест с использованием образца файла.
aws s3 cp s3://amazon-textract-public-content/idp-cdk-samples/moby-dick-hidden-paystub-and-w2.pdf $(aws cloudformation list-exports --query 'Exports[?Name==`OpenSearchWorkflow-DocumentUploadLocation`].Value' --output text)
  1. После выбора ссылки на рабочий процесс StepFunction или открытия консоли управления AWS и перехода на страницу сервиса Step Functions, можно просмотреть различные вызовы рабочего процесса.

Рисунок 2: Список выполнений рабочих процессов Step Functions

  1. Ознакомьтесь с текущим выполнением образца документа, где вы можете отслеживать выполнение отдельных задач рабочего процесса.

Рисунок 3: Выполнение рабочего процесса Step Functions для одного документа

По завершении процесса мы можем проверить, что документ проиндексирован в индексе OpenSearch.

  1. Для этого сначала создадим пользователя Amazon Cognito. Amazon Cognito используется для аутентификации пользователей в индексе OpenSearch. Выберите ссылку в выводе команды cdk deploy (или просмотрите вывод AWS CloudFormation в консоли управления AWS) с названием OpenSearchWorkflow.CognitoUserPoolLink.

Рисунок 4: Бассейн пользователей Cognito

  1. Затем выберите кнопку Создать пользователя, что перенаправит вас на страницу для ввода имени пользователя и пароля для доступа к панели управления OpenSearch.

Рисунок 5: Диалог создания пользователя Cognito

  1. После выбора Создать пользователя, вы можете продолжить на панель управления OpenSearch, нажав на OpenSearchWorkflow.OpenSearchDashboard в выводе развертывания CDK. Войдите, используя ранее созданное имя пользователя и пароль. При первом входе вы должны изменить пароль.
  2. После входа в панель управления OpenSearch выберите раздел Stack Management, а затем Index Pattern для создания индекса поиска.

Рисунок 6: Управление стеками OpenSearch Dashboards

Рисунок 7: Обзор шаблонов индекса OpenSearch

  1. Имя по умолчанию для индекса – papers-index, и шаблон имени индекса papers-index* будет совпадать с ним.

Рисунок 8: Определение шаблона индекса OpenSearch

  1. После нажатия кнопки Следующий шаг выберите timestamp в качестве поля времени и нажмите Создать шаблон индекса.

Рисунок 9: Поле времени шаблона индекса OpenSearch

  1. Теперь из меню выберите Обнаружение.

Рисунок 10: Обнаружение OpenSearch

В большинстве случаев необходимо изменить временной интервал в соответствии с последней индексацией. По умолчанию установлено 15 минут, и часто за последние 15 минут не было активности. В этом примере интервал изменен на 15 дней для визуализации индексации.

Рисунок 11: Изменение временного интервала OpenSearch

  1. Теперь вы можете начать поиск. Был проиндексирован роман, вы можете искать любые термины, например позвони мне Исмаил, и просматривать результаты.

Рисунок 12: Термин поиска в OpenSearch

В данном случае термин позвони мне Исмаил встречается на 6-й странице документа по данному Uniform Resource Identifier (URI), который указывает на местоположение файла в Amazon S3. Это позволяет более быстро идентифицировать документы и находить информацию в большом корпусе PDF-, TIFF- или изображений, по сравнению с ручным просмотром.

Масштабирование

Для оценки масштаба и продолжительности процесса индексации реализация была протестирована на 93 997 документах и общим числом 1 583 197 страниц (в среднем 16,84 страницы на документ, а самый большой файл имеет 3755 страниц), которые все были проиндексированы в OpenSearch. Обработка всех файлов и индексирование их в OpenSearch заняло 5,5 часов в регионе US East (N. Virginia – us-east-1) с использованием стандартных квот Amazon Textract Service. Ниже приведен график, на котором показаны начальное тестирование в 18:00, основная индексация в 21:00 и завершение в 2:30.

Рисунок 13: Обзор индексации OpenSearch

Для обработки был установлен параметр tcdk.SFExecutionsStartThrottle со значением executions_concurrency_threshold=550, что означает, что одновременное выполнение рабочих процессов по обработке документов ограничено 550, и лишние запросы помещаются в очередь Amazon SQS Fist-In-First-Out (FIFO), которая затем обрабатывается, когда текущие рабочие процессы завершаются. Значение порога 550 основано на квоте Textract Service в 600 в регионе us-east-1. Поэтому глубина очереди и возраст самого старого сообщения являются метриками, которые стоит отслеживать.

Рисунок 14: Мониторинг Amazon SQS

В данном тесте все документы были загружены в Amazon S3 одновременно, поэтому Approximate Number of Messages Visible резко возрастает, а затем медленно снижается, так как новые документы не индексируются. Approximate Age Of Oldest Message увеличивается, пока все сообщения не будут обработаны. Время хранения сообщений Amazon SQS установлено на 14 дней. Для очень долгой обработки отставшихся документов, которая может превышать 14 дней, начните с обработки небольшого подмножества представительных документов и отслеживайте продолжительность выполнения, чтобы оценить, сколько документов вы можете обработать, прежде чем превысить 14 дней. Метрики CloudWatch Amazon SQS выглядят аналогично для случая обработки большого запаса документов, которые загружаются сразу, а затем полностью обрабатываются. Если ваш случай использования предполагает постоянное поступление документов, оба параметра – Approximate Number of Messages Visible и Approximate Age Of Oldest Message – будут иметь более линейный характер. Вы также можете использовать параметр порога для смешивания постоянной нагрузки с обработкой отставшихся документов и распределения ресурсов в соответствии с вашими потребностями в обработке.

Другие метрики для мониторинга – это состояние кластера OpenSearch, который следует настроить в соответствии с лучшими практиками OpenSearch Service от Amazon. По умолчанию используются экземпляры m6g.large.search.

Рисунок 15: Мониторинг OpenSearch

Вот снимок ключевых показателей эффективности (KPI) для кластера OpenSearch. Ошибок нет, постоянная скорость индексации и задержка.

Выполнение рабочих процессов Step Functions показывает состояние обработки каждого отдельного документа. Если вы видите выполнение в состоянии Failed, выберите подробности. Хорошая метрика для мониторинга – автоматическая панель мониторинга AWS CloudWatch для Step Functions, которая предоставляет некоторые метрики Step Functions CloudWatch.

Рисунок 16: Мониторинг выполнения Step Functions

На этой графике панели мониторинга AWS CloudWatch вы видите успешные выполнения Step Functions со временем.

Рисунок 17: Мониторинг выполнения OpenSearch с ошибками

А этот показывает неудачные выполнения. Их стоит исследовать через обзор AWS Console Step Functions.

На следующем снимке экрана показан один пример неудачного выполнения из-за того, что исходный файл имеет размер 0, что имеет смысл, поскольку файл не содержит контента и не может быть обработан. Важно фильтровать неудачные процессы и визуализировать ошибки, чтобы вы могли вернуться к исходному документу и проверить причину.

Рисунок 18: Неудачный рабочий процесс Step Functions

Другие ошибки могут включать документы, не соответствующие типу mime: application/pdf, image/png, image/jpeg или image/tiff, потому что другие типы документов не поддерживаются Amazon Textract.

Стоимость

Общая стоимость обработки 1 583 278 страниц была разделена между используемыми сервисами AWS для реализации. Следующий список является приблизительными значениями, поскольку фактическая стоимость и продолжительность обработки могут варьироваться в зависимости от размера документов, количества страниц в документе, плотности информации в документах и региона AWS. Amazon DynamoDB потреблял $0.55, Amazon S3 – $3.33, OpenSearch Service – $14.71, Step Functions – $17.92, AWS Lambda – $28.95 и Amazon Textract – $1,849.97. Также имейте в виду, что развернутый кластер Amazon OpenSearch Service выставляется почасовая тарификация и будет накапливать большие затраты при длительной работе.

Модификации

Вероятно, вы хотите изменить реализацию и настроить для своего случая использования и документов. Мастер-класс “Использование машинного обучения для автоматизации и обработки документов в масштабе” представляет хороший обзор о том, как изменять фактические рабочие процессы, изменять поток и добавлять новые компоненты. Чтобы добавить пользовательские поля в индекс OpenSearch, обратите внимание на задачу SetMetaData в рабочем процессе с использованием функции AWS Lambda set-manifest-meta-data-opensearch для добавления метаданных в контекст, которые будут добавлены как поле в индекс OpenSearch. Любая информация о метаданных станет частью индекса.

Очистка

Удалите примерные ресурсы, если вам они больше не нужны, чтобы не возникли будущие затраты с помощью следующей команды:

cdk destroy OpenSearchWorkflow

в той же среде, что и команда cdk deploy. Обратите внимание, что это удаляет все, включая кластер OpenSearch, все документы и контейнер Amazon S3. Если вы хотите сохранить эту информацию, создайте резервную копию контейнера Amazon S3 и создайте снимок индекса из кластера OpenSearch. Если вы обработали много файлов, вам может потребоваться сначала очистить контейнер Amazon S3 с помощью консоли управления AWS (т.е. после создания резервной копии или синхронизации с другим контейнером, если вы хотите сохранить информацию), потому что функция очистки может завершиться по тайм-ауту, а затем удалить стек AWS CloudFormation.

Заключение

В этой статье мы показали вам, как развернуть полноценное решение стека для ввода большого количества документов в индекс OpenSearch, которые готовы к использованию в сценариях поиска. Были рассмотрены отдельные компоненты реализации, а также вопросы масштабирования, стоимости и варианты модификации. Весь код доступен как OpenSource на GitHub в виде образцов IDP CDK и как конструкции IDP CDK для создания своих собственных решений с нуля. В качестве следующего шага вы можете начать изменять рабочий процесс, добавлять информацию в документы в поисковом индексе и исследовать IDP-семинар. Пожалуйста, оставьте комментарий ниже о своем опыте и идеях по расширению текущего решения.