Google TFX 名詞小註解

聽說 Google 喜歡用自己的 tool, 跟外面的世界都不一樣, 不過這方面我們就不深究了. 本篇專門看 Tensorflow Extended (TFX) 這個 platform 包含那些東西. 就算是我們用不到這套 tool, 也能夠從它的架構複雜度, 理解到為何 Machine Learning 的 code size 只佔整套 AI 系統 5% 的原因.

本圖取材自 https://www.tensorflow.org/tfx?hl=zh-tw

其中幾個重點用我的話翻譯如下:

ExampleGenerator – 攝取 (ingest) 資料, 區分成 training set 和 evaluation sets.

StatisticsGen – 產生數據集的統計資料. (最大值, 均值, 缺值….etc.)

SchemaGen – 對於數據集 (dataset) 產生 schema , 各種數據的 type (e.g. floating).

ExampleValidator – 在數據集抓出異常資料.

Transform – feature engineering. 抓出 feature, 進行轉換.

Tuner – 找出最佳 hyper parameter 參數給 Trainer 用

Trainer – 實際訓練 model.

Evaluator – 評估 model 是否比 baseline 好

InfraValidator – 將 ExampleGen 輸出的合格 data 餵給 Trainer, 測試 model 是否能正確運行?

Pusher – 將 InfraValidator 驗證過的 model push 到 deployment 環境.

BulkInferrer – 終於可以做大量的 inference 了.

除了測試數據有沒有問題? model 有沒有問題? 後續還要有追蹤機制, 看看 model 是否不準了? 不準的原因看是 data drift 還是 data skew. 然後線上做更正處理. 總不能老是暫停服務吧! CI/CD 這部分就屬於 MLOP (Machine Learning Operation) Level 2 的範圍. 夭壽的是還有 level 3.

Data drift 包括 feature drift 和 concept drift. 前者像是叫外送的變多了, 所以交通流量和 training model 時已經不同. 後者像是病毒特徵被抓到後, 新的病毒把特徵改了, 所以舊 model 偵測不到. 輸出造成輸入的改變, 所以叫做 concept drift.

Data Skew 是說每個地區的使用習慣不同, 所以某特定區域就特別不適合先前訓練出來的 model. 像是台灣學生有午睡時間, 此時大家都沒有活動, 對世界其他地方就是一種異常. 這種狀況也需要線上監控把問題抓出來, 最後可能是加個 feature (location) 重 train.

一般人都不會想到還需要動態檢測 model 合不合用? 想想這還真是一個巨大的成本.

分散式機器學習小註解

先前學過的 Tensorflow model training, 久而久之也還給老師了. 今天趁颱風假學習分散式的機器學習, 順便把基本功也補一些回來!

需要分散式學習的原因就是 AI (ML) model 太大了, 因此有各式各樣的方法把工作分散給不同的 CPU, GPU, TPU (後續用 NPU 涵蓋之). 分散的方法包括把 training data 分散給大量 NPU, 或是把 model 的不同層拆給不同的 NPU 做. 後者比較沒有參數及時互通的問題就略過不談.

Data 分散出去給不同的 NPU 學習, 最明顯的問題就是大家拿到的 data 不同, 算出來的 gradient 理論上也不同, 那要麼收斂到同一版呢? 解決這個問題的架構 (architecture) 有兩個大方向, 分別為 synchronous 和 Asynchronous 兩種.

Synchronous 架構下, 每個 NPU 都要等其它 NPU 做完一個段落. 然後大家同步一下參數. 同步的方式可能只是將大家得到的數取個平均. 假設原本一個 update grdient 的段落是一個 batch. 現在有 N 個NPU 均分 data, 所以每個 NPU 只要做一個 mini-batch.

mini-batch = batch * strategy.num_replicas_in_sync (e.g. 1/N)

在一台機器有多個 NPU 的時候, 我們稱這個策略為 mirrorstrategy. 因為每個 NPU 做的事情都一樣, 像是照鏡子. 假如我有多台機器, 每一台機器 (worker) 都執行 mirrorstrategy, 此時稱為 multi-worker mirror strategy. 實際上的精神都是一樣的. 就是三個動作:

  1. 初始化:所有 worker 從相同的初始模型參數開始。
  2. 同步:取一個段落, 每個 worker 把自己的 grafient 傳出去. 每個 worker 看到其他所有 worker 的資料後, 做個計算 (像是取平均). 因為只要有一個 worker 沒更新, 大家都缺一筆資料, 所以不需要中控也可以自動進行.
  3. 參數更新:每個 worker 使用同步的梯度, 以 optimizer 更新其模型參數, 確保所有工作者在每一步都有相同的模型參數。

