«Изменение, которое раньше занимало часы или дни согласований, теперь занимает секунды»: AWS описала жизненный цикл адаптеров Textract

Что именно доучивает адаптер

Amazon Textract — полностью управляемый сервис машинного обучения, который вытаскивает из сканов текст, рукописные записи, элементы вёрстки и структурированные данные. В типовых сценариях так автоматизируют обработку счетов, приём ипотечных заявок, разбор страховых случаев и проверку документов, удостоверяющих личность. Адаптеры Custom Queries расширяют эту возможность: они подстраивают извлечение под конкретный тип документа, где у форм нестандартная вёрстка или своя терминология.

Своя модель для этого не нужна: вы загружаете образцы, размечаете их запросами и ожидаемыми ответами и доучиваете адаптер на распознавание характерного расположения полей. Разобранные в публикации приёмы — архитектура решения, стратегия продвижения по средам и настройки безопасности — не привязаны к типу адаптера и в равной степени относятся к адаптерам Forms и Tables.

Ключевая особенность, которая определяет всю экономику подхода: адаптер выучивает структуру и расположение полей типа документа, а не содержимое отдельного документа. В публикации это показано на наглядной пропорции — адаптер обучают на десяти образцах форм ABC, чтобы выучить вёрстку и поля, а в продакшене тот же самый адаптер разбирает 18 000 разных форм ABC этого типа.

Три препятствия на выходе из прототипа

Первое — продвижение адаптеров. Перенос из обучающего аккаунта в остальные сейчас устроен так: нужен тикет в AWS Support, а передаются только веса обученной модели — описания запросов и обучающие данные не переносятся. Каждая версия адаптера требует отдельного запроса на копирование, что даёт контроль над тем, какие именно версии попадают дальше. Исходный и целевой аккаунты обязаны находиться в одном регионе. Без автоматизации это ручное узкое место, замедляющее ритм релизов.

Второе — маршрутизация документов. Amazon Textract поддерживает один адаптер на один вызов AnalyzeDocument, на страницу и на тип функции. Поскольку большинство компаний обрабатывает несколько версий форм одновременно, перед обращениями к сервису нужен собственный механизм выбора подходящего адаптера. Для разных версий в разных файлах подходит предварительная классификация по текстовым маркерам, а если разные адаптеры нужны внутри одного многостраничного документа, применяют асинхронный StartDocumentAnalysis и ограничивают адаптер параметром Pages в AdaptersConfig.

Третье — продакшен-безопасность. Регулируемые отрасли требуют шифрования данных при хранении и передаче, сетевой изоляции, минимально необходимых прав IAM, полного журнала аудита и подтверждённого соответствия стандартам.

Как выглядит конвейер: S3, классификация, Parameter Store, Textract

Документы попадают в бакет Amazon S3 с шифрованием на стороне сервера; в примерах кода используется управляемое S3 шифрование AES256, но для продакшена рекомендованы ключи, управляемые клиентом в AWS KMS, — они дают полный контроль над ротацией ключей и политиками доступа. Для каждого входящего документа облегчённый шаг маршрутизации сначала извлекает сырой текст через DetectDocumentText, а затем определяет версию документа по маркерам вроде заголовков формы, идентификаторов версии или подписей полей. По результату классификации из Parameter Store достаётся идентификатор нужного адаптера, и уже он подставляется в вызов AnalyzeDocument или StartDocumentAnalysis.

Выбор синхронного или асинхронного вызова определяется размером документа: синхронный AnalyzeDocument обрабатывает одну страницу, асинхронный StartDocumentAnalysis берёт многостраничные PDF и TIFF до 3 000 страниц. Сервис принимает JPEG, PNG, PDF и TIFF, а PDF на основе XFA не поддерживается. Для асинхронного режима обязателен OutputConfig, определяющий, куда складывать результаты, — при желании с уведомлениями через Amazon SNS по завершении.

Главный выигрыш от такой схемы — развязка управления адаптерами и кода приложения. Вынеся идентификаторы адаптеров в Parameter Store, можно обновлять ссылки на продакшен-адаптеры с нулевым простоем и без переразвёртывания приложения, поэтому изменение, которое раньше занимало часы или дни согласований, выполняется за секунды.

Инфраструктуру — роли IAM, бакеты S3, ключи KMS, параметры SSM и аварийные сигналы CloudWatch — описывают через CloudFormation или Terraform. Оговорка важная: через CloudFormation адаптеры нативно не создаются, для этого используют AWS CLI, обёрнутый в custom resource на базе Lambda либо вынесенный в отдельный шаг CI/CD. В Terraform рекомендуют terraform_data, появившийся в версии 1.4 как замена устаревшего null_resource, вместе с local-exec; AWS Prescriptive Guidance предлагает считать это временным решением и следить за появлением нативной поддержки в провайдере.

Дисциплина версий задана численно: минимум пять обучающих и пять тестовых документов на адаптер. Предельные объёмы — до 2 500 обучающих страниц и до 1 000 тестовых страниц. Автообновление адаптера советуют отключать в продакшене, пока не выстроено регрессионное тестирование. Держать стоит несколько версий одновременно — продакшен, откат и предпродакшен. Отдельное требование: описания запросов документировать на своей стороне, потому что Amazon Textract не хранит текст запросов как отдельный извлекаемый артефакт.

