F@N Ad-Tech Blog

株式会社ファンコミュニケーションズ nend・nex8のエンジニア・技術ブログ

新規サービスインターンに参加しました!

5日間新規サービスインターンに参加させて頂いた高橋です。
インターンでは、Nuxt.jsを使用して開発を行いました。

スケジュール

1日目 インターンの手続きと新規サービスの説明

午前中はインターンの手続きと説明を受けました。
午後からは新規サービスの説明を受け、何の技術で開発を行うのかを検討しました。
私は、普段からNuxt.jsを使用する機会が多く、また、配属された先でもNuxt.jsでよく開発しているとのことだったので、Nuxt.jsで開発することになりました。
支給されたPCの環境を整え、Nuxt.jsの環境をGitHubのリポジトリにあげました。

2 ~ 4日目 新規サービスの開発

2日目から新規サービスの画面の作成が始まりました。
午前中は必要なライブラリなどを調べました。
2日目から毎日12時から朝会(昼会ではない)を行いました。朝会では今日やることだったり、UIや機能面での疑問点などを出し合ったりしました。発言もしやすく、チーム一体となってサービスを作っていくことを体感しました。
午後からは画面の作成を開始しました。
認証にはFirebaseを使用しました。Firebaseを使用したことがほとんどなかったのでidTokenを取得するのに時間がかかりました。また、GAEにデプロイもしました。

3日目はFirebaseから取得したidTokenをvuex-persistedstateを使用してログインの永続化を行いました。Local Storageは使用したことはありますが、Cookieを使用したことがほとんどなかったので色々と調べながら開発を行いました。また、トップ画面も作成しました。

4日目はmiddlewareを使用しログイン画面へリダイレクトさせるように実装しました。middlewareもほとんど使用したことがなかったので、Nuxt.jsのライフサイクルや、どういう処理を行うのかを調べながら開発を行いました。
また、詳細画面も作成しました。詳細画面ではリロードをするとデータが消えてしまうため、nuxtServerInitを使用し、リロード時にAPIを叩くようにしました。

5日目 退社手続きとフィードバックとデプロイ

5日目の午前中に退社手続きをしました。もうインターンが終わってしまうのかという寂しさを感じました。
午後からはnuxtServerInitの修正をし、次にマイリストを作成しました。最終日は手続きなどで時間があまりなかったですが、トップ画面と詳細画面で使用したコンポーネントを使用したのでなんとかマイリストを作成することができました。
メンターの方からフィードバックを受けました。貴重な意見が聞けたので、今後に活かしていきたいです。
最後に自分の作成したものをGAEにデプロイし、インターン終了です。

感想

今までNuxt.jsで開発を行っていましたが、認証周りはあまりやってこなかったので技術力が上がった気がします。また、FirebaseやGAEなども触ったことがほとんどなかったので、いい経験になりました。
昼食時は、色々な部署の方と話す機会を設けて頂き、貴重な話を聞けたこともよかったです。
新規サービスのインターンは私が初めてだったことを知り、驚きました。
実際の業務を通して、やりがいを感じました。仕事の楽しさが少しわかった気がします。

1週間あっという間でしたが、内容の濃いインターンになりました。

ミニDSP構築インターンに参加してみた

インターンに参加したs_kakimotoです。最終日のタスクとしてブログ執筆が設定されていましたので記入します。
検閲により削除されないよう注意しながら書きたいと思います。

概要

  • 株式会社ファンコミュニケーションズさんのインターンに参加した
  • 開催地は東京オフィス
  • 5日間
  • いくつかコースがあるが自分はミニDSP構築コース的なものに参加した
  • 有給

自己紹介

アルバイトで生のPHPを書く生活を2年ほどしていたこともありこのコースとなりました。
サポーターズさん主催のマッチングイベントにて社員の長田さんとお話をさせていただき、そこで伺ったインターンに参加という流れです。

タスクについて、やったこと

