sigverify-onsite银行离线签名核验 封面
FSI · Customer Technical Session · Confidential
Signature Verification
银行离线手写签名核验
数据不出行、永不自动拒绝、每个数字可复现的 1:1 核验方案
约束 › 方案 › 证据 › 上线 On-premises · Human-in-the-loop · Reproducible
AWS · Neo 孙
Solutions Architect Amazon Web Services
Agenda

今天的五个部分 先讲约束,再讲方案,然后用证据说话

先定判据,再谈模型

签名核验最容易出问题的不是模型,是口径。所以证据一章最长:协议、总表、局限,一个都不省。

Constraints · Solution · Evidence · Robustness · Next steps
01

问题与约束

Problem
现状 · 四条硬约束
P3–P5
02

方案

Solution
架构 · 三区间 · 交付模型 · 行内自适应
P6–P10
03

证据

Evidence
协议 · 15 列总表 · 中文 · 留出集 · 局限
P11–P16
04

鲁棒性与上线

Go-live
支票背景 · CPU 性能 · 安全审计
P17–P20
05

下一步

Next steps
试点计划 · 常见问题 · 总结
P21–P25
Agenda02
01
Problem & Constraints
问题与约束
银行要的不是「最准的模型」,而是「在这几条约束下能上线的系统」。
银行签名核验的现状四条硬约束
sigverify-onsite
03
Ch.1 · 问题与约束 · Status quo

银行签名核验的现状 人工比对为主,难点在中文、少参考与熟练伪造

今天怎么做 人工

柜员或后台把单据签名与预留印鉴卡比对。速度与一致性取决于个人经验,难以抽检、难以量化,更难回答「这个月漏掉了多少伪造」。

为什么难 数据

每位客户只有少量预留样本;中文签名笔画多、写法随时间漂移;真正的风险来自模仿过的熟练伪造,而不是随手乱签 —— 随手乱签人和模型都容易识别。

为什么不能直接买 合规

已发表的强模型几乎都用 GPDS、CEDAR 等非商用数据训练;云端 API 又意味着生物特征出行。两条路都走不通,只能为银行场景重新训练。

今天

按到达顺序逐张人工比对;结果取决于个人经验,难以抽检,也回答不了「漏掉了多少」;高峰期只能靠加人。

→
引入之后

系统先打分、排序、分到三个区间并附理由码;复核员先看最可疑的,最终判断仍由人做,并且每一步都可审计。

所以要解决的问题是

  • 一个可商用、可离线、对中文熟练伪造有效的模型 —— 并且能证明它比已发表的方法好。
  • 它是给复核员排序和分流的工具,不是替代复核员的判官。
  • 交付形态:一个离线容器 + 3 个模型文件,贵行自己运行、自己校准。
Ch.1 · 问题与约束 · 现状04
Ch.1 · 问题与约束 · Constraints

四条硬约束 每一条都对应系统里一处可检查的机制

01

数据不出行

  • 容器以 --network none 运行
  • 运行期无 pip / HF 下载
  • 模型只读挂载
  • 不依赖任何云端服务
02

永不自动拒绝

  • 只输出 accept / review / priority_review
  • 拒绝永远由人做
  • 每个判定带理由码
  • 系统从不替人说「拒绝」
03

可审计

  • 每次核验写一行 JSONL
  • 记录模型哈希与阈值版本
  • 账号以密钥哈希存储
  • 模板与阈值按模型哈希隔离
04

可商用

  • 交付模型只用许可干净的数据
  • 来源登记表 + 生成的归属声明
  • 非商用权重只做对照
  • DINOv3 许可原文随附