至於 asynchronous architecture 就沒有互等的機制, 參數 (weight, bias) 會放在一個以上的 parameter server (PS). 大家都去跟它要參數就對了. 等到 worker 算出自己的 gradient, 就把它傳給 PS, PS 負責用大家的 gradient 更新出新的參數給下一個 worker 抓取. 講義原文如下:

Each worker independently fetches the latest parameters from the parameter servers and computes gradients based on a subset of training samples. It then sends the gradients back to the parameter server, which then updates its copy of the parameters with those gradients.

由 Asynchronous 的架構會有大量的資料要傳遞 (weight, bias), 所以適合用在參數大多是 0 的 sparse model. 而參數大多不是 0 的 dense model (如 BERT, GPT) 就更適合 synchronous architecture. 言下之意是傳的時候多少會做壓縮吧!

MirroredStrategy 的 sample code 如下, 藍色字是和普通 training 不一樣的地方. 特別留意是 model 這行退縮到 with strategy.scope(): 的下一層.

import tensorflow as tf
import tensorflow_datasets as tfds

# Load the dataset

datasets, info = tfds.load(name='mnist', with_info=True, as_supervised=True)
mnist_train, mnist_test = datasets['train'], datasets['test']

# Define the distribution strategy
strategy = tf.distribute.MirroredStrategy()
print('Number of devices: {}'.format(strategy.num_replicas_in_sync))

# Set up the input pipeline
BUFFER_SIZE = 10000
BATCH_SIZE_PER_REPLICA = 64
BATCH_SIZE = BATCH_SIZE_PER_REPLICA * strategy.num_replicas_in_sync

def scale(image, label):
    image = tf.cast(image, tf.float32)
    image /= 255
    return image, label

train_dataset = mnist_train.map(scale).cache().shuffle(BUFFER_SIZE).batch(BATCH_SIZE)
test_dataset = mnist_test.map(scale).batch(BATCH_SIZE)

# Build and compile the model within the strategy scope
with strategy.scope():
    model = tf.keras.Sequential([
        tf.keras.layers.Flatten(input_shape=(28, 28, 1)),
        tf.keras.layers.Dense(128, activation='relu'),
        tf.keras.layers.Dense(10)
    ])

    model.compile(loss=tf.keras.losses.SparseCategoricalCrossentropy(from_logits=True),
                  optimizer=tf.keras.optimizers.Adam(),
                  metrics=['accuracy'])

# Train the model
model.fit(train_dataset, epochs=10, validation_data=test_dataset)

2024 年 Q3 投資回顧

今年的 Q3 相當低迷, 希望 Q4 不要變本加厲!

在 2024/7/16 創下歷史新高之後, 後面遇到 AI 類泡沫化疑雲, 美債降息, 美元貶值, 以及其他不確定因素, 導致股票資產明顯縮水. 8 月初甚至創下單日跌掉十幾個月薪水的記錄, 累積最大跌幅也曾來到 -7.5%. 這個 X 位數字若發生在 2008 年, 等於是天塌了! 還好累積16 年複利也不是講假的, 放到現在就還好而已. 我還幫老婆加了薪水壓壓驚 (粉飾太平).

這季唯二的變動是賣出美國短債 SGOV 和所有的波克夏持股. 除了台股 0050, 其他股票都主要是搭配 DRIP 股息再投入. 老巴是我的長久以來的學習對象. 多年來, 他能夠用一套不變原則選股, 長抱而且賺錢 – 這是我信奉老巴的理由. 但是現在教主的核心持股竟然變化得比我還快,我就沒有那種信奉宗教的情懷了. (臉書上另外一位台灣不 buy 教主最近被酸爆了, 不過這位和老巴不能相提並論.)

在賣掉 BRK.B 的持股後, 因為怕谷下有谷, 坑下有坑, 故遵守紀律地沒有在低點 all in 大盤. 相較於繼續信奉老巴神教, 這個舉動小虧 15 萬多. 理論上即使 BRK 和 QQQ 的股價不再拉開, QQQ 和 PFF 多配幾次息也是可以補回來. 畢竟老巴都不配息 – 這點對想要領月配的老人本來就不利! 這也是我不想永遠持有波克夏的原因之一. 既然終究要賣, 就下定決心賣.

