医疗单据隐私脱敏实战：OCR+视觉大模型+四点定位

医疗单据隐私脱敏这件事，最开始是被一个很具体的需求逼出来的。某次项目评审会上拿到一批真实拍摄的医疗单据照片——有折叠过的、有斜着拍的、有一半落在阴影里的。当时团队用的方案还是固定矩形框打码，效果只能用惨不忍睹形容，不是漏掉关键信息，就是把整片内容糊掉。后来前后打磨了两三个月，反复试错，最终落地了一套"OCR + Vision LLM + 四点定位打码"的组合流程，把弯曲、旋转、复杂拍摄场景都兜住了。现在项目已开源，这篇就把从设计到落地的完整思路写出来，包括哪些方案试过又放弃、哪些参数是反复调出来的、部署时会踩到的坑，一次性讲透，给正在做医疗数据合规、隐私计算相关工作的朋友做个参考。

1. 项目概述与需求拆解

1.1 医疗单据脱敏为什么这么难做

医疗单据和普通文档脱敏完全是两码事。一张普通合同或票据，敏感信息通常集中在一两个固定区域，用模板就能定位。但医疗单据的信息布局五花八门：门诊发票、住院清单、检查报告、药品处方，甚至手写的病程记录，版式差异极大。患者姓名、身份证号、联系电话往往散落在不同角落，诊断结论、用药记录这些高度敏感的内容更是混在大量正常文字中间。

更让人头疼的是单据本身的状态。医院打印的清单纸张普遍偏薄，打完折起来塞口袋里，拿出来拍张照，纸面就有明显的折痕和弯曲；从侧面拍还会产生透视变形；光线不足时字体和底色对比度下降。这些现实因素意味着任何基于固定位置的打码方案都不可靠，必须做到"内容理解级别"的脱敏——先搞清楚图像里哪块区域是什么、写了什么，再做判断和处理。

我一开始天真地想用现成的PDF脱敏工具，结果输入是照片而不是电子文档，第一步就卡住了。后来才意识到，面向拍摄场景的脱敏本质上是一个计算机视觉问题，而不是格式处理问题。整个项目的核心矛盾在于：在图像质量参差不齐的前提下，如何准确识别出所有敏感区域，同时不误伤正常内容，还能保证处理速度达到可用的级别。

1.2 技术选型：为什么偏偏是这三个组件

这套方案里三个组件各司其职，缺一个都会翻车。

OCR负责把图像里的文字变成可搜索的文本块，并给出每个文本块在图像中的坐标位置。这一步解决了"信息在哪"的问题。没有OCR，后面的一切都是空中楼阁。单纯用目标检测模型去做区域框选也行，但医疗单据里的敏感信息不完全是固定类型的，比如手写的病历和打印的报告混在一起，检测模型很难泛化。OCR的文本检测框天然覆盖了所有文字区域，相当于一个更大的召回池。

Vision LLM负责做语义判断。OCR只能说"这一块有文字"，但不能说"这一块是患者姓名，需要打码"。医疗单据里的敏感信息种类多样，即使同一个字段在不同医院、不同年代的单据里写法也不同。规则匹配（比如正则匹配身份证号）只能覆盖格式规范的场景，而视觉大模型可以从版面结构和上下文语义两个维度去理解"这块内容到底是不是敏感信息"。它弥补了OCR没有语义理解能力的短板。

四点定位打码是最后一道几何精修。OCR给出的检测框通常是轴对齐矩形，但真实拍摄场景里单据往往是旋转、透视变形的。矩形框在倾斜条件下无法精确贴合文本区域，框大了糊住周边内容，框小了遮不严信息。四点定位用任意四边形去刻画敏感区域边缘，再配合透视校正，实现像素级贴合。

这个选型不是设计出来的，是被实际问题逼出来的。最开始只有OCR + 规则匹配，弯曲场景翻车率超过三成；加入四点定位后，几何精度上来了但语义判断还是靠正则，遇到手写体就抓瞎；最后引入Vision LLM做兜底，才把误判率压到了可接受范围。

2. 整体架构与核心设计思路

2.1 三段式流程与数据流转

整个处理管线分为五个环节：图像预处理、OCR检测、候选框生成、语义筛选、几何精修与打码。它们之间的数据流转是标准的流水线模式，前一个环节的输出是后一个环节的输入。

图像预处理做的事很基础但很重要：统一分辨率到合理范围（比如长边不超过2000像素）、做一次自适应直方图均衡化提升对比度、用高斯模糊降噪。这些操作不是为了美图，而是为了让OCR识别率更稳。实际测试下来，预处理前后OCR的准确率差距能有五六个百分点。

