1.什么是NLP

NLP，即Natural Language Processing，中文为自然语言处理，是人工智能领域的一个重要方向，也是公认为最难的方向。自然语言处理是一门融语言学、心理学、计算机科学、数学等于一体的科学。
今天我们的生活离不开NLP，日常中的输入法，搜索，语音指令控制，新闻阅读推荐，广告等都在应用NLP技术。

1.1常见NLP任务

1. 文本分类：将文本对象(文档或句子)映射到事先定义好的类别体系的技术。常见的应用包括：垃圾邮件识别，新闻主题分类，情感分析，搜索类目导航等。
2. 文本匹配 / 相似度(Text Matching / Similarity)：通过匹配文本对象找到相似体。它的主要应用有：自动拼写修正，重复数据删除，以及基因组分析等等。相似度通常采用的方法就是计算样本间的 “距离”(Distance)。常见计算相似度的方法有余弦相似度、编辑距离( 将一个字符串转换为另一个字符串时，所需的最小编辑次数。可允许的编辑操作有插入，删除，或者替换)、KL散度(概率分布之间的距离)等。
3. 指代消解(Coreference Resolution)：指代消解是一个在句子里寻找单词(或短语)之间关系连接的过程。通常是计算句子中的“他“、“她”、“它”、“这里”、“那里”等所指代的具体实体。指代消解常被用于文件摘要，问答系统，以及信息提取等。
4. 文本摘要：给出一个文本文章或段落，自动对它做总结，并根据重要性、相关性的程度，按次序输出句子（依次输出最重要并最相关的句子）。
5. 机器翻译：通过处理语法、语义学以及真实世界的信息，自动将一个文本的语言翻译为另外一个语言的文本。
6. 视觉字符识别：给出一打印后的文本图，识别与之对应的文本。
7. 文档信息化：对文档（网站、文件、pdf和图片）里的文本数据进行语法分析，将它们处理为干净、可分析的格式。

2. 怎么学习NLP

• 分类：监督学习。常用分类算法：
  • 决策树分类
  • 朴素贝叶斯分类算法(naive Bayesian classifier)
  • SVM
  • 神经网络法
  • k-最近邻法(k-nearest neighbor，kNN)
  • 模糊分类法
  • 等等
• 聚类：把相似的东西分到一组, 无监督学习。常用聚类方法：
  • K均值(K-means clustering)聚类是最典型的聚类算法
  • 属于划分法的K-MEDOIDS算法、CLARANS算法；
  • 属于层次法的BIRCH算法、CURE算法、CHAMELEON算法等；
  • 基于密度的DBSCAN算法、OPTICS算法、DENCLUE算法等；
  • 基于网格的STING算法、CLIQUE算法、WAVE-CLUSTER算法；
  • 基于模型的方法
  • 等等
• 监督学习
  • 提供数据训练模型，NLP中模型的概念，可以理解成一个函数f，给定一个文本，给出相应的输出。如，f(“鸡蛋汤洒了”) = “餐品洒了”。特征就是将“鸡蛋汤洒了”量化成一些我们需要的数值，比如一个很简单的方式（不局限于这一种）：量化后的输入只包含两维，第一维表示”是否包含菜品名“，第二维表示”是否包含洒这个动词“，那这句的输入为x1=1；x2=1（1表示是，0表示不是）。训练数据中，“鸡蛋汤洒了”是“餐品洒了”的意图；通过模型训练，他学到“鸡蛋汤”和“冬瓜汤”是类似的语义，“xxx洒了”可能是“餐品洒了”的意图；那遇到“冬瓜汤洒了”时，尽管没见过，他也可能会准确判断出意图。
