FAQ


参加者のみなさまよりいただきました質問をまとめました.
以下の資料は,個人的に各所への説明用に作成した資料です. コンテストルール等の説明をされる際にご利用ください.
※概要のため,細かい部分まで定義されていませんのでご注意ください.


20171011 pwscup説明資料

Updated:2017-10-16 23:03:47(206)








予備戦提出データについて


・ [予備戦再識別フェーズ]終了後,複数のチームより提出した再識別データの取り下げ申請が寄せられました.実行委員内で検討した結果,取り消し申請を認 め,一部チームの予備戦順位が変更されております.本戦直前にご迷惑をおかけいたしまして,申し訳ございません.[2017/10/21]


・10月6日をもって終了した [予備戦匿名加工フェーズ] において,一部の参加チームによる提出データに不正があったため,以下の通り対処いたします.

  1. 不正内容について
    • 提出された匿名加工データに,オリジナルトランザクションデータに存在しない商品IDが含まれていました.
    • 商品IDの加工については,ルールブックにおいて以下の通り禁止事項が定められています.
      「 9.(d) 購買履歴データTに含まれない商品ID (t·,5) を含む匿名加工履歴データA(T)を加工すること.(単価 t·,6 ,数量 t·,7 はこの制約はない)」
  2. 不正があったデータ
    • S_T01KTR_100610401E0hD5FY.txt
    • S_T01KTR_100610451E0hH5io.txt
    • S_T01KTR_100610431E0hFpC0.txt
    • S_T04KST_100612521E0jGfYV.txt
  3. 対処方法
    • (2017/10/16) 再識別フェイズ終了後に,実行委員内で協議した結果,不正の内容が他チームから再識別されるヒントとなったことから,具体的な罰則が必要ないと判断した.そのため,本データをそのまま予備戦提出データとして認めることとする.
  4. 注意事項
    • 不正データを検知せず,受理してしまったことにつきましては,運営システム側で不正な商品IDのチェックに漏れがあったことも一因であり,不備があったことをお詫びいたします.
    • 本戦においては,新たに商品IDのチェックロジックを構築するため,不正の有無についてはシステムへのデータ投入により,確認することができます.


Updated:2017-10-21 09:00:17(312)








サンプリング手法について


今回のTαを生成したサンプリング手法は,サンプリング後のデータに500人のユーザが全員残っているようにするため,以下の手順で行っています.
本手順は,Mysqlで行っているため,概要のSQL文を記載します.
  1. Tテーブルを作成し,「Rand」カラムを追加して,0~1のランダム値を付与する.
    update T set Rand = RAND();
  2. TをIDでグルーピングしてユニーク化し,最も高い値の行番号を Temp1 テーブルとする.
    Create table Temp1 Select T.行番号,T.ID,max(Rand) from T group by T.ID ;
  3. その後,Tをランダムサンプリングし,Tαを満たす行番号になるまで加える.
    Create table Temp2 Select T.行番号,T.ID from T,Temp1 where T.行番号 != Temp1.行番号 order by rand() limit |Tα|-|M| ;
上記Temp1,Temp2を結合してTαを作成しています.



Updated:2017-10-11 17:06:03(205)








再識別フェイズに関する質問



Q1: 配布されている部分知識は行順が変わっていないので,DEL行がどの顧客のものか等が予測できてしまうが,これは再識別に用いていいのでしょうか?それとも元データを用いているとみなされるでしょうか?

  • DEL行がどの顧客であるかを確認するには,T25とT100などの連結が必要になります.このようなT同士の連結は行わない前提となっております.

Q2: 部分知識によっては再識別不能な顧客が出てくると思うのですが,それはよいのでしょうか?

  • 例 えばT25などでは,1ヶ月分の購買データが全て抜けている顧客が発生する場合があります.T25をベースに再識別を行った場合には仕方が無いもの,と理 解してください.また,そのような完全に消失した顧客を再識別した場合,他の知識を使っていることが予想されますが,機械学習などを用いて予測しているこ とも考えられるため,不正とは設定しません.ただし,その手法について実行委員から質問等が来る場合があります.

