完全に理解する技術。 Yandexリクエスト拡張

今日は、Yandex検索でユーザーが念頭に置いていたものを正確に見つけられるようにするメカニズムについて説明します。

検索の世界では、このメカニズムは検索クエリ拡張と呼ばれます 。 この用語は、再定式化、同義語、音訳、さらには認知さえも含む非常に広義です（後者は、誤って形態学的サポートと呼ばれることもあります）。

このメカニズムはどの部分で構成されていますか？ 彼が推測するのに何が役立ちますか？ そして、彼が多く助けた彼のまれなミスのそれぞれに何千ものリクエストがあるのはなぜですか？


なぜリクエストを受け取って拡張できないのですか。

小さなオンラインストアやローカルフォーラムでプリミティブ検索の実装を使用すると、多くの場合、最初のクエリを手動で再定式化する必要があります-単語を同義語に置き換え、ケースを変える、動詞の時制など。

これに何年も前に気づいた、検索エンジンの開発者は、特定のクエリだけでなく、さまざまなバリエーションや再定式を検索するために、ユーザーの生活を大幅に簡素化することが可能であると判断しました。 現在、 検索クエリをコンパイルする知恵に精通していないユーザーの正確な検索結果に誰も驚かない-しかし、 クエリを作成する際の時間を節約し、自由度を増すための苦労は続いている。

今日は、クエリ拡張メカニズム、つまり元のクエリの追加のみを検討します。 リクエストを変更する方法（ 「クラスメート」という単語のタイプミスを修正し、 Breach-Mullah、Breach-Mulloyに影響を与える方法）についてもう一度話をしようとします。

拡張機能をいくつかのタイプに分割します。各タイプは言語学的に類似していますが、独自の方法でもプロトタイプとは異なります。

略語（ rf → Rロシア連邦）

略語の開示はおそらく拡張機能の最も不正な形式です-一見正確で曖昧ではないように見えますが（「明白」、「モスクワ州立大学」は「モスクワ州立大学」）、すぐに明らかになります。「モルドヴィアン」と「マリウポル」の両方があり、 「国際人道主義者」など。

いくつかのタイプの略語を区別します。

• 頭字語（「モスクワ州立大学」、「CTP」）-それらを形成する単語の最初の文字で構成されます。 頭字語、特に2〜3文字の頭字語には、ほとんどのデコードオプションがあります。 頭字語のあいまいさが大きいほど、ランク付けの際に与える頭字語の重みは小さくなります。
• 複合（「matmeh」、「agricultural」）-単語の一部であり、通常は語根です。 場合によっては、ルートが追加の文字で結合されます（ " benz o saw " = " benz and saw "など）
• 句読点（「g。」、「Used」、「rn」）-略語に句読点が含まれる場合。
• 接頭辞の分離。各接頭辞は「auto」、「motorcycle」、「all」、「warm」の頭文字に縮小されます。 たとえば、「火力発電所」=「熱火力センター 」

文字変換（プジョー→プジョー）

略語とは異なり、直観はまさにここにあります。音訳は、拡張機能のすべての利点の数十パーセントを占めます。 彼女は良い正確さと完全さを持っています。 どんな状況でも大いに役立ちます。

ユーザーはキーボードレイアウトを切り替えたくないため、外国語の名前や地域を検索する場合、ロシア語（「Demongeot」ではなく「Demonjo」や「Cologne」ではなく「Cologne」）で入力する方が、元の正しいスペルを覚えるよりも簡単です。 逆の状況も非常に頻繁に発生します。ロシア語を話すディアスポラの居住者は、ロシア語のフォーラムでコミュニケーションすることに慣れていますが、音訳を使用しています。 このようなフォーラムでの検索は、キリル文字のクエリに必要です。 音訳は、検索語が見つかったサイトのアドレスに含まれている場合に便利です。

実際には、音訳する必要はありませんが、いわゆる実用的な転写 -別の言語による元の音の可能な限り最も近い伝達です。 そうしないと、たとえば、フランス語の単語が認識できないほど歪んでしまいます。

スペルチェックオプション（ike i →ike a ）

Orpho-optionsは同じ意味を持つ単語であり、このように書くことができます。また、両方のスペルは読み書きができると考えられます。

第一に、これらは耳から書かれた外来語であり、多くの場合、単一の正規のスペル（「ike i 」/「ike a 」;「 解釈 n」/「解釈n」）はありません。

音訳とは異なり、ここでは同じ言語でペアを扱います。 単一のラテン語のスペルに転写できるいくつかの単語は、オルソバリアントと呼ばれます。

次に、 綴りが異なるロシア語の単語 （「beat rd」→「bill rd」、「birthday is me」→「birthday is me」）

孤児のオプションは何に興味がありますか？

単語形成（モスクワ-モスクワ）

上記の拡張機能の種類（略語、翻訳、変曲、オルソバリアント）は、不可侵の意味を考慮して、可能な限りあらゆる方法でクエリの正確な単語を反映しようとしました。 しかし、元のリクエストにセマンティックの追加をより大胆に許可する必要があることがすぐに明らかになりました。 そのため、拡張子には単語の形成（「モスクワメトロ」→「モスクワメトロ」）と同義語（「カバ」→「カバ」）が追加されました。

単語形成の原則による拡張のアイデアは、他の品詞（「モスクワメトロ」→「モスクワメトロ」）を含む同種の単語をクエリに追加することです。

