«Шаблоны ломаются на каждой новой форме поставщика»: AWS собрала самообучающийся конвейер обработки документов на Bedrock AgentCore

Почему шаблонный IDP перестал устраивать

Классические системы интеллектуальной обработки документов (IDP) требуют заранее описать шаблоны, правила извлечения и логику проверки под каждый формат. Как только новый поставщик присылает счёт или заказ с другой вёрсткой, конвейер ломается. AWS в публикации ссылается на исследование IDC: проблемы с документами обходятся организациям в $19 732 на каждого информационного работника в год и снижают производительность на 21,3 %.

Сопутствующие цифры из того же материала: сотрудники тратят на работу с документами до 30 % времени, а доля ошибок при ручном вводе данных составляет 1–4 %. На этом фоне в статье сформулированы три главные проблемы шаблонного подхода — жёсткость шаблонов, отсутствие обучения (одни и те же ошибки повторяются, потому что система не сохраняет знание из прошлых исправлений) и разрастание издержек сопровождения: каждый новый поставщик или вариант документа множит объём ручной настройки.

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

Две схемы маршрутизации и восемь агентов

В решении восемь специализированных агентов работают внутри двух графовых маршрутов на Amazon Bedrock AgentCore, а сама схема собрана на открытом SDK Strands Agents. Первый маршрут — identification (идентификация), второй распадается на training (обучение на новом типе документа) и automation (обработка уже известного типа).

Идентификация устроена так: агент Analyzer извлекает текст через Amazon Textract и определяет тип документа и отправителя, а агент Matcher ищет похожие документы по векторному сходству в Amazon S3 Vectors.

Если совпадений нет, включается обучение: агент Instructions генерирует промпты извлечения, агент Extractor достаёт структурированные данные, а агент Validator сверяет результат со схемой и бизнес-правилами в Amazon Aurora DSQL. Когда проверка не проходит, агент Instructions Fixer уточняет промпт и запускает повтор; при успехе агент Save Instructions сохраняет инструкции для переиспользования.

Когда совпадение найдено, работает автоматизация: Extractor применяет уже сохранённые инструкции, а если валидация всё-таки падает, агент Troubleshooter правит сами извлечённые данные, не меняя инструкции.

Путь документа: от письма до проверки результата

Вход — письмо в Amazon Simple Email Service (Amazon SES) или прямая загрузка в Amazon S3. Дальше Amazon EventBridge запускает функцию AWS Lambda, которая создаёт задачу отслеживания в Amazon DynamoDB и вызывает AgentCore runtime.

Рантайм оркестрирует обработку через Strands Agents, а доступ агентов к ресурсам AWS обеспечивают machine-to-machine учётные данные под управлением AgentCore Identity и Amazon Cognito. Функции Lambda становятся инструментами агентов через интерфейс Model Context Protocol (MCP) в AgentCore Gateway; данные агенты извлекают через Amazon Textract, классифицируют документы векторными эмбеддингами в S3 Vectors, а бизнес-правила проверяют в Aurora DSQL, в том числе через MCP-серверы. Состояние и разбор инцидентов видны в чат-панели на Amazon Elastic Container Service, наблюдаемость дают AgentCore Observability и телеметрия Amazon CloudWatch.

Разворачивается всё как шесть стеков AWS CloudFormation: Core (S3, Cognito, DynamoDB), Gateway (Lambda-инструменты и AgentCore Gateway), Aurora (Amazon Aurora DSQL), Agent (AgentCore runtime и контейнеры), UI Orchestrator и Modern UI (React-приложение на Amazon CloudFront). По оценке публикации, установка занимает примерно 15–20 минут. В требованиях перечислены аккаунт AWS, доступ к Amazon Bedrock с моделями Amazon Nova и Anthropic (Claude), доступ к AgentCore (Runtime, Gateway, Identity), S3 Vectors и Aurora DSQL, установленный AWS Cloud Development Kit (AWS CDK) v2, работающий Docker, Python 3.11+ и Node.js 18+, плюс права IAM на создание бакетов, функций, таблиц, пулов пользователей и контейнерных сервисов.

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