• 无监督学习
  • 喂给机器很多特征数据(输入值)，是希望机器通过学习找到输入数据中是不是存在某种共性特征、结构（比如都像猫），或者数据特征值之间是不是存在某种关联。而不是像监督学习那样希望预测输出结果。无监督机器学习主要涉及两个问题，一个是句子的语义表示，另一个就是如何做知识聚类。
    • 句子语义表示
      • 在无标签语料上训练句子表示学习模型，基本思想都是在【无标签训练数据上】设计【监督学习任务】进行学习，因此这里所说的【无监督语义表示学习】着重于训练数据是无标签的.
      • 一种比较简单的设计方式是，让机器根据前文内容，去预测下一个出现的词。一段文本，每个位置的下一个词是已知的，不需要额外标注；这个已知的词就是当前任务的标准答案。可以看出，这是把无监督任务很好地转换成了有监督学习。通过这样一种方式，可以学到一个比较好的语义表示。
    • 知识聚类
      
      • 如上图所示，图(a)表达了初始的数据集，假设k=2（即我们需要将所有的样本聚成两类）。在图(b)中，我们随机选择了两个类别所对应的质心，即图中的红色质心和蓝色质心。然后如图©所示，分别求样本中所有点到这两个质心的距离，离哪个质心近就认为该样本是哪个类别，这是第一轮迭代。此时如图(d)所示，我们对当前标记为红色和蓝色的点分别求其新的质心，新的红色质心和蓝色质心的位置已经发生了变动。图(e)和图(f)重复了我们在图©和图(d)的过程，即，将所有点的类别标记为距离最近的质心的类别，并求新的质心。最终我们得到的两个类别如图(f)。当然在实际k-means算法中，我们一般会多次运行图(e)和图(f)，才能获得最终比较优的类别。下图是上述流程的一般化。
        
    • 强化学习
      • 强化学习也是使用未标记的数据，但是可以通过一些方法知道你是离正确答案越来越近还是越来越远（奖惩函数）。可以把奖惩函数看作正确答案的一个延迟、稀疏的形式。可以得到一个延迟的反馈，提示你是离答案越来越近还是越来越远。它主要包含四个元素：
        • agent: 学习者、学习如何去决策，比如人机对话中的机器
        • environment: 环境，环境是一个比较笼统的概念，具体反应到数值上就是state，即当前的状态，比如state可以是”无法确定用户所说领域“
        • action: agent根据当前的environment/state，所采取的决策，比如当state为”无法确定用户所说领域“时，action可以是”去做领域澄清“
        • reward: agent采取这个action好坏的一种评价，如果我们认为这个action是好的，就给一个正向的鼓励，如果认为这个action不好，就给一个负向的惩罚不同的action累积起来，agent最终会达到一个终极目标，所有的reward加起来就是他的累计奖励
      • 强化学习的目标就是：让agent知道，在当前的environment/state下，他应该采取什么样的action，才能拿到最大的reward，获得最多的累计奖励。
        

3. 智能客服对话技术

• 客户服务的本质是帮助客户解决问题，提升用户的满意度. 但如何让机器理解客户的自然语言，管理多轮对话上下文，替客户解决实际问题，都需要智能客服系统能很好地解决。
• 名词解释
  • 领域：指包含一系列相关意图的一个集合，如外卖机器人、外商机器人分别对应着外卖领域、外商领域，而美团app机器人则包含多个领域。
  • 意图：一个意图对应着一个标准问，如“我的外卖还有多久送到”，“我要买火车票”，“我要退票”等。
  • 话术：对应拓展问，意图的不同表达方式。
  • 实体：命名实体(named entity)就是人名、机构名、地名、饭店名、菜品命以及其他所有以名称为标识的实体。更广泛的实体还包括数字、日期、货币、地址等等。
  • 文法：文法是用来描述语言的语法成分、结构构造的形式规则。