OCR检测环节输出的是文本检测框列表，每个框包含四角坐标和识别文字。候选框生成阶段把这些原始检测框根据位置关系做了合并：同一行内距离较近的多个小块合并成一个候选区域，避免同一句话被拆成好几个碎片导致后面的语义判断混乱。合并后还会过滤掉面积过小、明显是噪声的检测框。

语义筛选环节把每个候选区域裁成小图，连同提示词一起送给Vision LLM，让它返回"敏感/非敏感"判断和敏感类型。这一步消耗的算力最多，所以必须确保上游OCR的召回率足够高，否则漏检部分进不到这个环节。

几何精修和打码是最后一环。拿到敏感的候选区域后，提取它的文本检测框四角坐标（注意不是合并后的矩形框），做透视拟合和四点定位，得到一个贴合文本行的任意四边形。再对这个四边形做膨胀处理，覆盖住文字外缘的墨迹，最后填充纯色块打码。

整个过程从输入图片到输出结果，平均耗时在2秒左右（具体跟配置和模型推理引擎有关，后面细说）。对批量离线处理场景完全够用，但不能期望做到视频实时。

2.2 四点定位打码的几何原理与实现要点

为什么矩形框在真实场景里不够用？看一张斜着拍的票据就明白了。文本检测框是轴对齐矩形，但图像里的文本行本身沿着单据的纹理方向排列，拍摄时角度一歪，文本行是斜的，矩形框就会在上下两端包含大量空白区域，左右两端反而可能切掉字符边缘。

常规做法是为每个文本区域计算最小外接矩形，这解决了旋转问题，但处理不了透视变形。真正的透视变形下，一个标准的方形文本区域在图像里会变成梯形或任意四边形，最小外接矩形依然框不准。这时就需要四点定位，用四边形去贴合区域的真实边界。

实现上有两种思路。第一种是直接用OCR文本检测模型返回的多边形坐标。很多检测模型天生输出任意四边形，比如文本检测常用的不同检测算法，返回的检测框天然是带角度的四边形。第二种是获取到敏感区域后，去检测单据纸张的边缘，计算纸张的四角坐标，做透视校正后再映射回去。实际项目中我采用的是第一种思路，更直接。

四点定位之后还有个关键操作：坐标膨胀。打码区域不能刚好贴合文本框边缘，因为OCR检测框通常比实际字符的外缘内缩了几个像素，刚好贴合就会露出一点墨迹。膨胀系数我调到了1.2倍，也就是每个方向外扩一定的比例。太小遮不住边缘，太大会把邻近的表格线、文字框一并盖掉，这个值需要结合具体数据微调到合理区间。

2.3 Vision LLM为什么是必要环节

很多人问，能不能不用视觉大模型，纯靠规则搞定？我的答案是：可以做，但召回率到不了可用水平。医疗场景里最怕的是漏脱敏，漏一个患者姓名或诊断信息，比误伤十行正常文字的后果都严重。纯规则方案能完美覆盖身份证号（正则表达式相对成熟）和手机号，但面对手写的患者姓名、不规范的住址、诊断结论的医学术语变体，就完全无能为力。

Vision LLM在这里扮演的角色是"语义兜底"。它看的是整块区域的图像内容，结合上下文判断"这块是不是敏感信息"。比如一段文字写着"诊断：高血压"，它知道这是诊断信息；一段文字写着"主治医师：张三"，它知道这是医生信息，通常情况下医生名不需要打码，除非业务方要求连医生姓名也隐藏。这是规则引擎做不到的粒度。

提示词设计是这一环节效果好坏的分水岭。我试过好几版提示词，最初用一句话"判断图中是否有敏感信息"，效果飘忽不定，后来改成结构化提示词：先明确敏感信息的分类标准，标明每类的具体定义和示例，再要求模型按固定JSON格式返回，效果立刻稳定了很多。

提示词里还要特别强调一点：不能只靠文本内容判断，还要结合版面位置。比如"姓名"两个字如果出现在表格头部，通常是字段名，不需要打码；但如果它后面跟了一串实际姓名，就需要打码。Vision LLM能同时理解文字和版式，这是它和纯文本LLM的本质区别。

3. 实操过程与关键步骤

3.1 环境搭建与模型选择

