本記事は Algolia Advent calender 2021 4日目の記事になります。

こんにちは、 Algolia のサポートエンジニアの半田です。

Algoliaはこの一年でもさまざまな機能リリースがありました。最近は特にAIを活用した機能が目立つのですが、一方で検索機能の使い勝手を向上させる堅実なアップデートもたくさん発表されました。その中でも比較的お問合せをいただくことの多い機能の一つであるVirtual Replicaについてご紹介してみたいと思います。

レプリカによる複数のランキングの実装

Virtual ReplicaはAlgoliaの検索結果について、複数の異なるランキングでの表示を可能にするための機能です。

Algoliaでは基本的には1つのインデックスは1つのランキング設定に紐づきます。このため、例えばeコマースのWebサイトなどで発売日順や価格順などでの検索結果を提供するためには、あらかじめそのようなランキング設定をしたレプリカインデックスを準備し、検索時に対象のインデックスを切り替える形となります。例えばInstantSearch.jsのSortBy Widgetは複数のインデックス間を切り替えるUIを簡単に作ることができます(サンプル)。

元々、Virtual Replicaが発表される前からAlgoliaのインデックスにはReplicaを作成する機能は存在していました(現在はVirtual Replicaに対しStandard Replicaと呼ばれています)。Standard ReplicaはPrimary indexのデータコピーを保持しつつ、異なるインデックス設定を適用させることができる機能です。このため、異なるランキング設定を持つStandard Replicaを作成することで複数のソート順を提供することが可能だったのですが、一方でReplicaの追加に伴うレコード数の増加を避けられませんでした。このため、Pay-as-you-goのプランではレコードの増加に従って課金単位となるUnitの消費が大きくなるのが悩みの種でした。

Virtual Replicaの特徴

こうした中で2021年3月にリリースされたVirtual Replicaは、Relevant sortとよばれる機能を提供することで一定の検索クオリティを保ちつつレコード数に影響しないソートの実装を可能にしました。Virtual Replicaはその名が示す通りデータコピーを持たないReplicaのため作成してもレコード数が増加することはありません。ではどのようにソートを可能にしているかというと、端的に言えばPrimary indexから取得した検索結果を再度並び替えることによりソートされた検索結果を返却します。

もう少し具体的な流れとしては、以下のステップで処理を行います。

1. クエリにマッチするレコードを Primary Index の ranking formula を元に取得する
2. Hit したレコードを relevancyStrictness パラメータに基づいてフィルタする
3. 取得したレコードをVirtual Replica の customRanking に従ってソートし、結果を返却する

こちらの内容から分かる通り、基本的にVirtual Replica に対するクエリの結果は「Primary Indexの同クエリの検索結果 (のサブセット)を並べ直したもの」ということになります。こうした内部処理を実施することで、データのコピーをあらかじめ用意することなくことなるランキング設定の検索結果を提供することができるのです。

Virtual ReplicaはStandard Replicaと同じようにAlgoliaのダッシュボード上やAPIからの作成が可能です。

レプリカ作成後、Relevant sortメニューからcustomRanking 設定を指定することで検索結果のソート順を指定することができます。

Virtual Replica使用上の注意点

上述のようにレコード数を増やさず複数のランキング結果を実装できるVirtual Replicaですが、Virtual ReplicaがPrimary Indexから検索結果を取得する際、レコードが部分的にフィルターされる可能性がある点には注意が必要です。すなわち、Virtual Replicaが返却する結果は従来のStandard Replicaを使用する場合と比べ、必ずしも網羅的(Exhaustive)ではないということです。

より具体的にはRelevanceが低いレコードがrelevancyStrictnessによってフィルタされるケースやPrimary Indexでの検索結果がpagenationLimitedToの上限数を上回るケースなどがあります。

relevancyStrictness によってフィルタされるケース

relevancyStrictnessはVirtual Replica固有の設定値で、Primary Indexからソート対象となる検索結果を取得する際のRelevance(関連度)の閾値を設定します。 この値を変化させることで、タイポを含むレコードなどクエリに対するRelevanceの低いレコードを結果にどの程度含めるかをコントロールすることができます。