お給料がでると聞いていたのでガッツリスキルを求められるかと身構えていましたが、このコースで実際渡されたタスクは既存業務に影響を与える訳ではなく、むしろ新人研修的な印象を受ける内容でした。
5日間の課題として渡されたものは以下のような要件を満たしたDSP(APIサービス)と呼ばれるものの実装です。

  • PHPをベースに使う(最終的に1/3ぐらいはJSで書いたけど)
  • POSTリクエストを受けてJSONレスポンスを返す
  • 3つのAPIエンドポイントを用意して、それらに処理を実装する
  • それぞれのリクエストとレスポンスは指定されたJSON形式でログとして保存する、保存先は自由
  • レスポンス時にMLと呼ばれる別サービスで導出された広告価格決定処理を行う、このMLとメインAPIは疎結合にして、ホストを分ける
  • 目標レスポンス時間100ms以内

DSPが何かということについては各自ggってください。
レスポンス100msの性能要件で泣きをみることになるのですが、それは後述します。

使った技術

PHP

後述するDockerで諸々を担保しました。ちなみに7.3をベースイメージに使いましたが、実業務で生きてるサービスのPHPバージョンは自主規制*1らしいです。つらい。

Laravel

唯一使ったことがあったPHPフレームワークなので用いました。ルーティングとかDB接続やマイグレーション/シーディングを楽にしたいな〜と思って脳死で選んだのですが、ローカルで動かしたらレスポンス1000ms(10倍)とかかかって泣きました。デプロイ環境では多少ましになったものの150msぐらいかかってました。
クエリ発行の効率が悪いだろうなーと思いつつ完成重視で実装してしまったのが原因です。

Docker

正直よくわかってないまま使うことに決めたのですが、ちょうどいい機会だと思って普通に使えるレベルにできるよう勉強しました。
デプロイ先とローカルとでいい感じにサービス立ち上げようとするならポートフォワードとか概要を覚えておくとよかったです。
一番技術面で成長できた分野と思います。Docker最高!🐳🐳🐳

Express / Node.js

正直よくわか(略)
MLとして使うことにしたJSフレームワークです。なるべく楽にAPIをぶち上げたかったので選んでみました。ぶっちゃけここがボトルネックの可能性も否めないのですが、デプロイ先環境のログをみたら0.4msとか書いてて禿げそうになりました。ほんまか?

MySQL

脳死で選んだ。遅いっぽい。というかメンターさんにはNoSQL使わないとスピード出せないっす的なこと聞きました。

Nginx

PHP(Laravel)を動かすWebサーバーとして使いました。普段Laravel使うときは php artisan serveとかApacheとか使うんですが参考にしたページでNginx使ってたのでそのまま使いました。Nginx.configをなんとなく把握できてよかったです。
ちなみにちょっと前までンギンクスって読んでました。

Makefile

バイト先で先輩社員が「docker-compose upとかbuildとかrun php bashとか打つの長いからエイリアスみたいなの用意したで!」って経緯で知ったので作ってみました。ローカル開発時は大変便利だったのですがデプロイ先AWSではコマンドが用意されてなくて直打ちしてたのでつらかったです。

AWS

AWSを公開テスト用に用意してもらいました。
中入って操作するのは問題なかったのですが思った以上に何も入ってなかったのでDocker使っててよかった〜ってなりました。Docker最高!🐳🐳🐳

Git / GitHub

一応privateにしてねって言われたのであんまりガチガチに環境変数保存しないようにとか意識しなくても良さそうでしたが、最低限clone, commit, push, pullはできる方がいいよね〜って感じの空気感でした。
他のコースはもっとプルリク駆動してるっぽい声が聞こえてきましたが。
インターン終わった後も継続して使ったりしてしっかり覚えようね!(戒め)

性能要件について

LaravelをDockerで立ち上げてNginxでサービスするんですが、普通にめっちゃ時間かかるのでつらかったです。隣のI君は生PHPの実行でサービスしてたんですが、そっちはAWS環境に乗せて40msとか出てるらしくて無力感というのを味わいました。
正直令和時代にレスポンススピードとか意識して開発することないやろとか思っていたのでいい刺激になりました。

つらかったこと

  • 初日からになりますがMacの操作がわからなくてつらかった。

- Macのターミナル見辛い
- 日本語の変換がトリッキー

  • GitとかVScodeの設定を完璧に普段と同じにできなくてつらかった。

