動機

私は個人を特定できる情報（PII）を含むデータセットを使用しており、データセットの一部を第三者と共有する必要がある場合があります。ここでの通常のアプローチは、データを完全に保留するか、場合によってはその解像度を下げることです。たとえば、正確な住所を対応する郡または国勢調査区に置き換える。

これは、サードパーティがタスクにより適したリソースと専門知識を持っている場合でも、特定のタイプの分析と処理を社内で行う必要があることを意味します。ソースデータは公開されていないため、この分析と処理の進め方には透明性がありません。その結果、QA / QCを実行したり、パラメータを調整したり、改良したりするサードパーティの能力は非常に制限される場合があります。

機密データの匿名化

1つのタスクには、エラーと矛盾を考慮しながら、ユーザーが送信したデータで名前で個人を識別することが含まれます。個人は、ある場所では「デイブ」、別の場所では「デビッド」として記録される場合があります。営利団体はさまざまな略語を使用でき、常にいくつかのタイプミスがあります。名前が異なる2つのレコードが同じ個人を表す場合を判断し、それらに共通のIDを割り当てるいくつかの基準に基づいてスクリプトを開発しました。

この時点で、名前を控えてこの個人ID番号で置き換えることにより、データセットを匿名にすることができます。しかし、これは受信者がマッチの強さなどについてほとんど情報を持っていないことを意味します。身元を明かすことなく、できるだけ多くの情報を渡すことができるようにしたいと思います。

機能しないもの

たとえば、編集距離を維持しながら文字列を暗号化できると便利です。このように、サードパーティは独自のQA / QCの一部を実行したり、PIIにアクセスしたり（リバースエンジニアリングを実行したりすることなく）独自の追加処理を選択したりできます。おそらく、編集距離<= 2で社内の文字列を照合し、受信者は編集距離<= 1でその許容範囲を狭めることの意味を調べたいと考えています。

しかし、私がこれに慣れている唯一の方法はROT13（より一般的には、任意のシフト暗号）であり、暗号化とは見なされません。それは、名前を逆さまに書いて、「あなたは紙をひっくり返さないと約束しますか？」

別の悪い解決策は、すべてを短縮することです。「Ellen Roberts」は「ER」などになります。これは、公開データに関連するイニシャルが個人の身元を明らかにする場合と、あいまいすぎる場合があるため、不十分なソリューションです。「ベンジャミン・オセロ・エイムズ」と「バンク・オブ・アメリカ」の頭文字は同じになりますが、それ以外の名前は異なります。だから、私たちが望むもののどちらもしません。

洗練されていない代替方法は、名前の特定の属性を追跡するために追加フィールドを導入することです。例えば：

+-----+----+-------------------+-----------+--------+
| 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の間の距離（つまり、一致にどれだけ近いか）について合理的に結論付けることはできません。

結論

目標は、元の文字列をわかりにくくする一方で、元の文字列の有用な品質をできるだけ多く維持するような方法で文字列を変換することです。復号化は、データセットのサイズに関係なく、不可能であるか、事実上不可能であるほど非実用的である必要があります。特に、任意の文字列間の編集距離を保持する方法は非常に便利です。

関連する可能性のある論文をいくつか見つけましたが、それらは私の頭上にあります。

• レーベンシュタイン距離に基づくプライバシー保護文字列比較
• プライベートレコードリンケージにおける近似文字列マッチングへのアプローチの経験的比較

OPで言及した参考文献の1つは、「ブルームフィルターを使用したプライバシー保護レコードリンケージ」（doi：10.1186 / 1472-6947-9-41）で説明されている、非常に強力な潜在的なソリューションに導きました。

暗号化された識別子とプライバシーを保護するレコードリンケージ用の新しいプロトコルが開発され、識別子のエラーが許可されました。このプロトコルは、qグラムの識別子のブルームフィルターに基づいています。

この記事では、この方法について詳しく説明します。ここでは、できる限りの方法で要約します。

