One-shot Learning只是一个概念，一种抽象的思想，甚至还不是一个通用的学习框架。对于语义理解来说，其肯定不是一个如图像识别或者语音识别一样典型的模式识别问题，或者说端到端的问题。语义理解是一个推理相关的问题，要通俗地说其更接近下棋这一类问题。这类问题，显然无法直接通过一个端到端的框架来进行训练和学习，而是首先需要针对问题本身进行建模，然后在这个基础上再寻求合适的学习方法。

　　举个很容易理解的例子，我们人学写字，只要学习写少量的字，然后再看到一个新的字的时候就能基本顺利地写出来，究其原因可以认为是我们针对写字这个过程做了某种近似的抽象和建模：就是把写字当成是有限的特定笔画+特定的空间排列的一个过程。当我们看到一个从未见过的字的时候，我们就尝试用这种抽象的方法去“构造”一个这样的字，然后边对照边调整，最后写出一个最像这个字的字出来。这里面也体现了我上面说的组合性和因果性，只是因果性可能更多地是一种统计关系。

　　所以这类问题最关键的地方就是要针对问题本身去建模，把问题抽象出来，逼近问题本质，不可能有一个现成的通用的框架来搞定。

　　接着上面问题：二是知道第三方app都可以完成哪些任务，需要点击哪里，然后才能与用户想做的事（语义理解）进行对接。

　　▎这个你们用什么应用内搜索技术解决的？

　　【这个问题看起来完全误解了我们的工作，我们根本不关注一个app是如何操作的，实际上也无需和具体app对接。】

　　再回到问题本质这个思想上来，现在的APP的操作是基于鼠标，键盘，触摸屏的输入方式来设计的，不管APP做得多么友好或者简洁，其都受限于这几种机械的输入方式，简单地说，现在的APP不过是这几种输入方式的一个组合操作。为什么要把语义理解和这种低级的操作方式对应起来呢？完全没有必要这么做！对话是一种全新的交互方式，也只有对话的交互方式才是最接近人与人之间的交互方式，当然也是人与机器最自然的交互方式。

　　脱离技术细节层面，我们要完成某个任务或者做某个决策，这个过程本身和输入方式无关，它就是一个任务流，可能有一些关键节点，不同的人都需要遵守，但更多的是其实没什么规律，每个人都要自己不同的个性化处理过程。比如“买飞机票”的过程：有人会去网上买，有人会打电话买，有人会去柜台买；有人很固执，只要满足其所有既定条件下的机票；有人犹豫不决，不停地对比，边询问边考虑；更多的人是有一个基本优化目标，比如价格要尽量低，或者说时间要尽可能快，然后根据当前航班情况选择一个自认为最好的。

　　我们要做就是在人完成一个任务的抽象层面，用一种最自然的方式来辅助人决策，以尽快推进任务的执行，这其中最合适的方式显然就是人与人之间的对话方式。其瞄准的是人完成某个具体任务的场景，用对话的方式来推进整个任务的快速进行，并在恰当的时候调用可能的第三方接口，比如展现特定信息，下单等，以使得整个任务朝着某个目标优化下去，比如获得最符合当前用户个性化的订单。这是典型的AI思路，所涉及的技术也是上面所说的各种复杂技术的融合。

　　当一个语音机器人的重心变成了帮用户决策，调动第三方应用来快速响应，它会变成一个重对接技术和资源的事情。

　　▎甚至重运营合作的事情，怎么看这个问题？

　　【这个问题是不是问我们需要对接很多服务，所以在服务对接的运营上会比较重？】

　　我们的确需要对接诸多服务，以在具体的任务场景中灵活地恰当地调用某种服务来辅助决策。

　　但和问题中的理解完全相反，我们可以针对网络上不同的服务接口，全自动地构建语义分析和服务对接程序（抛开具体商业谈判不谈，这里只从技术上考虑，毕竟网络上使用越广泛的服务就越是免费的），这也正是我们另外一个优势所在。除了我们的语义分析方法可以快速地从一个场景迁移到另外一个场景外，我们针对不同的服务，可以完全自动地构建起对应的对接程序。更直白地说就是针对一个特定服务的接口，直播，我们会让我们的系统自动“写”一段程序来处理这个服务下人和服务之间的对接过程，也就是针对这个服务接口的对话流程。从程序编写的角度看，就是我们设计了一个可以生成特定程序的程序，来代替本来可能需要程序员手工编写的工作。

　　▎调动第三方App来响应任务，范围很广，需要深度垂直化才有优势，如何平衡？