【置顶：立委科学网博客NLP博文一览（定期更新版）】

Date: October 27, 2008 03:37AM

立委

新技术先锋苹果公司最近推出了新款的笔记本电脑 Mac Pro，最大的卖点是 unibody 的设计制作工艺 (Precision aluminum unibody enclosure: http://www.apple.com/macbook/)。苹果开发副总介绍说，他们开始了一个开发过程的革命性转变。以前的电脑是组件安装，因此不够皮实，接口处常出问题。现今的工艺允许他们通过多道工序，把一个aluminum的整板，一丝一丝地鏤空。这就好比技艺超群的艺术工匠在岩石上雕塑，恰到好处去掉不属于雕像的部分，也就成就了艺术。这样出神入化的 engineering 工艺，就创造了最 rock-solid 的笔记本电脑，从根本上解决了传统电脑脱焊、松动和不抗冲击的问题。昨天去苹果专卖店看了看，新电脑确实夯实，感觉就是摔在水泥地上也没关系了，主要缺点还是显得太笨重一些。

一个复杂系统模型，无论硬件软件，其开发过程有两个路子：一个是自底而上（bottom-up），一个是由顶而下（top-down）。二者各有利弊，自底而上作风扎实，步步为营，但容易只见树木不见森林。由顶而下长于宏观把握，但操作难度大，模型失之粗糙笨重。各人手艺不同，不好一概而论，总之是两种方法最后还是相遇在中间，殊途同归是也。我个人比较喜欢自底而上，有多少水，和多少面，见到一个现象，描述一个现象，埋头拉车，愚公移山。这就好比建一座巨型雕塑，自感能力不足，没有苹果的艺高胆大，只好把大事化小，盲人摸象，从细处着手，先雕出一个鼻子，两只耳朵，还有那双眼睛，然后再往一处拼凑联接，只要有足够的耐心和基本功，总有功成的一天。这样的好处是心里踏实，拼的是笨鸟先飞和耐性。

模型无论怎样建构，质量控制（QA）是关键的关键。复杂系统的质量控制绝对不能仅仅依赖团队的素质，必须规范操作规程，实现自动检测和预警，才有希望。系统的任何修改，必须通过backward compatibility 的自动检测（regression test），问题及时发现，才能保证系统开发的健康进行。拿语言自动分析（parsing）来说，本质上就是把看不见摸得着的语法（grammar）现象模型化，来最大限度地涵盖语言现象，解构隐含其中的语言结构。在这个过程中，必须保证每处理一个现象，留下该现象的 unit tested 的实例，加入到自动检测的题库去。为了防止对于个别实例 over-tuning 而使系统走偏，检测库还要保证有足够的连续真实文本的处理结果同时存在。后续的开发必须保证没有 regression 的问题，才能前进。老熊掰棒子的事不能做。事实上，我们基本题库目前收入了样本例句一万，已经十倍于美国之音的《英语900句》。想起当年听《英语900句》，老师说熟记900例句，英语的常见基本结构就涵盖了。现在有了这一万句的baseline，基本英语结构和现象应该是少有遗漏了吧。做了一下初步统计，每句话留档的各种结果现场平均超过100个点，每个点就好像一只不知疲倦的眼睛，严密注释着系统的变化。有百万只眼睛盯着系统，晚上睡觉可以比较香甜了，杜绝了系统走偏太大的可能性。这样严密的操作规范，当然减慢了系统的前进速度，但是它是保证复杂系统健康开发的一个屏障。 欲速则不达，不怕慢，就怕站，是这么多年工作的切身体会。见过了太多系统，控制不周，最终报废，成为了死物。现在在基础模块上每增加一条代码，都要花数倍的时间维护，maintenance 远远大于新的开发，对此已经安之若素。

除了有超过百万个checking points的预警系统实时（non-stop）监测，我们还建立了更大规模的夜间测试环境，让系统每天晚上自动处理百倍于baseline的真实语料库，对结果做纵向比较，记录规则涵盖面的数据。Nightly test 的结果实在太庞大，人力已经无法招架，但是纵向比较可以发现异常度大的问题，自动 alert 开发者去 drill down to 某些潜在的重大隐患。虽说没有标准题库的答案，系统的绝对性能无法定量，然而，nightly test 却可以记录系统涵盖面（recall）的相对指标。原则上，一个健康的系统，涵盖面应该线性稳定渐缓地提高，任何大的起落都预示了系统的潜在危险和崩盘的可能。

自底而上开发的系统有个毛病，就是代码的 redundancy. 因为开发的时候，手头资料有限，头疼医头，脚疼医脚，免不了处事过分谨慎，放不开手脚，害怕概括过度。适度的 redundancy 不成问题，但是日积月累，可能给系统的维护带来困扰。这就好比雕左手用了一批代码，塑右手用了另一批代码，完工以后才发现两者大同小异。如果不做整合，那么在左手模型的完美化过程中，右手模型无法得益，两者需要单独维护。开发初期整合的条件不充足，因为样本不足，如今应该没有顾虑了，应该展开瘦身运动。

这两周就在做这事儿，给系统减肥，每删除一条代码，就好像自己减了一磅一样，感觉很爽。上周把代码减少了20％，感觉轻快简明多了。瘦身运动的目的首先是增强系统的可维护性，其次才是提高效率。在系统封存为黑匣子之前，我想定期减肥是很有必要的。如今不仅晚上睡觉香甜了，不怕同人和 team 的系统改动，而且大刀阔斧的瘦身运动，一样感觉到了保障。有百万个点的实时预警呢，还有上亿数据支持的综合走向指针，瘦身运动的健康发展有了切实保障。感觉最好的是，瘦身运动不但使代码更加紧凑清晰，系统更加轻便高效，而且概括的现象也在稳步增强。过分谨慎在有序的瘦身过程中得到克服，而过分大胆 over-generalization 的毛病被系统的检测系统及时纠正，这样的瘦身运动是很开心美好的事。

通天塔到底能建多高，极限何在，还是未知数。但通天塔的建立，有了健康发展（healthy development）的保障，确实是赏心乐事。