«Ответ со ссылкой на источник»: AWS показала диалогового помощника по страховым случаям на Amazon Bedrock Knowledge Bases

Что показала AWS

30 сентября 2026 года Amazon Web Services опубликовала в блоге Machine Learning материал «Query claims in natural language with Amazon Bedrock Knowledge Bases» — технический разбор, а не пресс-релиз о новом продукте. Авторы материала — Шрея Паваскар (Shreya Pawaskar), консультант по доставке AI/ML в AWS Professional Services, и Абхишек Шарма (Abhishek Sharma), старший архитектор решений AWS.

Задача сформулирована бытовым примером: ответы по страховому случаю разбросаны по дневниковым записям оценщика, сметам на ремонт, полицейским протоколам, платёжным регистрам и сканам вложений, а не лежат в одном поле. Клиент спрашивает, утверждена ли смета по случаю CLM-100482; оценщику нужны все открытые «авто»-случаи дороже 10 000 долларов, заведённые в прошлом месяце. Обе задачи требуют быстро найти и свести доказательства.

На этом разборе AWS строит диалогового помощника, который отвечает с цитатами: загружает документы и метаданные из Amazon Simple Storage Service (Amazon S3), ищет обычным языком через AgenticRetrieveStream, поддерживает уточняющие вопросы в многоходовом диалоге, сужает поиск фильтрами по метаданным (номер и тип случая) и добавляет проверку контекстного заземления (contextual grounding) через Amazon Bedrock Guardrails.

Ключевая оговорка прописана в самой публикации: разбор использует синтетические записи о случаях и не описывает боевое внедрение у реального заказчика. AWS прямо просит не размещать настоящие персональные данные (PII) и защищённые медицинские сведения в этих ресурсах без нужных контролей и согласований.

Как устроен конвейер

Схема делится на две полосы. Полоса загрузки (ingestion) принимает документы в форматах PDF, Word и текстовых заметок в S3 вместе с сопроводительными файлами метаданных; задание синхронизации связывает источник данных S3 с базой знаний по мере изменения документов; база знаний сама разбирает документы, разбивает их на фрагменты, считает эмбеддинги и индексирует содержимое вместе с метаданными в управляемом векторном хранилище.

База знаний создаётся управляемой: в конфигурации задаются type = MANAGED и embeddingModelType = MANAGED, а модель эмбеддингов выбирает и обслуживает сам Amazon Bedrock — настраивать векторное хранилище вручную не требуется.

К каждому документу кладётся файл метаданных с тем же именем и суффиксом.metadata.json: для CLM-100482.pdf — CLM-100482.pdf.metadata.json. Боковой файл допускает только скалярные строки, числа и булевы значения, ограничен 10 КБ, и именно его типы определяют доступные фильтры: claim_id строкой для точного поиска одного случая, claim_type — для линии бизнеса, amount — числом для сравнений по диапазону, date_filed — числом в формате YYYYMMDD, region и customer_id — для привязки к арендатору и клиенту.

Два правила по метаданным названы прямо. Даты хранят целыми в формате YYYYMMDD, потому что фильтры сравнивают числа, а не строки, — так работают диапазоны вида «заведено в прошлом месяце». И только одно сопоставимое денежное значение держат в поле amount: резервы, платежи и удержания остаются в тексте документа, чтобы их ярлыки не смешались между собой.

Что даёт AgenticRetrieveStream

В полосе поиска приложение вызывает AgenticRetrieveStream с вопросом, историей диалога и необязательными фильтрами по метаданным. Фундаментальная модель формирует подзапросы и повторяет поиск, пока доказательств не станет достаточно, — в пределах maxAgentIteration раундов; затем проверка контекстного заземления блокирует ответы, не подтверждённые найденными записями.

Ретриверов можно указать до пяти баз знаний; у каждого — свой фильтр по метаданным и лимит maxNumberOfResults в диапазоне от 1 до 100, который повышают для вопросов, охватывающих много случаев. Конфигурация agenticRetrieveConfiguration задаёт модель планирования: MANAGED для сервисной модели или CUSTOM с ARN конкретной модели.

