Lecture6 (lecture 6.pdf, 33 หน้า) · 2603520 Deep Learning

Keras Callbacks, TensorBoard และ Hyperparameter Tuning

ห้าบทที่ผ่านมาเราสร้าง "เครื่องยนต์" จนครบ — Lesson 1 สอนว่า cost function กับ gradient descent คืออะไร, Lesson 2–3 สอนว่า neural network คำนวณไปข้างหน้าและ backpropagate กลับมาอย่างไร, Lesson 4 สอน optimizer กับ regularization, Lesson 5 สอนว่าทำไม network ลึกๆ ถึงเทรนไม่ขึ้นและจะแก้ด้วย initialization/Batch Norm อย่างไร. บทที่ 6 นี้ไม่ได้เพิ่มคณิตศาสตร์ใหม่ แต่ตอบคำถามภาคปฏิบัติสองข้อที่เหลืออยู่:

1. ระหว่างที่โมเดลกำลังเทรนอยู่ เราสั่งให้มันทำอะไรอัตโนมัติได้บ้าง? → นั่นคือ callbacks (สไลด์หน้า 1–14)
2. ก่อนจะเทรน เราจะเลือกค่าอย่าง learning rate / จำนวน layer / dropout rate อย่างมีระบบได้อย่างไร? → นั่นคือ hyperparameter tuning (สไลด์หน้า 19–32)

ตรงกลางระหว่างสองเรื่อง (สไลด์หน้า 15–18) อาจารย์พาย้อนกลับไปดูปัญหา vanishing/exploding gradient ของ Lesson 5 อีกครั้ง แต่คราวนี้ดูด้วยตาผ่าน TensorBoard ซึ่งเป็นเครื่องมือที่เพิ่งสอนไปในหน้า 11–13 — สองเรื่องนี้จึงร้อยต่อกัน ไม่ใช่เรื่องแยก.

1. Callback คืออะไร: "ผู้ช่วยข้างสนาม" ที่ Keras เรียกให้เอง

เริ่มจากปัญหาก่อน (ทำไมถึงต้องมีสิ่งนี้): สมมติคุณสั่ง model.fit(X, y, epochs=50) แล้วเดินไปกินข้าว กลับมาเจอสามสถานการณ์นี้ ซึ่งทุกคนที่เทรนโมเดลจริงเคยเจอหมด:

• "มันดีที่สุดตอน epoch 31 แต่ฉันเทรนไปถึง 50" — val_loss ลดถึงจุดต่ำสุดกลาง ๆ ทาง แล้วค่อยๆ สูงขึ้นเพราะโมเดลเริ่ม overfit. ตอนเทรนจบ weight ที่อยู่ในมือคือของ epoch 50 ซึ่งแย่กว่า epoch 31. ของดีที่สุดผ่านมือไปแล้วแต่เราไม่ได้เก็บ
• "เทรนไป 4 ชั่วโมง แล้ว Colab ตัดการเชื่อมต่อ" — ไม่มีอะไรอยู่บนดิสก์เลย ต้องเริ่ม epoch 1 ใหม่
• "อยากลด learning rate ลงครึ่งหนึ่งตอน epoch 20" — แต่ fit() เป็นกล่องดำ เรายื่นมือเข้าไประหว่างทางไม่ได้

ทางแก้แบบดิบๆ คือเลิกใช้ model.fit() แล้วเขียน loop เทรนเองทั้งหมด เพื่อจะได้แทรกโค้ดของเราเข้าไประหว่าง epoch ได้ — ซึ่งยาว ผิดง่าย และต้องเขียนใหม่ทุกโปรเจกต์. Keras จึงเสนอทางที่สาม: เปิด "ช่องเสียบ" (hook) ไว้ในจุดสำคัญของ loop แล้วให้เราส่ง object เข้าไปหนึ่งตัว object นั้นจะถูกเรียกให้เองเมื่อถึงแต่ละช่อง. object ตัวนั้นคือ callback.

นิยามที่อาจารย์ทำสีไว้ทั้งประโยคคือหัวใจของหน้านี้: callback คือ an object that is passed to model.fit(). It is called by the model at various stages during training และสามารถ specific actions เช่นหยุดเทรนก่อนกำหนด, เซฟโมเดล, หรือปรับ learning rate. แยกคำสำคัญสามคำให้ชัด: (ก) มันเป็น object ไม่ใช่ฟังก์ชันลอยๆ — เราสร้างจาก class แล้วส่ง instance เข้าไป; (ข) called by the model แปลว่าเราไม่เคยเรียกเมธอดพวกนี้เอง Keras เรียกให้; (ค) various stages แปลว่ามีหลายจุดเวลาให้เลือกเสียบ ไม่ใช่จุดเดียว.

คอลัมน์ซ้ายของสไลด์ไล่ชื่อ "ช่องเสียบ" ทั้งหมดที่ Base Callback class มีให้ ซึ่งจับคู่กันเป็น begin/end เสมอ และแยกตามสามโหมดของโมเดล:

จุดที่ข้อสอบชอบหลอกคือคำว่า test: hook ชื่อ on_test_* ไม่ได้หมายถึง test set ของเราเสมอไป — มันหมายถึง "โหมดประเมินผลโดยไม่อัปเดต weight" ซึ่งเกิดขึ้นทุกครั้งที่จบ epoch ถ้าเราส่ง validation_data เข้าไป. ในสคริปต์ที่อาจารย์รันในคาบ callback ที่ดัก on_test_batch_end พิมพ์ออกมา 2 บรรทัดต่อ epoch เพราะ validation มี 50 แถวและ batch ของการประเมินเป็น 32 ⇒ \(\lceil 50/32 \rceil = 2\).

คราวนี้มาดูโค้ดที่สไลด์เขียนไว้ — มันคือการสร้าง callback ของตัวเองจาก base class โดยเลือกเสียบแค่ 3 ช่อง:

from keras.callbacks import Callback

class my_callback(Callback):
    # Called at the beginning of training.
    def on_train_begin(self, logs):
        print("training start")

    # Called at the beginning of a training batch
    def on_train_batch_end(self, batch, logs):
        print(f"End of batch:{batch+1}")

    # Called at the end of an epoch.
    def on_epoch_end(self, epoch, logs):
        print(f"End of epoch:{epoch+1}")

history = model.fit(X, y, validation_data=(Xval, yval), epochs=50,
                    batch_size=64, callbacks=[my_callback()])

ผลลัพธ์ที่คาด (ตัวเลขจากสคริปต์ที่รันในคาบ เมื่อลดเหลือ epochs=3, batch_size=64, train 150 แถว): พิมพ์ training start 1 บรรทัด จากนั้นวนซ้ำ 3 รอบของ End of batch:1 / End of batch:2 / End of batch:3 แล้วตามด้วย End of epoch:1 … จนถึง End of epoch:3. และเมื่อพิมพ์ logs.keys() ดูจะได้ตามตารางนี้ — ข้อมูลที่ callback "มองเห็น" ต่างกันตามจังหวะ:

ตารางนี้อธิบายกฎเหล็กข้อหนึ่งที่จะใช้ทั้งบท: callback ใดๆ ที่ตัดสินใจจาก val_loss (EarlyStopping, ReduceLROnPlateau, ModelCheckpoint แบบ save_best_only) ทำงานได้เฉพาะที่จังหวะจบ epoch เท่านั้น เพราะระดับ batch ไม่มีค่า validation ให้ดู.

ข่าวดีคือของที่ต้องใช้บ่อยมีให้สำเร็จรูปแล้ว ไม่ต้องเขียน class เอง. อาจารย์ทำสีคำกริยาของแต่ละตัวไว้ ซึ่งก็คือ "หน้าที่" ของมันในหนึ่งคำ — ท่องคู่กริยา-ชื่อคลาสนี้ไว้ เพราะข้อสอบชอบสลับ:

• EarlyStopping — Interrupting training when the metrics monitored such as validation loss is no longer improving (ถ้าระบุไว้ ยังเก็บโมเดลที่ดีที่สุดระหว่างเทรนไว้ให้ได้ด้วย). กริยาคือ "ขัดจังหวะ/หยุด" ไม่ใช่ "เซฟ"
• ModelCheckpoint — Saving the current state of the model at different points during training. กริยาคือ "เซฟ" และคำว่า current state บอกว่ามันเซฟสภาพ ณ ตอนนั้น ไม่ได้แปลว่าดีที่สุดโดยอัตโนมัติ
• BackupAndRestore — Back up and restore the training state. ต่างจากตัวบนตรงคำว่า training state (สภาพการเทรน = weight + เลข epoch + optimizer) ไม่ใช่แค่ตัวโมเดล และมันมีหน้าที่ "เอากลับคืนมา" ด้วย
• LearningRateScheduler / ReduceLROnPlateau — Dynamically adjusting the value of the learning rate of the optimizer during training. คำว่า dynamically = เปลี่ยนระหว่างทาง ไม่ใช่ตั้งครั้งเดียวตอน compile
• CSVLogger — Logging training and validation metrics during training. แค่ "จด" ลงไฟล์ ไม่ตัดสินใจอะไรเลย
• TensorBoard — Visualizing training info. learned by the model during training. แค่ "เขียน log ให้โปรแกรมดูกราฟไปอ่าน" ไม่ได้เปลี่ยนการเทรน

คอลัมน์ขวาของสไลด์ยังไล่ callback ทั้งหมดที่ Keras มี ซึ่งมีตัวที่ไม่ได้สอนละเอียดแต่ควรรู้จักชื่อ: Base Callback class, ModelCheckpoint, BackupAndRestore, TensorBoard, EarlyStopping, LearningRateScheduler, ReduceLROnPlateau, RemoteMonitor (ส่งผลไปเซิร์ฟเวอร์อื่น), LambdaCallback (เขียน callback สั้นๆ จากฟังก์ชันเดียว), TerminateOnNaN (หยุดทันทีเมื่อ loss เป็น NaN — โยงกับอาการ exploding gradient ใน §7), CSVLogger, ProgbarLogger (แถบความคืบหน้าที่เราเห็นตอน fit ก็เป็น callback!), SwapEMAWeights.

จับคู่ "ปัญหาที่เจอ → callback ที่ใช้" ให้ได้ ก่อนจะลงรายละเอียดทีละตัว:

2. EarlyStopping: หยุดเมื่อไม่ดีขึ้นตามเกณฑ์ที่กำหนด

