将任务拆解成两个部分，Model 1用于预测sel、agg、cond_conn_op和conds，Model 2用于预测conds_vals。先来看看准备的数据集是什么样的，数据集来自天池比赛，如果项目落地需要准备相应的数据：
1、table数据（数据库表数据）
2、”问题-结果“数据（人工格式化后的数据），参考上篇文档https://wiki.ingageapp.com/pages/viewpage.action?pageId=50664853。
Model 1的主要结构如下：
Python代码模型结构如下所示，主要利用了keras-bert库：
Model 2的结构如下：
Model 2的代码实现如下所示，具体的中英文转义、数据优化、模型训练参数等细节代码详见附件。：
一般来讲，涉及NLP相关算法复杂度都较高，依赖于GPU，目前训练集“问题-结果”4万条，表格数据40MB，测试集和验证集“问题-结果”分别4千条，表格数据10MB左右，目前在Mac mini单机上训练Model 1耗时大概10天，Model 2小数据集运行成功，全数据训练报错，有待调试。
命名实体识别的概念
命名实体识别（英语：Named Entity Recognition），简称NER，是指识别文本中具有特定意义的实体，主要包括人名、地名、机构名、专有名词等，以及时间、数量、货币、比例数值等文字。
举个例子，假如有这么一句话：
ACM宣布，深度学习的三位创造者Yoshua Bengio， Yann LeCun， 以及Geoffrey Hinton获得了2019年的图灵奖。
那么NER的任务就是从这句话中提取出：
机构名：ACM
人名：Yoshua Bengio， Yann LeCun，Geoffrey Hinton
时间：2019年
专有名词：图灵奖
NER系统就是从非结构化的输入文本中抽取出上述实体，并且可以按照业务需求识别出更多类别的实体。
比如产品名称、型号、价格等。因此实体这个概念可以很广，只要是业务需要的特殊文本片段都可以称为实体。
上篇主要考察了“不讲武德”的GPT-3算法，该算法打破“预训练+微调”的模式，证明了“大力可以出奇迹”的猜想，但实际落地难度较大，仅支持英文且花费高。就像当年的AlphaGo，更多的是指出行业前进的方向。上篇也讲解了BERT算法的原理，目前大多数NLP问题的解决方案都是基于BERT算法，“预训练+微调”的方法论依然是主流。
数据库存储了大量的个人或者企业的生产运营数据，我们每天都会和数据库产生或多或少的交互。通常，查询数据库中的数据需要通过像 SQL 这样的程序式查询语言来进行交互，这就需要懂 SQL 语言的专业技术人员来执行这一操作。为了让非专业用户也可以按需查询数据库，当前流行的技术方案是设计基于条件筛选的UI界面，用户可以通过点选不同的条件来查询数据库，如下所示：
但在这个界面上操作，极大地限制了数据库查询的使用场景和查询界限。即使对于精通数据库程序语言的专业人士，经常构思 SQL 语句、维护这样一个查询界面也是一项重复度较高的工作。
再比如下面这张出自某房地产行业研报的表格：
针对这张表格，用户可能会想问「哪些城市的全月销量同比超过了 50% 或者当日环比大于 25%？相应的房产类型和销售面积情况如何？」，那么用户能否通过自然语言来进行交互呢，能否避免繁杂的选择和参数输入。NL2SQL（Natural Language to SQL）是一项将用户的自然语句转为可执行 SQL 语句的技术，有很大的实际应用价值，对改善用户与数据库之间的交互方式有很大意义。
NL2SQL尤其适用于BI（Business Intelligence）场景，用户输入问题，算法模型能根据该问题算出对应的 SQL 查询语句，最后前端直接可视化输出，如下所示智能问答交互：
客户将数据放在我们的CRM中，我们为客户提供服务，服务本质上分为两种，也就是BI（Business Intelligence）和AI（Artificial Intelligence）：
1、BI服务：统计报表、数据可视化分析、指标监控等
2、AI服务：智能挖掘、智能预测、推荐系统、策略建议等
基础的BI服务缺少差异性和也缺少很强的竞争力，客户更希望我们能够通过数据挖掘出深层次的更有价值的信息或者直接提供操作建议，这里的数据不仅仅是客户的数据，还可能包含行业数据和第三方数据知识。
随着行业发展，客户深层次（非简单查询统计功能）的需求会越来越多，比如销售预测、商机金额预测、回款额预测、销售建议等。也是数字化之后，我们需要智能化产品，充分发挥数据的价值，为客户提供更好的服务。
下面以销售预测为AI业务场景，来说明数据智能平台建设方案。
前期我们做了很多AI产品，比如好孩子推荐系统、找客户推荐、智能对话等，大多是和业务数据强相关，缺少统一的数据算法平台，导致我们输出的是定制产品。以好孩子为例，假如有一天我们接到一个“好孩子2号”的母婴电商客户的推荐系统需求，我们是无法做到快速接入的，但是客户的需求几乎是一致的。
随着公司业务开展，不断出现新的算法业务场景，如果只针对各自遇到的问题做规划，必然会导致小作坊式算法生产模式，前期可能有很大的灵活性，但是越往后，局限性就越明显。资源缺乏统筹调度，无法形成规模化效应，大量重复性工作和无效输出。
一个完整的算法工作流如下所示，每个业务算法从训练到部署都有相同的流程：
微信对话开放平台开放了微信的智能对话技术，开发者及非开发者可围绕微信生态如公众号、小程序等快速搭建智能对话机器人。
1、智能对话机器人能做什么
平台对话系统由微信对话提供技术支持，应用业内最领先的语义理解模型。创建流程简单、易用，开发者无需深入学习自然语言处理技术，只需提供对话语料，即可零基础搭建智能客服平台与行业普通（问答型）或高级（任务型）智能对话技能。
2、智能对话机器人基础版：
官方提供了基础的技能，选择即可实现简单的对话。
但没有针对电商场景的技能
Kubeflow 是 Google 推出的基于 kubernetes 环境下的机器学习组件，通过 Kubeflow 可以实现对 TFJob 等资源类型定义，可以像部署应用一样完成在 TFJob 分布式训练模型的过程。
简单介绍下真正的机器学习模型服务上线都需要经历哪些阶段，如下图所示：
一个机器学习模型上线对外提供服务要经过:数据清洗验证，数据集切分， 训练，构建验证模型， 大规模训练,模型导出，模型服务上线， 日志监控等阶段。Tensorflow 等计算框架解决了最核心的部分问题，但是距离生产化，产品化，以及企业级机器学习项目开发，还有一段距离。比如: 数据收集， 数据清洗， 特征提取， 计算资源管理， 模型服务， 配置管理， 存储， 监控， 日志等等。
Kubeflow 诞生于2017年，Kubeflow项目是基于容器和Kubernetes构建，旨在为数据科学家、机器学习工程师、系统运维人员提供面向机器学习业务的敏捷部署、开发、训练、发布和管理平台。它利用了云原生技术的优势，让用户更快速、方便的部署、使用和管理当前最流行的机器学习软件。
Kubeflow特点：
将机器学习各个阶段涉及的组件以微服务的方式进行组合并以容器化的方式进行部署，提供整个流程各个系统的高可用及方便的进行扩展。
Redis 支持三种集群方案
Redis 提供了复制（replication）功能，可以实现当一台数据库中的数据更新后，自动将更新的数据同步到其他数据库上。引入主从复制机制的目的有两个
为了分载 Master 的读操作压力，Slave 服务器可以为客户端提供只读操作的服务，写服务仍然必须由Master来完成.Master Server 是以非阻塞的方式为 Slaves 提供服务。所以在 Master-Slave 同步期间，客户端仍然可以提交查询或修改请求.
当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。不具备自动容错和恢复功能.
哨兵模式是一种特殊的模式，首先 Redis 提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个 Redis 实例。
知识图谱于2012年5月17日由Google正式提出，其初衷是为了提高搜索引擎的能力，改善用户的搜索质量以及搜索体验。随着人工智能的技术发展和应用，知识图谱逐渐成为关键技术之一，现已被广泛应用于智能搜索、智能问答、个性化推荐、内容分发等领域。
知识图谱的官方定义如下：知识图谱是Google用于增强其搜索引擎功能的知识库。本质上, 知识图谱旨在描述真实世界中存在的各种实体或概念及其关系,其构成一张巨大的语义网络图，节点表示实体或概念，边则由属性或关系构成。
1、实体: 指的是具有可区别性且独立存在的某种事物。如某一个人、某一个城市、某一种植物等、某一种商品等等。世界万物由具体事物组成，此指实体。如图1的“中国”、“美国”、“日本”等。，实体是知识图谱中的最基本元素，不同的实体间存在不同的关系。
2、语义类（概念）：具有同种特性的实体构成的集合，如国家、民族、书籍、电脑等。 概念主要指集合、类别、对象类型、事物的种类，例如人物、地理等。
内容: 通常作为实体和语义类的名字、描述、解释等，可以由文本、图像、音视频等来表达。
3、属性(值): 从一个实体指向它的属性值。不同的属性类型对应于不同类型属性的边。属性值主要指对象指定属性的值。如图1所示的“面积”、“人口”、“首都”是几种不同的属性。属性值主要指对象指定属性的值，例如960万平方公里等。
4、关系: 形式化为一个函数，它把 k k个点映射到一个布尔值。在知识图谱上，关系则是一个把k k个图节点(实体、语义类、属性值)映射到布尔值的函数。
三元组是知识图谱的一种通用表示方式，其基本形式主要包括**(实体1-关系-实体2)和(实体-属性-属性值)**等。如下面的例子，中国是一个实体，北京是一个实体，中国-首都-北京 是一个（实体-关系-实体）的三元组样例。北京是一个实体 ，人口是一种属性2069.3万是属性值。北京-人口-2069.3万构成一个（实体-属性-属性值）的三元组样例。
1、精确性
知识图谱为物品引入了更多的语义关系，可以深层次地发现用户兴趣。
随着移动互联网流量红利期的结束，获取一个新用户的成本已经大大超出以往，甚至高到一家创业公司无法承受的地步。金融领域的创业公司，为了获得一位投资用户，甚至会支出四位数的CAC（ Customer Acquisition Cost）。有相关研究数据显示，获取新用户的成本是留住老用户成本的 8 倍，所以减少用户流失对企业来说至关重要。
每个企业也都渴望建立和保持一个忠实的客户群，而事实是由于各方面原因不可避免的会流失一些用户。如果我们根据用户的活跃度及消费情况，判断用户的流失意向，及时对有流失趋向的用户做营销召回，这对公司来讲是非常有必要的。
在精准防范用户流失时，要做的第一步就是先明确流失用户定义。需要根据自身产品的类型、调性以及用户画像来定义流失用户的概念。
比如，社交APP的价值在于解决沟通的问题，通常会以距离上次登陆的时间长短来定义流失用户。如果用户两个月不进行操作，则可以认为用户已经流失。再比如，电商APP通过用户购买来盈利，尤其是在双十一、双十二这种注重销量的特殊日子，通常以购买的活跃程度来定义流失用户。如果用户只看不买，对于电商来说就是一个可能会流失的用户。
只有流失用户的定义明确了，才能为用户流失预测制定好判断标准。一般情况下，用户流失其实指的是在一段时间内不再使用产品的用户，可以通过回流率来判断，即：回流用户数/流失用户数*100%。在分析时，需先找出可以定义用户的核心行为，例如用户多久没有浏览网页算流失；用户多久不使用产品算流失。在根据回流率采用拐点理论来确定流失周期，如下图可以看出第4周后回流率下降速度减慢，后期回流率趋于平缓，因此将第4周定义为流失周期，这样就可以通过流失周期将用户划分为流失与非流失用户。
对cdp而言，不同类型的企业客户对用户流失的定义标准是不尽相同的，比如好孩子和汇丰银行，但是用户流失预测模型思路是一致的。
痛点
在建设分布式训练平台的过程中，我们和机器学习的各个业务方，包括搜索推荐、图像算法、交易风控反作弊等，进行了深入沟通，调研他们的痛点。从中我们发现，算法业务方往往专注于模型和调参，而工程领域是他们相对薄弱的一个环节。建设一个强大的分布式平台，整合各个资源池，提供统一的机器学习框架，将能大大加快训练速度，提升效率，带来更多的可能性，此外还有助于提升资源利用率。
痛点一：对算力的需求越来越强烈
算力代表了生产力。深度学习在多个领域的出色表现，给业务带来了更多的可能性，同时对算力提出了越来越高的要求。深度学习模型参数的规模陡增，迭代的时间变的更长，从之前的小时级别，变成天级别，甚至月级别。以商品推荐为例，面对几亿的参数，近百亿的样本数量，即使采用 GPU 机器，也需要长达一个星期的训练时间；而图像业务拥有更多的参数和更复杂的模型，面对 TB 级的训练样本，单机场景下往往需要长达近一个月的训练时间。
痛点二：人肉管理的成本很高
人肉部署
一个典型的场景是：团队内的成员共享一批机器，每次跑训练任务前，用户手动登陆机器，下载代码，安装对应的 python 包，过程繁琐且容易出现安装包版本的冲突。
由于不同的训练任务对 python 的版本和依赖完全不同，比如有些模型使用 python 2.7，有些使用 python 3.3，有些使用 tensorflow 1.8，有些使用 tensorflow 1.11 等等，非常容易出现依赖包冲突的问题。虽然沙箱能在一定程度上解决这问题，但是也带来了额外的管理负担。
训练任务管理