• 智能客服机器人是一种使用自然语言与用户进行交互的人工智能信息系统，它采用包括自然语言理解、会话管理技术在内的多项智能人机交互技术，能够识别并理解用户提出的问题，通过语义分析用户意图，并以人性化的方式与用户沟通，向用户提供客户服务。当前业界主流的客服系统还都是以问答为主，利用NLP技术，将用户提出的问题与知识库中的标准问题（意图）进行匹配，将最匹配的问题的答案返回给用户。比如，知识库设定的一个标准问题是“无骑手接单”，当客户说“怎么还没有人接单”时，机器理解用户意图，将标准问题“无骑手接单”的答案呈现给用户。机器的准确性依赖底层算法和知识库维护。但对于复杂场景，比如"修改订单"，需要明确用户修改哪个订单、订单里哪一项、以及修改成什么，这就促使客服系统需要使用更复杂高级的技术来解决这类各式各样的任务问题。另外，在与用户沟通过程中，智能系统还需要有风险监控能力，通过对用户复杂情感进行建模，实时获取用户情绪，进而依据用户的情感做出不同响应策略。
• 下图是以用户提问为载体的智能客服状态机。
  
• 一次有效的客户服务是由用户和客服系统多个来回的多轮交互组成的。这个过程中对于智能客服系统来说，需要根据用户的输入及用户订单等信息来完成领域路由，完成基于上下文的意图识别、任务调度，以及完成系统回复话术。
• 用户的提问有可能属于多个不同领域，这时需要依据用户订单、用户画像、上下文等信息来进一步澄清，或通过与用户的再次交互澄清。此时的用户意图可能是问答类意图(常见的FAQ)，这时返回问答话术；用户的意图也可能是闲聊，这时返回闲聊话术；用户意图还可能是任务型的，这时会触发任务型多轮交互，而任务有可能是当前正在进行的，也可能是前几轮的，或是一个新任务，这时需要根据任务型多轮交互的状态流转，并最终返回action和任务话术。
  • 通用对话交互系统框架如下图:
• 一个完整的交互系统包含五个模块
  • 语音识别（ASR），将用户的语音转换成相应的文字
  • 自然语言理解（NLU），将文本转换成一种便于机器理解的结构化表示，便于机器“理解”这个文本的内容
  • 对话管理（DM），包含DST和Policy两部分，机器根据理解的内容去做一些决策，比如切换领域，这个切换的动作就是一个决策
  • 自然语言生成（NLG），将计算机数据库里的信息或语义意图转化为人类可读的语言
  • 语音生成（TTS），将文本回复转化成语音
• 智能客户交互架构
  
• 当用户进入到客服界面时往往是带着一个问题来的，那么我们需要做的就是对这个问题进行理解，然后根据理解结果去请求相应服务，去解决用户的问题。这里面主要分为两大块，一方面是离线训练和知识库整理部分，另一部分是在线处理部分。
  • 在线部分，首先需要对问题进行基础特征的提取，比如：分词、语义标签抽取、情绪分析、NER识别等；进而进入下面一层-意图理解层，主要有问题领域分类、意图识别和属性抽取；意图理解之后就进入到了对话管理这个阶段，对话管理模块主要包括两个部分，状态追踪(DST)和对话决策，DST根据上下文状态明确当前用户的领域和意图，而对话决策模块则根据用户当前意图决定后续动作；再之下是业务服务层，包括各业务的数据服务接口以及业务数据呈现样式等。
  • 离线部分，即知识库内容及其构建，该处暂不做讲解，放在后面的知识库维护部分详细介绍。

意图理解

