トップへ戻る
カレーが食べたい
www.yasuhisay.info
データを眺めるのが好き 収集している情報 実現方法 データから分かった知見(?) 今後 年末なので、今年買ってよかったものに引き続き、今年やってみてよかった習慣について書いてみたいと思います。 データを眺めるのが好き 昔からデータを眺めるのは好きだったんですが、今年の5月くらいから自分に関するデータをとにかく収集してみました。可視化することで何か有益な視点だったり、生活の改善点が見つかるのではないか、という目的です。色んなデータを集めまくった結果、以下のようなグラフができあがります。ちょっと画像が小さいですが、毎日の歩いた歩数や体重、気温、録画した番組名、自宅マシンの負荷状況などが載っています。 収集している情報 上の画像ではとりあえずBlogに上げれるようなデータしか見せていないですが、収集している情報としては以下のようなものがあります。使用しているスクリプトで公開できるものはgithu
確率論と統計学は俺がまとめるから、他の分野はお前らの仕事な。 確率論 Index of /HOME/higuchi/h18kogi 確率空間 生成されたσ-加法族 確率の基本的性質 確率変数とその分布 分布の例 分布関数 期待値、分散、モーメント 期待値の性質 独立確率変数列の極限定理 大数の弱法則(Weak Law of Large Numbers) 確率1でおこること 大数の強法則 中心極限定理 特性関数 Higuchi's Page Brown運動 Brown運動のモーメントの計算 連続性 Brown運動の構成:Gauss系として Brown運動に関する確率積分 空間L^2の元の確率積分 伊藤の公式(Ito formula) 日本女子大学理学部数物科学科の今野良彦先生のところにあった資料 最尤法とその計算アルゴリズム 収束のモード 大数の法則と中心極限定理 指数分布族モデルにおける最
サービスに機械学習技術(例えばSVM)を入れる際に、「この機械学習技術は本番サービスに投入しても大丈夫なものか?」を考える基準がまとまっていると人に説明するときに便利だなとふと思ったのでまとめてみました。散々言われ尽くされている話だとは思います。 前提 考慮に入る採用基準 予測精度 (コードの)メンテナンスの容易性 計算オーダー 学習時 予測時 挙動のコントロールのしやすさ/予測説明性の容易さ チューニングの必要性 その他 まとめ 前提 機械学習がプロダクトの主要な武器になる(例えば最近話題になっているGoogle翻訳におけるNMT)ものではなく、サービスにデータがまずあり、機械学習でデータを活用することにより、そのサービスを支えていくようなものを前提に考えています(例えばCGMサービスのスパム判定)。また、投稿内容は私個人の意見であり、所属組織を代表するものではありませんとお断りしておき
社内の機械学習勉強会で最近話題になった機械学習関連のエントリを取り上げているのですが、ここ一ヶ月ではGoogle Neural Machine Translation(GNMT)がとても話題になっていました。GNMTで使われているEncoder-Decoderやattentionのような仕組みを直近で使う予定は特にはないですが、機械学習を使うエンジニアとして知っておいて損はないし、技術的に何が変わったことにより何ができるようになって、何はまだできないのかを知ろう、というのが目的です。技術的な項目は興味ない人も多そうなので、最後に持っていきました。 Google Neural Machine Translation(GNMT)の最近の進化について できるようになったこと 定量的な評価 まだまだ難しいこと 技術的な詳細 Encoder-decoder Attention based encod
先週末、はてな社内の勉強会で構造学習、特に実装が簡単な構造化パーセプトロンについて発表しました。発表資料と説明用にサンプルで書いたPerlの品詞タグ付けのコードへのリンクを張っておきます。 今日からできる構造学習(主に構造化パーセプトロンについて) from syou6162 structured_perceptron/structured_perceptron.pl at master · syou6162/structured_perceptron 「えっ、Perlかよ」という人がいるといけないので、Clojureで構造化パーセプトロンを使った係り受け解析のサンプルコードへのリンクも張っておきます(2種類あります)。PerlもClojureもあれば8割くらいの人はカバーできそうなので、安心ですね。 syou6162/simple_shift_reduce_parsing syou616
FAQサイト、サポート問い合わせをせずとも自分で疑問を解決できて便利ですよね。でも、検索した単語が一件もヒットしないと、ちょっとガッカリしてしまします。そういったガッカリを減らすために、簡単なデータ分析を使ってFAQサイトを継続的に改善する話を書いてみます。 ...というのも、自分が仕事で関わっているMackerelでは最近FAQをリニューアルしたからなのでした。 MackerelのFAQではZendesk Guideを利用していますが、Zendesk Guideは便利なAPIが用意されているので、それと既存のデータ基盤を組み合わせて改善していく形です。 FAQサイト内の検索語を列挙する まず、FAQサイト内でどういった単語が検索されているのかを列挙します。Google Tag Manager経由でFirebase Analyticsにデータを飛ばすと閲覧状況が分かりますが、そのログをBi
最近、社内勉強会で機械学習についてエンジニアに説明する機会があり、その際にKaggleについても説明しました。一方で うーん、「Kaggler はパラメータチューニングやアンサンブル等の自明でインクリメンタルな改善『しか』できない」というような誤解はどうやって解いていけばいいんだろう。— im132nd (@im132nd) 2018年4月4日 という話もあり、(特にデータサイエンティスト以外の職種の人が)Kaggleをやる意義/メリットについてまとめてみました。ガッと勢いで書いたので、項目に結構被りがあります。なお、書いている本人はKaggleほぼ初心者であまり説得力がないです。Kaggle Masterの人がもっといいエントリを書いてくれるのを期待しています、議論の叩き台エントリです!! Kaggleをやる意義/メリット 様々なデータセットを触ることができる kernelでデータ分析の
週末KagglerとしてavazuのCTR予測コンペに参加しました。Kaggleは機械学習版のISUCONだと思ってもらえばよいです。コンペ自体は終わっているので、late submiteであまり意味はないかもしれません、練習です。leaderboard上で上位10%以内に行けたので、そこまでの試行錯誤をメモしておきます。謎ノウハウ(?)を持っているガチ勢じゃないと上位に行けないものかと思っていましたが、基本に忠実にやればこれくらいの順位(上位7.6%)に行けましたし、他の人の工夫を垣間見えるという意味でも現場の機械学習やり始めたエンジニアにお薦めできそうでした。 参加の動機 目標感: 頑張りすぎずに上位10%以内に入る 試行錯誤 AthenaとRedashによる探索的データ解析 ベンチマークをまず超える 線形分類器でシンプルな特徴量 時系列要素を忘れていて過学習発生 特徴量エンジニアリン
Twitterでは先に言っていましたが、現職のはてなを3月末で退職します。3/19が最終出社日でした。はてなでの思い出はこちらに書きました。 そのため、転職活動をしたわけですが、コロナ禍での転職活動は平常時と異なる部分も結構ありました。また、データエンジニアとしての転職は初めての経験でした。誰かの参考になるかもしれないので、私が考えたことや感じたことをメモ書きとして残しておきます。 在宅勤務と就業可能な地域 Web上でのアウトプット データエンジニアという職種の多様性 転職にあたって重視したこと 魅力に感じた点 当然、不安もある 在宅勤務と就業可能な地域 カジュアル面談させてもらった企業さんは、ほぼ在宅勤務に移行済みだった 隔週や月一で物理出社という会社も半々くらい? 緊急自体宣言が出ていない時期(夏〜秋)にカジュアル面談させてもらったので、今は状況が違うかも カジュアル面談、採用面談もz
社内で機械学習の案件があった際に、機械学習の経験者しか担当できないと後々の引き継ぎで問題が起こりがちです。これを防ぐために、機械学習に興味があり、これまで機械学習を経験したことがないエンジニアにも担当できる体制を整えられることが望ましいです。しかし、機械学習のことに詳しく知らないディレクターやエンジニアにとっては、どのような機械学習の理解段階ならばタスクを任せられるかの判断をするのはなかなか困難です。そこで、このエントリでは機械学習を実タスクでやるまでに乗り越えるべき壁だと私が思っているものについて説明します。 第一の壁: 綺麗なデータで機械学習の問題を解ける 講義で扱われるような綺麗なデータを扱える 行列形式になっていて、欠損値や異常値もない 上記のデータを回帰や分類問題として解くことができる 実際に解く際にはライブラリを使って解いてよい 手法を評価する上で何を行なえばよいか(Preci
書いてたらLaTeX以外のことも入ってきたけど、気にしない。 数式だけで20枚を越えてきたので、そろそろ整理の方法を考えておかないと崩壊しだす時期です。ということでなんかまとめておく。ながーい文章をLaTeXで書くのは初めてなので、間違っているところとかあるかもですが、ご愛嬌。。。 YaTeX&RefTexを使う書かないといけない量が膨大になってくるので、書くためのツールを洗練させる必要があります。まあ、自分の好きなエディタを磨げばいいと思うんですが、僕はEmacs使いなのでYaTeXを使います。もうとにかくYaTeXの補完なしでは数式が入った文章は書けなくなりました。 10枚程度ならYaTeXだけでもいいのですが、長くなってくるとRefTexの力が必要になってきます。RefTefについては、tokyo-emacsでのmishoの発表がとても参考になります。目次みたいなのを下のように表示で
そろそろ前職を退職してから、はてなで働き始めて5年(!)が経とうとしている。5年も働いていると、昔何をやっていたか、その当時どういう気持ちで働いていたかを忘れてしまう。備忘録っぽく書き残しておこう。ポエムです、長いです、大体自分向けに書いてる。 NTT CS研 => 株式会社はてな チーム開発への適応 インフラ苦手意識の克服 教師なし機械学習の本番環境での運用 データ基盤とCustomer Reliability Engineerへの挑戦 今後はデータエンジニアリング NTT CS研 => 株式会社はてな 基礎研究職からWebアプリケーションエンジニアへの転職だった。ログを残しておくと、こういう時に振り返れて便利。 NTT CS研を退職して、株式会社はてなに入社しました - yasuhisa's blog 割と珍しい(?)転職ではあったかもしれないが、機械学習や自然言語処理はアルゴリズム単
Amazon Elasticsearch Serviceに引き続き、AWS Lambdaに入門しました。Lambdaを使って、Amazon Elasticsearch Serviceで特定の単語を検索をさせてslackに書き込んでくれるbot君を練習台でやってみました。 やりたいこと 準備: 適切なポリシーを設定する Goで書いたプログラムをapexを使いAWS Lambdaに転送 Lambda上からAmazon Elasticsearch Serviceで検索 MackerelのAWS連携でLambdaを監視 まとめ やりたいこと AWS強化月間(?)ということでAmazon Elasticsearch Serviceに入門していました。 自宅のElasticsearchとKibanaをAmazon Elasticsearch Serviceに引越し - yasuhisa’s blog
大学サーバーは卒業するとあれになってしまうので、どっか契約することにしました。さくらレンタルサーバーのスタンダードでは、シェルログインができるので、これにしました。 最初に mkdir ~/local をやっておく。 vimviは入っているけど、vimは入っていなかった。 さくらインターネットのレンタルサーバーにvimをインストールしてみる - SIGSEGV ftp ftp://ftp.vim.org/pub/vim/unix/vim-7.0.tar.bz2 tar xvjf vim-7.0.tar.bz2 cd vim70/ ./configure --prefix=$HOME/local make make install .vimrc あんまり意味分かってないでコピペ(ry。 set number set compatible set tabstop=2 set shiftwidt
エイプリルフールも一段落したので、退職&入社エントリを書こうと思います。 これまで 3/31付けで前職のNTT CS研を退職しました。CS研には(インターン期間も含め)4年間お世話になりました。 CS研はとても研究する上でよい環境 CS研は研究をする上でかなりよい環境であったと思っていて 世界で活躍しているトップの研究者がわらわらいて、日々ディスカッションできる (全くないわけではないですが)雑用が少なく、研究に集中できる 研究をする上で必要なリソース(計算機、データなど)が十分にある 足りないものやデータ等を新しく作りたい場合は、上長をちゃんと説得すればお金をかけて作ることができる 自然言語処理の研究をする上でかなり重要 などなど、とても研究しやすい環境です。AAAIやEMNLP、CoNLLなどに行くことができたのもこうしたCS研の環境なしではありえなかったと思います。ここで4年間働けた
3~4年前はモブプロにめちゃくちゃ苦手意識があったんだけど、最近はなぜか(?)モブプロを推進していく旗振りをしている。モブプロの取り組み自体については今度会社のTech Blogに書く予定だけど、このエントリでは自分の心境の変化にフォーカスを当てる。人間、数年すると割と変わるもんだなぁと思って面白かったので、記録に残しておく。 モブプロが苦手だった頃 なぜモブプロしようとなったか 今はどうモブプロしているか 所感 モブプロが苦手だった頃 前職の開発チームにいた頃(3年前くらい)で、状況はこんな感じ。 7~8人くらいの規模の開発チーム 京都と東京でそれぞれメンバーは分かれているが、まだ物理出社している時期だったので、大きなディスプレイに写された自分の画面をみんなが見るスタイル 時間は60~90分くらいだったかな タイピストはガンガン交代するスタイルではなく、1回を1~2人のタイピストで回して
機械学習の中でもマイナーなテーマであろう異常検知がテーマの勉強会、異常検知ナイトというイベントでLTの登壇をしてきました。マイナーテーマなのに300人以上が集まる東京怖い。 3ページしかないですが、発表資料も置いておきます(LTのレギュレーションで3ページ5分)。 異常検知ナイト LT登壇資料 はてな id:syou6162 from syou6162 LTのテーマは、現在自分がどんなデータで異常検知をやっているか、どういう困り事があるかを発表してプロの方からアドバイスをもらおうというものです。Mackerelで今まさに異常検知機能の開発をしていて、時系列周りのモデルのハイパーパラメータを開発データでチューニンングしたいけれども、そもそも異常データを含む開発データって手に入らないことが多くてどう対応していくのがよいのか?という質問をさせてもらいました。プロからのアドバイスは動画で見れるので
Go言語を書く際、成果物がシングルバイナリになるのは便利です。deployするときや他人に使ってもらうときに、それだけ渡せば使ってもらえるので。cliツールやapiサーバーを書くときにはこの方式で困っていなかったのですが、いわゆるWebアプリをGo言語で書くときのベストプラックティスが分からなかったのでエントリにしておきます。 前提 Go言語側は重厚なフレームワークは特に使わない net/httpやhtml/templateといった標準ライブラリを使う フロント側はVue.js シングルバイナリを作るまでの過程 以下の過程をMakefileに書いてmake buildとやってシングルバイナリを作っていました。 webpackでJavaScript関係をbundle.jsという感じで一つのファイルにまとめる go-assets-builderを使って、index.htmlやbundle.js
8/2に京都に到着、8/3からインターンが開始されたはてなインターンですが無事全日程終了しました。後半に進めるのが決まったのが二週間前だとか信じられません。 というわけで興奮覚めないままの感覚で書いていこうと思います*1。 インターン後半戦 インターンの前半戦は毎日出される課題を倒していくという感じの日々でしたが、後半は実際にプロダクトの作成、改善、追加などを行ないました。チームも前半とは違って再配置となり、僕はid:mi_kattun、id:mroriiと一緒にid:onishiさん、id:antipopさん、id:ninjinkunさんの運用チームでやらせてもらいました。 このチームにて コメントスパム コメント日記 の撲滅を目指してスパムフィルタの作成をしました。以前は結構簡単なルールでフィルタリングしていたのですが、最近とにかく(本当に!本当に本当に!!本当に本当に本当に!!!)ス
現在仕事で作っている異常検知システムについてPyCon mini Osakaで登壇してきました。異常検知というマイナーなトピックですが、多くの人に聞いてもらえてよかったです。 #pyconjp #pyconosaka 「Pythonを用いた異常検知システム構築の裏側」 吉田康久さんです！ たしかはてなの人だったはず。 pic.twitter.com/hRacSgV59D— PyCon mini Osaka (@OsakaPyConMini) 2018年5月19日 はい、はてなのMackerelチームの中の人です。 機械学習の人からすると「なんだただの混合ガウス分布か」と思われるかもしれませんが、異常検知のシステムを実際に作ろうとすると考えることが色々あります。今回の発表では ユーザーのどのような要望から異常検知機能を作るに至ったか 異常検知とはそもそも何か、どういった問題設定か 異常検知手
パラメータの推定、でもその前に optimize関数について 補足 パラメータの推定 ベルヌーイ分布 定式化(尤度関数) 尤度関数の実装 尤度関数の最適化(パラメータ推定) 正規分布におけるパラメータ推定 まとめ パラメータの推定、でもその前に統計におけるパラメータの推定というのは大体最適化問題に帰着します。「なんとか関数を(最大|最小)にするようなパラーメータほにゃららを求めたい」とまあこんな感じで。というわけで、パラメータ推定は置いておいて、Rで最大化問題、最小化問題をどう解くかというところを最初にやってみようと思います。最適化問題は離散最適と連続のほうの最適に分けられますが、ここでは連続についての最適化問題について考えることにします。 optimize関数について Rにおける最適化をするための関数はoptim関数、optimize関数があります(他にもnlsなどありますが、とりあえず
2022-02-23 使われていないにも関わらず定期実行されてしまっているクエリ(in BigQuery)を検知するツールを作りました BigQuery TL;DR 背景 実装時の問題点 作った TL;DR データ活用が進んでくると、使われていないにも関わらず定期実行されているクエリが増えてきます 無駄な利用料金、スロットを使っていることになるので、こういったクエリはなるべく減らしていきたいです こうしたク… 2022-02-23 SQLは3値論理、NULLの扱いに気を付けよう SQL 基本的なことだけど、久しぶりにハマって2時間くらい溶かしてしまったので、自分用メモ。大体のことは以下の本に書いてある。 達人に学ぶSQL徹底指南書 第2版 初級者で終わりたくないあなたへ作者:ミック翔泳社Amazon INとNULL 普通のプログラミング言語であ… 2022-02-20 BigQueryのビ
ふと思いたったので書く。2016年は自然言語研究者からWeb系エンジニアになったということで、今振り返ってもキャッチアップで精一杯だったなーと思うが、2017年は去年よりは慣れたこともあり、もう少し自分にとって新しいことに取り組めたかなーと思う。といっても、XXXやり始めたという内容のほとんどが仕事で必要だったという理由なので、Mackerelチームで働くための基礎体力が本当になかったんだなと改めて痛感している(なぜはてなに入社できたのか謎)。飽きる暇もなく勉強の毎日です。来年はもう少し狭く深く掘り進めていきたいかな。 Go言語やり始めた Pythonやり始めた 異常検知やり始めた 深層学習やり始めた AWSやり始めた Docker&Ansible始めた IDEに魂を売った Go言語やり始めた 仕事でGo言語をやる必要があって勉強し始めたのが今年の初めだった。A Tour of Goを最初
自然言語の誤りを指摘してくれるRedPenを手元で使えるようにしてみました、という記事です。気が向いたので、色々書いてみました。 エンジニアであっても意外と文書を書いたり見たりする機会が多い 自然言語も機械が勝手に間違いを指摘して欲しい 自然言語もルールで分かることは機械(RedPen)に指摘してもらう 指摘例 EmacsからRedPenを使う まとめ エンジニアであっても意外と文書を書いたり見たりする機会が多い エンジニアとしてはてなに入社後、コードレビューをする機会はもちろん多いですが、意外と自然言語(私の場合は日本語、英語がメイン)のレビューをする機会も多いことに気が付きました。他人の書いた文書に対するレビューに限らず、自分の書いた文書に対するレビューも含みます。 告知文のチェック mackerelでは毎週告知をブログに書くので、エンジニアも内容をレビューする こういうやつ: mkr
このエントリはDeep Learning Advent Calendar 2016 5日目のエントリです。EMNLP2016に出ていたHow Transferable are Neural Networks in NLP Applications?を読んだので、それについて書きます。 [1603.06111] How Transferable are Neural Networks in NLP Applications? モチベーション 画像方面では、あるタスク(source side)で学習させた深層学習の結果を、別データセット(target side)でソフトマックス層だけ再学習させる転移学習(Transfer Learning)がうまくいっていると報告されています。 [1311.2901] Visualizing and Understanding Convolutional Ne
インフラやミドルウェアにとにかく苦手意識があるが、仕事的にいつまでもそう言ってられない。そこで、最悪全部ぶっ壊れても大丈夫な砂場を作り、そこを土台に活動をするというのを2018年の目標に設定していた。 結構な時間をかけたこともあり、それなりの砂場と活動ができて、自分としても勉強になってよかった点が多かったので振り返りを書きます。一個一個ちゃんとエントリ書いていたので、振り返りが楽で助かった。 完成系はML Newsだけど、2018年1月時点では そもそもWebアプリですらなくCLIアプリだった データの管理もデータベースではなくテキストファイル という素朴な作りだった。 インフラ編 最初はCLIアプリをWebアプリにする活動をやったが、その後はAWS上にインフラ部分の構築を進めた。 次に一台のEC2をAWSコンソールから立てて、sshでログインしてyumコマンドを打って...という10年前
ここ最近、チーム内でSQLのレクチャー会をやっています。世間的にはプランナーの人や営業の方がSQLを書くのもそれほど珍しいことではなくなってきていると思いますが、チーム内ではまだまだ一般的ではないです。なんとかしていきたい。 SQLレクチャー会の目的はこんな感じです。 チーム内のSQL / 分析力の底上げ データの民主化的なやつ データライフサイクルの改善 集計側であれこれ無理に頑張るより、入力データを集計側に合わせてもらうほうが圧倒的に省力化されることが多い データの入力側と集計側の意識を合わせることで、チームのデータ分析のしやすさを高めていきたい 毎月、毎期末作っているスプレッドシートの自動化 手間を減らしたり、手作業によるミスを減らしたり このエントリをきっかけに「うちでも似たことやってるけど、この取り組みをやってみたらさらにうまくいったよ」といったことが知れるとうれしいです。 背景
LINE福岡で行なわれたHacker Tackleにて登壇してきました。 発表内容は(1)機械学習を使ったサービス開発の難しい点について整理し(2)その難しさを乗り越えていくためにはてながどのような取り組みを行なっているかについてでした。一口に機械学習を使ったサービス開発といっても、古典的な問題設定でどうやればいいか比較的クリアに見えているものと、R&D要素が強くどう取り組んでよいか分からないものではよい取り組み方も異なってきます。そこで、今回の発表では古典的な問題設定(テキスト分類)であるBrandSafe はてなのリニューアル、R&D要素の強いMackerelの異常検知、それぞれに対し技術的/組織的にどのような取り組みを行なったかについて話させてもらいました。 はてなにおける機械学習の取り組み from syou6162 登壇時間は30分で割と話すことも多かったので、当初話す予定だった
というのをチームで議論する機会があったので、書いてみます。「うちではこうしている」とか「ここはこっちのほうがいいんじゃない?」とかあったらコメントで教えてください。 背景 / 前提 データウェアハウスのテーブルを社内に広く提供したい 初期の提供時期が過ぎてしばらくすると、要望を元にスキーマの変更や集計ロジックの変更が入る (事前にレビューはもちろんするが)SQLのミスなどで以前のバージョンに戻したいといったことがありえる 他の部門では新しいバージョンをすでに使っていて、気軽に戻せないこともある データウェアハウスのバージョンを場面に応じて複数提供できると都合がよい 一方で、大多数のデータウェアハウスのユーザーは最新バージョンの利用だけでよいはず SSOT(Single Source of Truth)になっていて欲しいわけなので... 複数バージョン見えていると「どのバージョンを使えばいい
次のページ
このページを最初にブックマークしてみませんか？
『yasuhisa's blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