Q3: 再識別には部分知識だけ使うように,とのことでしたが,公開されている評価指標の評価値は用いていいのでしょうか? また,MはTαと結合して知識として用いても問題ありませんか?

  • 公開されている指標値を用いることは問題ありません.また,Mは部分知識と結合して使用しても問題ありません.

Q4: 再識別の提出はそれぞれ10回までとのことでしたが,10回以上の提出はシステムにはじかれるのでしょうか?

  • 10回以上登録した場合はシステムで検知します.本日,ランキングページに投入回数がわかるページを追加しました.そちらを参考にしてください.

Updated:2017-10-12 15:24:07(208)








Item-CFについて


PWSCUP2017から新たに採用された有用性指標について説明する.

1. Item-CFの概要

  • 産総研の村上 隆夫氏,東大中川研の門田 将徳氏によるレコメンドエンジンの実装をシミュレートした有用性指標である.
  • レコメンドエンジンとは,WEBサイト等である行動を取った顧客に対して,次の行動を推薦する仕組みであり,User-User型とItem-Item型に分類される.
  • User-User型は,あるユーザに近い人を推薦し,Item-Item型は,あるアイテムを買う人が,追加して買うアイテムを推薦するものである.
  • PWSCUP では,ユースケースとしてItem-Item型のレコメンドエンジンを作成することを想定しており, そのための有用性評価としてアイテムベース協調フィルタリング:Item-CF(Item-based Collaborative Filtering)を利用する.
  • オリジナルのトランザクションデータTと, 匿名加工トランザクションデータA(T)からそれぞれItem-Item行列の類似度行列を作成し, それらの距離によってItem-Item型のレコメンドエンジンにおける有用性の評価を行う.

2. Item-Item行列の作成手順

  1. トランザクションデータから,User-Item行列を作成
    • User-Item行列は,全ユーザーに対してそれぞれのユーザーの全アイテムの購入数を格納した行列である.
    • すなわちi,j成分には,i番目のユーザーがj番目のアイテムを何個購入したか購入したかが格納さている.
  2. User-Item行列から,Item-Item行列を作成
    • 以下では,User-Item行列の各列をアイテムベクトルと呼ぶ.
    • 全てのアイテムの組み合わせに対して,それぞれのアイテムベクトルのCosine類似度を計算する(以下の画像を参照).
    • Item-Item行列のi,j成分には,i番目アイテムとj番目のアイテムのCosine類似度を格納した行列である.
    • 理論上は,全ての対角成分は「1」になるが,PWSCUP2017での有用性評価プログラムでは「0」になるようにされている(理由は後述).

3. Item-CFを用いた3つの有用性指標

  • E1-ItemCF-s
    • Supplierに提供することを想定し,大量購入の履歴のみから作られたItem-Item行列同士での比較を行う
    • User-Item行列のうち,購入点数が12以上となる,ユーザー,アイテムの組み合わせに対してのみ,Item-Item行列を作成する.
    • 有用性評価プログラムE1-ItemCF-s.pyでは,購入点数を,12以上23以下→1,... ,60以上71以下→5,72以上→6 となるように値を変換する.
  • E2-ItemCF-r
    • Retailerに提供することを想定し,少量購入の履歴のみから作られたItem-Item行列同士での比較を行う
    • User-Item行列のうち,購入点数が12以下となる,ユーザー,アイテムの組み合わせに対してのみ,Item-Item行列を作成する.
  • E3-topk
    • 匿名加工前後での,購入顧客数が上位kとなるアイテムリストを作成,差集合の計算(指標1).
    • さらに,Tから選出された上位k個のアイテムについてItemCFによる類似度行列を計算 (指標2).

