«Ответ возвращается быстрым, уверенным и неверным»: AWS заменила RAG извлечением полей агентами и аналитикой Amazon Quick

Где ломается RAG

Сценарий авторы описывают от лица директора по контрактам: на руках сотни, а то и тысячи договоров с поставщиками, в каждом зашиты суммы, даты истечения, статус подписания и контакты, а команда часами вытаскивает это из PDF в таблицы и отвечает на одни и те же вопросы — где мы тратим больше всего и какие договоры скоро истекают. Универсальные ИИ-чаты с этим справляются ровно до масштаба: один договор или несколько ещё работают, а сотни — уже нет. Причина в самом механизме: RAG режет текст на фрагменты и индексирует каждый отдельно, а на запросе достаёт только top-k самых похожих кусков, что нормально, когда ответ лежит в одном месте, и не работает, когда вопрос требует агрегации по всем документам сразу; авторы формулируют вывод жёстко — лучший промпт это не исправит, исправит другая архитектура.

Цифры делают проблему наглядной: 250 договоров по 10–20 страниц — это до 5 000 страниц неструктурированных данных, и аналитик, открывая каждый PDF вручную, тратит на расчистку завала больше недели ещё до прихода новых документов. Каждый уточняющий вопрос руководства запускает новый круг фильтрации, где легко опереться на устаревшие данные или сломать жёстко зашитые формулы. Если же загрузить портфель в популярный ИИ-чат и спросить общую сумму, ответ приходит быстро, уверенно и неверно. Это не случайность и не дефект конкретного инструмента: система по-прежнему возвращает только top-k фрагментов и суммирует только их — она не может сложить, посчитать или сравнить по всему портфелю, потому что портфель никогда не оказывается перед моделью.

Ключевая идея: сначала извлечение, потом запрос

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

Платформа — это React-приложение на AWS, которое превращает набор PDF- договоров в структурированные данные: ИИ-агенты извлекают ключевые поля и независимо их проверяют, разногласия по подписи разрешает Amazon Textract, а пользователи работают с результатом через встроенные дашборды и чат на естественном языке.

Пайплайн и двойная проверка

Договоры лежат в бакете Amazon S3, и загрузка файла сама запускает автоматический конвейер обработки. Агент извлечения на моделях серии Claude Sonnet читает PDF и достаёт восемь ключевых полей, каждое — с оценкой уверенности. Отдельный агент проверки на более лёгкой модели Claude Haiku независимо читает тот же PDF и проверяет извлечение, а если две модели расходятся в определении подписи, детерминированным арбитром выступает Amazon Textract с компьютерным зрением. Проверенные результаты попадают в Amazon Aurora PostgreSQL, пользователь видит статус конвейера в реальном времени по WebSocket и может сразу задавать вопросы через дашборды и чат. При типичных условиях весь конвейер обрабатывает договор за секунды, а бессерверная архитектура рассчитана на параллельную обработку множества договоров.

Агенты собраны на Strands Agent SDK и развёрнуты на AgentCore runtime — возможности Amazon Bedrock AgentCore, который берёт на себя серверный хостинг, автоматическое масштабирование и изоляцию сессий, так что для ИИ-компонентов инфраструктуру управлять не нужно. Сам AgentCore AWS описывает как полностью управляемый сервис для безопасного развёртывания и эксплуатации агентов в масштабе на любом фреймворке и модели, а Strands Agents SDK — открытый фреймворк с официальными примерами на GitHub. Поверх этого работает Policy in Amazon Bedrock AgentCore: политики на языке Cedar описывают границы доступа к операциям агентов, живут вне кода агента и проверяются автоматическим рассуждением до включения, так что агенты и пользователи видят только те договоры, на которые у них есть права. Это важно именно из-за чувствительности данных: в договорах лежат условия оплаты, финансовые обязательства и отношения с поставщиками.

Модели выбирали осознанно и по разным ролям. Claude Sonnet 4.6 используется для извлечения: он понимает документы, читает полный PDF нативно, без предварительного оптического распознавания символов (OCR), и возвращает структурированный JSON с оценками уверенности по каждому полю. Claude Haiku 4.5 используется для проверки: он быстрый и дешёвый и даёт независимый взгляд, а поскольку это другая модель с другим обучением, она ловит ошибки, которые повторный прогон той же модели пропустил бы. Логика двойной проверки проста: одна модель может уверенно выдать выдуманное значение, а расхождение двух независимых моделей — сильный сигнал к тому, что нужен человек.

Почему подпись решает Textract

