MLOps
Issue Date: 2025-10-10 Argo Workflows, Argo Project, 2017.11 #Article #RecommenderSystems #NeuralNetwork #Embeddings #EfficiencyImprovement #AWS #Blog #A/B Testing #TwoTowerModel
Issue Date: 2025-06-29 日経電子版のアプリトップ「おすすめ」をTwo Towerモデルでリプレースしました, NIKKEI, 2025.05 Comment
リアルタイム推薦をするユースケースにおいて、ルールベース+協調フィルタリング(Jubatus)からTwo Towerモデルに切り替えた際にレイテンシが300ms増えてしまったため、ボトルネックを特定し一部をパッチ処理にしつつもリアルタイム性を残すことで解決したという話。AWSの構成、A/Bテストや負荷テストの話もあり、実用的で非常に興味深かった。
#Article #RecommenderSystems #NeuralNetwork #CTRPrediction #NewsRecommendation #Evaluation #Blog #A/B Testing
Issue Date: 2024-08-31 NewsPicksに推薦システムを本番投入する上で一番優先すべきだったこと, 2024.08 Comment
>推薦モデルの良し悪しをより高い確度で評価できる実験を、より簡単に実行できる状態を作ることでした。平たく言えば「いかにA/Bテストしやすい推薦システムを設計するか」が最も重要だった訳です。
オフライン評価とオンライン評価の相関がない系の話で、A/Bテストを容易に実施できる環境になかった、かつCTRが実際に向上したモデルがオフライン評価での性能が現行モデルよりも悪く、意思決定がなかなかできなかった、という話。
うーんやはり、推薦におけるオフライン評価ってあまりあてにできないよね、、、
そもそも新たなモデルをデプロイした時点で、テストした時とデータの分布が変わるわけだし、、、
Off-Policy Evaluationの話は勉強したい。
あと、定性評価は重要
pythonコードでコンポーネントや、パイプラインを関数の形で記述するだけで、MLのCI/CDパイプラインをVertexAI上に自動構築できる模様。非常にお手軽で、多くの設定ファイルなどは自動生成されるようなので、簡単に始めることができそう。
記事中では、多クラス分類器を学習するためのデータをBigQueryから取得、モデル訓練、デプロイ、推論エンドポイント生成、モニタリングなどを簡単なコードベースで実現できている。便利そうではある。
細かいチューニングも自動生成された設定ファイルをいじれば可能だと思われる。
#Article #RecommenderSystems Issue Date: 2023-12-19 モバオクでのリアルタイムレコメンドシステムの紹介 Comment
DeNAでのRecSysのアーキテクチャ（バッチ、リアルタイム）が紹介されている。バッチではワークフローエンジンとしてVertex AI Pipelineが用いられている。リアルタイムになるとアーキテクチャが非常に複雑になっている。
複雑なアーキテクチャだが、Generative Recommendation使ったらもっとすっきりしそうだなーと思いつつ、レイテンシと運用コストの課題があるのでまだ実用段階じゃないよね、と思うなどした。
リアルタイム推薦によって、バッチで日毎の更新だった場合と比べ、入札率、クリック率、回遊率が大きく改善したのは面白い。
#Article #RecommenderSystems Issue Date: 2023-09-05 Lessons Learnt From Consolidating ML Models in a Large Scale Recommendation System Comment
推薦システムには様々なusecaseが存在しており、それらは別々に運用されることが多い。
- user-item recommendation
- item-item recommendation
- query-item recommendation
- category-item recommendation
このような運用はシステムの技術負債を増大させ、長期的に見るとメンテナンスコストが膨大なものとなってしまう。また、多くの推薦システムには共通化できる部分がある。
これら異なるusecaseの推薦システムをmulti-taskなモデルに統合し技術負債を軽減した経験が記述されている。
これが
このようなsingle multi-task modelを学習する構造に置き換わり、
その結果
- code量とデプロイの管理・メンテナンスコストの低減
- 保守性の向上
- 単一化されたコードベースが、緊急時の対応を容易にした
- あるユースケースで新たなfeatureを試し効果があった場合、他のユースケースに迅速に展開可能（同じパイプラインなので）
- ただし、multi taskの場合は特定のタスクに効果があったfeatureの導入により他タスクの性能が低下する懸念がある
- が、タスク間の関連性が高い場合（今回のような場合）、それは問題とならなかったことが記述されている
- 柔軟な設計の実現
- 複数のユースケースを一つのモデルに統合することは、複数のユースケースを組み込むための柔軟な設計が求められる
- これを実現したことにより、拡張性が増大した
- 結論
- このような統合がコードを簡略化し、イノベーションを加速させ、システムの保守性を向上させるシナリオが多くある
- ただし、ランキングの対象が異なっていたり、入力として活用する特徴量が大きく異なるモデル間で、このような統合の実施に適しているかは自明ではない
#Article #Tools #Infrastructure #Blog #Repository Issue Date: 2022-12-01 deploy-API-to-GCP Comment
FlaskAPIを（Flaskでなくても良い）Google Cloud Run上で、TerraFormで定義したインフラ環境でデプロイするためのリポジトリ
0. リポジトリをclone
1. Flaskアプリ作成
2. FlaskアプリをDocker化
3. TerraFormのStateを保存するためのCloudStorage作成
4. TerraFormのコード作成
5. GitHub Actionでデプロイ（CI/CD）
5によってmainブランチに対するプルリクが本番環境にデプロイされる。
Cloud Runについて
https://dev.classmethod.jp/articles/gc-cloud-run/
#Article #Infrastructure #Blog Issue Date: 2022-04-27 MLOps: 機械学習における継続的デリバリーと自動化のパイプライン, Google Comment
機械学習（ML）システムの継続的インテグレーション（CI）、継続的デリバリー（CD）、継続的トレーニング（CT）の実装と自動化
MLOpsのレベルを0~2で表現しており、各レベルごとに何が達成されるべきかが図解されている。
#Article #MachineLearning #Infrastructure #Blog Issue Date: 2021-06-18 NVIDIA TRITON INFERENCE SERVER, 2021 Comment
Nvidiaのオープンソースのinference server
モデルのデプロイや管理、スケーリング等を良い感じにしてくれるフレームワーク？