機器學習系統設計決策與問題分解

當今機器學習系統設計需要仔細權衡多種因素，諸如核心業務需求、成本效益、技術能力和資源組態。評估建構自有方案或整合現成產品的利弊，並考量開源與專有技術的特性，是確保系統符合需求的關鍵。此外，面對複雜問題時，採用問題分解策略，將其拆解成更小、更易於管理的子問題，能有效提升系統的準確性、可靠性和可維護性。這需要結合不同演算法的優勢，並考慮資料融合、邊緣案例處理和不同資料子集的特定邏輯。同時，選擇適當的創新程度，平衡研發投入與實際效益，也是至關重要的。

建構還是購買：開源或專有技術的抉擇

在面對複雜的技術系統（包括機器學習系統）時，企業經常會遇到一個重要的決策困境：是自行開發（Build）還是購買現成的解決方案（Buy）。這個決策過程涉及多方面的考量，包括業務核心競爭力、經濟成本、技術需求以及內部資源等。

建構還是購買的抉擇

以Slack為例，一款支援音訊和視訊對話的團隊通訊軟體，它具備接近即時的語音辨識功能。然而，對於這樣一個原本以文字為主的通訊工具，語音對話的使用比例相對較低，而對語音辨識的準確性要求卻很高。這種情況下，Slack的開發團隊就需要考慮是否要自行開發語音辨識技術，還是尋找現成的解決方案。

核心業務與非核心業務的區分

企業通常會專注於其核心競爭力，而對於一些非核心的功能或服務，則傾向於使用第三方服務。例如，大多數公司現在選擇從雲端伺服器供應商租用虛擬機器，而不是自行管理大量的伺服器。這種做法可以讓企業避免在非核心領域投入過多的資源。

經濟考量

另一個重要的因素是經濟成本。如果市場上已經有供應商提供相關的解決方案，並且其服務在品質和價格上都符合企業的需求，那麼購買現成的解決方案可能是更經濟的選擇。然而，如果企業能夠以較低的成本自行開發解決方案，或者需要高度客製化的解決方案，那麼自行開發可能是更好的選擇。

開源與專有技術的比較

企業還需要考慮是使用開源解決方案還是購買專有技術。開源解決方案可能具有較低的前期成本，但可能需要額外的維護和問題解決成本。另一方面，購買專有技術可以將許多維護問題轉嫁給供應商，但可能會受到供應商的排程和功能限制。

建構還是購買的決策因素

綜上所述，建構還是購買的決策取決於多個關鍵因素，包括企業的核心業務需求、經濟成本、技術需求以及內部資源等。

機器學習系統設計中的關鍵決策與問題分解

在設計一個機器學習（ML）系統時，面臨著多種複雜的決策，包括是否自行開發解決方案、選擇開源或專有技術，以及如何分解複雜問題等。這些決策不僅需要深入瞭解技術層面，還需要考慮到預算、法律法規以及系統的非功能性需求等因素。

自行開發還是採購現成方案

在決定是否自行開發ML系統或採購現成的解決方案時，需要考慮多個因素。首先，內部開發能力是關鍵。如果團隊具備足夠的專業知識和經驗，自行開發可能是更好的選擇。其次，資料敏感性也是重要考量。如果涉及高度敏感的資料，出於安全性和法規遵從性的考慮，自行開發可能是必要的。此外，預算也是影響決策的重要因素。如果內部開發可能導致預算超支，採購現成方案可能更為合適。反之，如果現成方案無法滿足預算要求，自行開發可能是唯一的選擇。

以Slack為例，一種可能的策略是先使用供應商的解決方案，確保功能受到客戶歡迎，然後根據收集到的資訊啟動內部解決方案的開發。這種方法可以降低風險，並確保新開發的系統能夠滿足實際需求。

值得注意的是，隨著技術的發展，某些原本需要自定義解決方案的問題現在可以透過簡單的API呼叫來解決。例如，在2020年代，大多數自然語言處理問題都可以使用大語言模型（LLM）API來解決，這使得從頭開始構建這樣的模型變得不那麼有吸引力。

開源技術與專有技術的選擇