约束落在哪里怎么验
数据不出行镜像运行层没有 pip / uv,设置 PIP_NO_INDEX、HF_HUB_OFFLINE;模型目录只读冒烟脚本在 --network none 下跑完全流程
永不自动拒绝决策只有 accept / review / priority_review 三个取值单元测试 + 变异清单
可审计每次核验一行 JSONL:模型哈希、阈值版本、区间、理由码单元测试校验审计行
可商用来源登记表 commercial.SOURCES → 生成 DELIVERY_NOTICE.md声明由程序生成,不手写
验收方式:四条约束都写成了测试和变异检查 —— 把任何一条机制拆掉,测试会变红。贵行验收时可以在自己的断网环境里把测试与冒烟脚本完整跑一遍,不需要我们在场。
Ch.1 · 问题与约束 · 四条硬约束05
02
Solution
方案
研发在场外,运行在行内;跨越边界的只有签过哈希的模型文件。
整体架构现场流程与三区间交付模型与许可链银行侧自适应
sigverify-onsite
06
Ch.2 · 方案 · Architecture

两个区域,一条单向边界 模型制品进,客户数据永不出

场外:研发与训练 AWS GPU

数据
许可干净的训练集

9 个来源:自研合成中文签名 SynCN + CC BY / CC0 公开手写数据

训练
三个互补的骨干网络

两个 ResNet18 + 一个 ConvNeXt(DINOv3 初始化)

导出
ONNX + 逐项对拍

与原模型特征余弦 < 0.9999 即拒绝写出

发布
哈希与实测性能

每个文件的 sha256 与 CPU 延迟由脚本实测生成,随版本记录

行内:离线运行 Docker · --network none

注册
预留签名 → 质量门 → 模板

至少 2 张;模板加密钩子由行内 KMS 提供

校准
开发集 → 阈值文件

用贵行自己的真签与伪造,按目标误受率定阈值

核验
单据 → 评分 → 三区间

通过 / 复核 / 重点复核

审计
每次核验一行 JSONL

模型哈希、阈值版本、区间与理由码

唯一的跨界物:3 个 ONNX 文件及其 sha256。训练数据、代码仓库、GPU 均不进入行内;行内数据也没有任何回传通道。
Ch.2 · 方案 · 整体架构07
Ch.2 · 方案 · Decision zones

三个区间,没有「拒绝」 系统负责排序和分流,人负责最终判断

1
裁切与去线

签名框图像,固定分辨率;去除印刷横线

›
2
质量门

尺寸、对比度、墨迹占比不合格即带理由码转人工

›
3
特征

3 个成员各出特征,归一化后拼接

›
4
评分

该客户专属分类器:自己的参考签名 vs 他人真签

›
5
分区

与两个阈值比较,输出区间 + 理由码

accept

通过

  • 分数高于通过阈值
  • 参考样本不足时阈值自动更严
  • 可按行规抽检
  • 同样写审计日志
review

复核

  • 落在两个阈值之间
  • 进入常规人工复核队列
  • 附上最相似的参考样本
  • 阈值由行内开发集校准
priority_review

重点复核

  • 分数低于目标误受率阈值
  • 或图像未过质量门
  • 优先由资深复核员处理
  • 仍然不是「拒绝」

为什么坚持不自动拒绝

  • 在 1% 误受率的工作点上,真签被打低分的比例仍然很高(第三章给实测数)—— 自动拒绝会直接伤到真客户。
  • 每个判定都带理由码(如 low_reference_count、quality_low_contrast),复核员看得到系统为什么这么分。
  • 区间的两个阈值都由贵行开发集按目标误受率定出,不是我们预设的。
Ch.2 · 方案 · 现场流程与三区间08
Ch.2 · 方案 · Delivery model v1

交付模型 v1:三个成员,一条干净的许可链 没有一张公开签名基准图进入训练

成员与来源

成员结构 / 初始化训练数据sha256 前缀
D2fResNet18 · 随机初始化SynCN + 5 个 CC BY 来源4af9190c59c6
D5ResNet18 · 随机初始化D2f 数据 + 3 个 CC0 / CC BY 手写来源6cf5e3fbae04
D9ConvNeXt-T · DINOv3 预训练同 D541474669c54d

来源全部登记在 commercial.SOURCES;归属声明 DELIVERY_NOTICE.md 由程序生成,不手写;哈希可与收到的文件逐一核对。

没有进入训练的

  • ChiSig、CEDAR、BHSig、GPDS 等公开签名基准
  • SigNet、FKD 等非商用权重(不做蒸馏教师)
  • 任何需要审批或「仅限研究」的数据
  • 任何银行或客户的真实签名
