推送姬关闭已经有半年之久了,在此期间我也有断断续续地更新推送姬,不过更新主要集中在今年的二月和三月初。

上图是推送姬的架构图,大致解释一下上面各部分部件的功能吧...
第一个:月家消息推送站(http://kaguyaluna.com/)
这里主要是采集了luna,pph,P丸的相关推送,存进数据库里面。当然这个网站我是写了前端的,在上面直接看也可以。缺点是需要手动访问一个页面来实现推送的更新(即:采集)。
第二个:推送姬的语言能力
最繁琐的一个部分...
以前推送姬的语言能力是通过调用上面的网站的后端实现的,具体实现如图所示:

这样做有很多缺点:
1.酷Q端访问网站获取内容本身需要花费时间;
2.独热编码匹配度低。如上图中的吃 和 吃饭 本来相似度很高,却被独热编码排除在外;
3.只能选出余弦相似度最大的五个问句去让百度计算,这是因为百度AI平台免费用户的QPS只有可怜的5...
这样做不仅花费时间长,出来的对话质量也是堪忧。
于是我改进了方案,首先是把语言平台转到了本地,再来的是弃用了百度AI平台,分词采用结巴分词,匹配则用群友这两年来的聊天记录作为语料生成词向量,这样我就可以抛弃独热编码而转用词向量来进行语句相似度的计算。
当然,这些都是用Python写的,这样就存在一个跨语言平台的问题,要解决这个问题,要么实现混合编程(这个很麻烦...之前matlab混合编程就已经够烦人的了,这段经历我会在后面提到),要么就让Python生成DLL让酷Q调用(这个貌似可行,但是我还是采用了别的方案),要么就直接生成程序然后用巧妙的方法实现两个进程的沟通(我选用了这个)。
两个进程的沟通一般来说可以采用管道(然而我并不会,嘿嘿,也懒得学),不一般来说似乎还是挺难的。这里我采用了一个有点吃资源的方法,原谅我,因为我比较急着把这部分做出了,毕竟会说话的推送姬才是好推送姬。
这个方法就是让酷Q端把问句输出成一个文件并放到指定目录,而Python端定时去查看这个目录下所有的文件,并逐一读取这些文件,计算相似度得出回答后把回答放到另一个文件。这样,酷Q端只要定时读取存放回答的那个文件,并把回答发送到群里,最后只要清空这个文件就行了。
之所以说占用资源是因为要实现这个方案需要用到两个定时器...说实话还是有点繁琐,希望以后可以改进以下,昨晚试用了一下没啥问题,我也就没管了。
第三个:定时刷新
这个没啥好说的,只是定时访问网站的refresh.php启动采集而已。
啊?你问我为啥不用python写?拜托,用vb只用写两句话的事情用啥py啊(
第四个:酷Q Pro端
推送姬的心脏,负责接发消息,获取推送。没什么好说的。
第五个:每日热词

这个稳定性不高...正在考虑替用方案。
那么上面大概就是第三代改良推送姬的架构了...希望以后能继续完善吧。
更新推送姬的历程是完善网站->酷Qpro端->每日热词->语言功能
另外关于开发推送姬的语言平台的心路历程,我以后应该会再写一篇文章讨论的,今天就到这里吧...
Comments
(Participate in the discussion)
Comments
No comments found.
No comments found.