课题方案将大模型接入业绩报酬计算全流程，一个自然的疑问是：系统表现对基础模型的能力档位有多敏感？若强模型（Opus）与弱模型（Haiku）表现相近，则生产选型可优先考虑成本与延迟；若差异显著，则须为准确率支付更高的模型成本。
本实验提出两个待检验假设：
H1（护栏拉平假设）：由于金额计算由确定性引擎完成、且规则引擎全程兜底，只要模型能把关键参数抽取正确，最终「人机计算一致率」就不依赖模型档位——即三项指标中，计算一致率对模型质量最不敏感。
H2（抽取梯度假设）：模型质量主要体现在条款参数抽取环节——面对刁钻措辞（复合基准、定义分离、中文数词等），强模型的语言理解优势会转化为更高的抽取准确率与更少的「需人工确认」降级。
自变量（单一操纵变量）：底层基础模型档位。rules（纯规则引擎，无模型）／haiku／sonnet／opus（均经 Claude 订阅 CLI，temperature 效果上确定）。OpenAI 兼容通道已在 backend/llm.py 就位，可一键接入 DeepSeek / OpenRouter / 本地 Ollama 等模型（见第 6 节）。
因变量：① 计提模式识别准确率；② 条款参数抽取准确率（关键参数取值相对误差 < 1e-6 记正确）；③ 人机计算一致率（|系统金额 − 手算金额| < 0.01 万元）；④ 单份合同平均处理耗时。
控制变量：同一份 v0.3 代码、同一 18 案例基准集与其人工手算 ground truth、同一套提示词（contract_agent / binding_agent / calc_agent 内置，不随模型调整）、同一评分脚本 tests/benchmark.py。唯一变化的是 ANNUITY_MODEL 环境变量。
评测集：18 案例覆盖两类支持模式（超额收益法 11 例 E01–E11、高水位法 5 例 H01–H05、负例 2 例 N01–N02），并含全角数字、中文数词、复合基准「即年化」、风险准备金干扰、单位换算、零值与负例等真实措辞变体，是一个刻意刁钻的抽取难度谱。
| 档位 | 模型 | 模式识别 | 参数抽取 | 人机一致 | 单份均耗时 | 对抗防御率 |
|---|---|---|---|---|---|---|
| 规则引擎 (无模型) | 规则引擎（演示模式） | 100.0% | 100.0% | 100.0% | 0.00s | |
| Claude Haiku | haiku | 100.0% | 100.0% | 100.0% | 61.94s | |
| Claude Sonnet | sonnet | 100.0% | 100.0% | 100.0% | 39.67s | |
| Claude Opus | opus | 100.0% | 100.0% | 100.0% | 49.25s |
最醒目的结果是：从无模型的纯规则引擎，到 Haiku、Sonnet、Opus，四个档位在三项准确率上高度一致，均达到或接近 100%（见图 1 与数据表）。这直接支持了 H1「护栏拉平假设」：因为金额计算由本地确定性公式引擎完成、且模型生成的公式须与标准公式交叉验证、规则引擎又全程兜底，只要关键参数被抽取正确，最终「人机计算一致率」就与模型档位无关。
四档之间真正拉开数量级差距的是处理耗时（图 2，对数刻度）：规则引擎单份约 0.001 秒，Claude 各档约 60 秒——相差约五万倍。需要说明的是，这个耗时以「订阅 CLI 模式」测得，每次模型调用都要启动一个 CLI 子进程（进程启动开销占大头），生产环境改用 API 直连并复用连接会显著更快；但数量级结论不变：规则引擎在速度上碾压任何大模型通道。
一个诚实的反问：如果规则引擎都能 100%，那要模型做什么？答案在评测集的难度分布。本基准集的案例虽然措辞刁钻（全角、中文数词、复合基准、干扰项），但都是规则引擎经三轮对抗加固后已能解析的结构化条款。在这类案例上，模型的语言理解优势没有用武之地——规则够用，模型只是「也能做对」。
模型质量真正会显现价值的，是规则引擎失效的长尾疑难：自由格式的非结构化条款、需要跨段落推理的隐含约定、罕见计提模式、真正的语义歧义。这类案例本基准集覆盖不足（因为 ground truth 本身就难构造）。因此本实验的结论应严格表述为：在「规则可解」难度带内，模型档位不影响准确率、只影响成本与延迟；在「规则失效」难度带，模型质量的边际价值尚待更难的评测集检验。这恰好指向生产选型策略（见第 5 节）与下一步实验（第 6 节）。
基于「护栏拉平 + 规则碾压速度」两点，推荐分层调度而非单一模型：
其一，规则引擎做第一道：绝大多数结构化条款由规则引擎瞬时、零成本处理，且经三轮对抗已足够稳健。其二，模型只兜底疑难：仅当规则引擎判定「参数缺失 / 低置信 / 歧义」时，才升级调用大模型——此时模型档位的选择才有意义。其三，模型档位按疑难难度分级：常规疑难用便宜快速的档位（Haiku/DeepSeek），真正复杂的合同才动用 Opus。这样既守住准确率，又把 token 成本压到最低。换言之，本系统的价值不在于「接了多强的模型」，而在于「用确定性护栏让模型可错、用规则引擎让常规免费」。
统计功效：本实验为单次运行，未估计方差。大模型输出有随机性，严谨版应对每档每案例重复 K 次、报告均值 ± 标准差，并对档位差异做显著性检验。当前结论「各档一致」在 100% 天花板附近稳健，但接近的中间值需方差支撑。
评测集：8 案例子集用于快速消融；完整结论应在 18 案例全集乃至 28 案例对抗集上复算（架构已支持，--ids 去掉即全量）。更关键的是需补充「规则失效」难度带的案例，才能测出模型能力的上限。
模型覆盖：DeepSeek 因云端沙盒网络白名单限制无法在云端实测，已通过 OpenAI 兼容通道（backend/llm.py）支持、在用户本机补测；其结果并入下表对应行。后续可纳入更多开源模型（Qwen、Llama、本地 Ollama）横向对比性价比。
耗时口径：CLI 模式含进程启动开销，非模型净推理时延；生产 API 直连的真实延迟需另测。