サンプルパイプライン : https://github.com/reproio/lab_sample_pipelines/tree/main/kfp 解説記事 : https://tech.repro.io/entry/2021/06/22/125113 ハンズオン資料 : https://gist…

この記事は自作している強化学習フレームワークの解説記事です。 この記事のコード場所:examples/kubernetes 続きです。 前回作成したk8s環境をGKEに作成します。 ※有料サービスを取り扱うので利用する場合は自己責任でお願いします 1:【強化学習】クラウドサービスを利用した分散強化学習(無料編) 2:【強化学習】クラウドサービスを利用した分散強化学習(kubernetes編) 3:ここ 全体イメージ(GKE) 今回作成する構成の全体イメージは以下です。 前回との違いは Trainer と Redis を同じPodに入れています。 Trainer と Queue は遅延をなるべく減らしたかったので同じ物理サーバにアサインされるように同じPodにいれました。 Google Kubernetes Engine (GKE) GKEはGoogle Cloud Platform(GCP
この記事は (1人で)基礎から学ぶ推薦システム Advent Calendar 2022の10日目の記事です。 前回までで、推薦システムを考える上でのさわりの部分は確認できたと思うので、ちょっとずつ実務っぽい話にシフトしていこうと思います。 実務で難しい推薦アルゴリズムを実装する前に、「チューニングとかはおいておいて、だいたいどれくらい効果が出るのかサッと試したい」という場面があったりします。 腰を据えてしっかりアルゴリズムを調整するならPythonでGPUを使って一つずつ実験をして…といった試行を繰り返すことになるかと思いますが、「安い!早い!うまい!」みたいなのが求められる状況では、Pythonを使うよりお手軽にサッと実装できると嬉しかったりします。 ということで、今回はSQLで推薦アルゴリズムを書いて、BQの計算能力でぶん殴るやりかたをやってみたいと思います。 問題設計 Datase
目次 はじめに 自己紹介 内容概要 基本設計 TCVのビジネスモデル 施策内容 システム構成 フェーズ1: とりあえずAutoMLを使ってみる フェーズ2: 目的変数を変える フェーズ3: BigQuery MLの導入による検証高速化 フェーズ4: 国別 フェーズ5: 回帰ではなく分類へ フェーズ6とその先へ おわりに はじめに 自己紹介 じげん開発Unitデータ分析基盤チームの伊崎です。 開発Unitは特定の事業部に所属しない全社横断組織です。 その中で、データ分析基盤チームは全社のデータ基盤の整備、データ利活用を担当しています。 私個人としては、大学で純粋数学を学んだ後、前職でエントリーレベルの機械学習エンジニアとして働きました。現職では半分データエンジニア、半分データサイエンティストとして働いています。 プライベートでKaggleに参加し、銅メダルを獲得した経験があります(最近は活動
1. はじめに 2. 並列学習環境を調べる 並列学習方法を調べる ネットワーク、コンピューティング周りを調べる 3. インフラ環境を構築する コンパクトプレースメントポリシーの作成 Compute Engine を起動する (Fast Socket と gVNIC を利用する) 4. まずはシングルノードで動かす 5. 次はマルチ環境で動かす w/ Docker リポジトリをクローン ssh/config を作成 authorized_keys を作成 hostfile を作成 Docker を build 6. つまずいたポイント 学習途中に出力したファイルを再利用するのでNFSが必要に NFSのリージョンを間違えて速度が出なかった 大量のGPUの調達はリソースを確保できないかもしれないので要サポート確認 コンパクトプレースメントポリシーは邪魔になりそうだった 7. 結果 8. まとめ
G-gen の佐々木です。当記事では Google Cloud(旧称 GCP)の機械学習サービスである Vertex AI の AutoML で作成した機械学習モデルを、サーバーレスなコンテナ実行基盤である Cloud Run にデプロイしていきます。 Vertex AI および Cloud Run とは? Vertex AI で作成したモデルのデプロイについて 当記事で Cloud Run にデプロイするモデル Vertex AI Model Registry からモデルをエクスポートする ローカルの Docker コンテナで予測を実行する Artifact Registry にモデルをアップロードする Cloud Run にモデルをデプロイする Cloud Run サービスに予測リクエストを送信する Vertex AI & Cloud Run Vertex AI および Cloud R
サーバレスプラットフォームである GCP Cloud Run で、Transformersのモデルを動かしてみました。 Transformersの汎用言語モデルを動作させるにはそれなりのスペックが必要になりますが、サーバレスと言うとメモリ等のリソースに厳しい制限があり大きなモデルを動かすようなことは難しい印象です。ですがCloud Runは結構メモリを積める1ので、実は普通に動かせてしまいます。 環境 Docker version 20.10.11, build dea9396 Docker Compose version v2.2.1 Google Cloud SDK 383.0.1 Cloud Run 第1世代 GCPのサービス内容は2022年5月14日時点のものになっています。 全体のソースコードは下記です。細かい依存関係などはこちらを参照してください。 実装 まずはCloud Ru
背景 どうやって異常を検知するか BigQuery MLでの異常検知 検知できるモデルの種類 共通設定 データの前準備 モデルの学習 モデルを元にスロット使用量が異常に増加していないか予測する 所感 背景 BigQueryはオンデマンドとフラットレート(定額料金)がある オンデマンドはスキャン量がお金に直結するため、INFORMATION_SCHEMA.JOBS_BY_*などを使ってクエリ警察をしている方も多いはず INFORMATION_SCHEMAに代表されるデータ管理に役に立つ現場のノウハウを最近会社のTech Blogに書いたので、そちらも見てね 一方で、フラットレートに関しては定額使いたい放題のプランであるため、オンデマンドよりはクエリ警察をしていない場合もある 見れるなら見たいが、どうしても支出に直結するオンデマンドを優先して見てしまいがち。工数も限られている が、あまりに自由
GAE の Task Queue (Push Queue) は Queue に入れられたタスクを全て一気に実行するのではなく、あらかじめ設定しておいた実行レートに従って、バックエンドの App Engine インスタンスにリクエストを投げてくれます。この実行レート制御のベースとなっているのが Token Bucket というアルゴリズムです。 今回はその Token Bucket アルゴリズムと、Task Queue の設定値である bucket_size rate max_concurrent_requests にどのような関連性があるか、まとめてみたいと思います。 Token Bucket アルゴリズム Token Bucket はネットワークに流れるトラフィックを一定量以下になるように調整するアルゴリズムであり、Amazon EBS の IOPS のバースト制御 や Amazon A
これなに? F81アドベントカレンダー二日目担当の長谷川です。 BQMLに新たに追加されたTRANSFORM句についての解説します。2019/12/2時点で、まだ日本語の公式ドキュメントが存在しないことから、記事にしようと思いました。なお、現時点ではまだこの機能はBetaです。英語の公式ドキュメントは存在するので、興味があれば、こちらも参考することをお勧めします。 今回の記事では、BigQuery(ML)の基本事項は一切説明しません。BQMLで使用できる関数などについては前記事を参照してください。 TRANSFORM句とは? 行いたい前処理をモデル構築時に定義し、予測、評価時に自動的に実行するためにしようするSQLの句(clause)です。 これにより、BQMLで作成するアルゴリズムとそれに伴う前処理を一体化させ、モデルを構築することができます。 前処理をモデルの中に集約し、隠蔽できるので
Kerasを使ったGoogle VisionサービスのDistillation(蒸留) Vision APIをVGGで蒸留する Vision APIの出力は実はタグの値を予想する問題でしかない 出力するベクトルが任意の次元に収まっており、値の範囲を持つ場合には、特定の活性化関数で近似できる 例えば、Vision APIはメジャーなタグに限定すれば、5000個程度のタグの予想問題であり、5000個程度であればVGGを改良したモデルで近似できることを示す (2017/11/08 データセットをスクリーニングして、問題のあるデータセット(一定の確率で特定のタグによってしまう)を排除したところ、だいぶ改善しました) 理論 去年の今頃、話題になっていたテクノロジーで、モデルのクローンが行えるとされているものである。 Google VISION APIなどの入出力がわかれば、特定のデータセットを用意す
はじめに 日本時間2020-06-17のリリースで、BigQuery MLにAutoML Tables、XGBoost、DNNが来ました。release-notes#June_16_2020 おさらいに、BigQuery MLで何ができるか再整理します。 追記: 日本時間2020-07-02のリリースで、BigQuery MLにARIMAも来ましたね。日本時間2020-06-28のリリースノートでエラーになってたのですが、リリース日がしれっと修正されてました。release-notes#July_01_2020 BigQuery MLでできること概要 BigQueryでStandard SQLを使って、機械学習モデルを訓練、推論できます。 データの移動を意識する必要がないため、開発スピードを向上と同時に、モデルの民主化を実現できます。 例えば、以下のようにして、1時間ほど待てば、AutoM
電通デジタルで機械学習エンジニアをしている今井です。 本記事では、BigQueryで傾向スコア分析を行うための方法について紹介します。 広告効果ってあったの?広告効果とは、広告に接触した場合と接触していない場合とのその後のコンバージョン(例えば、購入金額や継続期間など)の差である、と言えます。 しかしながら、同一ユーザーにおいて、広告に接触した場合と接触していない場合とを同時に観測することはできません。 これを反実仮想(counterfactual)と呼びます。 そこで提案されたのが平均処置効果(average treatment effect, ATE)です。 広告に接触したユーザー群(𝑤=1)と接触していないユーザー群(𝑤=0)とのその後のコンバージョン(𝑦 )の差を広告効果とするものです。 ここで、介入(広告に接触する)の有無以外の条件が公平になるようにユーザー郡が分かれていれ
slack にカギの開閉が通知される様子 玄関ドアのカギが開いた時、閉じたときに slack に通知が来る仕組みを作りました。今のところうまく運用できていて、外出後にカギが不安になって玄関まで戻ってくることがなくなりQoLがあがった感があります。 この仕組はドアの画像から閉じたサムターンを検出することで実現しています。Raspbeery Pi 3 で毎秒1画像くらいの処理ができるので、カギの通知としては問題ないレイテンシーです。 物体識別を可視化してみる 肝となる画像認識部分は GCP の AutoML Vision で学習させています。画像10枚で実用的な精度が出るDNNモデルが取得できる手軽さはなかなかすごいものがあります。 もちろんこんな簡単な画像認識なら、OpenCV を使ってテンプレートマッチングでも良いのでは? と思う向きもあるでしょう。実際その手法も試していて、頑張ってチュー
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? TL;DR AutoML TableがGoogle Cloud Next'19で発表されたよ もう触れるみたいなので、KaggleのHousePricePredictionで試してみたよ、手軽だったよ 一応LightGBMと比較してみたら、チューニングすれば良い成績を出せたよ 前置き Google Cloud Next'19でAutoMl Tableが発表されましたね〜 automl-tables LPがいつもすこ 早速使えるようなので(現在はβ版)、使ってみました。題材はKaggleから取ってきます。 Titanicでやろうとしてみた
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く