• 当用户提出一个问题时，我们首先要将这个问题进行领域分类，把它分到某个业务领域去，然后用业务知识去解决这个问题；领域明确后就是意图分类，根据问题的不同类别，比如问答类的、闲聊类的等，采用的方式也会有所差异
  • 领域分类:
    
  • 针对领域分类任务，如上图所示，我们首先会从不同的业务中收集大量的业务数据，作为基础的训练数据，虽然这些数据来自不同的业务，但是依然存在一些问题，主要有以下两方面：
    • 标签不准：用户有可能会在某个业务对话中提问其它领域的问题；
    • 领域重叠：某些问题可能会在多个领域中出现。
    • 原始数据不能直接拿来作为训练数据，必须要经过人工筛选和标注方可使用。 为了节约人力成本和提高迭代速度，我们采用了主动学习框架，模型的迭代主要分为如下几步：
      • 搜集业务数据，为每条业务数据打上相应的业务标签
      • 对数据进行模型训练
      • 将上步训练好的模型对样本进行预测
      • 标注人员对预测样本进行标注，选出错误和难分开的样本
      • 返回第2步，对标注好的数据重新进行训练
  • 意图分类: 意图分类主要包括问答型意图理解和任务型意图理解两个方面
    
    • 问答类，我们采用检索和相似度排序的策略，下图是问答类意图分类的设计架构。我们利用运营维护的知识库来构建索引，同时训练相似度模型。当我们的QABot训练完成之后，对于用户的每一个query，首先会经过索引召回最相似的几个问题，经过相似度模型计算的分数进行一个重新排序，然后将结果返回给用户。从原理上面来讲，整个QABot其实就是实现了一个从知识库找一个与用户的query最相似的拓展问，从而给出结果。因此，知识库的质量高低对QABot的效果有着至关重要的影响。
    • 任务型的意图，
      
    • 我们采用规则和模型结合的方式，一种是通过规则的方式，比如上下文无关文法，另一种是采用模型训练的方式

对话状态追踪(DST)

• DST解决的还是一个意图的问题，根据当前上下文的环境或者状态来明确当前用户的确切意图。目前 DST 主要负责确定用户查询的领域(domain，如外卖、小象、打车)和意图(intent，如退款、红包怎么使用等等，实际上对应着数据库中的标准问)。
  
• 上图是我们当前的框架，这个session context为上下文信息，NLU模块的输出信息可能是多个意图，我们需要根据其他的一些信息，比如，订单信息、门户信息，入口信息等，结合session context去明确它是属于哪个领域。如果这个领域不能明确怎么办？我们的做法是会跟用户进行一轮的澄清，反问用户一次，来解决这个问题，也就是框架最左边的“domain不明确进行澄清”逻辑。领域一旦明确后，下一步会进入到意图这一块，我们要明确它当前是什么意图，当然接收到的query也面临多意图判断的问题，同样我们也可以去做澄清，澄清包括利用上下文信息判定，或者增加一轮与用户的交互来澄清，如果明确则继续下面的流程，这是我们整体的架构。
• DST主要做的工作有两点:
  • 领域状态更新：当用户输入查询后，首先由系统确定问题所属的领域，
    • 如果可以确定领域 -> 进行意图识别，
    • 如果不能确定领域 -> 发起领域澄清，让用户主动选择自己所属的领域。
  • 意图状态更新：当领域确定后，就可以进一步进行用户意图的识别：
    • 如果系统根据当前查询匹配到当前领域下的唯一一个意图（标准问）-> 直接返回该意图所对应的答案或者进入该意图所对应的 task.
    • 如果系统根据当前查询匹配到当前领域下的多个意图（标准问）-> 发起意图澄清，让用户主动选择自己想问的意图。
    • 如果系统根据当前查询没有匹配到当前领域下的意图（标准问）-> 返回兜底答案
  • 例子1:
    • 用户：我要退款 （领域还未确定，进行领域澄清）
    • 系统：请问您想问是哪个业务：外卖、打车、小象。。。
    • 用户：外卖 （领域确定，并根据上一句话可以确定用户意图）
    • 系统：以下是外卖领域退款的答案：。。。
  • 例子2:
    • 用户：外卖（领域确定，意图不明确）
    • 系统：您好，请问您想问外卖的那个问题？
    • 用户：这个红包是怎么回事（意图不清晰，进行意图澄清）
    • 系统：您好，请问您的问题是：1.红包无法使用？ 2.红包无法领取？ 。。。
    • 用户：红包无法使用
    • 系统：外卖红包无法使用的答案：。。。

TaskBot

• 下图呈现的是一个“如何申请餐损”的Task树。当用户的问题触发Task后，Task机器人根据和用户的交流来获取槽信息，调用不同API接口来获取槽信息的数据，进而回复用户。下图“如何申请餐损”Task需要明确的槽包括“配送方式”、“餐损原因”、“申请状态”，其中“配送方式”和“餐损原因”是通过与用户的交互来明确，“申请状态”则是通过请求后台服务来明确。
  
