オリジナルリンク：https://yq.aliyun.com/articles/144035
著者：日建/千戦術
発行：2017年7月26日11時11分15秒
最大の特徴は、従来のインターネット接続です。
スマートデバイスの急速な発展は、人と機器の間の相互作用を変更しています。
かどうか、それは私が対話の時代を呼び出して、人と機器の間の相互作用の仕方に大きな変化を促し、ユーザーの受け入れ、またはスマートデバイスの急速な発展と普及です。
インタラクティブな対話が、私は次の4点を中心に考えています：
まず、インタラクティブな対話とインテリジェント機器、機械が人のために、自然言語は、最も自然な方法であるので、道が最低閾値であり、自然言語でなければなりません。
第二に、インタラクティブな対話と機器は、双方向でなければなりません。人や機器、および機器の話をしてもしても、一定の条件の下で、人に話すことができるだけでなく、ロボットが会話を開始することができます。
第三に、インタラクティブな対話と、デバイスがマルチラウンドで、タスクを完了するためには、このようなチケットは、ここでの相互作用のいくつかのラウンドを伴うだろうします。
伝統的なキーワード検索とのインタラクティブな対話と伝統的な検索エンジンの最大の違いは、キーワードである第四に、理解の文脈では、関係の前後に何もありません。これらの言葉は、現在のコンテキストで意味を理解するために、考慮にコンテキストを取るために、実際にインタラクティブな対話。
この背後にあるインタラクティブな対話の性質の変化への接続が不確実性の確実性から変更されたからだと思います。だから、アルゴリズムやインタラクションデザインの背後にあるかどうか、基本的には言語理解や不確実性を改善する方法を見つけなければならないことは、相互作用の不確実性を減らすことです。
伝統的なインタラクティブな対話は、おそらく以下のモジュールに分割されます：音声認識サブシステムが自動的にテキストに音声をオンにします。言語理解は、ユーザのテキストが構造化意味表現に変換されると言うことです。対話管理は、意味の理解に基づいているだけで結果は、このような定期便として、行動を取るか、アラームを設定するためにどのようなアクションを決定します。これは、それが行動し、道パラメータ生成経路に基づいている言語で作成され、より自然を通してそれを読むために。
私は今、伝統的な人間とコンピュータの相互作用と人間とコンピュータの相互作用は、データサービスと、この1の差があるため、データとサービスはますます多様化し、インターネットの発展に伴い、だと思う、人間とコンピュータの相互作用の目的は何ですか？最終的な分析では今でも、データやサービスの役割がますます重要になるだろう、このシーンでは、したがって、人間とコンピュータの相互作用、インターネット上の情報や様々なサービスを取得したいです。
まず、多様性の表現。また、このようなユーザーとして、意図、私が聞きたい、「王は、レンジャーを駐車するために私に言った」が、異なるユーザーがあまりにも多くを表現するさまざまな方法を持って、私は音楽を聴きたい、私は音楽を入れて、より。式が同じではありませんが、目的は同じであるが、そのマシンの場合は、マシンはこの事を理解することができるはずです。
第二に、言語のあいまいさ。例えば、私はラサに行くよ、歌を聞いて、良い曲の名前です。あなたが言うとき、私はラサに行くよ、彼は音楽を聴くことができ、それはラサへの切符を購入することも、それは列車の切符、または旅行を購入することであってもよいです。
ユーザー間で話して、より自然なカジュアル、ライブをキャプチャしたり、ユーザーの意図を理解することができるように理解する言語のプロセスため第三に、堅牢な言語理解、。
第四には、文脈を理解しています。これは、それがコンテキストに基づいてされていると理解され、キーワード検索で、伝統的なマンマシン対話の相互作用が非常に異なっているです。
言語で、このいずれかを理解して、我々は分類問題として抽象化のユーザの言語の意図を理解し、それは分類問題は、そのようなCNNニューラルネットワーク、SVM分類器などのような比較的標準溶液、一連の後に抽象的です。アリババは現在、ニューラルネットワークCNNを使用することであり、言葉の表現のレベルの改善を目標としました。
ユーザーのマシンを理解するために、そして意味の背後には、多くの知識に依存しなければなりません。例えば、曲の名前で、「ドーラといっしょに大冒険」は、実質的な知識のなメガオープンエリア、インターネット上のビデオで、毎日/ビデオ新しい曲があるだろう「王はパトロールに私を呼ばれます」 、知識のような大規模な量の不存在下で、私はマシンは、ユーザーの意図を理解することは本当に難しいと思います。この用語の意味表現は、単語の埋め込みに加えて、知識ベースの意味ベクトル表現を導入します。
ユーザーが実際にはよりカジュアルで自然である場合だけで、言及しました。次に、どのように我々はこのモデルはそれの話し言葉のランダム性の問題を解決するためのより良い堅牢性を持って作るのですか？その後、私たちはユーザーのデータ用にマークした後、自動的にアルゴリズムによって、いくつかのノイズを追加し、プラスノイズ（もちろん、前提は、セマンティクスを変更することはありません）、データの再訓練モデルに基づいて、モデルは、より良い堅牢性を持つことになります。
第二个模块是属性抽取，在这一块，我们把它抽象为一个序列标注问题。这个问题，神经网络也有比较成型的方法，我们现在也是用这种双向LSTM，在上面有一层CRF解码器，取得了不错的效果。当然其实在方法论上还是在神经网络框架下还是比较常见的或者说是标准的，但是这背后更大的功夫来自于对数据的分析和数据的加工。
以上所述的人机对话语言理解最大的特色就是基于上下文的理解，什么是上下文？我们看一个例子，用户说“北京天气怎么样？”，机器回答说“北京的天气今天温度34度”。接着用户说“上海”呢？在这里的理解一定是理解他指的是上海的天气，所以是要能够理解用户说的话，是和上文有关系的，所以我们再对问题做了一个抽象，在上下文的情况下，这句话和上文有关还是无关，把它抽象为二分的分类问题。这么做了抽象和简化以后，这个事情就有相对成型的方法。
对话引擎就是根据语言理解的这种结构化的语义表示以及上下文，来决定采取什么样的动作。这个动作我们把它分成几类。
第一，用于语言生成的动作。
第二，服务动作。
第三，指导客户端做操作的动作。
我们来看一个简单的对话例子。用户说我要去杭州，帮我订一张火车票，这个时候机器首先要理解用户的意图是买火车票，之后就要查知识库，要买火车票依赖于时间和目的地，但是现在用户只说目的地没说时间，所以它就要发起一个询问时间的动作，机器问了时间之后，用户回答说“明天上午”。这个时候机器要理解用户说的明天上午正好是在回答刚才用户问的问题，这样匹配了之后，基本上这个机器就把这个最关键的信息都收集回来了：时间和目的地。之后，机器就可以发起另外一个请求服务指令，然后把火车票的list给出来。这个时候用户接着说，“我要第二个”。机器还要理解用户说的第二个，就是指的要打开第二个链接，之后用户说“我要购买”，这个时候机器要发起一个指令去支付。
综上，对话交互，我会把它分成两个阶段：
- 第一阶段，通过多轮对话交互，把用户的需求表达完整，因为用户信息很多，不可能一次表达完整，所以要通过对话搜集完整，第一阶段得到结构化的信息（出发地、目的地、时间等）；
- 有了这些信息之后，第二阶段就是请求服务，接着还要去做选择、确定、支付、购买等等后面一系列的步骤。
其实，传统的人机对话，包括现在市面上常见的人机对话，一般都是只在做第一阶段的对话，包括像大家熟知的亚马逊Alexa，也只是在解决第一阶段的对话，第二阶段的对话做得不多。
我们在这个对话交互这块，在这方面还是做了一些有特色的东西。
第一，我们设计了一套面向Task Flow的对话描述语言。刚才说了，对话其实是分两个阶段的。传统的对话只是解决了第一阶段，我们设计的语言能够把整个对话任务流完整地表达出来，这个任务流就是类似于咱们程序设计的流程图。对话描述语言带来的好处是它能够让对话引擎和业务逻辑实现分离，分离之后业务方可以开发脚本语言，不需要修改背后的引擎。
第二，由于有了Task Flow的机制，我们在对话引擎方带来的收益是能够实现对话的中断和返回机制。在人机对话当中有两类中断，一类是用户主动选择到另外一个意图，更多是由于机器没有理解用户话的意思，导致这个意图跳走了。由于我们维护了对话完整的任务流，知道当前这个对话处在一个什么状态，是在中间状态还是成功结束了，如果在中间状态，我们有机会让它回来，刚才讲过的话不需要从头讲，可以接着对话。
第三，我们设计了对话面向开发者的方案，称之为Open Dialog，背后有一个语言理解引擎和一个对话引擎。面向开发者的语言理解引擎是基于规则办法，能够比较好的解决冷启动的问题，开发者只需要写语言理解的Grammar、基于对话描述语言开发一个对话过程，并且还有对数据的处理操作。这样，一个基本的人机对话就可以完成了。
问答引擎
其实人和机器对话过程中，不仅仅是有task的对话，还有问答和聊天，我们在问答引擎这块，目前还是着力于基于知识图谱的问答，因为基于知识图谱的问答能够比较精准地回答用户的问题，所以我们在这方面下的力气会多一点。
聊天引擎
在聊天这块，我们设计了两类聊天引擎。第一是基于<K,V>对的聊天引擎，它能够实现让业务方定制，为什么要定制呢？举个例子，在不同的场景下，机器的名字可能是不一样的，用户A和用户B给机器的名字是不一样的，我们有了这个机制之后，可以去定制机器的名字。但是这一方法的覆盖率是比较受限的。为了解决覆盖率的问题，我们又设计了基于seq2seq的生成式聊天引擎，这种生成式聊天，能够对开放的用户说的问题给出一个相对通顺并且符合逻辑的回答。当然这两类聊天引擎会有一个协同的策略在里面。
在功能上，比如说像地图、导航、路况，还有围绕着娱乐类的音乐、有声读物，还有实现对车的控制，在车的控制这块当然是受限的，现在能实现对车窗玻璃的控制。
在汽车场景下的对话交互，还和其他场景有非常多的不同。因为产品方希望当这个车在郊区网络不好的时候，最需要导航的时候，你要能够工作，所以我们的语音识别还有语言理解、对话引擎，就是在没有网络的情况下，要在端上能够完全工作，这里面的挑战也非常大。
对话交互平台背后第二个能力，就是提供足够强的定制能力.
智能对话交互生态的范式思考
过去3-4年，在人机对话领域，应该是说还是取得了长足的进步，这样的进步来自于以深度学习为为代表的算法突破。这个算法的突破带来语音识别大的改进。同时，另一方面我们认为对话交互和真正的用户期望还是有明显的距离的，我认为有两点：第一，对话交互能覆盖的领域还是比较受限的，大家如果是用智能语音交互的产品，你就发现翻来覆去就是那几类，音乐、地图、导航、讲笑话等等。第二，有的能力体现得还不够好，所以我们想未来怎么办呢？
我们先看看现在的模式，有几种模式，我把它总结为两类模式。第一类，自主研发。很多的创业公司或者是团队基本上都是自主研发的，像苹果它基本上是自主研发的模式。第二类，平台模式，比如说典型代表就是亚马逊的Alexa，这个平台的一个好处，它能够发动开发者的力量快速地去扩展领域。但是你会发现现在在亚马逊Alexa上有8000多个这种能力，但是很多领域的体验都不够好，根本原因在于开放平台上开发的这些skill没有很好的评测手段和质量控制机制。
自主研发的好处是体验相对较好，平台模式的好处是能够快速扩展。所以如何把这两者结合在一起，有没有第三种模式。
第三种模式应该有以下几个特点
第一，由于自然语言理解的门槛还是比较高的，门槛高指的是对于开发者来说，它比开发一个APP难多了，从无到有开发出来不难，但要做到效果好是非常难的。所以，语言理解引擎最好能够自研；
第二，对话逻辑要平台化。对于对话交互因为它和业务比较紧，每个业务方有自己特殊的逻辑，通过平台化比较合适，让平台上的开发者针对各自场景的需求和交互过程来开发对话；
第三，需要建立一套评测体系，只有符合这个评测体系的，才能引入平台当中；
第四，需要商业化的机制，能够让开发者有动力去开发更多的以及体验更好的交互能力。
如果这几点能够做到，我们称之为第三种范式，基于这个范式的平台能够相对快速地并且开发的能力体验是有效果保证的。这样它开放给用户的时候，无论是对B用户还是C用户，可以有更多的用户价值。
总结
最后，总结下我们对于研发对话交互机器人的几点思考和体会：
第一，坚持用户体验为先。这个话说起来很容易，但是我们也知道，很多团队不是以用户为先的，是以投资者为先的，投资者喜欢什么样的东西，他们就开发什么样的东西。坚持用户体验为先，就是产品要为用户提供核心价值。
第二，降低产品和交互设计的不确定性。刚才也提到了，对话交互实际上最大的问题是不确定性，在产品的交互上我们要想办法把这种不确定性尽量降得低一点，惟有通过设备设计的时候降低，或者是交互界面的降低，或者是通过对话引导的方式，把这种不确定性尽量降低。
第三，打造语言理解的鲁棒性和领域扩展性。语言的理解能力尽量做到鲁棒性，能够比较好的可扩展。
第四，打造让机器持续学习能力。对话交互我认为非常非常重要的一点，就是怎么样能够让机器持续不断地学习。现在的这种对话交互基本上还都是有产品经理或者是人工定的，定好之后这个能力是固化的，所以怎么样能够把算法（策划学习）能力打造出来，就像小朋友学语言一样，随着年龄的增长，能力会持续不断地增强。
第五是打造数据闭环。要能够快速地达到数字闭环，当然这个闭环当中要把数据的效能充分调动起来，结合更多数据的服务。