4. 注意事項

  1. Item-Item行列の対角成分について
    • 理論上は,全ての対角成分は「1」になるが,PWSCUP2017での有用性評価プログラムでは「0」になるようにされている.
    • 例えば,「単体で購入された商品に関するレコードのみを残す」という加工をした場合,Item×Item行列は「対角成分が1,それ以外の成分が全て0」となるが,このような極端な加工をした場合,アイテム推薦が一切できなくなってしまう.
    • しかし,匿名加工前後で対角成分については,類似度が変化しておらず,そのままの評価方法であれば,一定量の有用性があるという評価がされてしまう.
    • アイテム推薦としての有用性がなくなっていることを,正当に評価(有用性=0)するために,対角成分は常に0となるようにした.
  2. ソースコード中の閾値PurNum2Scoreについて
    • 1ダース以上購入された値はSupplierと定義されるが,6ダース以上購入したユーザは3σ以下の出現数となることから集約値に変換されることから「6」が最大値となっている.
  3. E3-topkについて
    • 予備戦ではk=100とする.本戦で変更がある場合は別途HPで告知する.
    • プログラム内では,Topkアイテムの選定のためのソートを「購入顧客数(降順)→商品ID(降順)」の順番で行っている.

Updated:2017-10-11 22:52:39(207)








再識別の定義について


再識別と呼ばれる処理には,多くの手法・定義があり,統一されたものはありません.

2015年,2016年に行われたPWSCUPでは,マスターデータにおけるIDと,匿名加工したデータの仮IDを結びつける行為を再識別,と定義しました.この手法は,2017年で設定された,IDを分割する手法にはそのまま適用できません.
そこで,月ごとにデータを提供する,というユースケースから,月ごとにIDを変更できない制限を加え,仮名表を作成する方式を提案しました.


しかし,仮名表を用いることが決定した後でも,1部分だけ再識別された場合に個人が再識別されるのか,など,計測方法が多様にあることから,議論が続いていました.

コンテスト開始当初は,1個しか購入していないユーザと1000個購入しているユーザでは,再識別された場合の影響が異なる,ということから,仮名表の一致率によって評価する方式を採用しました.



しかし,この方式では,今年度のテーマである仮名の長期的な利用によるリスクが評価できないことから,長期的な利用状況をより良く表すよう,12か月分の仮名全てが当てられた場合に再識別とする,という評価方式に変更しました.

ルールの変更により,多くの方々にご迷惑をおかけいたしました.大変申し訳ございませんでした.




Updated:2017-10-11 22:51:37(209)








データフォーマット



今大会で利用するデータフォーマットについてまとめます.
※本WEBサイトは概要のみ記しています.正確な定義は,ルール論文,ルールブックを参照ください.
■ PWSCUP 2017 ルール論文  ■ PWSCUP 2017 競技ルール  ■ 競技データ&プログラム

以下のオリジナルデータ,サンプルデータは一括でダウンロードできます.
データ説明()で括られたファイルは,サンプルデータ内に含まれている対応するファイル名です.

M , T は,昨年度のファイルフォーマットと同じものを利用しているため,各データ形式の詳細は資料をご確認ください.
※参考 PWS CUP 2016 トランザクションデータの書式
今年度は, M は加工対象ではありません. T のみが匿名加工対象です.

M : オリジナルの顧客マスターデータ( M.csv )

M 通称区分書式概要
c,1 顧客ID 識別子 50byte以下の任意の英数文字列
c,2 性別 属性 「f」か「m」
c,3 年代 属性 1930/1/1 ~ 1980/1/1
c,4 属性 United Kingdom,France,Germany,Others

T : オリジナルの購買履歴データ ( T_sample.csv )

T 通称区分書式概要
t,1 顧客ID 識別子 任意の英数文字列
t,2 伝票ID 識別子 消去済み
t,3 購入日時 日付 2010,2011年のYYYY/MM/DD形式
t,4 購入時間 時間 hh:mm 形式
t,5 商品ID 属性 9文字以下の任意の大文字英数文字列
t,6 単価 数値 整数部5桁以下、小数部2桁以下の正小数
t,7 購入数 数値 6桁以下の自然数

