azure ai-foundry multi-agent claims insurance observability

Тріаж страхових заяв від кількох агентів у Microsoft Foundry

Тріаж страхових заяв у Microsoft Foundry: координатор, який керує питаннями страхування, агенти з боротьби з шахрайством та врегулювання справ, контрольні точки, App Insights та хостинг Container Apps.

Видавець: REACTAPP.TOPДодано на сайт 26 вер. 2026 р.13 хв читання2993 слів

Джерела: AZURE AI: Multi-agent claims triage on Microsoft Foundry

Уявіть собі страхову компанію, яка щодня отримує тисячі нових заявок через веб-форми та телефонні лінії. Перед виплатою важливі три фактори: страховий покриття на дату інциденту, сигнали про шахрайство, які веде команда SIU, та діапазон виплати на основі оцінки збитків. Ручний послідовний перегляд є повільним. Метод триажу з використанням кількох агентів, що працює на платформі Foundry, дозволяє одночасно обробляти заявки фахівцями, залишаючи людей для розгляду винятків.

Використані інструменти

Розгортання моделей Azure AI Foundry, фреймворк агентів/оркестрації з передачею завдань, функція контрольних точок для стабільної роботи, Application Insights для відстеження процесів та Container Apps з керованою ідентичністю для розгортання.

Попередні вимоги

Підписка на Azure з доступом до Foundry, можливість розгортання контейнерних додатків, робоче простір App Insights та зразки даних заявок для тестування.

Архітектура проєкту

Агент-координатор розподіляє завдання між трьома спеціалістами (контроль покриття, боротьба з шахрайством, врегулювання справ). Інструменти об’єднують функції пошуку полісів, перевірки списків шахрайств та правил класифікації. Точки контролю зберігають стан заявки на протязі всього процесу. Телеметрія фіксує кожну передачу даних.

Крок 1. Створіть ресурс Foundry та розгорніть моделі

Підготуйте проект та розгорніть моделі чату, якими будуть користуватися агенти. Ретельно записуйте назви розгортань.

Крок 2. Встановіть фреймворк та налаштуйте клієнта чату для роботи з Foundry

az group create \
  --name rg-claims-prod-uks \
  --location uksouth

az cognitiveservices account create \
  --name fdy-claims-prod-uks \
  --resource-group rg-claims-prod-uks \
  --location uksouth \
  --kind AIServices \
  --sku S0 \
  --assign-identity

az cognitiveservices account deployment create \
  --name fdy-claims-prod-uks \
  --resource-group rg-claims-prod-uks \
  --deployment-name gpt-4o \
  --model-name gpt-4o \
  --model-version 2024-08-06 \
  --model-format OpenAI \
  --sku-capacity 200 \
  --sku-name GlobalStandard

az cognitiveservices account deployment create \
  --name fdy-claims-prod-uks \
  --resource-group rg-claims-prod-uks \
  --deployment-name gpt-4o-mini \
  --model-name gpt-4o-mini \
  --model-version 2024-07-18 \
  --model-format OpenAI \
  --sku-capacity 400 \
  --sku-name GlobalStandard

python -m venv .venv
source .venv/bin/activate
pip install agent-framework azure-monitor-opentelemetry azure-identity azure-cosmos

# claims/clients.py
import os
from azure.identity import DefaultAzureCredential
from agent_framework.azure import AzureOpenAIChatClient

credential = DefaultAzureCredential()

coordinator_client = AzureOpenAIChatClient(
    endpoint=os.environ["FOUNDRY_ENDPOINT"],
    deployment_name="gpt-4o",
    credential=credential,
)

specialist_client = AzureOpenAIChatClient(
    endpoint=os.environ["FOUNDRY_ENDPOINT"],
    deployment_name="gpt-4o-mini",
    credential=credential,
)

# claims/agents.py
from claims.clients import coordinator_client, specialist_client

coordinator = coordinator_client.create_agent(
    name="triage",
    instructions=(
        "You are the first-line claims triage officer for a UK motor insurer. "
        "Read the claim and decide which specialist should handle it next. "
        "Route to 'policy_agent' when cover or policy dates are in question. "
        "Route to 'fraud_agent' when the description contains any indicator of "
        "staged loss, late notification, or inconsistent detail. "
        "Route to 'settlement_agent' when cover is confirmed and only the payout "
        "figure remains. Call the matching handoff tool, for example "
        "handoff_to_fraud_agent. Never state a settlement figure yourself."
    ),
)

