«Проверили всё, и это можно доказать»: AWS показала шаблон Adjudicated Query для разбора десятков тысяч договоров аренды

Какую задачу решали

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

На малых объёмах договоры читает юрист, и ответу можно доверять, потому что за ним стоит человек; за некоторым порогом это перестаёт работать, и тогда отвечает число на экране, которое никто не может независимо проверить.

Из этой реальности следуют два обязательных свойства. Доказуемая полнота: утверждение «мы проверили все 22 910 договоров в Техасе» должно быть истинным и демонстрируемым, а запись, которую не оценивали, обязана попасть в отчёт как неоценённая, а не пропасть молча.

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

Именно эти два свойства отличают задачу от корпоративного поиска. Retrieval Augmented Generation (RAG) закрывает разрыв в доступности, но не даёт ни одного из них: у поиска по сходству нет порога, который означал бы «все», а ранжированная выборка не знает, что осталось за её пределами.

Text-to-SQL сокращает разрыв, но несёт риск целого класса: выдуманный предикат может молча сузить совокупность, и итоговое число выглядит точным, даже когда область неверна.

Как устроен шаблон

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

За границей слоя стоит движок правил: правила — это версионированные данные, а не код. Движок знает общие операторы сравнения (gte, lte, equals, exists) и не содержит ветки, называющей юрисдикцию или тему, так что изменение закона — это правка строки в книге правил, а не выкат кода.

Каждая проверка на соответствие порождает квитанцию полноты — утверждаемый инвариант, в котором compliant + in-breach + ambiguous + unreadable обязаны равняться числу просмотренных записей; инвариант считается по счётчикам и утверждается до того, как что-либо сохранится, а прогон, который не может отчитаться за свою совокупность, не завершается.

Разговорная поверхность несёт счётчики, квитанцию и помеченную выборку, тогда как полный результат — потенциально десятки тысяч строк — живёт на дашборде, читающем то же хранилище и разворачивающемся до отдельной записи; такое разделение не даёт модели «пересказать» гарантию.

Архитектура и опорные компоненты

Сотрудник по соответствию работает с двумя поверхностями Amazon Quick: чат-агентом для вопросов и дашбордом Amazon Quick Sight для просмотра полного набора результатов.

Чат-агент сначала получает OAuth-токен в Amazon Cognito, затем отправляет запросы Model Context Protocol (MCP) через Amazon API Gateway HTTP API, который проверяет токен и передаёт их в функцию AWS Lambda.

Lambda размещает MCP-сервер и движок правил, читает и пишет в Amazon Aurora Serverless v2 через RDS Data API и обращается к Amazon Bedrock только на пути исследовательского поиска по пунктам; дашборд Amazon Quick Sight читает то же хранилище Aurora напрямую через подключение к виртуальному частному облаку (VPC).

Обе поверхности читают одно хранилище — именно это делает квитанцию полноты единым источником правды.

Aurora Serverless v2 (Postgres + pgvector) хранит книгу правил, записи договоров, статус извлечения, определения и прогоны в одном реляционном хранилище, поэтому квитанция полноты — это SQL-подсчёт: недорогой способ сделать центральную гарантию проверяемой.

MCP-сервер реализован как JSON-RPC 2.0 поверх Streamable HTTP с кадрированием через Server-Sent Events, которое требует клиент Amazon Quick, а ограниченные операции транслируются в set-based SQL с привязкой значений правил как параметров — естественный язык до слоя запросов не доходит.

Amazon Bedrock питает только исследовательский путь, используя Amazon Titan Text Embeddings V2 (amazon.titan-embed-text-v2:0) для ранжирования по семантическому сходству и Anthropic Claude Sonnet 5 через кросс-региональный профиль вывода для качественной оценки пунктов; для официального определения о соответствии к нему не обращаются.

Автор отмечает, что доступность моделей Amazon Bedrock, включая Amazon Titan Text Embeddings V2 и Anthropic Claude Sonnet 5, различается по регионам AWS, поэтому перед развёртыванием нужно убедиться, что модели доступны в вашем регионе.

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

Правила, от которых не отступают

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

Естественный язык не доходит до SQL: операторы выбирают фиксированные SQL-шаблоны, а значения правил привязываются как параметры.

Детерминированное решение идёт перед ИИ: на проверке отвечает числовое сравнение, и модель не консультируют.

