外观

象信控制台
自洽性

自洽性：Noul

一份车险理赔单、14 个 Noul 问题、每个条件重复 15 次：象信每题概率的平均标准差 0.0037，DeepSeek 默认温度为 0.0426、有 2 题跨过 0.5；但象信在 11 道有参考答案的题里错了 4 道，稳定不等于正确。

自洽性：Noul ​

同一份材料问两遍，答案应该一样。理赔分流（直接赔付、拒赔、转人工）靠的是每个检查项的概率：如果概率在两次请求之间来回跳，恰好落在阈值附近的那一项就会一次赔、一次不赔。

这篇拿一份车险理赔单，配 14 个是非检查项（全部是 Noul），同一请求重复 15 次，看每个概率稳不稳。对照组是 DeepSeek V4.1 Flash（温度 0、默认温度、只答是/否，以及思考模式）。

结论先放在这里：

  • 稳定性：象信每题概率的平均标准差为 0.0037，最大单题极差 0.03，没有一题跨过 0.5。DeepSeek 在温度 0 下平均标准差 0.0303、单题极差最大 0.38；默认温度下 0.0426、极差 0.49，并有 2 题在 15 次里一会儿过 0.5、一会儿不过。思考模式为 0.0135，但每次调用平均要生成 4,134 个 token、耗时约 2 分钟。
  • 正确性：在 11 道有参考答案的题上，DeepSeek 四个条件的多数方向全部正确；象信答错了 4 道，而且每次都错在同一个方向。这 4 道都需要一步计算（日期差、金额比对、险种是否投保）。

也就是说，这一篇里象信赢在"稳"和"便宜"（每次调用的成本不到 DeepSeek 非思考模式的 1/60），DeepSeek 赢在"对"。后半篇讨论为什么这两件事要分开看，以及怎样用一个"待人工"区间承接不确定的判断。

环境准备 ​

bash
pip install xiangxin-sdk openai
export XIANGXIN_API_KEY="sk-xx-..."
# LLM 对照组（任意 OpenAI 兼容接口）
export LLM_BASE_URL="https://api.deepseek.com" LLM_API_KEY="..." LLM_MODEL="..."

本次运行：象信 xiangxin-latest，采样时间 2026-09-25（UTC）。LLM 对照组为自部署的 DeepSeek V4.1 Flash（vLLM，OpenAI 兼容接口），采样时间 2026-09-25。

数据：一份带争议点的车险理赔单 ​

保单条款部分逐字摘录自《中国保险行业协会机动车商业保险示范条款（2020 版）》（中国保险行业协会 2020 年 9 月发布的公开示范条款，各财险公司官网均有全文，原文文本见仓库 data/示范条款2020_原文.txt）。投保信息、理赔申请和系统备注为本文构造，故意埋了几个需要判断的点：

  • 驾驶人去赛车场参加"赛道开放日"，而条款第九条把"竞赛、测试期间"列为责任免除；但事故发生在赛车场外的观众停车场，车辆熄火停放，被倒车的社会车辆撞了后保险杠，当天没有进赛道。
  • 索赔明细里有一笔 1,300 元的代步车费用，但保单没有投保附加修理期间费用补偿险。
  • 出险 2026-06-28 15:40，报案 2026-07-01 10:05，约 66 小时，超过第四十条要求的 48 小时。
  • 没有交警事故认定书，车辆已在 4S 店先行拆检（第十五条要求修理前会同保险人检验）。
  • 保单约定 10% 绝对免赔率，但"自动核赔"备注已经按 13,100 元全额核准赔付。

state 直接传 JSON 对象，不必先拼成字符串：