• TaskBot以可视化编辑的方式，实现task的流程管理、执行逻辑等，通过意图(标准问)触发，执行预定义好的标准多轮对话流程。TaskBot提供了四大块核心能力；
  • 通过TaskBot配置台可以自定义多轮对话的执行决策树，结合预置的基础组件，描述常见问题场景；
  • 通过DLU(动态指令理解)识别用户意图；
  • 通过slotFilling进行自动槽位抽取和填充，辅助对话流程流转；
  • 通过Task回溯支持用户Task重入处理，优化用户体验；
  • 通过可扩展的组件接入能力支持更多交互和执行功能；

自动化推荐

• 用户在进⼊客服服务门户时，很多时候并不知道该怎么提问，这时候需要“猜你(用户)所想”，引导用户并主动解决用户问题。同理，当用户问完⼀个问题或者完成⼀个 task 后，系统仍可以依据上下⽂“猜你所想”， 使得整个交互由用户发起转换成由机器⼈主导，主动服务用户。当前推荐的内容为标准问力度的知识点。通过优化问题推荐模块，降低直接转人工率，降低迷失率
  
• 上图是自动化推荐的主要逻辑。推荐模型主要是基于用户信息(门店分类、营业状态)、系统信息(订单状态、页面来源、进入时间)、用户历史询问的问题，对知识库内标准问进行排序。自动化推荐的建模强依赖于用户信息、系统信息等特征。特征与用户关心的标准问关系越强，推荐模型预测精度将会越高。同时自动化推荐主要是基于历史数据，因此实时的、突发的问题需要进行人工干预(比如：吃货节，长青计划等运营活动带来的客服咨询数量激增)。
• 我们还可以提供的支持:
  • 检测【标准问】之间的相似度，当你们添加一个【标准问】时，我们给出一个已有的相似标准问的列表，人工来判断是要新增标准问、还是在原来的标准问下面进行丰富或者分层级。
  • 检测【拓展问】的重复，不允许在两个不同的标准问下面添加相同或者相近的拓展问。在添加的时候给出提示。
  • 将比较接近的拓展问聚合成一条Grammar提升泛化能力，同时也避免了大量维护形式相似的拓展问。如【鸡蛋汤洒了】和【冬瓜汤洒了】，我们合并成一条【<sys.DISHES>洒了】，其中<sys.DISHES>是一个词表，里面维护了常见的菜品名。

知识库

人工回路

• 客服的目的是为了解决用户的问题，AI在现有的work flow中节省人力，但是机器解决不了的事情还是要交给人来解决。所以在下图中，我们一定要加一条转人工的服务。另外我们利用无监督学习从日志中挖掘出的知识点也需要人工“业务运营”来check。在整个环路里监督学习从知识库中学习到的语义表示能力又可以提供给无监督学习使用。
  
