Когда бумаг больше, чем людей в Огайо
400 миллионов. Это не число звёзд в галактике. Это количество документов, которые Huntington Bank нужно было обработать за несколько месяцев. Чековые книжки, кредитные договоры, выписки — вся история клиентов за десятилетия. В каждом документе торчат персональные данные: имена, адреса, номера счетов, SSN. До старта проекта это был просто склад плёнок и коробок с бумагой. Буквально.
В чём соль? Регуляторы (спасибо, CCPA, GDPR, SOX) требуют, чтобы данные клиентов были защищены. Банк решил перевести всё в цифру, но нельзя просто отсканировать и выложить в S3. Нужно найти конфиденциальную информацию и аккуратно её закрасить — заменить на заглушки типа [REDACTED] или хеши. И при этом не потерять смысл для аналитики и аудита.
Ручная работа? 400 млн страниц — это сотни тысяч человеко-часов. Даже если нанять армию стажёров, банк не успеет к дедлайну. Нужен автомат.
❗Важный контекст: В 2026 году AWS Textract уже умеет детектить более 50 типов чувствительных сущностей. Но когда Huntington Bank запускал пилот, речь шла о кастомных моделях. Мы рассмотрим оба подхода — встроенный OCR и дообучение на SageMaker.
Почему не взять готовый OCR и не закрасить всё подряд?
Звучит просто: скормить все PDF в Textract, получить JSON с bounding boxes, найти паттерны (номера счетов, даты рождения) и заменить текст. На деле — ад.
- Документы разного качества: отлично отсканированные чеки и плохие копии с пятнами.
- Некоторые документы — рукописные (подписи, пометки). Textract с рукописью работал плохо (до 2024, сейчас лучше, но не идеал).
- Конфиденциальные данные не всегда в явном виде: номер счёта может быть вставлен в текст без пробелов.
- Нужно различать, что редактировать, а что оставить. Например, имя в поле «Получатель» — удалять? А если это публичная информация?
- Масштаб: 400 млн — это не 10 тысяч. S3, Lambda, API вызовы — всё должно работать на грани лимитов.
Простое решение «заретушировать всё подряд» не прокатит — аудиторы потребуют объяснения каждого заретушированного слова. Банк решил строить многоступенчатый пайплайн.
Архитектура: оркестр из Step Functions, Textract и SageMaker
Huntington Bank выбрал serverless-подход. Главный дирижёр — AWS Step Functions. Он запускает параллельные пачки документов, управляет очередями, повторяет ошибки. Внутри каждой пайплайн-ветки:
- Ingestion: S3 Event Notification -> SQS -> Lambda-функция, которая разбирает PDF на страницы (ImageMagick / pdf2image).
- OCR с Textract: Каждая страница отправляется в
AnalyzeDocumentс типомFORMSилиTABLES. Результат — JSON с координатами и текстом. - Классификация: SageMaker inference endpoint (на базе fine-tuned BERT) определяет, какие блоки содержат PII (Personally Identifiable Information). Если модель неуверенна — документ отправляется на ручную проверку через AWS WorkMail + простой UI.
- Редактирование: Lambda рисует чёрные прямоугольники поверх оригинала в указанных координатах. Генерируется новый PDF.
- Постобработка: Проверка качества (ещё одна модель, сравнивающая исходник и результат). Неудовлетворительные — в DLQ+человек.
- Сохранение: Результат в S3 с тегами, метаданные в DynamoDB, лог изменений — в CloudWatch Logs.
Map type: Distributed), разбивая документы на независимые задачи. Это позволило масштабироваться до сотен тысяч параллельных вызовов без перегрузки.Пошаговый план: как выжить с 400 млн документов (и не обанкротиться на Textract)
Разберём по полочкам, что сделал Huntington. Если хотите повторить — готовьтесь к бюджету на AI-услуги, но оно того стоит.
1 Инвентаризация и подготовка
Сначала — аудит. Какие форматы? Сколько страниц в среднем? Какие типы PII? Huntington выяснил, что 70% документов — это сканы с чеков (односторонние), 20% — выписки (многостраничные с таблицами), 10% — рукописные анкеты.
Загрузили всё в S3 Standard-IA (чтобы не переплачивать за архивный класс — доступ нужен постоянно). Каждый объект — один PDF, но мысль разбить их на страницы пришла позже.
- Ошибка, которую делают многие: не разбивать PDF на страницы. Textract
AnalyzeDocumentпринимает только одну страницу за раз (макс 10 Мб). Если скормить 500-страничный PDF, он упадёт с ошибкой. Решение: Lambda с PyPDF2 разрезает PDF на отдельные страницы, сохраняет в временный буфер (S3/EFS).
2 Кастомная модель для PII на SageMaker
Textract выдаёт сырые блоки текста с координатами. Чтобы понять, что именно является PII, одного Regex недостаточно. Huntington обучил модель на основе BERT (DistilBERT) на собственных данных. Разметили 50 000 страниц вручную (да, больно). Обучали на SageMaker Training с GPU-инстансами (ml.g4dn.xlarge, потом перешли на ml.g5). Fine-tuning занял 2 недели. Результат: F1-score 0.94 на тестовой выборке.
Как использовать? SageMaker endpoint принимает JSON с текстом и bounding box'ами, а возвращает список полей, которые нужно редактировать (с confidence).
⚠️ Внимание: кастомная модель — это дорого. Только инфренс на 400 млн страниц обойдётся в $5–10 млн на SageMaker (в 2026 цены слегка снизились, но всё равно бюджетно). Huntington использовал batch transform для больших объёмов и real-time endpoint только для ручных проверок.
3 Редактирование: как не испортить оригинал
Логика простая: берём координаты от Textract (нормализованные к размеру страницы), пересчитываем в пиксели, рисуем чёрный прямоугольник поверх текста. Но есть проблема: если текст был цветной, мы рискуем оставить следы. Поэтому Huntington использовал Python Pillow (PIL) и закрашивал не просто «по границе текста», а цельное поле (например, всю строку). Чтобы не было полупрозрачных артефактов — использовали paste() с чёрным цветом и альфа-каналом 255.
Ещё нюанс: некоторые документы — не изображения, а «плохие» PDF с текстовым слоем. Для них Textract работает отлично, а редактировать надо сам текстовый слой. Метод: Ghostscript для рендера страницы в изображение, редактирование изображения, затем замена страницы в PDF. Это ресурсоёмко — приходится ставить EFS для кеша.
4 Масштабирование: Step Functions + SQS + Rate Limiting
400 млн документов — это ~1 млрд страниц. Textract имеет квоту 1500 транзакций в секунду (по умолчанию). Huntington попросил увеличение до 10k TPS (AWS дал после обоснования). Step Functions разбивает на пачки по 1000 страниц. Каждая пачка — это Map с параллелизмом 500. Внутри — вызов Textract, ожидание ответа (синхронный режим плохо подходит — лучше асинхронный StartDocumentAnalysis).
Реальная схема: S3 Put -> Step Functions -> SNS -> Lambda стартует async Textract. Результат приходит в S3 -> второй Step Function. Это позволяет не платить за время простоя. Среднее время обработки одной страницы — 2 секунды. Итого: 1 млрд страниц / 10k TPS = 100 000 секунд = 28 часов. С учётом повторных вызовов и ручных проверок — около 2 месяцев.
Типичные грабли, на которые наступили (даже банкиры)
Хочу подсветить ошибки, которые стоили Huntington дополнительных недель:
- Не использовать асинхронные вызовы Textract изначально. Синхронные ломали таймауты Lambda (15 минут). Пришлось переписать.
- Игнорирование дубликатов. Один и тот же чек мог быть отсканирован трижды. Без дедупликации — тройной счёт за API. Решение: хеш документа в DynamoDB (SHA256 всего файла).
- Перекос данных в SageMaker endpoint. Когда тысячи запросов идут на одну модель, endpoint деградирует — латентность растёт. Пришлось включить auto-scaling с целевым показателем 1000 запросов на инстанс.
- Ручная проверка стала бутылочным горлышком. 2% документов отправлялись людям. Это 8 млн документов. Без автоматизации проверяли бы год. Решение: сделали второй классификатор (low-confidence -> экспертный просмотр в упрощённом UI на React + API Gateway).
- Не учли cost anomaly. Textract стоит $1.50 за 1000 страниц (первые уровни). При 1 млрд страниц — это $1.5 млн только за Textract. Huntington забил лимиты бюджета в AWS Budgets и настроил алерты.
FAQ: волнует каждого, кто дочитал до сюда
Сколько это стоило в итоге?
По оценкам Huntington (публиковали на re:Invent 2025) — около $4 млн на всё: Textract, SageMaker, хранение, Compute. Для банка с 20 млрд активов — копейки. Окупилось за счёт автоматизации комплаенс-отчётности.
А можно было обойтись без SageMaker?
Да, использовать Amazon Comprehend для PII (он умеет детектить 30+ типов). Но точность на финансовых документах была ниже (91% vs 94%). Банк выбрал кастомную модель. Если у вас бюджет ограничен — Comprehend + ручная вычитка спасёт.
Что если документы на нескольких языках?
Textract поддерживает >50 языков. Модель на SageMaker обучали только на английском (банк США). Для мультиязычности нужно больше разметки.
Как обеспечивается безопасность PII?
S3 — SSE-KMS, CloudTrail — логирование каждого доступа. Асинхронные вызовы Textract идут через VPC Endpoint (AWS PrivateLink). SageMaker endpoint — в VPC. Все данные шифруются в покое и в транзите.
Неочевидный совет, который вы заберёте с собой
Многие думают: «Давайте всё отправим в Textract, получим JSON, закрасим и готово». Но настоящий ад начинается на этапе валидации. Huntington построил автоматическое тестирование ретуши: случайно выбирает 0.1% обработанных документов, запускает повторный OCR и проверяет, не осталось ли PII. Если находится — инцидент, конвейер останавливается, модель дообучается.
Этот контур обратной связи — то, что отличает индустриальное решение от поделки. Сделайте такой же — и ваши аудиторы будут спать спокойно.
Кстати, если вы хотите глубже погрузиться в похожие кейсы, рекомендую почитать как Associa обрабатывала 48 млн документов — там тоже использовали Textract, но без кастомных моделей. Или кейс с 4700 инженерных PDF за 45 минут — совсем другой подход, но тоже полезно.
Если захотите построить RAG-систему на базе отредактированных документов — посмотрите локальный RAG для 4 млн PDF — там есть нюансы по хранению и индексации.
И да, ознакомиться с Amazon Textract стоит до того, как начнёте — изучите pricing как свои пять пальцев. Иначе можно случайно потратить бюджет года.