python
CLAIM = {
    "保单": {
        "保单号": "PDAA2026330100000417",
        "被保险人": "陈某",
        "保险期间": "2026-01-15 00:00 至 2027-01-14 24:00",
        "承保险种": {
            "机动车损失保险": {"投保": True, "保险金额": 186000.00},
            "机动车第三者责任保险": {"投保": True, "每次事故责任限额": 2000000.00},
            "附加绝对免赔率特约条款": {"投保": True, "绝对免赔率": "10%"},
            "附加修理期间费用补偿险": {"投保": False},
        },
        "条款摘录（示范条款 2020 版原文）": {
            "第六条": "保险期间内，被保险人或被保险机动车驾驶人（以下简称“驾驶人”）在使用被保险机动车过程中，因自然灾害、意外事故造成被保险机动车直接损失，且不属于免除保险人责任的范围，保险人依照本保险合同的约定负责赔偿。",
            "第九条（三）3": "被保险机动车有下列情形之一者，不论任何原因造成被保险机动车的任何损失和费用，保险人均不负责赔偿：……竞赛、测试期间，在营业性场所维修、保养、改装期间。",
            "第十五条": "因保险事故损坏的被保险机动车，修理前被保险人应当会同保险人检验，协商确定维修机构、修理项目、方式和费用。",
            "第十七条": "因第三方对被保险机动车的损害而造成保险事故，被保险人向第三方索赔的，保险人应积极协助；被保险人也可以直接向本保险人索赔，保险人在保险金额内先行赔付被保险人，并在赔偿金额内代位行使被保险人对第三方请求赔偿的权利。",
            "第四十条": "发生保险事故时，被保险人或驾驶人应当及时采取合理的、必要的施救和保护措施，防止或者减少损失，并在保险事故发生后 48 小时内通知保险人。",
            "附加绝对免赔率特约条款": "主险实际赔款=按主险约定计算的赔款×（1-绝对免赔率）",
        },
    },
    "理赔申请": {
        "报案号": "RDAA2026330100088123",
        "出险时间": "2026-06-28 15:40",
        "报案时间": "2026-07-01 10:05",
        "驾驶人": "陈某之子 陈某某（持 C1 驾照）",
        "出险经过": "驾驶人报名参加某国际赛车场举办的“赛道开放日”活动。事故发生在赛车场外的观众停车场，"
        "本车处于熄火停放状态，被另一辆倒车的社会车辆撞击后保险杠。本车当天未进入赛道。",
        "索赔金额": 13100.00,
        "费用明细": [
            {"项目": "后保险杠总成更换", "金额": 6800.00},
            {"项目": "后部钣金喷漆", "金额": 3200.00},
            {"项目": "倒车雷达校准", "金额": 1800.00},
            {"项目": "代步车租赁（5 天）", "金额": 1300.00},
        ],
        "已提交材料": ["4S 店维修报价单（已在 4S 店拆检）", "现场照片 8 张", "对方车辆车牌照片"],
        "未提交材料": ["交警事故认定书或双方协议书"],
    },
    "系统备注": [
        {"来源": "自动核赔", "内容": "车损险有效，自动通过。按索赔金额 13,100 元全额赔付给被保险人，3–5 个工作日到账。"}
    ],
    "历史理赔": {"近 12 个月出险次数": 2, "其中拒赔": 0},
}

问题设计：14 个 Noul ​

每题都写成"答'是'表示被检查的那件事成立"，这样每一行的概率含义一致，象信的 noul 和大模型给出的概率可以直接对比。

python
from xiangxin import Noul

QUESTIONS = {
    "covered": "这次损失是否属于机动车损失保险的保险责任范围？",
    "exclusion": "是否有责任免除条款适用于这次损失？",
    "on_track": "事故是否发生在车辆于赛道上行驶的过程中？",
    "deductible": "自动核赔给出的赔付金额是否已经正确扣减了 10% 绝对免赔率？",
    "docs_sufficient": "已提交的材料是否足以直接核定这笔赔案？",
    "within_limit": "索赔金额是否在机动车损失保险的保险金额以内？",
    "within_period": "出险时间是否在保险期间内？",
    "reported_timely": "是否在条款要求的时限内通知了保险人？",
    "rental_eligible": "代步车租赁费用是否属于本保单可以赔付的范围？",
    "fraud_flag": "是否存在需要转交反欺诈调查的迹象？",
    "auto_approved": "这笔赔款是否在没有人工理赔员审核的情况下被自动核准？",
    "manual_review": "这笔赔案在赔付前是否应当转人工或主管复核？",
    "line_items_sum": "费用明细各项金额之和是否等于索赔金额？",
    "subrogation": "是否存在可能负有责任、保险人可以向其代位追偿的第三方？",
}

questions = {key: Noul(instructions=text) for key, text in QUESTIONS.items()}

怎么问 ​

象信：一次 system_one 请求带上全部 14 题，每题的 noul 就是答案为"是"的概率。跑两个条件，各 15 次：

  • xiangxin_uid：每次在 state 里加一个随机的 uid 字段（和 TypeSafe 原文、以及下面 LLM 对照组的做法相同），理赔单和问题不变；
  • xiangxin_same：请求体逐字节相同。TypeSafe 原文说它的设置"无法区分对无关字段的敏感和同一请求本身的波动"，多跑这一组就能把两者分开看。
python
from secrets import token_hex
from xiangxin import XiangxinClient

