AWS 让基于 LLM 的模型无关 PII 检测成为提示词与固定模式之间的较量

AWS 在五个公开数据集的 49,365 条记录上测试九种检测器后，发布了基于 LLM 的模型无关 PII 检测方案。这种方法挑战了传统个人身份信息检测背后的一项基本假设：AWS 并非在模型训练期间固定支持的实体，而是将这些定义置于提示词中。

这一转变意义重大，因为企业数据很少遵循一套永久不变的隐私模式。客户支持档案中可能包含账户引用、员工标识符、钱包地址、凭证以及组织特有的代码。仅针对姓名和电话号码训练的检测器，无法自动识别每一种新增类别。

AWS 表示，其设计可通过指令添加实体，无需标注另一套训练数据或重新训练标注模型。它还可以在 Amazon Bedrock 模型之间切换，或使用自定义的自托管后端。因此，这场较量并不只是 AWS 与另一家供应商之间的竞争，而是提示词配置的检测与长期定义这一软件类别的固定模式之间的竞争。

该基准测试为这场较量提供了实质内容，但尚不足以得出决定性结论。AWS 报告称，Mistral Large 3 的 Core F1 达到 83.1%，而 OpenAI PrivacyFilter 为 80.7%。不过，这些结果来自 AWS 及其配套示例仓库，而非独立评估。

最重要的结果涉及罕见实体，而非这一狭窄的标题差距。AWS 报告称，更改提示词使每个受测模型的扩展实体 F1 都提升了数倍。如果这一结果在真实企业文本中成立，隐私团队将获得一种更快速的检测策略适配方式。

AWS 实际发布了什么

AWS 发布的是一条可配置的检测流水线，而非一个新训练的隐私模型。

该项目于 2026 年 9 月 10 日通过 AWS Machine Learning Blog 发布。作者 Christophe Dupuy 和 Rahul Gupta 介绍了一种指令驱动的检测器，并在开放的示例仓库中发布了其实现。

该检测器接收自由文本，并要求 LLM 识别敏感文本片段。片段是包含实体的确切文本部分，例如姓名或账号。模型会在结构化 JSON 列表中返回每个值及其类别。

随后，后处理层会在原始文本中查找每个返回的值，为其分配精确的字符偏移量，并移除重复检测结果。这一选择避免要求 LLM 计算位置；AWS 表示，模型无法可靠完成这一任务。

默认提示词定义了 15 个类别，包括私有和公开姓名、完整及部分地址、联系信息、金融数据、身份识别号码、凭证、日期、数字标识符和 URL。

提示词还包含排除项、简短定义和可选示例。这段文本充当检测器的运行模式。团队可通过修改指令来添加类别，而不是修改模型权重。

AWS 将该模式与推理后端分离。名为 Inferencer 的接口接收消息并返回模型响应。提供的适配器调用 Amazon Bedrock Converse API，开发人员也可以为其他环境实现相同接口。

已发布的代码通过在词边界处分割文本，支持超过模型上下文限制的输入。它还会重试暂时性的服务错误。根据该仓库，Boto3 是其唯一的运行时依赖。

恢复层处理了另一种典型的 LLM 失败情况。模型可能返回看似合理但不受支持的标签，例如提示词要求 DATES 时返回 DATE。软件会将已识别的变体映射回其定义的词汇表，并将无法解析的标签标记为未知。

这一机制让输出更易使用，但也揭示了为何 LLM 不能充当完整的隐私控制措施。在其他系统据此采取行动前，模型响应还需要经过验证、偏移量恢复、去重和标签规范化。

AWS 将最终生成的文本片段作为后续脱敏阶段的输入。检测器本身并不完成完整的数据清理流程。团队仍需要制定有关掩码、删除、审查、保留和例外处理的政策。

其直接目标是训练数据准备。自由格式文档可能含有模型日后会记忆或复现的个人信息。客户对话、人力资源记录、财务文件和聊天记录带来了尤其困难的检测条件。

不过，同一设计也可置于搜索索引、分析、支持自动化或内部 AI 助手之前。任何在系统间传递非结构化文本的工作流，都需要为敏感信息设置可靠边界。

这自然关联到工程团队如何管理可搜索知识库。检索质量固然重要，但隐私控制必须先决定哪些内容可以进入索引。

