リクエストの処理と分類。 パート2：ナビゲーションリクエスト

インターネット検索エンジンを開くときに最も必要なものは何ですか？ 逆説的に見えるかもしれませんが、できるだけ早くそれを残したいと思います。 願望を定式化し、ボタンを押して、すぐにそれが満たされるべき場所に行きます（願っています）。







欲求を表現する主な方法は2つしかありません。 何を取得（または実行）する必要があるかを記述するか 、「テレポート」したい場所を示すかです。 最初のケースでは、システムは最適なネットワーク回答を適切に選択することにより、要求を理解しようとし、決定ツリーでそれらの数百のプロパティを比較します。 2番目のルールでは、正しい答えは原則として1つだけであり、検索エンジンがそれを知っていることを期待しています。



2番目のタイプのクエリ、 どこで 、 どこで質問に答える-ナビゲーションクエリ。 私たちが彼らとどのように働くかについての短い話をあなたの注意にもたらします。



一般的に言って、 何と どこの境界はかなりあいまいです。 「サイクリストフォーラム」と「自転車フォーラムru」という2つの検索クエリを検討してください。 現在、これらの両方の要求に最も関連する回答は、同じサイトvelo-forum.ruです。 違いは、最初のケースでは答えが唯一のものではなく、彼と彼の仲間の間で競争があることです.2番目のサイトでは、サイトは結果のリストに載っているだけでなく、それがどれほど悪いか良いかに関係なく、それを導く必要があります。他の自転車フォーラムと比較して。 2番目の要求はナビゲーションであり、最初の要求はナビゲーションではありません。



「オノマトペwiki」など、混合型のクエリもあります。 今のところそれらを脇に置きますが、それらに戻ります。



そのため、ナビゲーション要求への回答を事前に知る必要があります。 技術的には、このタスクは次のように定式化されます。各ナビゲーションリクエストに対応するインターネットアドレス（以下、ターゲットと呼びます）を関連付けるために ：サイト、サイトのセクション、サイトのページ。 その前に、リクエストがナビゲーションであるかどうかを判断します。



なぜこれが必要なのですか？



まず、さまざまな調査により、ナビゲーションは主観的に最も単純なタイプの検索として認識されていることが示されています（これは驚くことではありません。何かを理解するよりも何かについて知る方が簡単です）。 このため、ユーザーは検索エンジンナビゲーションの回答の品質を評価することに特にこだわりがあり、検索エンジン全体の健全性を決定する際にユーザーに最も強い影響を与えるのはユーザーです。



同時に、多くのナビゲーションクエリがあります。 あまりにも多くの人が放置するのは非常に軽薄です。 結局、データを処理する上で最も重要なことは、会計と管理です。 それが統計と監視です。 この場合、クエリプロパティの統計と応答の品質の監視。



すべての検索クエリを数量の降順に並べ替えて、結果のリストを「将来」見ると、次のようなものが表示されます。







ナビゲーションクエリによってトップ全体が正確にキャプチャされ、人類の最も重要な情報ニーズで弱められていることがわかります（赤でマークされています）。 したがって、延期することはもうありません、



行こう！



リストを単純に歩いて、赤い斑点を投げ、残りの各リクエストにターゲットを手動で割り当てることから始めました。 VKontakteとクラスメートのみがリクエストの合計フローの5％をカバーし、120件のトップナビゲーションリクエストのリストのカバレッジはほぼ15％でした。 そのようなわずかな知的支出で悪くない。



さらに、ナビゲーションの「密度」は急速に低下するため、必要なクエリを自動的にフィルタリングする方法を探す必要がありました。 つまり、大まかに言えば、「VKontakte」と「porn」の違いを見つけることです。



ホールヘルプ



ユーザーが無関係な回答をクリックすることはほとんどありません。 したがって、ナビゲーション要求の場合、すべてが正しい答えのみを選択することを期待するのは理にかなっています。 作業仮説は、逆も真であるというものでした-リクエストを送信するほとんどのユーザーが同じ結果をクリックすると、リクエストはナビゲーションであり、結果はそのターゲットになります。