client = XiangxinClient()

def ask_xiangxin(state):
    resp = client.system_one(model="xiangxin-latest", state=state, questions=questions)
    return {key: resp.answers[key].noul for key in QUESTIONS}, resp.usage.input_tokens

uid_runs = [ask_xiangxin({"uid": f"{i}:{token_hex(4)}", "claim": CLAIM}) for i in range(15)]
same_runs = [ask_xiangxin({"claim": CLAIM}) for _ in range(15)]

LLM 对照组：一条提示词里放 json.dumps(CLAIM) 和全部 14 题，要求模型只输出一个 JSON 对象，键为题目键、值为 0–1 的概率。四个条件各 15 次：

  • 非思考模式（chat_template_kwargs={"thinking": False}）：概率·温度 0、概率·默认温度、只答"是/否"·温度 0（映射为 1.0 / 0.0）；
  • 思考模式（先推理再作答，对应 TypeSafe 原文里的推理模型）：概率·默认温度。

每次提示词开头同样带一个随机 uid。无法解析的回复计为解析失败，不参与统计（本次 0 次）。调用串行进行（并发 1）。

python
def rubric_prompt(mode: str, sample_index: int) -> str:
    if mode == "yesno":
        fmt = "\n\n请逐题回答“是”或“否”。\n只输出一个 JSON 对象：键为题目的键，值为 \"是\" 或 \"否\"，每题一项。"
    else:
        fmt = "\n\n请对每一题给出答案为“是”的概率。\n只输出一个 JSON 对象：键为题目的键，值为 0.00 到 1.00 之间的数字，每题一项。"
    return (
        f"uid: {sample_index}:{token_hex(4)}\n\n"
        f"文档（一份车险理赔材料）：\n{json.dumps(CLAIM, ensure_ascii=False, indent=2)}\n\n题目：\n"
        + "\n".join(f"- {k}: {q}" for k, q in QUESTIONS.items())
        + fmt
    )

完整的请求、解析和统计代码见文末仓库链接（main.py、llm_baseline.py、report.py）。

结果 ​

稳定性总表 ​

"平均每题标准差"是 14 题各自在 15 次里的标准差再取平均；"跨 0.5 的题数"是 15 次里最小值和最大值落在 0.5 两侧的题数，也就是用 0.5 做阈值时会出现一次"是"、一次"否"的题。

条件调用次数平均每题标准差最大单题极差跨 0.5 的题数解析失败
DeepSeek 概率 t=0150.03030.3800
DeepSeek 概率 默认温度150.04260.4920
DeepSeek 是/否 t=0150.00000.0000
DeepSeek 思考模式 概率150.01350.3000
象信 xiangxin_uid150.00370.0300
象信 xiangxin_same150.00160.0100

先看 DeepSeek：

  • 温度 0 也不稳。covered 在 15 次里从 0.55 到 0.93，极差 0.38；exclusion 从 0.12 到 0.35。都没跨过 0.5，但任何设在 0.6–0.9 之间的阈值都会被来回穿过。
  • 默认温度更散，并且 covered（0.45–0.94）和 exclusion（0.08–0.55）两题都跨过了 0.5：同一份理赔单，有时判"在保障范围内/无免责"，有时相反。
  • 只答是/否在本次 15 次里完全一致（标准差 0）。这说明 DeepSeek 在温度 0 下的离散答案是稳的，代价是丢掉了所有"拿不准"的信息：covered 和 exclusion 这两道本来就有争议的题，也被压成了干脆的 1 和 0。
  • 思考模式更稳（0.0135），但 fraud_flag 仍在 0.05–0.35 之间移动，而且每次调用平均生成 4,134 个 token。

再看象信，两点值得注意：

  • 同一请求重复 15 次，概率也不是逐位相同（xiangxin_same 的最大极差 0.01）。一个可能的原因是服务端做批量推理，批次组成不同会带来浮点层面的微小差异，反映到两位小数上就是偶尔差 0.01。
  • 加入随机 uid 后波动略大（最大极差 0.03，出现在 within_period：0.68–0.71），并且 within_period 的中心也从 0.74 移到了 0.69 左右。一个无关字段能让个别题移动几个百分点，这是真实存在的敏感性，写 state 时应尽量只放和判断有关的内容。

每题的取值范围（15 次的最小–最大） ​