Как система дописала себе инструкцию: разбор первого документа

Показательный пример в публикации — первый заказ на покупку от нового поставщика Two Wheel Store. Matcher не находит похожих документов и уводит задачу в контур обучения. Analyzer достаёт текст: номер заказа PO-2026-0102-2584, дата 2026-01-02, позиции AC-021 и SB-004 с количествами и ценами, итог $14 931,54.

Extractor собирает структурированный JSON, а Validator его отклоняет: артикул SB-004 не подходит под внутренний шаблон ^AB-[A-Z]{2}-\d{3}$ — у поставщика свой формат SKU, у компании свой (AB-SB-004). Агент Instructions Fixer распознаёт расхождение и добавляет в промпт явное правило: префиксовать артикулы поставщика через AB-. На втором проходе семь позиций проходят проверку, а Save Instructions сохраняет уточнённый промпт в векторное хранилище. Полный проход первого документа занял 3 минуты 49 секунд.

Второй заказ от того же поставщика система находит по сходству с оценкой 3,946 при пороге 3,7 и отправляет в контур автоматизации: Extractor применяет сохранённые инструкции напрямую, включая выученное правило трансформации артикулов (EL-002 → AB-EL-002, HB-071 → AB-HB-071, PD-002 → AB-PD-002). Три позиции проходят валидацию с первого раза при итоге заказа $5 979,19, а сквозное время обработки падает до 1 минуты 30 секунд.

Что повышает точность и сколько это стоит

Самообучение в системе реализовано двумя петлями обратной связи: обучающая петля (когда Instructions Fixer уточняет промпты после неудачной валидации, а улучшенные инструкции сохраняются и переиспользуются) и петля обработки (когда Troubleshooter разбирает ошибки извлечения и тем самым выявляет закономерности в вариациях форматов).

Стоимость считается на серверных и on-demand ресурсах без простоя: для нагрузки 10 обучающих документов и 1000 обработанных документов в месяц в регионе US East (N. Virginia) оценка — около $58 в месяц. Примерно 85 % этой суммы приходится на инференс фундаментальных моделей через Amazon Bedrock, то есть около $0,055 за документ; фактическая цена сильно зависит от того, какие модели назначены агентам. Выбор моделей вынесен в один файл agents/orchestratorgraph/utils/config.py, поэтому для простых задач можно брать более дешёвые модели, а сильные — только там, где они действительно нужны.

При смене модели публикация советует проверять качество извлечения через AgentCore Evaluations — нужная инструментовка уже есть, потому что решение использует AgentCore Observability.

Чего в решении нет

Границы очерчены честно: это демонстрационная сборка на синтетическом наборе данных вымышленной велокомпании с заранее подготовленной JSON-схемой и Lambda-функцией валидации, которая сверяет данные с моковой базой ERP. Для своих документов схемы и логику проверки придётся заменить, а промпты агентов, написанные под терминологию заказов на покупку, — адаптировать: Orchestrator, Validator и Instructions содержат предметную лексику, привязанную к этому типу документа.

Под свои бизнес-правила предлагается собрать отдельный Lambda-валидатор — сверять ID поставщика и сходимость сумм для счетов, обязательные условия и даты для договоров, номера полисов и лимиты покрытия для страховых случаев — и зарегистрировать его как инструмент в AgentCore Gateway. В рекомендациях: загружать 5–10 документов каждого типа вместе с пограничными случаями, подключать валидаторы к справочным данным, следить за производительностью через AgentCore Observability и CloudWatch, добавлять типы документов постепенно, а перед продакшеном включать Amazon Bedrock Guardrails и учитывать OWASP Top 10 for LLMs и Generative AI Apps.

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

Где смотреть

Полный текст с диаграммами и кодом — в блоге AWS Machine Learning Blog; эталонная сборка агентной оркестрации обработки документов лежит в открытом репозитории AWS Samples aws-ai-intelligent-document-processing.