起手式

研究的目的就是要產出一個模型？這其實是一個有點危險的起手式，回故我們一開始提到的 AI Canvas 和 ML Canvas 兩個架構，我認為這兩個架構的其中一個重點就是：一個好的起手式不是去寫任何程式碼，而是去弄清楚這個專案:

1. 要達到的目的是什麼？
2. 要接在什麼樣的使用情境？
3. 有沒有其他團隊提供的 Service 已經可以部分解決
4. 最快/ Baseline的解決方法什麼？

用我們 Account Takeover Detection (ATO) 問題來回答這幾個問題

1. 在用戶提款的當下，根據用戶申請提款的資訊和過往用戶的使用紀錄，判斷申請提款的請求是否是用戶本題提出的
2. 在提款的 API 收到請求的當下，調用 Rule Engine API 來 invoke event，如果 Rule Engine 判斷有問題，需要透過 Callback 方式來取消提款請求，這過程，提款請求會被 Pending 十分鐘的時間來做判斷
3. 目前已經有 Rrools Based 的 Rule Engine 團隊, 並且有一系列設備相關的特徵和資料庫，以及 ip 黑名單
4. 可以先研究 Rule 來看可以篩選出多少的案例

限制

這裡一個問題如果 Rule 哪摸厲害為什麼還需要做模型？其實真的不用，在這場景下我們對模型有兩層期待

1. 透過一個模型去涵括多個不同的 Rule
2. 透過模型預判可能會有的 Rule
   但在訓練邏輯上，要達到第二點是非常的困難的，所以我們大多情況都會以第一種為目標，至於原因可以等後續再來討論，但這也不代表不需要花時間做模型，如果能達到第一層的目的，就值得做模型。

但要記得模型先天有一個限制，不可能會完全沒有 False Positive，所以如果場景對於 False Positive 的接受度很低的話，就無法做到一個完全 End-to-End 的模型 Solution

那我們假設已經把基礎的 Rule 都做好，此時若想繼續去窮舉更多的規則是非常耗時且不切實際的，所以接著回到我們的題目，如何開始模型的研究

模型

如上圖模型的研究很粗略的分成三塊，EDA, Modeling, Evaluation 和 Deploy，有透過 AWS Sagemaker 上模型的人對這一切應該不至於太陌生，所以這裡我會省略常見的步驟，專注在討論兩個題目：版本控制和 Bias

版本控制

不管是 EDA 還是 Modeling 都會遇到一個問題就是，我們如何去管理我們的實驗中不同的嘗試，以及不同嘗試的產出，傳統上來說我們都會用 Github 來做特定的版本管理，但是版本管理有幾個問題

1. Github 不容易對 Data 做版本管理
2. 程式碼的撰寫風格差異大，版本管理很難做到風格的管理
3. Github 無法管理 Lineage 和 Artificate (Meta)
4. Github 難以管理中間產出的 Log
5. 不同實驗的 Log 以及結果比對也沒有很好的工具

Data 版本管理最大的問題在於 Storage, 雖然有像是 Git LFS 這樣的工具可以提供，我們會在後面的 Data Version Control 主題討論更多 Git LFS 會遇到的問題

另外透過 Git 做實驗管理時會遇到的問題我們也會在後面的 Experiment Version Control and Tracking 討論要解決什麼樣的問題，以及透過 Lineage 以及 Artifacts 來知道在整個實驗中資料的流動是根據什麼樣的 Pipeline 以及後續的產出

但版本控制的重點就是要讓實驗可以被追朔，可以被重現最後來達到自動化實驗的目的也就常聽到的 AutoML

Bias

常見的 Bias 都是在實驗之前我們透過先驗知識或是標記資料中得知的，但有些 Bias 是很難被解決的，舉我們的題目 ATO 場景，常見的 Labeling 方式就是通過用戶客訴來拿到，但這樣的 Labeling 方式來說有兩個情境可能會照成 Bias，

1. 資金金額太少，可能低於一百塊的金額，用戶都不太願意花大把時間回報，或是客服端收到這樣的回報時，就自動把這類案件的就對我們的資料建立起 Bias
2. 可能有一段時間因為平台大力推廣，造成客服來不及負擔，堆積的客訴案件也沒時間回頭消化，導致有些 Positive Case 因沒標記變成 Negative

當有些案例很難透過很好的 Process 或說他就直接在資料上就造成 Bias 要如何 Mitigate 並且更正確的 Evaluation 就是一個很重要的問題

後續的 Evaluation 就會針對這些繼續討論

那就等下週繼續寫關於 Experiment 相關的題目