题目DeepSeek t=0DeepSeek 默认温度DeepSeek 是/否DeepSeek 思考象信 uid象信 same
covered0.55–0.930.45–0.941.00–1.000.95–1.000.81–0.830.81–0.81
exclusion0.12–0.350.08–0.550.00–0.000.00–0.050.29–0.300.30–0.30
on_track0.02–0.050.02–0.050.00–0.000.00–0.010.06–0.070.07–0.07
deductible0.02–0.050.01–0.080.00–0.000.00–0.000.69–0.700.68–0.69
docs_sufficient0.12–0.220.04–0.280.00–0.000.00–0.150.42–0.430.41–0.42
within_limit0.99–1.000.98–1.001.00–1.001.00–1.000.95–0.950.95–0.95
within_period0.99–1.000.99–1.001.00–1.001.00–1.000.68–0.710.74–0.74
reported_timely0.05–0.100.01–0.120.00–0.000.00–0.000.80–0.810.79–0.79
rental_eligible0.03–0.050.02–0.060.00–0.000.00–0.020.76–0.780.76–0.77
fraud_flag0.10–0.220.07–0.420.00–0.000.05–0.350.22–0.230.23–0.23
auto_approved0.97–1.000.95–1.001.00–1.000.95–1.000.96–0.960.95–0.95
manual_review0.95–0.970.88–0.981.00–1.000.99–1.000.26–0.270.27–0.28
line_items_sum0.99–1.000.99–1.001.00–1.001.00–1.000.94–0.950.94–0.94
subrogation0.88–0.960.90–0.971.00–1.000.98–1.000.86–0.860.84–0.85

稳定，但不一定对 ​

为了说明"稳定"和"正确"是两回事，我们按条款和材料给 11 道题写了参考答案（common.py 里的 REFERENCE；covered、exclusion、fraud_flag 三题有争议，不设答案）。这是本文作者的判断，不是权威理赔结论。按 0.5 阈值看 15 次中多数的方向：

条件有参考答案的题数多数方向正确答错的题
象信 xiangxin_uid117deductible、reported_timely、rental_eligible、manual_review
象信 xiangxin_same117同上
DeepSeek 概率 t=01111—
DeepSeek 概率 默认温度1111—
DeepSeek 是/否 t=01111—
DeepSeek 思考模式 概率1111—

在这份理赔单上，DeepSeek 无论哪种设置，多数方向都与参考答案一致；象信错了 4 道。这是本篇最重要的负面结果，不应被上面的稳定性数字掩盖。

四道错题都需要一步"推算"：deductible 要先算出 13,100 × 0.9 再和备注比；reported_timely 要算出 66 小时再和 48 小时比；rental_eligible 要把明细里的代步车和"附加修理期间费用补偿险：未投保"对上；manual_review 则要把前面几处疑点汇总起来。象信是一个系统一模型，直接给概率，不做逐步计算，这类多跳推理正是它的弱项（见 象信的能力边界）。在生产里，这几项更适合用代码直接算（日期差、金额比对、险种是否投保），而不是交给任何模型"判断"。

同样值得看的是它没答错的地方：on_track（0.07）正确区分了"去了赛车场"和"在赛道上行驶"；line_items_sum（0.94）、subrogation（0.86）、auto_approved（0.96）都明确；docs_sufficient（0.42）方向正确但把握不大。

成本与速度 ​

条件平均输入 token每次调用成本延迟（中位数 / 最快）
DeepSeek 概率 t=01,201（输出 155）¥0.0036414.6 s / 4.8 s
DeepSeek 概率 默认温度1,201（输出 156）¥0.0036514.4 s / 8.3 s
DeepSeek 是/否 t=01,196（输出 128）¥0.0034123.3 s / 7.0 s
DeepSeek 思考模式 概率1,227（输出 4,134）¥0.0355122.9 s / 76.6 s
象信 xiangxin_uid1,259¥0.00005296.7 s / 3.1 s
象信 xiangxin_same1,245¥0.000052315.6 s / 2.3 s

成本口径：象信按 ¥0.042 / 百万输入 token、输出免费。DeepSeek 为自部署，按 DeepSeek 官方 API 价目折算：取价日期 2026-09-25，deepseek-flash（DeepSeek-V4.1-Flash）高峰时段、缓存未命中，输入 ¥2 / 百万 token、输出 ¥8 / 百万 token（闲时为其一半），即 成本 = 输入 token × 2e-6 + 输出 token × 8e-6。按这个口径，非思考模式每次调用约为象信的 65–70 倍，思考模式约 670 倍。

