サポート サポート問い合わせ先 | システムステータス システムステータス
ページ内容

    カタログ検索アーキテクチャ

    このトピックでは、CMS API と Playback API の両方に使用されるカタログ検索テクノロジーのアーキテクチャについて学びます。

    概要

    2019月XNUMX の時点で、カタログ検索機能が Elasticsearch にアップグレードされました。このアップグレードにはいくつかの利点がありますが、その主なものは、関連性と精度の向上、パフォーマンスの劇的な向上です。応答時間の一貫性がはるかに高く、通常はXNUMX倍の速さです。この新しい機能は、CMS API、Playback API、Studio インタラクティブ検索、およびカタログ検索メソッドに影響します。

    ブライトコーブは Elasticsearch の結果の一貫性を保つために多大な労力を費やしてきましたが、違いがあり、検索結果に特定の依存関係をコーディングした場合、統合が期待どおりに動作しない可能性があります。

    検索結果の違いと影響

    潜在的な影響を調査したところ、Brightcove は、検索の 90 % 以上が、返される結果の数に関して一致する結果を返すことを発見しました。これは、予想される結果が API 統合で問題を引き起こすほど大きく異なるべきではないことを示しています。

    比較

    このグラフは、XNUMXつのシステム間の結果の数と正確に一致する検索結果の数を青色で示し、数が異なるものは赤色で示します。

    ロールアウトの一環として、すべてのデフォルトの検索(空の文字列での検索)は、Elasticsearch によってすでに数か月間提供されているため、ユーザーは既に Elasticsearch の結果を問題なく表示して使用しています。

    ただし、この種の比較から学べることには制限があります。せいぜい特定の検索の意図の​​みを推測でき、カタログデータは流動的です。

    既知の違い

    以下の違いは主に根本的なものであり、検索結果を徹底的に分析した後で決定した結果です。完全に排除することは不可能です。

    ステミング

    ステミングは、活用された(または派生する場合もある)単語を、語幹、基本、または語根の形式(一般的には書き言葉の形式)に変換するプロセスです。

    ステム(語幹)を操作する英語のステマー、catは、 cats catlike 、ならびに catty のような文字列を識別する必要があります。ステミングアルゴリズムはfishingfished、ならびにfisherを、fishステムに減らします。ステムは単語である必要はありません。たとえばポーターアルゴリズムは argue argued argues arguing ならびに argus をステム argu に減らします。

    私たちの既存の検索では Lancaster(Paice / Husk)ステマーを使用しています。このアルゴリズムは、一般的に過度に攻撃的であると見なされています。これにより、区別が不足します。たとえば、 ライターライトは Lancaster では同じ用語と見なされます。

    Elasticsearch は、業界で広く採用されており、一般に大幅な改善と見なされている、最近のそれほど攻撃的でないアルゴリズム(PorterXNUMX)を使用しています(Lancaster は現在では珍しい)。ステマーの変更は、検索のかなりの割合(〜XNUMX%)に影響を与える可能性があります。つまり、結果が異なる というわけではなく、異なる可能性がある だけです。一般に、これはより良いものである必要があります。つまり、一部の顧客は古い動作に依存している可能性があります。

    関連性

    私たちの既存の検索では、より厳密なTF正規化があるようです。これにより、大きなフィールドで見つかった用語に対して異なる関連性ソートが発生します(つまり、既存のものは、ドキュメントの長さに対して相対的に小さいため、用語の重みが少ないため、一致の関連性が低いと見なされます)。

    特殊文字

    特殊文字は既存の検索内で削除されます。これは句読点と関連文字を削除することとほぼ同じです。削除する代わりに、通常、Elasticsearch でそれらをエスケープするため、検索では代わりにそれらが考慮される可能性があります。

    期間処理

    既存の検索クエリは「用語スムージング」を実行しますが、Elasticsearch では不正な用語を削除します。この検索で​​は空の検索を考慮します。 tags: term: q=tags: state:ACTIVE

    • 既存の: tags:state:ACTIVE —タグの付いた動画を検索します state:ACTIVE
    • Elasticsearch: state:ACTIVE - 空の用語を削除

    ぶら下がり句読点の処理に関連する微妙なエッジのケースや、通常は形式が正しくないクエリがいくつかありますが、クエリが意図したとおりのものを生成しようと試みますが、これらのケースでは、ユーザーが意図したものを推測しています(実際にエラーを返して、検索を絞り込むことができるはずだった場合)

    再生可能な動画のみ

    検索を現在再生可能な動画に制限するには、XNUMXつのメカニズムがあります。クエリにフラグを含めることも、クエリ自体に再生可能性のいくつかの側面を要求することもできます。

    • 既存:これは、更新されるフィールドの値に基づいて照会されます
    • Elasticsearch:計算された日付範囲に基づいて照会されます

    Elasticsearch は通常、より正確でより良い結果を生成する必要があります(既存のメカニズムに関連する遅延があり、フラグメンテナンスメカニズムは完全に信頼できるわけではありません)。

    インデックス精度

    Elasticsearch インデックスは既存のインデックスより「フレッシュ」であり、更新をより速く反映する傾向があります—これは常に当てはまるわけではありませんが、一般に Elasticsearch の経験では、結果は基になるカタログデータの状態をより正確に反映します。既存と Elasticsearch はどちらも分散システムであるため、返される結果に一貫性はありません。どちらかのシステムに対して繰り返しクエリを実行すると、異なる結果が返される可能性があります(特に、同時に実行されている削除操作の数が多い場合)。

    既存の検索結果は、アカウントが割り当てられているシャードの状態に基づいて変化します—特定のシャードのグローバルな状態は、特定のクエリの結果に影響を与える可能性があります(影響します)。Elasticsearch にはこの欠陥はありません。

    例1

    次のタイトルのXNUMXつの動画があるとします。

          Video#1: has the title “Don’t look into the light”
          Video#2: has the title “Using a lighter to make a campfire”

    ユーザーは、「light」という言葉が必要なすべての動画を返したいと考えています。 CMS API を使用すると、クエリは次のようになります。

          q=%2Blight or q=+light

    既存の検索では、これは両方の動画を次の順序で返します。

          Video#2 - “Using a lighter to make a campfire”
          Video#1 - “Don’t look into the light”

    これには2つの問題があります。

    • 関連性:順序が正しくありません。「ライターを使用してキャンプファイヤーを作る」(動画#2)の前に、「ライトを見ないでください」(動画#1)が表示されるべきです。
    • 正確さ:「ライター」を使用してキャンプファイヤーを作成することは、「ライト」という単語が動画タイトルにまったく表示されないため、結果セットに表示されるべきではありません。

    Elasticsearchを使用すると、動画XNUMXのみが返されます。

          Video#1 - “Don’t look into the light”

    これは改善です、次の理由により

    • 関連性:順序は正しいです。
    • 精度:タイトルに「ライト」という単語が含まれる唯一の動画であるため、動画XNUMXのみが返されます。

    例2

    ステミングに関する CMS API ドキュメントで説明されているように、ステミングはサポートされていますが、部分的な単語検索はサポートされていません。たとえば、次のタイトルのXNUMX本の動画があるとします。

          Video#1 - "Parking Ban Announced"
          Video#2 - "Parking to be Banned"
          Video#3 - "City Banning Parking"
          Video#4 - "Bank Holiday"
          Video#5 - "Bandit Captured"

    ユーザーは、名前フィールドに ban という単語が含まれている必要があるすべての動画を返したいと考えています。 CMS API を使用すると、クエリは次のようになります。

          q=%2Bname%3Aban or q=+name:ban

    「Ban」はXNUMXつすべての語幹であるため、「Ban」、「Banning」、および「Banned」は検索結果を生成すると予想されます。

    ただし、現在の検索システムでは、XNUMXつの動画すべてがこの順で返されます。

          Video#2 - "Parking to be Banned"
          Video#3 - "City Banning Parking"
          Video#1 - "Parking Ban Announced"
          Video#4 - "Bank Holiday"
          Video#5 - "Bandit Captured"

    繰り返しますが、これには2つの問題があります。

    • 関連性:順序が正しくありません。 「Parking Ban Announced」は、「Ban」という単語が含まれているため、最初に返される動画でなければなりません。
    • 精度:「Ban」は「Bank」または「Bandit」の一部ではないため、「Bank Holiday」および「Bandit Captured」はまったく返されないはずです。

    Elasticsearch では、結果は次のようになります。

          Video#1 - "Parking Ban Announced"
          Video#2 - "Parking to be Banned"
          Video#3 - "City Banning Parking"

    これは改善です、次の理由により

    • 関連性:順序は正しいです。
    • 精度:「Ban」という語の語幹(「Ban」、「Banning」、「Banned」)を含む動画のみが返されます。

    ページの最終更新日:12年2020月XNUMX日