固定模式检测器为何面临压力

AWS 的方案对那些只能通过新一轮训练周期来更改支持实体列表的检测器施加了压力。

许多成熟的 PII 系统结合使用正则表达式、词典、规则和命名实体识别模型。命名实体识别会依据从标注示例中学习到的类别，为文本片段标注。这种结构在其预定范围内可以准确且可预测。

当组织对敏感数据的定义超出训练标签时，弱点便会显现。医院可能需要识别内部患者代码；制造商可能需要保护与客户关联的设备标识符；金融平台可能将钱包地址视为敏感信息。

传统标注器不会自动推断这些政策选择。团队通常需要新的示例、标注指南、模型训练、评估和部署。每一次变更都会变成一个小型机器学习项目。

基于 LLM 的模型无关 PII 检测将其中大部分工作移至指令层。团队定义实体、提供示例，并将修订后的提示词发送给选定模型。应用接口可以保持不变。

这种分离也降低了对单一模型家族的依赖。AWS 通过 Amazon Bedrock 展示了托管模型，也展示了托管在 Amazon EC2 上的开放模型。只要遵循预期消息接口，同一检测类别即可使用自定义后端。

Amazon 将其 Converse API描述为面向受支持对话模型的一致接口。这种一致性为检测器提供了共同的集成点，尽管模型行为仍有所不同。

模型选择决定准确率、响应时间、运营成本、上下文长度和部署位置。提示词则决定检测器应查找哪些实体。将这些决策分开，是该项目的核心架构主张。

这一主张同时挑战了固定标注器和单模型 LLM 工具。固定标注器限制了模式；与单一基础模型耦合的检测器则限制了采购和部署选择。

诸如 Presidio 的开源系统采取了更广泛的编排方法。它们可以组合识别器并支持自定义逻辑。这类系统仍然具有相关性，因为企业通常重视确定性模式和可审计规则。

因此，新出现的竞争并非在所有情境下都是 LLM 与正则表达式的对决。信用卡格式、电话号码模式和已知标识符仍可受益于确定性识别。压力落在无法快速适应语义类别变化的系统上。

上下文正是 LLM 提供独特优势的领域。同一个数字可能代表年龄、账户引用、日期或无害文本。语言模型能够理解周围词语，而非仅依赖表面结构。

但上下文也可能让结果更难预测。提示词措辞、模型更新、采样设置和输入格式均会影响响应。固定规则或许覆盖范围较窄，但团队通常可以准确解释其触发原因。

企业买家必须比较两类维护工作。传统系统在模式变化时需要更新代码、标签或模型。指令驱动系统则需要提示词治理、回归测试和持续的模型评估。

AWS 降低了变更声明模式的成本，但并未消除证明修订后检测器有效的必要性。这一区别将便捷配置与可靠的隐私执行区分开来。

该项目推出之际，组织正将更多私密文本送入生成式 AI 流水线。数据从档案流向嵌入、微调语料、智能体记忆和检索系统。每增加一份副本，遗漏实体的后果都会扩大。

NIST Privacy Framework将隐私视为企业风险管理问题，而非单纯的分类问题。检测支持这一体系，但治理仍决定可接受的数据收集、使用、存储和披露。

基于 LLM 的模型无关 PII 检测在新实体上展现出最强优势

该基准测试最具影响力的结果，是提示词恢复罕见类别的能力，而不是某个模型微弱的 F1 领先优势。

AWS 使用托管在 Hugging Face 上的五个公开 PII 数据集评估了该方法。样本包含 49,365 条记录，以及横跨八种语言的 222,114 个真实标注核心文本片段。

这些语言包括德语、英语、西班牙语、法语、印地语、意大利语、荷兰语和泰卢固语。数据集涵盖合成档案、人力资源文件、金融文本和客户服务材料。

AWS 比较了九种基于 LLM 的检测器。其中三种通过 Amazon Bedrock 运行，另有六种使用托管在 Amazon EC2 上的模型。OpenAI PrivacyFilter 是其中一个自托管对比系统。

该评估将不一致的数据集标签映射为 12 种规范实体，涵盖姓名、地址、联系信息、日期、年龄、国家身份标识符、金融数据、网络地址、URL、用户名、凭证和身份识别号码。

