白：“让不让我们上学的人见鬼去吧！”

李：这个句子很绝，很绝。能注意到或想出这样例句的人很神 很神。句子“鬼” 啊。

让不让 （重叠式）vs 让/不让 （非重叠式）。试比较：

“叫不让我们上学的人见鬼去吧！”
“让不让我们上学，我们都是要上学的。”

不好整：重叠式处理离词法较近，远远早于 VP 的句法阶段，二者纠缠的时候，除非特地做休眠唤醒，很难协调好。真要做，唤醒的思路是：让不让重叠式所反映的选择疑问句 or-Question 语义与祈使句（imperative）语气不兼容。这是个唤醒的 trigger：不能够一边说 让还是不让 一个event 发生，一边又说这个 event 是祈使的。要祈使，就是定下了 event 的走向；要选择，就是没有定下这个 event。譬如：

“你给我滚！”

不能与 “让你滚还是不你滚呢” 兼容。

parse parse，哈哈哈 果然中招：

这个解析“几乎”无可挑剔，until it comes across 神人鬼句。

藏在树和图背后的解析结构表示里面有“选择疑问句”特征 orQ，这个 orQ 与“让”这个小词处于句首所应该表达的祈使语气，无法兼容。因此可以针对 “让” 做词驱动的休眠唤醒，可以搞定，但是显然不值得了。词驱动的休眠唤醒是定点解决问题，只要能落实到词，总是可以实现，虽然琐碎，实现起来其实不难，问题出在：1. 真地不值得：都是些长尾中的长尾，做了与不做，系统的性能测试上无感。2. 词驱动的定点休眠唤醒有一个前提，就是对于需要唤醒的另一条路径解读，需要有预见。

其实没人真地去做那么多“预见”，所以结果总是在遇到 bug 了以后去反思这个词驱动唤醒规则。这样一来，这个技术虽然机制上平台上可以实现，但没有有效的保证可以全面铺开，防患于未然。换句话说，对于小概率的长尾错误，值得做的方法应该可以 scale up，这样长尾积累效应使得系统性能最终得到可以认可并且难以逾越的提升。如果对付长尾需要零敲碎打，见到了才能想到去实现，这虽然比束手无策要强，但实践中也还是不能有真正的效果。词驱动就是零敲碎打，专家编码词驱动比愚公移山还要愚。

学习搞不定，专家又不够愚。难！愚公累了，不愿移山，能等得到上帝吗？

【相关】

《一日一析系列》

【语义计算：李白对话录系列】

【置顶：立委NLP博文一览】

《朝华午拾》总目录