# Andrej Karpathy: Tesla Autopilot and Multi-Task Learning for Perception and Prediction
{%youtube IHH47nZ7FZU %}

## Outline
> [TOC]

## Reference
針對不同任務要不要放在一起訓練的論文：
{%pdf https://arxiv.org/pdf/1905.07553.pdf %}
針對不同任務組在一起需要什麼模型架構的論文(透過 NASNet 自己解決)
{%pdf https://arxiv.org/pdf/1901.02985.pdf %}

## Architectural Considerations
1. 每種任務各一個模型
- Expensive at test time
- No feature sharing, potential overfitting
- Decoupled functionality
2. 共享 Backbone, 只用不同 head 輸出不同任務
- Cheaper at test time
- Tasks "fight" for capacity, sometimes
- Fully coupled functionality
3. 有論文專做 multi-task 的模型架構，截圖這篇是基於 NASNet 做的，讓模型自己找出架構
4. 移動物體和交通號誌通常不太會共享太多特徵
5. 什麼樣的任務一起共享特徵是有幫助的，什麼樣的任務一起訓練會傷害彼此。
5. 有些 head 只是用來幫助訓練，但實際上我們可能並不需要這些 Output。
6. 我們不僅針對每個 Camera 或多個 Camera 的任務做訓練，也可能會有跨時間使用 Context 的任務
7. 可能對不同任務會用不同 Camera 來負責這項任務(前鏡頭、側鏡頭、魚眼)，但這需要大量直覺跟實驗來驗證什麼鏡頭適合什麼任務。

## Loss Function Consideration
1. Loss 的合併權重一直是一個問題，大部分 Paper 都是使用 Grid Search，但當你有 100 個以上的 Loss 要合併就不適合了。
2. Loss 合併可能會根據：
- 不同 Loss 他們的 Scale 會不一樣而改變(cls, reg)
- task 重要度
- task 難易度
- 這項 task 資料多寡
- task 的 noise 可能比其他 task 多

## Traing Dynamics
1. 有些任務訓練很快，有些很慢，所以對於某些 task 我們可能只想每 10 個 epoch 採樣一次，有些會是每次都採樣，像是移動物件就可能要更頻繁去採樣，所以你可能會有一個稀疏矩陣，來判斷什麼物件要在哪張照片做採樣，什麼不用。
2. Earlt Stopping 當你有多個 task 的時候 Loss 總和可能會亂跳，有些任務很簡單收斂很快，有些會很慢，那何時要停止訓練就是個重大議題。

## Team Workflow
1. 每個人都對自己任務做 Fine-tune 後，可能會影響到其他人的結果
2. 每個人都對自己任務 Fine-tune 再回饋給原始 model，別人再到新的 model 去做一次 Fine-tune，最終的 model 將再也無法重現（Lineage Graph 將會變得很亂）。