#reco_tech cloud searchでレコチョク検索の実現に向けて

© RecoChoku Co.,Ltd. Proprietary and Confidential

株式会社レコチョク山本耕琢

05/03/2023

CloudSearch でレコチョク検索を実現するために


■ 楽曲情報の検索 API を利用している部分　レコチョクサイトの以下の機能で利用されている。

自己紹介（余談）

205/03/2023

PC サイトスマホ


305/03/2023

テーマの背景

CloudSearch に関して

レコチョク検索の要件

レコチョク検索を実現するために

まとめ


今回の発表するにあたり

405/03/2023

■ 背景　オンプレから AWS 環境への移行プロジェクトが開始した。　それに合わせて、レコチョクの検索基盤を Solr から Cloud　 Search に切替を実施した。

■ 発表内容　 Solr と CloudSearch の仕様差異により検索結果が違った。　同じ検索結果に近づくために工夫した事を発表する。　　■対象者　 Solr または CloudSearch の知識が少しある方とさせて下さい。　※すみません、専門用語を解説する時間がなく。

　　


505/03/2023

テーマの背景




まとめ


CloudSearch とは

605/03/2023

■CloudSearch とは　 AWS クラウドにおけるマネージド型サービスで、　 Web サイトやアプリケーション向けの検索ソリューションを　容易かつコスト効率良く設定 / 管理 / スケールが可能となる。


Solr と CloudSearch を比較してみて

705/03/2023

■CloudSearch の特徴　インフラが不要となり、検索基盤の構築 / 運用が容易である。　データ登録とデータ検索の条件が複雑な場合、 CloudSearch　で全て実現することが難しい。　　　

Solr CloudSearch

インフラ構築 ×インフラを構築- サーバを構築 / 運用が必要- アプリケーションを準備 ◎

クラウドサービスで利用- サーバの構築が不要- 数クリックで構築

検索フィールドカスタマイズ

◎柔軟なカスタマイズ- FieldClass をカスタマイズ- 設定ファイルによる変更 ×

提供されている設定のみ- 型と分析スキームを設定- 一部オーバーライド可

スケーリング × 手動でスケーリング- 最大利用量でスケーリング ◎ 自動でスケーリング

- 利用状況で自動スケーリング- 最低スケールは設定可能

モニタリング △様々な情報を取得- サーバの情報を取得- 取得する仕組みが必要 △

提供されている情報のみ- 取得する仕組みが不要- 提供されている情報が少ない


なぜ、 CloudSearch なのか？

805/03/2023

■ コスト　 Solr 版検索基盤は、サーバを 45 台で構成していた。　 EC2 ＋ Solr という選択もあるが、 CloudSearch を利用した方が　安価となった。　■運用工数　 45 台のサーバを運用工数が削減が出来る。　スケールアウト、スケールインが自動化される。

■挑戦　 AWS 上のサービスを利用して実現してみたかった。　　

　


905/03/2023

テーマの背景




まとめ


レコチョク検索の要件について

1005/03/2023

■ 多種多様な文字列や、様々な検索条件に対応　“嵐”、” B‘z” 、”かりゆし 58” 、”ハジ→”など多種多様な文字列の　検索が出来る。　プロフィールなどを、前方 /中間 /後方一致で検索が出来る。

■検索文字列の制御　データ登録・検索時の、シノニムとストップワードの適応が　それぞれ定義することが出来る。　検索文字列の正規化して検索する。　　 ●レコチョクの正規化ルール　　　　 - ひらがなとカタカナは、全角カタカナに変換する。　　　　 - 英字は、半角小文字に変換する。　　　　 - 数字は、半角に変換する。

■特定の情報でヒットした情報を上位に　検索フィールドに優先度（重み付け）の設定が出来る。


1105/03/2023

テーマの背景




まとめ


Solr での検索結果に近づけるために

1205/03/2023

■ 検索フィールドへの重み付けを設定する。

■検索キーワードが少し長くなると検索が出来ない。

■関連度 (score値 ) によるソート結果に差異がある。

■ N-gram(2+1) でインデックスが出来ない。

■記号での検索が出来ない。

　


Solr での検索結果に近づけるために

1305/03/2023

■ 検索フィールドへの重み付けを設定する。

■検索キーワードが少し長くなると検索が出来ない。

■関連度 (score値 ) によるソート結果に差異がある。

■ N-gram(2+1) でインデックスが出来ない。

■記号での検索が出来ない。

　

今回は割愛します m(_ _)m


CloudSearch では記号の検索が出来ない

1405/03/2023

■CloudSearch における検索フィールドの仕様　検索対象とする文字列は「 text」型で定義する。　「 text」型では、記号 (＠、→、♪など ) の検索が出来ない。