ブルームフィルターは、それぞれが同じ入力値で計算された、独立したハッシュ関数の固定セットの結果を格納する固定長の一連のビットです。各ハッシュ関数の出力は、フィルター内の可能なインデックスの中からのインデックス値である必要があります。つまり、10ビットの0インデックス付きシリーズがある場合、ハッシュ関数は0〜9の値を返す（またはマップされる）必要があります。

フィルターは、各ビットを0に設定して開始します。ハッシュ関数のセットの各関数で入力値をハッシュした後、任意のハッシュ関数によって返されるインデックス値に対応する各ビットは1に設定されます。 1つのハッシュ関数よりも、そのインデックスのビットは1回だけ設定されます。ブルームフィルターは、一連のハッシュを固定範囲のビットに重ね合わせたものと考えることができます。

上記のリンクの記事で説明されているプロトコルは、文字列をnグラムに分割します。この場合、文字のセットです。例として、"hello"次の2グラムのセットが生成される場合があります。

["_h", "he", "el", "ll", "lo", "o_"]

n-gramを作成するとき、前後にスペースを入れることは一般的にオプションのようです。この方法を提案する論文に記載されている例では、このようなパディングを使用しています。

各n-gramをハッシュしてブルームフィルターを作成し、このブルームフィルターのセットをそれ自体に重ねて（ビット単位のOR演算）、文字列のブルームフィルターを作成できます。

フィルターにハッシュ関数やn-gramよりも多くのビットが含まれている場合、任意の文字列がまったく同じフィルターを生成する可能性は比較的低くなります。ただし、2つの文字列に共通するn-gramが多いほど、フィルターが最終的に共有するビットも多くなります。次にA, B、ダイス係数を使用して2つのフィルターを比較できます。

D _A、B = 2h /（a + b）

ここで、h両方のフィルタ1に設定されるビットの数であり、a1に設定されたビットの数であるのみフィルタA、およびb1に設定されたビットの数であるだけの文字列が全く同じであればフィルタB.、ダイス係数は1になります。それらが異なるほど、係数はに近くなります0。

ハッシュ関数は不確定な数の一意の入力を少数の可能なビットインデックスにマッピングしているため、異なる入力は同じフィルターを生成する可能性があり、係数は文字列が同じまたは類似している確率のみを示します。さまざまなハッシュ関数の数とフィルターのビット数は、偽陽性の可能性を判断するための重要なパラメーターです。この方法で予測されるダイス係数よりもはるかに類似していない入力のペアです。

私が見つかりました。このチュートリアルでは、ブルームフィルタを理解するために非常に有用であることを。

このメソッドの実装にはある程度の柔軟性があります。また、他のメソッドとの関連性やさまざまなパラメーターに関するパフォーマンスの指標については、この2010年の論文（質問の最後にリンクされています）も参照してください。

あなたの質問を読む途中で、私はレーベンシュタイン距離があなたの問題に対する素晴らしい解決策であることに気付きました。トピックに関する論文へのリンクがあることを確認できたら、レーベンシュタインのソリューションがどのようになるかを明らかにすることができますか。

レーベンシュタイン距離は、エンティティの解決に多くの業界で使用されています。これが役立つのは、2つのシーケンス間の差の測定値だからです。文字列比較の場合は、単なる文字のシーケンスです。

これにより、別のフィールドのテキストがどれだけ似ているかを示す1つの数値を提供できるため、問題の解決に役立ちます。

以下は、あなたが与えたデータでレーベンシュタインを使用する基本的な方法の例です。

これは大丈夫なソリューションを提供し、8の距離は関係の何らかの指標を提供し、非常にPIIに準拠しています。しかし、それはまだ非常に便利ではありません。名の最初のイニシャルと完全な姓のみを取り、途中で何かを削除するテキストマジックを行うとどうなるか見てみましょう。

ご覧のとおり、0のレーベンシュタイン距離は、関係を示しています。一般的に、データプロバイダーは、データ内の匿名性を維持しながら、エンティティの関連性についてある程度の次元を与えるために、姓と名の一連のレーベンシュタイン順列を1、2、またはすべての文字と組み合わせます。

可能であれば、関連するレコード（Dave、Davidなど）をリンクし、それらをシーケンス番号（1、2、3など）またはすべての関連レコードを表すために使用される文字列のソルト ハッシュ（たとえば、デイブの代わりにデビッド）。