唯一的附带义务:D9 派生自 DINOv3,分发时须附 DINOv3 License 原文,并遵守其贸易管制条款。

登记在册的公开来源 另加自研合成数据 SynCN,共 9 个

Raparin / Firat offline handwriting signatures · CC BY 4.0 SignatureAuth · CC BY 4.0 BFL Brazilian Forensic Letter · CC BY 4.0 CERUG-EN word images · CC BY 4.0 Handwritten Chinese Numbers · CC BY 4.0 Toloka WhoSigned? · CC0 CCSD character-level handwriting · CC BY 4.0 Handwritten Signatures · CC0
含义:评测里用到的公开基准对交付模型而言全部是没见过的数据 —— 第三章的每一列都是留出测试。
Ch.2 · 方案 · 交付模型与许可链09
Ch.2 · 方案 · Bank-side adaptation

贵行可以自己做的一步:AdaBN 只用真签、不训练、在开发集上决定要不要

STEP 1
adapt-bn

用至少 200 张行内真签重估 BatchNorm 统计量;不碰伪造、不反向传播

›
STEP 2
两份开发集分数

原模型与适配后模型各对同一批开发集打分

›
STEP 3
compare

按目标误受率下的误拒率选优,EER 打破平局;样本不配对即拒绝比较

›
STEP 4
再注册、再校准

新文件哈希不同;模板和阈值只为选中的模型生成

它能做什么 实测,SigComp-CN 12 参考

16.2%
原模型 EER
11.4%
AdaBN 后
11.7%
最强对手

扫描条件与训练数据差异大时,重估统计量能把特征分布拉回到训练时的状态。

它的代价 实测,ChiSig 4 参考

13.9%
原模型 EER
15.1%
AdaBN 后
15.4%
最强对手

差异本来就小时,重估反而丢掉了训练时学到的、更好的统计量。

