サポートに、ごく普通の質問が届きます。

「マイページとは何ですか?」

ナレッジベースには 4,862 ページあります。答えはあります。しかも一つではありません。

最初のページには、このサイトの領域が何なのか、どうログインするのか、そこで何ができるのかが説明されています。二つ目は古いサービス変更の一覧です。三つ目は長いページで、「マイページ」という言葉が二十七回出てきます。四つ目はパスワード再設定の説明で、そこでは「ユーザープロフィール」と呼ばれています。

検索は三つ目を選びます。

壊れているわけではありません。単に、より多くの一致を正直に見つけたのです。

だからこそ危険です。

三つ目のページを開いた人は、時間をかけて読んでも同じ質問を持ったまま戻ってきます。最初のページの適切な節にたどり着いた人は、その領域が何のためにあるのかをすぐ理解します。この問いでは最初のページが主な結果になるべきです。違いは文章の質や利用者の検索能力ではありません。システムが文書をどう理解しているかです。

人にとって、文書は単なる単語の集まりではありません。「マイページ:ログインとできること」という見出しには意味があります。変更履歴の中にある同じ言葉は別の意味を持ちます。機能の表、ページのアドレス、本文は、それぞれ異なる情報を伝えます。検索はその違いに気づかなければなりません。そうでなければ、手順とその影を同じ確信度で返してしまいます。

BM25F は、この問題への一つの答えです。

文書が平らなテキストではなくなったとき

古典的な検索モデルは長い間、便利な単純化を使ってきました。文書を単語の並びとして扱うことです。まれな単語は一般的な単語より役に立ちやすく、一致が複数あれば一つよりよい、とシステムは考えます。この考え方から、単語の希少性を評価する TF-IDF が生まれ、次に見つかったページを並べるための式である BM25 が生まれました。

BM25 には二つの重要な制限があります。単語の繰り返しが、ページが役に立つという確信を無限に強めてはいけません。「マイページ」の最初の言及は重要で、二つ目は話題を確認します。しかし二十七回目がページを二十七倍役立つものにするわけではありません。また、長い文書が偶然の一致の余地が大きいだけで勝つべきでもありません。

このため BM25 は全文検索のよい土台になりました。しかし文書の構造が豊かになると限界が現れます。BM25 は単語を扱えますが、その単語が文書のどこにあるかは、それだけでは知りません。

一つの言葉、四つの異なる信号

ページタイトルの「マイページ」は、そのページの主題を示します。

節の見出しにある「マイページ」は、特定の断片の主題を示します。

機能表の「マイページ」は、利用できる選択肢の一つかもしれません。

本文の「マイページ」は、手順、文脈、たまたまの言及かもしれません。

これは見た目の違いではありません。検索にとっては意味の違いです。

明らかな解決策にある落とし穴

文書に構造化された部分ができると、最初の解決策はほぼ必然的です。ページタイトル、本文、ページアドレスの一致を別々に数え、その評価を足す。タイトルには十、本文には一の重みを与える。文書サイトなら、節の見出し、目次の位置、重要な対象の名前も加えます。

もっともらしく聞こえます。しかし計算する順序には意味があります。

BM25 は、繰り返しが増えるほど次の一回が加える確信を小さくするよう作られています。文書の各部分を先に評価してから完成した評価を足すと、この仕組みは変わります。各部分が別々に上限へ達し、システムはそれらを独立した証拠として足すことになります。

問題は重みそのものではありません。重みが検索のどの段階で現れるかです。

2004 年、Stephen Robertson、Hugo Zaragoza、Michael Taylor は Simple BM25 Extension to Multiple Weighted Fields で、より慎重な方法を説明しました。これが、複数の部分を持つ文書のための BM25 の拡張、BM25F です。詳しくは出典 1

BM25F が変えること

BM25F は、まず文書の異なる部分から一致を集め、重みと長さを考慮します。その後、BM25 の非線形な飽和を、その合わさった信号に適用します。

検索語の各単語について:
  合成信号 =
    ページタイトル × その重み
    + 節の見出し × その重み
    + 対象の名前 × その重み
    + 本文 × その重み

  その後、合成信号に BM25 の飽和を適用する。

