而且对于 Agent 而言，很难判断哪些用户对服务的认知有多深。如果不做识别，就容易问 “老手” 一些 “新手问题”，继而让老手觉得我还不如自己下单；而给新手又留下“你在说什么我都不懂” 的印象，也是不聪明。

　　所以要有好的体验，这是非常困难的。而基于上下文的对话，只是最基础的用户需求之一。

理解口语中的逻辑 (logic understanding)

　　在我们的实践中，我们发现对 “逻辑” 的理解直观重要。原因也是因为用户的正常对话，大部分都不是开发者预设那样的。

　　再做一个简单的测试，比如找餐厅，试试：帮我推荐一个附近的餐厅，不要日本菜。

　　这是一个简单逻辑，但是你看所有的服务，这次包括刚刚那个国内创业公司 C 一样，都会是一个结果：全部推荐日本菜。

　　也让朋友测试了亚马逊 Echo 的 Alexa，结果也无法识别” 不要 “这个最简单的逻辑

　　这次其实比刚刚好多了，至少 4 家里面除了 Google Allo，都识别出来我的意图是找餐厅——但是，当我明确提出不要日本菜的时候，给出结果的三家全部都是日本菜…… 也就是说 “不要” 两个字被完全忽略了。

　　观察大量的用户案例表明，当用户越是个性化需求强烈的时候，对话中出现逻辑和指代关系的频次越高。

　　“有没有更便宜的？”

　　“除了大床房以外的房间有么？”

　　“后天会比今天更冷么？”

　　“就要刚刚的那个 2 千多的吧。”

　　“除了廉价航空，其他的航班都可以。”

　　以上这些是提需求的时候，在对话中经常出现的表达方式，而且看似简单，但是目前没有任何一个 NLU 的系统或产品能够正确的理解。主要的阻碍就是对逻辑的理解，还有在基于上下文对话中的指代关系的理解失败。

NLP 不是全部，还要有能力履行（API 困境）

　　NLU 并不是智能助理发展的瓶颈，供给端的数据才是。

　　我们假设如果有一个黑科技出现，使得 NLP 有了极大的进步，以至于两个条件：

基于上下文场景的对话；

口语逻辑，都能被理解了，甚至还能基于场景和上下文用 NLG 来生成各类问题——它能理解我们所有讲出来的需求。

　　在用户熟悉的范围内，它能结合所有过去的对话、历史记录等等内部外部条件，帮助用户尽可能实现 “不用开口，就知道我在这个的需求”。比如当用户提出 “推荐餐厅的需求”：

　　用户：“女朋友周日过生日，推荐一个餐厅，找有江景的，最好桌子旁边有一个大落地窗户，能看到外面的夜景。吃的不要太贵，环境好点，有现场音乐的最好是爵士，不要太吵的。” （btw，这是一个真实需求）

　　Agent：“菜系有偏好么？”

　　用户：“意大利餐和法餐都可以，对了不要离外滩太远了”

　　Agent 解析出以下选择餐厅的条件：

周日晚（营业）

适合女朋友过生日

有江景

有大落地窗

不要太贵

环境好

有现场音乐，爵士

不能太吵

意大利餐或者法餐

距离外滩不能太远

　　然后它去哪里找到这样的餐厅呢？在地图服务提供商，或者点评的 API 提供的信息里只有 8，9 两项能找到数据。假设评论中有这样的数据，该用什么方式来传递呢？

　　接口提供的都是结构化的数据，而 “环境好” 这样的非结构化数据，最多以标签的方式来做，但是这样的话，标签就会无止境得多也不现实。

　　这就是我们所谓的 “API 困境”——当前基于 API 的数据传递方式，只能

承载结构化数据；

承载数量非常有限的结构化数据。

　　当前基于 GUI 的产品，都是用 API 来传递结构化数据。但大量个性化数据往往是非结构化的，以当前 API 的方式很难被处理。这还是在使用场景或者服务比较简单的情况下。

　　在用户不熟悉的场景下，Agent 面对稍微专业一点的服务，就会遇到知识图谱的问题。简单来讲，Agent 要做推荐的前提是对推荐的内容得先有了解。

　　好比，要向一位不懂酒的用户推荐一款威士忌，那就不能依赖这位用户自己提出的问题（很可能提不出要求），而得依赖 “懂行” 的自己对威士忌理解的方方面面来引导用户做合适他的选择。一个助理显然无法拥有所有服务所需的知识图谱。