policy_agent = specialist_client.create_agent(
    name="policy_agent",
    instructions=(
        "You verify whether the policy was in force on the incident date and "
        "whether the peril is covered. Use the lookup_policy tool. State the "
        "cover position plainly and cite the policy section. If cover is void, "
        "say so and stop; do not speculate on settlement."
    ),
)

fraud_agent = specialist_client.create_agent(
    name="fraud_agent",
    instructions=(
        "You score claims against the SIU signal list using the score_fraud_signals "
        "tool. Report each signal that fired and the aggregate score. Any score at "
        "or above 0.6 must be handed to policy_agent for a cover check before it "
        "goes anywhere near settlement."
    ),
)

settlement_agent = specialist_client.create_agent(
    name="settlement_agent",
    instructions=(
        "You band the damage estimate and propose a settlement using the "
        "band_settlement tool. Anything above 15000 GBP must be flagged for human "
        "authorisation in your response. Never approve a payment."
    ),
)

# claims/workflow.py
from agent_framework import HandoffBuilder
from claims.agents import coordinator, policy_agent, fraud_agent, settlement_agent

def build_triage_workflow():
    return (
        HandoffBuilder(
            name="claims_triage",
            description="Motor claims triage: cover, fraud signals, settlement banding.",
            participants=[coordinator, policy_agent, fraud_agent, settlement_agent],
        )
        .set_coordinator(coordinator)
        .add_handoff(coordinator, [policy_agent, fraud_agent, settlement_agent])
        .add_handoff(fraud_agent, policy_agent)
        .add_handoff(policy_agent, settlement_agent)
        .with_interaction_mode("autonomous", autonomous_turn_limit=12)
        .with_termination_condition(
            lambda conv: any(
                "AUTHORISATION REQUIRED" in (msg.text or "")
                for msg in conv[-2:]
            )
        )
        .build()
    )

# claims/tools.py
from typing import Annotated
from datetime import date
import httpx

POLICY_API = "https://pas.internal.claims-leeds.co.uk/v2"

async def lookup_policy(
    policy_number: Annotated[str, "The policy number, format MOT-00000000"],
    incident_date: Annotated[str, "Incident date as YYYY-MM-DD"],
) -> dict:
    """Return cover status and policy sections in force on the incident date."""
    async with httpx.AsyncClient(timeout=10.0) as client:
        r = await client.get(
            f"{POLICY_API}/policies/{policy_number}/cover",
            params={"as_at": incident_date},
        )
        r.raise_for_status()
        return r.json()

SIU_SIGNALS = {
    "late_notification_days": 14,
    "no_police_reference": True,
    "prior_claims_12m": 2,
}

def score_fraud_signals(
    description: Annotated[str, "Free-text claim description"],
    notified_after_days: Annotated[int, "Days between incident and notification"],
    prior_claims_12m: Annotated[int, "Claims by this policyholder in last 12 months"],
) -> dict:
    """Score a claim against the SIU signal list. Returns fired signals and aggregate."""
    fired = []
    if notified_after_days > SIU_SIGNALS["late_notification_days"]:
        fired.append("late_notification")
    if prior_claims_12m >= SIU_SIGNALS["prior_claims_12m"]:
        fired.append("claim_frequency")
    if "no witnesses" in description.lower():
        fired.append("no_independent_witness")
    return {"signals_fired": fired, "score": round(len(fired) / 3, 2)}

def band_settlement(
    estimate_gbp: Annotated[float, "Repair or replacement estimate in GBP"],
) -> dict:
    """Band an estimate and return the proposed settlement and authorisation route."""
    if estimate_gbp <= 2500:
        return {"band": "A", "proposed_gbp": estimate_gbp, "route": "auto"}
    if estimate_gbp <= 15000:
        return {"band": "B", "proposed_gbp": estimate_gbp, "route": "team_leader"}
    return {"band": "C", "proposed_gbp": estimate_gbp, "route": "AUTHORISATION REQUIRED"}

policy_agent = specialist_client.create_agent(
    name="policy_agent",
    instructions="...",
    tools=[lookup_policy],
)

fraud_agent = specialist_client.create_agent(
    name="fraud_agent",
    instructions="...",
    tools=[score_fraud_signals],
)

settlement_agent = specialist_client.create_agent(
    name="settlement_agent",
    instructions="...",
    tools=[band_settlement],
)

# claims/checkpoints.py
from agent_framework import InMemoryCheckpointStorage

# Tests and local runs
storage = InMemoryCheckpointStorage()

workflow = build_triage_workflow_with_storage(storage)

async for event in workflow.run_stream(claim_text, session_id=claim_id):
    handle(event)

