«97,0 % точности и 95,2 % полноты»: AWS собрала бессерверный конвейер редакции PII на Bedrock Data Automation

От OCR к модели: почему задачу переписали

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

Ручная редакция в таком масштабе не работает: она съедает человеко-часы, добавляет ошибок и создаёт комплаенс-риски. Более того, как подчёркивает AWS, редакция — это не только задача обнаружения, но и задача точности.

Классический путь — OCR плюс сопоставление по шаблонам или собственная ML-модель. Ограничения AWS перечисляет прямо: такие подходы ломаются на испорченном тексте, плохо выражают бизнес-логику уровня отдельного поля и требуют ML-экспертизы для сборки и переобучения моделей при каждой смене формата документов.

Генеративные модели, по логике авторов, меняют рамку: они интерпретируют вёрстку, подписи полей и контекст, а не отдельные символы.

Фундамент конвейера — Amazon Bedrock Data Automation (BDA): управляемый сервис, который извлекает структурированную информацию из неструктурированного контента — документов, изображений, видео и аудио. BDA применяет генеративный ИИ, чтобы превращать мультимодальные данные в структурированные форматы, и несёт встроенные предохранители вроде visual grounding и оценок уверенности.

Ключевая для этой задачи часть BDA — кастомный blueprint: в нём объявляют именованные поля документа и описывают их обычным языком, а на выходе получают содержимое поля, оценку уверенности и координаты bounding box для каждого найденного вхождения.

Линия эта не новая: раньше AWS уже показывала модельно-независимый детектор PII на больших языковых моделях, где логика обнаружения целиком живёт в инструкциях и тонком слое разбора.

Что именно описывает blueprint

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

В демонстрационном сценарии AWS разбирает редакцию выписок лечащего врача (Attending Physician Statements, APS) до их попадания в дальнейшую обработку страховых требований.

Blueprint создаётся через консоль, AWS CLI или SDK; схема перечисляет поля, их типы, описания на естественном языке и трансформации. Тип вывода при этом можно задать явно, а можно отдать сервису на догадку.

Именно инструкция на естественном языке позволяет разделить поля, которые выглядят одинаково. Дата рождения пациента — это дата, но даты приёма и подписи тоже даты, и редакции они не подлежат; формулировка в blueprint сужает область до данных пациента, а имя и подпись врача остаются вне набора на удаление.

Полная схема для APS в примере AWS — 37 полей в 9 группах.

В конвейер документ уходит по одной странице на вызов API: так область генеративного запроса ограничивается контекстом ровно одной страницы. В одном запросе BDA обрабатывает страницу целиком, интерпретируя вёрстку, подписи и контекст без опоры на посимвольный OCR.

Проверка точности: 12 документов, 47 страниц, шесть уровней качества

Оценку AWS проводила против эталона, размеченного людьми, на образцах шести уровней качества — от аккуратных печатных форм до сканов с низким разрешением 100 DPI.

Первые тесты показали неочевидный результат: blueprint находил каждое вхождение PII в наборе из 12 документов (47 страниц) как минимум один раз, но иногда пропускал повторные упоминания в повествовательном тексте и в рукописных заметках врача.

Решением стал второй проход поверх того же вызова. Blueprint отдаёт два вида вывода: кастомный — найденные PII-поля с bounding box, и стандартный — полное извлечение, где bounding box есть у каждого слова.

Проверка токенным сопоставлением нормализует каждое найденное значение PII в слова-токены, а затем ищет в пословном стандартном выводе страницы слова, чья нормализованная форма совпадает с токеном PII, и добавляет новые непересекающиеся совпадения.

Эффект измерен: точность 97,0 %, полнота выросла с 89,3 % до 95,2 % — на цифровых PDF, рукописных формах и факсах низкого разрешения. AWS отдельно отмечает, что второй проход не добавляет задержки: оба вида вывода приходят из одного вызова.

Пять функций Lambda, вложенные map-состояния и 25 000 страниц за ночь

Оркестрация — бессерверная: конвейер собран из пяти функций AWS Lambda под управлением AWS Step Functions. Схема выглядит как пять последовательных шагов: Initialize, Preprocessing, Redaction, Reassembly и Reporting.

Внутри работают два уровня вложенных распределённых map-состояний: внешний обход по документам, внутренний — по страницам внутри документа.

На вход конвейер получает три вещи: префикс в Amazon S3 с исходниками, префикс в S3 для результатов и ARN blueprint.

Заметная деталь реализации: редакция переписывает сами пиксели изображения, поэтому закрытое содержимое физически отсутствует в выходном файле. Это принципиально отличается от аннотаций-наложений, под которыми исходный текст остаётся восстановимым.

Отказоустойчивость описана на уровне документа: повторы с экспоненциальной задержкой и джиттером для всплесков троттлинга, изоляция ошибок, чтобы один испорченный документ не ронял соседей, штатный redrive Step Functions и итоговый отчёт с признаком fully_reconciled; если не удалось обработать вообще всё, задание завершается выделенным отказом PipelineNoOutput.

По безопасности AWS перечисляет выделенные least-privilege роли IAM для каждой Lambda, шифрование S3 по умолчанию алгоритмом AES-256, TLS при передаче, опциональный вывод трафика через VPC endpoints и аудит активности API через AWS CloudTrail.

Объём, ради которого всё это собиралось, назван прямо: около 25 000 страниц за ночь.

Где подход уместен

AWS не продаёт его как универсальную замену: подход, по её формулировке, подходит там, где документы испорчены или разнородны по формату, где нужна бизнес-логика уровня поля и где требуются координаты bounding box на уровне пикселей.

Главный практический вывод авторов — относиться к blueprint как к конфигурации: тот же продакшен-конвейер можно направить на новый тип документа, поменяв схему blueprint и входной префикс в S3.