ปัญหาก่อน: เราตั้ง epochs=50 เพราะเดาว่า "น่าจะพอ" แต่ความจริงคือกราฟ val_loss มักลดลงช่วงแรก แตะจุดต่ำสุดที่ไหนสักแห่ง แล้วค่อยๆ ไต่ขึ้นเพราะโมเดลเริ่มจำ training set (overfit — Lesson 4). เทรนต่อหลังจุดนั้นจึงเป็นการเสียเวลาและทำให้โมเดลแย่ลง. แต่จุดต่ำสุดอยู่ epoch ไหน เราไม่รู้ล่วงหน้า — ต้องให้โปรแกรมเฝ้าดูแทน.

แต่ "แย่ลง" ตัดสินยากกว่าที่คิด เพราะ val_loss ไม่ได้ลดเรียบๆ มันกระเพื่อมขึ้นลงทุก epoch (validation มีแค่ 50 แถว เปลี่ยนไปนิดเดียวก็แกว่ง). ถ้าหยุดทันทีที่แย่ลง 1 ครั้ง เราจะหยุดเพราะ noise. EarlyStopping จึงมี "ปุ่มปรับความอดทน" ให้สองตัว คือ patience (ยอมให้แย่ติดกันได้กี่ครั้ง) และ min_delta (ดีขึ้นเท่าไรถึงจะนับว่าดีขึ้นจริง).

ประโยคที่อาจารย์ทำสีไว้เป็นคำนิยามที่ใช้ตอบข้อสอบได้เลย: EarlyStopping จะ Stop training when the monitored performance metric shows no sufficient improvement ต่อเนื่องเป็นจำนวน epoch ที่กำหนดด้วย patience และเลือกได้ว่าจะให้คืน weight ของ epoch ที่ดีที่สุดกลับมาไหมด้วย restore_best_weights=True. คำที่ต้องอ่านช้าๆ คือ no sufficient improvement — ไม่ใช่ "แย่ลง" เฉยๆ แต่คือ "ดีขึ้นไม่พอตามเกณฑ์" ซึ่งรวมกรณี "ดีขึ้นนิดเดียว" เข้าไปด้วย. นี่คือที่มาของ min_delta.

from tensorflow.keras.callbacks import EarlyStopping

# min_delta can define how much improvement is required
early_stopping_cb = EarlyStopping(monitor='val_loss', patience=5,
                                  min_delta=0.001, restore_best_weights=True)

history = model.fit(X, y, validation_data=(Xval, yval), epochs=50,
                    batch_size=150, callbacks=[early_stopping_cb])

ผลลัพธ์จริงที่พิมพ์ในสไลด์ (คัดมาจาก log ของหน้า 3 — คอลัมน์ที่ใช้ตัดสินใจคือ val_loss ตัวสุดท้ายของแต่ละบรรทัด):

อ่านตารางนี้ให้เป็นคือได้ครึ่งบทแล้ว: คอลัมน์ loss (ของ train) ลดลงเรื่อยๆ ตลอด 0.4030 → 0.2965 ไม่มีสะดุด แต่ val_loss ลงไปแตะก้นที่ 0.4750 ตอน epoch 31 แล้วกลับสูงขึ้นเป็น 0.5149 — นี่คือหน้าตาของ overfitting ที่เห็นด้วยตัวเลข: โมเดลเก่งขึ้นกับข้อมูลที่เคยเห็น แต่แย่ลงกับข้อมูลที่ไม่เคยเห็น. ถ้าเราดูแต่ loss อย่างเดียวจะไม่มีวันรู้ว่าต้องหยุด — เหตุผลที่ monitor ต้องเป็น val_loss ไม่ใช่ loss.

หน้า 4 คืองานที่อาจารย์ทำให้ดูทีละบรรทัดว่ากลไกตัดสินใจอย่างไร และปิดท้ายด้วยหมายเหตุสามดาว: "การจะนับว่าดีขึ้น ต้องลด val_loss ได้อย่างน้อย 0.001 เทียบกับค่าที่ดีที่สุดเท่าที่ผ่านมา". ประโยคท้ายนี้สำคัญกว่าที่เห็น — ลองไล่ตามเองทีละขั้น:

กติกาที่ใช้ตัดสินแต่ละ epoch (เมื่อ monitor เป็นค่าที่ยิ่งน้อยยิ่งดีอย่าง val_loss):

"ค่าดีที่สุดเดิม ลบ ค่าใหม่" ต้องมากกว่าหรือเท่ากับเกณฑ์ ถึงจะนับว่าดีขึ้น

• ถ้าเป็นจริง → นับเป็น "ดีขึ้น": อัปเดต best ให้เป็นค่าใหม่ และรีเซ็ตตัวนับ patience เป็น 0
• ถ้าไม่จริง → ตัวนับ patience +1; เมื่อตัวนับแตะ patience ก็หยุดเทรน

หลักฐานว่าการคืน weight มีผลจริง — สไลด์หน้า 3 ให้ผลการ evaluate สามชุดไว้เทียบ ซึ่งเป็นตัวเลขที่ตอบคำถาม "แล้วมันต่างกันเท่าไร":

0.4750 เทียบกับ 0.5149 คือส่วนต่าง 0.0399 ของ loss ที่ได้มาฟรีๆ จากการเติมอาร์กิวเมนต์ตัวเดียว. และสังเกตอีกอย่าง: test loss (0.3819) ต่ำกว่า validation loss (0.4750) ซึ่งดูแปลก แต่ไม่ผิด — ทั้งสองชุดมีแค่ 50 แถว การสุ่มแบ่งจึงทำให้ชุดหนึ่งบังเอิญง่ายกว่าอีกชุดได้ง่ายมาก. บทเรียนคืออย่าอ่านตัวเลขทศนิยมตำแหน่งท้ายๆ ของ dataset จิ๋วเป็นเรื่องจริงจัง (อาจารย์เองเขียนหมายเหตุนี้ไว้ในสคริปต์ว่า "for experiment only").

3. บันทึกโมเดล: save, save_weights และ ModelCheckpoint

ปัญหาก่อน: §2 จบลงด้วยโมเดลที่ดีที่สุดอยู่ในหน่วยความจำ ปิด notebook ปุ๊บก็หายหมด. และถ้าเทรนนาน 4 ชั่วโมงแล้วเครื่องดับตอนชั่วโมงที่ 3 ก็ไม่เหลืออะไร. เราจึงต้องรู้สองเรื่อง: (ก) เซฟโมเดลด้วยมือทำอย่างไร และเซฟ "อะไร" ได้บ้าง (สไลด์หน้า 5) (ข) จะให้มันเซฟอัตโนมัติระหว่างเทรนอย่างไร (หน้า 6–8).

อาจารย์แยกหัวข้อหน้านี้เป็นสองบรรทัดที่ทำสีไว้: Saving and Loading Models Weights กับ Saving and Loading Models — ต่างกันแค่คำว่า Weights คำเดียว แต่ผลต่างกันมาก. แบบแรกเก็บเฉพาะ "ตัวเลขในโมเดล" แบบที่สองเก็บ "ทั้งตัวโมเดล". เปรียบเทียบง่ายๆ: การเซฟ weight เหมือนจดแต่คำตอบของข้อสอบลงกระดาษเปล่า — ถ้าไม่มีตัวข้อสอบ (โครงสร้างโมเดล) อยู่ในมือ คำตอบนั้นก็ใช้ไม่ได้ จึงต้อง build_model() ขึ้นมาใหม่ก่อนเสมอ; ส่วนการเซฟทั้งโมเดลเหมือนถ่ายเอกสารทั้งข้อสอบพร้อมคำตอบ หยิบมาใช้ได้เลย.

# save weights only
model.save_weights('my_model.weights.h5')

# rebuild the model
model = build_model()
model.load_weights('my_model.weights.h5')
model.get_weights()

# save the model
model.save('my_model.keras')   #Keras_Format

# load the model
from keras.models import load_model
model = load_model('my_model.keras')
model.summary()

ผลลัพธ์ที่คาด (ตามที่สไลด์แสดงหลังโหลด my_model.keras): แผงไฟล์แสดงสองไฟล์คือ my_model.keras และ my_model.weights.h5 ส่วน model.summary() พิมพ์ layer สี่ชั้น Hidden1/Hidden2/Hidden3/Output พร้อม Param # = 30, 110, 110, 11 และท้ายตาราง Total params: 785 (3.07 KB), Trainable params: 261 (1.02 KB), Non-trainable params: 0 (0.00 B), Optimizer params: 524 (2.05 KB).

สรุปความต่างที่ต้องตอบให้ได้:

ตัวเลข 785 / 261 / 524 ในสไลด์ไม่ได้มาลอยๆ — มันคำนวณได้ และเป็นโจทย์ที่ออกสอบง่ายมาก:

ทีนี้เอาการเซฟมาใส่ในการเทรนให้อัตโนมัติ. สไลด์สรุปว่า ModelCheckpoint saves the model (or its weights) during training, typically at the end of each epoch by default และให้ทางเลือกสองทางคือ Save models กับ Save weights only — ซึ่งก็คือคู่ model.save / model.save_weights ของหน้า 5 นั่นเอง แต่ถูกเรียกให้เองทุกจบ epoch.

from keras.callbacks import ModelCheckpoint

model_checkpoint_cb = ModelCheckpoint('my_model.weights.h5', save_weights_only=True)
history = model.fit(X, y, validation_data=(Xval, yval), epochs=5, batch_size=64,
                    callbacks=[model_checkpoint_cb])

from keras.callbacks import ModelCheckpoint

model_checkpoint_cb = ModelCheckpoint('my_model.keras')
history = model.fit(X, y, validation_data=(Xval, yval), epochs=5, batch_size=64,
                    callbacks=[model_checkpoint_cb])

ผลลัพธ์ที่คาด: เทรนจบได้ไฟล์เดียว (my_model.weights.h5 หรือ my_model.keras) ที่ถูกเขียนทับใหม่ทุกจบ epoch. เพราะชื่อไฟล์ตายตัว ไฟล์สุดท้ายที่เหลือจึงเป็นของ epoch ที่ 5 (epoch สุดท้าย) เสมอ — ไม่ใช่ epoch ที่ดีที่สุด. ในสคริปต์ที่รันในคาบจึงเห็นผลนี้ชัด: โมเดลที่ค้างในหน่วยความจำ (มาจาก EarlyStopping ที่ restore แล้ว) ให้ test_loss 0.4264 แต่ weight ที่โหลดจากไฟล์ checkpoint ให้ 0.3993 — คนละตัวกัน. นี่คือเหตุผลที่ต้องมีหน้าถัดไป.