サードパーティは本名を知る必要はないと思います。

編集：サードパーティが実行できる必要がある操作の種類を定義および正当化する必要があります。たとえば、ベンジャミンオセロエイムスからバンクオブアメリカを明確にするために、イニシャルとそれに続く数字（たとえば、BOA-1、BOA-2など）を使用することの何が問題になっていますか？それがあまりにも明らかになっている場合は、文字や名前の一部をビンに入れることができます。たとえば、[AE]-> 1、[FJ]-> 2など。BOAは1OAになります。または["Bank"、 "Barry"、 "Bruce"など]-> 1になり、Bank of Americaは再び10A。

詳細については、k-anonymityを参照してください。

1つのオプション（データセットサイズに依存）は、追加のデータセットとして編集距離（または使用している類似性の他の尺度）を提供することです。

例えば：

1. データセットに一意の名前のセットを生成します
2. 名前ごとに、お互いの名前までの編集距離を計算します
3. 名前ごとにIDまたは不可逆ハッシュを生成する
4. 元のデータセットの名前をこのIDに置き換えます
5. ID番号間の編集距離のマトリックスを新しいデータセットとして提供する

これらのデータを匿名化するためにできることはまだたくさんありますが。

たとえば、「Tim」が少年の最も人気のある名前であることがわかっている場合、人口全体の既知のTimの割合に厳密に一致するIDの頻度カウントはそれを与える可能性があります。そこから、編集距離が1の名前を探し、それらのIDが「Tom」または「Jim」を参照していると結論付けることができます（他の情報と組み合わせた場合）。

よくわかりませんが、ローカリティに敏感なハッシュが良い解決策かもしれません。入力データ（場合によっては名前）のハッシュ化を行うため、元の文字列は保持されます。一方、LSHの主な考え方は、同様のアイテムのハッシュ尤度を最大化することです。多くの異なるLSH実装があります。ツイートのテキストを比較するためにNilsimsa-hashを試してみましたが、非常にうまく機能しました。しかし、私は、短い文字列（名前）の場合にどれだけうまく機能するのかわかりません-この問題はテストが必要です。私はあなたの例を試しました、そして結果はここにあります（名前A、名前B、「距離」-最大は120です）：

1. AMELIA BEDELIA  - CHRISTOPH BAUER - 107
2. AMELIA BEDELIA  - C J BAUER       - 82
3. AMELIA BEDELIA  - FRANZ HELLER    - 91
4. CHRISTOPH BAUER - C J BAUER       - 81
5. CHRISTOPH BAUER - FRANZ HELLER    - 98
6. C J BAUER       - FRANZ HELLER    - 83

ご覧のとおり、CHRISTOPH BAUERとCJ BAUERが最も近いペアになりました。しかし、違いは重要ではありません。そしてちょうど例-これらの名前のハッシュ表現：

AMELIA BEDELIA  6b208299602b5000c3005a048122a43a828020889042240005011c1880864502
CHRISTOPH BAUER 22226448000ab10102e2860b52062487ff0000928e0822ee106028016cc01237
C J BAUER       2282204100961060048050004400240006032400148000802000a80130402002
FRANZ HELLER    58002002400880080b49172044020008030002442631e004009195020ad01158

私が言及しなかったアプローチは次のとおりです：プロセスを2つのステップに分けます：同じ名前の代替バージョンが同じ（またはほぼ同じ）にエンコードされるように名前のエンコードに焦点を当てた最初のステップと、作成に焦点を当てた2番目のステップそれらは匿名です。

最初のステップでは、さまざまな順序で名、姓、イニシャルに適用される音声アルゴリズム（Soundexとバリアント）のいずれかを使用できます。（この記事も参照してください）。このステップで、名前の類似点と相違点を解決して、偽陽性と偽陰性のバランスを取ります。

2番目のステップでは、その方法が名前の一致に与える影響を心配することなく、好きなハッシュまたは暗号化方法を選択できます。これにより、パフォーマンス、堅牢性、匿名性の両方に最適な特性を持つメソッドを自由に使用できます。