仅当预测的起始位置、结束位置和标签都与真实标注完全一致时，预测才会被视为正确。AWS 报告了精确率、召回率和 F1；后者平衡前两项指标。

Mistral Large 3 以 83.1% 的基础 Core F1 得分最高。EC2 上的 OSS-GPT 20B 以 81.6% 紧随其后。PrivacyFilter 达到 80.7%，而列出的最低分为 Nova Lite 2 的 74.9%。

这些结果并不表明每个 Bedrock 模型都优于现成的检测器。一款托管模型领先 PrivacyFilter，而另一款则落后它 5.8 个百分点。模型选择显然仍会产生实质影响。

延迟的差异更为明显。Gemma-4-E4B-it 的单次检测估计耗时为 0.43 秒，而 Qwen3.5-9B 需要 15.31 秒。根据 AWS 的估计，Mistral Large 3 需要 1.16 秒。

AWS 警告称，这些数字是根据并行批处理执行推算得出的，不应被理解为有保障的单请求延迟。基础设施、批处理方式、记录长度和服务条件都可能改变生产环境中的表现。

OSS-GPT 20B 的对比结果支持后端可移植性的说法。AWS 报告称，EC2 上的 Core F1 为 81.6%，通过 Bedrock 则为 81.3%。0.3 个百分点的差异表明，在这些经过测试的配置中，准确率相近。

更有力的证据来自扩展实体实验。多个数据集包含规范核心范围之外的类别，例如职业、公司名称、钱包地址、车辆标识符和用户代理字符串。

基础检测器几乎没有理由标记这些类别，因为其提示词并未定义它们。随后，AWS 通过 Extended 配置加入定义和示例。底层模型均未接受额外训练。

据报道，对于 Qwen3.6-35B-A3B，扩展实体 F1 从 9.4% 升至 80.5%。OSS-GPT 20B 从 12.1% 升至 73.3%。Mistral Large 3 从 17.3% 升至 72.7%。

模式扩展后，核心性能并未崩溃。AWS 报告称，Mistral Large 3 的 Core F1 从 83.1% 提升至 89.1%。OSS-GPT 20B 则从 81.6% 提升至 83.1%。

这些提升应被视为 AWS 报告的基准测试结果。完整的方法论和映射见项目的基准测试文档。仍有必要进行独立复现。

不过，该实验直接检验了项目的核心论点：无需重新进行带标签训练，仅通过新的实体定义就能产生有用的检测结果。这与固定标签器相比，是一项具有实际运营意义的差异。

它也改变了谁能够修改检测器。隐私专家和领域负责人可以协助编写实体定义与示例。机器学习工程师仍然是评估、基础设施和故障分析所必需的，但并非每次模式修订都需要他们参与。

结果更支持“策略即提示词”的工作流。团队可以将指令与应用代码一同进行版本管理，测试每项变更，并让相同样本通过多个模型。相比重建周边管线，这让替换模型变得更容易。

然而，提示词可移植性并不保证行为等价。两个模型可能遵循相同的实体定义，却返回不同的文本范围。模型无关架构意味着后端可以替换，并不意味着每次替换都会有相同表现。

基准测试仍存在生产级验证缺口

AWS 展示了一个可信的原型和广泛的内部基准测试，但两者都无法证明其在组织私有数据上的安全表现。

第一个限制在于来源独立性。AWS 设计了检测器、选择了评估方法、运行了基础设施，并发布了结果解读。公开的代码提升了透明度，但外部复现将增强这些发现的可信度。

第二个限制在于数据集的真实性。公开语料库使可重复比较成为可能，但其中若干数据集包含合成或标准化示例。生产文本则包含拼写错误、格式损坏、语言混用、复制的签名、非常规缩写和组织特有的简写。

第三个限制是仍然存在的错误率。接近 83% 的 F1 分数可用于分流，但隐私失误并不对称。遗漏一个国家级身份证明文件，可能比多次误报更重要。

总体 F1 也可能掩盖类别层面的薄弱环节。AWS 报告称，在一个数据集上，OSS-GPT 20B 在 SSN、金融和身份识别类别中的表现超过 95%。同一分析中，日期检测的表现则接近 50%。

日期体现了一个真实的策略问题。日期可能标识出生、预约、交易、出版或公开事件。正确标签通常取决于上下文和组织的隐私规则。

