模型也是一样，起初模型也无法记住不同人的面孔，但是，把每个人、每个角度、每种光线条件下大大小小的图片标注上每个人的名字，模型经过恰当的训练，就能跟我们一样喊出每个人的名字，这就是确定性。
可以使用基于矢量的导航功能来训练深度学习神经网络，以找到从点A到点B的最短路径。通过将动物大脑使用的相同网格线模式嵌入第一层，深度学习可以计算距离和到达目的地的方向。具有基于矢量的导航和深度学习功能的自动驾驶汽车还可以检测到任何新近可用的快捷方式的存在，以减少出行时间。
update操作天然满足结合律。但是这里又要考虑一种特殊情况，那就是执行结果为0。这说明此语句之前一定存在一个insert语句，但这个语句我们还没有收到。这时我们需要利用这条语句中的数据将update语句转成insert再重新执行一次。
在初期，Kubernetes 上主要运行着无状态的 Web 应用。随着技术的成熟和社区的发展，我们看到更多的有状态应用和大数据 /AI 应用负载逐渐迁移到 K8s 上。目前企业的大数据业务还是被 YARN 等调度技术主导，但是 K8s 已经在大数据社区得到更多的关注。Flink、Spark 等开源社区和一系列商业公司如 Cloudera、Databricks、星环都开始加大对 K8s 的支持力度。
在数据库方面，如何解耦核心和非核心业务的DB。在业务链路方面，由于微服务具有复杂的业务场景和节点，这些业务场景和节点间如何混合，业务节点如何支撑业务链路，容量不足时哪些业务场景应优先通过，限流时应优先限流哪些业务等也是解耦需要关注的内容。总体而言，解耦原则要求将最核心的业务链路隔离出来，使其与其它业务间的耦合尽可能小。
首先，签约业务是异步的，在设计时不应被纳入系统的核心链路。另外，签约服务需要与网关和商户服务进行信息同步，仍可能导致网关和商户服务宕机，比如修改商户的鉴权信息可能使签约不成功。因此，签约服务需要实现灰度设计。
理论上，这种架构设计是可以扩展的。信息流处理和业务流处理被解耦后就可以被部署在不同的节点中。比如，在国际支付时可以将信息流处理逻辑部署在支付方所在的区域中，这就使得支付操作不需要依赖原来的处理逻辑所部署的机房。需要注意的是，在将数据部署在其它机房时，通常需要一些额外的处理，比如信息安全等内容。
线下业务和淘宝业务实际上使用同一个版本进行应用开发和发布，它们的隔离仅仅体现在流量和部署层面。比如，它们所使用的交易服务在开发层面就是完全相同的，仅仅在部署层面将它们的流量分离到不同的服务中。这样，在以业务维度做跨节点的流量绑定时，就需要将几个服务及其节点圈出来进行分流。
会用 Pipcook 或 Python 技术生态的机器学习相关框架、库、包……
会数据获取、数据处理、模型配置、模型训练、模型验证、模型部署、数据回流闭环，能够用Pipcook 配置Pipline 进行流式计算，处理海量数据。
有时，深度学习网络甚至无法实现其本来打算完成的任务。神经网络很难像在不同的视频帧中一样在小图像变换中进行概括。例如，根据一项研究，深卷积网络将狒狒或猫鼬标记为相同的北极熊，具体取决于背景的微小变化。