relevancyStrictnessは0-100の間の数値で設定でき、デフォルト値は最大値である100に設定されています。値が大きいほど閾値が高くなり、Primary Indexから渡される結果に対するフィルタが強くかかります。言い換えると、Relevanceの低いレコードがVirtual Replica検索結果に含まれにくくなります。このため、デフォルト設定でソート対象に意図したレコードが含まれない場合には、relevancyStrictnessの値を下げながら意図した量のレコードがVirtual Replica の検索結果に含まれるように調整する必要があります。この際、Relevanceの判断は基本的にはPrimary Indexでの ranking criteriaに基づくものとなります。

少し具体的な例でrelevancyStrictnessの検索結果への影響を見てみます。 対象のレコード群を「アイルランド」というクエリで検索すると、Primary Indexでは4つのレコードがヒットするとします。この内、3つのレコードはexact matchが含まれ、4番目のレコードはタイポを考慮した一字違いの「アイスランド」という文字列が含まれています。

Primary Indexではデフォルトのランキング設定を使用しており、1-3番目は語の出現位置、4番目は typo によってランキングが決定されています(ランキングの詳細はこちらの記事を御覧ください)。 このインデックスに対し、Virtual Replicaを作成し、price attributeにて降順でソートする設定を行うと、どのような結果となるでしょうか。

relevancyStrictnessが100の場合、typoのない上位3つのレコードがRelevanceの観点で閾値を超えると判断され、Virtual Replicaはこれら3つのレコードをソート対象とします。結果として、検索結果は以下のような形になります。

これに対し、relevancyStrictnessが0の場合にはRelevanceの閾値が下がり、タイポのあるID:Dのレコードも含めた4レコードがソート対象となります。また、ID:Dのドキュメントはソート基準となるprice attributeの値が最も大きいため、relevancyStrictnessが100のときのランキングと比較するとランキング1位のレコードが入れ替わる結果となります。したがって、ランキング結果は以下のような形になります。

このように、relevancyStrctnessはPrimary indexでのランキングを基準にソート対象レコードの取捨選択をするため、ランキングの見え方にも大きな影響を及ぼす可能性があります。

relevancyStrictnessは正直なところ挙動にやや癖のあるパラメータです。値を設定する際にはまずはデフォルト値でお試しいただき、結果がStrictすぎる場合には値を少しずつ下げながらテストいただくことをおすすめしています。また、十分にトラフィックがある場合には A/B テストを使用して成績の良い設定値を探ることも有効です。

relevancyStrictnessを最低値の0にした場合には上記の例で見たとおりrelevanceによるフィルタリングは行われなくなります。この場合、Primary Indexから取得される全ての検索結果がVirtual Replicaでのソート対象となりますが、このときの対象レコード数は後述するpagenationLimitedToパラメータの値が上限となる点に注意が必要性です。

relevancyStrictnessパラメータの詳細についてはこちらのドキュメントが参考になります。

Primary Indexでの検索結果が上限数(pagenationLimitedTo)を上回るケース

Virtual Replica がPrimary Indexから取得できる検索結果の数はPrimary IndexのpagenationLimitedToパラメータの値に制約されます。デフォルトではこの値はパフォーマンス上の理由から1000に設定されており、Primary Indexで1001番目以降のレコードについてはVirtual Replicaのソート対象には含まれません。

Primary IndexではpagenationLimitedToの設定値を変更することで上限値を増やすことができます。ただし、このパラメータはクエリの応答速度に影響する可能性があるため、可能な限りデフォルト値でご利用いただくことをおすすめしております。本記事執筆時点で設定可能な最大値は20000となり、これがVirtual Replicaでソート対象とできるレコード数の最大値です。

まとめ

ということで、2021年に発表されたAlgolia機能の中でも比較的サポートにお問い合わせ頂くことの多いvirtual replicaについて、少し詳細な動作をご紹介してみました。レコード数を抑えながら複数のソート順を実装できるVirtual replicaの機能は非常に魅力的で、上手に活用することでAlgoliaの追加コストなしによりよい検索体験を実装することができます。

一方で、導入にあたってはその特徴から検索結果が必ずしも網羅的でない場合がある点をあらかじめ考慮頂く必要があります。レコード数の多いインデックスで、網羅性が求められるユースケースなどにおいては、従来のStandard replicaの使用が必要となるケースもある点をご注意いただければと思います。

Exhaustive sorting、Relvant Sortingおよび各レプリカについてはドキュメントも充実していますのでよろしければ参考にしてみてください。

• Exhaustive Sorting
• Relevant Sorting
• Understanding Replicas