目前單季結算投資收益從高點滑落 3.6%, 比去年底成長 21.9%, 稅後 3 個季度業外收入/全年業內收入的比降到 3.95 倍 (BTW, 螃蟹已經開獎, 所以全年收入也知道了). 只要大環境沒有發生太大的變化, 業外收入這部分預期將遙遙領先! 也沒啥好比了. 我希望我們部門明年業績爆發, 這樣我和同事們都能賺更多錢! 至於投資的這部分, 基本上我就是續抱美股的大盤, 科技股, 特別股加一點液體股票 (可樂和石油). 雖然油價最近跌很多, 但我沒有覺得不妥, 順其自然發展就好!

賀!

今天是 2024/9/17, 也是龍年的中秋節. 平安是福, 此為首賀!

桃園地景節 – 憲光二村

再賀的是: 經過 2 年漫長的等待, 我比較滿意的其中一個專利, 終於在美國通過了. 其實這個專利有四胞胎. 台灣四個都過了. 美國也過了第一個, 這是好的開始.

猶憶我 2022 年有點囂張地記錄下 2 個月得到 3 個美國專利的戰績, 這兩年老天就讓我校正回歸. 足足乾旱了兩年. 才等到現在我的第 9 號! 希望它的兄弟姊妹都能夠登上影神圖.

最後一賀是: 自從黑悟空在黑風大王那裡卡住之後, 我就用上了 “悟空 多功能修改器" 鎖血看劇情. 剛剛也告一段落. 雖然沒有全收集. 不過 " 81 難" 好歹觀賞完 64 難. 可以收工了.

黑悟空真的比較難打. 我承認如果不作弊我絕對打不贏楊戩和大聖殘軀. 我自信能跟二郎神一博的技能是翹二郎腿。

每次天命人被打死都要拔頭上的一根毛去土地廟上香. 我在想,如果遊戲夠寫實的話. 天命人將會變成禿子. 跟一拳超人一樣 (變強了頭也禿了) !

這張比天真頂好看一點

BTW, 跟艾爾登法環 DLC 相比. 那邊我只有最後一隻拉塔恩打不過是靠毒死的. 其他多打兩下還 OK. 頂多就是把搖桿玩壞, 必須要買新的而已.

為黃金律法犧牲的 gamepad

雖然官方日前更新削弱拉塔恩的戰力, 但毒死也是一種實力. 我不想重打了. 何況光是下毒失敗都死了好多次.

隱身丟出腐敗壺之後, 用擬態樹枝假裝是石獅子.

Model.pb 小註解

這個檔案是用來放 model 的 protocol buffer, 所以叫做 pb. 當我們對 input raw data 做了一些前處理, 然後才去 train model. 那使用這個 model 的天命任意人, 怎麼知道要用那些 pre-processing 的手法來處理他的真實資料呢? 沒錯! 就是去看這個 model.bp.

Model.bp 不只是記錄 metadata 這麼簡單, 它只是三個主要功能之一. 這三個功能分別是:

  1. Model Graph: 把 model 的 graph 記下來. 這個 graph 不是個圖檔, 是資料結構裡面的 graph, 它定義了 model 的資料流向.
  2. Metadata: 主要是 input 和 output 的 tensor information. 不論是做前處理或是後處理都會參考到.
  3. Portability: Model 作者最初可能是用 Tensorflow, Tensorflow Lite, 或者Tensorflow.JS 開發, 使用者 deploy 的 platform 不同於作者時, 也可以參考這個檔案獲得相容性資訊.

講到前處理, 另一個 keyword 是 tf.Transform. 這個 library 專門做 Tensorflow 的前處理用. Graph 也是它產生的. tf.Transform 整合了 Apache Beam, (Google) cloud Dataflow, 和 TensorFlow 兩種不同的處理方式 [1][2].

請留意 tf.Transform 是在 pre-process 階段做 feature engineering, 而 Apache Beam 和 Cloud Dataflow 是在 feature creation 階段. 所以後者提供 API 給 tf.Transform 使用. 第三個可以執行 feture engineering 的階段是 train model. 在 [1] 裡面寫了 1,2,3 三個圈圈, 順序和我提到的相反, 但是那沒關係, 只是做個區隔.

附帶一提 Beam 可以用更多的 programming language, 像是 Java, Python, 和 SQL. Tensorflow 基本上多了 C++, Javascript, 少了 SQL. 總之學 Python 就對了.

[REF]

  1. https://ithelp.ithome.com.tw/articles/10227075
  2. https://www.tensorflow.org/tfx/transform/get_started
  3. https://towardsdatascience.com/hands-on-apache-beam-building-data-pipelines-in-python-6548898b66a5