สไลด์หน้า 7 เติมสามอาร์กิวเมนต์ที่เปลี่ยน "เซฟทุก epoch" ให้เป็น "เซฟเฉพาะตอนดีที่สุด" และย้ำท้ายหน้าว่า EarlyStopping มักถูกใช้คู่กับ ModelCheckpoint. ความหมายของแต่ละตัวตามที่สไลด์เขียน:

# more saving criteria such as saving weights only
from keras.callbacks import ModelCheckpoint

checkpoint_path = 'checkpoint/my_model.weights.h5'
model_checkpoint_cb = ModelCheckpoint(checkpoint_path, save_weights_only=True,
                                      save_best_only=True, monitor='val_accuracy', mode='max')

model = build_model()
history = model.fit(X, y, validation_data=(Xval, yval), epochs=30, batch_size=64,
                    callbacks=[model_checkpoint_cb])

ผลลัพธ์ที่คาด: ในโฟลเดอร์ checkpoint/ มีไฟล์เดียวคือ my_model.weights.h5 ซึ่งเป็น weight ของ epoch ที่ val_accuracy สูงสุด. เมื่อ build_model() แล้ว load_weights ไฟล์นี้มาประเมิน สคริปต์ในคาบได้ test accuracy 0.8400 / test loss 0.3570 ซึ่งดีกว่าทั้งโมเดลในหน่วยความจำ (0.7800) และไฟล์แบบไม่ใช้ save_best_only (0.8000) ของการทดลองก่อนหน้า.

แล้ว EarlyStopping กับ ModelCheckpoint ใช้คู่กันอย่างไร? แบ่งหน้าที่กันชัดเจน: EarlyStopping ตัดสินใจเมื่อไหร่หยุด (และคืน weight ที่ดีที่สุดเข้าหน่วยความจำถ้าสั่ง restore_best_weights), ส่วน ModelCheckpoint(save_best_only=True) ทำให้มีไฟล์ของตัวที่ดีที่สุดอยู่บนดิสก์ — เผื่อโปรแกรมพังก่อนจะได้ใช้ และเผื่อเอาไปใช้วันหลัง. ถ้าใช้ ModelCheckpoint เฉยๆ โดยไม่ตั้ง save_best_only ไฟล์ที่ได้จะเป็นของ epoch ที่ตามหลัง best ไป patience รอบพอดี (ในตัวอย่าง §2 คือ epoch 36 แทนที่จะเป็น 31).

อาร์กิวเมนต์สุดท้ายของ ModelCheckpoint คือ save_freq ซึ่งสไลด์อธิบายว่าควบคุม how often the model is saved: ถ้าใส่ค่า "epoch" (ค่าเริ่มต้น) = เซฟตอนจบทุก epoch; ถ้าใส่จำนวนเต็ม = เซฟทุกๆ N batch ของการเทรน. ความเข้าใจผิดอันดับหนึ่งคือคิดว่า save_freq=6 แปลว่า "ทุก 6 epoch" — ไม่ใช่ มันคือ "ทุก 6 batch" และ batch นับสะสมข้าม epoch.

from keras.callbacks import ModelCheckpoint

checkpoint_path = 'checkpoint/my_model.weights.h5'
#checkpoint_path = 'checkpoint/my_model.{epoch}.{batch}.weights.h5'
model_checkpoint_cb = ModelCheckpoint(checkpoint_path, save_weights_only=True,
                                      monitor='val_accuracy', mode='max', save_freq=6)
model = build_model()
history = model.fit(X, y, validation_data=(Xval, yval), epochs=5, batch_size=64,
                    callbacks=[model_checkpoint_cb])

from keras.callbacks import ModelCheckpoint

#checkpoint_path = 'checkpoint/my_model.weights.h5'
checkpoint_path = 'checkpoint/my_model.{epoch}.{batch}.weights.h5'
model_checkpoint_cb = ModelCheckpoint(checkpoint_path, save_weights_only=True,
                                      monitor='val_accuracy', mode='max', save_freq=6)
model = build_model()
history = model.fit(X, y, validation_data=(Xval, yval), epochs=5, batch_size=64,
                    callbacks=[model_checkpoint_cb])

4. BackupAndRestore: เทรนต่อได้หลังถูกขัดจังหวะ

ปัญหาก่อน: ModelCheckpoint เก็บ "ของดี" ไว้ให้ก็จริง แต่ถ้า Colab ตัดการเชื่อมต่อตอน epoch 27 จาก 50 ไฟล์ที่มีคือ weight ล้วนๆ — เราไม่รู้ว่าเทรนไปถึง epoch ไหนแล้ว, ไม่มี momentum ของ optimizer, และถ้าสั่ง fit ใหม่มันจะเริ่มนับ epoch 1 ใหม่หมด. สิ่งที่ต้องการคือการ "หยุดชั่วคราวแล้วเล่นต่อ" ไม่ใช่ "เก็บผลงาน".

ประโยคที่ทำสีไว้คือคำจำกัดความ: callback นี้ back up and restore the training state after an interruption โดยเซฟ training state ซึ่งสไลด์วงเล็บบอกไว้ว่าประกอบด้วย weights, epoch number และอื่นๆ. คำว่า training state ตรงนี้คือคำที่แยกมันออกจาก ModelCheckpoint ทั้งหมด: ModelCheckpoint เก็บ "ผลงาน" (โมเดลเอาไปใช้งาน) แต่ BackupAndRestore เก็บ "บุ๊กมาร์ก" (เล่มเดิม หน้าเดิม).

callback = keras.callbacks.BackupAndRestore(backup_dir="/tmp/backup", save_freq='epoch')

ผลลัพธ์ที่คาด: เมื่อการเทรนถูกขัดจังหวะแล้วเรียก fit ใหม่ด้วยอาร์กิวเมนต์ชุดเดิม จำนวน epoch ที่รันจริงจะน้อยกว่าที่สั่ง — ในสคริปต์ที่รันในคาบ (สั่ง epochs=10 แต่ถูกขัดที่ epoch index 4) len(history.history['loss']) พิมพ์ออกมาเป็น 6.

สไลด์ยังระบุกติกาอีก 4 ข้อที่ต้องจำ เพราะมันคือจุดที่คนใช้ผิดกันบ่อย:

5. ปรับ Learning Rate ระหว่างเทรน และบันทึกผลลง CSV

ปัญหาก่อน: learning rate \(\alpha\) ในสูตรอัปเดต \(\theta := \theta - \alpha\,\nabla J\) (Lesson 1) คือ "ขนาดก้าว". ช่วงต้นเราอยู่ไกลจากจุดต่ำสุดมาก อยากก้าวใหญ่เพื่อเข้าใกล้เร็วๆ; ช่วงท้ายเราอยู่ใกล้ก้นชามแล้ว ก้าวใหญ่จะกระโดดข้ามไปมาไม่ลงสักที. ค่าเดียวจึงไม่เหมาะกับทั้งสองช่วง — แต่ compile() ให้เราตั้งได้ครั้งเดียวตอนเริ่ม. callback สองตัวนี้คือทางออก.

สไลด์อธิบายกลไกไว้เป็นประโยคเดียว: ที่ต้นของทุก epoch callback จะไปเอา updated learning rate value from schedule function แล้วเอาค่านั้นไปใส่ให้ optimizer. สองคำนี้บอกทุกอย่าง — (ก) updated คือค่าใหม่ ไม่ใช่ค่าเดิม; (ข) มันมาจาก schedule function ที่เราเขียนเอง Keras ไม่ได้คิดสูตรให้. และสไลด์ระบุสเปกของฟังก์ชันนั้นไว้ชัด: รับ epoch index (จำนวนเต็ม เริ่มจาก 0) กับ current learning rate (ทศนิยม) แล้วคืน a new learning rate as output (ทศนิยม). อีกอาร์กิวเมนต์คือ Verbose ซึ่งเป็น int: 0 = เงียบ, 1 = พิมพ์ข้อความบอกทุกครั้งที่เปลี่ยนค่า.

5.1 LearningRateScheduler: เขียนสูตรเอง

# Define the learning rate schedule function
def lr_function(epoch, lr=0.01, decay_rate=0.9, decay_steps=10000):
    # compute the learning rate for the current epoch
    exp = np.floor((1 + epoch) / decay_steps)
    alpha = lr * (decay_rate ** exp)
    # return the learning rate
    return float(alpha)

history = model.fit(X, y, validation_data=(Xval, yval), epochs=50, batch_size=10,
                    callbacks=[keras.callbacks.LearningRateScheduler(lr_function, verbose=1)])

# callbacks=[keras.callbacks.LearningRateScheduler(lr_function, verbose=1),
#            keras.callbacks.CSVLogger("results.csv")])
# This callback streams the results from each epoch into a CSV file.

เขียนสูตรเป็นคณิตศาสตร์ (ให้ \(\alpha\) = learning rate ปัจจุบันที่ Keras ส่งเข้ามา, \(r\) = decay_rate, \(s\) = decay_steps, \(e\) = epoch index เริ่มที่ 0):

เอา learning rate ปัจจุบันมาคูณด้วย \(r\) ยกกำลัง "จำนวนชั้น" โดยชั้นจะเพิ่มขึ้น 1 ทุกๆ \(s\) epoch

5.2 ReduceLROnPlateau: ลดเมื่อ "ติดแหง็ก" (ไม่ต้องเขียนสูตรเอง)

ข้อเสียของ 5.1 คือเราต้องเดาล่วงหน้าว่าควรลดตอน epoch ไหน ทั้งที่ยังไม่เห็นด้วยซ้ำว่าโมเดลจะติดขัดตรงไหน. ReduceLROnPlateau พลิกตรรกะ: ไม่ลดตามตารางเวลา แต่ลดเมื่อวัดได้ว่าไม่คืบหน้าแล้ว — ใช้เกณฑ์เดียวกับ EarlyStopping เป๊ะ (monitor, patience, min_delta) ต่างกันแค่ว่าเมื่อครบเงื่อนไขแล้ว EarlyStopping "หยุด" ส่วนตัวนี้ "ลด learning rate แล้วไปต่อ".

ReduceLROnPlateau(monitor='val_loss', patience=4, min_delta=0.001,
                  factor=0.1, min_lr=0.001), early_stopping_cb,
keras.callbacks.CSVLogger("results.csv")])

ผลลัพธ์ที่คาด: คอลัมน์ learning_rate ในไฟล์ csv จะเป็นขั้นบันได — ในสคริปต์ที่รันในคาบ (เริ่มที่ 0.03) ค่าคงที่ 0.03 จนถึง epoch 9 แล้วกลายเป็น 0.0030 ที่ epoch 10 และ 0.0010 ที่ epoch 14 จากนั้นค้างที่ 0.0010 ยาวจนจบ epoch 50.