　●インデックス作成のテキスト処理として、トークン分割、正規化後に、　　ステミング、ストップワード、シノニムを適応して作成する。　　　●トークン分割では、 UnicodeTextSegmentation で定義されている、　　ワードブレークを使用して分割する。その時、記号 (＠など）は、　　区切り文字として削除されてインデックスがされない。『 Amazon CloudSearch でのテキスト処理』より抜粋インデックスの作成中、 Amazon CloudSearch はフィールドに設定された分析スキームに従って text フィールドと text-array フィールドを処理し、インデックスに追加する用語を決定します。分析オプションが適用される前に、テキストがトークン分割および正規化されます。

トークン分割時、フィールド内のテキストのストリームは、 UnicodeTextSegmentation アルゴリズムで定義されたワードブレークを使用して、検出可能な境界上の別個のトークンに分割されます。ワードブレークルールに従って、スペースやタブなどの空白文字により区切られた文字列は別個のトークンとして扱われます。多くの場合、句読点は削除され、空白文字として扱われます。たとえば、ハイフン（ - ）および記号（ @ ）では文字列が分割されます。

＜中略＞正規化時、大文字は小文字に変換されます。

＜中略＞トークン分割と正規化が完了したら、分析スキームで指定されたステミングオプション、ストップワード、シノニムが適用されます。


具体的にどうなるかと言うと

1505/03/2023

■記号を含んだ検索結果の例　記号を含んだ場合、検索結果がノイズが混じったり、検索が　出来ないケースが発生する。

　

入力文字列CloudSearchのテキスト処理後

アーティスト名CloudSearchのインデックス

検索結果説明

ベッキー♪ # ベッキー

ベッキー♪ # ベッキー

○ 検索時も同様のテキスト処理が実施され、検索される。

ベッキーベッキー ○

♪# “ なし” ×

E-girls egirls

E-girls egirls

▲ 「 E」と「 girls」で検索されて、検索対象が多くなる。

Egirls egirs × 「 egirs」のインデックスが存在せず、検索されない。

つのだ☆ひろつのだひろ

つのだ☆ひろつのだひろ

○

つのだつのだ ○ 部分一致として、検索される。

*ω*Quintet quintet*ω*Quintet quintet

▲ 「 Quintet」で検索されて、検索対象が多くなる。

*ω* “ なし” × 　

□□□ “ なし” □□□ " なし " × インデックスが存在しないため、検索が不可となる。


では、記号での検索を実現するため

1605/03/2023

■ レコチョク独自のテキスト処理　アプリケーション側で、独自のテキスト処理を実施する。　その中で、記号を全角ひらがなに置換する。　

　

処理内容説明登録時検索時

文字列正規化文字列を正規化する。- ひらがな / カタカナ：全角カタカナ　※ひらがなは使用しない。- 英字：半角小文字- 数字：半角数字

実施実施

記号変換全角ひらがなに置換する。例）＠⇒「あああ」

実施実施

空白削除空白文字列を削除する。実施未実施

踊り文字変換 “ 々” ,”ゝ” ,”ヽ” ,”ゞ” ,”ヾ”を置換する。- 直前の文字に置換する。- 連続した場合は、直前の文字を置換する。- 直前に文字が無い場合は、置換しない。

実施実施

空白文字区切り空白区切りで文字列のトークン分割をする。未実施実施

シノニムワード同義語対応をする。実施実施

ストップワード除外対象語対応をする。実施実施

N-gram 分割登録時は、「 1+2-gram」で分割する。検索時は、「 2-gram」で分割する。

実施実施今回は割愛します m(_ _)m


これで記号の検索が実現した！

1705/03/2023

■記号を含んだ検索結果の例 (独自テキスト処理の導入後 )　独自テキスト処理で、以下のように記号の検索を実現した。

　

検索文字列レコチョクテキスト処理後

CloudSearchのテキスト処理後

アーティスト名レコチョクテキスト処理後

CloudSearchのインデックス

検索結果

説明

ベッキー♪ # ベッキーあいベッキーあい

ベッキー♪# ベッキーあいベッキーあい

○

ベッキーベッキーベッキー ○

♪# あいあい ○ 部分一致として、検索が可能となる。

E-girls e う girls e う girlsE-girls e う girls e う girls

○

Egirls egirs egirs × 検索されないことが、期待通りの動作となる。

つのだ☆ひろツノダえヒロツノダえヒロつのだ☆ひろツノダえヒロツノダえヒロ

○

つのだツノダツノダ ○

*ω*Quintet おかお quintet おかお quintet*ω*Quintet おかお quintet おかお quintet

○ 「 *ω*Quintet」として検索が可能となる。

*ω* おかおおかお ○ 部分一致として、検索が可能となる。

□□□ きききききき □□□ きききききき ○ 「□□□」での検索が可能となる。

■ 変換ルール：♪ ⇒ あ、 # ⇒ い、 - ⇒ う、☆ ⇒ え、 * ⇒ お、 ω ⇒ か、□ ⇒ き


しかし、記号の検索が実現したと思ったら…

1805/03/2023

■期待通りに検索されない　“ E-girls” で検索すると「 Girls’Generation-TTS」のように、「 E」と「 -」が連続していな文字列も検索された。

検索文字列レコチョクテキスト処理後

CloudSearchのテキスト処理後

アーティスト名レコチョクテキスト処理後

CloudSearchのインデックス

検索結果

説明

E-girls e う girls e う girls

E-girls e う girls e う girls ○

Girls’Generation-TTS

girls く generation う tts

girls くgeneration うtts

???「 e う girls」に一致する文字列がCloudSearch 上に存在しないはず。。。

■ 変換ルール： - ⇒ う ‘ ⇒ く


記号検索問題の発生

1905/03/2023

■問題の原因　記号を全角ひらがに変換したことによる副作用と判明した。　 UnicodeTextSegmentation では文字種の違いでも文字列を　トークン分割するため、変換部分で期待していない分割が　行われていた。　　

　

入力字文字列

レコチョクテキスト処理後

CloudSearchテキスト処理後アーティスト名レコチョク

テキスト処理後CloudSearchテキスト処理後

検索結果

説明

E-girls e う girlseうgirls

E-girls e う girlseうgirls

○


girls く generation う tts

girlsくgenerationうtts

▲分割されることにより部分一致も含めて、検索される。

■ 変換ルール： - ⇒ う ‘ ⇒ く


■ 対応策の検討　案１：記号変換する文字種を変更？　　文字種を半角小文字の英字にすることで文字種を揃える。　　逆に「クローバー」などは、期待通りの検索にならない。　　

　案２：分析スキームを「日本語 (_ja_default_)」に変更？　　日本語トークン分割ディクショナリで辞書登録をする。　　しかし、「日本語 (_ja_default_)」に変更すると、　「か」や「じ」は終助詞や助動詞として認識され、検索上　　重要でない品詞に該当する語として削除される。　　　案３： text 型から literal-array 型に変更？　　 N-gram(2 ＋ 1) に分割した結果を、 literal-array 型として　　保持する。ただ、配列の最大数が、 1000個となるため、　　プロフィール情報など長い文字列のインデックスを作成　　出来ない。　

詳細は割愛します m(_ _)m

記号検索問題への対応

2005/03/2023


■問題への対応　記号を全角ひらがなと半角大文字英字の両方でテキスト処理　した結果で検索文字列を作成した。　

●レコチョクの正規化ルール（再掲）　 - ひらがなとカタカナは、全角カタカナに変換する。 ※ひらがなは使用しない。　 - 英字は、半角小文字に変換する。 ※大文字英字は使用しない。　 - 数字は、半角に変換する。

　　

記号検索問題を解決

2105/03/2023

入力字文字列


CloudSearchテキスト処理後アーティスト名


CloudSearchテキスト処理後

検索結果説明

E-girls e う girlseUgirls

eうgirlseugirls

E-girls e う girlseUgirls

eうgirlseugirls

○


girls くgeneration うttsgirlsKgenerationUtts

girlsくgenerationうttsgirlskgenerationutts

× 「 eugirls」が存在しないため、検索されない

■ 変換ルール： - ⇒ う and U 　‘ ⇒ く and K


2205/03/2023

テーマの背景




まとめ


■ まとめ　簡易な検索基盤の構築なら、 CloudSearch がおすすめ。　

　●数クリックで検索エンジン基盤の構築が可能となる。　●テキスト処理は、 CloudSearch の仕様に合わせるのがよい。

　複雑な検索要件の場合は、テキスト処理をアプリ側でする。　

　●検索クエリーが複雑化する。　●検索結果をキャッシュするなど、検索回数を減らす方がよい。

　

　　

最後に

2305/03/2023


■ 今後の取り組み（表は再掲）　安定稼働に向けて、キャッシュ機構の導入と監視の強化を　実施したい。

　

　　

最後に

2405/03/2023

Solr CloudSearch

インフラ構築 ×インフラを構築- サーバを構築 / 運用が必要- アプリケーションを準備 ◎

クラウドサービスで利用- サーバの構築が不要- 数クリックで構築

検索フィールドカスタマイズ

◎柔軟なカスタマイズ- FieldClass をカスタマイズ- 設定ファイルによる変更 ×

提供されている設定のみ- 型と分析スキームを設定- 一部オーバーライド可

スケーリング × 手動でスケーリング- 最大利用量でスケーリング ◎ 自動でスケーリング

- 利用状況で自動スケーリング- 最低スケールは設定可能

モニタリング △様々な情報を取得- サーバの情報を取得- 取得する仕組みが必要 △

提供されている情報のみ- 取得する仕組みが不要- 提供されている情報が少ない

#reco_tech cloud searchでレコチョク検索の実現に向けて

Engineering