项目的主干代码用Python写的，依赖的核心库包括OpenCV（图像处理）、一个主流OCR框架（用于文字检测与识别）、以及一个视觉语言模型的推理框架。OCR部分我最初在两个方案之间纠结：一个中文识别效果好、部署重一些；另一个轻量、推理快但复杂版面稍弱。两条路都实测过，最终选了前者——医疗场景对中文识别准确率的要求远高于部署便捷性，只要准确率高，多花点资源值得。

Vision LLM的选择相对开放，因为这部分走标准的HTTP调用接口或本地推理均可。建议直接使用支持OpenAI兼容接口的视觉模型服务，方便替换不同模型做A/B测试。实测下来模型参数量从7B到几十B的都有可用的表现，但小模型在复杂版式理解上明显吃力，容易把表格标题误判为敏感信息。实际项目用的模型，我建议至少在10B这个规模以上，效果才有保障。

基础环境推荐的配置是：CPU至少8核，内存16GB以上，GPU建议不低于16GB显存。纯CPU也能跑，但OCR批量处理速度会慢3到5倍，Vision LLM部分在低端CPU上基本跑不动，只能走API。所以要么有GPU，要么接云端服务，否则体验会比较痛苦。

3.2 OCR检测与文本定位的实现细节

OCR部分我是按两步走的：先用文本检测模型拿到每个文本行的多边形坐标，再用识别模型输出对应文字内容。这个"检测+识别"分离的架构比端到端方案更灵活——检测框可以独立用于打码定位，识别文字可以独立用于后续语义分析。

具体到代码实现，核心逻辑大概这样：

bash复制# 安装核心依赖
pip install opencv-python
pip install paddleocr        # 这里选用中文识别友好的OCR框架
pip install requests          # 用于调用视觉LLM接口

OCR初始化和调用：

python复制from paddleocr import PaddleOCR

ocr = PaddleOCR(
    det_model_dir='det_model',      # 文本检测模型
    rec_model_dir='rec_model',      # 文本识别模型
    use_angle_cls=True,             # 开启文本方向分类
    lang='ch',                      # 中文识别
)

result = ocr.ocr(image_path, cls=True)

返回结果里每个字段都包含一个四元素的坐标列表（左上、右上、右下、左下）和识别出的文本内容。这一步得到的坐标就是后续打码的原始依据。

实际操作中，我注意到返回坐标的精度受检测模型推理尺寸影响很大。默认推理尺寸在长边960像素，对于手机拍摄的高清单据，长边动辄3000像素以上，直接做全尺寸推理会导致小字漏检。解决方法是把推理尺寸上限调高到1600或1920，代价是显存占用翻倍、推理时间增加约40%，但小字召回率的提升非常明显。这个取舍做下来完全不亏。

还有一点值得注意：医疗单据的底纹常常带有浅色网格或水印，会影响检测模型的置信度。遇到这类情况，建议在预处理阶段加一步去底纹操作，比如用形态学变换分离背景，或者直接做一个简单的自适应二值化。

3.3 敏感信息分类与筛选的提示词工程

Vision LLM部分的效果，七分在提示词，三分在模型。我把提示词写成了一个多段结构，每段职责清晰，实测下来比一段式指令稳定得多。

第一段定义角色和任务："你是一个医疗单据隐私审查助手，负责判断图像中是否包含个人敏感信息。"第二段给敏感信息分类标准，我这里定义了五类：个人信息（姓名、身份证号、电话、住址）、诊疗信息（诊断结论、检测结果、医嘱内容）、费用信息（医保卡号、支付账号）、经办信息（患者签名、家属签名）、其他（条形码、二维码中可能包含的敏感数据）。

第三段明确判断规则："只根据图像中出现的文字内容判断，不推测未显示的信息；表格字段名（如'姓名''诊断'）本身不算敏感信息，其对应的填入值才算；空白区域不判断为敏感。"第四段要求输出格式："只返回JSON，格式为{'contains_sensitive': bool, 'sensitive_type': str, 'confidence': float, 'reason': str}。"

这个结构化提示词带来的直接收益是：模型返回的JSON可以被代码直接解析，省去了自然语言解析的麻烦；同时把判断规则显式化之后，误判率下降了大概一半。校验的时候发现，凡是模型在reason字段里写了类似"图像中文字显示为患者姓名"这样的具体依据时，判断基本是准的；凡是reason写得模棱两可、含糊不清的，判断结果就不可靠，这种样本会被单独捞出来人工复核。

