主题:应用科学的学者和工程师是如何工作的? -- changshou
就是期望凭空把东西"想"出来。
其实,更简单的方法是找一份真的工程文档看看,看了就明白别人怎么做了,这就是工程师的工作方法。search都不干,哪来的research?
逐项回答changshou同学的问题。
1 到今天是不是已经不存在 一两个工程师单打独斗就能取得重大进展 的机会了?如果是的话,原因是什么?
答:在应用领域仍然存在英雄。似乎是生物学家饶毅说过一段这样的话,有人喜欢选择做小而美的问题,有些人喜欢做大问题。
在我的领域中,仍然有不少小而美的问题。
我的背景是机器学习,即给你一些真实样本,比如年龄、心跳、胆固醇、手术预后数据和术后生存年限,让计算机自动构建一个模型,来猜测一个刚完成手术的病人的期望生存年限。
一般来说,模型就是指一个数学函数。早期,大家都接受函数的输入和输出之间满足线性关系。后来慢慢的就扩展到非线性模型。再慢慢的,发现对模型完全没有约束的话,你总能找到一个数学函数精确的匹配每个样本点,但是对于未来的样本,就错的一踏糊涂。然后大家就开始想怎么对模型做正确的约束。在这个过程中,有许多论文,但最闪光的观点来自于少数几个人
2 一个浩大的前沿技术工程(比如 J20的研制)如果牵涉很多不同学科的工程师 如何进行组织?是不是需要几个 知识极为渊博的全才性的天才人物 来统摄全局?还是各学科的头头搞地位平等的协商就可以了?抑或有其他什么办法?
也许你们会觉得荒唐,但是对我这个搞纯理论的人来说 能组织几百几千个背景很不同的学者为了一个具体目标工作 是一件不可思议的事情(我非常佩服)。在我的领域中,这种事从来就没见过,而且也看不出如何能搞起来(唯一的办法似乎是出现 强得不可思议的历史上前所未有的超天才)。
答:但是,也有大问题。以下是几个我觉得有趣的大问题:
* watson。让计算机参与百万富翁电视答题节目,让计算机理解问题并回答。这是IBM的大项目,至少有几十个人。
* 搜索引擎。任给一个查询,给出最好的网页。这个项目是上百人的规模。
* 自然语言理解、Read the web。让计算机自己去阅读整个互联网,并证明计算机能够理解它所阅读的东西。
对于这种项目,应该怎么解决呢?总的来说是分解问题。对于科研共同体,因为没有权威,大家各有各的分法。有些分法大家都接受,就能吸引到最多的研究人员。以第三个项目为例,大家选择的方式是把自然语言理解分解成:找到词语、找到短语、理解语法、理解某些特定的语法块(比如A is B's mother/brother)、提取命名短语(如时间、地点、人物)。
做了几十年做不动了,大家就换个方向,做一些小问题,比如机器翻译,最早是查表法(china永远翻译成中国),后来是上下文(如果附近看到plate,那么china可能是瓷器)。这些小问题有的时候反过来帮助“自然语言理解”这个圣杯。
如果是公司里面做,分解问题的方法就会比较野蛮,最初的几个人决定了架构。这个架构可以不对,但往往可以带着你做到70分。
3 数学对工程师们而言有多重要?大学里学的数学有用吗?大学里学的数学够用吗?我常听到一种说法就是有经验的人告诉学弟学妹 大学里要尽量学好数学。这是普遍的看法吗?
答:有用。但大部分人数学不好。所以大家就会选择非数学的解决方法。有些时候也能有很好的结果。。。不一定比数学好的朋友涨薪慢。。
4 工程师们会刨根问题的问问题吗?刨到什么程度会满足?例如,(我猜)搞化工的应该都知道元素周期律。 那么化工工程师会不会设法搞清楚怎样由量子力学导出元素周期律? 如果知道了,会对工作有帮助吗? 如果不知道,心理上会觉得受困扰吗?
答:如果我是学化工的,我应该会停在元素周期律层面。业余会往深里学,但基本上就是个人爱好,对工作不会有短期帮助的。二十年后会不会有帮助我就不知道了。在工作中有许多有趣的现象,但往往满足于记住他们:比如A方法一般比B方法好。有些时候会往里走深一点,但是没有太多时间。
5 向上级递交重要报告的时候,工程师是如何保证其可靠性的?我估计在应用中是不可能有数学和物理教科书式的严密性的(基础理论研究则可以做到这一点),故有此一问。
答:这个问题简单。1) 统计显著性。随机进行多组实验,假设一个高斯分布。2) 说服。诉诸人的常识。
6 假如出现了新的前沿技术,而这前沿技术不是原先技术的改进 而是由基础研究的新发展给出的,那么工程师会不会去主动地学习基础研究的新发展(比如去学一些没学过的数学和物理)?抑或是会要求搞基础研究的人把它翻译重组为一种很实用化的贴近工程师原先知识体系的“包裹" 然后学习这个包裹以便快速上手?
答:两种情况都有。有些时候数学家进入我们的领域,带来一些新风。有的时候我们领域的研究人员去读读别人的工作。就我所知,懒人居多,大家都不喜欢读原始文献。所以统计方法被引入自然语言领域的时候,有一个公式错了好几年。
“每一个没有破洞的封闭三维物体,都拓扑等价于三维的球面。”
假设庞加莱猜想的证明问题可以带来类似于搜索引擎的盈利模式。每个用户跑上来说,我有一个形状,你能证明不?你要能证明我就给你钱。
Baidu公司看到了这里面的机会,一口气招了10个攻城师来做这个问题。
总监:“那个谁,老王,你做橘子。老廖,你大学毕业,水平高,你去做通用的证明吧。另外带带小张,他只上过小学。他就做点杂活吧,用户平时都问个什么形状,就让小张捏个泥模,看看是不是等价于球形。”
过了一年。
总监:“最近我们部门招了个新大学生。听说现在大家都玩统计了。有些形状用户考的比较多,我们应该优先做这些形状。橘子形占10%,香蕉占5%。所以,老王,今年你考评第一,涨薪50%。老廖虽然没有做出来证明,但是还是发了很多论文的,劳苦功高。小张一个一个形状做,做了2%,也很不错。”
又过了一年。
总监:“今年老王把苹果也做完了,真是我们部门的功臣呀。小张发明了一个快速捏模机,今年做了7%,很有进步嘛!老廖,你做了什么呀?”
老廖:“我证明了苹果和梨子是等价的,简化了证明方法。”
总监:“那也没有用嘛,我们的客户又不关心方法。”
老廖:“但是这个方法把我们系统的运行速度提高了5%~”
总监:“行,那今年的奖金还是给你吧。”
在公司里,老廖的路线非常危险,你的工作很基础,但对公司没有价值。老王也有水平,选择了难易适中的路线。小张呢,非科班出身,但是善于利用工具,凭着吃苦,完全不用数学,也能搞定问题。
能够在现有的基础(技术,设备,人员素质),预算和时间约束内完成既定目标。为此采用任何新技术都是一种冒险。因为即使不采用任何新技术,系统复杂性给大工程带来失败的风险已经很大。
对合格的工程师来说,必须准备好新技术这部分无法完成的预案。歼十的发动机就是一个典型的例子。
另外,工程师还必须考虑成本。新技术可以效果好,但是如果成本(经济,工艺难度等)过高 ,那么新技术也不会被采用。
搞工程就像结婚,搞理论就像谈恋爱。谈恋爱你可以制定任意目标,也可以不用严格的时间约束,这个谈不成可以谈下一个,谈不成的失败后果相对没有那么糟糕。
结婚必须制定切实可行的计划。和谁?什么时候?用多少钱?如何减少皆不成婚的风险?比如和李冰冰谈恋爱,可以想象。但计划和李冰冰结婚就风险太高,可以明确排除掉。
1.已知的已知
2.已知的未知
3.未知的未知
我们所面对的问题都是第一类和第二类(哈哈,为什么没有第三类,因为对于第三类事物,在我们的意识中并不存在,因此也不会把他列为“问题”)。
对于第一类问题(已知的已知),可以认为它可以被准确的描述,并且有现成的实现途径,因此它并不是我们这个帖子里所关心的。
而所谓“前沿技术的大工程”,通常可以分为两类:
a.由已知的已知和已知的未知构成
b.由已知的未知构成
那么我们讨论的核心是:如何去规划探索已知的未知?回到你的帖子,里面所提到的希格斯粒子、庞加莱猜想等都是属于已知的未知这一范畴。
那么面对已知的未知,我们怎么去做计划呢?而所谓“Plan”,也分为两种:
A.时间触发型:即该类计划完全按照一个时间表运行,计划中的每一个节点在达到某一时间点之后都自动转入下一个节点
B.事件触发型:即该类计划没有一个明确的时间表,计划中的每一个节点都需要在触发事件满足之后才会进入
而我们通常意义上的“计划”,都是一个混合型的计划,既有时间触发型,又有事件触发型,例如事件A是完成事件B的条件,但是我们要求事件A在时间点t1之前完成,事件B在时间点t1+deltaT完成。
其实,回答您帖子中的问题最好的例子就是“曼哈顿计划”,原子弹从理论物理学家的一个概念变成了活生生的现实。
未知的技术,并非不能规划,关键在于要有一个正确的计划。
再有趣的工作,干上十年也要烦了
好多工程項目都在堆砌細節,基本不用高深數學,按圖索驥即可,對智力要求不高,反而要牛馬。
現成的行業標準多如牛毛,有經驗的工程師知道那些標準合用,更有經驗的工程師知道那部分可以在自己的項目省下來偷工減料。資深工程師把標準找出來給初級工程師抄,抄着抄着也成為資深了。
行业标准又是怎么来的?攒的,每隔幾年都會加點東西進去,如果你查197x年的bs英规,簡單易明。再看2000年的,就仔細得多,但其實原則沒變,只是多了細節,學習要多花好幾倍時間。2020年的基本不用看,因為常用的都有国標或iso, 日不落工業都日落了,bs也沒以前講究了。
大形工程項目如修大橋一般由客戶,顧問,总包,分包,供應商各施其职所形成的,客戶的工程師主要职責是找錢,設計的大方向受投資人左右,是政治妥協的成果,工程技術不足掛齒。而且一般只能用巿場已經有的成熟產品,由供應商研發。
研發產品也算是要最動腦筋的一环了,但一般只限前綫初哥,有時新產品沒标準,就要自己分析問題找答案了。老板要控制风險,統籌全局,基本上不會抽空研發,如果覺得事有前境,人又可靠,會給你加人加錢,甚至可以請大學教授和研發中心外緩,好运就有成品啦。但不好运也要食飯呀,所以也要做一些比較重複性的單,风險低的單。教授也一樣,水一些論文,接一些商单,有技術儲備,有人脈,萬一有天正好用上呢。