EuRuKo2018に行ってきました - komagataのブログ
行ってきました。 ウィーンのオシャレさにアウェイ感を感じていましたが、おなじみのHerokuやCookpadのブースが並び、オマエラが大挙してきてすぐにホーム感満載となりました。 Matzのお話はRubyKaigi2018と概ね同じでしたが、AIに関して少し踏み込んだ感じでした。 RubyKaigiとの違いを感じた点はいくつかありました。 1 発表のスケジュールがゆったり 1セッション30分で、2セッションやったら休憩。このペースは自分としては集中力に余裕ができてよかったです。 2 発表中にPC見てる人が少ない 大体RubyKaigiでは95%ぐらいPCみてるけどEurukoでは5%ぐらいしかPC見てる人いない感じがしました。発表をしっかり聞いてる感じがしてこれはいいなと思った。そもそも聞きたくない人は出ていってるのかも。 3 発表の内容がマイルド これはRubyKaigiだけが異常だと思
機械学習の理論と実装はどう学んでいくと良いのだろうか
TL;DR 機械学習エンジニアは理論と実装の両方が求められる場合が少なくない この二つは割と異なる学びの過程がある気がしているが、自分を例にとってそれを考えてみる かなり強引に言うなら、理論は要素を積み重ねて全体を理解するやり方で、実装は全体から必要な要素を削り出していくやり方、な気がする 自分は実装に関してはどうトレーニングを積んでいくのが良いかいまいち分かっていない 知人と話していてタイトルにあるような話題になった。 機械学習が流行るようになって、これまではサービスを開発するような仕事ではそこまで要求されなかったであろう、数学的な理論とプログラミングによる実装の両方を兼ね備えることの重要性が増している。 これは自分が興味あるような機械学習エンジニアの仕事において、という前提条件の下での話だ。 そんなのなくても仕事ができるとかもっと大事なことがあるとか、意見は色々あるかもしれないけど、こ
確率統計－機械学習その前に v2.0
確率統計の勉強会資料を大幅に改定しました。数式を最小限にし、統計分析のためのトピックを総覧的に資料化しています。 2021/11/20 内容や記載を拡充しました（合わせて SpeakerDeckに移動しました） https://speakerdeck.com/hidekatsu_izuno/que-lu-tong-ji-ji-jie-xue-xi-sofalseqian-ni
ユーザー行動が成す力学系の実現と それを用いた推薦システムを支えるAWS アーキテクチャ - Speaker Deck
All slide content and descriptions are owned by their creators.
大規模データのクラスタリングには Mini Batch K-Means を使うべきという話 | 10001 ideas
タイトルの通りですが、大規模データをクラスタリングする際には単純なK-Means法ではなく、Mini Batch K-Means法を使うべきという話です。 とある大規模データ（150万件ほどの文章ベクトル）をクラスタリングしたいことがあったのですが、単純にScikit-learnのK-Means法に投げてクラスタリングを走らせていたところ、数時間経っても一向に終わる気配がありませんでした。色々と調べていると、大規模データのクラスタリングにはMini Batch K-Means法を使うべきという記述を見つけました。公式ドキュメントによると、大体1万件を超えるデータをクラスタリングする場合にはMini Batch K-Meansを使うべきとのことです。 APIとしては単純にKMeansをMiniBatchKMeansに置き換えれば動きます。理論的な背景としては、論文 “Web Scale K-
数えきれないほどの分類を行うExtreme Classification - Technical Hedgehog
本記事では分類タスクの一種であるExtreme Classificationの代表的な手法と特徴を紹介します。機械学習においてアヤメの分類など10数個までのラベルやクラスへの分類タスクはチュートリアルなどで多く取り上げられています。 一方で商品をカテゴリに分類したい場合など大量のラベルやクラスで分類したい場合、既存手法では計算量が膨大になるなど様々な問題に直面します。そこで大量のラベルやクラスを用いて分類を行うタスクをExtreme Classificationと呼び研究が進められています。 Extreme Classificationとは？ Extreme Classificationは10万〜100万にも及ぶ膨大なラベルやクラスを用いて対象を分類するタスクです。このタスクは少なくとも10年以上前から研究が行われており、学会のワークショップなどでも取り組まれています。直近ではNIPS E
メジャーリーグがAWSの機械学習技術を用いて試合中のさまざまな情報をリアルタイム放送に反映へ
by Brandon Mowinkel アメリカのメジャーリーグ(MLB)がAmazon Web Services(AWS)との連携を深めて、機械学習技術を用いてセイバーメトリクス分析情報などをリアルタイムにテレビ放送やネットに統合していくことを発表しました。 MLB, Amazon Web Services continue partnership https://www.mlb.com/news/mlb-amazon-web-services-continue-partnership/c-286242678 Amazon, MLB add machine-learned stats to cloud deal https://www.reuters.com/article/us-amazon-com-mlb/amazon-mlb-add-machine-learned-stats-to
カテゴリカル変数のEncoding手法について - ysaz (ImanazaS) blog
Structured Data（構造化データ）の下処理をおこなう際に避けて通れないのがFeature Engineering（特徴量エンジニアリング）。 特に悩ましいのがカテゴリ変数の扱いで、どのように扱えば良いか困ることが多く、また、使った手法もすぐに忘れてしまいがちなので、自分なりに整理して記事にまとめておきたいというのが趣旨。 １．よく使われる手法 ２．次元を増やさない場合 Label Encoding Count Encoding LabelCount (Count Rank) Encoding Target Encoding ３．次元を増やす場合 One hot encoding Entity Embedding ４．参考記事 １．よく使われる手法 まずはよく用いられる定番の手法から。次元を増やすかどうかで大まかに次の２つに分類できる。 ・次元を増やさない場合（Label, Co
機械学習・深層学習の基礎体力測定① - Yusuke Sugomori's Blog
久しぶりのブログ更新です。今回は、ますます活発に研究されている深層学習分野が、その活発さ故に引き起こされてしまっている下記の問題をテーマに、記事を書いていきたいと思います。 「簡単に深層学習の手法が実装できるライブラリが出てきたことによって、実装はできるけれど実は数式部分、すなわち理論背景についてはよく知らない場合が多い」 これは個人的には非常にもったいないと思っていて、「機械学習に対する体系的な理解」ができていないことに端を発する問題だと考えています。 「体系的な理解」なんて書くとエラそうに聞こえてしまうかもしれませんが、ここで書いていくものは、「こうやって理解すると、少しはスッキリするんじゃない？」くらいの提案として受け取ってもらえれば幸いです。タイトルで「基礎体力」と書いたのもそのためです。 じゃあ具体的には何を理解すればいいの？となるわけですが、ここでひとつ、簡単な問題を考えてみま
Spark で機械学習を社内データに適用してみた - astamuse Lab
山縣です。夏休みの宿題のようにブログの当番が回ってきました。 機械学習が非常に注目を浴びている今日このごろですが、私もデータ関連を扱うソフトエンジニアの端くれとして機械学習について学んだり、機械学習のアルゴリズムを時々試したりしています。 機械学習は面白いとは思うのですが、いざ実際に業務に適用しようとするとなかなか難しいなあと感じることもあります。ちょっと試してみると思ったような精度が出なかったり、機械学習でできないかというような要望と、機械学習できそうなこと（自分自身の知識的な問題も含む）に隔たりがある気がします。 今回は比較的扱いやすそうな課題があったので、ものは試しに機械学習でやってみました的なところを書いてみたいと思います。 また機械学習のプラットフォームとして Spark を使っているのでそのあたりについても書いてみました。 残念ながら機械学習や統計などについての十分な知識や経験
PostgreSQLとcupyを繋ぐ～機械学習基盤としてのPG-Stromその①～ - KaiGaiの俺メモ
世間の機械学習屋さんは、機械学習・統計解析のライブラリにデータを食わせる時に、どうやってデータを入力しているのだろうか？ 話を聞くに、データを一度CSV形式に落とし込んで、それをPythonスクリプトで読み込むというパターンが多いようではある。 ただ、ある程度大量のデータセットをCSVファイルで扱うようになると、いくつか問題点が露わになってくる。 解析すべきデータセットを切り替えるたびに異なるCSVファイルを用意する事になり、ファイルの取り回しが煩雑である。 前処理をかけた後のCSVファイルがまたできてしまい、ファイルの取り回しが更に煩雑になってくる。 最終的にCSVファイルの所在が誰にも分からなくなってしまい、機械学習・統計解析の元になったファイルが散逸してしまう。 そもそも、GB単位のフラットファイルをシェル上でコピーしたり読み込ませたりするのはそれなりに時間を要する処理である。 デー
論文を読む能力 - なーんだ、ただの水たまりじゃないか
去年の4月くらいから、論文を読む事が出来るようになった、という気がしている。 もう一年以上前の話なんだが。なんとなくその事をブログに書いてなかったな、と思ったので、ここに書いておく。 論文を読む、というのは、みんなやっている、と主張はするものだ。 ちゃんと理解できているかは怪しいものだが、 一方でその区別もそんなにはっきりとはしていないので、 誰が論文は読めて誰が読めてないのかもよく分からない。 論文の分野にもよるからますます一概には言えない。 ただ、機械学習の仕事では論文を読むのは重要な日常業務の一つで、 この能力が明らかに不足している人というのはかなり居る。 明確な境界を決めるのは無理だけれど、明らかに足りてない場合は明白に分かるし、皆が言う程はこの能力は簡単な物では無い。 実際、自分も2015年ころには、この論文を読む能力が低くて困っていた。 2017年の4月頃には読めるようになった
Argo によるコンテナネイティブなデータパイプラインのワークフロー管理 - LIVESENSE Data Analytics Blog
データプラットフォームグループの野本です。主に機械学習基盤の構築やそれにまつわるアプリケーションの開発をしています。 以前までの記事で現在 Kubernetes を利用して機械学習基盤の構築を進めているという紹介をしましたが、機械学習システムに付きものだと思われるワークフローのジョブ管理に Argo という Kubernetes 上で動作するワークフローエンジンを導入し使いはじめまてみました。まだ色々試している段階でもあるのですが現状でどんな感じで使っているのか紹介してみようと思います。 ワークフローエンジンの選定に関して 現在機械学習基盤では先に紹介した以前の記事 や マルチコンテナ構成による機械学習アルゴリズムとアプリケーションの疎結合化 のような形で機械学習システムの構築を進めています。特に後者の具体例のように各アプリケーションを疎結合にうまく動かせるように出来るのが理想です。 これ
Google Cloud Dataflow で Google BigQuery へストリーミング ETL するの巻 - おくみん公式ブログ
okumin.com のアクセスログを Google BigQuery で分析するために、ETL パイプラインを構築しました。 Apache Beam(Scio) + Google Cloud Dataflow を用いてログの加工及び BigQuery へのストリーミングインサートを行うという構成です。 この記事ではその全体像と個々のコンポーネントの簡単な説明を行います。 アーキテクチャ 次の流れで ETL を行っています。 Google Container Engine(GKE) 上に配置した Nginx コンテナのログを Stackdriver Logging へ集約 Stackdriver Logging のログを Google Cloud Pub/Sub のトピック「okumin-com-access-log-raw-v1」へエクスポート Google Cloud Dataflow
【k8s合宿】 Kubernetesのログ分析環境を作る - Uzabase for Engineers
こんにちは、SPEEDAのSREチームでエンジニアをしている阿南です。SPEEDAのSREチームでは、昨年末kubernetesについて理解を深めるために合宿を行いました。やり方はA〜Cの３チームに分けて、それぞれのチームでkubernetesに関することを調査、構築するという形式で、今回はAチームが実際にやってみた内容についてブログを書きたいと思います。（それぞれのチームでかなりボリュームがあるので、複数回に渡って連載的な形でお届けしたいと思います。） Aチームでは、kubernetesを本番環境に投入するにあたり、ログ収集周りをあまり調査できてないなと感じ、GCP上に環境を作ってみることにしました。 構築する環境 構築手順 クラスター構築 wordpress + MySQL構築 Fluentdイメージの作成 ConfigMap設定 DaemonSet設定 まとめ お知らせ 構築する環境
kubernetesでgRPCするときにenvoy挟んでみたよ - Qiita
kubernetes(今回はGKE内)でgRPCの通信を場合にぶち当たる問題として、ロードバランシングの問題があります。 gRPCの通信は永続化されるので、そのままの状態で使うとバックエンドにあるサービスがスケールしても分散されないということになります。 具体例 上記のような構成でhoge-gateway(4pod)からhoge-app(10pod)に向けてコネクションプーリングが1で通信をする場合、hoge-appが最大4podしか使われない状態になります。 下記がその状態です。 GKE Container - CPU usage for hoge-app GKE Container - CPU usage for hoge-gateway 解決方法 これを解決する手段としてgRPCのclientLoadbalancingを使う方法がありますが、clientに依存する方法はあまりスマート
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
t-distributed Stochastic Neighbor Embedding (t-SNE)
Clovaにおける機械学習モジュールの配信＆運用基盤の紹介