请求发出去之后，系统会做一轮后处理校验。比如模型把某个区域判为不含敏感信息，但OCR识别文本里包含形似身份证号的长串数字，系统会直接覆盖模型结论，转而判定为敏感。这种"OCR兜底+LLM兜底"互相校验的机制，是目前整个管线召回率的最重要保障。

3.4 四点定位与打码的坐标映射

打完语义筛选，拿到敏感候选区域列表后，打码环节需要精确操控坐标。我把坐标处理拆成三步：粗定位、透视拟合、坐标映射。

粗定位阶段，把OCR返回的敏感区域检测框四角坐标直接取出来。因为检测框是任意四边形，天然匹配倾斜文本行，比矩形框贴合度好太多。

透视拟合阶段，由于OCR检测框的四个角点可能因检测噪声略微偏移，我会对这四点做一个微调——计算四边形的长宽比，如果畸变过大（比如一条边比另一条短超过30%），则判定为异常检测，退回用最小外接矩形代替。

坐标映射阶段处理的是打码框到最终输出的对应关系。有一个细节经常被忽略：OCR检测坐标所在的图像分辨率，与最终输出图像的尺寸可能不一致。如果在预处理阶段缩放了图像，打码坐标必须同步缩放回去，否则打码位置会在全尺寸图上偏移。

核心代码大致如下：

python复制import cv2
import numpy as np

def mask_polygon(img, points, expand_ratio=1.2):
    # points: 4个坐标点 (x, y)，按左上、右上、右下、左下排列
    # 1. 计算质心并向外扩张
    centroid = np.mean(points, axis=0)
    expanded = centroid + (points - centroid) * expand_ratio

    # 2. 生成掩膜并填充
    mask = np.zeros(img.shape[:2], dtype=np.uint8)
    cv2.fillPoly(mask, [expanded.astype(np.int32)], 255)

    # 3. 打码填充（纯色覆盖或高斯模糊都行）
    result = img.copy()
    result[mask > 0] = (120, 120, 120)   # 灰色填充
    return result

这段代码看起来挺简单，但实际操作里有两个坑。第一个坑是坐标顺序必须一致，OCR返回的四边形点序偶尔是乱的，需要按点之间的位置关系重新排序，否则画出来的多边形是自交的。第二个坑是膨胀系数的选择，1.2倍是我基于大量样本调的基准值——对于翻拍的打印体单据够用，但如果遇到手写体，笔画比较粗，膨胀系数要再往上加到1.3甚至1.4，否则文字边缘会露出半个笔画。

4. 复杂场景应对与效果优化

4.1 弯曲褶皱单据的分段校正策略

单据弯曲是个特麻烦的问题。纸张一旦打折，字符沿着折痕两侧会轻微偏移，整行文字不再是一条直线，而是一条曲线。OCR对这种文本的检测结果表现为：同一行文字被拆成多段、每段的角度略微不同、中间可能夹杂着折痕阴影造成的误检。

第一版方案直接整张图做透视校正，结果惨不忍睹——透视校正假设整个图像平面是单一平面，但弯曲纸张其实是多个微小曲面的组合，整图校正把本来还算平的文字反而拉得更歪了。

后来换成分段处理的思路：用OCR检测结果中的文本行方向做聚类，把方向一致的检测框归为同一组，每组单独计算一个仿射变换，各自校正后再拼接。这样处理之后，弯曲单据上的文字定位准确率提升非常明显。代价是逻辑变复杂，但收益值得。

还有一种更简单但效果也不错的兜底方案：对于严重弯曲的局部区域，直接把该区域对应的候选框标记为"低置信度敏感候选"，不做精细打码，改用整体覆盖。业务上，宁可多遮一点，不可漏遮一点。这个策略在合规审查场景里尤其推荐使用，因为脱敏的后果是单向的——误伤可以接受，漏脱敏不能接受。

4.2 旋转与透视变形的几何恢复技术

旋转场景相对好处理。图像里的单据如果是整体的90度或180度旋转，OCR的方向分类器基本能解决，比如开启角度分类模型后，文字识别会自动旋转到正确的方向。真正麻烦的是任意角度的旋转，比如单据斜放15度拍照，行的方向是倾斜的，这时候OCR检测框本身已经带了角度信息，四点定位可以直接用，无需额外校正。

透视变形主要是拍摄角度导致的。手机从上往下垂直拍，单据是正矩形；低于单据平面斜拍，单据就变成了梯形。透视变形下，OCR检测框的四边形不再是矩形，相邻两边不再垂直，直接把对角线拉长会导致打码区域的形状失真。