Точная фильтрация — для полноты, векторы — только для ранжирования, и сходство никогда не решает вопрос принадлежности к совокупности.

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

Нечитаемые документы называются, а не отбрасываются: каждый договор попадает ровно в одну корзину.

Находки — только append-only: путей UPDATE или DELETE против находок в кодовой базе не существует.

Модель как недоверенный рендерер

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

На практике наблюдались два случая: модель сняла префикс-оговорку — тег ILLUSTRATIVE был удалён при пересказе, и модель выдала выдуманную ссылку как норму закона. В другом случае модель экстраполировала по выборке: получив 20 строк предпросмотра, она вывела диапазон по всей совокупности, которого в данных не было.

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

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

И повторять метки режима на нескольких структурных уровнях — поле, строка, сводка, — чтобы хотя бы одна пережила пересказ; принцип в том, что защита в полезной нагрузке ровно настолько сильна, насколько она выживает при пересказе.

Развёртывание, стоимость и границы

Полная референсная реализация выложена на GitHub и поставляется с синтетическими данными, детерминированной генерацией корпуса и приёмочными тестами против развёрнутого стека.

Перед развёртыванием нужен аккаунт AWS с включённым доступом к моделям Amazon Bedrock для Amazon Titan Text Embeddings V2 и Anthropic Claude Sonnet 5 в регионе US East (N. Virginia) us-east-1, настроенный AWS CLI v2, Python 3.12 и Node.js 24 для AWS CDK.

Стек разворачивается командой npx aws-cdk@2.261.0 deploy: версия CDK зафиксирована под requirements.txt, а провижининг Aurora обычно занимает около 11 минут, хотя сроки зависят от аккаунта и региона.

Затем последовательно запускают миграцию схемы и книги правил с семью проверками, генерацию корпуса, загрузку с эмбеддингами, настройку дашборда и приёмочный набор из 28 проверок против живого стека; корпус детерминирован, поэтому пересобранный стек воспроизводит идентичные результаты.

Чтобы избежать постоянных затрат, стек уничтожают командой destroy. Aurora Serverless v2 умеет масштабироваться до 0 ACU и автоматически останавливаться после периода простоя, но в этом примере намеренно задана небольшая ненулевая минимальная ёмкость: остановленный кластер добавляет задержку возобновления к первому вопросу сессии. NAT gateway в стеке не разворачивается.

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

Отдельно оговорена атрибуция: Amazon Quick аутентифицируется к MCP-серверу машинно-машинно через двухзвенный поток client credentials, поэтому токен идентифицирует приложение Amazon Quick, а не конкретного человека, задавшего вопрос. В движке сохраняются решение, версия правила, доказательство, метод и дата, но идентичность пользователя туда не попадает — для части «кем» защитимости атрибуция живёт в слое аудита Amazon Quick, а находка связывается с человеком сопоставлением sweep ID и метки времени.

Если атрибуцию нужно хранить в самом хранилище соответствия, в разборе советуют протянуть идентификатор пользователя из Amazon Quick в вызов инструмента и сохранить его в строке прогона.

Когда шаблон подходит и когда это ошибка

Шаблон Adjudicated Query уместен, когда пропущенная запись — это ответственность, а не мелкое неудобство, когда ответ могут оспорить через месяцы те, кого не было в комнате, когда управляющая логика принадлежит внешней стороне и меняется по своему расписанию и когда совокупность записей можно перечислить.

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

RAG — более простой выбор, когда достаточно правдоподобных ответов и пользователь может переспросить; text-to-SQL хорошо работает для команд, которые могут проверять сгенерированные запросы и терпят отдельные неверные результаты; если ответственные пользователи согласны на дашборды без разговорного слоя, стоит взять движок правил плюс BI напрямую — это даёт ту же гарантию дешевле.

Есть и три случая, когда шаблон — ошибка. Если правила на самом деле не детерминированы — например, решение требует настоящего суждения, а не чистого сравнения вроде «пеня не выше предела», — шаблон спрячет субъективность внутрь авторства правил и заставит результат выглядеть точным, когда он таким не является, и для таких определений в разборе советуют оставлять человека в контуре.

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

И если сама совокупность размыта: квитанция доказывает охват каждой записи в совокупности, но не то, что совокупность правильна; когда определение «все техасские договоры» само спорно, гарантия точна относительно неверного знаменателя.