「正準値→検索候補」の逆引きは正引きから導出する — 保存が原文のままなら片側手書きが検索漏れを生む
設計判断
検索
データモデリング
知識
判断
運用
保存側が入力の原文(表記ゆれを含む)をそのまま持ち、検索は正準値から候補集合を作って完全一致で照合する構成での判断。
問題の型
表示は「原文 → 正準値」の正引きだけで足りるが、検索には「正準値 → 原文候補」の逆引きが要る。この逆引きを辞書として手で持つと、正引きと非対称になる。特に落ちやすいのは次の2種類。
- 正規化で形が変わる表記(ダッシュ・括弧・空白の全角半角など)。逆引きが正規化後の形を返すと、原文のまま保存された行と完全一致せず 0 件になる
- 正引きが動的に分解する複合値(1セルに複数の値が区切りなしで連結しているようなもの)。分解結果は正準値になるが、連結された原文自体はどの逆引きにも載らない
症状は「詳細画面には正しく表示されるのに、検索とファセット件数からは消えている」という非対称で、表示側だけ見ていると気付けない。
判断
逆引きを手で持たず、既知の原文集合を正引きに通して機械的に導出する。こうすると「正引き(x) がキー K を返すならば x は必ず 逆引き(K) に含まれる」が構造的に成立し、辞書を編集するたびに両方向を手で同期する必要がなくなる。
検証方法
実データから採取した原文集合の全件について、上記の対称性を表明するテストを置く。逆引きが返す値を正引きできることだけを確認するテストは、逆引きに載っていない原文を入力に取らないため反証にならない(構造上ほぼ恒真になる)。反証力があるのは「実データの原文を入力にする」方向のテストだけ。
適用条件と例外
検索基盤側にクエリ時正規化の仕組み(アナライザ相当)があるなら、そちらで吸収する方が素直で、逆引き辞書は不要になる。逆引き方式は「保存を原文のままにしたい」「正規化を後から変更できるようにしたい」という要求があるときの選択で、その対価としてこの対称性の担保が要る。