白:把N-gram模型和分层有机结合起来还是一个没有很好解决的问题。

我: 单位（句素）可以看作是动态的，因此 “gram”可以一路变大。从n字（词素）， 到n词， 到n词组。词组本身可大可小，有基本型和嵌套型，所以句素之间的距离会越来越近。距离近到一定程度的时候，句型就触手可及了。这个动态“句素”在deep parsing中的奥妙，我的导师刘先生80年代就一直在强调，而语言学祖师爷乔老爷反倒一叶障目，自己栽进了自己的递归陷阱，这才有对FSA的盲目批判。

白: 也可以理解为，中心词的投射半径一路变大。滑动窗口远去的时候，投射半径大的词仍然残留在滑动窗口之内。

我: 有个疑问要请教白老师。

白: 请讲。

我: 就是你说的，formalism的私货总归会导致灾难。大体是这个意思。我不大信服。

白: 哦，那就是你私货已经饱和了，这个时候已经可以总结formalism了。

我: 我对计算复杂性的理论不大在行，所以对于工程师的作为不多干预。因此，作为架构者，我主要是提出specs，根据语言学的需求，怎样的扩展可以更方便去捕捉语言现象。然后工程师就去实现。在这个过程中，我看到的是，如果一个方案不大灵光，或者因为时间或者因为空间，工程师会推到重来，重新实现。然后就是讨价还价。大体上就是对我原有的specs做某种限制，只要我感觉这种限制，并不太影响我想要做的表达，我愿意接受。这样一个互动的结果，就是扩展了的formalism或platform：既满足了语言学家的要求，也满足工程的要求。就是线速啊memory啊等。

白: 那是你们公司的治理结构决定的。如果是一个既懂语言学又懂复杂性又懂软件工程的人提出方案，就会在做方案的过程中对后面那些限制一并考虑。

我: 等到系统 scale up 到大数据上一直运行无误的时候，我为什么要担忧呢？有什么可担忧的？

白: 这样提出来的formalism，工程师不会有太多架构层面的颠覆。

我: 其实，经验上，我觉得担忧的不是formalism的扩展和实现。那个东西如果有问题一定迟早会表现出来。我最关注的不是formalism层面，那个对我太“低级”,我关注的是软件工程层面，就是系统开发层面的规范。这个层面如果不掌控好，真地有可能把系统导向歧途，譬如过度开发问题。总之不能由着语言学家和开发者的性子来，要用数据和规范去约束他们。有时候也用一点formalism的限制去约束他们。

白: 这就是我说的控制“野蛮生长“

我: 迄今为止，我最有感觉的就是前不久新智元翻译转发的谷歌2015年“顶级论文”（《新智元笔记：【Google 年度顶级论文】有感》），所谓谷歌最重大的机器学习的秘诀，那里面所说的关于使用机器学习在工程上所要注意的事项和应对策略的总结，与我的规则系统开发所经验的问题与对策，几乎完全吻合。都是一个工程现场的NLP系统开发的掌控问题。

白: 我理解formalism没有什么low不low的，你已经解决了自然不需多加关注。当然对这种事实上的formalism做不做总结、做什么样的总结，是另外一个问题。但是，好用的formalism不是唯一的，尽管可以神似。我下一篇博文“打回原形”就要说这个问题。

我: 也许，白老师是说，如果我的计算背景再强一些，我可以把实践中摸索出来的formalism 的拓展，从理论上提高一下，这样对于推动领域的发展，或者帮助推动某种更一般性的平台突破，会有贡献。其实，这个工作已经开始做了，这才有我写的那篇《语言创造简史》， 制定一门NLP专用语言的 specs本身就是对 formalism 的总结。至于 formalism 本身，我觉得验证了就 work 了，并不要担心。担心的是使用formalism 的人和团队，而不是 formalism 本身。formalism就是个工具，使用工具的人可能会滥用。