# claims/telemetry.py
import os
from azure.monitor.opentelemetry import configure_azure_monitor
from agent_framework.observability import enable_instrumentation

def init_telemetry() -> None:
    configure_azure_monitor(
        connection_string=os.environ["APPLICATIONINSIGHTS_CONNECTION_STRING"],
    )
    enable_instrumentation()

dependencies
| where timestamp > ago(24h)
| where name startswith "invoke_agent"
| extend agent = tostring(customDimensions["gen_ai.agent.name"])
| extend claim = tostring(customDimensions["session.id"])
| summarize
    hops = count(),
    total_ms = sum(duration),
    p95_ms = percentile(duration, 95)
    by agent
| order by total_ms desc

# claims/run.py
import asyncio
from agent_framework import RequestInfoEvent
from claims.telemetry import init_telemetry
from claims.workflow import build_triage_workflow

CLAIM = """
Claim MOT-40118822. Policy MOT-00318844, incident 2026-07-29, notified 2026-08-19.
Insured reports offside wing and door damage in a supermarket car park, no witnesses,
no police reference. Third party details not supplied. Estimate 3,180 GBP.
"""

async def main() -> None:
    init_telemetry()
    workflow = build_triage_workflow()

    async for event in workflow.run_stream(CLAIM, session_id="MOT-40118822"):
        if isinstance(event, RequestInfoEvent):
            # Autonomous mode only surfaces this on escalation
            print(f"HUMAN NEEDED: {event.data.prompt}")
            break
        print(event)

asyncio.run(main())

az identity create \
  --name umi-claims-triage \
  --resource-group rg-claims-prod-uks

PRINCIPAL=$(az identity show -n umi-claims-triage -g rg-claims-prod-uks --query principalId -o tsv)
CLIENT=$(az identity show -n umi-claims-triage -g rg-claims-prod-uks --query clientId -o tsv)
FOUNDRY=$(az cognitiveservices account show -n fdy-claims-prod-uks -g rg-claims-prod-uks --query id -o tsv)

az role assignment create \
  --role "Azure AI User" \
  --assignee-object-id $PRINCIPAL \
  --assignee-principal-type ServicePrincipal \
  --scope $FOUNDRY

az containerapp create \
  --name ca-claims-triage \
  --resource-group rg-claims-prod-uks \
  --environment cae-claims-prod-uks \
  --image acrclaimsproduks.azurecr.io/claims-triage:1.0.0 \
  --user-assigned umi-claims-triage \
  --min-replicas 1 \
  --max-replicas 8 \
  --cpu 1.0 \
  --memory 2.0Gi \
  --env-vars \
    FOUNDRY_ENDPOINT=https://fdy-claims-prod-uks.openai.azure.com/ \
    AZURE_CLIENT_ID=$CLIENT \
    ENABLE_INSTRUMENTATION=true \
    OTEL_SERVICE_NAME=claims-triage \
    APPLICATIONINSIGHTS_CONNECTION_STRING=secretref:appi-conn

az group delete \
  --name rg-claims-prod-uks \
  --yes \
  --no-wait

az containerapp delete \
  --name ca-claims-triage \
  --resource-group rg-claims-prod-uks \
  --yes

az cognitiveservices account deployment delete \
  --name fdy-claims-prod-uks \
  --resource-group rg-claims-prod-uks \
  --deployment-name gpt-4o-mini

Налаштуйте кінцеву точку, розгортання та автентифікацію через Entra/managed identity — уникайте включення API-ключів до зображень контейнерів.

Крок 3. Визначте координатора та трьох спеціалістів

Надайте кожному спеціалісту чіткі інструкції та набір інструментів. Координатор лише направляє завдання та об’єднує інформацію; він не повинен повторно реалізовувати логіку спеціалістів.

Крок 4. Сконфігуруйте схему передачі завдань

Чітко визначені канали передачі завдань кращі за хаотичний набір інструментів. Логіка «Покриття → Мошенництво → Врегулювання» є розумним стандартом; дозвольте швидку передачу завдань до SIU, коли рівень мошенництва різко зростає.

Крок 5. Надайте спеціалістам справжні інструменти

Інструменти мають підключатися до реальних систем або до точних їх копій із відповідними схемами. Фальшиві інструменти, які завжди «схвалюють», нічого не допомагають у навчанні.

Крок 6. Створіть точку контролю, щоб після перезапуску не було втрати поточної заявки

Зберігайте стан потоку/заявки після роботи кожного спеціаліста. Перезапуск контейнера під час обробки заявки має продовжити її обробку, а не призвести до подвійної оплати.