例1: T のサンプル




A(T) : T を加工制限の範囲内で匿名加工したデータ

S : A(T) の提出後,削除行を排除し,行番号をかく乱したデータ

F : TA(T) の関係から作成された仮名表

A(T) の加工制限


以下の加工制限の範囲内で作成したA(T)をシステムに提出してください.
※本WEBページは概要説明です.正式な定義はルール論文とルールブックを参照ください.

1 ) 匿名加工履歴データ A(T) の行の順序は,購買履歴データ T と同一とする.

2 ) T に存在しない行の追加は認めない.

3 ) T に含まれる行を削除する場合は,当該行を [DEL,,,,,, ] と記載する.すなわち,列数は変更しない.
  以下,削除した行を'DEL行'とする.

例2:例1の T の2行目を削除する場合

4 ) A(T) に含まれるDEL行は,全行数の50%以上になってはいけない.

5 ) A(T) に含まれる属性の1列目は元情報の識別子であるため,元の識別子とは異なる仮名を付与すること.

6 ) A(T) の仮名は期間内では矛盾のない様に割当てる.同じ月内において仮名を変更してはならない.

例3:例1の T に仮名を付与したが,4行目に異なる仮名を割り当て,エラーになる例

7 ) 月ごとに仮名は必ずしも変更しなくてよい.月をまたいで同一人物に同じ仮名をつけても良い.

8 ) 'DEL' という仮名は禁じる.

9 ) 購買履歴データ T に含まれない商品ID( t·,5 )を含む匿名加工履歴データ A(T) を加工すること.
  単価 t·,6 ,数量 t·,7 はこの制約はない.

10 ) 日付 t,3 属性は,本来分割されたデータであることから,月をまたいだ加工を禁じる.

例4:例1の T の日付を加工したが,月をまたいでエラーになる例

11) 生成した A(T) は,'AT_*****.csv' という名前のファイル名として,システムに提出すること.
  上記の加工制限を逸脱していない場合,有用性・安全性評価に進むことができる.


SF のフォーマット


システムに提出された A(T) は,有用性,安全性の評価後に, SF に加工して,他ユーザに秘匿して管理される.

S は, A(T) からDEL行を排除し,行番号をかく乱したものである.
この処理は A(T) の提出後にシステム内で自動に行われ,再識別フェイズ以降,他参加者に公開される.

例5:例2の A(T) に仮名を付与した後,行番号をかく乱された例


また,システム内では, T A(T) ,仮名表 F を生成する.
仮名表は,
 元の識別子,2010年12月の仮名,2011年1月の仮名,2011年2月の仮名,...,2011年11月の仮名
という形式で表す.

再識別フェイズは,この仮名表 F を推定して作成した F^ を生成し,提出する.
FF^ は同じフォーマットであるため,以下を参考に生成すること.

例6:仮名表 F の例

この表は以下のようなテーブルであると考えると理解しやすい.
特に,開始月が2010年12月であることに注意すること.

例7:例6の仮名表 F をテーブル化したもの
識別子2010/122011/12011/22011/32011/42011/52011/62011/72011/82011/92011/102011/11
12431ABCDEDELDELDELDELABCDECDEFGCDEFGCDEFGCDEFGCDEFGCDEFG
15100VWXYZVWXYZVWXYZDELXYZABDELDELDELDELVWXYZVWXYZDEL
16211DELHIJKLDELDELDELHIJKLDELDELDELDELDELDEL


例7の表では,顧客12431氏は,2010年12月から2011年5月までABCDEという仮名に変換され,2011年6月からはCDEFGという仮名に変更された.2011年1月から2011年4月までは何も購入していないため仮名は存在せず,DELと表す.

また,顧客15100氏は,2011年4月にXYZABという仮名に変換されたが,その後はその仮名は使用していない.
このような加工も提出データとして認める.


Updated:2017-10-05 11:26:16(201)