白: 比如，你的前条件就是lookahead，你的后条件就是栈。有了lookahead和栈，那还叫什么有限状态自动机，早就穿墙了。

我: 可那不是真栈，没有根本损害线速。

白: 要换一种语言，把它变成架构性约束，从中看不见语言学，只看见软件工程，就到位了。LR（k）也是线速。人家也是既有lookahead又有栈。

我：formalism 本身的限制和宽松其实是双刃剑，举个简单的例子。FSA中，* 和 + 是个可能导致memory 溢出的算符，滥用的话不好，可是这个东西用起来蛮方便。从 formalism 着手去限制，我也做过，就是让 FSA 不 support 它们，人为地禁止使用。就好比当年为结构程序设计，禁止 GOTO 语句一样。结果就是code 变得难看、冗长一些了，但一劳永逸地解决了溢出的问题。不支持 * 或+ ，后来在语言中改成了只支持 *n，就是让写代码的人必须给这个* 一个确定的数字。这个办法最好，算是 formalism 层面的强制要求。

白: 内存保护是共性问题，是软件工程的“标配”。领域知识（含语言学知识）硬编码也是大忌。通常要对二者从架构上就进行隔离。

我: 硬编码是说用程序直接实现？那个东西在前处理或很个别的过程中，有一些方便。

白: 对。如果调整语言学知识，就要重新编译。这种就属于硬编码。

我: 成体系的知识，包括长尾知识，都是资源性质，然后通过formalism 实现。所谓资源与程序分开，就是说的这个。

还有就是，NLP 的流程和一些config 是在 formalism 之上的。那个东西有点像secret source，一般是只做不讲，为什么这一步这么做，那一步那么做，怎样协调，遵循什么原则，等等。教科书上的parser 没有这一部分带有语言学算法性质的东西，结果照本宣科的人做不了实用的 parser。

白: 从公司老板角度，要对人事变动具有应变的弹性，不能过度依赖藏在员工脑袋里的秘密。除非秘密藏在老板本人的脑袋里。

我: 哈，其实老板现在不怎么在乎，更操心的是产品层面和sales，因为核心引擎做出来稳定以后，就是个黑匣子样，基本没必要再进去做变动了（除了词典外）。变动的都是抽取层，那玩意儿没啥学问和奥妙。另外还可以变动的就是领域词典或领域ontology，也是在系统的周边做变动。

白: 如果真如你所说，那理论上可以把你踢走了。

我:当然，藏在架构师脑子里面的东西，对于拓展一个新产品，或对做一个本来没有预见到的应用的任务，还是有很大作用的，换一个不懂架构的，可能就不知所措了。

Who 踢走 who 啊？:=)

不踢走的原因是还有符号价值。另外一个理由是，还不够昂贵。最关键的理由是不能涣散民心。首席走了，面子上不好看。如果是“被走”，那是无奈。

我现在最好奇的其实是白老师在做的东西，觉得那个把 FSA 规则转成 RNN 的东西哪一天会突然爆发。反正我已经下了战书了（  【新智元：中文 parsing 在希望的田野上】），就等白老师的系统来应战了，：），其他的那些不大想关注。什么斯坦福parser，还有什么 CMU parser，五花八门，测试一下看上去也还不错，但没有让人惊喜的地方。

顾: 从文字理解延展到推理，是否可行？

我: 推理和常识是我不敢碰的东西，从体系上说。至于词典语义里面暗度陈仓一些零星的常识，那已经用了很久了。

白:推理是做多做少的问题，理解是能做不能做的问题。

我: 关键是，只要尝试过一些NLP 应用和产品就会发现，产品所要求的“理解”往往并不是太难。从分析抽取到产品的grounding，路程大多不远。因此，抽象层面的理解和推理，更多的是学术意义，难度大，但往往不是应用的必需。

【相关】

   [转载]【白硕 - 穿越乔家大院寻找“毛毛虫”】

    【新智元笔记：中文 parsing 在希望的田野上】

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