另一個需要面對的決策是在開源技術和企業級專有技術之間做出選擇。這通常取決於系統的非功能性需求，如所需的正常執行時間、延遲和負載承受能力等。對於不需要緊急支援的系統，開源解決方案通常是一個安全的選擇。然而，對於高負載、任務關鍵型系統，依賴像特定供應商這樣的巨頭可能更為明智。同時，也可以購買開源解決方案的企業級支援，這是一種折衷的方案。

問題分解

問題分解是軟體工程師工具箱中最有用的工具之一，對於ML系統設計尤其重要。當面臨看似無法解決的複雜問題時，可以應用「分而治之」的方法。

一個典型的例子是搜尋引擎設計。搜尋引擎需要在數百毫秒內從資料函式庫中提供相關的搜尋結果。這可以分解為兩個主要屬性：相關性和快速性。為了實作這一點，可以採用兩階段系統：第一階段是快速的候選篩選，第二階段是對篩選出的候選專案進行更複雜的排名。這種方法在許多搜尋引擎中已經使用了幾十年。

問題分解的原因

問題分解有多種原因，包括：

計算複雜度：透過分解問題，可以減少所需的計算量。
提高準確性：透過多步驟處理，可以提高最終結果的準確性。

在電腦視覺領域，也常見到類別似的多步驟管道：首先應用深度學習模型，然後進行後處理以獲得最終答案。在處理文字和其他半結構化資料時，一個步驟提取結構化資料，下游則使用更受限的模型處理這些結構化資料。

問題分解的必要性與應用

在機器學習（ML）系統的設計中，問題分解是一種常見且重要的策略。將複雜問題分解為較小的子問題，可以提高系統的準確性、可靠性和可維護性。這種方法利用了不同演算法的優勢，避免了單一模型的侷限性，並且能夠更好地處理邊緣案例。

為何需要問題分解

演算法不完美：在某些情況下，先前的步驟可能存在錯誤，而後續步驟可以用來調整這些錯誤。這與提升演算法家族（boosting algorithms families）的原理相似。
利用演算法的優勢，避免弱點：例如，在影像中計數物體時，使用卷積神經網路（CNN）進行迴歸分析可能不是最佳選擇，因為CNN的池化層可能會丟失關鍵資訊。相反，可以先使用物件檢測模型，然後應用經典的電腦視覺演算法來計數輪廓。
資料融合需求：ML模型無法直接從其他來源取得資料，因此常見的做法是先執行模型，然後根據結果取得額外資料，並在下游處理融合後的資料。
處理邊緣案例：ML模型可能會失敗，而分解問題可以幫助及早解決這些問題。例如，可以使用簡單的模型或條件檢查來評估輸入資料的有效性。
對不同資料子集應用不同的模型或邏輯：在某些情況下，模型對大部分使用者有效，但難以推廣到整個使用者群。這時，可以根據簡單的啟發式方法將使用者路由到不同的模型或系統路徑。

問題分解的實際應用

在擴增實境公司中，一個虛擬試穿鞋子的應用程式需要結合多種演算法，包括檢測腳部在影片流中的位置並渲染所選鞋子的遮擋演算法。最初，遮擋演算法存在許多問題，直到公司的CTO提出了一個自有的演算法，才解決了大部分情況下的問題。儘管這個演算法有許多缺點，但它在大多數情況下有效，成為早期產品釋出中的寶貴資產。後來，團隊開發了一個新的方法，解決了舊演算法的大部分缺點，並替換了Pipeline中的一步，從而提高了整體體驗。

機器學習系統設計的趨勢

過去，機器學習系統的設計傾向於構建具有多個小型的、順序執行的元件的Pipeline。然而，隨著深度學習模型的興起，趨勢轉向了端對端單一模型的方法。這種方法可以捕捉更複雜的資料關係，不受手動設計的假設和限制，並且減少了步驟之間的錯誤累積。

語音處理的例子

在語音處理領域，端對端文字轉語音（TTS）模型直接將文字輸入對映到音訊波形，而不需要明確的語言資訊作為中間表示。雖然端對端模型取得了成功，但它們往往需要資料函式庫的支援。最近，像GPT-4這樣的大語言模型（LLM）取得了令人印象深刻的零樣本效能，但它們計算成本高，容易產生幻覺（即將錯誤資訊呈現為真實）。目前的研究正在探索如何結合LLM的優勢與可維護的外部資訊源。

