誤検知のない確率的セット？

したがって、ブルームフィルターは非常にクールです。これらは、偽陰性のないメンバーシップチェックをサポートするセットですが、偽陽性の可能性はわずかです。しかし最近、私は反対を保証する「ブルームフィルター」を望んでいます：偽陽性はなく、潜在的に偽陰性。

私の動機は単純です：処理するアイテムの（大量の）ストリームが大量にある場合、前に見たアイテムの処理を避けたいと思います。複製を処理するのに害はなく、時間の無駄です。しかし、要素の処理を怠ると、壊滅的なものになります。「逆ブルームフィルター」を使用すると、スペースのオーバーヘッドがほとんどないアイテムを保存し、セット内のメンバーシップをテストすることで、重複の処理を高い確率で回避できます。

しかし、私はそのようなものを見つけることができないようです。私が見つけた最も近いものは「レタッチされたブルームフィルター」です。これにより、選択された誤検知をより高い誤検知率と交換することができます。ただし、すべての誤検知を削除したい場合、それらのデータ構造がどれだけうまく機能するかはわかりません。

誰でもこのようなものを見ましたか？:)

1つの答えは、大きなハッシュテーブルを使用し、それがいっぱいになったら、他の場所に（存在しない）空のスロットを見つけるのではなく、その中の要素を置き換え始めることです。ブルームフィルターで行うような固定された誤答率は得られませんが、何もしないよりはましです。これは、すでに検索された位置を追跡するためのチェスソフトウェアなどの標準的なものだと思います。

この質問に対する答えは「いいえ」です。理由を確認するために、非常に極端な場合と、通常のブルームフィルターが「グロザーフィルター」と呼ばれる理論的な「Bizzaro World」ブルームフィルターとどのように機能するかを考えることができます。

ブルームフィルターの優れている点は、エラーの確率と保存されているアイテムの数に関して固定サイズのデータ​​構造を使用して、アイテムのメンバーシップ（誤検知）の片側テストを実行できることです。アイテム自体のサイズはまったく関係ありません。たとえば、最大1,000個のアイテムを3％未満のエラーで格納するようにブルームフィルターを設定した場合、Wikipediaのコーパス全体の1,000種類のわずかに異なるバージョンを格納し、それぞれに1文字ずつ変更して、必要なメトリックを取得すると、データ構造は非常に小さくなります（1キロバイト未満）。もちろん、これらのハッシュを計算することは困難ですが、その原則は依然として有効です。

次に、これらの同じ大きな文字列を暗闇のフィルターに保存することを検討してください！今は偽陰性しか持てません。したがって、「はい、ウィキペディアのコーパス全体のこのバージョンがこのセットに含まれています」と言う場合、それについて絶対に正しい必要があります。同じ値にハッシュする他の文字列が常に存在するため、ハッシュは役に立たないことを意味します。「はい」と言って確認する唯一の方法は、文字列全体、または同じ長さの同等のデータを保存することです。常に保存して「いいえ」と言うことはできませんでしたが、最終的にはエラー率が追いつきます。できることは圧縮であり、構造のサイズを、格納されているデータのエントロピーと必要な精度の積にまで下げます。

そのため、残念なことに、暗闇フィルターは存在しません。キャッシングが唯一の解決策ですが、保存される情報の量とフィルターの望ましい精度の積に比例するため、実際にはブルームフィルターの反対ではありません。もちろん、多くの実際のシナリオでは、大きなデータをIDで表すことができるため、キャッシングは依然として受け入れられます。ただし、強力なブルームフィルターとは根本的に異なります。

キャッシュが欲しいだけなのに、奇妙な方法で考えています。

免責事項：私はキャッシュの専門家ではないので、これはナイーブなアイデアかもしれませんし、これまで聞いたことのない既知のアイデアかもしれません。その参照を引用できない場合は、すみません（存在する場合）。投稿を編集して追加するための参照がある場合はお知らせください。（私はそれが非常に直感的であるため、参照があるかもしれないと疑っています）。

Strilancに触発された後の簡単な解決策は、最大エントリ（は一定の定数）の関連付けマップを保持して、アイテムを表示回数と関連付けることです。関連付けマップがいっぱいで、マップにない新しいアイテムに出会った場合、コインを裏返して追加するかどうかを決めます。追加する場合は、それまでに表示された回数に反比例する確率でアイテムを削除します。$c$$c$

私は、部分陰性のAVL（および場合によっては赤黒）ツリーを使用して、偽陰性のないフィルターとして機能しました。ツリーを挿入または照会するときは、アイテムの最初のXバイトのみを使用します。データ構造の形式は確率的ではないため、ビット衝突による誤検知のリスクはありません。また、アイテム全体をキャッシュするのとは異なり、このアプローチは計算可能な最大スペースを提供します。誤検出とスペースのコストと比較して、異なるプレフィックス長/ツリー深度を考慮することにより、誤検出の割合を調整できます。

上記のデータ構造が存在できないことを示す下限を証明できると思います。基本的に、データ構造がmビットを使用する場合、固定ビットベクトル（入力の表現）は、カウント引数によって最大（（（un）+ n eps）\ choose（un））セットに対応できます。この数が少なくとも2 ^ m倍（u \ choose n）でなければならない（すべてのセットを表現する必要がある）ため、基本的にセットSを正確に格納することに非常に近い下限が得られます。