精确匹配评分要求很高，因为部分正确的边界不会获得任何分数。这种严格性对脱敏很有用，因为暴露部分值就可能使控制失效。但它也可能放大细微的标注差异。

多语言平均值带来另一项风险。AWS 报告称，针对一个模型和数据集，八种语言的 Core F1 处于 83% 至 90% 区间。这一证据并不能证明其在方言、混合语言文档或所有书写系统中的表现。

提示词注入值得特别关注。检测器将不可信文本置于发送给通用模型的指令附近。文档可能包含试图覆盖任务或操纵输出的语言。

公开的提示词结构和解析层可以减少格式错误的响应。但它们无法保证每个模型都会忽略对抗性内容。团队需要使用包含类似指令的文本、编码值、碎片化标识符和刻意规避内容的测试。

幻觉标签带来相关担忧。AWS 的恢复层将常见变体映射到批准类别，并将未识别标签显示为未知。这比悄然虚构一个类别更安全，但仍需要监控。

偏移量恢复也会引入边缘情况。模型返回的是值而非位置，软件会在源文本中搜索这些值。重复字符串、标准化标点、Unicode 变体或变更后的空白字符，都可能使匹配变得复杂。

该项目对模型输出的依赖也带来了变更管理义务。服务提供商可以在不更改调用代码的情况下更新托管模型。团队应检测这些更新是否改变召回率、误报率或格式行为。

因此，生产部署需要一个由具有代表性的内部样本构建的版本化测试套件。该套件应包括罕见实体、多语言文本、对抗性段落、空记录、长文档和已知的困难负例。

对于不确定情况和高影响工作流，人工审核仍然合适。检测器可以为记录排序优先级、标记文本范围，或阻止自动摄取。但在没有可恢复流程和明确策略的情况下，它不应自动删除源数据。

团队还应避免将原始敏感文本发送至非预期的区域或服务。Bedrock 访问、身份权限、网络路径、日志记录、加密和数据驻留都需要单独审查。只有在部署配置正确时，模型可移植性才有帮助。

需要在真实记录上衡量成本和吞吐量。每次检测的延迟在数百万份文档中可能变得相当可观。批处理和并发可以提高吞吐量，而更长的提示词和重复示例会消耗更多 token。

混合架构可能比纯 LLM 设计更实用。确定性识别器可以快速捕获结构化模式。LLM 可处理模糊上下文和组织特有实体，而审核则保留给不确定结果。

在这里，固定模式与提示词模式的框架就不再那么绝对。企业很少需要一个通用检测器。它们需要的是分层控制，其组件以不同方式失效，并暴露足够证据供调查。

真正的决策关乎控制，而非最高分数

模型选择决定性能，但运营控制决定检测器是否适合受监管的工作流。

Amazon Bedrock 提供了一条托管路径，可通过一个对话式接口使用受支持的模型。这可以减少基础设施工作，并简化受控对比。团队无需改变检测器的公开调用模式，只需更换模型标识符即可。

自托管提供了另一种形式的控制。组织可以将推理保留在自己管理的基础设施内，并选择硬件、网络边界和更新计划。但这也意味着需要承担容量、补丁、可用性和监控责任。

AWS 的架构支持这两条路线，因为 Inferencer 接口很小。任何兼容适配器都可以接收消息并返回助手文本。即使是从不使用 Bedrock 的团队，这一抽象也很有价值。

它让模型评估成为持续进行的采购决策，而非一次性的应用承诺。团队可以使用相同提示词和测试语料库比较准确率、延迟和运营约束。

不过，后端可移植性可能带来虚假的信心。从技术上看，一行配置变更很简单，但替换模型应触发回归测试。接口等价并不意味着隐私结果等价。

不同模型可能以不同方式理解排除规则。它们可能对公开姓名、商业地址、部分标识符和上下文日期存在分歧。它们的 JSON 可靠性以及抵御指令冲突的能力也可能不同。

提示词变更也需要同样的严谨性。新增类别可能与现有排除规则重叠，或意外扩大检测范围。AWS 指出，其 Extended 配置会移除与新受保护类别冲突的排除规则。

例如，某个组织可能开始将雇主名称视为敏感信息。随后，它必须重新考虑任何豁免公开公司信息的指令。这是一项策略决策，而不只是方便的提示词编辑。

