D: 问题是parsing的目标是什么？如果和具体应用对接的话，也不一定需要parsing，或者传统意义上的句法parsing，可能是某些其他结构的提取和转化，类似翻译出一种机器可理解的语言。

我: parsing 的目标就是帮助降低应用开发的 costs，这个以前的沙龙讨论中详细论过。有了靠谱的 parser，做抽取或很多NL应用，就大大节省了成本，因为 dirty work 都被 parser 在 domain independent 的语言学层面干掉了。有靠谱的parser，抽取简直就是玩儿。（见：《新智元：有了deep parsing，信息抽取就是个玩儿》）没有 parser 也可以做，但就变成一个繁难的任务。

D: 如果是这么宽的目标，有时候起的作用就很有限，只能起到辅助性作用。

我: 怎么叫宽? 抽取中多数任务可以从 parsing 中得到太大的帮助了。

D: 你说降低costs，很宽泛的目标呀。

我: 可以测量的啊，譬如，如果没有 parser，我要完成一个产品规定的情报抽取任务：

（1）如果用规则去做的话，需要 n 人天 才能完成表层的 patterns

（2）如果用统计的话，需要 n 多人力去做标注，然后去设计 features 和调试系统等。

如果有了 parser，简单的任务 一两天的开发，复杂的任务 一两周的开发。最复杂的任务，譬如社交媒体的舆情抽取，要几个月的时间。都是可以定量比较 costs 的节省的。

我: parser 把本来是千变万化的表层 patterns，变得可以从结构上见底。就是这个道理。这个 “初级阶段” 对于高效的情报抽取很关键，虽然并不是“必要”的：事实上，绕过 parser 做抽取依旧是共同体的常态，不过这里有些不得已的因素（很多人没有靠谱的 parser 可用，还有人不愿意把结构加入抽取系统怕算法或model太过复杂伺候不了，等等）。

D: 我明白，相当于您抽象了底层模版,可以限制任意模版的写法在某个合适的范围。

我: 就是乔姆斯基上世纪50年代革命时候开始提出的概念：表层结构 parse 成了底层结构，语言在结构上被逻辑化了，所以后来又叫做 logical form。在逻辑结构层面做抽取，比起在语言表层（譬如 ngram）做抽取，那个功效不是以一当十，而是以一当百或千。而且，不仅仅是规则开发量的区别，还有表层根本就无法捕捉的所谓 long distance 现象，在 parser 的支持下变得 tractable，可以涵盖了。

D: 但是这个逻辑结构具体是什么形式？我是说是哪类逻辑？

我: 就是董老师说的逻辑语义结构（董振东：逻辑语义及其在机译中的应用）, 说到底就是逻辑结构树，以 argument structure 为核心的依存关系，逻辑主谓宾补+各类定状。

D: 老师有这种把自然语言转化为逻辑形式的系统吗？

我: 有啊，一直不就是在吹的这个么？

D: 不是数学上的逻辑形式是吧，还只是语言学上的限定关系

我: 基本是语言学上的（【征文参赛：美梦成真】）。

D: 赞如此坚持，如果能进一步转化为数学形式就完美了，机器就能理解。我设计了一套系统尝试把自然语言转成数学化语言，以支持后续演算，后续多交流。

我: 自然语言中只有很小的一个子集可能 mapping 到形式逻辑的数学表达，数学教科书中的表述与日常用语的表达的不同也揭示了这一点。当年初学形式逻辑的时候很着迷，曾经幻想过把自然语言最终都表达为形式逻辑，那多干净漂亮啊。后来做了一些尝试，包括思维实验，发现基本上此路不通。

D: 按照蒙太古的理论自然语言和形式语言没有本质区别。

我: 譬如，“当且仅当” 这样的表述根本就是从逻辑反推到语言的，根本就不是自然的“人话”。研究一下语言中的“与或非”相关的表达就会发现，要理解成形式逻辑的语义表达很难。当然如果你的应用局限在数学 domain，朝这个目标做语义是有理的。本群的老革命严老师就做过这方面的工作，他的任务是把几何题的表述 parse 成内部表达，然后进入几何解题。

