不是很想要编辑滑到最后贴长文，所以直接回文
*[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都是在很多人共
同努力下的产物，完全的不套用也不切实际。
简单回复需要能力: 基础的数学能力以及不会太差的实作能力。程度的话我觉得我会的都
是简单的，但四人众就是办不到，所以也很难说好坏高低。希望有回答到问题。