- 貸与PCなので仕方ないです。

  • 普段のノリでノートPC担いで出社して、一切使わず持ち帰る生活でつらかった。

- 特に不要とも書いていなかった気がするので持ってきたが1.2kgの筋トレをするだけになった

主にMacが悪い買おうか割と迷ってます

その他

オフィス環境について

青山学院の近くにオフィスがあるんですが、まさか2拠点あると思ってなくてメールの「ここにきてください!(地図のリンク)」の指す場所とそのメールの署名欄に書いてる本社ビルの住所も建物名もズレてるな〜と思いながら初日は本社に向かいました。
もうお分かりかもしれませんが地図リンクが正しくて、そっちでみなさんをお待たせしてしまいました。初日から遅刻をやらかすという悪い例です。
主に作業するフロアはバスケットコートを横に2面あるかないかぐらいの広さで、それが2フロアと本社のビルという感じでした。
休憩スペースがまあまあ広くて、デロンギのエスプレッソマシンとか給茶機とか、あとモンエナ170円の自販機とか無人コンビニの小さいやつみたいなのがあります。無人コンビニは小腹空いた時とかにちょうどいい感じの品揃え+冷凍食品とかカップ麺とかもあるので外出たくない時も食事できるな〜って感じです。

デスクについて

案内されたデスクにはMacBookPro15”が置いてて貸与されました。キーボードがペチペチじゃない一つ前の型のなので神でした。その他23”の外部モニターも使えましたし、デスクは驚きの電動昇降でした(!)  これが””””人権””””なのか。。。?

日本酒会

なぜかインターン期間中、終業後に日本酒を持ち寄って休憩スペースで飲むという集まりがあって、
なぜか気づいたらご相伴にあずかっていて、
なぜか日本酒もワインもおつまみも、あと机の上にあった(苦手なはずの)ウイスキーや芋焼酎まで口に入れていて、
なぜか終わって気づいたら二次会のチャーハンの食券をいただいて食べてました。ごちそうさまです。

今後インターン生で日本酒会に興味があるひとはご注意ください。

まとめ

初めてのインターンでしたが、最初の課題説明で大体の構成をイメージできる難易度感とタスク量で、無事作りきることができてよかったです。
タスクの難易度については各コースやチームによって変わると思いますが、その辺りは他の参加者の記事を参照してもらえると嬉しいです。
大企業(規模的に)に新卒で入ることについては消極的だったのですが、こういう働き方や空気感の大企業もあるんだな〜と知ることができました。
技術的にもDockerやAWS、Expressなど触ったことの少ない技術も使ってフィードバックを得ながら開発できたのでとてもよかったです。

ありがとうございました!

*1:載せ替えようと頑張っていらっしゃるみたいです

楽しいインターン SSP

おはようございます!!
3月25日から29日までの5日間インターンシップに参加させていただきました瀬川です。
楽しいインターンです!!
もう一度言います。楽しいインターンです!!

内容

Mini-SSPサーバの開発

1週間の振り返り???

1日目(初日)

初日ということもあって、入社書類等の提出書類の処理、社内見学?探検?、アドテク(DSP,SSP等について)の説明などなど。
自分はもともとSSP、DSPに興味があったのでSSP、DSPがどういうものかある程度知っていましたが、丁寧にDSP、SSP等について説明していただけるので全く知らない人でもわかりますし、自分も詳しいところまでは知らなかったので、詳しい中身まで理解して開発を行えます。 そのあとMini-SSP開発にあたって、言語選択から開始(ここで8~9割1週間の苦しみ具合が決まる)。
残り時間もあまりなかったので、残りは環境構築が主でした。

環境

OS - CentOS 7 (Centかubntでどちらでもいいと伝えたら、Centになった)
たぶん言えば別のOSでもやらせてくれるじゃないかな?・・・知らんけど

言語 - Scala (2.12.7) (最新版を使いたくないある程度安定版使いたい派なので、バージョンがちょっと古いのは許してくだせう) Scala触ったことなかったので挑戦を兼ねてScalaを選択

ビルドツール? - sbt (1.2.8)