このテストでは、仮説全体が真実であることが示されました。非常に関連性の高い回答（「nokiaテーマ」や「icqのダウンロード」など）を含むまれな非ナビゲーションクエリのみが同様の行動パターンを引き起こします。 ただし、ほとんどすべての誤検知では、擬似ターゲットがサイト内のページであることが判明したため、このような要求を（一時的に）考慮から除外しました。



ユーザーの全会一致を測定するためのいくつかの方法（従来のクリック画面を含む）を検討し、次のシンプルで便利な指標を決定しました。



C _iを結果R _iのクリック数とし、 demandC _iをオンデマンドの合計クリック数とします。

N = log C _i / log ∑ C _iは、リクエストのナビゲーションの程度です。



手動評価では、メトリック値が0.95を超えるクエリは高精度のナビゲーションであることが示されました。 さらに、この精度は、頻度クエリとまれなクエリの両方で等しく高いです。 この方法を使用すると、ナビゲーションの要求/応答のベースは、約80,000のストレージユニットに成長しました。



ただし、ユーザーの行動に基づく分類には重大な欠点があります。

リクエストが認識されている場合、つまりログに存在し、正しい結果が見つかってクリックされた場合にのみ機能します。 結果として、小さなサイトとまれなクエリは、実際に宝くじを演じます。誰もまだ誰かを検索していない、他の人を検索しているが、見つけることができず、ランダムなものだけが成功しています。



新しい要因



最初に、私たちは少なくとも探していた（しかし見つけることができなかった）不運な人々を助けることにしました。



数千のさまざまなナビゲーションクエリを手動で選択し、それらのプロパティの調査を開始しました。 彼らは、それらの最も特徴的な単語とフレーズのリスト、およびそれらの反対の、特徴的でない単語のリストを編集しました。 リクエストを、それらが導くページのタイトル、およびこれらのページへのリンクのテキストと比較しました。 これらのページのナビゲーションハーネスのブロックをソートしました。 音訳されたドメインとドメイン内パス...



これらすべてが、最終的に、ベイジアン分類器の要素となり、決定木のノードの因子となりました。 トレーニングサンプルのバランス調整と学習結果の評価を数回繰り返した後、評価者はベースをさらに10倍増やしました。 現在、約800,000の異なるページを対象としたリクエストがあります。

• 主要な内部サイト（「LJトップ」）
• 適切なサイトをいくつか持っている（「TSC Antares」：貿易および建設会社、ダンスおよびスポーツクラブ）
• ユーザーの地域に応じたターゲット（「Sberbank」、「mvideo」）でのリクエスト

ただし、有用な情報に加えて、マシンモデルはかなりの量の低頻度のゴミ、タイプミス、およびデータベースへの再トレーニングアーティファクトを導入しました。



発生した2番目の問題は、データベースの明らかに目に見える断片化、つまり、存在するクエリと意味的に同等のクエリが予測できないことです。 たとえば、「ヘッドハンターの仕事」はベースに当たり、「ヘッドハンターの仕事」はモデルにふさわしくないように見えました。







私たちの状況では、予測不可能性は良くありません。同じ意味を持つリクエストは同じ方法で処理されるべきです。 ただし、すべてのリクエストのすべてのバリアントをデータベースに含めると、それが宇宙の次元にまで膨らみます。 そして、よくあることですが、2番目の問題の解決策は、最初の問題を調査する過程で発見されました。つまり、上記のノイズと冗長性からベースを取り除く方法です。 これを行うには、ナビゲーションクエリの「デバイス」を詳しく調べる必要がありました。



「デバイス」クエリ



ナビゲーションクエリは、自然言語の文のようにモノリシックではなく、構成で分解することもできます。異なる単語は異なる役割を果たします。 合計で、5つのそのような役割が特定されました（一般に受け入れられている用語がないため、私は自分で作成しなければなりませんでした）。 以下は、すべての「ナビゲーションオファーのメンバー」が存在する複雑なクエリです。