处理透视变形有两种路线：一种是在检测前先做图像校正，把单据边缘提取出来，计算单应矩阵，把整个单据投射成正面视角，再进行常规流程。另一种是保持图像不校正，只对敏感区域的四边形本身做透视拟合，用最小二乘法把四个角点拟合成规范的四边形，再膨胀打码。

两种路线实测下来，前一种对OCR识别率的提升帮助很大（OCR对正视图的识别率远高于透视畸变图），但单据边缘提取在背景复杂时容易失败。后一种流程更稳，不依赖背景分割。我的方案是把两种结合：当图像能稳定提取到单据边缘时走校正路线；当背景杂乱、边缘提取不可靠时，退化为不对全图校正，只做四边形精修。这个双路线机制在处理真实场景数据时，成功率大概能提升十几个百分点。

4.3 光照不均与遮挡问题的兜底策略

真实的手机拍摄场景，光源方向极其不稳定。半边亮半边暗是常事，窗户反光打在纸面上形成亮斑也不少见。光照不均对OCR识别影响很大，尤其是浅色字体遇到亮斑时，检测框直接丢失。

预处理阶段的自适应直方图均衡化解决了一部分问题，但还不够。我又加了两个策略：一是多尺度retinex增强，对低照度和阴影区域有奇效，缺点是处理时间增加了约100毫秒；二是自适应阈值二值化，把图像先转成二值图再做OCR检测，对强阴影的抑制效果很明显，但会丢失一些低对比度文本细节。

遮挡问题的兜底更简单暴力：如果Vision LLM判断某个区域存在敏感信息的置信度很高，但OCR在这个区域没检测到任何文本（可能被反光或阴影盖住了），系统会把整块区域标记为"疑似敏感"，按敏感区域处理。判断依据是上下文的连贯性——比如前面有"患者："后面紧接着一块模糊没识别出来的区域，那这区域极大概率是姓名。

5. 常见问题与排查技巧实录

5.1 误检漏检与召回率调优的实操记录

做脱敏最怕的不是多盖几块，而是漏盖。我把漏检分成两大类：OCR漏检和语义漏检。OCR漏检指模型压根没检测到文本区域，多见于低对比度小字、弯曲折痕文字；语义漏检指OCR检测到了文本，但Vision LLM没把它判为敏感信息。

针对OCR漏检，我的策略是做两次OCR——第一次用高阈值低敏感度模式抓主要文字，第二次把推理尺寸调大、阈值调低，专门抓小字和边缘文字。两者合并去重后，检测框的召回率能提升约15%。代价是单张图片的OCR耗时增加约0.3秒，但对批量任务来说可以接受。

针对语义漏检，最有效的优化手段是"反向校验"：把OCR识别出的所有文本内容做一个正则表达式扫描和关键词匹配，凡是匹配到身份证号模式、手机号模式或医疗敏感关键词（如"诊断""既往史""用药"等）的检测框，即使Vision LLM判为不敏感，也强制升级为敏感候选。反过来，Vision LLM判为敏感但OCR没有文本内容的，也保持敏感。这个双向互检机制让整个管线的召回率从86%左右提升到97%以上。

漏检排查的具体流程建议是：先收集一批真实场景样本，把系统漏掉的敏感区域标记出来，分析是OCR没检测到，还是检测到了但没判为敏感。按比例对症下药，不要盲目调参。我拿到的典型分布是：OCR漏检占60%，语义漏检占30%，坐标精度不足导致的"看似漏检"占10%。先解决OCR漏检，收益最大。

5.2 打码误伤正常内容的边界控制

误伤是另一个维度的锅，尤其对于表格型单据，敏感字段和普通字段挨得很近。患者姓名下面一格就是登记号，身份证号旁边就是联系电话。如果打码框膨胀系数设得太大，旁边的登记号、日期就会被一并盖住，导致信息不可读。

边界控制的核心是"按需避让"。我实现了一个宽度约束逻辑：打码区域和相邻非敏感文本检测框做交并比计算，重叠超过阈值时，自动往非重叠方向收缩膨胀系数，优先保证非敏感内容完整露出。这个逻辑听起来简单，但实实在在地把误伤比例降了下来。

还有一种误伤更容易被忽视：印章。很多医疗单据上有医院盖章，印章通常是红色的圆形，拍照后有时会被OCR检测为一个文本区域。如果不加判断直接按敏感信息打码，会把公章整体糊掉——业务上经常需要保留公章图像用于法律效力核验。我的处理方案是在视觉LLM的分类体系里单独加一个"印章/非敏感"类别，让模型判断是否为印章，如果是印文章则不进行脱敏，或者可以打上细密点阵（隐藏信息但保留轮廓）。这个细节建议在对接真实业务时提前确认清楚，不同业务方对公章的处理要求差异很大。

