在当前，做助理的产品底层技术基本都是围绕 NLU（自然语言理解）打造的，很多还没有涉及到 NLP。可是无论是大公司还是小公司的 NLU 都是让人失望的。

　　举个简单的例子，在大公司的几个产品上提出需求：我下周五要去北京，帮我查一下航班。

需要识别意图：查机票

需要识别 entities：时间（下周五），目的地（北京），出发地（无 / 当前地理位置）

　　我们看看结果，首先看三家的回复，从左到右分别是苹果的 Siri，微软的 Cortana，Google 的 Allo。

　　没有一个能识别出来意图，全部用关键词来检索网页 (SERP)。没有识别出意图，继而也就没有可能识别 Entity 所在的场景。对于 C 端用户而言，这可能算是最基础的服务之一，而三大巨头提供的产品完全不能用。

　　不过当我们看到国内的创业公司，却能按照需求识别出意图，并且识别出对应的 Entity，组合查询出结果，看上去比几个巨头更强大。

　　我们继续测试上下文的对话。比如，我是国航的会员，Agent 给出上面的结果里没有国航的航班，我自然会问：“ 有没有国航的？”

　　结果并没有如期望那样，在给出的列表里找到国航的航班，而是重新开始了一次查询。

　　换一句话来说，没有结合上下文的对话。我并不是为了黑，事实上这个产品在国内的创业公司中也算不错的技术了。但是不会结合上下文的对话，会造成的最严重的问题就是这个 Agent 基本不能独立完成服务。因为用户不会在一个句子里把所有的条件都列出来。

　　以上是基本要素，就当前的产品形态来看，只有非常少的产品能真正做到第一点。大部分号称能做到的，都是滥竽充数，连续问问题而已。

　　不能真正理解上下文的对话（机票查询）：

　　AGENT： 从哪里出发？

　　用户：上海虹桥机场。

　　AGENT：到哪里？

　　用户：还是从浦东走吧。

　　AGENT：好的，从虹桥出发到浦东的航班是……

　　在上面的对话，AI Agent 在问第二个问题的时候，不能理解用户对前一个回答的修改（出发地从 “虹桥” 改为“浦东”），只是按照预先设计对话的顺序，填上命名实体识别得来的 Entity。继而查询不到结果，给用户的感觉就是笨。

　　真正理解上下文的对话（机票查询）：

　　Agent：从哪里出发？

　　用户：上海虹桥机场。

　　Agent：到哪里？

　　用户：算了，从浦东走吧。

　　Agent：好的，出发改为浦东。那到达城市呢？

　　用户：北京。

　　Agent：好的，从浦东到北京的航班是……（给出正确的结果）

　　而具备真正上下文理解的对话，Agent 可以正确理解用户第二个回答的内容（从浦东走），其实是在修改上一问题的回答（出发机场），而不是真的在回答第二个问题（到达地在哪里）。

　　这只是上下文的例子，而对于服务类 Agent 而言，所有后续的 NLP 功能都基于上下文对话为前提。这些看上去其实都是非常简单的需求，但是当前没有任何一个 2C 的 Agent 可以做到。

　　可能有人会问，j2直播，大部分用户都应该在第一时间把需求表达出来吧，为什么还需要对话？实际上，真正操作过大量案例的同学就会发现，用户不可能如此” 贴心 “地按照开发者的设计来提出需求。

　　“帮我看看下个星期五去北京，下午 3 点多，从虹桥出发，国航的航班。”——这一类的表达方式在几乎从来没有出现过。哪怕是在用户最熟悉的场景，也很难确保一个句子的表达里包含了所有必须的检索条件。而且，用户还会不停地补充更多个性化需求。

　　对于用户自己比较了解的场景，如：订机票需要提供到达地，用户提出的大多数需求，在最初都非常简单，然后逐渐开始细化。所以需要当用户提出不完整需求的时候，根据其意图，结合之前已经给过的条件，通过对话，向用户提出问题，再获得答案来补全剩下还需要的条件，最后再完成服务。

　　对于用户自己不熟悉的场景，用户根本就不知道自己该提出哪些方面的需求。如：不懂酒的用户，想买一瓶合适的威士忌。他就根本很难提出除了价格以外的需求，比如产地、年份、酿造原料、水源等等。因此，Agent 得以合适的方式来提问，引导用户给出偏好，并且用对话提出推荐。