これは実際のナビゲーションクエリであり、予想どおり、唯一の正しい答えがあります。



ナビゲーションの役割について説明しましょう。



カーネル -リクエストが導くサイトを一意に識別するフラグメント。 これは、リクエストの最も重要な部分です。 通常、サイトには10​​を超える異なるコアはありません。 たとえば、サイトlib.ruの場合、「lib ru」、「libra」、「libru」、および「midgeのライブラリ」です。



バックグラウンド -サイトに許可されたフラグメント。 リクエスト内でのそれらの存在自体は、そのナビゲーションの性質を示すものではありませんが、同時に適切なカーネルの存在下でターゲットを変更することはありません。 youtube.comの場合、これらは「ビデオ」、「ビデオ」、 headhunter.ruのような単語です-「空室」、「仕事」など。



パス -ターゲットをルートページからサイトに移動する単語。 たとえば、Yandexコアに適用される「カード」という単語は、要求をmaps.yandex.ruにリダイレクトします。



リージョン - パスの一種。リクエストの地理的位置を示します。 その特徴は、地理依存ナビゲーションの場合、クエリテキスト内の領域の明示的な表示は、ユーザーの場所の実際の変更と同等であることです。 たとえば、Kazanからユーザーから受け取ったIKEAリクエストは、他の地域から送信されたIKEA Kazanリクエストと同じ場所につながるはずです。



ノイズ -ナビゲーションに関して何も意味しない言葉。 これらは、「www」、「http」、「website」などの品詞および単語のサービス部分です。



各サイトについて、これらのクエリフラグメントはすべて、多くの場合、異なる順序および組み合わせで繰り返され、データベースに存在します。 重複を排除するために、「複合」クエリを基本部分に自動的に分割して、一意のフラグメントのみを残し、それらの相互作用のロジックをプログラムで実装する方法を探し始めました。



解決策は驚くほど単純でした-私たちの手に渡ったのはデータベースデータの冗長性でした。



同じターゲットを持つクエリをソートし、次に短いクエリを長いクエリからカットすると、クエリのセット全体が2つのタイプのフラグメントに分割されます：個別のクエリとして存在するものと、クエリの一部としてのみ存在するもの。 たとえば、ソースリストがリクエスト「YouTube」と「YouTube video」で構成されている場合、「YouTube」という単語が最初のリストと2番目の「video」に表示されます。 これらはそれぞれコアとバックグラウンドになります。



サイト内の主要なリクエスト（「Raiffeisen ATM」など）を取得し、同様にルートページ（「Raiffeisen」）に到達するリクエストを「減算」すると、 pathが取得されます 。



途中で、最初のリストのさまざまなフラグメントの数をカウントし、データベースに最も頻繁なフラグメントのみを残しました。したがって、多くのクエリがそれらにつながる大規模なサイトでは、小さなもののために何も失わずにすべてのゴミを捨てることができました。



カオスから秩序へ



その結果、分類が再び複雑になりました。まず、1つのリストの代わりに5つのリストが表示され、次に要求でそれらを照合する非自明なロジックを実装する必要がありました。



しかし、1石で3羽の鳥を一度に殺すことができました。ベースのサイズを小さくし、低周波ノイズを除去しながら、分類の完全性を高めました。 およそ次のようになりました（ほこり-単語backgroundの非常に無料の翻訳）：







クエリ分割手順の複雑さは2次ですが、まだ最適化されていません。単純な真珠のスクリプトは、1時間以内にデータベースの分解に対処できます。



オンラインロジック



したがって、データベースは構造化されており、5つのリストはすべて辞書のマーカーになっています。 さて、リクエストを受け取った瞬間に、そのナビゲーション性について最終決定を下す必要があります。 これを行うには、パーサーで、リクエストに対して次の条件が満たされているかどうかを判断します。

