Deep LearningをKerasで可視化したい - GMOインターネットグループ グループ研究開発本部
こんにちは。次世代システム研究室のJK (男)です。 突然ですが書籍の「ゼロから作るDeep Learning」読みましたか？基礎からクリアに説明されていて、個人的にはとても面白かったです。これまでLSTM, 強化学習の記事を書いてきましたが、今回はこの本にならってDeep Learningの基礎の「ちょい深」理解を目指し、Deep Learningの可視化に焦点をあてたいと思います。 ちなみに今回の内容のcodeは、ここに上げておきました。 0. 可視化のモチベーション 最近のDeep Learningのフレームワークは充実していて、簡単に動かせるようになりましたね。でも動かせたけど理解した気がしない、って人も多いのではないでしょうか？その理由の一つが、Deep Learningがブラックボックス化していることだと思います。簡単に動かせることの副作用だと思いますが、インプットデータと教師
Digdag 入門 - GMOインターネットグループ グループ研究開発本部
D. M. です。レガシーの crontab が肥大化して困っています。今日はそのリプレイス候補である Digdag を使ってみた話です。 やりたいこと crontab は Linux のスケジューラの仕組みで定期バッチの実行用途でよく利用されますが低機能です。順序の依存関係やアラートは毎回独自に作りこまなければいけません。そのため近年は代替スケジューラを利用するケースが多いです。その候補のひとつである Digdag について検証したいと思いました。 Digdag を使うべき人 一般的にバッチスケジューラに求められる要件的には以下のようなものがあります。 ・スケジュール実行 ・複数バッチの順番の制御（ワークフロー） ・GUIでの管理 ・失敗時のアラート ・SLA 機能（長時間実行していたらアラートを飛ばす） ・分散実行 などなど 代替として広く知られているものですと Jenkins でのワ
Deep Q-LearningでFXしてみた - GMOインターネットグループ グループ研究開発本部
次世代システム研究室のJK（男）です。よろしくお願いします。 今回はDeep Q-Learningという手法でFXをやってみたので紹介します。前回のブログでは、LSTMというディープラーニング(Deep Learning; 深層学習とも)の一種を使って、株価変動の予想をしました。これは「教師あり学習」という手法で、コンピュータに常に「正解」を教えて学習させます。でも、よくよく考えると金融商品って時間変動の予想が最終目標じゃないですよね。最終目標は（基本的に）金融商品の売買で儲けること。つまり予想を元に、いま売るのか、買うのか、何もしないのか、という「行動」を決めることです。完全に未来がわかるのでもない限り、この行動に「正解」が無いことがわかります。 完全に予想するのは無理（短期的には買ったり負けたり）かもしれませんが、長期的には儲けるような「方針」は立てられるかもしれない。このように「方針
Java on Linux でのトラブルシューティング - GMOインターネットグループ グループ研究開発本部
こんにちは。次世代システム研究室のY.I.です。 最近参画した歴史あるプロジェクトで行ったトラブルシューティングの話題です。 アプリケーションの概要は CentOS 上の Tomcat で動作するサーバサイド Java アプリケーションとなっています。 今回は 「メモリ不足によるトラブルの対処」と「Java スレッドがデッドロックしてしまった件」をどのように調べて解決したかをお伝えします。 ◆メモリ不足によるトラブルの対処について 連携先との兼ね合いで Tomcat サーバから Apache サーバへ ssh して連携媒体と通信する機能がありました。こちらが2日に1回程度エラーになり Tomcat を再起動するまで失敗し続けるという状況になっていました。 エラーログ ERROR [InitAction.postProcess:132] ssh error web server ip=192
スケールアウト可能なSQLエンジンのベンチマークテスト：Presto vs Spark SQL vs Hive on Tez - GMOインターネットグループ グループ研究開発本部
2015.12.22 スケールアウト可能なSQLエンジンのベンチマークテスト：Presto vs Spark SQL vs Hive on Tez １、初めに 次世代システム研究室のL.G.Wです。最近リリースした関連記事推薦システム：TAXEL byGMOに携わっております。 このシステムは多様なデータソースからの集計・解析・ETLが重要になるので、性能とビジネス要件を満たすSQLエンジンを選定するため、主要なSQLエンジンのベンチマークテストを実施しました。 “Small Start, Scale Fast” – 最初のハードウェアコストをなるべく低く抑え、ビジネスが拡大したらシステムも拡張できることが前提です。主にバッチ処理用途で、ある程度のリアルタイム性も要求されます（数分間～1時間内）。データの規模は数十GBから数TBくらいの想定です。 主要なSQLエンジンとして、スケーラビリテ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