版本控制可以让这些选择变得可见。团队可以审查每项定义、示例、排除规则、模型标识符和评估结果。部署审批可以引用特定配置，而不是非正式的提示词。

成熟的工作流还应在不制造另一项隐私问题的前提下存储检测证据。日志需要足够的上下文来诊断错误，但将完整敏感值复制到可观测性系统会增加暴露风险。

一种选择是记录类别、位置、置信度代理、配置版本和受保护的文档引用。当调查确有必要时，审核人员可以通过授权系统检索源文件。

置信度本身仍然难以处理。生成式模型不会自动为每个文本范围返回经过校准的概率。团队可能需要跨模型一致性、重复评估或单独的验证规则来确定不确定案例的优先级。

检测器的模型替换能力使集成测试成为可行选择。团队可以比较快速模型与更准确模型的输出。但这会使复杂性翻倍，并可能增加数据传输。

最佳的初始部署很可能是在下游 AI 工作流之前设置一个范围有限的关卡。检测器可标记或脱敏候选范围，同时由现有策略控制处理审批和例外情况。

训练数据准备很适合这种模式，因为清洗本就发生在模型开发之前。搜索摄取和智能体记忆也是有力候选，因为团队可以在文本扩散前将其拦截。

实时客户交互带来更严格的约束。延迟、误报和可用性会立即产生影响。每条记录需要数秒的检测器，可能需要异步处理或更快的第一阶段过滤器。

AWS 通过发布实现降低了实验门槛。但它并未消除生产级隐私所需的工程工作。其价值在于减少模式摩擦，同时保留部署选择权。

三个信号将决定基于提示词的路线能否站得住脚

独立复现、对抗性测试和持续的生产使用，将决定这一设计能否成为可靠的隐私层。

第一个信号是对基准测试的独立复现。研究人员或企业团队应使用公开的检测器运行相同数据集，并报告完整的类别级结果。

复现应验证提示词、模型版本、采样设置、映射、基础设施和评分代码。接近的结果将增强 AWS 的核心主张。较大差异则会暴露评估中的隐藏敏感性。

第二个信号来自对抗性和组织特定数据的证据。测试应包括提示注入、混淆标识符、多语言代码切换、重复值、Unicode 替换以及少见的内部代码。

成功意味着：由提示定义的模式能够在杂乱文本中保持稳定，且召回率不会出现不可接受的损失。失败则表明，更容易的定制化可能将过多风险转移到了提示行为和后处理环节。

第三个信号是可衡量的生产采用情况，以及公开的运营实践。有价值的报告应说明吞吐量、审核率、误报成本、模型更新、数据驻留控制和事件处理方式。

采用本身并不能验证准确性。已记录的保障措施能够表明，团队是否可以通过配置变更和后端替换来治理检测器。没有评估细节的静默部署，所提供的证据要弱得多。

短期内，开发者应将该项目视为一套可测试的参考架构。它提供代码、映射、示例和基准测试结果，而不只是产品层面的宣称。

隐私团队应从自己熟悉的语料开始。定义真正重要的实体，包括通用工具容易遗漏的内部标识符。随后按类别衡量召回率，并检查每一个严重的漏报。

平台团队应至少比较两个合适的后端。他们应记录延迟分布、格式错误的响应、未知标签、偏移量失败情况和总吞吐量。平均 F1 分数本身无法用于选择生产模型。

安全审查人员应攻击整条流水线。测试计划应涵盖恶意文档指令、日志暴露、过度权限、区域路由以及不安全的下游删除操作。

LLM 驱动、模型无关的 PII 检测背后的更大押注其实很直接：隐私定义的变化速度快于传统模型训练周期，因此这些定义应成为可配置的运行时策略。

AWS 已为这一押注提供了有意义的证据，尤其是在扩展实体方面。它也揭示了仍待完成的工作，包括模型差异、后处理、对抗性韧性和独立验证。

正确的下一步并非替换所有现有检测器。选择一个范围明确的数据集，保留当前控制机制作为基线，并让两个系统同时针对经过审核的真实标签运行。

应该由什么结果来决定取舍？首先跟踪漏检的高风险实体，其次考察审核负担、延迟和运营控制能力。如果基于提示的检测器能够更快适应，同时不削弱这些指标，那么 AWS 的架构论点将更难被忽视。