不是很想要編輯滑到最後貼長文，所以直接回文
*[1;31m→ *[33mcarryton *[m*[33m: 好奇裡面的要求程度，譬如用到KNN是只要套
用?
*[1;31m→ *[33mcarryton *[m*[33m: pi應用就好嗎
*[1;31m→ *[33mcarryton *[m*[33m: 還是要自己設計數學公式，不能套用api
先不論女神和她兩個心腹以及阿港的組成，認識他們是損失，領Junior的錢還要負責教育
他們能力有多不足。基本上他們碰過的東西就是黑歷史，做越多虧越多的那種。
其他的我大概寫個以後來和好主管跟他們團隊合作後的一個project為例的總體流程:
有真正有Senior能力的人接洽產線對口，理解需求以及大致了解他們對成品的期望。這段
會花去不少時間，包含理解他們在意的是precision/ recall等evaluation metric，以及
短期長期目標 (是否需要real time 之類得)，還有 data 來源，有什麼data可用之類的
。
評估該project的優先順位，以及要花多少人力進行。前兩點主要都由Senior跟好主管接
洽，我最多就是花時間在跟著他們參加會議學習他們是怎麼接洽的，接下來才會是我主要
的工作。
拿到project題目後，互相確定理解無誤。之後開始進行paper survey，從中找出適合的
模型或技巧，並且評估在神山資源下的可行性。包含現有的package到什麼程度，我需要
多少時間完善並在時間內完成prototype。
報告prototype給對口，並確認接下來的方向及調整，以及上線還有之後的maintain。
回到問題，數學會用到多少，或者是整體的要求程度。提到的是KNN，以目前KNN的進展來
說，Nearest Neighbor 最基礎的問題有 a) 用什麼measure b) 用什麼演算法加速距離計
算跟sorting (例如 KD-Tree 或 LSH)。這類型的數學技巧跟證明(例如 epsilon-net) 我
們基本上不會碰到，所以就是call別人做好的package (除了少數真的很需要卻沒有的可
能需要自己刻)，以這點來說，就是以call package為主，coding的部分大多數還是在各
package間的整合。
但我不認為數學理論不重要，回到我主要負責的3.，大多數狀況下，3. 可能需要在一週
內完成，至少要有一個prototype給上面的人看。舉個有一次我接到的為例，星期三下班
前接到，星期五要先有一個proposal 並做好投影片寄給上面的人確定方法跟進度。隔週
一二要實作並有基礎成果，星期三下班前把結果投影片寄出。
所以我在兩天內快速看了20篇左右的paper，這包含了下關鍵字做paper survey，快速看
懂那篇要做什麼，判斷paper所擁有的數學統計假設適合不適合我要解決的問題，以及我
有沒有辦法在剩下的時間內用那個方式得出一個不差的結果給個初步交代。好的數學能力
以及實作能力在這裡變得非常重要，因為這可以給出一個快速且有效的判斷基準，判斷失
準的話會需要更多的時間才能完成project，也會難以跟急著要看結果的廠區或對口交代
。(話說最後可用的paper是在好主管建議下找到的)
當然這是好主管的部分組織運作模式，不代表好主管底下所有的計畫都是這樣運作的 (例
如 DNN 相關的給的時間會比較長)，也不代表所有神山的AI相關團隊都是這樣運作得 (至
少有女神為另外一個例子，整天和她的心腹嚷嚷著演算法無用論 (一直阿狗阿狗的，洗個
美國私校碩學歷連英文都沒練到)，或說別人的東西一定做不出來，因為她自己做不出來
，完全惡搞的那種)。
Paper 裡的演算法雖然嚴謹，但往往嚴謹的背後就是有過多的假設，因此在一些比賽用的
漂亮的data上面可能適合，但不一定適用於實務上的資料。比起創新更好更快的演算法或
損失函數之類的，需要的更著重在以足夠的數學能力而達到為現實的資料篩選方法跟模型
，以及不同模型間的選配與整合。另外除非特殊情況，大多數的package都是在很多人共
同努力下的產物，完全的不套用也不切實際。
簡單回覆需要能力: 基礎的數學能力以及不會太差的實作能力。程度的話我覺得我會的都
是簡單的，但四人眾就是辦不到，所以也很難說好壞高低。希望有回答到問題。