クエリ拡張はファイルIDや日付の正確な検索をなぜ損なうのか？

クエリ拡張は、狭い検索シグナルをより広い意味的・語彙的な候補に置き換えるため、ファイルIDや日付の正確な検索を損ないます。

ローカルRAGシステムは、検索前に同義語、関連エンティティ、綴りのバリエーション、または仮説的な回答を追加することで、一般的な質問への対応を改善できます。しかし、クエリが正確なファイル名、UUID、請求書番号、バックアップスナップショットの日付、またはカメライベントのタイムスタンプである場合、同じ動作は危険です。1文字の違いで別のレコードが特定されることがあり、広い解釈によって、同じトピックや月について説明している文書が優先され、ユーザーが文字どおり求めている対象が除外される可能性があります。

ファイルIDと日付はトピックではなく検索キー

識別子によるクエリには、通常、意図された対象が1つあります。ユーザーはIMG_20260804_173221と概念的に似た文書を求めているのではなく、その完全な文字列をキーに含むレコードを求めています。

Oracleのハイブリッド検索に関するガイダンスでは、ID、コード、その他の文字どおりの値について、正確な識別子のシグナルを、検索における主要な根拠として扱っています。

こうしたクエリは自然言語の質問とは異なる方法で処理します。元の文字列を保持し、想定されるフィールドを特定したうえで、意味的な拡張を許可する前に、完全一致またはフィールドに応じた正規化後の一致を必須にします。

拡張によって、関連して見えても間違った候補が追加される

2026-08-04のような日付は、「2026年8月」「8月上旬」「その日前後のイベント」などに拡張される可能性があります。ファイルIDの場合は、同じ接頭辞、フォルダー、プロジェクト、またはカメラモデルを持つファイル名が周囲に追加されることがあります。

Redisは、意味検索が意味ベースの質問では良好に機能する場合でも、正確な識別子の検索に苦労することがあると説明しています。

こうした近傍候補が役立つのは、正確な対象が見つからない場合、またはユーザーが関連資料を明示的に求めている場合だけです。デフォルトで追加すると、余分な候補がtop-kの枠を占めたり、誤った回答の根拠になったりするため、適合率が低下します。

トークン化によって文字どおりの同一性が崩れる

ハイフン、アンダースコア、スラッシュ、ピリオド、英字と数字の混在は、分割、正規化、または小文字化されることがあります。その結果、検索エンジンが識別子全体ではなく、断片同士を比較する可能性があります。

Weaviateの識別子を考慮したトークン化に関する解説は、URL、UUID、その他の構造化文字列には、完全一致検索に必要なシグナルを保持するアナライザーが必要な理由を示しています。

分析対象のテキストとは別に、正規化したキーワードフィールドを保存します。完全なキーはキーワードフィールドで検索し、ユーザーが一部しか覚えていない可能性のあるファイル名や説明には、分析対象フィールドを利用します。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

誤字許容によってキーが書き換えられることがある

誤字補正は名前や一般的な単語には有効ですが、2つのファイルIDの1文字の違いには意図があるかもしれません。補正によって、別の対象へ検索が気づかれないまま移る可能性があります。

Meilisearchには、完全一致が重要な場合に範囲を狭めたり無効にしたりできる誤字許容の制御機能があります。

既知の識別子フィールドと機械生成トークンでは、誤字許容を無効にします。ユーザーの入力ミスが疑われる場合は、文字どおりの検索結果を表示し、別枠で代替候補を提案します。クエリを見えないところで置き換えてはいけません。

ハイブリッド統合でも広い一致が優先されることがある

BM25スコアとベクトルスコアを組み合わせても、正確な一致が自動的に保護されるわけではありません。広い意味検索の候補が複数の拡張クエリで高く評価され、正規化や逆順位融合の後に、文字どおりの一致を上回ることがあります。

Supermemoryは、ハイブリッド検索の重み付けによって、正確な識別子と意味的類似性のどちらが最終ランキングを支配するかが決まると説明しています。

正確なフィールド一致には、決定的なブースト、または早期返却の経路を設定します。「7月3日のファイルABC-42に関連するメモ」のような混合クエリでは、まずIDと日付で絞り込み、その限定された集合内で意味ランキングを実行します。

日付は構造化フィルターとして扱う方が適している

文書本文中の日付は、作成日時、更新日時、イベント日時、公開日時、または段落内で言及されているだけの日付を意味する可能性があります。拡張しても、ユーザーがどのフィールドを意図しているかは解決できません。

Qdrantのメタデータフィルタリングのガイドでは、構造化された条件によって、完全一致するペイロード値や範囲を満たすレコードだけにベクトル検索を制限する方法を説明しています。

取り込み時にタイムスタンプを正規化し、タイムゾーンと元の値を保持します。また、作成時刻、更新時刻、撮影時刻、インデックス登録時刻を別々のフィールドとして用意します。「8月4日」という指定は、関連する日付表現へ拡張するのではなく、正しい現地日の範囲に変換します。

拡張する前に正確なクエリを振り分ける

クエリを、正確な検索、範囲を限定した混合検索、概念検索に分類します。認識可能なUUID、チェックサム、ファイル名、ISO日付、シリアル番号、引用符で囲まれた文字列は、まず正確な検索経路に送ります。

文字どおりの検索で結果がない場合は、正規化した句読点、フィールド固有の誤字候補、近接する日付範囲、意味的な近傍候補など、制御された代替手段を提示できます。各代替手段を表示し、検索範囲が広がったことをユーザーが把握できるようにします。

ZimaSpaceのAI NAS検索インデックスが派生レコードを公開する仕組みに関する記事は、もう1つの境界も示しています。検索システムは、インデックス作成時に生成されたチャンク、メタデータ、サムネイル、その他のレコードと、ソースの同一性を区別しなければなりません。

よくある質問

ローカルRAG検索では、すべてのクエリ拡張を無効にすべきですか？

いいえ。概念的な質問、略語、語彙の不一致に対しては、再現率の向上に役立ちます。確度の高い識別子や正確な日付条件がクエリに含まれる場合は、無効にするか、後回しにします。

引用符を付ければ、必ず正確な結果になりますか？

検索バックエンドと対象フィールドが、フレーズ検索またはキーワード検索に対応している場合に限ります。クエリルーターが正確なフィルターを追加しない限り、ベクトル検索が文字どおりの一致条件を無視することもあります。

日付も埋め込み対象にすべきですか？

日付は文脈のために埋め込みテキストへ残して構いません。ただし、日や期間が検索条件の一部である場合は、正規化した日付メタデータをフィルタリングとランキングに使用します。