5.3 推理延迟与并发性能优化

整条管线的性能瓶颈几乎肯定在Vision LLM环节。OCR部分在GPU上跑一张图只需几百毫秒，但Vision LLM处理每个候选区域都要一次前向推理，候选区域一多，总耗时直接翻倍上涨。

第一轮性能优化是把所有候选区域做批量推理，而不是逐个请求。把多个小图拼成一个大Batch，一次推理完成，吞吐量能提升3到5倍。但Batch太大时会超出上下文窗口限制，实测控制在8到16个区域一批比较稳。

第二轮优化是结果缓存。同一张单据如果在不同时间被重复提交（比如人工审查时回放），OCR结果和LLM判别结果都可以缓存下来，直接走缓存输出打码结果，耗时能压到几百毫秒以内。缓存键我用的图像感知哈希值，相同内容的不同尺寸照片也能命中缓存。

第三轮优化是推理引擎层面的。OCR和视觉模型都尝试用量化推理加速，精度损失微乎其微，但显存占用和推理速度的改善非常明显。量化后的视觉模型推理速度提升约40%，显存占用下降50%左右。如果没有太严苛的精度要求，量化是性价比最高的加速手段。

6. 项目部署实践与扩展思考

6.1 全流程部署的踩坑记录

部署阶段暴露出来的问题比开发阶段更多，因为真实的数据分布远比测试集复杂。第一个坑来自环境差异：开发环境用的CUDA版本和部署环境的驱动不兼容，模型加载直接报错。建议在项目文档里把CUDA、cudnn的版本组合固定下来，用容器化方案分发，能省去大量环境排错时间。

第二个坑是并发场景下的显存管理。Vision LLM模型加载后占用的显存，在批量请求时会出现动态波动。起初配置进程池时没预留足够余量，高并发下偶尔会OOM。后来把最大并发数调到显存可承载范围的60%，并加了显存预分配机制，就没再出过问题。

第三个坑是图像格式的统一。真实场景的输入图片五花八门：有HEIC格式的、有带EXIF旋转信息的、有超大尺寸的。EXIF旋转是最隐蔽的坑——某些手机拍摄的JPEG会在元数据里写入方向标记，但图像数据本身没有旋转，OpenCV默认不读取EXIF信息，直接处理会导致输出图方向错误。我的解决方案是在预处理第一步统一做EXIF方向修正，转换到标准RGB格式再进管线。

6.2 从脱敏到医疗数据合规的扩展方向

这个项目现在只做了脱敏，但脱敏只是医疗数据合规的一个环节。后续有几个很自然的扩展方向，我在项目里预留了接口和设计空间。

第一个方向是脱敏审计日志。当前系统只输出打码后的图像，没有记录"哪里被脱敏了、为什么被脱敏"。对接真实业务时，合规审计要求每张单脱敏操作可追溯。后续计划把脱敏区域坐标、敏感类型、触发规则一并记录成结构化日志，方便审计回溯。

第二个方向是数据统计与报表。把脱敏过程中识别出的敏感信息类别做统计聚合（注意是脱敏后按类型统计，不能暴露原始数据），可以得出"哪些类型的敏感信息在单据中出现频率最高"的分布曲线。这个数据对优化脱敏规则、调整资源分配都有实际价值。

第三个方向是端侧部署。当前方案对算力要求偏高，很难直接跑在手机端。后续如果针对特定场景（比如慢病管理App的拍照上传），需要对模型做进一步的剪枝蒸馏，把OCR和视觉模型都压缩到可端侧推理的规模。这在工程上很有挑战性，但一旦跑通，应用面会广很多。目前项目里已经预留了模型导出的接口，方便后续对接端侧推理框架。

我个人在实际项目里最深的一点体会是：隐私脱敏这类工具，做得好的标准不是"技术多炫"，而是"漏脱敏率多低"。一套算法表现得再完美，在真实数据集上如果漏掉一个身份证号，它带来的隐患是灾难性的。所以这个项目在设计时所有决策都是以召回率优先——宁可多打码、宁可耗时略长、宁可误伤少量正常内容，也不允许漏掉真正敏感的信息。这种取舍在技术人眼里可能不够"优雅"，但在合规业务里才是正确的。希望这个开源项目能帮到正在做类似工作的朋友，少走一些我走过的弯路。