0%

在使用 NNI 自动跑实验,过了几个小时去看了一眼状态,结果发现有任务一直处于 WAITING 状态(如图所示),而实际上服务器的 GPU 并非处于全部被占用的状态。

经过查阅 issue 与查看源码,发现 nni 判定 WAITING 状态的任务在何时可以执行并将状态转变为 RUNNING 的条件是文件 /tmp/<user_name>/nni/script/gpu_metricsgpuInfos 字段下各 GPU 的状态 activeProcessNum。由于服务器上有 GPU 实时监控软件在不断调用 nvidia-smi 程序,导致 nni 的检查 GPU 状态的程序一直卡在 nvidia-smi 处。

而 nni 中专门有个脚本可以用来检测 GPU 使用情况并更新 gpu_metrics 文件:/<python_path>/site-packages/nni/tools/gpu_tool/gpu_metrics_collector.py。查看代码可以看到:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
def main(argv):
metrics_output_dir = os.environ['METRIC_OUTPUT_DIR']

cmd = 'nvidia-smi -q -x'.split()
while(True):
try:
smi_output = subprocess.check_output(cmd)
except Exception:
traceback.print_exc()
gen_empty_gpu_metric(metrics_output_dir)
break
parse_nvidia_smi_result(smi_output, metrics_output_dir)
# TODO: change to sleep time configurable via arguments
time.sleep(5)

因此,将环境变量 METRIC_OUTPUT_DIR 设定在 gpu_metrics 所在的目录,即可自动生成最新的 GPU 状态。在我这儿卡住的服务器上 kill 掉无响应的 nvidia-smi 程序,执行 METRIC_OUTPUT_DIR=/tmp/<user_name>/nni/script/ python3 -m nni.tools.gpu_tool.gpu_metrics_collector,成功地让一直卡在 WAITING 状态的程序继续运行,状态转为 RUNNING

为了后续不被卡住,特意用了 crontab 定期执行一次杀掉 nvidia-smi 和执行 gpu_metrics_collector 的操作,一劳永逸。

当我们开始在 React 中重构前端项目时,可复用 UI 组件还不在我们设计和开发工作流程之内。我们的 jQuery 前端项目主要是基于 Twitter 的 bootstrap 组件构建的,这些组件针为特定的用例进行了调整,或通过附加功能进行了扩展。我们通过从旧设计中汲取精华并加以改进,让每个特性都有了新的设计。随着团队和应用的不断发展,我们的各个组件朝着不同的方向改进,导致了文本大小、配色、按钮和链接出现了各种各样的变化,最终使得整个应用的用户体验脱节。

在 React 中重构前端项目,给了我们重新思考设计和开发工作流的机会,也让我们有机会将重点放在为用户提供更统一的体验上。这一点非常重要,因为我们所需要做的,就是让应用程序更容易访问和能更快速地响应。这也促使了新的组件库的诞生,并继而驱动了设计系统的需求。这个迭代过程一开始非常困难且缓慢,但随着时间的推移,新的组件库和设计系统变得越来越实用,让开发人员和设计师兴奋不已。

Read more »

Redux 是一个简单的库,可以帮助你管理 JavaScript 应用的状态。虽然它很简单,但在学习过程中还是很容易掉坑。我经常需要解释 Redux 的用法和原理,而且我总是会从如何实现 Redux 来开始说明。所以,在此我们做这样一件事:从头开始,写一个能用的 Redux。我们的实现不会考虑所有的情况,但可以揭示大部分 Redux 的原理。

注意,实际上我们将会实现的是 Redux React Redux。在这里,我们把 Redux 和著名的 UI 库 React 相结合,而这正是在实际场景中最为常见的组合。哪怕你把 Redux 和其他东西组合,这里讲解的所有东西几乎也还是一样的。

我们开始吧!

Read more »