エディタ - emacs (宗教戦争をするつもりはないです・・・でも、emacsのほうがいいですよですよね?)

のちにこのemacsが悲劇を生むことをこのときは知るよしもなかった・・・

[オススメ言語一覧]

  • c++
    dspとかssp用のライブラリーがある。並列処理をそのライブラリーでやってくれるので脳死で書ける。処理速度も早い。C++使ってる会社もある。
  • scala
    純粋に並列処理(リスト処理)が楽。処理速度も早い
  • python
    簡単に書ける。処理速度は遅い。
  • golang
    ゴルーチンは神。ゴルーチンとチャンネルのおかげで並列処理楽。処理速度はそこそこ速い。
  • Rust
    並列処理がいいんじゃない?・・・知らんけど
  • erlang
    並列処理向けの言語だから並列処理に向いてる。erlang使ってる会社も多い。
  • Assembler !? 高速通信ならアセンブラでしょ??できるのかわからないけど・・・
  • nginxモジュール !? Webサーバ本体が処理したらそっちのほうが早いに決まってんじゃんwww(誰もやらないだろう・・・)
  • Shell オススメはしてない。できそうだけど、速くはないと思うよ・・・ でも、誰かやってみてほしい。。。

余裕ある人は変わった言語で試してもらいたいなぁ|ω・`)

2日目

実装内容の確認

SDK -> SSP -> DSPの流れでリクエストが送られる。
そのレスポンスとして、DSP -> SSP -> SDK で送られる。

f:id:fan_h_segawa:20190411183414j:plain 

scalaが初めてで、sbtも初めて・・・
sbtのことをよくわかっていなかった。

とりあえず、リクエストを受けて、レスポンスを返すというものを作ったが・・・
ライブラリのエラーでずっと動かない!!
でも、コンパイル時ではエラー出てない!?
ずっと試行錯誤を繰り返していた。。。

3日目

ライブラリーのエラーで動かないという話をScalaのできる人に聞くと・・・
ででーん!!!!!!!!!!!!!
そもそも実行コマンドが間違っていた!!

sbt はコンパイルするためのツールと思っていた私( ́・ω・ )
sbt compileでコンパイルしたあとにsbt run で実行するんだってさ(;´Д`)
sbt compileでコンパイルしたあとに scala hogeで実行しようとしてた。。。
scala hogeでもできなくはないが、ライブラリをsbtで用意しているから当然scalaのライブラリの方にはないよね・・・
当然といえば当然なんですよね・・・

とりあえず、リクエストが送られて来るとレスポンスを返すようにできた。

4日目

3日目までに単一の処理しか実装できていないため、SDK,SSP,DSPで流れるようにしようとしたら、関数の使用時に別の関数を使用しろとエラーが起きていたが・・・

エラー内容がよくわかん( ́・ω・ )

時間かかっても自分で限界まで考えたいマンの僕は無駄に時間を消費した。。。(ただコミュ症なだけ)

そうここでemacsでの悲劇だったのだ。
ここまでサーバ上の素emacs(no package)でやったきたため、どれが関数かパッとわかりにくいのである!!

結果、IntelliJで開発することにした(最初からそうしろ!!)

IntelliJで書きだしたら、見える見える関数がどれか見える!!!!!!!!! コーディング速度がめっちゃ上がった。

Javaはやってたが、eclipseでやってたので知らなかったがIntelliJめっちゃいいね♥ ここまでScalaが嫌いになりかけていたが、なんとか持ちこたえたのである。

5日目(最終日)

IntelliJのおかけでなんとかSDK->SSP->DSP->SSP->SDKと流れるに動作するよにでき、 複数台DSPに対して、リストで処理するようした。 でも、残念なことにDSPからのレスポンスをSSPで受け取り、1位のDSPに勝利報告をするところがよくわからず時間内には実装しきらなかった・・・・・(帰って自宅鯖で完成させた)

感想

昇降机など自分にあった物理的開発環境を整えることができるのは長時間働く上ですごく大事だなと思った。高さがあってなければ、腰や首、目などに多大な影響を与えるため働き安い環境であると思った。 ただ、正直オフィス内の温度は暑かった・・・・ 大体のオフィスがそうなんだろうが、夏は寒く!!、冬は暑い!! ここだけは本当に辛かった。 ただ、それ以外に不満はなく本当に自由にできる最高のインターンでした。 ありがとうございました!!!