選擇適當的創新程度

在設計機器學習（ML）系統時，瞭解所需的創新程度至關重要。不同的領域和競爭環境對ML系統的準確性和創新性有不同的要求。有些領域需要大量的研究投資，而有些領域則可以使用基本的ML解決方案。

定義創新程度

要確定所需的創新程度，首先需要問利益相關者一個簡單的問題：最終產品應該有多好（即準確度）？常見的答案是“完美”、“100%”或“盡可能好”。然而，這些答案往往模糊不清，實際上意味著“在滿足其他約束條件的前提下盡可能好”。時間和預算是兩個明顯的約束條件。

根據我們的經驗，大多數ML系統可以分為三個類別：

最低可行ML系統：這是一個非常基本的解決方案，可能存在各種故障模式。這類別系統通常被視為基線或原型，不期望有太多的創新。
平均人類水平ML系統：許多成功的ML系統尚未達到人類水平的表現，但仍然對公司有價值。達到這種表現需要一定程度的研究和創新。
最佳級ML系統：在競爭激烈的領域，如交易、廣告技術或全球性產品（如搜尋引擎），ML系統需要超越大多數競爭對手。即使是準確度的微小變化也可能導致數百萬美元的利潤或損失。

創新程度與問題空間和解決方案空間之間的橋樑

所需的創新程度與問題空間和解決方案空間之間的橋樑密切相關。在“最低可行系統”類別中，創新程度為零，只需使用已知最簡單、最快的解決方案即可。在另一端，“最佳級ML系統”則需要持續的創新。

實作創新的實用方法

知道了所需的創新程度和系統的高層結構，就可以尋找更低層次的實作想法。目前，有五個流行的資訊來源可供參考：

ARXIV

ARXIV（https://arxiv.org/）是一個發布學術論文的網站，主要涵蓋科學、技術、工程和數學學科。電腦科學及其子學科佔了其中很大一部分。

ARXIV是一個瞭解學術界對您問題看法的良好場所。除了閱讀與關鍵字相關的所有內容外，我們鼓勵您使用引文和連結機制：一旦找到相關論文，您可能會對閱讀它提到的舊論文和參照它的新論文感興趣。

使用ARXIV的工具

ARXIV本身可能看起來有點原始，因為很難閱讀所有的新論文，而且其搜尋機制從現代的角度來看有些原始。有許多流行的工具可以簡化探索過程。目前，我們推薦使用https://arxivxplorer.com/，這是一個現代化的搜尋工具。

#### 內容解密：

本文主要介紹了在設計ML系統時，如何選擇適當的創新程度。我們首先需要了解利益相關者對最終產品的期望，並根據時間和預算等約束條件來定義所需的創新程度。然後，我們將ML系統分為三個類別：最低可行ML系統、平均人類水平ML系統和最佳級ML系統。最後，我們介紹瞭如何尋找實作創新的實用方法，包括使用ARXIV和相關工具來探索學術界對問題的看法。

為何選擇合適的創新程度如此重要？

選擇合適的創新程度對於設計成功的ML系統至關重要。它可以幫助我們在滿足業務需求的同時，避免不必要的創新投入，從而節省時間和資源。同時，它也可以確保我們的ML系統具有足夠的競爭力，能夠在市場上脫穎而出。

3.4 選擇適當的創新程度

在學術研究和實務開發中，找到正確的創新程度至關重要。本文將探討如何利用各種資源進行初步研究，以確定解決方案的可行性和創新程度。

論文與程式碼資源

Papers with Code

Papers with Code（https://paperswithcode.com/）是一個匯集學術論文及其對應程式碼實作的平台。該網站按照主題分類別論文，並在可能的情況下根據效能進行排名。使用者可以找到與特定問題相關的頂級論文、其評估指標、相關元資料（如是否需要額外資料）以及公開的程式碼實作連結。對於那些偏好直接檢視程式碼而非正式學術寫作的人來說，這是一個非常有價值的資源。

# 範例：使用 Papers with Code 搜尋特定任務的頂級模型
import requests