在 centos 7 环境下配置与安装 docker 二进制版。

  1. 解压 docker 文件:
    1
    tar xzvf /path/to/<FILE>.tar.gz
  2. 复制 docker 文件至 /usr/bin/ 目录下
    1
    sudo cp docker/* /usr/bin/
  3. 使用 docker service 让 dockerd 自启动
    1
    sudo cp docker_service/* /etc/systemd/system
  4. 重启 systemctl,启用 docker 自启动
    1
    2
    3
    sudo systemctl daemon-reload
    sudo systemctl enable docker
    sudo systemctl start docker
  5. 创建 docker 用户组,并将当前用户加入其中

    1
    2
    3
    sudo groupadd docker
    sudo gpasswd -a $USER docker
    newgrp docker

    注:如果没有这一步,会导致 docker 只能由 sudo 运行,否则会出现 permission denied 的错误。

  6. 重启 reboot

  7. 验证 docker 安装情况: docker images

按照官方说明,在 stylesheet 中直接使用

1
2
3
edge{
label: data(name);
}

可以让连边的 label 正常显示:

-w806

但是,文字覆盖在连边上效果很不好,因此有时候会使用 outline 等方式,让文本更加突出。而根据需求,现在需要让 label 文本和连边错开(即文本在边的上边而不是重合),使用官方提供的 margin 等接口,都会在连边不是水平的时候导致文本的错位:

-w575

-w220

上面两个图片是

1
2
3
edge{
text-margin-y: 10;
}

的效果。

解决方案

1
graph.cy.style().selector('edge').style({'label':  label => label.data().name + "\n\n\u200b"}).update()

直接让一行标签变成三行标签,这样就刚好和连边错开了。其中 \u200b 是空白的字符,在图中不会显示,拿来做占位符恰好合适。效果如下:

-w310

在 17 世纪,德国数学家戈特弗里德·莱布尼茨(Gottfried Leibnitz)提出了一种机器,该机器可以读取任意数学陈述,并根据数学公理来判断其是否正确。但是,每个陈述都可以这样判定么?或者我们所能知道的东西是否存在着极限呢?这个问题被称为 Entscheidungsproblem(判定性问题)。

两个世纪后,另一位德国数学家戴维·希尔伯特(David Hilbert)乐观地宣布,判定性问题的答案必须是,是的,我们能并且会知道任何数学问题的答案。他于 1930 年在德国柯尼斯堡(Königsberg)的一次讲话中曾说:

Wir müssen wissen — wir werden wissen.(“我们必须知道 —— 我们会知道。”)

但是我们会知道吗?

数学的极限

历史表明希尔伯特的乐观主义是短暂的。同年,奥地利数学家库尔特·哥德尔(Kurt Gödel)通过证明他著名的不完备定理(incompleteness theorem)表明我们的数学知识是有极限的。

下面是理解哥德尔定理的简单方法。请考虑以下陈述。

命题 S:此命题不可被证明。

现在,假设在数学中我们可以证明 S 为真。但是这样一来,命题 S 本身将为假,从而不一致。好吧,那么让我们假设相反的情况,即我们无法在数学中证明 S。但这将意味着 S 本身为真,并且数学中包含至少一个无法证明为真的真命题。因此,数学要么不一致,要么不完备。如果我们假设它是一致的(命题不能同时为真和假),这只能得出数学是不完备的结论,即存在不能完全证明是真命题的真命题。

哥德尔(Gödel)对不完备定理的数学证明比我在此概述的要复杂得多,这从根本上改变了希尔伯特(Hilbert)所宣称的完整知识是可行的观点(“我们会知道”)。换句话说,如果我们假设数学是一致的,那么我们必然会发现无法证明的真命题。

例如,哥德巴赫猜想(The Goldbach conjecture),根据该猜想,每个偶数都是两个素数的和:

6 = 3 + 3
8 = 3 + 5
10 = 3 + 7
12 = 7 + 5,依此类推。

至今还没有人发现反例,如果猜想是真的,那也就不存在反例。得益于哥德尔的贡献,我们知道有无法证明的真命题,但不幸的是,我们没有办法找出这些命题。哥德巴赫猜想可能就是其中之一,如果是这样,那么尝试证明它就是浪费时间。

Kurt Gödel(左)和 Alan Turing(右)

计算的极限

艾伦·图灵(Alan Turing)第一次了解哥德尔不完备定理时还是剑桥大学的研究生。在那段时间里,图灵忙于做一种机器的数理设计。这种机器可以处理任何输入并计算结果,与莱布尼茨几个世纪前所设想的相似。今天这些概念化的机器被称为图灵机,是现代数字计算机的蓝图。简单来说,图灵机可以看作现代计算机程序。

图灵当时在研究所谓的停机问题,可以描述如下:

是否有一个程序可以确定另一个程序会停止(停机)还是不停(死循环)?

图灵证明了停机问题的答案是“否”,即不存在这样的程序。与哥德尔的工作类似,他也是用“反证法(proof by contradiction)”证明的。假设存在一个程序 halts(),它能确定给定程序是否将停止。但是,我们还可以构建以下程序:

1
2
3
4
def g():
if halts(g):
loop_forever()
return

看看这里发生了什么?如果 g 成立,则 g 不成立;如果 g 不成立,则 g 成立。无论哪种方式,我们都将得到一个矛盾。因此,程序 halts() 不存在。

哥德尔证明了数学是不完备的,而图灵证明了在某种意义上计算机科学也是“不完备的”。某些程序根本不存在。这不仅是理论上的好奇:停机问题在当今的计算机科学中具有许多实际意义。例如,如果我们希望编译器为给定的程序找到最快的机器码,那么我们实际上是在尝试解决停机问题 —— 而我们已经知道该问题是无法解决的。

一个复杂的蛋白质结构 —— 预测蛋白质如何折叠是一个 NP 问题(NP-problem)

知识的实际极限:P 与 NP 问题

哥德尔和图灵通过揭示存在着的一些根本无法解决的问题,证明了我们所能知道的在理论上存在极限。但是此外,还有其他问题是理论上可以解决,但是因为求解的时间太长了,而我们实际上无法解决的。这里我们将会说明 P 问题和 NP 问题的区别。

P 问题是可以在“合理的时间”内解决的问题。在这里,“合理的时间”的含义是“多项式(polynomial)时间”(因此称为 P)。求解这些问题的计算复杂性随问题输入规模的增长而倍数增加(想想乘法或排序问题)。

另一方面,NP 问题是无法在合理时间内解决的问题。NP 是非确定性多项式(non-deterministic polynomial)的英文缩写,它的含义是可以用多项式级的计算复杂度验证问题的一个解,但不能用多项式级的计算复杂度求解。求 NP 问题的解的复杂度是指数级的,而不是多项式的,这会产生巨大的实际差异。NP 问题的例子包括最佳调度,预测蛋白质的折叠方式,加密消息,解决数独难题,最佳包装(又称背包问题)或最佳路由(又称旅行商问题)。一些问题(例如找到函数的离散傅立叶变换)最开始属于 NP 问题,但由于开发了新的、巧妙的算法来简化求解,最终变成了 P 问题。

当今计算机科学领域中最大的未解之谜之一就是 P 与 NP 问题:P 是否等于 NP?换句话说,对于所有我们可以在合理时间内验证一个解的问题,我们是否能在合理的时间内解?

P 与 NP 问题非常重要,因此被列入“千禧年大奖难题(Millenium prize problems)”。如果找到答案,你会赢得一百万美元。再怎么夸大这个问题的重要性也不为过:P=NP 的世界与 P≠NP 的世界有着根本的不同。如果 P=NP,那么我们可以肯定地说,有一种更快的方法可以解决数独难题,或者预测蛋白质的折叠方式,我们只是还没有找到这种方法。毫无疑问,了解蛋白质的折叠方式会对现实世界产生全方面的影响,例如理解阿兹海默症的病理或治愈癌症。

如今,大多数科学家相信 P 不等于 NP,但是我们能确定吗?P 与 NP 问题本身可能类似于希尔伯特的 Entscheidungs 问题或图灵的停机问题:这个问题可能根本没有答案。

Read more »

68747470733a2f2f63646e2d696d616765732d312e6d656469756d2e636f6d2f6d61782f31323030302f312a742d64725f3543724b663435524530557577773273672e6a706567

通过本文,我们将熟悉树莓派 GPIO 及其技术规范。并且,我们将通过了一个简单例子,说明如何使用树莓派的 I/O 控制 LED 和开关。

你可能见过 “IoT” 这个术语,它是 Internet of Things(物联网) 的缩写。意思是,人们可以通过互联网控制一台设备(即“物” thing)。比如,用手机控制你房间内的智能电灯泡就是一种物联网的应用。

由于物联网设备可通过互联网控制,所以 IoT 设备需要始终与互联网相连。我们主要有两种方式将设备连接至互联网:以太网网线和 WiFi。

物联网设备可被用于各种目的。例如,你可以使用物联网来控制你家的室内温度、照明或者在回家前打开某些设备,所有这些操作都只需要通过你的手机便能实现。

那么,物联网设备的技术规范有哪些?简言之,它应该包含连接到互联网的工具,有一些输入和输出接口来读写设备的模拟或数字信号,并且使用最少的硬件来读取和执行程序指令。

一个物联网设备配有一个硬件组件,为外部设备读取数字数据和取电提供接口。该接口就是 GPIO 或称作 General Purpose Input Output(通用输入输出接口) 。这种硬件组件基本上都是由一系列可以连接到外部设备的引脚(或管脚,pin)构成。

这些 GPIO 引脚可以被程序控制。比如,在满足一些条件的情况下,我们可以给一个 GPIO 引脚施以 5V 的电压,任何连接到该引脚的设备都会被开启。程序也能够监听来自互联网的信号,并根据该信号对 GPIO 引脚进行控制。这就是物联网。

Read more »

css-vs-js

欢迎你踏上了一条在前端世界中饱含争议的道路!相信大部分读者会在关于如何在 JavaScript 应用中处理 CSS 这一话题上产生共鸣。

文章伊始,先声明一句:无论是在基于 Vue、Angular 还是 React 构建的应用,针对如何处理 CSS,世界上并没有任何放之四海而皆准的方法。各个项目皆有不同,每种方式也有可取之处!可能这么说显得含糊其辞,但就我所知,在我们的开发社区内,那些追寻新知识,推动网页开发向前发展的人举目皆是。

让我们放下对本文话题的感性认知,先领会下 CSS 世界架构的奇妙之处。

Read more »

Enhancing Pre-trained Chinese Character Representation with Word-aligned Attention 一文是我和组内同学、师兄的合作工作,作为短文录用于 ACL 2020。

说起来很奇妙,这个工作最开始是为了做 Aspect-extraction 相关工作而开始的,效果很一般。但是在调参的时候发现单纯作为序列标注任务的一个额外的特征输入,居然得到了一丁点提升。也就是这一点点提升,我决定把它应用在预训练语言模型中做一做实验。在经过大量的试错、调整和调参后,最终得到了这么一种新奇的方法,可以让预训练语言模型额外获得一些 word-level 的信息,在各个需要词信息的任务中都有那么一点提升。但这个方法相当的实验化且缺乏理论支撑,并且还有一些别的致命问题(如果没有这些问题谁会去投短文…),会在后面一一说明。下文将结合在会上做远程汇报的 slide,简单描述这个工作。

ppt 已经放在这里

反正就是想写个笔记给自己看,又不是写论文,就不用玩啥避重就轻之类的套路了,吐槽为主(反正没人看)。

概述

-w591

首先是预训练语言模型在最近有了很大的发展,上面那个图是 thunlp 组同学整理的。现在预训练语言模型发展方向就是在不断改进预训练任务和模型结构,让其能适配更大量的数据的数据,方便刷榜,看看 GPT-3 那 1700 亿个参数就心酸。当然也有许多做压缩模型、蒸馏的工作,这些现在应用起来反而更实用一些。还有一些工作在尝试融入额外信息,比如:清华 nlp 提出的 ERNIE 在 BERT 中融入知识图谱;百度的 ERNIE 1.0 融入实体信息,ERNIE 2.0 花式训练;香侬科技魔幻的 Glyce 融合字形;创新工场的 ZEN 用 n-gram 去融合分词信息。

-w399

但是不管怎样边,主流的预训练语言模型都和上图一样,分预训练和微调两个阶段(GPT-3 那种号称不用微调的除外),现在大家的主要工作也是集中在预训练阶段去做的。近些年这块最经典的工作当然非 BERT 莫属了,所以我后面都是在 BERT 上跑实验。

不管啥模型,第一件事都是 tokenizer。对于 BERT 来说,英文的 token 是 word-piece,中文的是字(这也对后面的实验造成了很大的麻烦,因为要对齐)。而且已经有相当多的工作证明了,对于中文在 character-level 建模会比较合适(香侬在 ACL2019 的那篇《Is Word Segmentation Necessary for Deep Learning of Chinese Representations》很是经典)。不过在实际应用中,包括很多 Application of NLP 领域的文章,还有我自己的文章,都发现将词信息融入到文本表示中会对应用有效果。

所以,这篇论文实质上就是在实验看有什么办法去各种拐着弯儿向 character-level 的表示模型融入词信息。

动机

至于动机也很简单。玄一些就是把一些眼动追踪的研究挪过来建模:

[1] Reading spaced and unspaced chinese text: Evidence from eye movements
[2] Parafoveal load of word N+1 modulates preprocessing effectiveness of word N+2 in Chinese reading
[3] Cognitive mechanisms in reading ancient Chinese poetry: evidence from eye movements

上图就是上面几篇论文的部分结论,总结起来就是人阅读中文的时候对每个词付出的“注意度”类似。

实在一些就是想找一些方法来改变 transformer 的 attention 分布,或者找一种可以折中 soft-attention 与 hard-attention 的方法,在维持原 attention 机制的情况下,用比较 soft 的方法来实现比较 hard 的效果,来方便某些任务(后记中有写)。

总之,我就是根据这些动机进行了实验。

模型

单个分词器下的情况

(在师兄指导下画的图,还挺好看的)

模型很简单,就是在预训练语言模型对下游任务进行微调时,中间插上一层 multi-head attention 的变体。

首先,可以使用分词工具将输入的文本进行分词,具体来说就是讲由字构成的序进行划分(parition),我们把这种划分策略称为 $\pi$。

得到划分 $\pi$ 后,将其应用于正常得到的 attention 权重矩阵上,可以得到按词划分的(word-based)字级别(character-level)的 attention 权重组合。

为了同时考虑:1. 句子中所有词的语义表示;2. 句子中最重要的词的语义表示 这两种情况,我们使用 mix-pooling 来对 mean-pooling 和 max-pooling 进行混合:

其中 $\lambda$ 为参数(后面做实验观察 $\lambda$ 发现,还是 MeanPooling 更重要一些)。

比如上图就是这种 attention 权重矩阵的可视化效果图。这个例子是从情感分类任务模型中拿出来试的,可以看到 attention 权重矩阵被转化为了 character-level to word-level 的形式,而实际上还是 character-level 的模型,保留了字建模的优秀表示,同时也做到了前面动机所说的接近 hard-attention 的效果。

把这样的 attention 权重再拿回 character-level 表示去调整它,就能得到最终的字表示,送往后续的下游任务。

多个分词器下的情况

然而,众所周知,分词器经常会出现问题。

上图是论文里的图(为了和平特意找了个都没分错的例子),这几个分词器得到的结果都是对的,但是其粒度不同。

为了减少分词错误,以及用上不同粒度级别的特征,我们找了一种简单的方法,同时用上多个分词工具的分词结果。

真的很简单,就是几个分词器的结果,分别得到下游表示之后过个线性层结合在一起而已。

实验证明这样是有一定效果的。

实验结果

都在原文里有,没啥槽点,就是做实验耗的时间太多了。

总结

总结一下这个工作的优缺点:

优点:

  • 提出了这么一种有意思的结构
  • 这么一种有意思的结构可以融入一些分词信息,并且对预训练语言模型的下游任务有一些帮助
  • 单纯融入一种分词信息不够,就多加几种分词信息

缺点:

  • 实在缺乏理论支撑
  • 预处理的真的特别特别慢(尤其是要用几种分词器来分词),并且数据预处理无比复杂(因为各个分词器的处理逻辑都不一样,各种特殊符号、数字、英语、日语、繁体啥的全部都要单独处理,尤其是 BERT 会将英语单词 tokenize 成 word-piece,导致 token 对不上,前期实验有 80% 以上的时间都是在搞这些预处理)
  • 在 forward 的时候把 transformer 的时间复杂度 $O(n^2)$ 变成了 $O(d n^2)$(这还好是常数级),但是要命的是,在这个方法中,每一条训练数据都会有各自不同的分词方式,都只能各自去分段计算 mix-pooling,这导致完全无法应用 cudnn 原语加速,也完全没可能写成矩阵运算来利用 GPU batch 加速,即使直接用 cuda 编程也没法改善。连 forward 都这么慢,backward 更不用说了……这点是致命的,让我的实验时间变得特别特别长,跑个 CMRC 数据集硬生生把 6 个小时的训练时间搞成了 28 个小时,心态都炸了。

总结下来,这个工作其实缺点其实挺明显的,主要集中在预处理和速度极慢这两块上。吐槽:但投稿时 call for short paper 写明白了就是欢迎分享这些不是很完善的 idea 呀,不懂为啥要使劲冲着缺陷打,没这些问题投长文不香吗?

优点主要还是这个结构足够新颖。由于这种东西的预处理实在太 dirty 了,跑起来也慢的令人抓狂,我是不打算 follow 这个工作继续做下去了。但是,这种有意思的结构可以用在其它一些 NLP 应用里面,还是可以做一做的。

后记

在郁博文师兄的帮助下第一次写这种实验性质的短文也是挺有意思的。我受到的指导,和我写的文章,一般都是发现问题->分析问题->分析方案->理论支撑方案->实验支撑理论这么个范式;而这篇文章是发现问题->分析问题->哇,有灵感了->实验结果还不错这么个流程,还是蛮奇妙的。但说到底还是缺乏理论支撑,我去年曾尝试用离散数学去建模分词和这个模型的过程(有图为证),还试图用正则化或者标准化等深度学习术语来解释这种模型,但都成功地浪费了大量的时间,在没有理论支撑的情况下,也只能这样了。

-w202

这篇文章的录用还是很侥幸的。在审稿 rebuttal 的时候,审稿人给的分和评价都很一般。正如前文所说,文本的确有很多问题,但几位审稿人最主要的关注点居然都主要集中在空间复杂度和训练参数数量上面,没有抓主要矛盾而是重点抓次要矛盾去了。所以简单回答这些关于参数、空间占用之类的问题值后,有位审稿人改了分,这才被录用。

最后这篇论文出来的时候真是命运多舛,赶上了 2020 年的疫情,不让回实验室,资料、代码啥的全在工位台式机上,又赶上组里的大工程和自己的毕设,只能抽空远程一点一点扒代码,扒到开会都没扒完;后来都有好几位老师同学发邮件索取了,都没办法直接发给人家可以直接跑的模型,只给一个老师发了最主要的那个 attention align 模块,也不知道有没有帮上他的忙;好在后来找了点办法能远程直连了,不然更难受。