GoでSSP構築をやってみた

こんにちは。
3月25日〜3月29日までの5日間、インターンでお世話になりました澤です。
9月にもSDKインターンでお世話になりましたが、今回またお誘いをいただき、今度はSSP構築インターンに参加させていただきました。

課題

課題は、SSP(Supply Side Platform)を構築するというものでした。
よくWebサイトを閲覧したり、スマホでゲームをやったりする時に広告が出ていると思います。
Webサイトにその広告を配信しているのがSSPです。

簡単に言えば、SSPとは、Webページに広告を掲載したいという時に、いい感じに処理して、広告を配信してくれているサーバのことです。

前回、SSPやDSPに関する説明を受けた時に、アドネットワークの世界にはこんな物語があるのかと感動した記憶があるので、今回SSPというアドネットワークの一部に触れることができる課題で非常に楽しみにしていました。 

5日間の流れ

1日目

いくつかの書類を書いて、会社についての説明を受けました。
そして、今回の課題についての説明を受け、課題をスタートしました。
僕自身サーバサイドのプログラムの経験は乏しいのでとても不安なスタートでした。
どの言語で書くかを自由に決められたので、Goを使うことにしました。
理由としては、
・比較的速度が速い
・並列処理に強い
・ライブラリなどが充実していて書きやすい
というのが主な理由です。

ネット上の記事を参考にしながら、何となくですが触りの部分は実装することができました。

2日目

Go言語を書くのも初めての経験だったので、非常に苦戦しました。
 
例えば、このような構造体があったとします。
 

type DSPRequest struct {
	ssp_name     string
	request_time string
	request_id   string
	app_id       int
}

何とこのままでは、他のパッケージからアクセスすることができないのです。
他のパッケージからのアクセスを有効にするには、以下のように要素の初めの文字を大文字にしないといけないのです。

type DSPRequest struct {
	Ssp_name     string
	Request_time string
	Request_id   string
	App_id       int
}

Javaのようにpublicをつけるという訳ではないので、知った時は目から鱗でした。
これに気づくのに2,3時間かかってしまい、非常に痛いミスでした。

SSPの話ではなくGo言語の話になっていますが、Go言語の仕様に悩まされつつSSPの構築を進めました。
サーバサイドのプログラムだけでなく、Go言語の学習にも繋がったので良かったです。

3日目

SDKからSSPにアクセスし、SSPからDSPに広告を要求し、その結果である広告のURLをSDKに返すという一連のSSPの処理を完成させることができました。

Goもサーバサイドも初めてで苦労しましたが、何とか形にはできて嬉しかったです。

ソースコードが読みづらかったので、少し綺麗にしようと試みました。
しかし、結果10行程度の削減にしかならなかったので、もう少しコンパクトに書けるように訓練していきたいと思いました。

4日目

この日はローカルの環境ではなく実際のサーバ上で動くかどうかを確認しました。
結果、サーバ上でも動作したので良かったです。

また、DSPから100ms以内に返事がもらえないときにタイムアウトする処理の実装を忘れていたので実装を行いました。
しかし、タイムアウトの実装が非常に難しく一日行いましたが、終わりませんでした。
ネット上で色々探して、実装してみましたが、どれも上手くいきませんでした。

やっぱりGoはあまり好きではないと感じたので、時間があれば他の言語でも書いてみたいと思いました。
(あるいはサーバサイドのプログラムが好きではないのかもしれない)

5日目

