Search Engineering Newsletter vol.10
イチオシは、お手軽な検索API構築 と Do you really need a feature store? です。
Search
How we're improving search results when you use quotes - Google
Google、引用符による完全一致検索結果をフレーズを中心に表示するよう改善 - PC Watch ダブルクォートを使った完全一致検索を行う際に、webページのヘッダーやURLなどは検索対象外になることで、GoogleのWeb検索体験を改善した。
厳格なテスト – Google 検索の仕組み Google 検索がどのようにテスト・評価を行っているか。 2021年に、約4000件の変更、約11000件のABテストを行っているらしく驚き。 簡単に逆算しても月間に900件ABテスト???をやっていることになるのだが、どんなことをすればこんな数のABテストを実行可能になるのだろうか...。 例えば、一つのABテストで、セグメントと5分割したからこれを5回としますならわかるけど、それでも月間に180回のABテストなので現実味がわかないですね。 Google検索に関わるエンジニアの数が全体でどれくらいいるのか気になりますが、この成果はさすが世界最大規模の検索エンジンですね。
サーバーレスの検索システムってどう作るんだろうかと気になって軽く調べていた経緯で紹介します。 コンテナイメージ内に検索インデックスイメージを含めることで、サーバーレスに Apache Solr を運用した記事です。
利用条件に制限を少し加えて、データの更新をリアルタイムには行わない、サーバ1台で管理できない規模のデータを扱わない
確かにインデックスをリアルタイムに更新する理由が強くない場合などもあると思うので、実現できそうな状況は多々ありそうです。 サーバーレスに構築することで、運用コストを押さえつつ全文検索はやりたいという目的は達成できそう。Cookpad さんの人気順検索のSolrはスケールのためにディスクを捨てた - クックパッド開発者ブログとアプローチが似ていますね。 機械学習領域もそうですが、コンテナにデータをもたせて更新していくというアプローチは状態を持つアプリには利点がおおい運用なので、コンテナ様様です。 コンテナ内に含めずにS3上のデータを全文検索したいケースを解説した記事がCloud-native search engine をうたうquickwit-oss/quickwit: が執筆しています。 Searching the web for < $1000 / month | Quickwit 知らなかったんですが、Elasticsearch も S3 上にインデックスをマウントする機能をリリースしてるんですね。 quickwit は 計算部分とストレージ部分を分離させることを目指しているらしく、どんな仕組みで行っているか、次のニュースレターでみてみます。 勉強不足なので知らなかったのですが、 Spark や Presto は ストレージと計算を分離しているらしい。この仕組も気になる。
Optimizing Elasticsearch for Low Latency, Real-Time Recommendations - Zillow Tech Hub
不動産売買のマーケットプレイスを運営する Zillow が Elasticsearch を使って、どのようにして高速にリアルタイムな推薦を行っているかの解説。 Elasticsearch のリクエストのライフスパンの解説で、リクエストが、キュー・クエリ・フェッチの三段階でさばかれる。 Zillow の場合はフェッチ部分がボトルネックになっているので、その最適化のためにフェッチメソッドを souce
から doc value
に変えて最適化して約2割程度、レイテンシーが高速化されたのは勉強になった。またCPUの使用率も3-5割ほど削減されたとのこと。 また、高速化のためにElasticsearch のキャッシュの活用やバルクリクエスト、リフレッシュインターバルも紹介されており実践的で面白い。
How Instagram suggests new content Instagram がどのように新しいコンテンツを推薦しているかの解説記事。
関口宏司のLuceneブログ Lucene のComitter でもありPMCでもある関口さんのブログ。最近は更新されていないが、 #lucene についての解説記事が書かれており勉強になります。
全社横断のレコメンドAPIを開発した話 - pixiv inside Pixiv 内部のサービスを横断して、提供可能なら推薦サービスを構築した話。 初手はGoogle BQ 上で推薦結果を計算して、サービス側にその結果をサービス内に同期する方法を取っていたらしく、これも良いアプローチですね。 データガバナンス的に、一つの推薦サービスでサービスA、サービスBと認可されていないデータの管理とかどうやるのかなと思っていたら、暗号化により認可を兼ねているらしく面白かった。
多様なコンテンツをとどける、レコメンドベースのnoteのホームタイムラインをつくる|kiha|note 松竹梅のアプローチを考えた上で、Elasticsearch を使ってnoteの推薦サービスを構築したお話。 #elasticsearch icsearch では Significant terms aggregation | Elasticsearch Guide [8.4] | Elastic という集計機能を使えば、特徴的なタームを集計できると知った。 最初はこの集計機能で、note の記事のキーワードを抽出を試みたが、結果的には note の記事のハッシュタグを利用して、キーワード抽出を行ったのは既存のデータを上手く活用して、コスパよく試せるアプローチで良いなと思いました。
同じ機能を プロダクトマネージャー視点から開発した紹介記事も公開されており面白かったです。 機械学習エンジニアがPdMとして推薦機能をマネージメントしたらこうなった|konumaru|note この記事で感心したのは、Sagemaker の出力結果をGoogle Spreadsheet に保存して、それをFigmaと同期することで実際に推薦結果を出されたかのようなプロトタイプを作って検証している点です。
Spreadsheetではサムネが無いことによる体験の悪化に気づけなかった
ここの点とか すごく共感できるんですが、アプリレベルまで落としてからこそ気がつける体験があるので、実際のアプリに限りなく近い状態での体験の検証って大事ですね。
Machine Learning & Data Science
Evolution of ML Fact Store. by Vivek Kaushal | by Netflix Technology Blog | Netflix TechBlog Netflix での特徴量ストアの運用を通じて学んだことをまとめてくれている。5年前から特徴量ストアが必要だと言っていたんだよから始まり、自前のOSS(EvCache, Iceberg)を駆使してどのように特徴量ストアを構築したかが書かれている。
Do You Really Need a Feature Store? | by Lak Lakshmanan | Towards Data Science 本当に特徴量ストア って必要ですかというお話。 要約として、特徴量をサーバーサイドで生成しないといけない(つまりリアルタイムに特徴量をオンラインで生成する必要性がある)とき以外は、特徴量ストアはオーバキルだよねという良いお話。 適切な道具は適切なタイミングで使わないと真価が発揮されない。 上で紹介したNetflix のような事例は確かに有効かもしれないが、オーバキルになっている場合もあるんじゃなかろうか
tldr: Use a feature store if you need to inject features server-side, especially if the method of computing these features will keep improving. Otherwise, it is overkill.
AI Project Management Flow and Build Trap Review 不確実性の高い機械学習プロジェクトを自己組織化されたチームで健全かつ最大化されたゴールに向かうために - Speaker Deck 2020年2月に公開されたプロジェクトマネジメントアンチパターンが進化した資料[^dena]。組織内で統一的に機械学習のプロジェクトはこうすすめるべきという指針が出来ていたら成功確率もかなり上がりそうですね。
Etsy Engineering | Towards Machine Learning Observability at Etsy Etsy での機械学習システムの監視に関する記事。Etsyではほとんどのモデルが、24時間毎に3ヶ月分の学習データで再学習してデプロイされている。 つまり高頻度な再学習によりモデルのドリフトを回避している。 だが、再学習のコストは馬鹿にならないので、再学習頻度を抑える代わりに監視を行い、適切なタイミングで再学習を行うようにしたいという自然な動機。
Google BigQuery の隠れた名機能 | Google Cloud Blog AUTO カラムやマルチステートメントトランザクションの機能は知らなかった。まだプレビューだけど、インデックス機能は、BQにためたデータに対して制約条件を理解した上で検索したいときに大きく役立ちそうですね。
faker-ruby/faker: A library for generating fake data such as names, addresses, and phone numbers. Stable Diffusion などで機械学習による人工的なデータ生成がキャズムを超えそうな気がしていますが、自然言語処理の分野で人工的なデータ生成ってあったけなと思い返すと、Ruby 製の Faker がありました。 READMEを観てると Japanese media という章があり、ジブリやドラゴンボールに対応していて驚いた。
Zig の TensorFlow Lite ライブラリを書いた。 様々な言語向けに TensorFlow Lite ライブラリを作っている mattn さんが、 zig 言語用のTensorFlow Lite ライブラリを作成。が、Zig のパッケージのエコシステムがまだ未発達なので画像を扱うようなタスクなどは作れないとのこと。
機械学習の社会実装勉強会 - connpass 2021年11月から、毎月開催されている機械学習の実装に重きをおいた勉強会。 運営している Machine Learning Casual Talks - connpassを定常開催できなくなってしまっていますが、同じような目的の勉強会が活発なのは嬉しいですね。
AlexNet前夜 - Speaker Deck 牛久先生による、 AlexNet が席巻するまでの機械学習による画像認識の歴史を俯瞰的に説明してくれた資料。
PLATEAUから街の構造を見る - estie inside blog オープンデータを使って、東京の都市構造、具体的には道路の長さや方角を集計することで、都市の特性を可視化してみたよという記事。 昔コンピュータービジョンの論文を読み漁っていたときに、位置情報が付与された大量の画像を使って、世界の26個の都市構造を解析するという、面白い考えの論文[^cimave]を読んだことがあり、好きなネタになりました。
Step-by-Step MLOps and Microsoft Products - Speaker Deck マイクロソフトによるMLOps の成熟度の定義とAzure を使ってどのように実現していくかの日本語の資料。 他の大手クラウドベンダーのGCP[^gcp]やAWS[^aws]も同じような成熟度を定義していますが、クラウドベンダー毎に成熟度を定義してくれれば、各ベンダーでどんなサービスを具体的に使えば実現できるのかわかりやすそうです。
GPT-neoxの学習用にマルチノード並列学習環境を整えた with DeepSpeed - ABEJA Tech Blog
ABEJA GPTモデルにおけるアーキテクチャの工夫 - ABEJA Tech Blog ABEJAさんが取り組んだ大規模言語モデル GPT構築に挑んだ際に得られた知見を惜しみなく公開してくれている記事。 学習データが巨大すぎて、前処理中にディスクオーバーしたりと、このタスクでしかなかなか味わえないような結果は読み応えがありました。 Hugging Faceでモデルも公開されているのでもし興味があれば試してみるのも良さそうです。Web上で文章生成をすぐに試せるのでそれだけでも楽しいです。
時間を割り切って、小刻みに定期的に書いたほうが記事を消化できることに今更気がついたので、これから隔週か毎週くらいでニュースレターをかけたらよいなと思っています。
感想など
Twitter で #searchengineeringnewsletter のハッシュタグでつぶやいていただくか、Google フォーム での感想投稿をお待ちしております。 また、substack上でのコメントも歓迎しております。
それらのご感想は執筆の励みにさせていただきます。
もしよろしければ、Buy Me a Coffeeからサポート(投げ銭)していただけると、ニュースレター配信のモチベーションに繋がります✨
[^dena]: AI Project Management Anti Pattern - Speaker Deck [^aws]: MLOps foundation roadmap for enterprises with Amazon SageMaker | AWS Machine Learning Blog [^gcp]: MLOps: Continuous delivery and automation pipelines in machine learning | Cloud Architecture Center | Google Cloud [^cimave]: C-IMAGE : city cognitive mapping through geo-tagged photos