动机
我使用包含个人身份信息 (PII) 的数据集，有时需要与第三方共享部分数据集，这种方式不会暴露 PII 并使我的雇主承担责任。我们通常的做法是完全保留数据，或者在某些情况下降低其分辨率；例如，用相应的县或人口普查区替换确切的街道地址。
这意味着某些类型的分析和处理必须在内部完成，即使第三方拥有更适合该任务的资源和专业知识。由于没有披露源数据，我们进行这种分析和处理的方式缺乏透明度。因此，任何第三方执行 QA/QC、调整参数或进行改进的能力都可能非常有限。
匿名化机密数据
其中一项任务涉及在用户提交的数据中通过姓名识别个人，同时考虑到错误和不一致。一个私人可能在一个地方被记录为“Dave”，在另一个地方被记录为“David”，商业实体可以有许多不同的缩写，并且总是有一些拼写错误。我已经根据一些标准开发了脚本，这些标准确定两个名称不同的记录何时代表同一个人，并为它们分配一个公共 ID。
此时，我们可以通过保留名称并用这个个人 ID 号替换它们来使数据集匿名。但这意味着接收者几乎没有关于例如匹配强度的信息。我们希望能够在不泄露身份的情况下传递尽可能多的信息。
什么不起作用
例如，能够在保持编辑距离的同时加密字符串会很棒。这样，第三方可以自己做一些 QA/QC，或者选择自己做进一步的处理，而无需访问（或可能进行反向工程）PII。也许我们在内部将字符串与编辑距离 <= 2 进行匹配，而接收者想要查看将公差收紧到编辑距离 <= 1 的含义。
但我熟悉的唯一方法是ROT13（更一般地说，任何移位密码），它甚至几乎不能算作加密；这就像把名字倒过来然后说，“保证你不会把纸翻过来？”
另一个糟糕的解决方案是缩写所有内容。“艾伦·罗伯茨”变成了“ER”等等。这是一个糟糕的解决方案，因为在某些情况下，与公共数据相关联的姓名首字母会揭示一个人的身份，而在其他情况下，它太模棱两可了；“Benjamin Othello Ames”和“Bank of America”将具有相同的首字母，但它们的名称不同。所以它不会做我们想要的任何事情。
一个不优雅的替代方法是引入额外的字段来跟踪名称的某些属性，例如：
+-----+----+-------------------+-----------+--------+
| Row | ID | Name | WordChars | Origin |
+-----+----+-------------------+-----------+--------+
| 1 | 17 | "AMELIA BEDELIA" | (6, 7) | Eng |
+-----+----+-------------------+-----------+--------+
| 2 | 18 | "CHRISTOPH BAUER" | (9, 5) | Ger |
+-----+----+-------------------+-----------+--------+
| 3 | 18 | "C J BAUER" | (1, 1, 5) | Ger |
+-----+----+-------------------+-----------+--------+
| 4 | 19 | "FRANZ HELLER" | (5, 6) | Ger |
+-----+----+-------------------+-----------+--------+
我称之为“不优雅”，因为它需要预测哪些品质可能会很有趣，而且它相对粗糙。如果删除了名称，则您无法合理地得出关于第 2 行和第 3 行之间匹配强度或第 2 行和第 4 行之间距离（即它们与匹配的接近程度）的合理结论。
结论
目标是以这样一种方式转换字符串，即尽可能多地保留原始字符串的有用品质，同时掩盖原始字符串。无论数据集的大小如何，解密都应该是不可能的，或者实际上是不可能的。特别是，保留任意字符串之间的编辑距离的方法将非常有用。
我找到了几篇可能相关的论文，但它们有点超出我的想象：