def search_top_models(task_name):
    url = f"https://paperswithcode.com/task/{task_name}"
    response = requests.get(url)
    # 解析網頁內容，提取頂級模型的資訊
    # ...
    return top_models

# 使用範例
top_models = search_top_models("image-classification")
print(top_models)

內容解密：

搜尋特定任務的頂級模型：此函式示範如何使用 Papers with Code 網站搜尋特定任務（如影像分類別）的頂級模型。
解析網頁內容：透過傳送 HTTP 請求取得網頁內容，並解析 HTML 以提取所需資訊。
傳回頂級模型列表：函式傳回與指定任務相關的頂級模型列表。

開源平台與資源

GitHub

Hugging Face

Hugging Face 模型中心（https://huggingface.co/models）是一個匯集大量機器學習模型和資料集的平台。截至撰寫本文時，該中心已包含超過 56 萬個公開可用的機器學習模型。該平台對模型進行了精確的分類別和標籤，並且許多模型提供了小型互動式網頁演示以展示其功能。

# 範例：使用 Hugging Face Transformers 函式庫載入預訓練模型
from transformers import AutoModelForSequenceClassification, AutoTokenizer

def load_pretrained_model(model_name):
    model = AutoModelForSequenceClassification.from_pretrained(model_name)
    tokenizer = AutoTokenizer.from_pretrained(model_name)
    return model, tokenizer

# 使用範例
model, tokenizer = load_pretrained_model("bert-base-uncased")
print(model.config)

內容解密：

載入預訓練模型：此函式示範如何使用 Hugging Face Transformers 函式庫載入預訓練的序列分類別模型及其對應的分詞器。
使用預訓練模型進行推理：透過載入預訓練模型，使用者可以快速將其應用於自己的任務中。
自定義模型名稱：使用者可以指定不同的預訓練模型名稱來載入不同的模型。

競賽平台

Kaggle

Kaggle（https://kaggle.com）是目前最流行的機器學習競賽平台。許多組織利用 Kaggle 舉辦競賽，吸引全球頂尖的機器學習從業者參與競爭。在競賽過程中，參賽者分享他們的想法和程式碼片段。競賽結束後，獲勝者和領先者通常會公開他們的解決方案。

# 範例：使用 Kaggle API 下載競賽資料集
import os
from kaggle.api.kaggle_api_extended import KaggleApi

def download_competition_dataset(competition_name):
    api = KaggleApi()
    api.authenticate()
    api.competition_download_files(competition_name, path="./data", force=True, quiet=False)

# 使用範例
download_competition_dataset("titanic")
print("資料集下載完成！")

內容解密：

下載競賽資料集：此函式示範如何使用 Kaggle API 下載指定競賽的資料集。
驗證 API 身份：透過驗證 Kaggle API 的身份，使用者可以存取和下載競賽資料。
指定下載路徑：使用者可以指定資料集的下載路徑。

實務案例：建立有效的搜尋系統

假設一家圖片函式庫公司希望建立一個有效的搜尋工具，以便客戶能夠根據文字查詢找到最相關的圖片。在這種情況下，首先需要進行初步研究，以瞭解現有的解決方案和技術提供商。透過研究類別似問題的解決方案、學術論文和開源專案，可以更好地理解問題的全貌並做出更可靠的決策。

設計檔案的準備與重要性

在定義了系統要解決的問題、列出了相關利益相關者，並對合適的技術與解決方案有了初步瞭解之後（正如第三章所述），接下來便是準備設計檔案。

設計檔案的撰寫時機與彈性

值得注意的是，在建立機器學習（ML）系統的初期，並沒有固定的動作順序。只要你明確了問題與目標，就可以開始準備設計檔案，特別是在重視交付速度的初創公司中更是如此。

本章涵蓋內容

本章將討論以下主題：

設計檔案的常見誤解
定義反目標以更清晰地聚焦核心目標
根據現有資訊草擬設計檔案
審閱設計檔案
設計檔案的演變過程

選擇適當的創新程度

在進行初步研究時，我們需要考慮到創新程度的選擇。市場上存在著許多導向消費者的專案，它們能夠幫助分類別個人照片集。雖然這些專案不一定能處理數百萬張圖片，但它們通常是開源的，因此可以直接深入程式碼中取得靈感。

