ИИ спрашивает, правила решают: схема Adjudicated Query от AWS

AWS опубликовал в блоге по машинному обучению пять разборов.

Два из них, о проверке договоров аренды и о веб-поиске для Claude Desktop, описывают одну схему.

Мы в KT.Team строим ИИ-интеграции по той же логике: в регулируемых процессах это самый надёжный из известных нам способов довести модель до продакшена.

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

Модель переводит вопрос в запрос к движку правил. Движок выносит

Языковая модель вероятностна: два прогона одного и того же договора могут дать два разных ответа. Для черновика рассылки это допустимо, для комплаенса нет. Проверяющий спросит, почему договор признан соответствующим, и ответ «так решила модель» не примет.

Ему нужен воспроизводимый след: версия правила, поле договора, значение, результат. Вторая проблема в полноте. Фраза «мы проверили все договоры»

имеет смысл, только если есть реестр договоров и у каждой строки стоит статус. RAG такой гарантии не даёт: поиск по устройству возвращает несколько самых похожих фрагментов. Договор, который не попал в выборку, останется непроверенным, и модель об этом не сообщит. Третья проблема в цене ошибки. Ложное «соответствует» в договоре аренды оборачивается штрафом или иском. Отвечать за него будет руководитель, который запустил систему без детерминированного слоя.

Здесь решение принимает машина, и это оправдано: ошибка стоит одного неудачного показа, а результат сразу виден в конверсии. Отсюда практическое правило.

Если ошибку дёшево исправить и её видно в метрике, решение можно отдать модели.

Если ошибку дорого исправлять и её придётся объяснять внешнему проверяющему, модель остаётся интерфейсом, а решает код.