กติกาการลดเขียนเป็นสูตรได้สั้นๆ:

ลดลงเป็นสัดส่วน แต่ถ้าลดแล้วต่ำกว่าพื้นที่กำหนดไว้ ให้ใช้ค่าพื้นแทน

สรุปเทียบสองตัวให้ชัด เพราะข้อสอบชอบถามว่า "ควรใช้ตัวไหนเมื่อไร":

ส่วน CSVLogger นั้นง่ายที่สุดในบท: CSVLogger("results.csv") รับแค่ชื่อไฟล์ แล้วเขียน logs ของทุก epoch ต่อท้ายลงไฟล์ — ไม่มีการคำนวณ ไม่มีการตัดสินใจ ไม่กระทบการเทรนใดๆ ทั้งสิ้น. ประโยชน์คือเอาไฟล์ csv ไปเปิดใน pandas/Excel เพื่อวาดกราฟเทียบหลายการทดลอง โดยไม่ต้องเก็บ history ไว้ในหน่วยความจำ.

6. TensorBoard: ดูการเทรนเป็นภาพ

ปัญหาก่อน: สิ่งเดียวที่เราเห็นระหว่างเทรนคือตัวเลขสี่ตัววิ่งผ่านหน้าจอ (loss, accuracy, val_loss, val_accuracy). ถ้าโมเดลเทรนไม่ขึ้น ตัวเลขพวกนี้บอกแค่ว่า "ไม่ขึ้น" แต่ไม่บอกทำไม. คำถามอย่าง "weight ของ layer แรกขยับบ้างไหม" หรือ "การกระจายของ weight เปลี่ยนไปอย่างไรตลอด 20 epoch" ตอบไม่ได้เลยจากตัวเลขสี่ตัวนั้น. TensorBoard คือเครื่องมือที่ทำให้เห็นข้างใน.

อาจารย์นิยาม TensorBoard ว่าเป็น Browser-based application that monitor a variety of information during training. คำว่า browser-based สำคัญกว่าที่คิด: มันไม่ใช่ฟังก์ชัน Python ที่คืนค่ากลับมา แต่เป็นเว็บแอปแยกต่างหาก ที่ไปอ่าน "ไฟล์ log" ที่ Keras เขียนทิ้งไว้ — เพราะงั้นขั้นตอนจึงมีสองฝั่งเสมอ: ฝั่ง Keras เขียน log (ผ่าน callback) กับฝั่งเราเปิดเว็บอ่าน log. สไลด์สรุปสิ่งที่ดูได้ไว้ 4 ข้อ: ดู metric (accuracy, loss) ระหว่างเทรน, ดูการกระจายและ histogram ของ weight กับ bias, ดู computational graph ของโมเดล, และอื่นๆ เช่นสำรวจรูปภาพ. แล้วปิดท้ายว่า Keras ผลิตไฟล์ log พวกนี้ผ่าน TensorBoard callback โดยเรา "แค่ระบุว่าอยากให้เขียน log ไว้ที่ไหน".

from tensorflow.keras.callbacks import TensorBoard

tensorboard_callback = TensorBoard(log_dir='/full path to your log directory')

model.fit(X_train, y_train, epochs=20, validation_split=0.2, callbacks = tensorboard_callback)

ผลลัพธ์ที่คาด: ไม่มีอะไรพิมพ์เพิ่มบนหน้าจอนอกจาก progress bar ปกติ — ผลลัพธ์คือไฟล์ในโฟลเดอร์ log_dir (ชื่อแบบ events.out.tfevents... แยกเป็นโฟลเดอร์ย่อย train/ และ validation/) ที่ต้องเปิดด้วยเว็บ TensorBoard ถึงจะเห็น.

อ่านกราฟ loss สองแบบที่สไลด์เอามาเทียบ: แผงที่ชื่อ "Model does not learn anything" มี loss แกว่งอยู่ระหว่างประมาณ 11.0 ถึง 15.0 ตลอดตั้งแต่ step ที่ 400 จนถึง 2,800 โดยค่าเฉลี่ยไม่ลดลงเลย — ขึ้นลงแบบนี้คือ noise ของการสุ่ม batch ไม่ใช่การเรียนรู้. ส่วนแผง "Model learns all the informations" loss เริ่มที่เกิน 25 แล้วดิ่งลงมาราว 10 ภายในประมาณ 1,000 step จากนั้นแบนราบ — รูปตัว L แบบนี้คือหน้าตาปกติของการเรียนรู้ที่สำเร็จ (ลดเร็วตอนต้น แล้วค่อยๆ อิ่มตัว). กฎการวินิจฉัย: ถ้ากราฟของคุณหน้าตาแบบแรก ให้สงสัยสามอย่างตามลำดับ — learning rate (ใหญ่/เล็กเกิน), การ initialize weight, และ vanishing gradient (§7) — ก่อนจะไปโทษว่าข้อมูลไม่พอ.

อ่าน histogram ของ weight/bias: แผง layer1/biases ในสไลด์มีป้ายกำกับเส้นขอบไว้ว่า maximum, 93%, 84%, 69%, median (50%) และ minimum. ความหมายคือแต่ละ epoch (แกนนอนไล่จาก 0 ถึง 1,000 กว่า) เราเอา bias ทั้งหมดใน layer นั้นมาเรียงจากน้อยไปมาก แล้ววาดว่า "ค่ากลางอยู่ตรงไหน (median) และค่าที่กระจายออกไปอยู่แค่ไหน (93%, maximum)". ในภาพนี้แถบเริ่มจากแคบๆ แถว 0.06 แล้วบานออกครอบคลุมช่วงประมาณ 0.06 ถึง 0.16 เมื่อ epoch เพิ่มขึ้น — บานออก = weight กำลังเคลื่อนที่ = กำลังเรียนรู้; ถ้าแถบแบนนิ่งเป็นเส้นตรงแปลว่า weight แทบไม่ถูกอัปเดตเลย ซึ่งเป็นเบาะแสของ vanishing gradient หรือ learning rate ที่เล็กเกินไป. เครื่องมือชิ้นนี้คือสิ่งที่ §7 จะใช้ทั้งหมด.

หน้า 12 ไล่ว่าในเว็บ TensorBoard มีแท็บอะไรให้ดูบ้าง จับคู่ "อยากรู้อะไร → ไปแท็บไหน" ได้ดังนี้:

ในภาพหน้าจอจริงของสไลด์ แถบ Runs ด้านซ้ายมีสี่รายการที่ชื่อขึ้นต้นด้วย 20210314-132517 และ 20210314-132602 โดยแต่ละอันแยกเป็น /train กับ /validation — นี่คือเหตุผลของการตั้งชื่อโฟลเดอร์ด้วย timestamp ในหน้าถัดไป: ติ๊กเลือกได้ว่าจะเทียบการเทรนรอบไหนกับรอบไหน และกราฟ epoch_accuracy จะวาดทั้งสองเส้นซ้อนกันให้เทียบทันที.

หน้า 13 ให้ขั้นตอนครบทั้งฝั่งเปิดเว็บและฝั่งเขียน log. ฝั่งเปิดเว็บใน notebook คือสามบรรทัดสั้นๆ: %load_ext tensorboard (โหลดส่วนขยาย), log_folder = 'logs' (ตั้งชื่อโฟลเดอร์), %tensorboard --logdir={log_folder} (เปิดหน้าเว็บฝังใน notebook). สไลด์ยังมีคำสั่งล้าง log เก่าไว้ด้วย (!rm -rvf logs สำหรับ Colab, rm -rvf logs สำหรับ Jupyter) เพราะถ้าไม่ล้าง log ของการทดลองเก่าจะปนกับของใหม่ในกราฟเดียวกัน.

# specify the TensorBoard callback during the model's fit method.
from keras.callbacks import TensorBoard

callbacks = [TensorBoard(log_dir=log_folder,
                         # set 1 if activation and weight histograms will be computed
                         histogram_freq=1,
                         # set True if the graph will be visualized in TensorBoard
                         write_graph=True,
                         # determines how losses and metrics are written to TensorBoard
                         update_freq='epoch')]

ผลลัพธ์ที่คาด: หลังเทรนเสร็จ แท็บ Scalars มีกราฟ epoch_accuracy กับ epoch_loss (อย่างละ 2 เส้น: train/validation), แท็บ Graphs มีผังโมเดล, และแท็บ Histograms มีแผงหนึ่งคู่ต่อ layer (dense_X/bias_0 กับ dense_X/kernel_0) ครบทุก layer.

เรื่องสุดท้ายของหน้า 13 คือการตั้งชื่อโฟลเดอร์แบบมี timestamp: สไลด์เขียน log_folder = "logs/fit/" + datetime.datetime.now().strftime("%Y%m%d-%H%M%S") แล้วยกตัวอย่างผลลัพธ์ว่า 20210315-031559. อ่านรหัสนี้ทีละส่วน: 2021 ปี, 03 เดือนมีนาคม, 15 วันที่, แล้ว 03 ชั่วโมง, 15 นาที, 59 วินาที — รวมเป็น "15 มี.ค. 2021 เวลา 03:15:59". เหตุผลที่ต้องทำคือทุกครั้งที่รันจะได้โฟลเดอร์ใหม่ไม่ซ้ำ ⇒ TensorBoard เห็นเป็นคนละ "run" ⇒ เอามาวาดซ้อนกันเทียบได้ (เหมือนสี่ run ในหน้าจอของหน้า 12) แทนที่จะเขียนทับกันมั่วจนอ่านไม่ออก.

หน้า 14 เป็นแบบฝึกหัดที่เตรียมข้อมูลสำหรับการทดลองใน §7. โจทย์คือชุดข้อมูล "วงกลมซ้อนวงกลม": จุดสีแดง (label 1) อยู่วงใน รัศมีประมาณ 0.5 และจุดสีน้ำเงิน (label 0) อยู่วงนอก รัศมีประมาณ 1.0 โดย noise=0.1 ทำให้แต่ละจุดกระเด็นออกจากวงเล็กน้อยจนสองวงเบียดกัน. ความสำคัญของข้อมูลชุดนี้คือเส้นตรงเส้นเดียวแยกมันไม่ได้เลย — ไม่ว่าจะลากเส้นตรงอย่างไรก็จะมีทั้งแดงและน้ำเงินอยู่ทั้งสองฝั่ง — จึงเป็นโจทย์ที่ logistic regression ตัวเดียวทำไม่ได้และต้องมี hidden layer (เหตุผลเดียวกับ XOR ใน Lesson 2).

from sklearn.datasets import make_circles
X_train, y_train = make_circles(1000, noise = 0.1)
X_train.shape
# (1000, 2)