Крок 7. Надсилайте логи та показники до Application Insights

Випускайте користувацькі події для передачі даних, затримки інструментів та кінцевого етапу обробки. Панелі керування мають відображати середнє значення часу обробки порівняно з ручним базовим показником.

Крок 8. Пройдіть обробку заявки та прочитайте результат

Використовуйте ідеальну заявку з відомим рівнем страхового покриття та результатами перевірки на шахрайство. Переконайтеся, що кінцевий пакет координатора містить усі три результати спеціалістів.

Крок 9. Розгорніть на Container Apps з керованою ідентичністю

Надайте права цій ідентичності для розгортання в Foundry та для будь-яких API-сервісів, до яких звертаються інструменти. Забезпечте строгий контроль входу.

Усунення проблем

Порожній вихід даних від спеціалістів зазвичай означає неправильну назву розгортання або скорочений JSON-файл інструменту. Цикли часто виникають через відсутність умов завершення передачі даних. Помилки автентифікації пов’язані з RBAC, а не з тим, що „модель не працює“.

Витрати на роботу цього рішення

Модельні токени домінують; зберігання чекпоїнтів та дані App Insights є відносно невеликими. Встановіть максимальну кількість ходів за заявкою та обмеження для пошуків у кеші.

Очищення

Видаліть контейнерні додатки, ідентичності та розгортання, які ви створили під час демонстрації, щоб ресурси для демо не залишалися у рахунку.

Закінчення

Система сортування заявок багатьма агентами працює ефективно, коли спеціалісти мають вузьку сферу компетенцій, інструменти є реальними, чекпоїнти стабільними, а телеметрія підтверджує перевагу низької затримки. Foundry забезпечує основу для моделі; граф та правила операцій створюють кінцевий продукт.

Додайте етап людського схвалення для сум, що перевищують певний поріг. Агенти повинні прискорювати процес сортування, а не мовчки схвалювати великі виплати.

Правила щодо шахрайства з версіями слід визначати окремо від запитів до моделей. Коли SIU оновлює список сигналів, не потрібно змінювати запити, щоб це врахувати — інструменти мають читати поточний список.

Протестуйте навантаження на одночасні запити щодо обмежень швидкості у реалізації Foundry. Має бути визначена поведінка при переповненні черги: відхилення, затримка чи перехід на ручний режим.

Приватність: текст запитів є конфіденційним. Переконайтеся, що журнали містять замасковані дані PAN/SSN, а функція вибірки даних у App Insights не зберігає сирі персональні дані у спеціальних вимірах.

Зберігайте тест на створення хаосу, який зупиняє контейнер під час обробки запиту та перевіряє можливість продовження роботи з попереднього стану без дублювання ефектів від інструментів — ключі ідемпотентності під час запису є обов’язковими.

Додайте етап людського схвалення для сум виплат, які перевищують певний поріг. Агенти повинні прискорювати процес сортування запитів, а не мовчки схвалювати великі виплати.

Правила боротьби з підробками версій слід тримати окремо від параметрів моделей. Коли SIU оновлює список сигналів, не повинно бути потреби змінювати параметри моделі, щоб це врахувати — інструменти мають читати поточний список.

Протестуйте одночасні запити щодо обмежень швидкості у реєнтрації Foundry. Має бути визначена поведінка при переповненні черги: відхилення, затримка чи перехід на ручний режим.

Приватність: текст запитів є конфіденційним. Переконайтеся, що журнали містять замасковані дані PAN/SSN, а функція вибірки App Insights не зберігає сирі персональні дані у спеціальних вимірах.

Проводьте тести хаосу, які зупиняють контейнер під час обробки запиту та перевіряють можливість продовження роботи з точки контролю без дублювання побічних ефектів інструменту — ключі ідемпотентності під час запису є обов’язковими.

Інструкції для фахівців мають забороняти вигадування положень правил. Якщо інструмент аналізу покриття повертає порожній результат, фахівець мусить передати справу на вищий рівень — а не припускати, що „ймовірно все покрито“.

Встановіть перевірку схеми для аргументів інструменту. Неправильно введений ідентифікатор запиту має призводити до невдачі виклику інструменту, перш ніж це стане причиною хибних висновків у звіті.

Розділяйте інструменти для читання від інструментів для запису. Агенти для триажу за замовчуванням мають режим лише для читання; записи для врегулювання вимагають схвалення та ключа ідемпотентності.