# 每个成员各适配一次(只用真签),再把两份开发集分数配对比较
run adapt-bn --onnx /models/d2f.onnx --out /data/d2f_bank.onnx /data/adapt_genuine/*.png
# run score:同一批开发集人员,原模型与适配后模型各打一次分 → dev_plain.npz / dev_adabn.npz
run compare --scores plain=/data/dev_plain.npz adabn=/data/dev_adabn.npz --target-far 0.01
结论:效果取决于扫描设备,所以不能由我们替贵行决定 —— 两个都量,用 compare 选。
Ch.2 · 方案 · 银行侧自适应10
03
Evidence
证据
18 个已发表或开源的对手,15 列基准,逐对比较。输的地方也写出来。
评测协议15 列基准总表中文与银行工作点跨语种留出集诚实的局限
sigverify-onsite
11
Ch.3 · 证据 · Protocol

「赢」的定义写在代码里 不是平均值好看就算赢

① 同一套协议 WD

每位用户一个分类器,用自己的参考签名对抗他人的真签。所有模型只换特征提取器,其余完全相同。

② 逐对比较 paired

同一折、同一组参考样本上比较。我们的每一个种子都必须在至少 60% 的配对单元上赢过最强对手,且平均更低。

③ 对手场完整 18 个

任何一个对手在某列没跑完,这一列就不许宣称胜出。见过该数据集作者的对手不计入最强对手。

多种子 ≥ 3

每个配置至少 3 个独立训练种子;一个种子不达标,整列不算赢。v1 配方已用全新种子 3–5 完整复现:11/15 列胜出。

维度公平 gamma 随特征维度缩放

不同模型的特征维度不同,SVM 的核宽度按维度归一,避免高维模型被默认参数吃亏或占便宜。

一条真实的判定记录 ChiSig 4 参考 · v1 的 3 个种子,各自对最强对手的平均差与配对胜数

vs FKD ResNet18 (Tsourounis 2025): Δ-1.62 10/15, Δ-2.11 12/15, Δ-0.80 9/15

这意味着

  • 总表里的「胜」是一个严格的、可复算的判定,不是挑出来的最好看的那次运行。
Ch.3 · 证据 · 评测协议12
Ch.3 · 证据 · Benchmark

15 列基准总表 熟练伪造 EER %(越低越好),各配置多种子平均

基准最强对手对手v1判定v1 + AdaBN判定新种子复现
ChiSig 中文(4 参考)FKD ResNet18 (Tsourounis 2025)15.413.9胜15.1未达未达
ChiSig 中文(4 参考) · FRR@FAR1%FKD ResNet18 (Tsourounis 2025)69.465.2胜68.6未达胜
ChiSig 中文(2 参考)DetailSemNet (ECCV 2024)18.917.6未达18.8未达未达
SigComp-CN 中文(12 参考)SigNet (Hafemann 2017)11.716.2未达11.4未达未达
SigComp-CN 中文(4 参考)SigNet (Hafemann 2017)22.426.0未达20.0胜未达
SVC2004 中英(10 参考)Multi-task Triplet (Viana 2023)13.710.5胜10.3胜胜
SVC2004 中英(5 参考)Multi-task Triplet (Viana 2023)18.915.3胜15.2胜胜
CEDAR 英文SigNet (Hafemann 2017)6.74.9胜5.0胜胜
BHSig 孟加拉文SigNet (Hafemann 2017)5.02.4胜2.3胜胜
BHSig 印地文Multi-task Triplet (Viana 2023)5.03.6胜3.3胜胜
SOHI 阿萨姆文(12 参考)FKD ResNet18 (Tsourounis 2025)5.54.8胜5.0胜胜
SOHI 阿萨姆文(4 参考)FKD ResNet18 (Tsourounis 2025)8.27.0胜7.0胜胜
ICFHR2018 泰文SigNet-S (Viana 2023)3.83.1胜3.3胜胜
TRSig 土耳其文Multi-task NT-Xent (Viana 2023)8.26.8胜6.1胜胜
SigComp2009 荷兰文SigNet-S (Viana 2023)9.76.8胜7.0胜胜
读法:v1 胜 12/15 列,v1 + AdaBN 胜 11/15 列,新种子复现 11/15 列。分别报告、不按列挑优;选哪个由贵行开发集上的 compare 决定。
Ch.3 · 证据 · 15 列基准总表13
Ch.3 · 证据 · Chinese & operating point

中文熟练伪造与银行工作点 ChiSig · 4 张参考签名

v1 · EER
13.9%
最强对手 15.4%
v1 · FRR @ FAR 1%
65.2%
最强对手 69.4%
新种子复现 · EER
14.2%
均值更低,未过逐对判定
研究轨上限 · EER
8.8%
用了非商用数据,不交付

什么是「银行工作点」

在开发集上把阈值定到熟练伪造误受率 1%,再看测试集上有多少真签落到阈值以下。这比 EER 更接近银行的实际取舍:先锁住风险,再看给复核员增加多少工作量。阈值只用开发集人员定,测试人员不参与。

这个数字该怎么读

误受率锁在 1% 时,约 65.2% 的真签会落入重点复核 —— 已优于所有对手,但离「自动化」很远。这正是我们坚持三区间、不自动拒绝的原因。

研究轨是什么

用 ChiSig 等非商用数据训练的对照模型,不交付。它的作用是给出「用真实中文签名继续训练」能到达的参考水平,也是试点之后的改进方向。

带走的一句话

  • 银行工作点(FRR @ FAR 1%)上,v1 与新种子复现都判定胜出;EER 上 v1 胜出,复现均值仍更低但未过逐对判定 —— EER 的领先对训练种子敏感。
  • 研究轨 8.8% 说明:用真实中文签名继续训练,还有明显空间。
Ch.3 · 证据 · 中文与银行工作点14
Ch.3 · 证据 · Held-out scripts

没见过的语种,照样胜出 四个非中英文语种,从未进入训练与选型

泰文 · ICFHR2018
3.1%
SigNet-S (Viana 2023) 3.8%
土耳其文 · TRSig
6.8%
Multi-task NT-Xent (Viana 2023) 8.2%
荷兰文 · SigComp2009
6.8%
SigNet-S (Viana 2023) 9.7%
阿萨姆文 · SOHI
4.8%
FKD ResNet18 (Tsourounis 2025) 5.5%

为什么这一页比总表更有说服力

总表的中文与英文列在开发过程中反复看过,存在「对着测试集调」的风险。泰文、土耳其文、荷兰文三个基准是在配方冻结之后才接入的:泰文 900 张真签 / 360 张伪造,土耳其文 1,408 / 1,334,荷兰文 222 / 624。它们的结果,是模型对全新书写体系的真实泛化。

判定记录 各种子对最强对手的平均差与配对胜数

泰文 vs SigNet-S (Viana 2023): Δ-0.82 5/5, Δ-0.82 4/5, Δ-0.58 4/5
土耳其文 vs Multi-task NT-Xent (Viana 2023): Δ-1.29 5/5, Δ-1.02 4/5, Δ-1.84 5/5
荷兰文 vs SigNet-S (Viana 2023): Δ-1.99 4/5, Δ-3.27 5/5, Δ-3.24 5/5

结论

  • 四个留出语种全部判定胜出,对手包括 SigNet-S 与 Viana 2023 等用非商用数据训练的模型。
Ch.3 · 证据 · 跨语种留出集15
Ch.3 · 证据 · Limitations

诚实的局限 这些是我们没赢、或还不能保证的地方

① SigComp-CN 12 参考:未达

原模型 16.2%,AdaBN 后 11.4%,SigNet 11.7%。平均已略好,但没过「每个种子 60% 配对胜」的判定,所以不宣称。

② ChiSig 2 参考:未达

v1 平均 17.6%,对手 18.9%:平均更低,但配对胜率不够。参考样本越少,个体差异越大。

③ AdaBN 是取舍,不是升级

它让 SigComp-CN 4 参考从 26.0% 降到 20.0% 并胜出,却让 ChiSig 从 13.9% 升到 15.1%。必须在贵行数据上量。

④ 阈值必须在行内重定

演示站的阈值是在合成数据上定的:真实签名图库的排序 12/13 正确,但所有真实样本都落进了重点复核。阈值不能跨数据源搬用。

⑤ 繁体签名:没有公开基准

公开的中文签名库以简体为主,我们今天给不出繁体的数字。这是试点的必测项。

⑥ 伪造强度来自数据集

公开库的熟练伪造由志愿者模仿完成;真实作案者可能更强。试点应纳入贵行的历史伪造案例。

我们的立场:这四条写进了交付文档。试点的目标之一,就是用贵行真实数据把 ① ② ⑤ ⑥ 变成可量化的结论 —— 无论结果好坏,都写进试点报告。
Ch.3 · 证据 · 诚实的局限16
04
Robustness & Go-live
鲁棒性与上线
基准是干净的白纸;支票不是。上线前要知道哪些因素会把所有模型一起打垮。
支票背景探针部署与 CPU 性能安全与审计
sigverify-onsite
17
Ch.4 · 鲁棒性 · Cheque backgrounds

支票背景探针:尺度是第一杀手 SSBI · 55 种支票底纹 · 4360 个裁切

模型尺度随机固定尺度固定尺度 + 去横线
SigNet (Hafemann 2017)44.16.25.4
SigNet-S (Viana 2023)32.34.93.9
FKD ResNet18 (Tsourounis 2025)37.210.06.0
交付成员 D2f29.03.32.7
交付成员 D2f + D5 集成29.43.12.4

指标:同一签名叠在不同底纹上 vs 熟练伪造的 EER(%,越低越好)。D9 未参与此探针。

尺度随机

模拟扫描分辨率不统一:同一签名以不同大小出现在底纹上。

固定尺度

按墨迹宽度对齐到训练尺度,相当于全行统一扫描 DPI。

+ 去横线

再去掉支票上的印刷横线,只留签名笔画本身。

上线前必须做的两件事

  • 固定扫描分辨率(训练尺度为 300 dpi):尺度一变,包括已发表模型在内全部失效。
  • 去除印刷横线对每个模型都有帮助;但签名可能用红笔时,不要启用去红章步骤 —— 它会把签名一起去掉。
  • D9 尚未补测;在此之前,不把两成员的结果外推到三成员集成。
Ch.4 · 鲁棒性 · 支票背景探针18
Ch.4 · 上线 · Deployment & CPU

纯 CPU,单张约 41.1 毫秒 AMD EPYC 7R32(16 vCPU) · onnxruntime 实测 p50

集成 · 4 线程
41.1ms
三成员之和
集成 · 1 线程
127.1ms
最保守口径
ConvNeXt 成员 · 4 线程
26.1ms
占集成大头
ResNet 成员 · 4 线程
7.5ms
每个
成员1 线程 p50 (ms)4 线程 p50 (ms)sha256 前缀
D2f · ResNet1827.77.54af9190c59c6
D5 · ResNet1827.77.56cf5e3fbae04
D9 · ConvNeXt-T71.726.141474669c54d

交付物

  • 离线 Docker 镜像:依赖按锁文件哈希安装,运行层无 pip / uv
  • 三个 ONNX 文件 + sha256;模型目录只读挂载
  • 一键冒烟脚本:在断网环境跑完注册→校准→核验

不需要的

  • GPU、PyTorch、任何外网访问
  • 把数据交给我们 —— 校准、自适应全在行内命令完成
  • 改动现有影像系统:输入就是签名框图像

冒烟脚本做什么

  • 断网启动容器,加载 3 个成员
  • 注册 → 校准 → 核验 → 自适应 → compare
  • 输出本机延迟与每一步的结果
口径:数字为单张签名特征提取的中位延迟,由 release_facts.py 在发布文件上实测生成;贵行硬件不同,冒烟脚本会给出本机数字。
Ch.4 · 上线 · 部署与 CPU 性能19
Ch.4 · 上线 · Security & audit

安全与审计:缺什么就响亮地说缺什么 不做静默降级

账号标识

账号以 KMS 下发的密钥做哈希后才进模板目录与日志。未配置密钥时退回无密钥 sha256,并在每一行审计日志标注 sha256-unkeyed。

模板加密

模板是特征向量,属于生物特征数据。加解密钩子由行内提供;未配置时启动即告警,并在每个模板元数据写 encryption: "none"。

审计日志

每次核验一行 JSONL:模型哈希、阈值版本、区间、理由码。复核员与审计都能回溯「当时用的是哪个模型、哪版阈值」。

模型与阈值绑定

模型哈希覆盖集成的每个成员且有序;不同模型的模板与阈值不会混用,换模型必须重新注册与校准。

贵行提供用途缺失时系统怎么做
KMS 密钥 SIGVERIFY_ID_KEY账号的密钥哈希退回无密钥 sha256,每行审计标 sha256-unkeyed
加解密钩子模板加密存储明文存储,启动告警,元数据写 encryption: "none"
负样本池(他人真签)每位客户分类器的负例拒绝注册:no_negative_pool
开发集人员(真签 + 熟练伪造)按目标误受率定阈值拒绝核验:no_thresholds;伪造不足时阈值文件写警告
设计原则:「检查失败」和「检查通过」在日志里必须长得不一样,任何降级都留痕。另需注意:负样本池不得包含正在注册的客户本人。
Ch.4 · 上线 · 安全与审计20
05
Next steps
下一步
用贵行自己的数据,把今天的每一个结论重新量一遍。
试点计划常见问题总结
sigverify-onsite
21
Ch.5 · 下一步 · Pilot

试点五步 每一步都有可验收的产出,全部在行内完成

STEP 1
环境就绪

导入镜像与模型,核对 sha256,断网跑通冒烟脚本

›
STEP 2
准备开发集

固定分辨率扫描;真签 + 熟练伪造;负样本池

›
STEP 3
选模型

原模型 vs AdaBN,compare 决定

›
STEP 4
校准阈值

按贵行目标误受率生成阈值文件

›
STEP 5
影子运行

与人工并行,不影响业务,只比较

步骤验收标准负责方
环境就绪三个文件 sha256 与发布记录一致;冒烟脚本在 --network none 下通过贵行运维 · AWS 远程支持
准备开发集开发集人员与测试人员不重叠;熟练伪造数量足以支撑目标误受率(不足时阈值文件会警告)贵行业务与影像
选模型得到一份配对的 compare 报告,记录选择理由贵行 · AWS 协助解读
校准阈值留出人员上的实测误受率接近目标值贵行
影子运行得出「重点复核命中的伪造比例」与「通过区间的真签比例」两个业务数字贵行业务 · AWS 复盘

试点前贵行准备

一台断网的 x86 服务器;固定分辨率扫描的开发集;负样本池;KMS 密钥与加解密钩子。

试点结束时贵行得到

一份 compare 报告、一份阈值文件、影子运行的两个业务数字,以及是否上线的决策依据。

我们提供:镜像、模型、运维手册与远程支持;不接触贵行任何签名数据。
Ch.5 · 下一步 · 试点计划22
Ch.5 · 下一步 · FAQ

常见问题 技术团队最常问的六个

Q1 能用贵行数据继续训练吗?

可以,且研究轨结果说明有空间。但训练要 GPU 与数据治理审批,建议在试点数字出来后再立项,训练数据同样要走许可登记。新模型照样要过同一套 15 列判定。

Q2 繁体与简体签名有区别吗?

模型看的是笔迹形态而非字符本身。但公开基准以简体为主,繁体签名的效果必须在贵行开发集上验证,这是试点的必测项,开发集应按简繁比例抽样。

Q3 客户签名随年龄变化怎么办?

模板可随新的已核验签名更新;参考样本越多越稳,少于 4 张会被标注并收严阈值。更新只能用已人工确认的签名,否则伪造会被学进模板。

Q4 为什么不用大模型或云 API?

我们实测了 DINOv2/v3、SigLIP 2 等通用视觉模型作为对手,直接用都不如专门训练的模型;云 API 则不满足数据不出行。通用模型的数字都在总表的对手里。

Q5 模型更新怎么交付?

新文件、新哈希。模型哈希变化后旧模板与阈值不会被误用,需要重新注册与校准;冒烟脚本可在断网环境先验证新版本,再切换生产。

Q6 能处理在线手写板签名吗?

当前是离线图像核验。手写板轨迹可以渲染成图像接入(演示站已这样做),但未针对笔速、压力等动态特征优化;如有需要,可作为独立课题评估。

更多问题:部署与运维细节见交付包内的运维手册;判定明细可按列逐条提供。
Ch.5 · 下一步 · 常见问题23
Ch.5 · 下一步 · Summary

总结 三句话

约束

数据不出行,系统不拒绝

  • 断网容器 + 三区间
  • 每个降级都留痕
  • 交付模型许可链干净
  • 贵行自己运行、自己校准
  • 缺什么就报什么
证据

12/15 列严格胜出

  • 18 个对手、逐对、多种子
  • 新种子复现 11/15 列
  • 四个留出语种全胜
  • 输的地方写在交付文档里
  • 每个数字由程序生成
  • 判定规则写在代码里
上线

固定分辨率,行内校准

  • CPU 单张约 41.1 ms
  • AdaBN 由 compare 决定
  • 阈值必须用贵行数据定
  • 先影子运行,再决定上线
  • 不需要 GPU 与外网
严格胜出
12/ 15 列
交付模型 v1 · 复现 11/15
对手
18个
已发表或开源
ChiSig 银行工作点
65.2%
对手 69.4%
CPU 单张
41.1ms
4 线程 p50

我们的请求

  • 一份固定分辨率扫描的开发集(真签 + 熟练伪造),和一个断网的测试环境 —— 其余都由交付包完成。
  • 试点结束时,用影子运行的两个业务数字决定是否上线。
Ch.5 · 下一步 · 总结24
谢谢
银行离线手写签名核验 · sigverify-onsite
AWS · Neo 孙
Solutions Architect Amazon Web Services
会后可提供:
· 15 列基准总表与判定明细
· 交付模型归属声明与许可原文
· 部署与运维手册