import matplotlib.pyplot as plt
# Find Indices of Positive and Negative Examples
pos = y_train == 1
neg = y_train == 0
# Plot Examples
fig = plt.figure()
plt.plot(X_train[pos, 0], X_train[pos, 1], 'o',
         markerfacecolor='r', markersize=8, markeredgecolor='k')
plt.plot(X_train[neg, 0], X_train[neg, 1], 'o',
         mfc='b', ms=8, mec='k')
plt.xlabel('X_train')
plt.title('Circle Dataset')
plt.ylabel('y')
plt.legend(['positive', 'negative'])
plt.show()

ผลลัพธ์ที่คาด: X_train.shape พิมพ์ (1000, 2) และได้กราฟ scatter ที่จุดแดงกระจุกเป็นวงในกับจุดน้ำเงินเป็นวงนอก ตามภาพในสไลด์.

7. ทดลองดู Vanishing/Exploding Gradient ด้วย TensorBoard

ทำไมหัวข้อนี้มาอยู่ตรงนี้: Lesson 5 พิสูจน์ด้วยสูตรว่า gradient หดหายหรือระเบิดได้เมื่อ network ลึก แต่ตอนนั้นเรายัง "มองไม่เห็น" มัน. ตอนนี้เรามี TensorBoard แล้ว อาจารย์จึงพาย้อนกลับมาทำการทดลองสามชุดบนข้อมูล Circle ชุดเดียวกัน (หน้า 14) เปลี่ยนทีละอย่างแล้วดู histogram ว่าอะไรเกิดขึ้นกับ weight จริงๆ. นี่คือทักษะ "วินิจฉัยโรค" ที่ข้อสอบชอบถามในรูป "เห็นอาการแบบนี้ สาเหตุคืออะไร".

อาจารย์ทำสีคำว่า Gradients vanishing ไว้ แล้วอธิบายต่อว่ามันทำให้ gradient เล็กลงเรื่อยๆ เมื่อไล่ลงไปยัง layer ล่าง ผลคือการอัปเดตแบบ gradient descent ทิ้งให้ weight ของ layer ล่าง virtually unchanged (แทบไม่เปลี่ยน) และ training never converges to a good solution. สองวลีที่ขีดเส้นใต้นี้คือ "อาการ" ที่เราจะไปหาหลักฐานใน TensorBoard.

def build_model():
    model = keras.models.Sequential([
        keras.layers.Dense(5, input_dim=2, activation='tanh', kernel_initializer=RandomUniform(0,1)),
        keras.layers.Dense(5, activation='tanh', kernel_initializer=RandomUniform(0,1)),
        keras.layers.Dense(5, activation='tanh', kernel_initializer=RandomUniform(0,1)),
        keras.layers.Dense(5, activation='tanh', kernel_initializer=RandomUniform(0,1)),
        keras.layers.Dense(5, activation='tanh', kernel_initializer=RandomUniform(0,1)),
        keras.layers.Dense(1, activation='sigmoid')])

    model.compile(optimizer=SGD(lr=0.01, momentum = 0.9),
                  loss='binary_crossentropy',
                  metrics=['accuracy'])

    #fit the model and pass in the callback
    model.fit(X_train, y_train,
              epochs=20,
              validation_split=0.2,
              callbacks = callbacks)
    return model

ผลลัพธ์ที่คาด: เทรน 20 epoch แล้ว accuracy ค้างอยู่แถว 0.50 ตลอด — ในสคริปต์ที่รันในคาบ epoch สุดท้ายได้ accuracy: 0.5163 - loss: 0.6930 - val_accuracy: 0.4800 - val_loss: 0.6948. ตัวเลข 0.5 คือความแม่นยำของการเดาสุ่มในงานสองคลาส และ 0.693 คือ \(\ln 2\) ซึ่งเป็นค่า binary cross-entropy ของโมเดลที่ทำนาย 0.5 ให้ทุกตัวอย่าง — พูดอีกอย่างคือโมเดลไม่ได้เรียนรู้อะไรเลยแม้แต่นิดเดียว.

ทำไมถึงเป็นอย่างนั้น? ตัวการคือบรรทัด kernel_initializer=RandomUniform(0,1). ลองตามตัวเลขดู:

ทางแก้ที่ 1 — เปลี่ยนเป็น ReLU + He initialization. สไลด์สั่งสั้นๆ ว่า "Change the code and observe the weight of each layer" โดยเปลี่ยน activation='tanh' เป็น 'relu' และ kernel_initializer=RandomUniform(0,1) เป็น 'he_normal'. เหตุผลของทั้งสองอย่างมาจาก Lesson 5 ตรงๆ: ReLU มีความชัน 1 คงที่เมื่อ \(z > 0\) จึงไม่มีการอิ่มตัวให้ gradient หาย; ส่วน He initialization สุ่ม weight จากการแจกแจงที่มีค่าเฉลี่ย 0 และ variance \(2/n_{in}\) ⇒ ผลรวม \(z\) ไม่พุ่งไปทางบวกอย่างเดียว.

ผลที่เห็นใน histogram ของแผงบน (layer ชื่อ dense_92 ถึง dense_97): แถบของ bias_0 เริ่มจากศูนย์แล้วบานออกเรื่อยๆ ตลอด 20 epoch จนครอบคลุมช่วงราว \(+0.1\) ถึง \(-0.2\) ส่วนแถบ kernel_0 กว้างประมาณ \(\pm0.8\) และค่อยๆ ขยับ — แปลว่า weight ทุก layer กำลังถูกอัปเดตจริง. ในสคริปต์ที่รันในคาบ โมเดลชุดนี้ (ReLU + He, SGD lr = 0.01, momentum 0.9) เทรน 50 epoch แล้วได้ accuracy: 0.7538 - loss: 0.5176 - val_accuracy: 0.7500 - val_loss: 0.5165 — จาก 0.5163 (เดาสุ่ม) ขึ้นมาเป็น 0.75 เพราะแก้แค่สองคำในโค้ด.

คำถามต่อของสไลด์ — "How about slow learning rate?" อาจารย์ทดลองอีกกรณีหนึ่งคือใช้ SGD ที่ learning rate 0.0001 และ momentum 0.9 แล้วดู histogram ของ dense_116/dense_117 ที่มุมขวาล่าง: แกนตั้งของ bias_0 ไล่แค่ \(+2\times10^{-4}\) ถึง \(-4\times10^{-4}\) (เทียบกับแผงบนที่ไล่ถึง \(\pm0.2\) — เล็กกว่าราว 500–1,000 เท่า) และแถบ kernel_0 เป็นแนวราบแทบไม่ขยับเลยตลอด 20 epoch.

ตรงนี้คือบทเรียนที่ลึกที่สุดของหน้านี้: กราฟ "แบนราบ" เหมือนกัน แต่สาเหตุคนละเรื่อง — กรณีหน้า 15 weight ไม่ขยับเพราะ \(\nabla J \approx 0\) (gradient หาย), กรณีนี้ weight ไม่ขยับเพราะ \(\alpha\) เล็กมาก ทั้งที่ gradient ปกติดี. ดูจากสูตรเดียวกัน \(\Delta\theta = -\alpha\,\nabla J\) จะเห็นว่าผลคูณเล็กได้จากสองทาง. วิธีแยกในทางปฏิบัติ: ถ้าลองเพิ่ม learning rate แล้วแถบเริ่มบานออก แปลว่าเป็นโรคที่สอง; ถ้าเพิ่มแล้วยังนิ่ง (หรือ layer บนขยับแต่ layer ล่างนิ่ง) แปลว่าเป็นโรคแรก.

อีกด้านของเหรียญคือ Exploding gradients ซึ่งอาจารย์อธิบายว่าทำให้เกิด unstable network ที่อย่างดีที่สุดก็เรียนรู้จากข้อมูลไม่ได้ และอย่างแย่ที่สุดได้ weight เป็น NaN ที่อัปเดตต่อไม่ได้อีกเลย (NaN = Not a Number ซึ่งเกิดจากตัวเลขล้นเกินขอบเขตที่คอมพิวเตอร์เก็บได้ และเมื่อเป็น NaN แล้วทุกการคำนวณต่อจากนั้นก็เป็น NaN หมด). สไลด์ไล่อาการที่สังเกตได้ 3 ข้อ:

def build_model():
    model = keras.models.Sequential([
        keras.layers.Dense(5, input_dim=2, activation='relu', kernel_initializer='he_normal'),
        keras.layers.Dense(5, activation='relu', kernel_initializer='he_normal'),
        keras.layers.Dense(5, activation='relu', kernel_initializer='he_normal'),
        keras.layers.Dense(5, activation='relu', kernel_initializer='he_normal'),
        keras.layers.Dense(5, activation='relu', kernel_initializer='he_normal'),
        keras.layers.Dense(1, activation='sigmoid')])

    model.compile(optimizer=SGD(learning_rate=0.10, momentum = 0.9),
                  loss='binary_crossentropy',
                  metrics=['accuracy'])

    #fit the model and pass in the callback
    model.fit(X_train, y_train,
              epochs=20,
              validation_split=0.2,
              callbacks = callbacks)
    return model

ผลลัพธ์ที่คาด: กราฟ epoch_accuracy ในสไลด์แกว่งอยู่ระหว่างประมาณ 0.465 ถึง 0.515 แบบฟันเลื่อยตลอด 18 epoch (ไม่มีแนวโน้มขึ้น) และ epoch_loss แกว่งอยู่ในช่วงแคบๆ ราว 0.694–0.698 ซึ่งวนอยู่รอบ \(\ln 2 \approx 0.6931\). ส่วน beta/histogram แกว่งขึ้นลงแรงระหว่าง \(-0.1\) ถึง \(+0.2\) แบบไร้ทิศทาง — นั่นคือหน้าตาของ "unstable" ที่สไลด์พูดถึง: ค่าเปลี่ยนเยอะทุก update แต่ไม่ไปไหน. (ในสคริปต์ที่รันในคาบ อาจารย์ดันไปถึง learning_rate=0.2 ผลคือ accuracy 0.5088 / loss 0.6943 ที่ epoch 50 — ยืนยันว่าเทรนไม่ขึ้นเหมือนกัน)