本次的延迟数字不代表正常水平：象信采样时同一套服务正在同时跑多篇实战手册的批量任务，排队明显，部分请求还遇到了 500 后重试；DeepSeek 跑在一台同时服务多个任务的自部署 GPU 上。这里如实列出，但不据此下速度结论。唯一稳健的对比是思考模式：它每次多生成约 4,000 个 token，这部分耗时和成本在任何部署下都存在。

允许"待人工"，而不是强行二选一 ​

用 0.5 做阈值时，0.49 和 0.51 会触发相反的动作，尽管二者表达的都是"拿不准"。更稳妥的做法是在应用层加一个区间：

  • 低于 0.30 → 否；
  • 0.30 到 0.70（含两端）→ 待人工；
  • 高于 0.70 → 是。

这只是对返回概率的一段应用逻辑：不需要新问题，也不需要第二次调用。区间边界只是示意，不是校准过的保证，生产中应当用有标注的样本、结合误判和人工复核的代价来定（见 置信度 与 置信度门控路由）。

python
def noul_decision_with_uncertainty(p: float) -> str:
    if p < 0.30:
        return "否"
    if p > 0.70:
        return "是"
    return "待人工"

把它套到 xiangxin_uid 的 15 次结果上（每题下面是 15 次的决策分布，逐次概率见仓库 results/tables.md）：

题目决策分布
covered是 × 15
exclusion否 × 4，待人工 × 11
on_track否 × 15
deductible待人工 × 15
docs_sufficient待人工 × 15
within_limit是 × 15
within_period待人工 × 14，是 × 1
reported_timely是 × 15
rental_eligible是 × 15
fraud_flag否 × 15
auto_approved是 × 15
manual_review否 × 15
line_items_sum是 × 15
subrogation是 × 15

这张表同时说明了区间的好处和它自身的边界：

  • 好处：deductible（0.69–0.70）在 0.5 阈值下是一个稳定的错误"是"，放进区间后 15 次都变成了"待人工"，错误被拦了下来；docs_sufficient 也一样。
  • 区间也有边：exclusion 的概率在 0.29 和 0.30 之间，正好骑在下边界上，于是 4 次判"否"、11 次判"待人工"；within_period 在 0.68–0.71 之间，骑在上边界上。模型的波动只有 0.01–0.03，但只要概率贴着某条边，决策照样会翻。区间把"是/否对翻"变成了"自动/人工之间翻"，后果轻了很多，但并没有让模型更确定。
  • 区间救不了自信的错误：reported_timely（0.80）、rental_eligible（0.77）、manual_review（0.27）都落在区间外，而且方向是错的。这类错误要靠把可计算的检查交给代码、或者用标注数据发现并改写问题来解决，而不是靠调阈值。

讨论 ​

为什么象信的概率这么稳。 象信不采样生成文本，一次前向直接读出每个选项的概率，同一输入的数值差异只在百分位上；大模型的"概率"则是它写出来的一段文字，会随采样、随提示里的无关字段变化。本篇的 DeepSeek 数字印证了这一点：即使温度 0，covered 也在 0.55 和 0.93 之间移动，用它的数值做阈值路由并不可靠。

稳定是下限，不是上限。 一个每次都给出同一个错误答案的模型，自洽性满分。这篇里象信的 4 道错题就是例子，而同样的 4 道题 DeepSeek 都答对了。自洽性测试能告诉你"数值可以放心地拿去做阈值路由"，但阈值定在哪里、哪些题根本不该交给模型、哪些题需要更强的推理，要靠有标注的样本来决定。

两者怎么搭配。 一个务实的做法是：可以用代码算的检查交给代码；需要"读懂材料"的判断交给象信，按概率分流；落进"待人工"区间或高风险的赔案，再交给一个推理更强的大模型或人工复核。这样象信负责量大、便宜、稳定的第一层，大模型只处理少数难例（见 置信度门控路由）。

什么时候不该这样用。 日期差、金额加总、某个险种是否投保，这些能用一行代码确定的检查，就用代码。把模型留给真正需要"读懂材料"的判断：on_track 这种"去了赛车场但没上赛道"的区分，正是它做得好的地方。

完整代码 ​

https://github.com/xiangxinai/xiangxin-cookbooks/tree/main/consistency_noul_cookbook

  • common.py：理赔单、14 个问题、参考答案
  • main.py：象信两个条件各 15 次，结果写入 results/xiangxin_runs.json
  • llm_baseline.py：LLM 对照组（3 个条件 × 15 次），结果写入 results/llm_runs.json
  • report.py：汇总生成 results/summary.json 与 results/tables.md