単語形成メカニズムは、単に形態と呼ばれることがよくありますが、これは完全に真実ではありません。 教育という単語に加えて、単語の変更は形態も指します（つまり、「ブリーチマロイ」）。 Inflectionがクエリに新しい意味のニュアンスを追加することはほとんどありません。通常、すべての形式（「 パラダイム全体」）で元のクエリワードを検索するため、この投稿では触れません。

反対に、語の形成は意味的に離れた異形を追加する可能性があります。一般的な考慮事項とは反対に、同じ語根を持つ語は意味が近くにある必要はありません。 実際には優れた検索拡張機能である語形成タイプはごく少数であるため、注意する必要があります。

同義語（モバイル→セル）

従来の辞書の学術的な同義語を基礎として、それらを検索にロードすることは可能ですか？ 確かに、辞書では信頼できる同義語の広範なランクを収集しました。

したがって、同義語の純粋な語彙、言語理解から離れ、等価物の統計検索ははるかにうまく機能します。 学術的な意味では同義語ではないかもしれないが、ユーザーが探しているものを見つけるのに役立つオプションが収集されます。 これがまさに主要な品質基準です-ランキングに対する拡張機能の有用性（意味における辞書の近接性ではありません）。

しかし、従来の意味で統計的に収集された同義語のコレクション（同じ意味を持つ単語として）は十分ではありません。 インターネット上に情報が非常に少ない非常に特殊なクエリの場合、一部のクエリ語をより一般的な概念（ 「hyperonyms」 ）に置き換えると便利です。

拡張オプションを収集する方法

次のセクションで最も興味深い部分は、拡張機能が検索でどのように使用されるかですが、最初に拡張機能仮説を準備する方法を見てみましょう。

上記から、インターネット上の「野生」に存在する実際のデータを分析することによってのみ、私たちのニーズに合わせて可能な拡張のオプションを構築できると推測するのは簡単です。 ユーザーのリクエストに迅速に応答する必要があるため、事前にそのようなオプション（いわゆる「拡張辞書」）を準備します。検索時には、完成した辞書からクエリワードのすべてのペアを選択します。

仮説集

ロシア語の場合、これは約1億5,000万のペアを提供します-拡張仮説。

周波数フィルタリング

クエリとインターネット上のテキストの両方であまりにもまれなペアは、非常に信頼できるソースではないため、仮説を収集した後、発生頻度に制限します。

特に意味はなく、何らかの形で（少なくともロシア語の場合）単語が1つまたは別のペアと一緒に見つかった形式（大文字と小文字の変化）を考慮します。 したがって、単語の形式（通常はイニシャル）のみを残します。

この結果、通常約1億のペアが取得されます。

最も可能性の高い拡張子の選択

しかし、1億個の粗雑な仮説は、単純に要求処理段階に渡すことのできない鉱石です。

この選択の結果、1000万の拡張機能が得られます。この「辞書」はクエリ処理で使用されます。 これについては次のセクションで説明します。

拡張機能が検索にどのように関与するか

ユーザーから検索クエリを受信したら、コンテキストから関連する拡張子を辞書から選択します。

たとえば、[mgu]は[mgu ^ mgu ^ msu ^ "Moscow State University"]に展開されます。

また、拡張クエリにより、検索では元の（「完全一致」）を含むさまざまな表現オプションを持つドキュメントが検索されます。 多くの要因は、元の単語と拡張子の両方を考慮して、ドキュメントのランキングを考慮します。 他のすべての条件が同じで、正確な形式（「msu」）に一致することは、拡張子を入力するよりも優先されます（「モスクワ州立大学」のように綴る場合でも）。



スニペットのクエリワードだけでなく、使用されているすべての類義語も強調表示することで、ユーザーが特定のドキュメントを表示する理由を理解できるようにします。

特定のリクエストに適切な拡張子とそうでない拡張子を判断する方法。 正確に、どのような場合に、どのボリュームに追加するのですか？ 拡張機能の種類が多いほど、それらを混合するためのアルゴリズムを構築するのが難しくなります。 通常、それらは手動で選択された分岐および係数ロジックから始まり、それらが多すぎる場合、定性的に異なる方法を探します。 私たちの経験では、最初の10個の要因の後で複雑なロジックを開発することはできません。1つの品質指標の成長が他の品質指標の匹敵する低下をもたらさないようにパラメータを選択するのが難しくなります。 少し前まで、この問題の解決策を機械学習に割り当てました。これにより、新しい要因をより迅速に追加でき、検索品質への拡張機能の貢献度が20％増加しました。 結果として生じるメカニズムを「コンテキストモデル」と呼びます。

, , 27% , .



, :

, , . , , . , .

, , . : , .

. , «» «», «Google» «», «» «Facebook» . , : «», « », «», «», «». (, ..), — .

, «» → «» , . , . 例：

( — )

, , : , .

, . , , ? . , [' ] [ ], .

— : ; , .

, : . , - , .

— . , , .

— . , . , «war k raft» — ( «War c raft»), - — ( [ ]) «» → «war k raft» , .

, «», «» «», .


, , . — . , , . 30% , 15% — .

文学

1. , . , 2010 ().
2. Voorhees, Query Expansion using Lexical-Semantic Relations — TREC WordNet.
3. Jones et al. Generating Query Suggestions — Yahoo! .
4. Dang, Xue, Croft. Context-based Quasi-Synonym Extraction — N- (, ).
5. Dang, Croft. Query Reformulation Using Anchor Text — Microsoft Research.
6. .. , .. . . ., , 1985 — .