หน้า 18 คือทางแก้ของทั้งสองโรค และไม่ใช่แค่สไลด์ชื่อหัวข้อ — มันมีโค้ดเต็มและกราฟผลลัพธ์. สิ่งที่เปลี่ยนคือแทรก BatchNormalization() เข้าไประหว่าง Dense กับ Activation ของทุกชั้น (คอมเมนต์บรรทัดแรกเขียนว่า # normalize before = normalize ก่อนผ่าน activation) โดยที่ learning rate ยังเป็น 0.10 ตัวเดิมที่ทำให้โมเดลพังในหน้า 17.

# normalize before
def build_model():
    model = keras.models.Sequential([
        keras.layers.Dense(5, input_dim=2, kernel_initializer='he_normal'),
        keras.layers.BatchNormalization(),
        keras.layers.Activation('relu'),
        keras.layers.Dense(5, kernel_initializer='he_normal'),
        keras.layers.BatchNormalization(),
        keras.layers.Activation('relu'),
        keras.layers.Dense(5, kernel_initializer='he_normal'),
        keras.layers.BatchNormalization(),
        keras.layers.Activation('relu'),
        keras.layers.Dense(5, kernel_initializer='he_normal'),
        keras.layers.BatchNormalization(),
        keras.layers.Activation('relu'),
        keras.layers.Dense(5, kernel_initializer='he_normal'),
        keras.layers.BatchNormalization(),
        keras.layers.Activation('relu'),
        keras.layers.Dense(1),
        keras.layers.BatchNormalization(),
        keras.layers.Activation('sigmoid')])

    model.compile(optimizer=SGD(learning_rate=0.10, momentum = 0.9),
                  loss='binary_crossentropy',
                  metrics=['accuracy'])

    #fit the model and pass in the callback
    model.fit(X_train, y_train,
              epochs=20,
              validation_split=0.2,
              callbacks = callbacks)
    return model

ผลลัพธ์ที่คาด: กราฟในสไลด์แสดง epoch_accuracy ไต่ขึ้นจากราว 0.47 ไปถึงประมาณ 0.80 และ epoch_loss ลดจากราว 0.72 ลงมาราว 0.45 ตลอดแกน 0–100 และ kernel/histogram มีแถบที่บานออกจาก \(\pm0.4\) เป็นราว \(-0.8\) ถึง \(+1.2\) — ทั้งสามอย่างคือสัญญาณว่าเรียนรู้ได้จริง. ในสคริปต์ที่รันในคาบ รุ่น "normalize after" ที่ learning rate 0.2 ให้ accuracy: 0.7937 - loss: 0.4558 ที่ epoch 50 เทียบกับ 0.5088 / 0.6943 ของรุ่นไม่มี BN ที่ learning rate เดียวกัน.

8. Hyperparameter Tuning: มีอะไรให้ปรับ และค่าเริ่มต้นที่ควรใช้

ปัญหาก่อน: ตลอดห้าบทที่ผ่านมา ทุกครั้งที่เขียนโค้ดเราต้อง "เลือกตัวเลข" เต็มไปหมด — Dense(10) ทำไมไม่ใช่ 20? learning_rate=0.03 ทำไมไม่ใช่ 0.003? กี่ layer ดี? dropout เท่าไร? ที่ผ่านมาเราเลือกตามที่อาจารย์บอกหรือตามความรู้สึก. หน้า 19–32 ตอบคำถามว่าจะเลือกอย่างมีระบบได้อย่างไร.

อาจารย์เปิดด้วยการเปรียบเทียบที่จำง่าย: hyperparameter เหมือนปุ่มหมุนบนวิทยุเก่า ที่ต้องค่อยๆ หมุนหาจนเสียงชัดที่สุด (คำบรรยายใต้ภาพเขียนว่า "Hyperparameters are like knobs that we need to tune to yield the best performance"). สามประโยคที่ทำสีไว้เรียงกันเป็นเหตุผลครบชุด:

• Hyperparameter tuning finds the best hyperparameter combination for minimizing cost functions — นิยาม. คำสำคัญคือ combination: เราไม่ได้หาค่าที่ดีที่สุดของแต่ละปุ่มแยกกัน แต่หาชุดที่ดีที่สุดพร้อมกัน เพราะปุ่มส่งผลกระทบต่อกัน (เช่น batch size ใหญ่มักต้องการ learning rate ใหญ่ตาม)
• Hyperparameters can be tuned in a manual or automatic way — มีสองทางเลือก: หมุนเอง หรือให้โปรแกรมหมุน
• In deep neural networks, manually tuning hyperparameters can be suboptimal and time-consuming — และเพราะเหตุนี้ Automatic hyperparameter tuning จึงเป็น more efficient approach. สองคำที่ทำสีต้องแยกให้ออก: suboptimal = ได้คำตอบที่ไม่ดีที่สุด (คุณภาพ), time-consuming = เปลืองเวลา (ต้นทุน) — คนละปัญหากัน และการจูนอัตโนมัติแก้ได้ทั้งคู่

ทำไม "โมเดลลึก" ถึงทำให้การจูนด้วยมือแย่เป็นพิเศษ? เพราะจำนวนปุ่มโตตามความลึก (ทุก layer เพิ่มมาก็มีจำนวน unit, activation, dropout rate ของตัวเอง) และการเทรนแต่ละครั้งใช้เวลานาน. คนที่หมุนปุ่มเองจึงลองได้ไม่กี่ชุดและมักติดอยู่กับ "ชุดที่คุ้นเคย" แทนที่จะสำรวจให้ทั่ว.

สไลด์บอกว่า Hyperparameters can be categorized into three main categories ซึ่งเป็นโครงที่ควรท่องให้ได้ เพราะข้อสอบชอบถามว่า "ข้อใดอยู่ในหมวดใด". วิธีจำที่ได้ผลคือถามว่าแต่ละหมวดตอบคำถามอะไร:

สังเกตรายละเอียดที่สไลด์วงเล็บไว้: Batch Normalization (also mitigate overfitting) — BN ถูกจัดอยู่หมวดที่ 2 แต่มีผลข้างเคียงช่วยหมวดที่ 3 ด้วย เพราะสถิติของ mini-batch ที่ต่างกันทุกก้าวทำหน้าที่เป็น noise เล็กๆ คล้าย regularization. ข้อสอบชอบใช้ตัวนี้เป็นตัวหลอกเพราะตอบได้สองหมวด — ถ้าถามว่า "จัดอยู่หมวดไหน" ให้ตอบตามที่สไลด์จัดคือ Learning and optimization.

หน้า 21 เจาะหมวดแรก. หัวข้อย่อยแรกคือ Number of hidden layers and number of neurons และคำแนะนำของอาจารย์สวนสัญชาตญาณของมือใหม่: ให้เลือกโมเดลที่มี layer และ neuron มากกว่าที่จำเป็นจริงๆ เพื่อให้ความจุ (capacity) "large enough" พอจะเรียนรู้ลักษณะของข้อมูลได้ — แต่วงเล็บไว้ว่า but not too complexity. แล้วประโยคที่ทำตัวหนาคือกลยุทธ์: Key is to observe the performance and then fine-tune as needed — คือเริ่มใหญ่ไว้ก่อน ดูผล แล้วค่อยหด. เหตุผลที่ต้องหดก็เพราะถ้าให้ความจุมากเกินไป โมเดล "may tend to overfit the data and memorize the training set" และเมื่อเจออาการนั้นให้ลดจำนวน hidden unit ลงหรือใช้วิธีของหมวดที่ 3.

หัวข้อย่อยที่สองคือ Activation type ซึ่งอาจารย์ให้คำตอบสำเร็จรูปเลย: ReLU และตระกูลของมันเป็น default ที่ดีสำหรับทุก hidden layer; ส่วน output layer "really depends on your task" (งานสองคลาสใช้ sigmoid, หลายคลาสใช้ softmax, ทำนายตัวเลขใช้ linear — ตาม Lesson 3). นี่คือ hyperparameter ที่ไม่ต้องเสียเวลาค้นหา เพราะมีกฎชัดเจนอยู่แล้ว.

หน้า 22 คือหน้าที่ "ให้คำตอบมาเลย" มากที่สุดในบท — อ่านแล้วประหยัดเวลาค้นหาไปเยอะ. ไล่ทีละหัวข้อที่ทำสีไว้:

สองบรรทัดสุดท้ายคือของแถมที่มีค่าที่สุดสำหรับข้อสอบ: การเลือก initializer ไม่ใช่การค้นหา แต่เป็นการจับคู่กับ activation (ReLU↔He, sigmoid/tanh↔Xavier) และ จำนวน epoch ไม่ใช่ hyperparameter ที่ต้องค้นหา เพราะ EarlyStopping จัดการให้แล้ว. สองข้อนี้ตัดมิติของพื้นที่ค้นหาออกไปได้ฟรีๆ ซึ่งสำคัญมากเมื่อเห็นตัวเลขใน §9.

หน้า 23 ไล่หมวดที่สาม และรูปแบบของทุกบรรทัดเหมือนกันหมดคือ "เครื่องมือ → ปุ่มที่ต้องจูนของมัน" ซึ่งเป็นสิ่งที่ต้องจำเป็นคู่:

• L2 regularization → จูน regularization parameter (lambda) คือ \(\lambda\) ในพจน์โทษ \(\frac{\lambda}{2m}\sum\theta^2\) ของ Lesson 4. \(\lambda\) ใหญ่ = บีบ weight ให้เล็ก = โมเดลเรียบขึ้น (underfit ได้ถ้ามากไป)
• Dropout layers → จูน dropout rate = สัดส่วนของ unit ที่ถูกปิดสุ่มในแต่ละก้าว (เช่น 0.2 = ปิด 20%). สูงไปโมเดลเรียนไม่ทัน ต่ำไปก็ไม่ช่วย
• Batch normalization → จูน mini-batch size หรือ momentum parameter ถ้าจำเป็น (ตัวเดียวกับที่หน้า 22 บอกค่า 0.9/0.99/0.999)
• Data augmentation → จูน random transformations metrics คือพารามิเตอร์ของการแปลงข้อมูลแบบสุ่ม (หมุนกี่องศา ซูมเท่าไร พลิกซ้ายขวาไหม) — เป็นการ "สร้างข้อมูลใหม่จากของเดิม" จึงลด overfitting ที่ต้นเหตุคือข้อมูลน้อย

สังเกตว่า Batch normalization โผล่มาทั้งหน้า 20, 22 และ 23 — ย้ำอีกครั้งว่ามันมีสองบทบาท.

หน้า 24 คือ "สูตรสำเร็จ" ของการจูนที่ §10 จะทำตามทุกขั้นด้วย KerasTuner — จำสี่ขั้นนี้ให้ได้ตามลำดับ:

1. ระบุว่าจะจูนอะไรและช่วงไหน — Specify which hyperparameters to tune and their search space. คำว่า search space คือ "พื้นที่ค้นหา" = เซ็ตของค่าที่ยอมให้ลอง (เช่น units ตั้งแต่ 10 ถึง 50, activation หนึ่งในสามตัว) — ถ้าคำตอบที่ดีที่สุดอยู่นอกพื้นที่นี้ เราจะไม่มีวันเจอมัน
2. สร้างโมเดลที่รับค่าเหล่านั้น — Build the corresponding model. คำว่า corresponding คือโมเดลที่ "สอดคล้อง" กับ search space นั้น ๆ คือเขียนให้ตัวเลขที่จะจูนกลายเป็นตัวแปรแทนที่จะเป็นค่าตายตัว
3. เลือกอัลกอริทึมค้นหา — Define the search algorithm ซึ่งมีหน้าที่เลือก next set of hyperparameters ที่จะลองต่อไป โดยอัตโนมัติ ตาม selected search algorithm. นี่คือหัวใจ: สิ่งที่ทำให้ Grid / Random / HyperBand / Bayesian ต่างกันคือวิธีเลือกชุดถัดไป ไม่ใช่วิธีเทรน
4. เซฟตัวที่ดีที่สุดแล้ววัดผลบน test set — Save the best model and measure performance on your test set. ย้ำว่า test set ใช้ตอนท้ายเท่านั้น ไม่เอามาร่วมตัดสินใจระหว่างค้นหา

9. อัลกอริทึมค้นหา: Grid, Random, HyperBand, Bayesian

ปัญหาก่อน: ขั้นที่ 3 ของหน้า 24 บอกให้ "เลือก search algorithm" — แต่เลือกจากอะไร? ทั้งสี่ตัวทำงานเดียวกันคือ "เลือกชุด hyperparameter ชุดถัดไปที่จะลอง" ต่างกันแค่วิธีเลือก และความต่างนั้นแปลเป็นเวลาที่ต่างกันเป็นร้อยเท่า. ไล่จากโง่ที่สุดไปฉลาดที่สุด.

Grid Search คือวิธีที่ตรงไปตรงมาที่สุด: สไลด์บอกว่ามัน explores predefined combinations ของค่า hyperparameter ด้วย systematic brute-force search — แต่ละ hyperparameter ได้รับ "เซ็ตของค่าผู้สมัคร" มาชุดหนึ่ง แล้วโมเดลถูกเทรนและประเมินทุกการจับคู่ที่เป็นไปได้ (every combination). สไลด์ระบุเงื่อนไขการใช้ไว้ชัด: ได้ผลดีเมื่อ model is relatively simple และ search space is small; ส่วนกับ Deep Learning มันเป็นวิธีที่ computationally expensive เพราะต้องเทรนซ้ำหลายชุดมาก.

อ่านรูป Grid Layout ให้ได้ประเด็น: แกนนอนของรูปคือพารามิเตอร์ที่ "สำคัญ" (important parameter — เส้นโค้งสีเขียวด้านบนแสดงว่าคะแนนเปลี่ยนแปลงมากตามแกนนี้ และมียอดแหลมอยู่จุดหนึ่ง) ส่วนแกนตั้งคือพารามิเตอร์ที่ "ไม่สำคัญ" (unimportant parameter — เส้นสีเหลืองด้านซ้ายแทบแบน คะแนนแทบไม่เปลี่ยนไม่ว่าจะตั้งค่าใด). การทดลองทั้งหมดมี 9 จุด = 3 ค่าของแกนนอน × 3 ค่าของแกนตั้ง. ผลคือเราจ่ายค่าเทรน 9 ครั้ง แต่ได้ข้อมูลเกี่ยวกับพารามิเตอร์สำคัญแค่ 3 ค่าเท่านั้น — อีก 6 ครั้งคือการลองค่าเดิมซ้ำโดยเปลี่ยนปุ่มที่ไม่มีผล. และถ้ายอดของเส้นเขียวบังเอิญอยู่ระหว่างสองค่าที่เราเลือก เราจะพลาดมันไปเลย ซึ่งคือสิ่งที่สไลด์ทำสีแดงไว้ว่าได้ (suboptimal solution) — Grid Search หา "ค่าที่ดีที่สุดภายในตารางที่กำหนดไว้ล่วงหน้า" ได้จริง แต่ไม่รับประกันว่าดีที่สุดจริงๆ เพราะอาจพลาดค่าที่อยู่ระหว่างหรือนอกตาราง.

Random Search แก้ปัญหาข้างบนด้วยไอเดียที่ดูไม่น่าจะได้ผลแต่ได้ผลจริง: แทนที่จะลองทุกการจับคู่ ให้สุ่มชุดค่าขึ้นมาตามจำนวนครั้งที่เรากำหนดเอง (a specified number of randomly selected hyperparameter combinations) โดยแต่ละ trial สุ่มค่าของแต่ละ hyperparameter จากช่วงหรือรายการที่นิยามไว้.

อ่านรูป Random Layout เทียบกับรูปก่อนหน้า: จำนวนจุดเท่ากันคือ 9 จุด (งบเท่ากัน) แต่คราวนี้ไม่มีจุดไหนมีพิกัดแกนนอนซ้ำกันเลย ⇒ พารามิเตอร์สำคัญถูกทดสอบถึง 9 ค่าที่ต่างกัน เทียบกับ 3 ค่าของ Grid. โอกาสที่จะมีจุดใดจุดหนึ่งตกใกล้ยอดของเส้นโค้งสีเขียวจึงสูงกว่ามาก ทั้งที่จ่ายเท่ากัน. นี่คือความหมายของวลีที่สไลด์เน้นว่า fewer, more diverse combinations และเหตุผลที่มัน more efficient than Grid Search โดยเฉพาะเมื่อ "only some hyperparameters have a strong effect on model performance" — ซึ่งเป็นสถานการณ์ปกติของ deep learning.

แต่สไลด์ก็ทำสีแดงจุดอ่อนไว้ด้วย: Random Search เป็น blind search — มัน does not use results from previous trials ในการตัดสินใจว่าจะลองอะไรต่อ. trial ที่ 30 สุ่มแบบเดียวกับ trial ที่ 1 เป๊ะ ทั้งที่ตอนนั้นเรามีข้อมูลแล้ว 29 จุดว่าย่านไหนดีย่านไหนแย่. ผลคือ "it may miss promising regions or the best hyperparameter combination within the search space" — มันอาจเดินผ่านย่านที่มีแวว แล้วไม่กลับไปขุดต่อ. สองอัลกอริทึมที่เหลือคือการแก้ข้อนี้คนละทาง.

HyperBand โจมตีจากอีกมุม: แทนที่จะฉลาดขึ้นเรื่อง "เลือกอะไรต่อ" มันฉลาดเรื่อง "จ่ายเท่าไรให้แต่ละตัว". สไลด์บอกว่า HyperBand ใช้วิธี successive halving ในแต่ละรอบด้วย different budgets เพื่อหา best configurations และขยายความว่า: มันใช้ successive halving เพื่อระบุและให้ความสำคัญกับ configuration ที่มีแววอย่างรวดเร็ว พร้อมทั้งทิ้งตัวที่ดูไม่มีแวว; configuration ที่รอดจากการคัดออกจะได้รับงบเพิ่ม (The configurations that survive the elimination are given additional budgets) ทำซ้ำจนเหลือเพียงไม่กี่ตัว และจบเมื่อใช้งบสูงสุดครบ.

สัญชาตญาณเบื้องหลังคือข้อสังเกตง่ายๆ: configuration ที่แย่มักแย่ตั้งแต่ epoch แรกๆ เราไม่จำเป็นต้องเทรนมันครบ 81 epoch ถึงจะรู้. กราฟด้านซ้ายของสไลด์แสดงเส้น loss ของหลาย configuration ที่งบน้อย — เห็นชัดว่าบางเส้นดิ่งลงเร็ว บางเส้นแทบไม่ขยับ ⇒ ตัดเส้นที่ไม่ขยับทิ้งได้ตั้งแต่ยังจ่ายไปนิดเดียว.

ตารางด้านขวาคือการจัดสรรงบจริง โดยมีหัวตารางกำกับว่า max_iter = 81, eta = 3, \(B = 5 \times \text{max\_iter}\). สูตรของแต่ละ bracket คือ (ให้ \(n\) = จำนวน configuration เริ่มต้น, \(r\) = งบเริ่มต้นต่อตัว, \(\eta\) = ตัวหารการคัดออก):

ทุกรอบถัดไป จำนวนผู้รอดหารด้วย \(\eta\) ส่วนงบต่อตัวคูณด้วย \(\eta\)

Bayesian Optimization คือตัวที่ "ฉลาดที่สุด" ในสี่ตัว เพราะมันแก้จุดอ่อน blind search ของ Random ตรงๆ. สไลด์บอกว่ามันก็รันโมเดลหลายครั้งด้วยชุดค่าต่างๆ เหมือนกัน แต่มันประเมิน past model information เพื่อ select hyperparameter values สำหรับสร้างโมเดลตัวถัดไป. ผลคือ "requires less iterations to get to the optimal set" เพราะมันตัดย่านที่เชื่อว่าไม่มีอะไรดีทิ้งไป. และสไลด์ระบุ two key components ไว้สองตัวที่ต้องจำคู่กัน:

• Surrogate model — a probabilistic model that try to learn the true objective function, which forms a mapping ของ hyperparameter ไปยัง "probability score ว่า objective function จะทำได้ดีแค่ไหน". พูดง่ายๆ คือโมเดลตัวแทนที่ราคาถูก: แทนที่จะเทรน network จริง (แพง) เพื่อรู้คะแนนของจุด \(x\) เราให้ surrogate ทำนายให้ (ฟรี) จากจุดที่เคยลองมาแล้ว. ในรูปคือเส้นสีแดงที่พยายามลากตามเส้นประ (true function) โดยอาศัยจุดสีแดงที่สังเกตได้
• Acquisition Function — utilizes the surrogate model แล้วตัดสินว่าย่านไหน worth exploiting (optimum area = ย่านที่คาดว่าคะแนนดี) และย่านไหน worth exploring (area we haven't yet looked = ย่านที่ยังไม่เคยลอง). พูดง่ายๆ คือตัวตัดสินว่าจะลองจุดไหนต่อ ในรูปคือเส้นสีน้ำเงิน — จุดที่เส้นน้ำเงินสูงสุดคือจุดที่จะถูกเลือกลองต่อไป

แถบสีเขียวในรูปคือช่วงความเชื่อมั่น (Upper/Lower Confidence Interval) ซึ่งกว้างตรงที่ยังไม่มีจุดข้อมูลและแคบตรงที่มีจุดหนาแน่น — นั่นคือ "ความไม่แน่ใจ" \(\sigma(x)\) ที่ acquisition function เอาไปใช้.

สไลด์ใช้ acquisition function แบบ UCB (Upper Confidence Bound) ซึ่งเขียนกำกับไว้บนกราฟทั้งสามรูป:

คะแนนที่คาดไว้ บวกโบนัสตามความไม่แน่ใจ โดย \(\lambda\) คือตัวคูณของโบนัส

หมายเหตุใต้รูปของสไลด์สรุปไว้ว่า \(\lambda\) ควบคุม exploration–exploitation trade-off: \(\lambda\) ใหญ่เอื้อย่านที่ไม่แน่ใจ (exploration) ส่วน \(\lambda\) เล็กเอื้อย่านที่คาดว่าคะแนนสูง (exploitation). สังเกตกราฟทั้งสามรูปในสไลด์: ที่ \(\lambda = 0.2\) เส้นน้ำเงินแทบทับเส้นแดง (เชื่อ \(\mu\) เป็นหลัก); ที่ \(\lambda = 1.2\) เริ่มแยกตัวขึ้นตรงย่านที่แถบเขียวกว้าง; ที่ \(\lambda = 5\) เส้นน้ำเงินพุ่งสูงจนสเกลแกนตั้งต้องขยายไปถึง 60 และยอดของมันอยู่ในย่านที่ไม่มีจุดข้อมูลเลย — แปลว่ามันจะไปลองตรงที่ไม่รู้จักก่อน.

สรุปเทียบทั้งสี่ตัวในตารางเดียว (นี่คือรูปแบบข้อสอบที่เดาได้ง่ายที่สุดของหัวข้อนี้):

10. ใช้ KerasTuner: สร้าง HyperModel → เลือก Tuner → ค้นหา → ดึงผล

ปัญหาก่อน: §9 อธิบายอัลกอริทึมไว้หมดแล้ว แต่ถ้าต้องเขียนเองทั้ง loop (สุ่มค่า → สร้างโมเดล → เทรน → จดคะแนน → เลือกชุดถัดไป → ทำซ้ำ) ก็คงไม่ไหว. KerasTuner คือไลบรารีที่ทำ loop นั้นให้ เหลือหน้าที่ของเราแค่สองอย่าง: บอกว่า "โมเดลหน้าตาอย่างไรและปุ่มไหนให้ปรับได้บ้าง" กับ "ใช้อัลกอริทึมไหน".

สไลด์บอกว่า KerasTuner เป็น "general-purpose hyperparameter tuning library" และวิธีใช้เริ่มจากการเขียนฟังก์ชันที่คืนโมเดล Keras ที่ compile แล้ว (aka HyperModel) โดยฟังก์ชันนั้นรับอาร์กิวเมนต์ชื่อ hp สำหรับนิยาม hyperparameter ระหว่างสร้างโมเดล. สไลด์มีหมายเลขกำกับสองจุดในรูป: ❶ ชี้ที่ hp พร้อมคำอธิบายว่า "hp : HyperParameter object to be config to tune" และ ❷ ชี้ที่ return model พร้อมคำว่า "Compiled model with hyperparameters to tune". และย้ำว่ามี hyperparameter หลายชนิดให้ใช้: Int, Float, Choice, Boolean.

แนวคิดที่ต้องเปลี่ยนในหัว: แทนที่จะเขียน Dense(32, ...) ด้วยตัวเลขตายตัว เราเขียน Dense(hp.Int("units", 10, 50)) ซึ่งแปลว่า "ตรงนี้เป็นช่องว่าง ให้ tuner มาเติมเลขระหว่าง 10 ถึง 50 เอง". ฟังก์ชันนี้จะถูกเรียกใหม่ทุก trial และแต่ละครั้ง hp จะแจกค่าคนละชุด.

!pip install keras-tuner

def build_model(hp):
    # build the model
    model = models.Sequential()
    Flatten(input_shape=(X.shape[1:],))
    for i in range(hp.Int("num_layers", min_value=1, max_value=2)):
        model.add(Dense(units=hp.Int("units_" + str(i), min_value=10, max_value=50, step=1),
                        activation=hp.Choice("activation", values=['relu', 'elu', 'selu'])))
        model.add(Dropout(hp.Float("dropout_" + str(i), 0, 0.5, step=0.1)))
    model.add(Dense(1, activation='sigmoid'))

    # compile the model
    model.compile(optimizer=keras.optimizers.Adam(learning_rate=hp.Float("lr", 1e-4, 1e-2, sampling='log')),
                  loss='binary_crossentropy',
                  metrics=['accuracy'])
    return model

# hp : Boolean Example
# Tune whether to use dropout.
if hp.Boolean("dropout"):
    model.add(layers.Dropout(rate=0.25))

ผลลัพธ์ที่คาด: ตัวฟังก์ชันเองไม่พิมพ์อะไร — ผลลัพธ์ของมันคือโมเดลหนึ่งตัวต่อการเรียกหนึ่งครั้ง. สิ่งที่พิมพ์ออกมาจะเห็นตอนเรียก tuner.search_space_summary() ในหน้า 30.

สรุปชนิดของ "ช่อง" ที่ hp เปิดให้ ซึ่งสไลด์ระบุไว้สี่แบบ:

หน้า 30 คือขั้นที่ 3 ของหน้า 24: หลังนิยาม search space แล้วต้องเลือก tuner class และสไลด์ไล่ชื่อไว้สี่ตัว — GridSearch, RandomSearch, HyperBand, BayesianOptimization — ซึ่ง "correspond to different tuning algorithms" คือตรงกับสี่อัลกอริทึมของ §9 เป๊ะ. ข้อดีของการออกแบบแบบนี้คือ build_model ไม่ต้องแก้เลย เปลี่ยนแค่ชื่อคลาส.

# Instantiate the tuner
tuner = kt.Hyperband(build_model,     # A HyperModel - Model-building function takes an hp argument
                                      # from which you can sample hyperparameter ranges, and it returns a compiled Keras model.
                     objective="val_accuracy",   # metrics to be optimized
                     max_epochs=81,              # the maximum number of epochs to train one model
                     factor=3,                   # the reduction factor for the number of epoch
                     directory="kt_dir",         # saves logs and checkpoints for each trial run during the hyperparameter search
                     project_name="kt_hyperband",# differentiate with other runs and is a subdirectory under directory
                     seed = 42)

# Display search space summary
tuner.search_space_summary()

ผลลัพธ์ที่คาด (ตามที่สไลด์พิมพ์ไว้ในกรอบ):

บรรทัดบนสุดของผลลัพธ์เขียนว่า Default search space size: 5 ซึ่งเป็นจุดที่ชวนงง: โค้ดของเรามี units_i และ dropout_i เผื่อไว้สำหรับ layer ที่สองด้วย ทำไมนับได้แค่ 5? คำตอบคือ hyperparameter ใน KerasTuner ถูกสร้างขึ้นตอนที่โค้ดรันผ่านบรรทัดนั้นจริงๆ — ตอนเรียก search_space_summary() ระบบรัน build_model หนึ่งรอบด้วยค่า default ซึ่ง num_layers ได้ค่าน้อยสุดคือ 1 ⇒ loop วนรอบเดียว ⇒ มีแค่ units_0 และ dropout_0 เกิดขึ้น. ส่วน units_1/dropout_1 จะโผล่มาเมื่อ tuner สุ่มได้ num_layers = 2 ในระหว่างการค้นหา — นี่เรียกว่า conditional hyperparameter (hyperparameter ที่มีอยู่ก็ต่อเมื่อเงื่อนไขบางอย่างเป็นจริง) และเป็นเหตุผลที่การนับขนาด search space ด้วยมือใน §9 ต้องแยกกรณี 1 layer กับ 2 layer.

หน้าสุดท้ายของการใช้งานคือขั้นที่ 4: รันค้นหาแล้วดึงผล. จุดที่สวยของ KerasTuner คือ tuner.search(...) รับอาร์กิวเมนต์เหมือน model.fit() ทุกตัว — รวมถึง callbacks ⇒ เอา EarlyStopping จาก §2 มาใช้กับทุก trial ได้เลย ทำให้ trial ที่ไม่มีแววไม่กินเวลาเกินจำเป็น (เป็นการประหยัดซ้อนกับ successive halving ของ Hyperband อีกชั้น).

tuner.search(X, y, epochs=20, validation_split= 0.4, batch_size=512, callbacks=[early_stopping_cb])

best_model = tuner.get_best_models()[0]
print(best_model.evaluate(Xtest, ytest))
np.mean(np.round(best_model.predict(Xtest[:10])).reshape(-1) == ytest[:10])

11. ข้อควรระวังและแนวทางปฏิบัติ

สไลด์ปิดท้ายด้วยสามข้อที่ผูกกับทุกอย่างที่คำนวณมาแล้วในบทนี้:

1. ไม่มีตัวเลขวิเศษ — สไลด์ขีดเส้นใต้ว่า no magic numbers that work for every problem ค่าที่ดีขึ้นกับ dataset และ task ที่ทำอยู่. นี่คือเหตุผลที่ตารางหน้า 22 ให้ "จุดเริ่มต้น" (32–256, 0.9/0.99/0.999) ไม่ใช่ "คำตอบ"
2. ต้องเข้าใจว่าแต่ละปุ่มทำอะไร — การเลือกและจูนต้องอาศัยความเข้าใจ และสไลด์ทำตัวหนาขีดเส้นใต้ว่า Some degree of manual intervention and domain knowledge remain valuable in configuring the search and interpreting results. แปลว่าการจูนอัตโนมัติไม่ได้แทนที่คน — คนยังต้องเป็นคนตั้งขอบเขตการค้นหาและตีความผล
3. Tuning Guidelines สองข้อ: (ก) Don't try to check all parameters manually เพราะ time consuming และไม่ได้ผล — ให้ใช้ global config กับ hyperparameter หลายตัว (คือล็อกค่าที่มีกฎชัดเจนไว้ทีเดียว ตามตารางหน้า 22); (ข) If the tuning is very slow, you might perform coarse to fine grained approach คือค้นแบบหยาบก่อน ดูผลว่าควรไปทางไหนต่อ แล้วค่อยรันใหม่ให้ละเอียดในย่านนั้น

ภาคผนวก: Slide ทั้งหมดใน lecture 6.pdf (33 หน้า) — เช็คว่าอ่านครบ

สงสัยตรงไหน ถามได้เลยในแชท — ผมเป็นผู้สอนของคุณ ถามซ้ำได้ ถามลึกได้ ไม่ต้องเกรงใจ.