API транслирует события потоком. Событие traceEvent отдаёт план поиска, шаги, расширение до полного документа, действия проверок, статус и сгенерированные подзапросы; событие result содержит дедуплицированные результаты, а при generateResponse = True — полный ответ и его цитаты. Каждая цитата указывает диапазон символов внутри ответа и ссылается на записи в результатах, поэтому приложение может показать, откуда взялся каждый фрагмент.

Фильтры применяются до семантического поиска. Поддерживаются операторы equals, notEquals, числовые сравнения, in, notIn, stringContains, listContains и логические andAll/orAll; startsWith ограничен векторными хранилищами Amazon OpenSearch Serverless. Если фильтр не вернул документов, AWS советует вернуть понятное «ничего не найдено» вместо сгенерированного ответа.

Что измерено и с какими оговорками

AWS приводит замеры на синтетическом корпусе из 30 документов и наборе из 40 вопросов: прямые поиски, сравнения, псевдонимы, заменённые записи, развёрнутые платежи и текст, похожий на инструкции внутри документов.

Результаты такие: на все 40 вопросов дан ответ, у всех 40 ответов есть цитаты, в среднем 3,9 цитаты на ответ, полнота поиска по ожидаемым источникам (expected-source retrieval recall) — 90,5 %, полнота цитирования ожидаемых источников — 81,2 %, а фрагментов, противоречащих заданному фильтру, — ноль. На 20 состязательных вопросах полнота поиска составила 96,7 %, полнота цитирования — 90,2 %; модель удержала похожие по названию компании раздельно, сохранила утверждение как утверждение и проигнорировала текст, похожий на инструкцию, во вложении.

Оговорки AWS называет там же. Замеры сделаны вызовами Retrieve и RetrieveAndGenerate, а не AgenticRetrieveStream, поэтому это базовая линия именно для этого корпуса и схемы метаданных, а не бенчмарк агентного поиска. Оценку фактов делала автоматическая проверка фундаментальной моделью, то есть результаты ориентировочные. Полнота цитирования не гарантирует полноту ответа, поэтому её нужно мерить отдельно. Узкие вопросы по конкретному случаю показали лучшие результаты, а широкие вопросы-инвентаризации без фильтра — три самых слабых. Перед выводами к страхователям AWS просит провести человеческую проверку на своём корпусе.

Безопасность, заземление и границы

Фильтры по метаданным AWS предлагает трактовать как границу доступа: выделять region или customer_id из аутентифицированной сессии на сервере, объединять их с поисковыми фильтрами через andAll и никогда не принимать эту границу из текста пользователя. Для контроля доступа служит и поле userContext.

Набор прав IAM перечислен по действиям: bedrock:AgenticRetrieveStream, bedrock:Retrieve и bedrock:GetDocumentContent для базы знаний, bedrock:InvokeModelWithResponseStream, а также bedrock:GetGuardrail и bedrock:ApplyGuardrail. Вызовы записываются в AWS CloudTrail; объекты в S3 шифруются по умолчанию, и для бакета и управляемого векторного хранилища можно использовать управляемые заказчиком ключи AWS KMS; трафик API идёт по TLS.

Заземление обеспечивает проверка контекстного заземления Amazon Bedrock Guardrails по двум осям: согласованность с найденными документами (grounding) и соответствие вопросу пользователя (relevance). В примере выставлены пороги 0,85 для grounding и 0,75 для relevance; более высокие пороги блокируют больше ответов, а в контуре страховых случаев отказать безопаснее, чем выдать неподтверждённое. Поддерживается действие BLOCK: проваленная проверка блокирует ответ, а событие трассировки фиксирует вмешательство.

Последняя граница — человек. AWS прямо советует оставить человека в контуре, чтобы тот проверял процитированные доказательства и принимал итоговое решение по случаю. Разбор заканчивается тем же паттерном для андеррайтинга и документации по обслуживанию полисов, а регион в примере — US West (Орегон), us-west-2.