D: 不全是，精确搜索相关的。我猜wolframe的系统也用类似做法

我: 语言学的结构表达，就已经可以大大提高精准搜索的很多要求。这个以前也论过，说的是 parsing 是智能搜索和问答系统的核武器（泥沙龙笔记：parsing 是引擎的核武器，再论NLP与搜索）。

D: 身高一米六八的日本男明星，parsing出来有什么用？离结构化查询还很远。

我: 问题在哪里？你需要什么？

D: 我需要这个query的结果。实际上和解数学题一样。

我: 知识图谱啊。知识图谱中把人的 entity 的图谱 normalize 就好。

ISA:  明星

Height: 1.8m

D: 我觉得这个和理解数学题是一样，可以通用处理

我: query parsing 中也有一个 normalize 的过程：一米六八 --》 1.68 m。你这个问题，顺着图谱的思路，是有迹可循的：parsing + 抽取 + normalize。

D: 我要说的其实是觉得parsing太语言学了，离计算机可处理的形式太远，应该还是一种初级表达，需要往前走一步

我: parsing 的语言学化是自然的，因为它是独立于domain的纯语言的表达。计算机可处理的形式可以是 parse tree，但更经常的则是图谱（IE Template or AVM），都是结构化数据，本性上就是逻辑的。图谱可以由用户或代表用户需求的产品经理来定义，他要怎么逻辑就怎么逻辑。IE 的任务不外就是从语言学的 parse 表达 map 到用户或产品经理定义的图谱上去。语义逻辑化说的实际上就是这个过程，与你的要求没有冲突和距离。

你的要求中需要有抽取，parsing 是很好的支持，至于抽取的值如何 normalize，至少对于数量结构，这是一个 tractable 的子任务，可以单做。只要做就可以做出来：数的 normalization 和单位的 normalization，例如，单位如果是 foot 可以 normalize 到默认的 meter，如此等等，清晰的路子。

D: 我也认为这些细节怎么做都不是问题，问题是语言到底用什么形式描述可以很好地支持运算，以及这个形式是描述语法就可以了，还是可以统筹语义，最后可以训练和学习，并对接到机器接口上，这些看起来更加底层和有意义。用什么形式描述可以很好地支持运算，以及这个形式是描述语法就可以了，还是可以统筹语义，最后可以训练和学习，并对接到机器接口上，这些看起来更加底层和有意义。

铺: 谢谢李老师的分享，我们也很感兴趣这类问题。

我: 语言的抽取逻辑化，分成两大部分：如果把图谱目标形式化地定义为 AVM （Attribute Value Matrix）的话，第一个是 A 的定义，譬如 Name 、ISA、Height、Weight、Age 等等；第二个是 V 的 normalization。换句话说，要对语义结果做逻辑操作，需要逻辑化的结构关系，还需要节点值的逻辑化，这包括 时间的 normalization： 如 14:30 --》2:30pm，地点的normalization： Beijing --》 Geo的表达；数量单位的 normalization，等等。在这些任务中，V 的逻辑化都是一个个子任务，大多是 tractable 的，一个模块一个模块的开发好了。当然也可能有一个歧义的问题，但是对于搜索，歧义并不可怕，根本就不要排除歧义，就产生 nondeterministic 结果就好了。至于 A 的定义，本质就是反映 IE 情报填空的需求，parser 在这里是最核心的保障和支持。

往: 李老师的parser支持试用吗?

我: 公司没有动机去开放 parser，虽然有 API。

漆: 这种Parser应该也不会是通用的对吧

我: 是通用的

fast （near linear speed）

robust

domain independent

precise

good recall

good recall because 有一些长尾未及解决或者选择不去解决。

我: 我们用了一些 HowNet.