Data Driven Development （仮）~ Semi-Automated Relevancy Evaluation Platform in Search ~

0112/2013Kotaro OginoSearch Platform Group, Search Section, Big Data Department, Rakuten Inc.http://www.rakuten.co.jp/

2

楽天の検索から

来ました

3

楽天の検索

4

検索プラットフォームをパッケージ製品から内製に

• クラウドなプラットフォーム • 検索結果の改善

開発環境の整備　→　システムテストの自動化

5

アジャイルテストの４象限

機能テスト例）　ストーリーテスト　プロトタイプ　シミュレーション

探索的テストシナリオユーザビリティテスト受け入れテストアルファ / ベータ

単体テストコンポーネントテスト

パフォーマンス / 負荷テストセキュリティテスト「〜性」テスト

ISBN:9784798119977“ 実践アジャイルテスト” p.96

技術面

ビジネス面

チームを支援する製品を批評する

自動

自動と手動

ツール

手動

6

アジャイルテストの４象限

機能テスト例）　ストーリーテスト　プロトタイプ　シミュレーション

探索的テストシナリオユーザビリティテスト受け入れテストアルファ / ベータ

単体テストコンポーネントテスト

パフォーマンス / 負荷テストセキュリティテスト「〜性」テスト

ISBN:9784798119977“ 実践アジャイルテスト” p.96

技術面

ビジネス面

チームを支援する製品を批評する

自動

自動と手動

ツール

手動

検索機能

運用性可用性

7

JaSST 14 Tokyoで事例発表するよ

http://jasst.jp/symposium/jasst14tokyo.html

8

開発環境は整った

9

サービス品質向上やるぞ

10

アジャイルテストの４象限

機能テスト例）　ストーリーテスト　プロトタイプ　シミュレーション

探索的テストシナリオユーザビリティテスト受け入れテストアルファ / ベータ

単体テストコンポーネントテスト

パフォーマンス / 負荷テストセキュリティテスト「〜性」テスト

ISBN:9784798119977“ 実践アジャイルテスト” p.96

技術面

ビジネス面

チームを支援する製品を批評する

自動

自動と手動

ツール

手動

検索機能

完全性可用性

11

アジャイルテストの４象限

機能テスト例）　ストーリーテスト　プロトタイプ　シミュレーション

探索的テストシナリオユーザビリティテスト受け入れテストアルファ / ベータ

単体テストコンポーネントテスト

パフォーマンス / 負荷テストセキュリティテスト「〜性」テスト

ISBN:9784798119977“ 実践アジャイルテスト” p.96

技術面

ビジネス面

チームを支援する製品を批評する

自動

自動と手動

ツール

手動

検索機能

完全性可用性

検索結果の

品質

12

検索結果の品質にまつわる問題…

検索ランキングの評価 → 検索ランキングってテスト可能？ → 検索結果のランキングは複数の コンポーネントが複雑に 相互作用して作られる = システムテストが必要

13

検索結果の品質にまつわる問題…

データ分析者と開発者の関係 → データ分析者は”専門分野”を 評価している　　　例 ) 形態素解析、音素分析、 TFIDF → リリース後のユーザーの行動に よる AB テストで トータルとしてよくない結果が 出ることがしばしば

14

Big Data

Agile

×

15

×行動

観測 報酬

目的関数

テスト

実装 リファクタリング

生産性

ReinforcementLearning TDD

PDCA iterations

16

Data Driven Development

(2) 開発

(3) 評価 (4) 承認

(1) 目的関数

17

Data Driven Development

分析者

開発者

対象システムベースライン

対象システム改善手法

評価 評価用データセット

(2) 開発

(3) 評価 (4) 承認

(1) 目的 関数

→ 対象システムの 目的関数の最適化の ための継続的な 開発サイクル

18

Data Driven Development

(2) 開発

(3) 評価 (4) 承認

(1) 目的関数

19

(1) 目的関数(2) 開発

(3) 評価 (4) 承認

(1) 目的 関数

既存の開発の問題点

既存の分析の問題点

・定量的な評価手法が存在しない・継続的な改善の仕組みがない

・分析、評価が開発プロセスから 独立している→ 分析サイドで評価に使われている　　目的関数を開発サイドに導入

20

(1) 目的関数(2) 開発

(3) 評価 (4) 承認

(1) 目的 関数

諸事情によりモザイク

21

Data Driven Development

(2) 開発

(3) 評価 (4) 承認

(1) 目的関数

22

(2) 開発(2) 開発

(3) 評価 (4) 承認

(1) 目的 関数

分析者

開発者

対象システムベースライン

対象システム改善手法

評価 評価用データセット

目的関数を最適化する改善手法の開発、設定 - Tokenizer, Filter の開発 - スキーマ などの設定

23

(2) 開発

Git

Main stream

Relevancy branch

ベースライン

改善手法

24

Data Driven Development

(2) 開発

(3) 評価 (4) 承認

(1) 目的関数

25

(3) 評価(2) 開発

(3) 評価 (4) 承認

(1) 目的 関数

既存の開発の問題点・開発後にしか評価が出来ない・自動化されていないので頻繁に 評価を実行できない既存の分析の問題点・トータルなサーチ結果の改善を 示す事が困難

→ 共通の自動化された評価基盤を提供

26

(3) 評価(2) 開発

(3) 評価 (4) 承認

(1) 目的 関数

分析者

開発者

対象システムベースライン

対象システム改善手法

評価 評価用データセット

Jenkins, Vagrant, Ngauto で共通の自動評価プラットフォームを構築

27

(3) 評価(2) 開発

(3) 評価 (4) 承認

(1) 目的 関数

STG の Jenkins のジョブ

Ngauto のテストクラス

→ JUnit でそれぞれの シナリオが 記述されている

→ 対応するジョブを 作成

28

(3) 評価(2) 開発

(3) 評価 (4) 承認

(1) 目的 関数評価結果

・ Jenkins の画面

29

(3) 評価(2) 開発

(3) 評価 (4) 承認

(1) 目的 関数評価結果

・ Jenkins の画面

テストが失敗した！ = 検索結果に変化が生じた！

30

Data Driven Development

(2) 開発

(3) 評価 (4) 承認

(1) 目的関数

31

(4) 承認(2) 開発

(3) 評価 (4) 承認

(1) 目的 関数

Git

Main stream

Relevancy branch

ベースライン

改善手法- pull request- approve

32

Data Driven Development

33

Data Driven Development

= 継続した改善のための　　　 ATDD のサイクル

34

Data Driven Development

(2) 開発

(3) 評価 (4) 承認

(1) 目的関数

35

AgileBig Data