コンテンツハッシュは、変更されていないファイルの再埋め込みをどのように防ぐのですか？

コンテンツハッシュは、各ファイルやチャンクに、ハッシュ対象のコンテンツが変わると変化する決定論的なフィンガープリントを付与することで、不要な再埋め込みを防ぎます。

ホームナレッジインデックスでは、再起動、スケジュールされたクロール、またはウォッチャーイベントの後に、何千ものPDF、メモ、Markdownファイル、マニュアル、エクスポートされたレコードを再スキャンすることがあります。テキストが同一でも、変更日時やパスは変わる可能性があります。ハッシュを使うと、取り込みパイプラインは解析や埋め込み処理にコストをかける前に、より絞り込んだ質問をできます。つまり、このレコードを定義するバイト列または正規化済みテキストは、すでにインデックス化されたバージョンから実際に変わっているのか、という確認です。

ハッシュは可変長のコンテンツを安定したフィンガープリントに変換する

ハッシュ関数は任意の長さの入力を受け取り、固定サイズのダイジェストを生成します。パイプラインは、このダイジェストをインデックス化されたドキュメントやチャンクの横に保存し、ハッシュ化された表現そのものを示すコンパクトな識別情報として利用します。

固定長メッセージダイジェストは入力表現に対して決定論的なフィンガープリントを提供し、取り込みシステムは高コストな後続処理を呼び出す前に、現在のコンテンツと以前に保存された状態を比較できます。

ダイジェストはファイルの意味を表すものではなく、埋め込みでもありません。選択したバイト列またはテキスト表現が等しいかどうかを高速に判定するためのシグナルです。2回のスキャンで異なるOCRテキストが生成された場合、ページ画像が似ていてもテキストハッシュは異なります。ファイルを変更せずに別のフォルダーへコピーした場合、パスのメタデータが変わってもコンテンツハッシュは同じままにできます。

パイプラインはハッシュに何を含めるかを正確に決める必要がある

生のファイルバイト列をハッシュ化すると、テキストや検索に使われる内容を変えないメタデータ、圧縮方式、コンテナの違いなど、あらゆるバイナリ変更を検出できます。正規化済みの抽出テキストをハッシュ化すれば、それらの変更の一部を無視し、埋め込み入力により近い部分に焦点を当てられます。

コンテンツ由来のアドレッシングは、保存されたコンテンツの識別情報をファイル名やパスから独立させられる理由を示しています。これは、変更されていないファイルを移動または名前変更する場合に便利です。

RAGパイプラインでは、ソースオブジェクト用、正規化済み抽出テキスト用、最終チャンクごとのハッシュなど、複数の層でハッシュを利用できます。

適切な層は、どの処理を省略したいかによって異なります。ソースバイト列が一致すれば解析全体を省略でき、テキストが一致すれば再チャンク化を省略でき、チャンクテキストが一致すれば、隣接するチャンクが変わっても既存のベクトルを維持できます。

保存されたハッシュにより、再取り込みは計算前の比較処理になる

新たに取り込みを実行すると、パイプラインは現在のダイジェストを計算し、同じソースまたはチャンクの識別情報に対応する、以前保存された値を検索します。

増分埋め込み更新を利用すると、フィンガープリントまたはそこから導出されたテキストが実際に異なるコンテンツだけを対象にベクトルを再生成し、変更されていないチャンクを維持できます。

ハッシュが一致すれば、既存の埋め込み、ベクトルID、検索メタデータをそのまま保持できます。一方で、パス、権限、スキャン日時など、変更された非埋め込みメタデータは更新できます。ハッシュが異なる場合、システムは影響を受けるソースまたはチャンクを変更対象としてマークし、そのデータだけを高コストな後続処理に送ります。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

チャンクレベルのハッシュ化により、小さな編集でドキュメント全体を再計算せずに済む

ファイル全体のハッシュは何かが変わったかどうかを示しますが、どの箇所が変わったかは特定できません。200ページのマニュアルで1行を修正しただけでも、ファイル全体のダイジェストは変わります。

コンテンツアドレス指定オブジェクトは、より小さなコンテンツ単位にも独自の識別情報を持たせられることを示しています。これにより、上位のドキュメントが変更されてもチャンク単位で再利用できます。

解析とチャンク化の後、各チャンクに独自のハッシュを付与できます。変更されていないチャンクのハッシュは既存の埋め込みを維持し、新規、変更、統合、削除されたチャンクには、適切な作成、更新、削除の処理を適用します。

編集がまばらで、チャンク境界が安定している場合、この方法は特に大きな効果を発揮します。1か所の挿入後にチャンク化処理がすべての境界をずらすと、文の大半が変わっていなくても、多くの後続チャンクのハッシュが変わる可能性があります。

ハッシュの一致は、検索に関係するすべてのプロパティが変わっていないことを意味しない

テキストハッシュが一致していても、アクセス権限、ドキュメントの信頼性、バージョン状態、ページ対応、ユーザーに表示されるファイル名が変わることがあります。これらのフィールドは、埋め込み入力が同じでも検索結果に影響する可能性があります。

古い派生パッセージを防ぐには、ソースの状態をすべての派生チャンクと照合する必要があります。新しいベクトルが正しくても、同じドキュメント系列に属する古いレコードが自動的に無効になるわけではないためです。

そのため、取り込みスキーマでは、埋め込みに影響するコンテンツと検索メタデータを分離する必要があります。権限の変更ではフィルターの更新が必要になる場合がありますが、ベクトルの再生成までは必要ないことがあります。

同様に、埋め込みモデル、正規化ポリシー、パーサー、チャンク化アルゴリズムを変更すると、すべてのソースファイルのハッシュが変わっていなくても、古い派生アーティファクトは無効になります。

ハッシュ化で計算量を削減できるのは、識別情報とライフサイクルのルールが信頼できる場合だけ

ダイジェストが役立つのは、比較対象となる以前のレコードをシステムが正しく把握できる場合だけです。名前変更、重複コピー、ハードリンク、アーカイブからの復元、生成された一時ファイルは、パスベースの識別情報を混乱させる可能性があります。

ストリーミングハッシュ計算を使うと、比較前にソースオブジェクト全体をRAMへ読み込むことなく、大容量のローカルファイルをホームサーバー上で段階的にフィンガープリント化できます。

安定したソースIDを使用し、ハッシュのバージョンと正規化ポリシーを保存し、定期的にインデックスとソースライブラリを照合してください。これにより、ウォッチャーやデータベースのイベントを取りこぼした後も、スキップされたファイルが古いレコードとして恒久的に残ることを防げます。したがって、コンテンツハッシュは埋め込み処理の前段に置くゲートであり、完全な同期システムではありません。等価性が確認できた場合は再計算を防ぎますが、変更または削除されたレコードの検出と廃棄には、別のライフサイクル管理の仕組みも必要です。