利用Amazon Bedrock上任意LLM构建可配置PII检测器,检测实体定义在Prompt而非代码中,换模型无需重训练,在五个公开语料上超越现成工具。
一种可配置、由指令驱动的检测器,可运行于任何在 Amazon Bedrock 上管理的大型语言模型(LLM),在五个公开 PII 语料库上针对九款基于 LLM 的检测器进行了评估,其中包括 OpenAI PrivacyFilter。
在真实文本上微调模型会带来个人身份信息(PII)检测问题。训练语料库中充满了 PII:姓名、家庭住址、电子邮件和电话号码、身份证号和社会保障号码、银行账户、出生日期。在未清洗的文本上训练的模型可能会记住这些数据,并在后续的提示中复现它们,从而泄露真实人物的详细信息——而这个提示本不打算暴露这些信息。在这篇文章中,我们描述了一个构建在大型语言模型(LLM)之上的可配置、与模型无关的检测器,介绍其实现过程,用现成工具对其进行基准测试,并展示如何在自己的数据上运行它。
示例代码:本文描述的检测器随 pii-detector 包一起发布,可在 sample-llm-pii-detection 仓库中获取。以下每个代码片段均来自该包,检测器端到端运行一节将介绍如何在自己的数据上安装和运行它。
PII 很少以整洁的表单字段形式存在。它隐藏在客户支持记录、人力资源档案、聊天日志,以及构成团队微调所依赖的自定义数据集的长自由文本列中。它以混乱的多语言格式出现,没有固定模式能够预见。常用工具是双向 token 分类模型: transformer 标记器,用在训练时固定的 PII 类型标记每个 token。自定义微调语料库引入的特定领域标识符(如员工 ID 或加密钱包地址)恰好超出了这个冻结模式的范围。要添加它意味着重新标注和重新训练。而且它们被锁定在单一模型和单一部署上。
大型语言模型重新定义了这个问题。LLM 在推理时读取指令,因此要检测的实体、输出格式和部署后端都变成了配置而非代码。一个检测器可以通过编辑提示词来针对新的实体类型,而无需重新训练;可以运行在托管 API 上或你自己的虚拟私有云(VPC)内部;可以在八种语言之间进行上下文推理,无需翻译步骤。本文其余部分描述了这样一个检测器,介绍了其背后的工程设计,并展示了它与现有工具的比较结果。
检测器将语言模型视为一个可配置、可替换的组件。你将输入文本包裹在定义 PII 实体和期望输出的指令中。然后模型返回检测到的实体结构化列表。两个设计选择使其与模型无关:
指令驱动的检测:检测逻辑完全存在于指令和一个薄薄的解析层中。这使其独立于任何单一模型的特性。
可配置后端:模型通过统一的推理接口(称为 Inferencer)访问。该包附带了一个 Amazon Bedrock(托管式,例如 Mistral 或 OSS-GPT)的适配器。同一接口接受一个针对开放模型的定制适配器,例如在你自己的基础设施上使用 GPU 服务的 OSS-GPT 20B。这覆盖了无法访问 Amazon Bedrock 的安全或气隙环境。任何接受消息列表并返回助手文本的对象都满足该接口,因此检测器对其运行的后端是无关的。
定制化来自两个独立组件。第一个是模型,它决定准确性、延迟和成本:你选择前沿的 Amazon Bedrock 模型或单个 GPU 上的小型开放模型。第二个是实体集,它定义了什么算作 PII。要扩展它,你添加一个特定领域的标识符或删除不需要的。改变实体集只需对指令做一行编辑,无需重新训练和重新部署。
LLM 的工作是狭窄且定义明确的。它读取文本,识别所有 PII 跨度,并用模式中的实体类型标记每个跨度。它将这些跨度作为结构化 JSON 返回,后处理步骤计算精确的字符偏移量并去除重复项。
为了将这种方法置于上下文中,我们与其他八款基于 LLM 的检测器(包括 OpenAI PrivacyFilter)逐跨度进行评估。所有检测器均在共同的真实标签上进行评分。
技术实现
检测器由四个部分构建。提示词定义模式,后端运行模型,解析和偏移量层将响应转换为带位置的跨度,一个薄薄的调用序列将它们绑定在一起。本节按照请求流经系统的顺序介绍每个部分,指向实现它的包仓库中的模块。
PII 模式和检测提示词
模式存在于单一的系统提示词模板中,这是检测器的核心:十五个实体类别,每个类别有一行定义、一个不标记列表、可选的少样本示例以及输入文本。因为模式是文本,添加或删除一个类别只需一行编辑。模型被指示返回一个 JSON 列表,每个检测到的实体对应一个对象,携带实体类型和找到的确切文本值。它不返回字符偏移量,因为 LLM 无法可靠地生成这些。这些偏移量在后处理中恢复:
[{"pii_entity_type": "FULL_ADDRESSES", "pii_entity_value": "82 Oak Street"},
{"pii_entity_type": "CONTACT_INFO", "pii_entity_value": "bob@example.com"}]
完整的提示词在 pii_detector/templates.py 中,下面的端到端演练用它对示例字符串进行原样运行。
LLM 后端集成
因为检测逻辑在提示词中,后端是一个自由选择。在我们提供的实现中,检测器通过一个小型接口(称为 Inferencer)与外界通信:消息输入,文本输出。因此同一检测器可以针对 Amazon Bedrock 上的托管模型运行,也可以针对你自己在 Amazon Elastic Compute Cloud(Amazon EC2)上托管的开放模型运行。该包附带 Amazon Bedrock 适配器(pii_detector/bedrock_inferencer.py),这是 Converse API 的一个薄包装。下面的演练端到端运行该路径。
模型的原始文本通过三个步骤变成干净的带位置跨度列表,全部在 pii_detector/detector.py 中:
JSON 解析:将文本响应转换为字典列表,每个条目对应一个检测到的 PII(如果记录不包含任何 PII,则为空列表)。
偏移量计算:因为模型返回的是值而不是位置,每个值通过正则表达式在源文本中进行定位。
幻觉标签恢复:LLM 经常发出近似误标签(DATE 代替 DATES,EMAIL 代替 CONTACT_INFO),因此每个发出的标签通过形态和一个精心策划的别名表重新映射到提示词自身的词汇表。无法映射到任何层级的标签被标记为 UNK,而不是强制拟合,这样真正的幻觉保持可见。
端到端运行检测器
本节介绍如何在你的数据上运行检测器,从前置条件到清理步骤。每个步骤都使用文章顶部提到的 pii-detector 包。
要跟随操作,你需要以下前置条件。
Python:Python 3.11 或更高版本。
具有 Amazon Bedrock 模型访问权限的 AWS 账户:一个其凭证可以调用 Amazon Bedrock Converse API 的 AWS 账户。你还需要在 Amazon Bedrock 控制台中为所选模型启用模型访问权限,例如 Mistral 或 OSS-GPT 模型。有关按 AWS 区域划分的模型可用性,请参阅 Amazon Bedrock 中的按 AWS 区域划分的支持模型。检测器通过标准 AWS 凭证链解析凭证,因此在环境中设置 AWS_PROFILE(或 IAM 角色或 SSO 配置文件)和 AWS_REGION。
Python 依赖:Boto3,这是唯一的运行时依赖,需要安装到虚拟环境中(参见步骤 1)。
以下步骤假设你已经克隆了 pii-detector 仓库并在其根目录下工作。
创建虚拟环境并安装 boto3。该包从仓库根目录运行,因此设置 PYTHONPATH 以使 pii_detector 模块可以从仓库根解析。
cd pii-detector
python -m venv .venv && source .venv/bin/activate
pip install boto3
export PYTHONPATH=. # so `import pii_detector` resolves from the repo root
将 Boto3 指向具有 Amazon Bedrock 访问权限的账户,并选择你启用模型访问权限的区域。
export AWS_PROFILE=my-bedrock-profile
export AWS_REGION=us-east-1
如果你不使用命名配置文件,Boto3 也支持 AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY,但我们建议使用 AWS Identity and Access Management(IAM)角色或 SSO 配置文件,而不是长期存在的静态密钥。
该仓库附带了一个可运行的示例(examples/detect.py),它可以检测示例字符串中的 PII。从仓库根目录将其作为模块运行。如果凭证或模型访问权限缺失,它会快速失败并给出可操作的指导。
python -m examples.detect
使用任意 Amazon Bedrock Converse 模型 ID 构建一个 Amazon Bedrock 推理器,将其包装在 PiiDetector 中,然后对字符串调用检测器。它返回定位到的跨度列表,每个跨度都带有精确的字符偏移量,可直接馈送给下游脱敏步骤。由于 Amazon Bedrock 是全托管服务,因此无需管理任何服务器。
from pii_detector import BedrockInferencer, PiiDetector
inferencer = BedrockInferencer(
model_id="openai.gpt-oss-20b-1:0",
region="us-east-1",
)
detector = PiiDetector(inferencer)
spans = detector("Email bob@example.com or call Jane at 555-0142.")
# -> [{'pii_entity_type': 'CONTACT_INFO', 'pii_entity_value': 'bob@example.com',
# 'start': 6, 'end': 21}, ...]
model_id 可以是任意 Amazon Bedrock Converse 模型 ID 或推理配置 ID,例如 amazon.nova-lite-v1:0 或 mistral.mistral-large-3-675b-instruct。切换模型只需修改一行代码,检测器和调用方保持不变。
Amazon Bedrock 是无服务器架构,因此无需拆卸基础设施,且按实际使用的 token 量付费。清理时,停用虚拟环境(deactivate),如果不再需要,可在 Amazon Bedrock 控制台中禁用已启用的模型访问。如果你使用自托管后端而非 Amazon Bedrock,请自行关闭该主机,因为检测器不管理后端基础设施。
评估使用了来自 Hugging Face 的五个公开 PII 语料库,每个都带有真值跨度,每个数据集采样约 10,000 条记录。合计覆盖 49,365 条记录和 222,114 个跨八种语言(de、en、es、fr、hi、it、nl、te)的真值核心跨度。领域涵盖多语言合成档案到英语 HR 和客服文档,这使得聚合语料库成为一个公平的压力测试。
预测跨度通过精确的(start、end、label)重叠(IoU = 1.0)与真值匹配,并使用 Precision、Recall 和 F1 进行评分。
在这些数据集上比较不同检测器比表面看起来更难,因为标签并不对齐。每个检测器和每个数据集都使用自己的词汇表:PRIVATE_NAMES 对比 NAME,street_address 对比 street。为使比较公平,来自检测器输出和数据集真值的所有原始标签都被映射到单一的十二个常见实体规范分类。然后,每个检测器仅在其与数据集都声明的标签范围交集上进行评分。这样,没有检测器会因从未声称支持的类别而受到惩罚。
规范核心实体分类。这十二种类型在各个数据集和检测器中都很常见,因此构成了主要比较的基础。包仓库给出了五个数据集从原始标签到规范标签的精确映射。
该分类定义了两种报告范围。Core F1(核心 F1)是公平的正面交锋数字,覆盖十二种常见实体类型。Extended-entity F1(扩展实体 F1)覆盖数据集特定的类别(职业、公司名称、加密钱包地址等),这些是大多数现成检测器完全没有概念的类别。这部分在 Customization(定制化)下讨论。
主要指标是跨度级别的 Core F1。下表报告了该指标以及跨代表性 LLM 检测器选择的估计每次检测延迟。它涵盖了 Amazon Bedrock 上的托管模型和 Amazon EC2 上托管的开源模型,包括 OpenAI PrivacyFilter。开源模型的选择涵盖了比 OSS-GPT 20B 更小和更大的模型,因此可以看到范围。Amazon Bedrock 与模型无关,因此正确的选择取决于工作负载的准确性、延迟和成本需求,而非任何单一排名。结果因模型而异。docs/benchmarks.md 给出了我们测试的每个模型的完整表格。
跨度级别 Core F1(全部五个数据集,49,365 条记录)和估计每次检测延迟,按后端分组(Amazon Bedrock、Amazon EC2)。实际上检测会在许多记录上运行,并使用并行工作线程。每次检测数字是反推回单条记录的总墙钟时间,因此它是指示性的,而非严格的单次调用测量。
在同一语料库上,Core F1 范围从 74.9%(Nova Lite 2)到 83.1%(Mistral Large 3),PrivacyFilter 为 80.7%。Mistral Large 3 和 OSS-GPT 120B 在 Amazon Bedrock 上运行,而 OSS-GPT 20B(81.6%)运行在你控制的硬件上。延迟由模型驱动,而非参数量。OSS-GPT 20B 在 Amazon EC2 上约需 1.2 秒,而同样大小的 Qwen3.6-27B 约需 12.8 秒,因为推理冗长度和架构比原始大小更重要。后端是自由选择的,因为 OSS-GPT 20B 在 Amazon EC2(81.6%)和 Amazon Bedrock(81.3%)上的得分仅相差 0.3 分。
准确性在语言和高风险标识符上保持稳定。在 ai4privacy_500k 分解上(见包仓库),OSS-GPT 20B 在所有八种语言中保持在 83–90% 的紧密 Core F1 范围内,包括非拉丁语的印地语和泰卢固语。它在最关键的标识符上也达到或超过前沿模型:SSN、金融和 ID 号码均高于 95%。共同的弱点是 DATE,约 50%,因为跨度边界和格式确实存在歧义。
目前的准确性结果调动了模型这个杠杆,在准确性与延迟和成本之间权衡。第二个杠杆是要检测的实体集,完全在指令中定义。这正是该方法超越固定范围工具的扩展方式,最清晰的证据在于稀有、领域特定的实体。
每个数据集都标注了自己的核心之外类别。nemotron 和 gretel 语料库标注了职业、职位和公司名称。isotonic 语料库标注了加密钱包(比特币和以太坊)地址、车辆标识符和用户代理字符串。ai4privacy_500k 语料库标注了性别、性别认同和组织。使用基础配置运行的检测器对这些类别没有概念,得分接近零。
恢复它们不需要新模型,也不需要重新训练,只需更改指令。我们称之为 Ext(扩展)配置。它将每个数据集的额外类别定义和一些工作示例添加到提示中。它还删除了否则会与之冲突的不要标记行,例如一旦公司名称成为目标就从公共列表中删除"商业地址"。包仓库列出了完整的额外类别定义。
效果显著,且在我们测试的所有模型上都适用,无论前沿模型还是小模型。Extended-entity F1 跃升数倍,而核心准确性保持不变或略有提升:
基础提示与扩展(Ext)配置的对比,针对五个公开数据集,按 Extended-entity F1 排序。添加额外的类别定义将 extended-entity F1 提升约六倍,同时也将 core F1 略微推高。这在所有测试模型上都有效,而固定范围标记器如果不重新训练则无法针对这些类别。
同一个杠杆可以泛化到全新的实体类型。要针对特定领域的一种实体,只需将其定义和一个示例添加到提示中。没有模型需要微调,也没有管道需要重新部署。结合其后方可自由选择模型的灵活性,同一个检测器可以在指令级别适应每个领域的词汇表。
基于 LLM 的 PII 检测器将现成工具的最硬约束转化为通过两个杠杆设置的配置。这些约束是固定的实体范围和锁定于一个模型及一个部署。模型杠杆设置准确性、延迟和成本。在涵盖八种语言的五个公开语料库上,九个检测器的 Core F1 范围为 74.9–83.1%,PrivacyFilter 为 80.7%。开源 OSS-GPT 20B(81.6%)在 Amazon Bedrock 或你自己的 GPU 上运行同样良好。实体杠杆设置什么算作 PII:扩展配置将所有测试模型的 extended-entity F1 从约 12% 提升到约 73%,无需重新训练。因为检测逻辑是文本而非权重,同一个检测器可以适应新领域或新后端,而无需新模型。
如果你想将此应用到自己的数据上,后续步骤如下:
尝试检测器:安装包并在你自己语料库的样本上运行捆绑示例,看看它会标记什么。
选择后端:对于无需自托管的最高准确性,使用 Amazon Bedrock 上的托管模型(如 Mistral Large 3 或 OSS-GPT 20B)。要控制数据驻留,可为托管在你自己 GPU 上的开源模型(如 OSS-GPT 20B)提供你自己的适配器。
扩展模式:使用扩展配置(记录在包仓库中)作为模板,将你领域特定的实体定义添加到提示中,然后在你的样本上重新运行。
闭合循环:将检测到的跨度(携带精确的字符偏移量)输入到脱敏步骤中,使清洗后的文本流入你的训练管道。
由此,自然延伸也遵循相同的模式。支持新的实体类型或额外的语言只需修改指令,无需更换模型。
完整的检测系统提示词、每个数据集的标签映射、完整的检测器基准测试表,以及扩展配置(Extended-configuration)类别定义均记录在包仓库中。
示例代码:pii-detector 包,包含可运行的示例以及完整的提示词和标签映射文档。
基准测试和标签映射:完整的检测器基准测试表、每个数据集的标签映射,以及扩展配置类别定义。
Amazon Bedrock 控制台:启用模型访问并试用模型。
Amazon Bedrock 服务页面:概览、支持模型和定价。
Amazon Bedrock 文档:Converse API 和模型访问指南。
相关文章:Evaluate large language models for quality and responsibility – evaluating and comparing models on your own criteria.
相关文章:Redact sensitive data from streaming data using Amazon Comprehend – applying managed PII detection and redaction to text at scale.