打开日志(不是必须,但是最好打开,便于debug):
vi /etc/rsyslog.d/50-default.conf
sudo service rsyslog restart
重启服务
service cron restart
查看执行记录:cat /var/log/cron.log
检查执行记录及最终结果,执行记录有报错一定没执行成功,可以根据报错debug;执行记录没报错也不一定是执行成功,因为sh脚本可能做了相应的报错隐藏,要检查一下实际的执行结果确认.
Word2Vec应用已经比较普遍.
基于类似思路,希望对句子级别内容实现向量化,以便后期使用时可以高效运算,比如寻找相似句子等.
本篇练习主要讨论:
在无标签情况下,或可使用最近邻查找或聚类等效果用以反映向量化的效果,作为特征进行分类可考虑.
特别地,Annoy挺好用.
另外,也可试试二维或者三维可视化看看效果.
基于Word2Vec,尝试了最简单的词向量平均及TFIDF加权平均,结果表明,在短句(<20左右)的情况下,效果还不错.
但是句子一旦稍长,结果就不甚可用.文章级别就更勿论.
NIPS 2013 Deep Learning Workshop:NNforText.pdf中page20处也早就提到了这一点,亲身肉测发现确实.
(要是文档链接看不了的可以跟我吱一声)
想想其实可理解,不管是平均或者加权平均,都丢掉了句子结构信息,在短句情况下,句子结构本来也比较简单一些,所以可能信息丢失不多,尚可.
句子越长越复杂,结构越复杂,平均丢掉的信息也就越多,结果就扑街.
所以,基于Word2Vec,捕捉句子结构及顺序,可能会是一种值得探索的方向.
另外,不久之前的Bert或可考虑是否有用.当然,如果准备用Bert中间层导出,基本也就不用考虑LSTM模型了,因为结果肯定是有差距的.
Distributed Representations of Sentences and Documents
介绍了将文章视为另一个词的方法,文章所代表的“词”将刻画哪些未出现在当前上下文中的信息,故称:Distributed Memory Model of Paragraph Vectors(PV-DM).上下文信息通过滑动窗口得到.
论文介绍的Paragraph Vector方法从逻辑到实现上都比较通畅明晰,训练时间论文提到的是2.5万(平均230词)句子在16核机器上需要30分钟.个人觉得可以实验一下.
而且文章也间接总结了之前相关的一些论文,也可以作为索引.
ps1:在gensim的Doc2vec实现方法上用300万的中文句子做了尝试.结果表明,还是只能对短句起到比较好的效果,长句仍无法达到推进生产的标准.(所耗时间倒是跟论文所提差不多)
ps2:还试了一个Pytorch版本的Paragraph2vec,效果也不是很好,且面对新句子没法推导vec.但是思路还是可以借鉴的,或可在此基础上改进一下.
On sentence representations
是一篇介绍文章,主要介绍了句子表示方法.比较详细的介绍了最近的/较早的-监督/无监督句子表示方法.可以作为综述文章阅读.
BERT
bert-as-service
这个项目写得挺好的,耦合比较规范,但我就是不知道作者为啥把代码都写在了init.py中,但项目仍然是个非常好的项目.
直接可用.
主要实验了mean Word2Vec/ paragraph vector / Bert embedding
Bert embedding的操作是输入句子,利用Bert预训练模型得到中间层结果(实验以得到的第12层为基准)
层越往前,可能效果会越有损失,但是速度可能会更快一点.
文章从6月中开始写,但是伴随着实验结果不理想以及方法的探索,一直写到7月底,速度也是够慢的.
结果是,使用Bert embedding能够得到目前可以获取的最好结果,效果基本可以达到Word2Vec水平.
所以基本达到了可以应用的水平.
可以达到聚类可用的水平,近邻搜索用于召回或许还有点问题.
速度上来讲,120长度,基于CPU需要200ms左右,基于GPU需要30ms左右.
句子长度(需要保留的长度)越长速度也会越慢,层越往后也会越慢.
目前Sentence2Vec基于最佳的Bert可以得到最好效果.
通过聚类可以发现,能够较好的刻画关键信息,即使句子比较长(<512),长度500左右基本可以覆盖中短篇章.
再往后估计需要期待下一步的NLP发展,仍需探索.
[1]. Distributed Representations of Sentences and Documents
[2]. A Gentle Introduction to the Bag-of-Words Model
[3]. BERT
[4]. bert-as-service
利用Pytorch 训练好模型后,如何在生产环境部署目前还是一个探索中的问题,尚未形成比较统一的方案.
不像TensorFlow有比较好的生态,生产环境中可以将模型放到Serving上.
那为什么不到TensorFlow中进行模型的开发呢?主要是:觉得TensorFlow中开发太慢了,不太熟悉,更喜欢Pytorch.
那么尚没有比较完整生态的Pytorch模型应该怎么部署呢?
主要有几种不同的场景:
API封装调用本质上来讲也是服务端部署,只是架构上做了一层分离,更容易scale,但是也可能需要付出更多的通信成本.
除了区分不同场景外,还有几种主要的操作方式,主要有:直接嵌入/模型服务(微服务/C++服务/云端部署/框架部署(MLFlow, Kubeflow, RedisAI,甚至TensorFlow Serving))
几种方式的基本介绍在Pytorch官网有一篇blog,谈了目前推荐的一些方案,可参考.Model Serving in PyTorch(https://pytorch.org/blog/model-serving-in-pyorch/)
针对服务端做了两个尝试:
mbp/Django/python3.6/torch1.1.0
这里可能需要说一下的是,如果torch版本不是最新稳定版本的话,可能需要注意一下,对结果影响也是挺大的.
其实主要测的还是并发,因为如果速度优势足够大的话牺牲一点简洁性也是可以接受的.
起一个C++web服务,具体我已将repo传到GitHub,详见:Pytorch-NLP-serving-inference-example(https://github.com/LG-1/Pytorch-NLP-serving-inference-example)
repo是完整的,环境OK的话可以运行测试.
其实步骤都比较简单
最关键的其实是我想记录一下测试结果.
原本想着用C++起服务可能会比较快一点,但是结果测下来,发现然而并没有(也有可能是我不熟悉C++的原因).
C++的RPS只能到20左右
Django嵌入可以到50左右.
另外,当然是后者的方式更简洁一些.
再另外,如果需要要在C++中做比较多的处理步骤,可能就会更不方便,比如分词.
所以,如果是图像一类,如果做得合适,还有可能用C++起个服务,但是NLP一类可能会更困难一些.
相对来说,Django嵌入的方式应该简单多了.
再再另外,
模型对系统版本,框架版本,部署线程等其实也挺敏感的,多试几次就好了++,搜索空间也不大.
Ubuntu 16.04/torch1.1.0/ gunicorn1
torch.set_num_threads(3)
1
gunicorn --env DJANGO_SETTINGS_MODULE=xxxx.settings xxxx.wsgi:application -w 3 -b 0.0.0.0:8001 -k gthread --thread 3 --max-requests 4096 --max-requests-jitter 512 --log-level=debug --timeout 120 --preload
家里有一台Windows PC,我希望能够像连阿里云服务器一样随时随地都可以远程连接,以便充分利用资源.
当然可以利用远程连接软件,比如teamviewer\向日葵 甚至 QQ都可以实现这样的远程控制,
但这不是我最想要的,一是多屏不方便,二是在两个电脑的两个软件之间转来转去也很麻烦.
我最希望的是像ssh连服务器一样直接连上去操作就好了.
查了一下资料,还真可以,且挺简单的,略微记录一下.
PC/Mac/AWS服务器
AWS服务器是免费的,真是太好用且稳定了,现在我已经有两个服务架在上面了,VPN server, 内网穿透服务端,是真香.
另外主要是frp(内网穿透软件)的配置.
哈哈,真香~
后面可以再看看powershell的使用,充分调动起来,跑跑代码,说不定就不用Windows鼠标和键盘了.