完全な式では、文書の各部分に独自の長さ補正があります。ページタイトルは数語ですが、本文は数千語になることがあります。同じ長さ補正を使うのは、見出しの一致とフッターの一致を同じように評価するのと同じ誤りです。

思考実験

文書 A では、「マイページ」がページタイトルと「マイページでは何ができるか」という節の見出しにあります。文書 B では、同じ言葉がよくある質問の節に八回出てきます。

BM25F が常に A を選ぶ必要はありません。しかし、二つの強い構造上の信号が、長い本文での八回の繰り返しより重要になり得る理由を、説明可能な形で判断できます。

この例では、最初のページが問い全体に答えているため、主な結果になるべきです。長い変更一覧は結果から消えませんが、人が必要とする説明を隠さなくなります。

このように、検索は文書の種類ごとに調整できます。カタログではブランド、分類、商品の属性が特に重要です。研究資料では論文名、要約、キーワードです。サイトのヘルプではページタイトル、節の見出し、本文です。

この考え方が使われている場所

BM25F は大学の式だけにとどまりませんでした。Apache Lucene には、文書の複数部分を一つの全体として扱い、相対的な重要度を設定できる仕組みがあります。出典 2

SharePoint はフィールドごとの BM25 を BM25F と明示的に呼び、管理プロパティの重みと長さ補正を設定できます。出典 3

Manticore Search は、文書部分の重みを考慮して結果を並べる方法として BM25F を提供しています。出典 4

ただし、これらを同じものとして扱うべきではありません。文書の複数部分を検索することや、ページタイトルを人工的に優先することが、必ずしも古典的な BM25F を意味するわけではありません。システムは各部分を独立に評価したり、見つかった一致を強めたり、別の方法でテキストを統合したりできます。どれも有用ですが、振る舞いは異なります。

完全一致の境界

最初の質問に戻りましょう。利用者が「マイページ」と入力している間、BM25F は得意な領域で働きます。言葉と、それが文書構造のどこにあるかを見ます。

しかし質問は別の表現にもなります。「請求額を確認して支払うにはどこへ行けばよいですか?」これはマイページを指しているかもしれませんが、その名前を含みません。ここでは、フィールドを考慮するモデルも完全一致には頼れません。

これは BM25F の欠点ではなく、役割の境界です。BM25F が答えるのは「検索語が文書のどの適切な場所にあるか」です。二つの違う表現が同じ状況を説明していると、単独で理解する義務はありません。

検索は一人の勝者を選ぶわけではない

正確な名前、エラーコード、設定名、商品番号 — 完全一致の検索。

言い換えられた質問 — 意味の近い表現を対応づける意味ベースの検索。

関連する文書 — ページと概念の関係をたどる検索。

強い候補が複数ある場合 — 結果の追加比較。

よい検索では、これらの方法は互いを追い出しません。完全一致の検索は、エラーコード、料金プラン名、設定名、法律上の表現、商品番号をしっかり保持します。意味ベースの検索は、利用者が状況は覚えていても正確な名前を覚えていない場合に役立ちます。その後、システムは強い候補を比較し、問い全体に答えるものを選びます。

Dzen ではどこにあるか

Dzen の単語検索も、情報源の構造を考慮します。ページタイトル、ページアドレス、断片の見出し、本文は異なるものとして扱われます。これにより完全一致は偶然の副産物ではなく、独立した信号になります。

しかしこの信号が最後の判断をするわけではありません。意味ベースの検索やページ間の関係をたどる検索と組み合わされ、答えを準備する前に複数の結果が比較されます。見出しの完全一致は失われませんが、それだけで利用者が目にする情報源を決めることもできません。

ここでは、正確な式以上に BM25F の考え方が重要です。検索は、文書にどんな単語があるかだけでなく、その単語がそこでどんな役割を果たすか、つまり知識の形を見るべきだと教えてくれます。

検索はマイページについてのページをどう選ぶか

検索方法を切り替え、ページのタイトルと見出しをどれだけ重視するかを変えてみてください。

    出典

    1. Robertson, Zaragoza, Taylor. Simple BM25 Extension to Multiple Weighted Fields, CIKM 2004.
    2. Apache Lucene. CombinedFieldQuery.
    3. Microsoft Learn. Customizing ranking models to improve relevance in SharePoint.
    4. Manticore Search. Функции поиска и ранжирования.