AWS的定義機器學習問題
在本文中我們將學習到如何把組織遇到的業務問題定義(或轉換)成機器學習(以下簡稱ML)問題。一旦我們這麼做了，我們將需要能夠收集資料需求、特徵工程和訓練/調整模型。
ML問題定義
我們在前一篇文章:AWS的機器學習 — 從業務角度理解ML，我們談到了CRISP-DM框架，這提供一種了解整個ML lifecycle各階段的框架。一但我們定義了業務問題與並確實驗證了業務問題能夠被ML方法所處理，哪麼下一步就是定義出ML問題(PS :並不是所有問題都是都可以用ML來解決)。
ML的目標是使用數學模型預測未知的數值或類別。 要產生模型，我們需要一些模型可以用來“學習”的資料，這些資料由自變量(independent variable)和因變量(dependent variable)組成。也就是我們已知的訓練用資料。
該模型根據提供的資料中的自變量學習預測因變量。 一個好的模型應該能夠將它學到的東西"延伸到未知的資料"，即"因變量的未知資料"。 簡單地記住訓練用資料的爛模型將具有較差的通用效能，因此將無法在業務流程中使用。
我們將會在其他的文章(模型訓練)中，更深入地研究不同類型的ML和特定演算法，但就目前而言，這種High level的理解就足夠了。 我們看到，為了使任何問題成為ML問題，我們需要擁有由自變量和因變量（也稱為labels或target variable）組成的資料。 如果我們沒有任何因變量資訊該怎麼辦呢？ 這樣的問題還能是ML問題嗎？
答案是 Yes — — 在沒有因變量的情況下，我們仍然可以使用ML來探索資料中的模式。 這是一種稱為非監督式學習的ML形式，我們在"AWS的定義機器學習問題"文章中討論。
案例1:倉庫庫存及時預測
讓我們舉一個實際的例子。 假設我們是一家零售業，並且公司有想要知道每週預測對某些產品的需求，以確定如何為他們的倉庫儲存庫存。 他們問題是可否使用ML來解決這個問題。
首先，這可能是一個ML問題，因為企業可能每天或每週都有來自各門市點的歷史產品銷售資料。 他們也可能擁有有關倉庫庫存的相關資料。 在這種情況下，我們可以構建一個ML模型，該模型使用時間單位（天/週）等自變量來預測因變量（總銷售額）。
案例2:電商的客戶區隔
讓我們再舉另一個例子。 假設我們經營電商務業務，並且我們的公司想要了解更多有關其客戶的資料。 他們詢問是否可以使用ML來解決這個問題。 首先，這可能是一個ML問題，因為公司可能擁有來自電商平台的客戶資料，例如年齡、性別、地址和購買歷史。 但是，在這種情況下，這個資料沒有附加label。 我們可以使用非監督式ML方法（例如clustering）來發現客戶群中的模式，並根據他們的行為模式將他們劃分為不同的群組。
請記住，ML只是一種工具，我們是否使用ML應該由具體的業務成果來推動。 即使問題是ML問題，如果我們沒有資料或收集資料的代價高昂，那麼ML可能不是解決問題的正確方法。 因此，讓我們來看看在嘗試將業務問題構建為 ML 問題時應該採用的一些推薦做法。
推薦做法
當我們嘗試定義出業務問題是ML問題時考量下列的問題:
- 在業務層面如何確認這個ML專案是成功的
一旦我們有明確的業務指標，將這個指標對應到ML指標上。請記住，ML模型必須針對某些指標或quantity進行優化，這些指標可能是 accuracy， precision或recall。我們必須想辦法把我們業務轉成一個業務指標，例如最大化我們的利潤或最小化我們業務停止營運的時間，而這些都必須是數學度量，因為ML只懂這個。 - inupt是甚麼?我們要的output又是甚麼?
演算法需要具體的input，對於 ML 演算法，input就是data。我們應該都聽過一句ML 格言，“garbage in, garbage out”。 ML 模型的好壞取決於它們所訓練的資料，識別輸入資料是關鍵。 還要關注output: 我們希望模型預測什麼？ 我們是否擁有將input與模型可用於訓練的output相關聯的現有資料？ 如果沒有，我們能否快速且經濟高效的label一些資料？ 如果沒有，我們能否將此use case範圍作為模式識別的use case，而在這其中我們想從input data中學習到某些模式？ 擁有具體的input和output以及可量化的優化指標將幫助我們確定要應用的ML演算法類型。 - 我們的資料來源甚麼?它們已經被標記(label)了嗎?
深入了解公司擁有的資料類型、資料來源以及獲取額外資料的挑戰。在此階段擴大範圍會很有幫助，甚至考慮使用公司外的資料，例如天氣或公共資訊/新聞（取決於use case）。 Web scraping(網頁爬蟲)通常是獲取外部資料的常用方法。一旦我們確定了所有相關的資料來源，我們就可以根據更容易獲得或最具成本效益的資料縮小它們的範圍，從而確定我們的專案範圍。請務必注意可能適用於我們用於ML或其他應用程式的資料集的任何資料許可限制(就是它是不是合法取得)。在 ML 進行中的這個階段，如果我們沒有足夠的labeled data來訓練模型，那麼考慮是否要使用某種data annotation或labeling strategy來label data也很重要。在這方面，詐欺偵測等一些use case可能很棘手，因為詐欺案件的總數可能非常低。如果沒有足夠的詐欺範例，我們將無法開發一個好的 ML 模型來預測詐欺。在開發 ML 模型之前，考慮我們是否首先要使用人類專家label一些資料。 - 是否有可能針對業務給出有用的代理指標(proxy metric)？
在上面的詐欺範例中，如果我們沒有足夠的labeled data並且將資料標記為詐欺的代價太高，我們可能需要詢問公司是否可以尋找其他詐欺指標。 例如，銀行經常聘請專家來識別詐欺，他們的專業領域知識可能會派上用場，來確定另一個可以作為欺詐代理的標籤。 - 開始簡單的模型然後逐漸複雜化
永遠從一個簡單的模型開始，隨著時間的推進後慢慢採用更複雜的方法，因為更複雜的模型需要很長時間來訓練，計算代價更高（因此成本更高），並且更難理解。 如果我們的業務需要可解釋性，那麼花幾個月的時間訓練深度學習模型是沒有價值的，因為眾所周知，深度學習模型難以解釋。 線性回歸/邏輯回歸、決策樹和隨機森林樹等簡單模型很受歡迎是有原因的。 - 考慮模型風險等標準，如果它們與我們的產業相關
正如我們之前提到的，有時政府監管方面的考量可能需要我們解釋我們 ML 模型的輸出(output)。 儘管有一些技術可以做到這一點，例如 Shapely 值或LIME(local interpretable model-agnostic explanations)，但它們通常適用於線性或tree-based的模型，而不是深度學習演算法。 這可能會決定我們構建的模型類型，並且在構建 ML 問題時是一個重要的考慮因素。