• ナビゲーショントークンは、最初の単語から最後の単語までのクエリ全体をカバーします
• ナビゲーションコアがあります
• マーカーと少なくとも1つの共通ターゲットの組み合わせがあります

個別に処理されたパス 、明示的に指定されたURL、リクエスト内のリージョン 、ユーザーの実際のリージョン。 その結果、判定が発行されます。要求がナビゲーションであるかどうか、およびユーザーがどこに行きたいかです。



以下は、「ウサギはいません」というクエリの操作性を確認するプロセスの概略図です。





しかし、「1石で3羽の鳥を殺す」という神秘的なリクエストはクライアントではありません。リクエストの一部はナビゲーションとして定義されていますが、なじみのない（またはナビゲーション非互換の）単語もあります。



ローカル検索



これらのリクエストの一部（実際には非常に多く）では、ナビゲーション以外の部分を独立したリクエストとして提示できます：「1石の3羽の鳥の心臓のサウンドトラックはありません」、「librusekに関係する」、「YouTube vivaldi heavy」、「shakira v kontakte」。 これらは、冒頭で既に述べた混合型のクエリです。



厳密に言えば、それらはナビゲーションではありませんが、私たちがそれらを追い抜いたので、それらは言うまでもなく罪です。



サイトの静的セクションとページ（「書籍ファイル」、「ビーライン関税」）を対象とするオンサイトナビゲーションとは異なり、そのようなリクエストには、指定されたサイトの動的コンテンツから受信した応答が必要です：ソーシャルネットワークの個人ページ、ニュースリソース、百科事典の記事、フォーラムなどのトピック



このようなクエリでは、ナビゲーション部分を特定し、他のすべてをユーザーがそこで見つけたいものと見なします。



このようなクエリでは、検索パラメーターの次の変更が可能です。

• 指定されたサイトでのみ検索
• 独自のサイト検索を使用します（つまり、結果にこのようなリンクを表示します）
• 特別なことは何もしない

結果は何ですか？



その結果、主な質問に対する答えが得られました。受信するナビゲーションクエリの数とそれらにどれだけ答えるか。 次の図に簡単な要約を示します。







したがって、リクエストのストリーム全体の4分の1から3分の1（ローカル検索を考慮するかどうかによって異なります）はナビゲーションです。 ナビゲーションクエリ自体のうち、3番目はサイトの内部ページにつながり、10分の1がユーザーの地域に依存し、最も人気のある2つのロシアのソーシャルネットワークが四半期全体を占めています。 考える機会。



さらに、分類結果は、現在非常に強力な要因として「大」検索の結果のランク付けに使用されます。



そして最後に、視覚的な結果：ナビゲーション検索の結果に対して、拡張スニペットを作成し、時には目的のサイトからいくつかの結果を表示し、ファビコン、ウェブサイトリンク、その他の特殊効果を表示します。







次は？



結論として、私たちがまだカバーしていないセクター、つまりユーザーがまだ検索していないセクターを思い出しましょう。 これらは、小さな地域組織、高度に専門化されたサイト、ソーシャルネットワークのローカルコミュニティ、パーソナルページ、そしてもちろん、登場したばかりのサイトとそのセクションです。 それらを小さくしますが、それらの多くがあり、いつか誰かがそれらを見つけたいという事実に備えたいと思います。



まだリクエストはなく、それに応じて分類するものもありません。 ただし、ページのテキストを調べたら、ユーザーをこのページに導くクエリを作成できます。 これを行うには、ページテキストの一意のフラグメントを見つけて、ナビゲーションリクエストとして使用できるフラグメントを選択する必要があります。



おそらく、このあいまいなタスクは、ドラゴンのいる深byに満ちているでしょう。 ほとんどの場合、他の落とし穴との解決および衝突に対する他のアプローチが必要になります。 しかし、それが面白い理由です。



私はこれを回っています、あなたの注意に感謝します、そして、私はそれがあなたにとって面白かったと思います！ 次の部分は、スペルチェッカーに関する話です。



ミハイル・ドリニン、

検索クエリチームリーダー