• 标准问/拓展问挖掘:一个标准问就是一个意图，是用户一类query的代表，拓展问是标准问的不同话术，即不同表达方式。标准问和拓展问的关系为：在知识库中标准问和拓展为为“一对多”的关系，即一个标准问下会有多个拓展问。
• 运营任务：在运营平台，AI培训师(运营同学 😃 的职责就包括“新标准问发现”和“新拓展问发现”，所谓”新标准问“是指在当前的知识库中未包含的某类问题，”新拓展问“是指已有标准问下的不用用户说法。这个过程中算法为助力：系统的知识发现模块会对一段时间的用户query进行知识挖掘，基于聚类等技术发现潜在的新标准问和潜在拓展问，然后AI培训师对算法发现的新标准问和拓展问进行审核确认。
• 意图推荐: 我们根据用户的日志数据提取相应意图，然后根据意图共现、回复共现去挖掘，当一个用户问了一个问题之后还会提问哪些问题，当用户收到反馈之后还会反问哪些问题。根据这些信息，我们可以挖掘出推荐问题，应用的地方有单轮FAQ问答话术推荐，task结束话术推荐，离线构建好之后交给运营的同学，运营同学审核通过之后就可以上线了。
• Task挖掘：客服场景中存在大量单轮FAQ问答，其把多种条件以及各条件下的答案糅合在一起作为答案回复用户。这不但增加了用户阅读量，同时还需要用户自行判断条件，从中寻找最终答案，体验不好。另外，在用户与坐席沟通过程中，存在着大量的可复用、可模板化的Task问题。在这个环节中算法更多的是要去挖掘task流转条件、流转话术，来辅助运营人员构建Task类知识库。

知识库运营

• 知识库维护需要关注的点
  • 交互诉求，如有订单场景和无订单场景其默认行为不同，有订单场景我们希望的是默认要获取到订单信息
  • 领域分类，需要知识点有明确的“领域(业务)”信息，不同“领域”内容模型训练时需要知道
  • 标准问相似度匹配，训练时需要每簇内语义相同，簇间语义不同
  • TaskBot构建，需要满足可读可维护性、条件的完毕性
  • 配置task时节点名称尽量有明确的含义，即节点命名需要可读，这里有很多“流程节点”，增加后续阅读困难。
  • 每一个判断节点的各个出边，需要保证各个条件是一个全集，即包含所有可能情况。通常可以设置一条兜底的出边处理接口结果不符合预期的情况。
  • TaskBot测试，尽量使用确定能识别的标准问，保证不会因为标准问识别问题导致无法触发Task的情况
  • 运营需要关注过程指标，定期评估线上效果，维护动态测试集
  • 建议每个业务以月为单位，从真实日志中拉取以session为粒度的日志标注测试集，涉及的指标有意图识别率，准确率，话术质量，问题解决率等，优先关注意图识别率和准确率。
  • 测试集数据标注需要看上下文以整轮的会话为单位，需要标注用户每一轮输入的【领域】和【意图】，标注的时候需要关注上下文信息，不能单看某一句
  • 如何在现有的知识库体系里，增加业务信息呢？当前的解决方案是构建标准问标签体系。设计中的标签管理详见 标签管理功能 (MT帮助中心业务标准问标签)。
• 交互诉求
  • 针对订单类标准问，增加【订单问题】标签，该标签表示该标准问是订单问题。
• 领域分类
  • 增加【本业务问题】标签，该标签表示该标准问是本业务相关。如果相关，需要标示出。
• 标准问相似度匹配
  • 1.增加【语义不相似】标签，表示该标准问下面的拓展问其语义不都相同。 如果不相似，则需要采用不同的算法来解决，所以需要标示出。语义相同的例子如标准问【配送超时催单】下面的拓展问表述有一定相似性，包括”配送超时了帮我催一下“、”配送超时催一催“等；语义不相似的例子如【我要追加备注】里什么情况都有，这些拓展问不具有相似性。这两类标准问需要区别对待。
  • 标准问之间区分度尽量大一些。 比如下面例子: 外卖领域中的“如何查询配送状态”和“如何查询订单的配送时间”。这些或多或少有相似或者包含关系，模型在区分的时候很有难度。这种要尽量避免。
  • 标准问之间的组织需要有逻辑关系。或者可以定义成层级的方式。 如：可以把所有和发票有关的问题，归类到一个大类【发票问题】，之前的标准问是子类。类似，可以把配送相关的，合并到【配送问题】等等。
  • 不同的标准问下面不要有相同的拓展问或者特别相似的拓展问。如：标准问【如何开发票】下面有标准问【补开发票】的拓展问，模型很容易混淆。
  • 拓展问的添加注重多样性，同类型的拓展问加太多可能效果不能有比较多的提升，如：拓展问中已经有”鸡蛋汤洒了“，下次再添加”冬瓜汤洒了“ 的收益不大了，说法不同的”打翻了冬瓜汤“会更好一些。

附件