尧图网页设计 
OpenMed PII 召回率基准评测指南用合成金标精确测量标签感知的 Exact-Span 与 Grapheme Recall【免费下载链接】openmedLocal-first healthcare AI: clinical NER HIPAA PII de-identification that runs 100% on-device. 2,200 medical models, 21 languages, Apple MLX Python, no cloud, no patient data leaving your network. Apache-2.0项目地址: https://gitcode.com/GitHub_Trending/ope/openmed本指南对应仓库中的 skills/benchmark-pii-recall/SKILL.md 技能文档讲解如何在 OpenMed 上对 PII 模型执行召回率基准评测构建带精确偏移的合成金标、运行extract_pii、计算标签感知的精确跨度召回与字素召回并把零关键泄露作为发布门禁。读完本文你将掌握一套可运行的评测脚本、指标语义与发布门禁设计能对模型、阈值、后端或量化产物进行召回率对比并在发版前强制达标。为什么 PII 评测必须召回优先在 OpenMed 的语境里一个被漏掉的直接标识符姓名、电话、邮箱就是一次隐私事故即使聚合 F1 分数在上升也不能掩盖这一点。因此技能文档给出的第一原则是先测 PII 召回率再优化 F1、体积或延迟。F1 是精确率与召回率的调和平均一个在精确率上表现优异但漏掉少数高价值标识符的模型可能在 F1 上得分不低却在实际脱敏中造成泄露而召回率直接回答金标中的 PHI 到底找回了多少。评测的第二个原则是聚合之外必须有切片只看一个整体数字会把不同标签、语言、脚本、章节和设备的缺陷平均掉。例如某个模型对英文姓名召回 1.0、对印地语-天城文姓名召回 0.85聚合后可能仍有 0.99掩盖了具体短板。评测流程总览技能文档将完整流程归纳为六个步骤这也是评测脚本的主干构建带精确偏移和规范化 PII 标签的合成金标synthetic fixtures with exact offsets and canonical PII labels。金标必须覆盖直接标识符、边界情况boundary cases、多语言/多文字languages/scripts以及目标设备或量化形态target device or quantization。在候选阈值下运行extract_pii。对预测标签做归一化normalize prediction labels并逐文档分别打分不跨文档混算。只聚合计数counts only不持久化原始文本或标识符表面形式do not persist raw text or identifier surfaces。未达到召回底线或零关键泄露要求时拒绝发布。第 4、5 步是评测的隐私边界金标文本与预测表面如demo.patientexample.test只在内存中参与匹配报告里只出现聚合计数、TP/FP/FN 与字素覆盖数绝不把原始文本或标识符写进评测产物。核心评测 API 与源码依据评测脚本依赖三个公开入口均已在当前仓库实现并导出API位置语义openmed.extract_piiopenmed/core/pii.py对文本做 PII 抽取返回含实体列表的结果对象openmed.core.labels.normalize_labelopenmed/core/labels.py把任意来源标签映射到UPPER_SNAKE_CASE规范分类openmed.eval.compute_exact_span_f1openmed/eval/metrics.py严格标签感知的精确跨度 F1含 TP/FP/FN 计数openmed.eval.compute_character_recallopenmed/eval/metrics.py标签感知的字素簇grapheme-cluster召回率extract_pii 的关键参数从 extract_pii 实现 可以看到评测中会用到的参数model_namePII 检测模型注册表键或 Hugging Face ID当使用默认值且lang不是en时会自动选择对应语言的默认模型。技能文档中的基准使用OpenMed/OpenMed-PII-SuperClinical-Small-44M-v1。confidence_threshold最低置信度0–1默认值为 0.5——评测脚本显式传入0.5就是候选阈值。langISO 639-1 语言码en, fr, de, it, es, nl, hi, te, pt, ar, ja, tr控制默认模型与正则模式的选择hi/te的混合拉丁-天城文/泰卢固文笔记会自动走印度临床路由。use_smart_merging启用基于正则的语义单元合并默认True把模型碎片化预测合并成完整实体并做主导标签选择。cache_results/max_cache_entries进程内 LRU 缓存开关与容量缓存结果可能含 PHI但永不落盘。返回的PredictionResult.entities中每个实体带有start、end、label、text、confidence等字段评测脚本正是取这些字段构建predicted列表。两个指标的分工Exact-span recall只有label、start、end三者完全一致的预测才计为 TP。从 compute_exact_span_f1 实现 看匹配是逐 gold span 扫描未被占用的预测 span三者全等才记 TP然后由 _f1_from_counts 计算 precision/recall/F1 与 TP/FP/FN 计数。这衡量的是完整无缺地命中边界偏移一位即失败。Grapheme recall按Unicode 字素簇而不是裸字符计算金标 PHI 被同标签预测覆盖的比例返回RateMetricrate/numerator/denominator。实现上 _grapheme_coverage_tally 先合并预测区间再通过 _grapheme_units 按字素簇与文字脚本切分金标统计每个字素簇是否被完整覆盖。这意味着命中了名字但少了姓氏最后一个字母在字素层面仍算部分丢失比精确跨度更宽容、却比字符计数更接近真实用户感知尤其对组合字符如带变音符的拉丁名、天城文连写更准确。两者都通过normalize_eval_spans对金标与预测做统一归一化且匹配是标签感知的预测了正确偏移但标签错误如把 PHONE 标成 EMAIL不会贡献 TP。可运行的合成基准评测脚本先安装模型运行时python -m pip install openmed[hf][hf]是pyproject.toml中定义的 optional extra见 pyproject.toml包含transformers4.50、huggingface-hub0.30、accelerate0.29等。技能文档提供的完整可运行脚本如下from openmed import extract_pii from openmed.core.labels import normalize_label from openmed.eval import compute_character_recall, compute_exact_span_f1 MODEL OpenMed/OpenMed-PII-SuperClinical-Small-44M-v1 RECALL_FLOOR 0.99 FIXTURES [ { text: ( Call the synthetic clinic at 212-555-0198 or email demo.patientexample.test. ), spans: [ (PHONE, 212-555-0198), (EMAIL, demo.patientexample.test), ], }, { text: ( The synthetic callback number is 415-555-0136 and the contact address is sample.userexample.test. ), spans: [ (PHONE, 415-555-0136), (EMAIL, sample.userexample.test), ], }, ] true_positives false_positives false_negatives 0 covered_graphemes total_graphemes 0 for fixture in FIXTURES: text fixture[text] gold [] for label, surface in fixture[spans]: start text.index(surface) gold.append( {start: start, end: start len(surface), label: label} ) result extract_pii( text, model_nameMODEL, confidence_threshold0.5, langen, ) predicted [ { start: entity.start, end: entity.end, label: normalize_label(entity.label), } for entity in result.entities if entity.start is not None and entity.end is not None ] exact compute_exact_span_f1(gold, predicted, source_texttext) recall compute_character_recall(gold, predicted, source_texttext) true_positives exact.true_positives false_positives exact.false_positives false_negatives exact.false_negatives covered_graphemes int(recall.numerator) total_graphemes int(recall.denominator) exact_recall true_positives / max(true_positives false_negatives, 1) grapheme_recall covered_graphemes / max(total_graphemes, 1) print( { documents: len(FIXTURES), exact_span_recall: exact_recall, grapheme_recall: grapheme_recall, false_positives: false_positives, false_negatives: false_negatives, } ) assert grapheme_recall RECALL_FLOOR, PII recall floor not met逐段拆解其设计要点金标构建每个 fixture 只存text与(label, surface)对start text.index(surface)在运行时精确计算偏移end start len(surface)。这样避免了手工写死偏移的维护成本也保证偏移与文本一一对应。预测归一化只取start/end非空的实体并用normalize_label把模型输出的任意标签BIOES 前缀、大小写、分隔符变体映射到规范分类。从 normalize_label 实现 看它接受英文snake_case、葡萄牙语无分隔大写FIRSTNAME、BIOES 形式B-NAME、I-EMAIL、混合大小写等中文临床标签CMeEE也经langzh走专属映射未知标签落回OTHER而非抛错。逐文档打分compute_exact_span_f1与compute_character_recall都在每个 fixture 上单独调用计数在循环外聚合——这正对应流程第 4 步每个文档分别打分。分母防零max(true_positives false_negatives, 1)防止金标为空时除零这是可直接复用的健壮性写法。发布断言脚本末尾assert grapheme_recall RECALL_FLOOR把0.99的召回底线变成硬性门禁未达标即抛异常CI 直接失败。从两个数字到完整切片与泄露度量技能文档要求报告 per-label、language、script、section、device 切片。仓库中的openmed.eval提供了比裸循环更强的现成工具可直接把上面脚本升级为切片报告compute_recall_slices返回RecallSlices包含overall以及by_label、by_language、by_device、by_script四个维度的字素召回率外加各维度的覆盖/总数字素计数。脚本只需把compute_character_recall换成它即可在代码 20 行内产出文档要求的全部切片。compute_leakage_rate与召回互补的泄露率——未被任何同标签预测完全覆盖的金标 PHI 字素数除以金标 PHI 总字素数同样按标签/语言/设备/脚本切分。召回回答找回了多少泄露率回答还剩多少暴露两者共享同一套字素加权口径。compute_critical_finding_recall只对标记为关键发现critical finding的金标 span 计算召回且输出保持 PHI-free——漏检项只报告类别category、fixture id、规范标签与偏移绝不回显标识符表面。这正是零关键泄露门禁的度量底座。零关键泄露zero-critical-leak的落地技能文档的门禁要求即使聚合召回率通过关键直接标识符也必须零漏检。仓库在 openmed/eval/v22_conformance.py 提供了assert_zero_critical_leakage(direct_identifiers, surfaces)对给定直接标识符集合扫描各输出表面review、grounding、FHIR bundle、日志等返回每个表面的命中计数任何表面计数非零即抛出V22ConformanceError且错误信息只列表面名称、不回显标识符本身。对应测试在 tests/integration/test_v22_exchange_conformance.py其中用assert_zero_critical_leakage断言敏感值集合在安全结果 日志中的计数全为 0。此外 tests/fixtures/risk/negation_traps.jsonl 提供了一类高价值合成负例——否定上下文陷阱如Patient Elena Park denies chest pain… Call 415-555-2671期望critical_leakage_rate: 0.0且forbidden_residuals如Elena Park、415-555-2671绝不残留在输出中。这类 fixture 可以直接扩展进你的评测金标专门打击上下文语义导致漏检的场景。发布门禁清单技能文档的 Release gates 是评测的最终裁决层逐条落实如下关键标识符零漏检即使聚合召回率通过对关键直接标识符仍要求零漏检——用compute_critical_finding_recall度量、assert_zero_critical_leakage裁决。分片报告按标签、语言、脚本、章节、设备分别报告定位短板而非被平均掩盖。量化对比对比量化与全精度输出拒绝任何召回率回退recall regression。量化是压缩设备侧模型的主要手段但必须证明压缩没有以漏掉标识符为代价。加入硬负例hard negatives防止过度脱敏over-redaction藏在高召回率背后——一个把整段文本都标成 PHI 的模型召回率可能很高但会把病历改得面目全非硬负例让不应命中的文本参与打分从而同时钳制精确率。只存元数据只持久化 fixture 哈希、模型身份、阈值与聚合计数原始文本与标识符表面一律不落盘。受控语料受 DUA数据使用协议约束的语料库必须放在仓库之外只在用户批准的路径下加载。仓库实战示例策略审计与发布证据技能文档指向的仓库示例是 examples/v16_policy_audit_release_gates.py它演示了如何在完全离线、不下载模型的前提下跑通发布证据链手工构造合成脱敏结果姓名Casey Example、电话212-555-0198然后用openmed.core.audit的AuditReport生成并签名审计报告含repro_hash、签名校验、verify_repro_hash对应审计证据要求用 compute_leakage_heatmap 对金标/预测 span 计算泄露热力图leakage_total与worst_leakage_cells对应PHI-free 泄露度量用openmed.risk.kanon.kanon_report对age_band、zip3等准标识符做 k-匿名评估把重识别风险纳入发布证据。该示例的输出全部是聚合指标与审计元数据不打印任何原始 PHI——与技能文档只聚合计数、不持久化表面的原则完全一致是搭建你自身评测流水线时可直接对照的模板。把评测接入你的发布流水线综合技能文档与仓库实现一个符合 OpenMed 规范的 PII 召回评测流水线可以这样收敛用合成文本构建金标含直接标识符、边界、多语言/多脚本、目标设备形态必要时混入negation_traps式否定陷阱与硬负例在每个候选阈值下调用extract_pii预测标签统一经normalize_label归一到规范分类逐文档计算compute_exact_span_f1与compute_character_recall聚合 TP/FP/FN 与字素覆盖计数并按compute_recall_slices输出标签/语言/设备/脚本切片用compute_critical_finding_recall单独把关关键标识符用assert_zero_critical_leakage对输出表面与日志做零泄露扫描只持久化 fixture 哈希、模型身份、阈值与聚合计数受 DUA 约束的语料留在仓库之外把RECALL_FLOOR与零关键泄露要求固化为断言与 CI 门禁量化产物必须通过与非量化基线同等的召回检查方可发布。这套方法论的完整依据都落在当前仓库中指标实现在 openmed/eval/metrics.py标签规范化在 openmed/core/labels.py抽取入口在 openmed/core/pii.py门禁与证据链示例则在 examples/v16_policy_audit_release_gates.py 与 openmed/eval/v22_conformance.py 中可复现。【免费下载链接】openmedLocal-first healthcare AI: clinical NER HIPAA PII de-identification that runs 100% on-device. 2,200 medical models, 21 languages, Apple MLX Python, no cloud, no patient data leaving your network. Apache-2.0项目地址: https://gitcode.com/GitHub_Trending/ope/openmed创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OpenMed PII 召回率基准评测指南：用合成金标精确测量标签感知的 Exact-Span 与 Grapheme Recall
OpenMed PII 召回率基准评测指南用合成金标精确测量标签感知的 Exact-Span 与 Grapheme Recall【免费下载链接】openmedLocal-first healthcare AI: clinical NER HIPAA PII de-identification that runs 100% on-device. 2,200 medical models, 21 languages, Apple MLX Python, no cloud, no patient data leaving your network. Apache-2.0项目地址: https://gitcode.com/GitHub_Trending/ope/openmed本指南对应仓库中的 skills/benchmark-pii-recall/SKILL.md 技能文档讲解如何在 OpenMed 上对 PII 模型执行召回率基准评测构建带精确偏移的合成金标、运行extract_pii、计算标签感知的精确跨度召回与字素召回并把零关键泄露作为发布门禁。读完本文你将掌握一套可运行的评测脚本、指标语义与发布门禁设计能对模型、阈值、后端或量化产物进行召回率对比并在发版前强制达标。为什么 PII 评测必须召回优先在 OpenMed 的语境里一个被漏掉的直接标识符姓名、电话、邮箱就是一次隐私事故即使聚合 F1 分数在上升也不能掩盖这一点。因此技能文档给出的第一原则是先测 PII 召回率再优化 F1、体积或延迟。F1 是精确率与召回率的调和平均一个在精确率上表现优异但漏掉少数高价值标识符的模型可能在 F1 上得分不低却在实际脱敏中造成泄露而召回率直接回答金标中的 PHI 到底找回了多少。评测的第二个原则是聚合之外必须有切片只看一个整体数字会把不同标签、语言、脚本、章节和设备的缺陷平均掉。例如某个模型对英文姓名召回 1.0、对印地语-天城文姓名召回 0.85聚合后可能仍有 0.99掩盖了具体短板。评测流程总览技能文档将完整流程归纳为六个步骤这也是评测脚本的主干构建带精确偏移和规范化 PII 标签的合成金标synthetic fixtures with exact offsets and canonical PII labels。金标必须覆盖直接标识符、边界情况boundary cases、多语言/多文字languages/scripts以及目标设备或量化形态target device or quantization。在候选阈值下运行extract_pii。对预测标签做归一化normalize prediction labels并逐文档分别打分不跨文档混算。只聚合计数counts only不持久化原始文本或标识符表面形式do not persist raw text or identifier surfaces。未达到召回底线或零关键泄露要求时拒绝发布。第 4、5 步是评测的隐私边界金标文本与预测表面如demo.patientexample.test只在内存中参与匹配报告里只出现聚合计数、TP/FP/FN 与字素覆盖数绝不把原始文本或标识符写进评测产物。核心评测 API 与源码依据评测脚本依赖三个公开入口均已在当前仓库实现并导出API位置语义openmed.extract_piiopenmed/core/pii.py对文本做 PII 抽取返回含实体列表的结果对象openmed.core.labels.normalize_labelopenmed/core/labels.py把任意来源标签映射到UPPER_SNAKE_CASE规范分类openmed.eval.compute_exact_span_f1openmed/eval/metrics.py严格标签感知的精确跨度 F1含 TP/FP/FN 计数openmed.eval.compute_character_recallopenmed/eval/metrics.py标签感知的字素簇grapheme-cluster召回率extract_pii 的关键参数从 extract_pii 实现 可以看到评测中会用到的参数model_namePII 检测模型注册表键或 Hugging Face ID当使用默认值且lang不是en时会自动选择对应语言的默认模型。技能文档中的基准使用OpenMed/OpenMed-PII-SuperClinical-Small-44M-v1。confidence_threshold最低置信度0–1默认值为 0.5——评测脚本显式传入0.5就是候选阈值。langISO 639-1 语言码en, fr, de, it, es, nl, hi, te, pt, ar, ja, tr控制默认模型与正则模式的选择hi/te的混合拉丁-天城文/泰卢固文笔记会自动走印度临床路由。use_smart_merging启用基于正则的语义单元合并默认True把模型碎片化预测合并成完整实体并做主导标签选择。cache_results/max_cache_entries进程内 LRU 缓存开关与容量缓存结果可能含 PHI但永不落盘。返回的PredictionResult.entities中每个实体带有start、end、label、text、confidence等字段评测脚本正是取这些字段构建predicted列表。两个指标的分工Exact-span recall只有label、start、end三者完全一致的预测才计为 TP。从 compute_exact_span_f1 实现 看匹配是逐 gold span 扫描未被占用的预测 span三者全等才记 TP然后由 _f1_from_counts 计算 precision/recall/F1 与 TP/FP/FN 计数。这衡量的是完整无缺地命中边界偏移一位即失败。Grapheme recall按Unicode 字素簇而不是裸字符计算金标 PHI 被同标签预测覆盖的比例返回RateMetricrate/numerator/denominator。实现上 _grapheme_coverage_tally 先合并预测区间再通过 _grapheme_units 按字素簇与文字脚本切分金标统计每个字素簇是否被完整覆盖。这意味着命中了名字但少了姓氏最后一个字母在字素层面仍算部分丢失比精确跨度更宽容、却比字符计数更接近真实用户感知尤其对组合字符如带变音符的拉丁名、天城文连写更准确。两者都通过normalize_eval_spans对金标与预测做统一归一化且匹配是标签感知的预测了正确偏移但标签错误如把 PHONE 标成 EMAIL不会贡献 TP。可运行的合成基准评测脚本先安装模型运行时python -m pip install openmed[hf][hf]是pyproject.toml中定义的 optional extra见 pyproject.toml包含transformers4.50、huggingface-hub0.30、accelerate0.29等。技能文档提供的完整可运行脚本如下from openmed import extract_pii from openmed.core.labels import normalize_label from openmed.eval import compute_character_recall, compute_exact_span_f1 MODEL OpenMed/OpenMed-PII-SuperClinical-Small-44M-v1 RECALL_FLOOR 0.99 FIXTURES [ { text: ( Call the synthetic clinic at 212-555-0198 or email demo.patientexample.test. ), spans: [ (PHONE, 212-555-0198), (EMAIL, demo.patientexample.test), ], }, { text: ( The synthetic callback number is 415-555-0136 and the contact address is sample.userexample.test. ), spans: [ (PHONE, 415-555-0136), (EMAIL, sample.userexample.test), ], }, ] true_positives false_positives false_negatives 0 covered_graphemes total_graphemes 0 for fixture in FIXTURES: text fixture[text] gold [] for label, surface in fixture[spans]: start text.index(surface) gold.append( {start: start, end: start len(surface), label: label} ) result extract_pii( text, model_nameMODEL, confidence_threshold0.5, langen, ) predicted [ { start: entity.start, end: entity.end, label: normalize_label(entity.label), } for entity in result.entities if entity.start is not None and entity.end is not None ] exact compute_exact_span_f1(gold, predicted, source_texttext) recall compute_character_recall(gold, predicted, source_texttext) true_positives exact.true_positives false_positives exact.false_positives false_negatives exact.false_negatives covered_graphemes int(recall.numerator) total_graphemes int(recall.denominator) exact_recall true_positives / max(true_positives false_negatives, 1) grapheme_recall covered_graphemes / max(total_graphemes, 1) print( { documents: len(FIXTURES), exact_span_recall: exact_recall, grapheme_recall: grapheme_recall, false_positives: false_positives, false_negatives: false_negatives, } ) assert grapheme_recall RECALL_FLOOR, PII recall floor not met逐段拆解其设计要点金标构建每个 fixture 只存text与(label, surface)对start text.index(surface)在运行时精确计算偏移end start len(surface)。这样避免了手工写死偏移的维护成本也保证偏移与文本一一对应。预测归一化只取start/end非空的实体并用normalize_label把模型输出的任意标签BIOES 前缀、大小写、分隔符变体映射到规范分类。从 normalize_label 实现 看它接受英文snake_case、葡萄牙语无分隔大写FIRSTNAME、BIOES 形式B-NAME、I-EMAIL、混合大小写等中文临床标签CMeEE也经langzh走专属映射未知标签落回OTHER而非抛错。逐文档打分compute_exact_span_f1与compute_character_recall都在每个 fixture 上单独调用计数在循环外聚合——这正对应流程第 4 步每个文档分别打分。分母防零max(true_positives false_negatives, 1)防止金标为空时除零这是可直接复用的健壮性写法。发布断言脚本末尾assert grapheme_recall RECALL_FLOOR把0.99的召回底线变成硬性门禁未达标即抛异常CI 直接失败。从两个数字到完整切片与泄露度量技能文档要求报告 per-label、language、script、section、device 切片。仓库中的openmed.eval提供了比裸循环更强的现成工具可直接把上面脚本升级为切片报告compute_recall_slices返回RecallSlices包含overall以及by_label、by_language、by_device、by_script四个维度的字素召回率外加各维度的覆盖/总数字素计数。脚本只需把compute_character_recall换成它即可在代码 20 行内产出文档要求的全部切片。compute_leakage_rate与召回互补的泄露率——未被任何同标签预测完全覆盖的金标 PHI 字素数除以金标 PHI 总字素数同样按标签/语言/设备/脚本切分。召回回答找回了多少泄露率回答还剩多少暴露两者共享同一套字素加权口径。compute_critical_finding_recall只对标记为关键发现critical finding的金标 span 计算召回且输出保持 PHI-free——漏检项只报告类别category、fixture id、规范标签与偏移绝不回显标识符表面。这正是零关键泄露门禁的度量底座。零关键泄露zero-critical-leak的落地技能文档的门禁要求即使聚合召回率通过关键直接标识符也必须零漏检。仓库在 openmed/eval/v22_conformance.py 提供了assert_zero_critical_leakage(direct_identifiers, surfaces)对给定直接标识符集合扫描各输出表面review、grounding、FHIR bundle、日志等返回每个表面的命中计数任何表面计数非零即抛出V22ConformanceError且错误信息只列表面名称、不回显标识符本身。对应测试在 tests/integration/test_v22_exchange_conformance.py其中用assert_zero_critical_leakage断言敏感值集合在安全结果 日志中的计数全为 0。此外 tests/fixtures/risk/negation_traps.jsonl 提供了一类高价值合成负例——否定上下文陷阱如Patient Elena Park denies chest pain… Call 415-555-2671期望critical_leakage_rate: 0.0且forbidden_residuals如Elena Park、415-555-2671绝不残留在输出中。这类 fixture 可以直接扩展进你的评测金标专门打击上下文语义导致漏检的场景。发布门禁清单技能文档的 Release gates 是评测的最终裁决层逐条落实如下关键标识符零漏检即使聚合召回率通过对关键直接标识符仍要求零漏检——用compute_critical_finding_recall度量、assert_zero_critical_leakage裁决。分片报告按标签、语言、脚本、章节、设备分别报告定位短板而非被平均掩盖。量化对比对比量化与全精度输出拒绝任何召回率回退recall regression。量化是压缩设备侧模型的主要手段但必须证明压缩没有以漏掉标识符为代价。加入硬负例hard negatives防止过度脱敏over-redaction藏在高召回率背后——一个把整段文本都标成 PHI 的模型召回率可能很高但会把病历改得面目全非硬负例让不应命中的文本参与打分从而同时钳制精确率。只存元数据只持久化 fixture 哈希、模型身份、阈值与聚合计数原始文本与标识符表面一律不落盘。受控语料受 DUA数据使用协议约束的语料库必须放在仓库之外只在用户批准的路径下加载。仓库实战示例策略审计与发布证据技能文档指向的仓库示例是 examples/v16_policy_audit_release_gates.py它演示了如何在完全离线、不下载模型的前提下跑通发布证据链手工构造合成脱敏结果姓名Casey Example、电话212-555-0198然后用openmed.core.audit的AuditReport生成并签名审计报告含repro_hash、签名校验、verify_repro_hash对应审计证据要求用 compute_leakage_heatmap 对金标/预测 span 计算泄露热力图leakage_total与worst_leakage_cells对应PHI-free 泄露度量用openmed.risk.kanon.kanon_report对age_band、zip3等准标识符做 k-匿名评估把重识别风险纳入发布证据。该示例的输出全部是聚合指标与审计元数据不打印任何原始 PHI——与技能文档只聚合计数、不持久化表面的原则完全一致是搭建你自身评测流水线时可直接对照的模板。把评测接入你的发布流水线综合技能文档与仓库实现一个符合 OpenMed 规范的 PII 召回评测流水线可以这样收敛用合成文本构建金标含直接标识符、边界、多语言/多脚本、目标设备形态必要时混入negation_traps式否定陷阱与硬负例在每个候选阈值下调用extract_pii预测标签统一经normalize_label归一到规范分类逐文档计算compute_exact_span_f1与compute_character_recall聚合 TP/FP/FN 与字素覆盖计数并按compute_recall_slices输出标签/语言/设备/脚本切片用compute_critical_finding_recall单独把关关键标识符用assert_zero_critical_leakage对输出表面与日志做零泄露扫描只持久化 fixture 哈希、模型身份、阈值与聚合计数受 DUA 约束的语料留在仓库之外把RECALL_FLOOR与零关键泄露要求固化为断言与 CI 门禁量化产物必须通过与非量化基线同等的召回检查方可发布。这套方法论的完整依据都落在当前仓库中指标实现在 openmed/eval/metrics.py标签规范化在 openmed/core/labels.py抽取入口在 openmed/core/pii.py门禁与证据链示例则在 examples/v16_policy_audit_release_gates.py 与 openmed/eval/v22_conformance.py 中可复现。【免费下载链接】openmedLocal-first healthcare AI: clinical NER HIPAA PII de-identification that runs 100% on-device. 2,200 medical models, 21 languages, Apple MLX Python, no cloud, no patient data leaving your network. Apache-2.0项目地址: https://gitcode.com/GitHub_Trending/ope/openmed创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考