第 15 章：理赔、金融犯罪与风险评估——Insurance claims / Financial crime / Risk assessment

这一章把三个高风险的行业放在一起，因为它们的判定结构是同一条链：先核验证据是否齐全、再看有没有危险信号、最后把多个维度的判断聚合成一个风险分与处置建议。它们也是最需要"可解释、可审计、可回退"的场景——每一次自动判定背后都可能牵涉一个人的理赔、一笔资金的安全。本章用真实项目讲清这条链怎么搭，也坦白哪些环节还只有通用做法。

三个场景，一条判定链

官方 use-case-map 把理赔、金融犯罪、风险评估列为相邻的行业用例，原因就是它们共享同一副骨架：

flowchart TB
    S["非结构化材料
理赔单 / 交易流水 / 对手方资料"] --> G1["证据门（Noul）
材料是否齐全、是否存在"]
    G1 --> G2["信号检测（Noul / Choice）
损伤类型 / 可疑行为 / 名单命中"]
    G2 --> G3["维度打分（Score）
风险等级 / 欺诈强度 / 行为异常度"]
    G3 --> R["硬规则否决
（代码，最高优先级）"]
    R --> AGG["代码聚合 → 风险分 + 处置建议"]
    AGG --> ACT["放行 / 转人工 / 拦截（可回退）"]

关键在于分工：模型只负责那些"规则写不动、只能靠语义"的判断（这份材料像不像造假、这笔转账像不像洗钱），而所有硬约束和最终动作留给代码。这条边界在下文每个项目里都会反复出现。

理赔：材料核验与分类

理赔链路的第一步不是"赔多少"，而是材料够不够、损伤属于哪类、有没有欺诈信号。这三件事分别对应 Noul、Choice 和 Noul。

需要说明的是：在本章读取的社区分类里，理赔方向还没有出现高星的专门开源项目，因此下面给的是一套通用的落地做法（官方用例要点 + 示例代码），而不是某个具体项目的实现。

from typesafe import TypesafeClient

client = TypesafeClient()

def screen_claim(claim_text: str, docs: str) -> dict:
    d = client.systemone(
        state=f"【理赔申请】\n{claim_text}\n\n【提交材料】\n{docs}",
        questions={
            "complete": {"type": "noul",
                "question": "申请材料是否齐全：保单信息、事故说明、必要凭证均已提供？"},
            "damage_type": {"type": "choice", "question": "申请指向的损伤 / 损失类型？",
                "choices": ["车辆", "医疗", "财产", "责任", "身故", "其他"]},
            "fraud_signal": {"type": "noul",
                "question": "材料中是否存在常见欺诈信号：时间线矛盾、金额与损失不符、凭证可疑？"},
            "severity": {"type": "score", "question": "损失严重程度？",
                "labels": ["轻微", "一般", "严重", "重大"]},
        },
        instructions="你是理赔初审助手。只依据材料中可核对的证据判断；材料缺失时判为不齐全，不要补全。"
    )
    if not d["complete"].value:
        return {"action": "request_more_docs", "need": d["complete"].probability}
    if d["fraud_signal"].probability >= 0.6:
        return {"action": "fraud_review", "type": d["damage_type"].choice}
    return {"action": "normal", "type": d["damage_type"].choice,
            "severity": d["severity"].score}

三个工程要点。材料核验不猜：材料缺失就判"不齐全"，让模型不要脑补，这与前面章节反复强调的"证据不足判否"一致。欺诈信号单列：它是 Noul，只回答"有没有典型信号"，不回答"是不是欺诈"——后者是不可逆的指控，必须留给人工和调查。损伤类型用 Choice：封闭选项让分类稳定，方便后续走不同的赔付流程。

金融犯罪：可疑线索的语义检测

金融犯罪（AML/KYC、可疑交易、制裁名单匹配）的判定有一个天然分工：名单匹配是确定的（命中就是命中，交给确定性规则或哈希比对即可），但"这笔交易像不像结构化拆单""这个客户的行为像不像洗钱""这个名称是不是被制裁实体的语义变体（缩写、音译、别名）"——这些只能靠语义判断。

同样，社区分类里这个方向也缺少高星专门项目，因此下面是通用做法，非某项目实现：

def aml_screen(txn: str, customer: str, sanctions_hits: list[str]) -> dict:
    # 1) 硬规则：名单精确命中，代码直接拦截，不询问模型
    if sanctions_hits:
        return {"action": "block", "reason": "sanctions_exact", "hits": sanctions_hits}

    # 2) 语义层：规则兜不住的可疑信号，交给决策层
    d = client.systemone(
        state=f"【客户】\n{customer}\n\n【交易】\n{txn}",
        questions={
            "structuring": {"type": "noul",
                "question": "这笔交易是否呈现结构化拆单特征（刻意规避申报门槛的拆分行为）？"},
            "kyc_consistent": {"type": "noul",
                "question": "交易行为是否与客户已声明的身份、职业、收入水平一致？"},
            "name_variant": {"type": "noul",
                "question": "客户名称是否为某受制裁实体的语义变体（缩写、音译、别名）？"},
            "risk": {"type": "score", "question": "综合可疑程度？",
                "labels": ["正常", "关注", "可疑", "高度可疑"]},
        },
        instructions="你是反洗钱初筛助手。只依据给定信息判断，不引入外部推测；证据不足时判为不一致。"
    )
    if d["structuring"].probability >= 0.7 or d["name_variant"].probability >= 0.7:
        return {"action": "file_report", "risk": d["risk"].score}
    if d["kyc_consistent"].probability < 0.5 or d["risk"].score >= 2.5:
        return {"action": "manual_review", "risk": d["risk"].score}
    return {"action": "pass", "risk": d["risk"].score}

两点必须记住。命中名单不交给模型判——把确定性的匹配放代码里，既是正确性也是合规底线。可疑不等于定罪：Jev 的输出是"可疑程度"和"是否呈现某种特征"，把最重的动作（申报、冻结）限制在高置信 + 人工确认之后。金融犯罪的自动化只该缩小人工要看的面，不该替人下结论。

交易决策：把"涨还是跌"类型化

交易是判定最密集的场景之一。Jevinik（unicodeveloper/jevocks）是一个终端程序：它通过 Valyu 收集实时市场证据，然后问 Jev 一个布尔问题——这只股票在未来 30 天是否可能走高。它的价值不在于"预测多准"，而在于把"方向"变成一个带概率的封闭判定，让下游的风控和仓位逻辑有一个明确的输入。

围绕同一个骨架，社区还给出了几种变体：

• jev_stock（sosopop/jev_stock）是一个实验性的港股框架，把结构化的市场状态转成 Jev 关于价格方向的判定，并附带一个针对首个交易日的回测脚本；
• jev-trade（aowang-ai/jev-trade）在 Hyperliquid 的某个市场上每一轮让 Jev 在 long 与 short 之间做一次 Choice，下单后对多个资产跑同一个循环；
• Polymarket BTC 5m Jev trader（VGabriel45/polymarket-btc5m-jev-trading）把 Jev 放在决策层，处理 Polymarket 的五分钟 BTC 涨跌市场，外面套一个终端 UI；
• Jev X Sentiment Analysis（brainstormity）则展示了证据聚合：每次请求先吃进 50–1000 条推文，经统计预处理和 SQLite 去重，再让 Jev 把存活的证据变成一张决策卡，含入场区间、止损、目标位，且不执行任何交易。

ai-hedge-fund（virattt/ai-hedge-fund）是一个多智能体的对冲基金系统，它原生集成了 JevLLM，用来执行"快速、类型化、不需要解析"的决策。这恰好回应了第 1 章的论断：交易系统最怕的不是判错，是判对了却解析错了——类型化输出把这个风险去掉。

执行层：每个区块一次的买卖判定

交易对延迟和成本最敏感。jev-trader（jarrodwatts/jev-trader）给出了目前社区里最硬的一组数字：它盯住 Monad 上的 Kuru MON-USDC 订单簿，每一个区块都让 Jev 做一次 buy/sell 的 Choice，然后下单。在真实 dry run 中，它公布的决策延迟为 81 毫秒，单次 Jev 调用成本 0.000004 美元。

def trade_once(order_book: str) -> str:
    d = client.systemone(
        state=order_book,
        questions={
            "side": {"type": "choice", "question": "下一笔应买入还是卖出？",
                     "choices": ["buy", "sell", "hold"]},
        },
        instructions="你是做市/执行决策助手。只依据订单簿状态判断，不给理由、不做风控。"
    )
    return d["side"].choice     # 风控、仓位、限额全部由下游代码掌管

81 毫秒意味着它能跟上一个区块链的出块节奏，而 0.000004 美元的单次成本意味着"每个区块都判一次"在经济上完全可行——如果是生成模型，光是逐 token 生成就不可能压进这个预算。注意 hold 选项和那句 不做风控：模型只做方向判定，风控永远留给代码，这是交易系统里必须守住的红线。

风控：把多个 Score/Noul 聚合成处置分数

把前面所有的判断聚合成一个可执行的风险分，是这三个场景共同的收尾动作。jev-guard（klauswg/jev-guard）是这一环最好的样本：它筛查加密交易所的充值和提现，用 Jev 做风险等级、行为模式、冻结概率三项分诊，但——硬规则拥有否决权，最终动作由 Java 代码合成（while hard rules veto and Java composes the final action）。它还为这套判定公布了一份100 样本的三列校准结果，对照的是一个"只用规则"的基线。

同样的模式在 jev-risk-check-provider（caiovicentino/jev-risk-check-provider）里被做成了服务：它是一个 x402 的 risk-check 提供方，把对手方的判定拆成 Noul/Choice/Score 问题，聚合进一个由代码掌控的 0–100 分，并对每一个裁决签发一份 ES256 签名的证明（attestation）。它的实测数据同样具体：540 次调用的规模测试在 65–75 阈值区间上达到 99.76%、0 个假阳性；5 轮、共 1500 个用例的对抗红队循环达到 100% 对抗准确率；单次决策成本约 0.00005 美元、p50 约 400 毫秒。

def risk_score(counterparty: str) -> dict:
    d = client.systemone(
        state=counterparty,
        questions={
            "sanctioned": {"type": "noul", "question": "是否命中或疑似命中制裁 / 黑名单？"},
            "behavioral": {"type": "score", "question": "行为异常程度？",
                           "labels": ["正常", "轻微", "异常", "高度异常"]},
            "freeze_p": {"type": "noul", "question": "是否应冻结资金以待人工核查？"},
        },
        instructions="你是交易对手风控助手。只依据给定材料判断，证据不足时从宽处理。"
    )
    # 代码聚合：Noul 用概率、Score 归一化后加权
    raw = (0.45 * d["sanctioned"].probability * 100
           + 0.35 * (d["behavioral"].score / 4) * 100
           + 0.20 * d["freeze_p"].probability * 100)
    score = round(raw, 1)

    if d["sanctioned"].probability >= 0.9:      # 硬规则优先，代码说了算
        return {"score": score, "action": "block", "attestation": sign(counterparty, score)}
    if score >= 70:
        return {"score": score, "action": "manual_review"}
    return {"score": score, "action": "allow"}

这里最该学的是聚合权重的两个来源：Noul 贡献它的 P(true)（0–1），Score 贡献归一化后的 score（除以档位数）。所有加权、阈值、否决都在代码里，模型只负责把每个维度的语义判出来。jev-risk-check-provider 的签名证明则回答了另一个问题——这一分是怎么算出来的、由谁签发的，这在风控里与分数本身同等重要。

让判定喂给下游模型：ML Feature Extraction

在这一章里，Jev 的角色往往不是"最终拍板的人"，而是"特征抽取器"。风险评估的十种决策形态中有一类叫 ML Feature Extraction：模型的输出不是给人看的结论，而是变成数值特征，喂给下游的评分卡、风控引擎或再上一层模型。这条路子恰好贴合理赔与金融犯罪——因为它们都有成熟的特征工程传统，缺的是从非结构化文本里稳定地读出字段。

差别在于：传统做法用正则和关键词去抠字段，遇到自由文本就脆；让生成模型来读又多了一层"解析对不对"的不确定性。Jev 的类型化输出天然是结构化的——Score 直接给出 0–1 的连续值，Noul 给出 P(true)，都可以不做二次解析就进特征向量：

def claim_features(claim_text: str, docs: str) -> dict:
    d = client.systemone(
        state=f"【理赔申请】\n{claim_text}\n\n【提交材料】\n{docs}",
        questions={
            "fraud_strength": {"type": "score", "question": "欺诈信号的强度？",
                               "labels": ["无", "弱", "中", "强"]},
            "timeline_consistent": {"type": "noul", "question": "事故时间线是否自洽？"},
            "amount_plausible": {"type": "noul", "question": "金额与所述损失是否相称？"},
        },
        instructions="你是理赔特征抽取器。只输出对给定文本的判断，不下结论、不引用外部信息。"
    )
    return {
        "fraud_strength": d["fraud_strength"].score / 4,        # 归一化到 0–1
        "timeline_ok": d["timeline_consistent"].probability,
        "amount_ok": d["amount_plausible"].probability,
    }

这样一来，claim_features 的返回就是一个标准的特征字典：某银行既有的 XGBoost 评分卡、反欺诈规则引擎都无需改动，只是把原来靠正则抽的几个字段换成决策层给的连续值。三个工程好处值得点明。

其一，特征即概率，天然平滑。 正则只能给 0/1，而 timeline_ok = 0.83 这样的连续值保留了"有多像"的颗粒度，对下游模型的区分度更友好。

其二，抽取器与决策器解耦。 特征抽取只回答"这段文本里有什么"，处置逻辑（放行/转人工/拦截）单独一层。改阈值、改规则不影响抽取，改抽取模型也不影响规则——这正好呼应第 13 章讲的"策略即数据"。

其三，评估口径清晰。 特征抽取的正确性可以用一份标注样本单独衡量，不必和下游模型的整体表现混在一起。一旦抽取这一层不稳定，后面的分数再漂亮也是空中楼阁。

同样的思路可以直接搬到金融犯罪：把 structuring、kyc_consistent、name_variant 的 P(true) 作为三个特征送进既有的反洗钱评分系统。Jev 不去替代那套系统，只负责把它过去读不懂的非结构化部分补上。

可解释性与可审计

在这一章的场景里，"为什么"往往比"是什么"更重要。

硬规则优先于模型。 三个项目用同一种方式实现了这一点：jev-guard 让硬规则否决、Java 合成动作；jev-risk-check-provider 把判定聚合进"代码掌控"的分数；jev-trader 把风控完全移出模型。模型可以抬高严重度，但不应有权降低确定性规则的结论。

每个裁决都要能追溯。 保留概率分布而非只有最终结论：P(SEV1)=0.62 与 P(SEV1)=0.95 在事后复盘里含义完全不同。jev-risk-check-provider 更进一步，给每个裁决签一份 ES256 证明，使"这个分数出自哪次判定、内容是否被篡改"可被验证。

校准是对外负责的前提。 jev-guard 的 100 样本三列校准、jev-risk-check-provider 的 540 次规模测试与 1500 例红队循环，都是在回答同一个问题："把阈值设在 70 时，误杀和漏放各有多少？"没有这份数字，任何自动风控都不该上线。

小结

• 理赔、金融犯罪、风险评估共享同一条判定链：证据门（Noul）→ 信号检测（Noul/Choice）→ 维度打分（Score）→ 硬规则否决 → 代码聚合 → 处置建议。
• 理赔方向社区尚无高星专门项目：用"材料齐全性 Noul + 损伤类型 Choice + 欺诈信号 Noul + 严重度 Score"的通用做法，材料缺失判不齐全、欺诈信号只做提示而不做指控。
• 金融犯罪同样是通用做法：名单精确命中交代码直接拦截，语义层（结构化拆单、KYC 一致性、名称变体）才交给 Jev；可疑不等于定罪。
• 交易方向有真实项目：Jevinik 用 Valyu 证据问"30 天是否走高"，jev-trade 在 Hyperliquid 上每轮做 long/short 判定，jev_stock 做港股方向判定，ai-hedge-fund 原生集成 JevLLM 消除解析脆弱性。
• jev-trader 在 Monad 的 Kuru MON-USDC 上每区块判一次买卖，公布 81 毫秒延迟与 0.000004 美元/次成本；模型只判方向，风控留在代码。
• 风控聚合看 jev-guard（硬规则否决、Java 合成动作、100 样本三列校准）与 jev-risk-check-provider（0–100 代码掌控分数、ES256 证明、540 次调用 99.76% / 0 假阳性、1500 例红队 100%）；可解释与可审计是这类场景的硬要求。

至此，第三部分"AI Automation Software"的七个行业用例全部走完。第五部分将把镜头收回到工程层，讲大数据上的 Map Reduce、通用验证与 Harness Engineering——把这些零散的判定模式，变成可持续运行的系统能力。