Пов’язуйте помилки Application Insights із конкретними діями: при різкому збільшенні кількості запитів щодо тайм-аутів інструментів боротьби з шахрайством відповідальність за розв’язання мають нести власники інтеграції SIU, а не команда платформи LLM за замовчуванням.

Зберігайте синтетичні заявки у наборі фікстур, який включає крайні випадки: закінчення терміну дії поліса, межові значення оцінки шахрайства та інциденти з кількома транспортними засобами, що створюють навантаження на механізми маршрутизації.

Під час демонстрації керівництvu покажіть ланцюг відстеження для однієї заявки. Головною темою є оркестрація процесів та механізми контролю, а не назви моделей.

У спеціалізованих запитах має бути заборона на вигадування положень поліса. Якщо інструмент оцінки покриття повертає порожній результат, спеціаліст зобов’язаний підняти справу на вищий рівень — а не припускати, що покриття існує.

Встановіть перевірку схеми для аргументів інструменту. Неправильно введений ідентифікатор претензії має призвести до невдачі виклику інструменту, перш ніж це стане хибною інформацією в звіті розслідування.

Розділіть інструменти для читання від інструментів для запису. Агенти для триажу за замовчуванням мають лише право на читання; записи для врегулювання вимагають схвалення та ключа ідемпотентності.

Пов’язуйте збої у Application Insights із конкретними діями: різкий зростання кількості випадків перевищення тайм-ауту інструментів боротьби з шахрайством має потрапляти до відповідальних осіб за інтеграцію SIU, а не до команди платформи LLM за замовчуванням.

Зберігайте синтетичні претензії у наборі тестових даних, який включає крайні випадки: претензії з закінченим терміном дії полісу, претензії з межовим рівнем шахрайства та інциденти з кількома транспортними засобами, що створюють навантаження на механізми маршрутизації.

Під час демонстрації керівництву покажіть ланцюг відстеження для однієї претензії. Головною темою є оркестрація процесів та механізми контролю, а не назви моделей.

Спеціалісти повинні забороняти створення умов полісу з голосових запитів. Якщо інструмент аналізу повертає порожній результат, спеціаліст має передати справу на вищий рівень — а не припускати, що страхування, ймовірно, діє.

Встановіть перевірку схеми для аргументів інструменту. Неправильно введений ідентифікатор претензії має призвести до невдачі виклику інструменту, перш ніж це стане підставою для хибних висновків у звіті.

Розділіть інструменти для читання від інструментів для запису. Агенти з триажем за замовчуванням мають лише право на читання; записи для врегулювання вимагають схвалення та ключа ідемпотентності.

Пов’язуйте збої у Application Insights із конкретними діями: різкий зростання кількості випадків перевищення тайм-ауту інструменту боротьби з шахрайством має потрапляти до відповідальних осіб з інтеграції SIU, а не до команди платформи LLM за замовчуванням.

Зберігайте синтетичні претензії у наборі тестових даних, який включає крайні випадки: закінчення терміну дії поліса, межові показники ризику шахрайства та інциденти з кількома транспортними засобами, що створюють навантаження на механізми маршрутизації.

Під час демонстрації керівництву покажіть детальний аналіз однієї заявки. Головне — це організація процесу та механізми контролю, а не назви брендів моделей.

Інструкції для фахівців мають забороняти вигадування положень страхових умов. Якщо інструмент аналізу повертає порожні дані, фахівець зобов’язаний передати справу на вищий рівень, а не припускати, що заявка, ймовірно, покривається.

Встановіть перевірку схеми для аргументів інструменту. Неправильно введений ідентифікатор заявки має призводити до невдачі виклику інструменту, перш ніж це стане причиною хибних висновків у звіті.

Розділіть інструменти для читання від інструментів для запису. Агенти з обробки заявок за замовчуванням мають лише право на читання; записи щодо врегулювання вимагають схвалення та ключа ідемпотентності.

Пов’язуйте помилки Application Insights із конкретними діями: при різкому збільшенні кількості випадків перевантаження інструменту боротьби з шахрайством перш за все мають втрутитися власники інтеграції SIU, а не команда платформи LLM за замовчуванням.

Зберігайте синтетичні заявки в пакеті налаштувань, який включає крайні випадки: поліс, що закінчив термін дії, оцінку шансів на шахрайство на межі та інциденти з кількома транспортними засобами, що створюють навантаження на маршрутизацію.

Під час демонстрації керівництву покажіть детальний аналіз однієї заявки. Головне — це організація процесів та механізми контролю, а не назви брендів моделей.

← Усі статті Надіслати бриф