同样，不同部门的银行业务人员，关注点却截然不同，可以分属不同的应用场景。银行客服部门关注用户投诉的类别，应用场景是投诉分类，如“信用卡->额度->临时提额”、“客服->电话->接不通”；而银行营销部门关注用户是否为潜客，可针对性营销哪些产品，应用场景是潜客获取，如“出国金融”。
由此可知，同样的NLP技术，识别出同样的实体结果，但在不同的应用场景下，输出的结果却截然不同。显而易见，NLP的应用必须是场景化的。
应用场景能给NLP什么？
一、NLP的需求必须结合场景
NLP的需求，无处不在，只要有文本的地方，就有NLP的用武之地。但通常无法简单概括NLP的需求，都必须结合场景才能明确。比如本文例子，客服场景的需求是投诉分类，而营销场景的需求是潜客获取。即使都是客服场景的投诉分类，不同银行的分类体系也不同，如：临时提额、额度不够。这对NLP来说，这显然是不同的需求。
不似语音识别、人脸识别等感知技术，需求相对单一明确，与场景关联度低。如语音识别需要把语音转换成文字，无论转录、听写、对话场景，或是教育、司法等应用领域，需求是明确不变的。
NLP需求的场景化，使NLP应用只能针对具体场景定制，无法实现快速复制。这也是在NLP领域尚没有出现类似科大讯飞、商汤科技这样的独角兽公司的原因。
二、NLP的任务类型受场景支配
NLP技术是多样的，底层基础技术有自动分词、词性标注、实体识别，乃至当前流行的深度学习预训练模型等，应用技术有分类、匹配、关联、抽取等。每一种技术或算法，往往都只擅长某类特定的任务，比如谷歌发布的BERT模型，在文本分类、相似性匹配等任务中表现很好，但是在关联关系识别任务中的表现没有那么惊艳。因此，在NLP领域，没有一个通用的模型或框架，能适用于所有应用场景，能在所有场景中都表现良好。
NLP任务的确定，算法与模型的选择，存在复杂性，且受应用场景支配。既需要行业知识，熟悉场景需求，如客服投诉的需求；又需要有极强的NLP专业知识，对各种算法的优劣性了如指掌，知道在什么条件下，哪些算法是表现较好。而这在外人看来，就像艺术一样，让人捉摸不透，“state of the art”（最先进的，是艺术级的）。
NLP任务的场景化，是NLP技术走向产业应用的必经之路，也是最容易产生认识误区的地方。常有人抱怨，某个算法在论文中可以达到96%的正确率，为什么放在实际场景中，正确率却不到70%。这其实都是场景在作祟，论文的封闭实验场景和实际应用的开放场景不同而已。对待场景化的正确姿势，是选择最适合场景需求的NLP技术，而不是最优技术。
三、NLP的常识知识来源于场景
NLP应用需要常识知识。如“股市翻红”这一简单描述，到底是利好，还是利空？就涉及到股市常识，如果应用场景是中国股市，那么“红色”上涨，“翻红”为利好；如果应用场景是美股，那么“红色”是下跌，“翻红”则为利空。
常识知识包含两种。一种是通用常识，如“上涨”的反义词是“下跌”，“思考”的主语是“人”，“吃食堂”中“食堂”是“吃”的地点（而不是“吃”的内容）等，这些是普通人都掌握的知识。另一种是特定场景下的专业知识，也叫业务知识，如银行客服的投诉分类体系，每个类别都包含哪些内容等，这些是具体场景下的专业人员所拥有的专业知识，必须来源于场景。这里关注的是第二种常识。
场景的业务知识，一般是由两类人掌握。一是具体业务人员，如银行客服人员，但他们只懂业务，而对技术了解甚少；一是提供行业解决方案的应用开发商，如客服系统开发人员，他们往往既懂业务，又懂技术。相反，对一般NLP开发人员来说，场景业务知识是短板。这是很多NLP技术人员，甚至是著名高校的顶级专家，到具体的场景下倍感挫折的原因，不管你跟客户讲“技术是多么的先进”，客户最后都会落脚到“你们不懂业务”。NLP应用的落地，一定要将NLP技术与场景的常识知识结合起来。
应用场景对NLP的要求
实际的应用场景千变万化，每个场景都有特定的需求，这要求NLP技术不能只局限在实验室环境和论文级别上，而应用工程化思路，提供适合场景的、好用的NLP技术。
一、组件化
将NLP中的算法和模型组件化，实现在具体场景下的零门槛调用。
组件以任务为单位实现标准化。NLP的技术体系庞杂，算法、模型很多，即使同一个任务，也可用不同算法实现。如命名实体识别，可选CRF算法，可与LSTM算法结合，也可与最新的BERT模型结合。不同算法有特定的输入、输出要求。组件化将不同算法封装成统一格式，不论选择哪种算法，都可无缝跳转，不影响组件使用。
组件将算法细节封装起来。NLP算法的训练、调参过程，技术性极强，一般用户会望而生畏。组件将这些过程都封装起来，用户使用组件时，只需选择正确的组件，无需搞懂组件内每个算法的参数，也无需对参数进行反复试错，以寻找最佳配置。
组件的开发，需要NLP专业人员来做，但组件的使用，应该不需要专业知识，一般场景下的开发人员即可完成。
二、流程可组装
一个应用场景的实现，经常需要调用多个NLP组件，而不同的应用场景，组件的调用流程也不同。这就要求NLP的处理流程可组装。
一个典型的客服投诉分析场景，其实现流程包括：
输入：投诉文本
自动分词->词性标注->命名实体识别->情感计算->投诉分类
输出：投诉分类
该流程中，输入文本（如本文开始的一段文本），经过多组件处理，上级组件的输出，作为下级组件的输入，逐级对数据进行加工，最后输出投诉分类（如“信用卡->额度->临时提额”）。
流程可组装，要做到两个一致性：一是上下级组件的数据一致性，确保数据能在各组件之间正确传递；二是各组件运行环境的一致性，确保所涉及的组件，能在相同的环境下，正确执行。
三、可建模
NLP技术需要学习、使用场景的业务知识，主要通过建模完成，大体分为两类建模方式：
一种是形式化建模。业务人员利用形式化规则，如产生式规则，直接编写业务规则。NLP技术自动识别和执行这些形式化规则，从而输出符合业务人员预期的结果。优点在于简单直观，业务人员经过简单培训即可操作。缺点是规则泛化能力弱，且规则难免以偏概全，无法覆盖所有业务现象。
一种是机器学习模型训练。业务人员标注大量的数据，尽可能地将业务知识体现在标注数据中。NLP技术利用机器学习、深度学习算法，对标注数据进行自动训练，形成预训练模型。优点在于自动化程度高，学习的泛化能力强。缺点是对标注数据要求很高，标注数据量、标注语料平衡性等都需要达到算法要求，才能得到理想效果，而这一点在绝大多数应用场景下都很难做到。
选择正确的方式建模，是特定场景下NLP应用成功的关键。
泰岳语义工厂--场景化的自然语言处理平台
神州泰岳在场景化NLP应用方向，已经耕耘了8年时间，积累了丰富的场景化技术和经验，已在16个行业的上百个典型客户中实现了落地应用。
泰岳语义工厂是神州泰岳推出的场景化自然语言处理平台，支持场景化应用开发、部署、运行，其核心能力包括：
一、组件化的NLP算法库
语义工厂的算法，我们称之为智慧语义认知技术。将符号化语义表示与深度学习技术进行结合，包含词语、句子、篇章、海量文本多层次的NLP分析技术，能有效地识别多种语言结构，实现同一意思、不同结构的归一化处理；对语言结构的递归嵌套处理，表现优异。同时，平台包含了深度优化的深度学习技术和模型，如中文词向量ChineseWordVec、基于词的BERT模型等。智慧语义认知技术，已有200个NLP组件，涵盖NLP基础、深度学习、分类聚类、信息抽取、情感计算、自动写作、对话机器人、效果评估等。所有组件均可以通过restful方式调用。
二、可建模、可组装、跨平台的场景化开发工具
DINFO-OEC平台，是语义工厂中支持场景化开发、部署、运行的NLP工具。具有三大功能支持场景化开发：
1、支持场景化业务建模，可通过概念规则，构建形式化的业务规则，也可通过数据标注，指定机器学习（包括深度学习）算法，训练机器学习模型。
2、支持可视化流程定制，可通过组件拖拽方式，灵活组合自带的200多个NLP组件，快速搭建NLP应用。业务建模给出的模型，可通过组件方式，加入到定制化流程中。
3、提供统一的、跨平台的NLP运行环境，支持大数据分布式计算（如Spark）、深度学习TensorFlow等技术环境的灵活配置。可以配置使用平台自带环境，也可以配置客户已有环境。
三、 开放赋能的场景化SAAS服务
语义工厂将神州泰岳数十年来，在多个行业典型用户积累的应用场景知识、算法、模型，打包成面向场景的服务，服务的效果已经在行业用户中得到验证。开发者只需要一次调用，输入待处理的非结构化文本，即可输出想要的结构化数据。整个过程，无须开发者标注数据，无须调参，无须长时间训练，无须二次开发，开发者即使没有任何NLP技术背景，也可以轻松地把NLP技术嵌入到自己的应用中去。泰岳语义工厂将开放包含NLP基础服务、应用场景服务和数据服务等三大类服务，涉及16个行业领域，140多个场景的成熟服务。
长风破浪会有时，直挂云帆济沧海。
泰岳语义工厂为场景化而生，场景化NLP应用也必将借助泰岳语义工厂的助力，迎风起航！
作者：晋耀红博士，神州泰岳AI研究院首席科学家
