AWS показала RAG-конвейер для сложных документов на Textract и Bedrock

Raw-файлы оказались плохим входом для RAG

AWS разобрала задачу customer support, которому приходится искать сведения в тысячах коммунальных счетов. Многостраничные PDF, плотные таблицы и меняющаяся разметка мешают быстро находить account number, сумму, due date и инструкции по оплате. Первая версия решения загружала исходные документы прямо в RAG, но LLM пропускала важные поля, иногда выдавала неверные или нерелевантные ответы и нестабильно работала с разными форматами.

Вывод AWS практичен: retrieval не исправляет плохое представление документа автоматически. Если таблица распалась на несвязанные строки, заголовок потерял отношение к значению, а страница смешалась с декоративным текстом, модель получает неоднозначный контекст ещё до generation. Поэтому авторы ставят перед Amazon Bedrock отдельный processing layer на Amazon Textract, который извлекает structured и unstructured content, а затем очищает и обогащает результат.

Конвейер разделяет оригиналы, parsing и индексируемый текст

После развёртывания пользователь создаёт в S3 папку raw_files и загружает туда примеры счетов. Upload запускает Lambda document-parser, которая инициирует Textract jobs. Обработанные данные сохраняются в parsed_files, после чего вторая Lambda преобразует результат в TXT для каталога parsed_kb_documents. Только этот финальный слой синхронизируется с Amazon Bedrock Knowledge Bases.

Такое разделение оставляет наблюдаемый след каждой стадии. Оригинал можно сопоставить с извлечённым представлением, а представление — с документом, который попал в knowledge base. Если ответ неверен, команда может выяснить, где именно потерялось значение: во время OCR и разбора layout, при очистке, на этапе indexing или уже в generation. Монолитная схема «загрузить PDF и спросить модель» такой диагностики обычно не даёт.

CloudFormation собирает минимальную рабочую архитектуру

AWS публикует sample code и deployment script custom_kb_deployment_setup.sh. Скрипт создаёт CloudFormation stack с двумя Lambda functions, execution role и Lambda layer, S3 bucket, OpenSearch Serverless cluster, Amazon Bedrock Knowledge Base и отдельной IAM role для неё. После создания ресурсов остаётся загрузить файлы, выбрать data source и запустить Sync в консоли Bedrock.

Для проверки руководство предлагает Text Knowledge Base с моделью Amazon Nova Micro. Это демонстрационный выбор, а не утверждение, что одна модель оптимальна для любого document workflow. Качество зависит от структуры исходных файлов, способа chunking, полноты extracted fields и характера вопросов. Sample repository следует рассматривать как воспроизводимую стартовую точку, которую нужно измерять на собственных документах и критериях ответа.

Заявленная поддержка форматов требует осторожной проверки

Материал перечисляет PDF, DOCX, TXT, HTML, XLSX и PNG. Для PDF и PNG роль Textract понятна: сервис извлекает текст и элементы сложной разметки или изображения. Для остальных типов архитектура примера также обещает parsing, но production-команде важно проверить фактический путь каждого формата в опубликованном коде, ограничения сервисов и сохранение таблиц. Сам факт расширения файла ещё не доказывает одинаковую точность обработки.

Особенно это касается spreadsheet и документов со сложными embedded objects. Если ячейки, merged regions или визуальная иерархия превращаются в линейный TXT, retrieval может потерять связь между показателем и периодом. До масштабирования нужен набор контрольных вопросов с известными ответами: суммы, даты, account numbers, единицы измерения и ссылки на конкретную страницу или строку источника. Проверять следует не красоту ответа, а полноту и корректность извлечённых фактов.

Grounding необходимо проверять отдельно от безопасности

В разделе Responsible AI AWS рекомендует Bedrock Guardrails для фильтрации harmful content, denied topics и чувствительных данных, а также grounding validation, которая оценивает, поддерживается ли ответ найденными документами. Эти механизмы решают разные задачи: guardrail ограничивает допустимое содержание, но не гарантирует, что номер счёта или сумма действительно взяты из нужной страницы.

Для customer support полезен более строгий контракт ответа: каждое значимое поле должно сопровождаться ссылкой на document ID и локальный фрагмент, а низкая уверенность — переводить запрос человеку. В официальной статье нет опубликованных accuracy metrics, сравнения с raw-RAG baseline или данных о цене обработки тысячи страниц. Поэтому потенциальное улучшение скорости и точности остаётся целью архитектуры, а не универсально доказанным результатом для всех организаций.

Главный урок — сначала сделать документ машинно проверяемым

Предложение AWS полезно тем, что переносит внимание с prompt engineering на data preparation. Перед диалогом с knowledge base документы проходят extraction, cleaning, enrichment и преобразование в контролируемый текстовый слой. Для utility bills это позволяет явно сохранять таблицы и важные поля, а для других областей тот же принцип требует собственной схемы: договоры, отчёты и технические формы имеют разные единицы контекста.

Production-внедрение должно добавить то, чего нет в walkthrough: шифрование и retention policy, least-privilege IAM, мониторинг failed Textract jobs, управление версиями parsed documents, тестовый corpus и бюджетные лимиты OpenSearch, Lambda, Textract и Bedrock. Сам sample уже задаёт правильную последовательность — original → extraction → normalized corpus → retrieval → answer. Надёжность появится тогда, когда каждая стрелка получит readback, метрику качества и понятный путь ручной проверки.