Именно на этом месте авторы нашли показательный режим отказа: модель проверки иногда отмечала договор как подписанный с уверенностью 95–100 %, хотя подписи не было, и расходилась с агентом извлечения, который верно прочитал документ как неподписанный. Причина оказалась в том, что модель принимала за подпись само поле для неё — строку вида Signature: __________. Вместо того чтобы согласиться с галлюцинацией или писать изощрённые промпты в обход, в архитектуру добавили определение подписи средствами Amazon Textract: визуальный анализ вместо языкового понимания, который запускается только при расхождении двух моделей по полю is_signed и потому остаётся дешёвым. Общий вывод авторов: языковые модели — для понимания документов, извлечения полей и контекста, детерминированные сервисы — для визуальных элементов, точного подсчёта и математики.

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

Как отвечает Amazon Quick

Извлечения и проверки мало — людям нужно задавать вопросам данные, от общих сумм по портфелю до условий одного договора, и Amazon Quick сводит структурированные записи и исходные документы в один интерфейс: внутри возможность Amazon Quick Sight отвечает за дашборды, а запросы на естественном языке и чат — за вопросы обычными словами. Дашборды Quick Sight встроены прямо в React-приложение через Amazon Quick Sight Embedding SDK, так что аналитика доступна без экспорта и отдельных BI-инструментов, и данные при этом запрашиваются напрямую, без кэширования в SPICE, — дашборды всегда живые, и договор появляется в них сразу после обработки.

В дашборде три уровня: обзор с ключевыми показателями вроде числа договоров и их общей стоимости, диаграммой подписанных и неподписанных и таблицей извлечения с фильтрами; детали с оценками уверенности обоих агентов и пофайловым статусом совпадения полей; и затраты с разбивкой по сервисам, которая подчёркивает бессерверную природу архитектуры. Чат-агент внутри Amazon Quick подключается и к теме с данными, и к базе знаний документов, поэтому отвечает и на агрегатные вопросы, и на вопросы по конкретному документу: в примерах авторов — 20 договоров общей стоимостью 50 миллионов долларов, три истёкших на 3,7 миллиона, 17 подписанных против трёх неподписанных и подсказка по приоритету — неподписанные договоры с ближайшим истечением, отсортированные по стоимости. Статус конвейера в реальном времени по WebSocket авторы считают отдельным улучшением: непрозрачное «загрузил и жду» превращается в понятный процесс, где видно, какой сервис работает с документами, и это повышает доверие к многомодельной схеме.

Сколько это стоит

Решение почти целиком бессерверное, и основная стоимость — не вывод моделей, а лицензия Amazon Quick: при 1 000 договоров в месяц авторы насчитали 290 долларов на Amazon Quick с одним корпоративным пользователем и инфраструктурным сбором, 44 доллара на Amazon Aurora Serverless v2, 12 долларов на Amazon Bedrock за извлечение на Sonnet и проверку на Haiku, 2 доллара на Amazon Textract за арбитраж подписи и меньше доллара на AWS Lambda, Amazon API Gateway, Amazon S3 и Amazon CloudFront — итого около 349 долларов в месяц. Переменная часть составляет 0,014 доллара за договор на вывод моделей и распознавание, линейно растёт и остаётся пренебрежимой рядом с фиксированной лицензией на аналитику.

Что забирают с собой

Выводы авторов складываются в четыре правила: извлекай, потом спрашивай — для агрегатов по множеству документов ключевые поля вынимаются в структурную базу, поиск хорош в нахождении информации внутри документа, а база данных — в агрегации поверх них, и нужны оба; проверяй независимо — две разные foundation-модели ловят ошибки, которые одна пропустит, и стоимость второй, более дешёвой модели мала на фоне точности на ответственных данных; применяй детерминированные сервисы для детерминированных задач — там, где модель галлюцинирует подпись или пересчитывает элементы, нужен специализированный сервис, а не третья LLM; и делай ИИ видимым, потому что статус конвейера в реальном времени превращает непрозрачный процесс в понятный. Отдельно авторы оставляют место человеку: если две модели расходятся так, что детерминированный сервис спор не разрешает, договор нужно отправлять на проверку человеку, а не разрешать автоматически, — для этого у Amazon Quick есть центр задач с участием человека, где такие задачи становятся в очередь и отслеживаются. За пределами договоров та же схема применима там, где много неструктурированных документов и нужны вопросы по всему портфелю: закупки, юридический комплаенс, страховые случаи, онбординг-документы и договоры аренды.