引き続きタイムアウトの実装を続けて、昼前には何とかそれっぽいものが完成しました。
良いか悪いかは別として、チャンネルを使いこんな風に(取得する値の数次第では、修正する必要あり。)書いてみました。(全体像はこちら

ch := make(chan string)
for i := 0; i < 1; i++ {
	go func() {
		Request_id, Url, Price, err = communicateDSP(url, dspRequestJson)
		ch <- "ok"
	}()
}

// タイムアウトを設定する
timeout := time.After(100 * time.Millisecond)

for i := 0; i < 1; i++ {
	select {
	case result := <-ch:
		fmt.Println(result)
	case <-timeout:
		err := errors.New("timeout")
		return "", "", 0, err
	}
}


書いたものの、不安定なので、それからもどうしたらいいのだろうかと考えてました。
負荷をかけてみても結果はよくありませんでした。

色々後悔することはありますが、レビューをいただいて、ブログを書いてインターン終了しました。

まとめ

今回、実装したコードはGitHubに公開しているので興味のある方は是非ご覧ください。
github.com

初めてGo言語を触ったので言語仕様にもなれず非常に苦戦しましたが、良い経験になったと思います。
また、サーバ構築を本格的にしたのも初めてだったので勉強になりました。

時間がなくて取り組めなかったことや後悔していることとしては、

・捌けきれない量の通信が来てもいいように作成したプログラムの前にnginxなどを置くこと
・コードが綺麗ではなかったり、無駄なところ多かったりしたので綺麗に書きたかった
・もう少しサーバサイドの知識やGo言語の知識を身につけてインターンに臨みたかった
・英語が苦手だが、英語から逃げずに英語の文献やページも読んで実装したかった
・分かりやすいログを出してどこで詰まっているのかを明確にして取り組むべきだった

といったところです。

最後に

インターンを受け入れてくださり、ありがとうございました。
会社の雰囲気もよく、非常に過ごしやすい1週間でした。
特に机の高さが自由に変更でき、立っても座っても作業できるのは新鮮で良かったと思います。

メンターのy_kawasakiさんをはじめとしてサポートしていただいた社員の皆さんありがとうございました。

非常に楽しく自分のペースで進めていくことができたので、おすすめです。

F@Nのインターンに応募するか迷っているのなら、ぜひ応募することをおすすめします。

5日間という短い期間でしたが、ありがとうございました。

サイトの分類を機械学習で予測する(MeCab + TF-IDF + Word2Vec)

こんにちは!5日間インターンに参加させて頂いた中島です。
昨年の夏に続き2回目の参加となりました。
前回はCTR予測を行いましたが、今回は自然言語処理をテーマにサイトの分類を行いました。
tech-blog.fancs.com

なぜサイトの分類を行うのか

ユーザーに合わせた広告を配信することは、収益をあげる上で重要です。
サイトを訪れるユーザーに合わせた広告を配信するためには、サイトの傾向を掴み分類する必要があります。
人間が目視で確認すればタグ付けできますが、何億件もあるサイトに適切なタグを1つ1つ付けるのには限界があります。
そこで機械学習でよしなにやってしまおうという訳です。

今回の目標

与えられたサイトのurlデータからそのサイトが広告に適したサイトかどうか(違法サイトかどうか)を2値分類する。

手法

サイトには様々な情報があります。

  • 画像
  • 動画
  • テキスト
  • リンク

今回は与えられたurlからサイトをスクレイピングし、得られたテキストデータを特徴量として分類モデルを作成しました。

データ概要および取得方法

データは以下の通りです。

  • urlからスクレイピングし得られた約1000件のテキストと広告に適したサイトかどうかのタグ。
  • タグは人力で違法サイトかどうか判断してつけられたもの。
  • 1000件のうち、違法データは約20件。

スクレイピングにはRequestsBeautiful SoupというPythonライブラリを使用しました。

特徴量の作成と実験

得られたテキストに対して形態素解析およびTF-IDFをして特徴ベクトルに加工し、大きく3段階に分けて実験を行いました。

  • 1. テキストに対して形態素解析、TF-IDFする
  • 2. テキストに対して形態素解析、TF-IDFし、オーバー及びアンダーサンプリング
  • 3. 2に加えてWord2Vecにより作成した特徴量を追加

尚すべてロジスティック回帰を用いて分類し、結果は混同行列で確認、評価にはF値を使用しました。

1. テキストに対して形態素解析、TF-IDFする

まずは、最も基本的な手法を試しました。以下2つはこちらの記事で詳しく触れられています。

形態素解析とは
日本語の文書から形態素(意味をもつ表現要素の最小単位)に分割する分析手法。
今回はMeCabを用いて、辞書にはネット用語に対応したmecab-ipadic-NEologdを使用。

TF-IDFとは
ある文章において、ある名詞がどれだけ重要かを特徴ベクトルとして数値化すること。
ある文書でよく出てくるが、他の文書であまり出てこなければ、その単語は重要という感じ。
これによって作られた特徴ベクトルを分類器に投げます。

32件のテストデータに対し,分類器の予測結果は以下の通り
f:id:fan_k_nakashima:20190329161743p:plain

混同行列は次のように読みます。

モデルの予測結果
違法である 違法でない
実際のタグ 違法である 0 6
違法でない 0 26

結果から、すべて違法でないと判定するモデルになっていることが分かります。
これは違法サイトのサンプル数が極端に少ないためです。
天気予報でいえば、「今日雷が落ちるかどうか」を当てろと言われた時に「落ちない」と答え続けば高確率で当たりますよね。

多少間違えたとしても、違法サイトを検出したいため、特徴量作成の工夫を考えます。

そこで、訓練データの違法サイトの数と違法でないサイトの数を調整します。

2. テキストに対して形態素解析、TF-IDFし、オーバー及びアンダーサンプリング

オーバーサンプリングとは
少数派のデータをもとに不足分のデータを補完する方法。
SMOTE(synthetic minority over-sampling)というライブラリでかさ増ししました。

アンダーサンプリングとは
少数派のデータ件数に合うように多数派データからランダムに抽出する方法。
違法でないデータを10分の1に削減しました。

また、TF-IDFにおいて単語の出現頻度を設定しました。
これによりほとんど出現しない単語の特徴ベクトルを作成しないようにし、より重要な特徴量に注目します。

分類器の予測結果は以下の通り
f:id:fan_k_nakashima:20190329164134p:plain

少しだけ当てられるようになったことがわかります。
まだ外しているサイトがあるため、どんなサイトの分類に失敗しているのか確認しました。
主観ですが、違法サイトは大きく2つに分類できます。

  • アダルトサイト
  • 漫画、動画などの違法ダウンロードのサイト

どうやら違法ダウンロードのサイトの分類に失敗しているようでした。
それは訓練データのTF-IDFの重要度にも表れていました。

順位 名詞
1 考察
2 ワンピース
3
4
5
6 ちゃんねる
7
8 ネタバレ

?はすべてアダルトワードのため自主規制

上の表は違法サイトだと分類するのに重要だとされている単語を上位から並べたものです。
アダルトワードは正しく検出されましたが、マンガタイトルなども上位にきてしまっています。

実際に違法漫画サイトと合法な漫画サイトを見比べてみましたが、使われている単語の大きな差はあまり無かったです。
そこで単語の出現頻度だけではなく、単語同士の類似度にも注目してみることにしました。

3. 2に加えてWord2Vecにより作成した特徴量を追加

Word2Vecとは
Word2Vecとは文章中の単語を任意の次元のベクトルに変換します。
類似語のベクトルをベクトル空間にグループ化することで単語同士の演算や単語の類似度の導出を可能にします。

TF-IDFでの特徴量に加えてWord2Vecで作成した特徴量も加えます。

分類器の予測結果は以下の通り
f:id:fan_k_nakashima:20190329175938p:plain

まだ少し外していますが、違法ダウンロードサイトも一部分類できるようになりました。
精度向上の理由の考察は深められていませんが、TF-IDFでは拾いきれなかった特徴量が拾えているようです。

まとめと感想

3つの手法のうち,1,2日目で1を,3日目で2を,4日目で3をし,5日目は考察とまとめを行いました。

  • MeCab + TF-IDF + Word2Vec でそれなりの特徴量が作成可能
  • 不均衡データにはサンプリングが大事

今回はテキストデータだけに注目しました。加えて画像データやリンクの数などにも注目すると、より精度が向上すると期待できます。
機会があれば画像処理なども取り入れていきたいと思います。

最後になりますが、メンターのkawasakiさんをはじめ、社員の方々にはお世話になりました!
聞きたいことを聞きつつ自分のペースで伸び伸びやらせて頂きました。
5日間ありがとうございました!