魏金华医疗单据脱敏这件事，看着简单，做起来全是细节。很多人第一反应是“把姓名、证件号盖住不就行了”，但等你真拿手机随手拍一张病历或者检验报告试试，就会发现远不是“盖住”两个字能解决的——纸张弯曲、拍摄旋转、桌面反光、手写打印混排、模板五花八门，光是把“图上哪里写了什么”搞清楚就很费劲，更别说还要判断哪些信息算隐私、哪些内容公开出去没问题。
我做这个开源项目时，核心思路是组合三条技术线：OCR负责把图中文字和位置找出来，视觉大模型负责判断哪些内容是敏感字段，四点定位负责把弯曲、旋转的图像统一到标准坐标系上再做精准打码。简单说就是“先看懂，再判断，最后精准遮盖”。这套方案主要面向手机拍摄、相机翻拍这类复杂场景，做完以后既能保留报告里化验数值、医嘱等可用信息，又能把患者身份、病历号、联系方式这类字段彻底盖掉。
适合谁参考：医疗信息化开发者、做隐私计算或数据合规的工程团队、研究文档识别与多模态模型的算法同学，以及单纯想给自己的图片分享流程加一道隐私闸门的人。这篇文章把整体架构、技术选型、踩坑经验和完整实现路径都整理出来了，照着搭一套完全可行。
1. 先想清楚：脱敏不只是“打码”
1.1 为什么通用打码方案在医疗单据上行不通
人脸打码产品已经很成熟，大家习惯性觉得“检测到人脸然后模糊”就够用了。但医疗单据上的关键隐私几乎全是以文本形式存在的：患者姓名、住院号、身份证号、手机号、家庭住址、就诊日期、医生签名、检查设备编号。这些信息没有一个统一的视觉特征可以直接“检测”，必须靠文字识别加语义理解才能定位。
退一步，直接用正则关键词匹配行不行？我也试过，部分场景确实能盖住，比如对18位身份证号、11位手机号这类模式，规则匹配很稳定。但医疗单据最大的问题就是格式不统一：有的报告写“患者：张三”，有的写“姓名/性别：李四/女”，有的是手写体与印刷体混排，有的把电话号码拆成“区号-号码-分机”三段，还有的医院把患者ID印在条码旁边的字母数字串里。正则规则在这样的自由度面前会漏掉大量边缘情况。
更麻烦的是，隐私边界本身带有语义性。一张化验单上写着“某项传染病初筛：阳性反应”，这个检查项目名称本身就能反向关联到患者情况，必须盖；但报告顶部的“标本：血清”“仪器型号：某某生化分析仪”一般不涉及个人身份，盖了反而伤害可用性。这种判断靠关键词规则做不到，需要模型理解上下文。所以这个项目最终的定位不是“全文打码”，而是“理解内容之后，精准地只盖该盖的”。
1.2 三条管线如何分工，为什么非这么配不可
整个系统的核心是三个模块配合，我把它当成三条各司其职的管线来设计。
第一条是OCR管线。它的任务是回答两个问题：图上有哪些文字？这些文字在图像的什么位置？我需要的是文本框坐标而不是纯文本，因为后面的打码操作完全依赖坐标。OCR给出的坐标是后续一切几何操作的基础，这个环节不能糊弄。
第二条是视觉大模型管线。它拿到OCR输出的文本列表之后，逐个字段做语义判断：这个字段属于患者身份信息、联系信息、诊疗记录，还是非敏感内容？然后输出结构化的标注结果。有人会问，视觉大模型不是应该直接看图吗？没错，它确实有视觉能力，后面我会讲到什么时候用它的视觉通道。
第三条是四点定位与几何映射管线。它解决的是拍摄图像“歪了、斜了、纸弯了”的问题。通过检测单据纸张的四个角点或版面区域边界，计算透视变换矩阵，把所有敏感区域统一映射回原图上做像素级遮盖。
为什么不让视觉大模型直接看图出框？我早期确实这么试过。模型看图后给出的是大致区域，坐标误差从几个像素到几十个像素不等，对于打码这种“刚好盖住但别盖到旁边数值”的任务来说不可靠，而且看图推理的算力开销比看文本高一个数量级。让OCR管坐标、让大模型管语义，各干各擅长的，精度和成本都可控。这也是项目把“OCR + 视觉大模型 + 四点定位”并列写出来的原因，三者缺一不可。
这一分工逻辑在真实测试中被反复验证：OCR的坐标精度是像素级的，视觉大模型对语义的理解是自然语言级别的，两者恰好互补。
1.3 输入与输出边界设计
做技术项目第一步一定是把边界定义清楚，不然做着做着就跑偏了。输入方面，我支持三种形态：单张图片文件、一个文件夹下的批量图片、以及包含多页的PDF文件。实际医疗场景里最常见的是三类：医生手机拍的病历照片、患者自己上传到线上平台的检查报告拍照件、科研团队在做匿名化整理时拿到的带页眉扫描件。前两类拍摄条件差，正是这个项目的核心攻坚方向；最后一类虽然是扫描件，但页眉里往往带着医院名和科室名，同样需要处理。
输出包括两部分。第一部分是脱敏后的图片，所有被判定为敏感的区域都做了遮盖，尺寸与原图一致。第二部分是一份结构化的JSON脱敏报告，记录每个被覆盖区域的内容类型（比如patient_name、patient_id、phone）、在原图中的坐标、以及采用的打码策略。这份报告有两个用途：一是用于审计，证明哪些字段被处理过；二是用于调试，万一某次脱敏盖错或漏了，能回溯是哪一步的判断出了问题。
边界设计上还有一个重要决定：不做自动删除文字，只做原位遮盖。删除会破坏版式，一旦误删还会影响单据其余内容的可读性；原位遮盖保留了原始排版结构，哪怕误伤了也能肉眼立即发现。打码策略我做成三档可配置——马赛克、高斯模糊、纯色块，参数怎么选后面专门讲。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心模块拆解：OCR、视觉大模型、四点定位
2.1 OCR模块：先把“弯曲图像里的文字”读出来
OCR是整套系统里最考验工程经验的部分。扫描仪进纸出来的图像干净、端正、光照均匀，任何识别引擎都能稳定发挥；但手机拍的病历完全是另一个物种：纸张弯曲导致文本行呈弧线，拍摄角度产生梯形透视，桌面反光会造成大块高光，阴影会盖住部分文字，再加上机打体、手写体混排。在这种输入条件下，OCR的识别率和检测框质量直接决定脱敏效果。
我的预处理流程是固定的。先做白平衡和亮度归一化消除色偏，再做自适应对比度增强，让浅色墨迹在复杂背景里也能被捞出来。如果图像分辨率低于阈值，先做插值放大再送入识别器，OCR对低分辨率小字体的识别率会断崖式下降，这一步不能省。
版面分析也建议做。单据上除了正文，往往还有页眉、页脚、条形码、表格线甚至印章。如果让OCR对整页无差别识别，印章里的文字会和正文混在一起，表格线还会干扰文本框合并。我的做法是先检测文档主体区域，再用外接框过滤掉印章区域和条码区域，只保留真正需要判断的文本区。
引擎选型上，优先考虑中文识别效果好的开源引擎，并且一定要确认它支持旋转框输出。为什么强调旋转框？因为透视畸变和弯曲会让文本框不是水平的，如果引擎只输出水平矩形，一个跨两行的弯曲文本会被包在很大的矩形框里，打码时会把两行之外的空白区域一起盖掉，既难看又容易误伤相邻字段。OCR输出统一解析成：每个文本单元包含识别文本、类别（表格、印章、正文）、四个顶点的坐标、置信度。坐标保持浮点，不做取整，后面的几何映射阶段自然会处理。
2.2 视觉大模型模块：语义判断才是脱敏的真正核心
OCR之外，真正决定脱敏质量的是语义判断。这一步我用视觉大模型来做。需要解释一下为什么叫视觉大模型：这类多模态模型既能理解图像，也能理解文本。在这个项目里，默认模式下它主要处理OCR输出的纯文本序列；当某条文本边界模糊、规则库拿不准时，我会把对应区域裁剪成小图一并喂给模型，让它结合字形与上下文综合判断，这就是视觉通道的价值所在。
先解释为什么这个任务必须上大模型。医疗单据里常见的敏感字段包括：患者姓名、年龄（部分场景下结合日期能定位到人）、住院号/门诊号、身份证号、手机号、地址、医保卡号、就诊科室加医生签名、特殊诊断名称、检查项目名。这些字段格式不固定，还经常相互关联。举个例子，“王某，男，56岁，今日行胃镜复查，病理回报：出具了明确诊断结论”中，“王某”是姓名，诊断描述是敏感信息，年龄单独不算敏感，但一旦和姓名同页出现就要谨慎处理。这种上下文关联判断是正则规则很难覆盖的。
Prompt设计我踩过不少坑，最终稳定下来的策略是给模型一份“字段清单 + 判断规则 + 结构化输出要求”。先按阅读顺序组织OCR文本块，给每个文本块编号，然后告诉模型：你的任务是逐条判断哪些编号文本属于敏感字段。最后要求模型输出一个JSON数组，每个元素包含文本编号、判定字段类型、置信度。我刻意不让模型直接输出“盖掉/不盖掉”这种二元判断，而是让它输出字段类型，是否打码由规则层决定。原因是模型对“这个字段是不是电话号码”的判断，比“这个字段要不要脱敏”更稳定、更可解释，也更容易排查。
视觉大模型必然存在误判，所以系统里加了一个兜底规则库。凡是文本内容命中身份证号正则、手机号正则、日期时间格式，无条件标记为敏感；规则库确认敏感的，即使模型判为不敏感也会被覆盖。反过来，模型判为敏感但规则库不支持的情况，进入待人工确认队列，不直接执行打码。这套策略在实践里把漏脱敏率降到了可用范围，误脱敏率也没有明显上升。
2.3 四点定位模块：为什么是“四点”而不是“旋转到水平”
这是标题里最容易被低估、但其实最核心的模块。四点定位的本质，是计算一个透视变换矩阵，把原本弯曲、旋转、倾斜的图像区域映射到一个标准矩形上。
有人会问：直接检测倾斜角把图片转正不就行了吗？纯旋转只适合“图片倾斜但纸张是平的”这种情况。手机拍摄时镜头和纸张不垂直，会产生透视形变，原本的矩形纸张在图像里变成不规则的四边形，甚至因为纸张弯曲，四条边都不是直线了。用一个固定角度的旋转矫正根本无法压平这种变形。四点定位比旋转更普适：它不假设区域是矩形，直接把任意四个点定义的四边形变换成规整矩形，同时把原图里的所有坐标点通过同一个变换映射过去。
具体计算并不复杂，主流的开源计算机视觉库都有现成实现。核心是两个函数：根据四组对应点计算透视变换矩阵，再用矩阵对图像做重投影。但这里有一个非常关键的设计决策：四点定位不只是为了“把图摆正”方便OCR识别，更是为了建立“原图坐标”和“矫正图坐标”之间的双向映射。OCR在矫正图上读到文本框坐标，视觉大模型判断出哪些文本是敏感信息，敏感框在矫正图里的坐标再通过逆透视变换矩阵反算回原图坐标，直接在原图上打码。整个流程可以一句话总结：在正图上做判断，在歪图上做遮盖。
四个点从哪里来？我试过三种来源：版面分析模型输出的文档区域四边形、图像边缘检测后拟合出的纸张边缘、以及OCR版面结果中所有文本框的外接凸包。最稳定的是第一种，但需要额外加载版面模型；想要轻量一些，用边缘检测加轮廓拟合也能跑，只是对背景复杂的照片鲁棒性差一些。
四点定位还有一个附加收益：透视变换之后，所有输入图像被统一到了标准分辨率，OCR识别时的图像质量一致性更高，整体识别率也会提升。这一点在批量测试里体现得很明显，同一批照片直接识别和先四点矫正再识别，识别率平均能提升十个百分点左右。
3. 完整实操：从一张弯曲的照片到脱敏输出
3.1 整体流程与目录结构
直接给一个可以照着跑的完整管线。整体七步：图像预处理、四点定位与透视矫正、OCR识别、敏感字段语义标注、坐标逆变换、打码、输出报告。整条管线可离线运行，不依赖云服务，部署在普通工作站上就能处理。
代码结构大致如下：
- 输入目录：receipts_raw/
- 输出目录：receipts_processed/、reports/
- 预处理模块：preprocess.py
- 透视矫正模块：warp.py
- OCR封装模块：ocr_engine.py
- 语义标注模块：llm_classifier.py
- 打码模块：redact.py
- 主控流水线：pipeline.py
- 配置与字段规则：config.yaml、rules.py
所有可调参数集中在config.yaml里管理。不同医院、不同单据模板差异性很大，参数如果散落在代码里，调试时会非常痛苦。
3.2 关键实现：透视变换与坐标回映射
先说透视矫正的核心代码。假设已经从版面模型拿到原始图像中单据区域的四个角点，按左上、右上、右下、左下排序，并且确定了矫正图的目标尺寸，那么计算变换矩阵和重投影只需要几行：
python复制# 以常见的开源计算机视觉库为例，其Python接口提供了透视变换能力
import cv2
import numpy as np
def warp_four_points(img, src_pts, out_size=(1200, 1600)):
"""
src_pts: 原图中单据区域的四个角点，顺序为左上、右上、右下、左下
out_size: 矫正图输出尺寸 (width, height)
返回矫正后的图像和透视变换矩阵
"""
dst_pts = np.array([
[0, 0],
[out_size[0] - 1, 0],
[out_size[0] - 1, out_size[1] - 1],
[0, out_size[1] - 1]
], dtype=np.float32)
src_pts = np.array(src_pts, dtype=np.float32)
matrix = cv2.getPerspectiveTransform(src_pts, dst_pts)
warped = cv2.warpPerspective(img, matrix, out_size, flags=cv2.INTER_LINEAR)
return warped, matrix
这里的matrix是原图到矫正图的正向变换。OCR在矫正图warped上识别，拿到的是矫正图坐标系里的文本框坐标。接下来要把这些框映射回原图，使用matrix的逆矩阵，配合透视变换函数逐点映射即可。
这里有一个反复踩到的坑：做逆透视映射时，很多人直接拿逆矩阵去乘坐标向量，但透视变换是齐次坐标下的变换，简单矩阵乘法会出错。正确做法是用cv2.perspectiveTransform把多边形所有顶点一起映射，函数内部会处理齐次坐标归一化：
python复制def map_box_back(box_points, matrix):
"""
box_points: shape (N, 1, 2) 的float32数组，表示矫正图上的多边形顶点
matrix: 原透视变换矩阵
返回映射回原图坐标系的多边形顶点
"""
inv_matrix = np.linalg.inv(matrix)
mapped = cv2.perspectiveTransform(box_points.reshape(1, -1, 2).astype(np.float32), inv_matrix)
return mapped.reshape(-1, 2)
这一步如果出错，脱敏效果表现为“打码块偏移了一截”，偏移量从几个像素到一整行都有可能。建议在开发阶段把映射后的敏感多边形绘制在原图上输出一张调试图，肉眼对比打码框与真实文字位置，确认无误后再进批量流程。
3.3 OCR与语义标注的衔接：让大模型看懂字段清单
OCR输出之后，我把文本块按阅读顺序排列，并按文字在矫正图中的垂直位置分组。排序规则是：先按纵坐标粗略分成“行”，行内按横坐标排序，再把多行合并成段落编号。这样视觉大模型看到的不是一堆乱序文本，而是一个类似人类阅读顺序的编号列表。这个预处理对标注准确率提升非常明显，我对比过乱序输入和按阅读顺序输入的结果，后者的漏标率至少下降了三分之一。
Prompt模板我实际跑下来比较有效的一版是这样组织的：
- 系统角色设定：你是一个医疗文档隐私判断助手，只负责判断字段类型，不做任何修改。
- 字段定义：给出敏感字段清单及判定标准，包括患者姓名、证件号、病历号、联系方式、地址、主治医生、医院与科室、特殊检查项目名称、诊断摘要等；同时给出非敏感字段举例，如检验数值、单位、参考范围、样本类型、设备型号、日期。
- 输入数据：编号后的OCR文本列表。
- 输出要求：严格输出JSON数组，不要输出解释性文字。
解析结构化输出时要注意一个工程问题：有的模型会在JSON之外加解释，或者把JSON包在Markdown代码块里。解析时最好先剥离代码块标记再json.loads，解析失败就重新请求一次，仍然失败则放弃该批语义判断，全部交给规则库兜底。这个降级路径一定要保留，否则大模型服务稍微波动一下，整条管线就断了。
当某条文本规则库拿不准时，我会启用高精度模式：把这条文本对应的矫正图小图裁剪出来，与OCR文本一起送入视觉大模型的图文输入通道，让它结合字形和上下文判断。这个模式速度慢，但准确率明显更高，适合处理手写体和印章遮挡区域。
3.4 打码策略：三档遮盖方式怎么选
打码看起来最简单，实际操作里门道不少。我实现了三种遮盖方式，对应不同隐私强度和版面保护需求。
第一种是马赛克。实现方式是把目标区域缩小到十六分之一大小，再用最近邻放大回去，产生像素块效果。马赛克保留了一种“此处有内容但无法辨认”的视觉暗示，适合姓名、地址这类不需要保留格式信息的字段。第二种是高斯模糊，适合诊断名称这类需要“隐约知道这一行长不长”的场景，视觉上不突兀。第三种是纯色块填充，直接用浅灰色块盖住，适合身份证号、病历号这类必须彻底抹除的字段，因为哪怕只透出几位数字都可能造成泄露。
参数上，建议所有遮盖区域先向外扩6到10个像素再执行。如果不外扩，识别框本身存在几个像素误差，叠加透视映射的累积误差后，很容易出现“文字边缘还露在外面”的情况。外扩之后用一个小尺寸中值滤波把遮盖区域边缘柔化，输出效果会自然很多。
3.5 输出与评估：怎么证明脱敏结果可靠
批量处理完成后，除了输出脱敏图片，还会生成一个汇总评估页面，包含三组指标：敏感召回率，指敏感字段里有多大比例被成功遮盖；误伤率，指非敏感内容被错误遮盖的比例；单张耗时。这里最关键的是敏感召回率，因为脱敏项目里漏一条信息都意味着风险；误伤率次之，主要影响可用性。
我在本地测试集里选了一张同时含机打表格、手写补充、盖章和反光的门诊病历照片做端到端测试。结果大致是：OCR识别出37个文本块，规则库命中10个，视觉大模型额外标出8个，最终遮盖14个区域（部分区域合并）。人工核对没有漏盖，误盖两处：一处是化验单样本号被规则库当成病历号规则误判，另一处是参考范围文字被大模型标成了敏感字段。整体效果可以接受，但这两处误盖也证明，纯自动化判断仍需要规则层做最终把关，这也是系统里保留人工确认队列的原因。
4. 常见问题与排查技巧实录
4.1 弯曲矫正后OCR反而变差的坑
这是项目里第一个重大挫折。最开始我以为把所有输入图片都做四点透视矫正，OCR效果一定更好。实测打脸：对于平整但倾斜的纸张，矫正后识别率确实提升；但对弯曲严重的照片，强行单次透视矫正反而会把弧线文本拉得更变形，识别率不升反降。
原因很简单：透视变换本质是平面映射，能把平面上的倾斜、透视拉正，但没法把曲面展开成平面。纸张弯曲意味着文本所在位置不是一个平面，单次全图矫正只能按某个平面的视点强行拉直，其他区域就会变形。
解决办法有三个，按推荐顺序：一是先判断弯曲程度，轻微弯曲直接矫正，弯曲严重就跳过矫正环节，直接依赖OCR引擎的旋转框检测能力；二是对弯曲区域做分块矫正，把页面切成若干窄条，每个窄条单独计算局部透视变换，效果接近但计算量较大；三是用展开算法做重建，精度最高但工程复杂度也最高。我线上版本用的是方案一加方案二的分级处理：页面平整度高于阈值就全图矫正，否则分块矫正，只有少数分块也无法处理的才原图直跑OCR。
4.2 打码区域错位的三类原因
打码区域错位是这类项目里被吐槽最多的问题，归纳下来一共三类原因，排查顺序如下。
第一类，透视映射没做对。症状是打码块整体偏移，多个区域偏移方向一致。原因是逆变换矩阵用错，或者没做齐次坐标归一化。解决办法就是检查map_box_back那段代码，并用调试图对比原始敏感框和映射后多边形的重合度。
第二类，OCR检测框输出格式没统一。有的OCR引擎输出外接水平矩形，有的输出旋转矩形，有的直接输出多边形。如果没在封装层统一格式，就会出现某些文本块打码正常、某些块偏斜的情况。解决办法是在OCR封装层把所有输出强制归一化为四点多边形，并在单元测试里固定几个样例断言坐标正确性。
第三类，取整误差和边界裁剪。浮点坐标转整数时如果直接截断，会向零方向偏最多一个像素，在多边形边界上可能漏掉半行文字。解决办法是一律向上取整到像素边界，并且外扩至少8像素再打码。边界裁剪发生在多边形超出图像边界的情况，打码时先做掩膜再与原图复合，就能天然避免越界报错。
4.3 视觉大模型漏标与误标的兜底策略
语义标注环节最不稳定的因素就是大模型自身。漏标比误标更危险，因为漏标意味着敏感信息直接出去了。我设计的是双层防御：规则库先行，视觉大模型补充。规则库对结构化痕迹明显的字段，比如身份证号、手机号、日期、金额，做到高命中率；视觉大模型负责规则库覆盖不了的自由文本，比如手写姓名、自定义诊断描述、检查项目名称。
即使这样，大模型仍可能把该标的标成非敏感。针对这种情况，Prompt里加了一个技巧：要求模型对每条文本同时输出“是否敏感”和“敏感字段类型”，当置信度低于阈值时，该条文本进入待人工确认队列。这个队列可以是一个人看着脱敏预览页勾选，也可以是一套二次规则。实测下来，加入低置信度队列后，漏脱敏率又压掉了一半以上。
4.4 性能瓶颈与优化经验
整套管线里最吃资源的是视觉大模型推理和OCR检测。单张图的端到端耗时，在普通工作站上大约是OCR两秒、大模型推理几秒，加起来十秒出头。批量处理上百张时这个耗时不可接受，我做了三处优化。
第一处是缓存。同一张图片如果预处理参数没变，OCR结果直接走缓存，不重复识别。第二处是批处理。OCR和视觉大模型都支持批量输入，把一批图片的识别结果分块拼接后做一次大模型推理，比逐张调用能省一半以上的开销。第三处是降级策略。图片清晰且规则库命中率高的场景，可以跳过视觉大模型直接走规则打码，这个快速通道在纯扫描件场景能省下大量时间。
部署上的建议是：OCR引擎用CPU也能跑，但视觉大模型强烈建议使用支持半精度推理的显卡，模型精度损失可忽略，速度能提升好几倍。如果部署环境没有显卡，可以把语义标注降级成规则库加一个小型序列标注模型，精度会低一些，但至少管线是完整的。
5. 后续可以怎么扩展，以及我的一点体会
5.1 值得继续做的几个方向
这个开源项目做完一轮后，我自己的体会是脱敏永远没有“彻底做完”的时刻。最有价值的扩展方向有三个。
第一个是支持视频脱敏。医疗直播、远程问诊的录屏里同样存在隐私风险，技术上可以把这套管线接到抽帧流上，每隔N帧做一次检测，中间帧用目标跟踪结果延续，能兼顾准确率和性能。第二个是构建错误反馈闭环。把人工确认时发现的漏盖、误盖案例定期导回训练集，微调视觉大模型或者扩充规则库，这是让系统越用越准的唯一路径。第三个是轻量化部署到手机端，让患者在拍照上传之前就在本地完成脱敏，把隐私保护前置到数据产生的那一刻。
5.2 我踩过最大的一个坑
最后说一个印象最深的教训。项目早期，我把视觉大模型的输出当成了最终真相，直接用它决定打码范围，结果出过一次比较严重的误伤。一张化验单上的“标本采集时间”被识别成了患者年龄信息，直接盖掉了。事后排查发现，问题出在Prompt里“年龄”的判定标准写得太宽，模型把符合数字模式的文本都归入了年龄。
从那之后我给自己定了一条规矩：大模型的输出永远只作为建议，规则库和人工确认队列才是最终裁决者。这个原则后来帮助整个系统避免了很多离奇的误判。做脱敏这种涉及隐私安全的事情，宁可多一次人工确认，也不能把判断完全交给一个不可解释的模型。