本文档由英文原版机器翻译而成。如果翻译版本与英文原版之间存在任何冲突，请以英文原版为准。 阅读英文原版
设备端匿名化器：构建与基准测试
2026-05-22 · Caiioo Team
我们希望解决 AI 系统在训练和保留真实个人身份信息方面的隐私问题。“零数据保留”政策和协议虽然降低了风险，但充满了例外条款。它们本质上是在说：“我们不会存储您的任何提示词或输出，除非：(此处插入一长串例外清单：安全目的、政府监管、诉讼保全、产品开发、错误日志、改进服务……)”
为了解决这个问题，我们构建了一个在用户自己机器上运行的个人数据过滤器，它在消息离开设备之前对其进行处理，并返回与用户在未开启过滤器时完全相同的答案。
于是我们做到了。Caiioo 的下一个版本将包含该匿名化器。可以通过智能体聊天中的盾牌图标以及设置进行访问。
本白皮书概述了我们隐私过滤系统背后的基本原理、架构、评估过程和设计原则。
我们的目标
通过数据最小化实现通用隐私保护。 当用户与远程模型对话时，模型并不需要真实姓名、家庭住址、真实电子邮件或客户电话号码来回答用户的问题。它需要的是问题的轮廓，并且需要看起来像一个真实的问题，这样 LLM 才不会将查询视为测试而忽略。因此，过滤器会从发送给 AI 的数据中剥离真实标识符，并在返回过程中将真实值缝合回去。模型看到的是合成的姓名和标识符；用户看到的是真实的对话。
HIPAA 合规协助。 第二种模式针对 HIPAA 安全港规则 (§164.514) 中的 18 项标识符以及较宽松的受限数据集 (Limited Data Set) 变体。临床医生、医疗保健管理员或任何从事受监管工作流的人员都可以与通用模型讨论真实案例，而无需将受保护的健康信息发送给 AI。我们不是受监管实体的合规官——但我们可以作为防止 PHI 离开笔记本电脑的第一道防线。我们的评估提供了可衡量的基准，组织可以使用这些基准来评估过滤器是否符合其合规性和隐私标准。所有隐私和安全措施均为判断性决策，由用户或用户实体负责。
我们选择这两者是因为其工程原理相同，而且 PHI 使用场景在技术上实际上更容易，因为它使用了独特的命名实体，这比个人数据 (Personal Data) 类别中更通用的数据更容易脱敏。HIPAA 过滤还得益于其通常使用英语或西班牙语。我们检测标识符，替换为相同格式的稳定伪名和替代标识符，在返回时将其还原，并且绝不记录真实值。合成信息与真实信息之间的映射仅保留在用户的设备上，以便用户可以在智能体的响应中阅读真实信息。模式之间的区别仅在于类别列表和策略网关。
为什么采用正则表达式加机器学习，而不是仅用其一
我们的匿名化工具中包含两种主要的过滤技术：一种是名为正则表达式（regex）的确定性模式识别语言，另一种是经过训练的机器学习模型。
正则表达式在表面格式识别上具有无可比拟的优势。电子邮件地址有其固定的形态 ([email protected])。IP 地址、信用卡号、IBAN、VIN、SSN (XXX-XX-XXXX) 以及 API key 也是如此。如果格式是可靠的，正则表达式就能以确定性的方式捕捉到它，且每次都能成功，无需加载模型，也没有推理成本。
然而，正则表达式在处理上下文时却无能为力。“Sarah's chart from last Tuesday”（莎拉上周二的图表）包含一个人物和一个日期，但仅凭格式无法将其中任何一个识别出来。“The patient at 14 Elm”（榆树街 14 号的患者）包含一个地址，而该地址的格式与成千上万个非地址信息重叠。“Their MRN is 7741032”（他们的病历号是 7741032）则需要结合数字周围的词汇才能产生实际意义。
一个经过微调的小型语言模型可以处理上下文——我们的模型是一个经过特殊训练的 1.1 亿参数（110M-parameter）编码器，由一个多语言微型语言模型蒸馏而成。它读取的是句子而非子字符串，且体积足够小，可以在设备（甚至是手机）上极速运行。
基准测试说明了这两层技术的互补优势。我们对这两层进行了隔离测试，以确保每一层都发挥了应有的作用。在包含 150 个问题的 PrivacyBench-PD 测试集中（这些问题和答案明确未被用于模型训练）：
| 层级 | 捕捉到的 PII | 捕捉率 |
|---|---|---|
| 仅正则表达式 | 205 / 670 | 30.6 % |
| 仅机器学习 | 516 / 670 | 77.0 % |
| 两者结合 (生产环境) | 625 / 670 | 93.3 % |
仅靠正则表达式会漏掉四分之三的标识符，因为真实文本中的大多数标识符是非结构化的。仅靠机器学习则会漏掉正则表达式层本可以捕捉到的 16 个百分点——即那些纯粹取决于其形状的信息（信用卡看起来就是信用卡；模型没有额外的信号可以补充）。两者结合，覆盖了彼此无法单独覆盖的范围。
深入观察每一层发挥决定性作用的场景：在同一测试集中，有 16 个测试值仅被正则表达式捕捉到（电子邮件、IP、金融账户、结构化 ID），而有 327 个测试值仅被机器学习捕捉到（姓名、上下文标识符、多语言表述）。
轻量、智能、快速——且随处运行
让过滤器在设备端运行是一项工程挑战。
它必须足够轻量，因为我们的应用在多种系统的设备上运行：浏览器扩展、macOS 应用、iOS 应用、Android 应用，以及 Windows 和 Linux。每个模型的包大小约为 113 MB。共有两个模型——一个用于通用个人数据，一个用于受保护的健康信息——安全港模式会并行运行这两个模型。在这些设备中，低端 Android 设备的性能最弱，但我们的系统依然运行良好。
它必须足够智能，因为漏报会导致真实数据泄露给远程 LLM，而误报则会破坏对话。姓名必须被脱敏，而代词则不应被脱敏。转发邮件中的医生邮箱应该被脱敏，但页脚的 [email protected] 可能不需要。
它必须足够快速，因为它直接位于用户发送或接收的每条消息的路径上。我们测得在单 CPU 线程上的往返开销低于 200 毫秒，大部分是分词耗时。在 WebGPU 和 Apple 的神经网络引擎（Neural Engine）上，与 LLM 调用的网络延迟相比，这一开销微乎其微。
它必须支持多种运行环境，因为 Caiioo 是跨平台的。同一套系统运行在 Chrome 扩展、macOS 和 iOS、Android 以及 Windows 和 Linux 上。统一的检测模型、统一的正则库、统一的合并器、统一的策略——在 Caiioo 运行的每个界面上都保持行为一致。
评分结果
经过多轮测试和训练，我们最终确定了模型的第 16 个版本。以下是三个基准测试，分别衡量不同的维度。
我们自己的测试集，模型从未见过的 150 个问题
在针对公共基准进行测试之前，我们针对一个刻意从训练数据中排除的内部测试集运行了 Personal Data 过滤器——因此检测器从未见过这些问题。150 个问题被分为四组（代码片段、文档正文、刻意设计的陌生措辞以及 10 种非英语语言），外加一个完全不包含私密数据的“负向”组（用于检查我们是否过度脱敏的健全性检查）。结合 regex + ML 流水线的结果如下：
| 子基准 | 捕获数 | 比率 |
|---|---|---|
| code_bench | 69 / 74 | 93.2 % |
| doc_bench | 233 / 247 | 94.3 % |
| generalization_bench | 123 / 133 | 92.5 % |
| multilingual_bench | 200 / 216 | 92.6 % |
| 所有 4 个正向基准总计 | 625 / 670 | 93.3 % |
（负向组中没有需要查找的私密数据。过滤器屏蔽了一个不该屏蔽的内容——这与下文的精确度数据一致。）
评分标准非常严格：每个预期的私密数据片段必须从屏蔽输出中完全消失，该问题才能得分。没有部分得分，也没有“足够接近”。这比要求另一个 LLM 担任裁判的基准测试要苛刻得多（LLM 裁判往往比较慷慨）。有关与其他系统直接对比的数据，请参阅下文的对标部分。
PrivacyBenchHIPAA — 40 个医疗保健问题
每个问题都列出了必须脱敏的受保护健康信息（姓名、病历号等），以及必须保留的信号（日期、地理位置、90 岁以下的年龄——根据 HIPAA 有限数据集规则）。评分器会检查两个方向：我们是否删除了应该删除的内容，以及是否保留了应该保留的内容？
| 模式 | PHI 已脱敏 | 保留项已留存 |
|---|---|---|
| 有限数据集 (保留日期 / 地理 / 年龄 ≤89) | 79 / 79 (100 %) | 34 / 34 |
| 安全港 (脱敏包括日期在内的所有内容) | 99 / 104 (95.2 %) | — |
有限数据集子模式在此基准测试中表现完美。安全港模式由于需要脱敏的内容更多，因此遗漏的机会也更多，覆盖率为 95.2%。
基于我们自有数据的各类别结果，每种模式 200 个样本
公共基准测试通常将所有内容混为一谈。我们的内部测试数据按类别（姓名、电子邮件、地址等）细分结果，并以三种方式运行每一项：仅限 regex、仅限 ML 以及两者结合。这能准确告诉我们哪种技术捕获了哪种类型的标识符，以及各自在哪些方面需要对方的补充。最近一次运行时间为 2026-05-20：
三种过滤器模式的摘要
| 模式 | 综合召回率 | 精确度 | F2 | 样本数 |
|---|---|---|---|---|
| Personal Data 过滤器 | 97.3 % | 97.8 % | 97.4 | 200 |
| HIPAA 过滤器 — 有限数据集 | 92.3 % | 92.3 % | 92.3 | 200 |
| HIPAA 过滤器 — 安全港 | 91.9 % | 91.5 % | 91.8 | 200 |
这些数字不包括 URL，我们刻意保留了 URL——破坏 URL 会导致“打开此链接”或“获取该页面”等下游操作失效。更多相关内容请参阅下文的工作流部分。
各类别表格前的总体情况：在每种模式下，真正能识别个人身份的标识符几乎 100% 被捕获。姓名、电子邮件、电话号码、邮寄地址、政府 ID、生物识别 ID、精确地理位置、病历号、出生日期、社会安全号码——在每个样本、每次测试中都被捕获。我们低于 100% 的类别是可以预见的：设备 ID（真实文本中的格式极其多样）、杂项机构 ID（会员号、员工 ID——同样的问题）以及照片（纯文本过滤器无法看到图像内部的内容）。这些都不是真正关系到泄露风险的“图表上的姓名”或“草稿中的电子邮件”标识符。高风险类别的表现非常可靠。
Personal Data 过滤器
按综合召回率排序（最高优先），然后按风险层级（T1 = 最敏感）排序。
| 类别 | 层级 | regex 召回率 | ML 召回率 (原始) | 综合召回率 | 金标准数量 |
|---|---|---|---|---|---|
| biometric_id | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| email_address | T1 | 100.0 % (20/20) | 100.0 % (20/20) | 100.0 % | 20 |
| government_id | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| person_name | T1 | 13.3 % (4/30) | 96.7 % (29/30) | 100.0 % | 30 |
| phone_or_fax | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| postal_address | T1 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| precise_geolocation | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| birth_date | T2 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| ip_address | T2 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| online_handle | T2 | 40.0 % (4/10) | 100.0 % (10/10) | 100.0 % | 10 |
| vehicle_id | T2 | 50.0 % (5/10) | 100.0 % (10/10) | 100.0 % | 10 |
| authentication_secret | T4 | 40.0 % (4/10) | 100.0 % (10/10) | 100.0 % | 10 |
| financial_account | T1 | 90.0 % (18/20) | 100.0 % (20/20) | 90.0 % | 20 |
| institutional_id | T3 | 80.0 % (8/10) | 90.0 % (9/10) | 90.0 % | 10 |
| device_id | T3 | 40.0 % (4/10) | 50.0 % (5/10) | 80.0 % | 10 |
从横向对比来看，双层设计正在发挥作用。邮寄地址、出生日期和人名在仅使用 regex 的情况下得分仅为 0–13%——因为这些内容没有固定的匹配模式，所以只有 ML 模型能捕获它们。电子邮件、电话号码、IP、政府 ID、生物识别 ID 和精确地理位置在仅使用 regex 的情况下得分为 100%——这些是 ML 模型可以轻松获得的表面格式。在线账号、车辆 ID 和身份验证密钥的情况则比较复杂：regex 捕获标准形式，ML 捕获其余部分。在每个类别中，综合召回率都达到或超过了单层中最强的一项。
设备 ID 和杂项机构 ID 是低于 100% 的类别，我们知道原因：这些在真实文本中的格式最为多样。我们宁愿诚实面对召回率下降的类别，也不愿假装过滤器在任何地方都是完美的。
HIPAA 过滤器 — 有限数据集子模式
有限数据集子模式在设计上保留了日期、地理位置和 89 岁或以下的年龄——这些是 HIPAA 允许组织保留用于合法临床研究和运营的信号。
| 类别 | 层级 | regex 召回率 | ML 召回率 (原始) | 综合召回率 | 金标准数量 |
|---|---|---|---|---|---|
| biometric_id | T1 | 100.0 % (12/12) | 100.0 % (12/12) | 100.0 % | 12 |
| email_address | T1 | 100.0 % (13/13) | 100.0 % (13/13) | 100.0 % | 13 |
| medical_record_number | T1 | 100.0 % (26/26) | 100.0 % (26/26) | 100.0 % | 26 |
| person_name | T1 | 15.4 % (4/26) | 100.0 % (26/26) | 100.0 % | 26 |
| phone_or_fax | T1 | 100.0 % (13/13) | 100.0 % (13/13) | 100.0 % | 13 |
| social_security_number | T1 | 100.0 % (12/12) | 100.0 % (12/12) | 100.0 % | 12 |
| account_number | T2 | 0.0 % (0/13) | 100.0 % (13/13) | 100.0 % | 13 |
| health_plan_id | T2 | 0.0 % (0/13) | 100.0 % (13/13) | 100.0 % | 13 |
| ip_address | T2 | 100.0 % (12/12) | 100.0 % (12/12) | 100.0 % | 12 |
| license_number | T2 | 0.0 % (0/12) | 100.0 % (12/12) | 100.0 % | 12 |
| vehicle_id | T2 | 25.0 % (3/12) | 100.0 % (12/12) | 100.0 % | 12 |
| device_id | T3 | 41.7 % (5/12) | 100.0 % (12/12) | 100.0 % | 12 |
| photo | T2 | 0.0 % (0/12) | 0.0 % (0/12) | 0.0 % | 12 |
照片是已知的遗漏项——纯文本过滤器无法看到图像内部的内容。图像 PHI 是我们尚未发布的一个独立问题。此模式下的所有其他类别均为 100%。
HIPAA 过滤器 — 安全港子模式
安全港模式会剥离有限数据集子模式保留的所有内容——日期、89 岁以上的年龄、地理位置。为了获得最严格的覆盖，它并行运行两个过滤器模型：HIPAA 专用模型和通用个人数据模型。
| 类别 | 层级 | regex 召回率 | ML 召回率 (原始) | 综合召回率 | 金标准数量 |
|---|---|---|---|---|---|
| age_over_89 | T1 | 100.0 % (18/18) | 0.0 % (0/18) | 100.0 % | 18 |
| biometric_id | T1 | 100.0 % (9/9) | 100.0 % (9/9) | 100.0 % | 9 |
| email_address | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| medical_record_number | T1 | 100.0 % (20/20) | 100.0 % (20/20) | 100.0 % | 20 |
| person_name | T1 | 20.0 % (4/20) | 100.0 % (20/20) | 100.0 % | 20 |
| phone_or_fax | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| social_security_number | T1 | 90.0 % (9/10) | 100.0 % (10/10) | 100.0 % | 10 |
| account_number | T2 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| general_date | T2 | 100.0 % (27/27) | 29.6 % (8/27) | 100.0 % | 27 |
| health_plan_id | T2 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| ip_address | T2 | 100.0 % (9/9) | 100.0 % (9/9) | 100.0 % | 9 |
| license_number | T2 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| vehicle_id | T2 | 10.0 % (1/10) | 100.0 % (10/10) | 100.0 % | 10 |
| device_id | T3 | 22.2 % (2/9) | 88.9 % (8/9) | 77.8 % | 9 |
| photo | T2 | 0.0 % (0/9) | 0.0 % (0/9) | 0.0 % | 9 |
两个有趣的行是通用日期（regex 100%，ML 30%）和 89 岁以上的年龄（regex 100%，ML 0%）。我们在安全港模式中刻意让 regex 处理这两项：日期具有 regex 每次都能捕获的形状，而且我们不希望概率模型去猜测像“>89”这样的数值阈值。确定性规则比要求 ML 模型学习相同的规则更可靠。
所有类别的总体数据
综合来看：完整流水线（regex + ML 结合）与单一层相比表现如何？
| 模式 | 层级 | 召回率 | 精确度 | F2 |
|---|---|---|---|---|
| Personal Data | 仅限 regex | 65.8 % | 93.0 % | 69.9 % |
| Personal Data | 仅限 ML | 95.4 % | 92.4 % | 94.8 % |
| Personal Data | 两者 (完整) | 96.9 % | 98.0 % | 97.1 % |
| 有限数据集 | 仅限 regex | 55.9 % | 95.0 % | 60.9 % |
| 有限数据集 | 仅限 ML | 92.9 % | 84.5 % | 91.0 % |
| 有限数据集 | 两者 (完整) | 92.9 % | 89.3 % | 92.1 % |
| 安全港 | 仅限 regex | 58.9 % | 93.6 % | 63.6 % |
| 安全港 | 仅限 ML | 82.4 % | 88.3 % | 83.5 % |
| 安全港 | 两者 (完整) | 92.4 % | 88.9 % | 91.7 % |
Personal Data 过滤器的“完整”行在每项指标上都优于单层版本——将 regex（用于表面格式）与 ML 模型（用于上下文）相结合，确实提供了单一层无法实现的效果。本文开头提到的 97.3% 标题数据反映了真实用户获得的结果。上表中的数字略低，仅是因为它包含了 URL 类别，而我们为了不破坏链接和工具调用而刻意保留了该类别。
与其他专用隐私过滤器的对标测试
对于像我们这样在设备端运行、近乎即时的隐私过滤器，公平的比较对象应该是其他在设备端运行、近乎即时的隐私过滤器——而不是那些每条消息需要数秒处理时间且需要网络往返的大型云端托管 LLM。我们针对相同的测试集，使用相同的匹配规则运行了该类别中的每个系统。对每个人都采用相同的标准。
同类产品包括：
- openai/privacy-filter — OpenAI 的开源专用隐私过滤器。约 5000 万参数，小到可以在任何现代浏览器中运行。
- piiranha-v1 — 来自 iiiorg 的 2.78 亿参数检测器。其许可证限制其仅用于研究和评估（我们可以测量它，但不能进行商业发布）。
- Microsoft Presidio — 部署最广泛的开源脱敏工具，结合了传统模式匹配和用于上下文的小型语言模型。
- GLiNER PII 系列 — 一个小型通用实体分类器系列。Knowledgator 发布了 small (~44M)、base (~86M) 和 large (~304M) 变体；NVIDIA 在 2025 年 10 月发布了一个 570M 变体。
- Caiioo 的三种模式（Personal Data、HIPAA 有限数据集、HIPAA 安全港）。
五个测试集的召回率如下，Caiioo 排在首位：
| 系统 | PrivacyBench PD-25 | Caiioo 合成 PD-200 | PrivacyBenchHIPAA-40 | Caiioo 合成 PHI-200 | 多语言 PD-40 (10 个地区) |
|---|---|---|---|---|---|
| Caiioo — Personal Data | 96.2 % (76/79) | 99.0 % (198/200) | — | — | 92.6 % (200/216) |
| Caiioo — HIPAA 有限数据集 | — | — | 100.0 % (79/79) | 100.0 % (200/200) | — |
| Caiioo — HIPAA 安全港 | — | — | 100.0 % (79/79) | 100.0 % (200/200) | — |
| openai/privacy-filter (50M) | 96.2 % (76/79) | 83.0 % (166/200) | 93.7 % (74/79) | 77.0 % (154/200) | 94.9 % (205/216) |
| gliner_pii_nvidia (570M) | 94.9 % (75/79) | 85.5 % (171/200) | 84.8 % (67/79) | 85.0 % (170/200) | 76.9 % (166/216) |
| gliner_pii_large (~304M) | 72.2 % (57/79) | 86.5 % (173/200) | 84.8 % (67/79) | 93.0 % (186/200) | 50.0 % (108/216) |
| gliner_pii_base (~86M) | 87.3 % (69/79) | 66.0 % (132/200) | 74.7 % (59/79) | 66.0 % (132/200) | 51.4 % (111/216) |
| gliner_pii_small (~44M) | 88.6 % (70/79) | 84.5 % (169/200) | 91.1 % (72/79) | 83.0 % (166/200) | 68.5 % (148/216) |
| Microsoft Presidio | 82.3 % (65/79) | 76.5 % (153/200) | 84.8 % (67/79) | 76.5 % (153/200) | 69.0 % (149/216) |
| piiranha-v1 (~278M) | 60.8 % (48/79) | 58.5 % (117/200) | 43.0 % (34/79) | 47.0 % (94/200) | 82.4 % (178/216) |
Caiioo 在两个最大的测试（PD-200 和 PHI-200）中领先于专用过滤器类别，在公共基准测试中持平或领先，在多语言测试中排名第二。在最小的测试（PrivacyBench PD-25，仅 25 个问题）中，Caiioo 和 openai/privacy-filter 以 96.2% 持平。在多语言方面，openai/privacy-filter 仍以 94.9% 领先，Caiioo 为 92.6%——我们落后最多的语言是中文；在其他所有地方，我们都处于或接近顶尖水平。如果多语言覆盖是任务关键型的，openai/privacy-filter 是一个合理的替代方案。对于此类工作负载中的大多数其他情况，Caiioo 则是首选。
HIPAA 的结果是重头戏。Caiioo 的两种 HIPAA 模式在每次 HIPAA 测试中都达到了 100% 的召回率——每个患者姓名、每个病历号、每个出生日期、每个账号都被捕获。排名第二的系统是 openai/privacy-filter，在 PrivacyBenchHIPAA 上的得分为 93.7%——在每一个遗漏都意味着真实世界泄露的基准测试中，这是一个 6.3 个百分点的差距。
第二个值得关注的数字是：过度脱敏——屏蔽了并非真正私密数据的内容。过度脱敏不是隐私损害，而是可用性成本。屏蔽过多内容会导致 LLM 的推理能力变差，返回的答案质量下降。Caiioo 在各测试集中不必要屏蔽的次数为 1–24 次。Presidio 为 10–51 次。NVIDIA 的 GLiNER 仅在 HIPAA 测试中就达到了 31–64 次。当目标是以最小的暴露风险获得最佳答案时，精确度与召回率同样重要。
为什么不直接使用前沿 LLM 作为过滤器？
它们确实可以——而且在原始召回率上，它们会胜出。大型通用 LLM（Llama 3.1 8B、Gemma 4、Qwen 3.5 9B 等），无论是在云端还是本地运行，在包括多语言在内的每项测试中都能获得 95–100% 的分数。对于需要最高召回率且愿意为此付出代价的用户来说，这确实是一个选择。
然而，缺点也很明显：
- 速度慢。 每条消息需要数秒而不是数毫秒。过滤器位于用户发送的每条消息之前。
- 要么消息离开用户的机器，要么模型离开。 要在云端过滤，消息必须上传——这违背了初衷。要在设备端过滤，则需要下载 1–17 GB 的模型。
- 容易被欺骗。 生成式模型可能会在消息中间被诱导不进行脱敏（“提示词注入”攻击）。像我们这样的小型分类器则不会。
- 输入相同，输出不同。 生成式模型并不总是两次给出相同的答案。这会破坏往返过程——发出的屏蔽和返回的去屏蔽依赖于同一个真实值始终映射到同一个伪造值。
Caiioo 是为这种权衡的另一面而构建的：一个微型、可预测、亚秒级的过滤器，在用户按下发送键之前在编辑器中运行，并且在对话中始终为相同的真实值生成相同的伪造值，从而保持往返过程的一致性。上方的同类产品对比表是此类用例的对等比较。
事实胜于雄辩
基准测试只是起点，而非终点。该过滤器已集成到 Caiioo 的新功能中：匿名化器（pseudonymizer）——这是实际位于编辑器与模型之间的组件。
以下是用户点击发送时发生的过程：
- 检测。 正则表达式（regex）层首先运行——它是确定性的，且速度达到微秒级。机器学习（ML）模型随后对剩余内容进行处理。如果两层在同一段文本上重叠，我们遵循一个简单规则：正则表达式在表面格式上胜出，ML 在上下文理解上胜出。
- 标记自我与他人。 Caiioo 会区分指向用户本人的标识符与指向他人的标识符。用户可以选择仅脱敏其中之一，或两者全部脱敏。用户添加到个人词典中的名称始终被视为“自我”。
- 替换。 每个真实值都会获得一个稳定且风格匹配的假名。例如，“Sarah Goldberg” 变为 “Maya Hartwell”——并在整个对话过程中保持为 “Maya Hartwell”，这样模型对该人物的推理就不会在多轮对话中产生碎片化。真实值与虚假值的对照表保存在用户的设备上，并使用来自平台钥匙串（keychain）的密钥进行加密。
- 发送。 模型接收到的是一条完全虚假的消息。任何真实标识符都不会跨越网络，我们的审计日志仅记录计数——绝不会记录数值本身。
- 还原。 流式响应在到达时会被映射回原值。模型回复中的 “Maya Hartwell” 在显示到屏幕之前会变回 “Sarah Goldberg”，并以微光胶囊样式渲染，以便用户一眼就能看到哪些内容受到了保护。
- 同时还原工具参数。 如果模型调用了一个工具——例如发送电子邮件、提交工单、写入文档——且参数中包含虚假值，我们会在工具运行之前将真实值替换回去。模型基于虚假值进行推理；而实际操作则采用真实值。
该过滤器并不关心正在使用的是哪种 AI 服务。它在消息到达模型之前运行，因此 OpenRouter、Anthropic、Google、OpenAI 以及本地的 Ollama 接收到的都是经过掩码处理的相同载荷。添加新的供应商不会重新产生隐私漏洞。
保护对象
用户。 用户的姓名、电子邮件、地址、电话、IP 和生物识别标识符——这些共同构成聚合器识别个人身份的信息——在开启过滤器时绝不会离开设备。
用户谈论的人。 大多数隐私工具只关注输入者，但它们忽略了“社会契约”——即我们对他人和对自己都负有责任。将“请分析桑德斯先生的不称职行为”提交给 LLM（其可能会被无限期记录在系统日志中）是不负责任的（且具有潜在的诽谤性）。向 LLM 寻求关于包含 1,000 个业务联系人的 Google Sheet 的帮助，会将所有这些信息存入数据保留的“粘蝇纸”中（程度取决于实际生效的“零数据保留”政策）。Caiioo 的过滤器也涵盖了第三方：正在起草合同的客户、正在分析病历的患者、被粘贴进上下文的邮件联系人。他们并未同意让远程 LLM 看到其标识符。过滤器默认尊重这一点；如果工作流需要，用户可以切换到“仅限自己”或“仅限他人”。
实体——企业、医院、公司。 账号、许可证号、病历号、财务路由详情、内部 ID、API 密钥、客户名单。企业与个人一样具有数据最小化的利益。临床医生使用 Caiioo 起草出院小结时，不会将患者的病历号发送给 OpenAI。律师不会将客户的账号发送给 Anthropic。支持工程师不会将客户日志中的 API 密钥发送给 Google。过滤器不会询问标识符属于个人还是实体——它只是将其保留在设备上。
效用最大化，暴露最小化
核心点在于用户不应该感觉到过滤器的存在。
大多数隐私工具强迫用户做出选择：要么进行激进的脱敏并眼睁睁看着模型的回答变差，要么保持提示词可用但看着隐私承诺瓦解。我们拒绝这种权衡。模型仍然会收到一个完整的提示词——它能看到姓名、地点、日期、病历号，且都在正确的语法位置上。它看到的只是虚假的信息。它的推理逻辑是完全一致的，只是字符串被擦除了。
稳定的替换是实现这一点的关键。因为在一次对话中，同一个真实值总是映射到同一个虚假值——无论是用户的消息、引用该姓名的工具返回结果，还是模型之前提到它的回复——模型都有一个连贯的人物、地点或事物进行推理。多轮对话不会变得混乱。工具调用不会中断。子智能体会继承父对话的映射表，并在整个任务中保持一致。
用户看到的是真实的对话。提供商看到的是连贯的虚构内容。工作发生在两个视角之间的缝隙中，而目标——唯一的目标——就是让这个缝隙变得不可见。
一个碍事的隐私过滤器会被关闭。一个能融入工作流的隐私过滤器才是唯一值得发布的。
这就是我们构建系统的标准。