此外，還有一些非虛擬商品的交易市場，例如銷售服裝、傢俱等。有些是像亞馬遜這樣的大型平台，有些則是專注於特定領域的小型平台。它們的業務非常依賴搜尋品質，但商品不僅僅是圖片，通常還具有更多的屬性（可能是文字描述或賣家資訊）。這樣的搜尋引擎使用了關於商品的多種資訊，不僅僅是視覺資訊；在機器學習領域，我們稱之為多模態。

搜尋引擎的核心運作原理

大多數搜尋引擎實際上都執行著相同的操作：計算使用者查詢與潛在相關專案（檔案）之間的相關性分數，並根據這個分數對專案進行排序。

相關性 = f(encode_text(查詢), encode_image(專案))

這種架構引出了多個開放式問題：

函式 f 可能屬於哪一類別演算法？
如何對查詢（文字）和專案（圖片）進行編碼？
如何衡量相關性？
如何將使用者反饋納入系統？

每個問題都很寬泛，值得單獨成書或至少多個章節的探討。因此，我們建議在深入研究相關資訊來源時牢記這些問題。

公司現狀與預算限制

公司的現狀與預算限制會影響我們對創新程度的選擇：

公司已經具備基本的搜尋技術，但已經過時且經常產生無關的結果。
公司的業務可以從良好的搜尋功能中受益。目前，許多使用者因為搜尋結果不佳而無法找到所需的圖片，從而離開網站轉向競爭對手。
預算非常有限，但一旦這個專案取得初步成功，就有機會獲得更多的資金用於新的研發計畫。

這些因素表明，我們需要設計一個堅實的系統，同時考慮到預算限制和未來的改進空間。

重點回顧

尋找市場上能夠完全或部分滿足需求的解決方案。如果找到，請思考系統的哪些部分可以使用這些解決方案。
定義系統的高層檢視。嘗試將其繪製成三到五個區塊，讓非技術主管也能理解。
建構或購買的兩難選擇可能成為決定是自行開發元件還是購買第三方產品的關鍵因素。為了正確處理，需要考慮各種內部和外部因素，包括可用的時間和所有相關團隊的能力。
檢查可能需要分解問題的因素列表。如果正在解決的問題符合其中任何一點，那麼很可能也需要對其進行分解。
可能會有強烈的誘惑去交付最先進的產品；儘管如此，仍需要問自己是否準備好為創新而投資於該系統，以及這種投資是否能在第一時間就獲得回報。
不要猶豫，透過流行的線上聚合器來尋找可以作為參考的案例。

設計檔案的撰寫與審閱

一旦明確了系統要解決的問題、利益相關者，並對適當的技術和解決方案有了初步的瞭解，接下來就需要準備設計檔案。設計檔案的撰寫是一個關鍵步驟，它能夠確保專案的方向正確並且所有相關人員都對專案目標和實作路徑有清晰的認識。

玄貓 BlackCat

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。

機器學習系統設計決策與問題分解

建構還是購買：開源或專有技術的抉擇

建構還是購買的抉擇

核心業務與非核心業務的區分

經濟考量

開源與專有技術的比較

建構還是購買的決策因素

推薦購買的情況

推薦建構的情況

機器學習系統設計中的關鍵決策與問題分解

自行開發還是採購現成方案

開源技術與專有技術的選擇

問題分解

問題分解的原因

問題分解的必要性與應用

為何需要問題分解

問題分解的實際應用

機器學習系統設計的趨勢

語音處理的例子

選擇適當的創新程度

定義創新程度

創新程度與問題空間和解決方案空間之間的橋樑

實作創新的實用方法

ARXIV

使用ARXIV的工具

#### 內容解密：

為何選擇合適的創新程度如此重要？

3.4 選擇適當的創新程度

論文與程式碼資源

Papers with Code

內容解密：

開源平台與資源

GitHub

Hugging Face

內容解密：

競賽平台

Kaggle

內容解密：

實務案例：建立有效的搜尋系統

設計檔案的準備與重要性

設計檔案的撰寫時機與彈性

本章涵蓋內容

選擇適當的創新程度

搜尋引擎的核心運作原理

公司現狀與預算限制

重點回顧

設計檔案的撰寫與審閱

玄貓 BlackCat