深度学习落地项目 呼叫中心系统
作为软件项目，我实现了十多个软件项目，其中最让我为止陶醉的有三个项目、呼叫中心项目，智慧医疗，档案分析。
这些项目具有一个共同的属性，就是通过lstm实现对权重状态的转变。
呼叫中心很好理解，实现的是语音处理系列的操作，当然项目中的整个模块也包含着客户管理系统。对客户的来电手机进行手机，这个时候就涉及到电话的有效时间性验证问题，我们怎么去识别出来一个电话的机主是否变化。这也是一个呼叫中心系统的标定就是声音的模糊化标定。这个实现的是客户的一个知识图谱的功能，在我们的交易环节以至于我们的广告推广收集业务处理部门，这类的优质信息都会成为我们的数据的标定。
在交流过程中，我们采取双向的时间记录，在我们进行预约等类似约定性操作的时候，系统会根据词语判定标定当前用户的事件，并以判定时间进行提前的信息预判。坐席在接听电话的时候会根据事件以及识别结果进行相关的判定。
图论模型的概念。数据库突然转变到了neo4j这种图论数据库，但是高速读取的库很定就不是这个库了而是redis实现的告诉读取的库，我们之前的存入序列化一般采用的都是java自带的序列化器序列化成fastjson进行保存。
那么我们为什么采取如此之多的数据呢，
协同过滤的描述是这样描述数据的，a 事件在c 群体中的可能性，b事件在d群体中的可能性，c d群体之间的关系耦合性。这个时候，我们认为a 在c 群体中的概率是 e ，b在d中的概率是 f，c与d之间的存在耦合性关系的概率为g 那么当a事件和b 事件同时发生的时候他们的事件权重就应该是 e*f*g,而不同的事件所产生的efg是完全不一样的，所以 在这种情况下转变到我们的自然语言处理或者是真实项目的时候我们就可以通过特点去预测未来发生的事情。
为什么要预期未来即将发生的事情呢，就是类似的话在客服行业是具有极大的一个工作量的，这个工作量的背后就设计到我们客户交互的时候的那种及时性通讯机制，这种通讯机制的背后，我们的项目采用的websocket和netty两种插件体系进行实现。
而这种预测模型肯定不是事先的那种，必然需要一个近实时的数据搜索，那么从网络通讯一直到后期的数据查询，我们采用的必然都是极快的一个框架，计算模块单独服务器部署，就可以在计算服务器接收到信息之后进行并行的数据运算，为什么这种异步的通讯还能保证数据的实时性有效性嘛，这里就涉及到一种内存算法，也就是最短路径优先的一个算法机制去保证数据的两种情况，可保证的就是对于语义的判断的内存映射，也就是最快速度的语音识别直接进行语音流的识别。并加入关键词的决策树体系实现内存中加载的数据范围可以获取到下一步将发生的数据。
这个预测的话也是分细粒度的实现。在交流数据平台之中采用倒排索引结构搭建。在每一次交流的时候的上下文进行判定，这种数据可能在一定的程度上会让大家觉得数据将会极其的巨大，但是事实上这种可以产生的交互数据的在redis中的zset数据结构量并不是超出预期的大。为什么选择zset呢，因为zset可以减少cpu在排序上的压力，在插入相关信息之后，redis可以极快的实现数据的重新排列。这样的背后就是我们垂直于呼叫中心领域的一个语料库。
在后期的文本分析的时候我们也可以很清晰的在句义进行bilstm+crf之后去实现另外一种数据就是句向量数据。初始化的每一个句向量在交流过程中存入redis中。数字的范围话搜索就可以建立更加完善的同义词的检索策略。当然在数据的读取上我们采用的还是进行快速的识别后进行redis中的问题反馈。这种结构实现的是座席端的一个问题引导，这样的问题引导可以实现的更多的就是让客户们更舒服的去了解问题应有的解决方案。
在传统的呼叫中心的售后系统中问题类型的分类可能是你点击号码的时候所点击的号码。也可能是你在描述之后坐席进行的记录。这个时候客户的情绪信息，满意度信息就存在一个极其让人遗憾的丢失。
而我们今天所描述的平台却完全不存在信息丢失的问题，这个的背后首先需要感谢的就是我们的大数据存储平台。大数据解决方案应该大家都不陌生。hadoop,spark,strom.
hadoop的组件中不管是mapreduce的存储策略还是底层的hdfs的实现，都给平台提供了一种极大的拓展性，以至于我们很清晰的可以了解到我们的产品供货商是如何去不断的根据数据平台去改变企业安排分布的。
实战经验的面前。传统的架构springboot springcloud nginx redis hadoop spark (scala语言实现编程，并不困难但是内存运算的速度确实快速) python 配合rabbitmq实现数据异步通讯。已经完全的展现出即便是扩容也不会影响的系统稳定性。在移动端的交互过程中，hadoop的读取展现也是超出所有人的预期。
在分类的基础上，我们也会根据语音中所展现的信息进行有效判定，那么这个判定是如何实现的呢。
这个部分确实是在自然语言处理的基础上以及word分词器的基础上进行的展现，就涉及到word分词器的关键词提取。
那么如果我们也需要实现这种效果如何进行有效的操作呢、
我写了一个解决方案就是在交流的过程中进行上下文的判定，将语言中所出现的词义进行标注，词义标注后，我们就具有了一定数量的这种句义结构。也就是我们通过句义结构的标定实现关键词提取。这个方案当时就被领导否了，因为涉及到相当一部分的数据精准性。而这其中的语义标注依旧不是底层算法。在社交媒体中寻找到的结果就是通过bilstm+crf实现的词的语义标注。在这个基础上一款迁移学习的自然语言处理平台跃然而出fasttext。
fasttext是facebook开源的一个词向量与文本分类工具，在2016年开源，典型应用场景是“带监督的文本分类问题”。提供简单而高效的文本分类和表征学习的方法，性能比肩深度学习而且速度更快。
fastText结合了自然语言处理和机器学习中最成功的理念。这些包括了使用词袋以及n-gram袋表征语句，还有使用子字(subword)信息，并通过隐藏表征在类别间共享信息。我们另外采用了一个softmax层级(利用了类别不均衡分布的优势)来加速运算过程。
这些不同概念被用于两个不同任务：
有效文本分类 ：有监督学习
学习词向量表征：无监督学习
机器学习深度学习逃不开的问题就是相似度和分类两大问题。
这个时候对于项目而言，这种呼叫中心系统的问题的分类计算复杂度就有一定程度上的降低。为什么说我们只考虑上下文对于当前词向量的影响，而不去在意我们句义中对词的权重不同的改变，只能说按照句意的词向量的判别是我刚刚想出来的东西，我觉得下一步就有必要去认识一下词上下文实现的词权重判定和句义结构中对词向量的有效判定具有哪些优势。
在词向量进行判定之后我们采用的词向量的分类就是最基础的那个svm进行数据的分类。为什么用svm因为svm的速度快，分隔效果好。
监督学习和非监督学习的差别就是非监督的实现更困难，但是实现出来之后的自动化效果可以创造更多的企业效益。
正常的算法类的文章总会有一种算法的因素在这个中间，但是我觉得算法的实现是比较生涩的。真正的落地项目更多的是环节上实现的对不同的算法的应用。一般软件项目在意的是系统稳定程度，所以会进行数据读取和计算的分隔。
今天呼叫中心项目与深度学习的结合就讲到这里，如果喜欢请分享到你的圈子里面让算法更加普及。
微信扫一扫
关注该公众号