Копирование между аккаунтами против единого хаба

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

Первый подход — копирование между аккаунтами: адаптер обучают в одном аккаунте и копируют в каждый нижестоящий через тикет в AWS Support, так что каждая среда хранит свой идентификатор адаптера. Он проще для организаций с небольшим числом адаптеров — меньше десяти — и нечастыми обновлениями. В целевом аккаунте адаптер с нужным именем и описанием должен уже существовать, обучать его там не требуется, а после копирования точность сверяют, прогнав тестовый набор документов.

Второй подход — выделенный хаб-аккаунт, в котором обучаются все адаптеры, а среды обращаются к Amazon Textract в этом аккаунте через кросс-аккаунтные роли IAM. Так снимаются и обращения в поддержку, и само копирование, но добавляется сложность кросс-аккаунтной сети.

Экономика у подходов разная. В схеме с хабом все начисления за Amazon Textract ложатся на один аккаунт, что упрощает учёт, но требует внутреннего перевыставления затрат, например через теги распределения расходов. Тарификация при этом страничная, а Custom Queries с адаптерами стоят дороже базового распознавания текста. Свести весь объём в один аккаунт не значит получить скидку за объём, поскольку Amazon Textract использует плоскую цену за страницу. Кросс-аккаунтный доступ к S3 внутри одного региона не тарифицируется за передачу данных. Отдельный риск — квоты: при централизации все среды конкурируют за квоты одного аккаунта, а лимиты на максимальное число адаптеров и на создаваемые за месяц версии адаптеров считаются для хаба суммарно.

Практический критерий выбора в публикации сформулирован прямо: централизованный хаб — когда типов адаптеров меньше десяти, пропускная способность предсказуема и есть платформенная команда. Распределённое копирование выбирают при пиковых нагрузках, жёстких требованиях к изоляции отказов и более чем десяти типах адаптеров у разных команд.

Безопасность: PrivateLink, KMS, CloudTrail и отказ от обучения на ваших данных

Сетевую изоляцию обеспечивает интерфейсный VPC-эндпоинт на базе AWS PrivateLink: трафик к API Amazon Textract не выходит в публичный интернет. Такой эндпоинт позволяет обращаться к API приватно, без интернет-шлюза, NAT-устройства, VPN-подключения или AWS Direct Connect, — трафик между вашим VPC и Amazon Textract не покидает сеть AWS. Вся коммуникация с сервисом идёт с шифрованием TLS 1.2+ при передаче. Для данных при хранении настраивают серверное шифрование бакетов S3 ключами, управляемыми клиентом, а роли Amazon Textract выдают права kms:Decrypt на ключ входного бакета и kms:Encrypt на ключ выходного.

В политиках IAM действует принцип минимально необходимых прав, причём с оговоркой: операции обработки документов не поддерживают права на уровне ресурсов, поэтому в политике приходится указывать Resource со звёздочкой — и ограничивать набор разрешённых действий. Для дополнительной защиты от прямого доступа к бакету в политиках S3 применяют ключ условия aws:CalledViaFirst, разрешая доступ к объектам только запросам, инициированным Amazon Textract. В кросс-аккаунтных сценариях с адаптерами советуют явные ресурсные политики и внешние идентификаторы против атаки confused deputy.

Наблюдаемость строится на журналировании всех вызовов API через AWS CloudTrail и метриках Amazon CloudWatch, включая аварийные сигналы на дросселирование по счётчику ThrottledCount, частоту ошибок и задержки. Резкий рост неуспешных извлечений может указывать на неверно настроенный адаптер или попытки несанкционированного доступа.

Отдельный пункт — использование данных для улучшения сервиса: по умолчанию AWS может применять обработанный Amazon Textract контент для развития сервиса. Это отключается политикой отказа от использования контента сервисами ИИ на уровне организации, организационного подразделения или аккаунта в AWS Organizations. Полезная деталь из документации: отказ от использования контента приводит к удалению всей связанной исторической информации, которая была передана AWS до установки этой настройки. Документы, обработанные синхронно, не сохраняются после возврата ответа API, а результаты асинхронной обработки лежат в указанном вами бакете S3 под вашими ключами шифрования.

Что касается регулируемых отраслей, Amazon Textract заявлен как пригодный для нагрузок в рамках HIPAA, PCI DSS, FedRAMP High, SOC 1/2/3, ISO 27001/27017/27018 и HITRUST CSF. AWS при этом напоминает о модели разделяемой ответственности: инфраструктуру защищает провайдер, а конфигурацию, управление доступом и обращение с данными — вы.

Публикацию подготовили Бхавья Срути Соде, технический менеджер по работе с клиентами AWS в области ИИ и машинного обучения, и Хуан Пабло Ариас Мора, менеджер по анализу клиентских настроений (Customer Sentiment Intelligence) с фокусом на Physical AI и робототехнику, — оба из подразделения AWS по клиентским решениям.