【NLP论文笔记】Sequence to Sequence Learning with Neural Networks

Posted 2023-04-17

参考技术A 本文主要用于记录谷歌发表于2014年的一篇神作（引用量上千），现已被广泛使用的Sequence to Sequence模型论文。方便初学者快速入门，以及自我回顾。

论文链接： https://papers.nips.cc/paper/5346-sequence-to-sequence-learning-with-neural-networks.pdf

基本目录如下：

------------------第一菇 - 摘要------------------

深度神经网络（DNNS）在2014年之前已经被证明可用于各种复杂的学习任务，并且均被证实其可行性及高准确率。但是其有一个弊端，即它需要有足够的标注数据，因此其并不适用于去做序列到序列的映射任务（map sequences to sequences）。本论文主要贡献在于提出了一种端到端（end-to-end）的神经网络模型，来学习这种映射关系。作者用一个多层的LSTM网络来将输入序列映射（编码）为一个固定大小纬度的向量，再用另外一个多层的LSTM网络来解码该向量为输出序列。为了论证该模型的可行性，作者将其应用于英语-法语的翻译任务，最终发现其所能达到的效果与当时最好的成绩（可能是某一种SMT，统计机器翻译模型）相差无几。最后，作者对模型以及实验结果进行分析以后，还发现几个有趣的点。1）模型对句子的主动与被动语态并不敏感，但是对输入词的顺序很敏感。2）倒序输入句子能提升模型效果

------------------第二菇 - 核心思想------------------

话不多说，直接介绍该论文提出的模型结构。NLP里面的王牌长短时记忆模型（LSTM）当仁不让的被选为作为该模型的基础。主要的思想就是，用一个LSTM（已经被证实能很好的解决长时序列依赖问题）来编码输入序列，顺序输入序列（one step at a time，并没有对输入序列对长度做限制！），以此我们就会得到一个固定大小纬度的向量表达，然后再用另一个LSTM（本质上就是一个语言模型，除了其初始状态就是输入序列被编码得到的向量）来解码该向量，并得到输出序列。可以说这套Seq2Seq框架的提出，为之后的序列映射任务（比如机器翻译等）的质量提升，奠定了扎实的基础。没有理解透其原理的读者，可以再多看一眼论文的图1，我这边也贴出来了，简单理解一下就是输入序列为ABC以及输入序列结束符号<EOS>，从<EOS>开始解码出WXYZ以及结束符号<EOS>，停止解码。多说一句该模型架构在翻译任务上，均取得了不错的效果，且还有巨大的提升空间（比如引入注意力机制），具体细节可以看论文第一章。

在随后介绍模型的第二章，作者也强调了他们对LSTM一些改进的点，主要可以归纳为如下3点：
1）他们使用了2个不同的LSTM模型，以此在增加模型参数的同时，计算量的增加微乎其微，但却提高量模型的泛化能力。
2）实验证明，深层的LSTM模型要比浅层的表现更好，这也符合我们的一贯认知。
3）倒序输入句子，意思就是ABC输入的顺序为CBA，实验表征这样的效果更好。论文自己也很坦诚说自己还没有给出完善的理论依据，但也强行解释了一波，这里我的理解是，顺序与逆序输入并没有改变平均距离（这里距离指的是time step diff），但是却让一开始的几个词他们的距离变短了，而句子末尾的词距离变长的代价似乎并不显著，因此逆序输入会得到更好的效果。

还有一个模型细节可以提一下就是，在解码阶段，beam search解码方式被采用，且能显著提高准确率。该方法其实本质就是在解码各阶段保留多个候选句子，最后在选择概率最大的序列。如果该方法的保留个数为1，其实就是贪心的思想，每一次解码都选取概率最大的那个值。该论文给出的结论是当size为2的时候，模型的表现最好。更多有关该方法的讨论大家可以移步该 博客 。

更多关于模型的训练细节，大家还是仔细看一下论文的第三章，这里就不展开介绍了，唯一想记录的一点就是，他们实验的时候尽量保证一个Batch的句子长度相似，据说提高了2倍的训练速度。

具体的实验结果这里就不展现了，原文中也表述的十分清晰，该框架模
型的结果还是杠杠的，这里具体谈2个比较有趣且有价值的点。
1）模型对句子中词的先后顺序较为敏感，但是对其语态并不敏感。这里再贴一张原文的图如下：

大家可以发现，John和Mary的顺序颠倒以后，并没有很好的聚合到一起，倒是admires和is in love with能聚合到一起，由此可见，我们的模型对句子对顺序是十分敏感的。

2）该框架模型对长句的翻译表现出乎意料的好。这里贴一张原文的图如下：

左图呈现了BLEU分数随着句子长度的增加，我们的模型表现并没有呈现明显的下降趋势（其实还在上升），只有在超过35字以后，才略微有一点下降。这也说明了该模型框架对于长句的处理也是足够能胜任的，能想到的就是在实际应用中可能也不需要特别对长句做特殊处理。

右图呈现的就是对那些比较生僻的句子，模型的泛化能力，可以看到模型下降的趋势还是比较明显的，这倒也不难理解，毕竟生僻句子在数据集本身占比就少，如果有特殊的应用场景，那通常的做法我们都是加该场景下的特殊数据，进行微调，应该也能取得不错的效果。

------------------第三菇 - 总结------------------

到这里，整篇论文的核心思想及其创新点已经说清楚了。这套seq2seq的框架，也为后续的序列映射任务奠定了基础。论文作者也是尤其惊诧逆序输入句子对效果的提升，以及该模型对长句的翻译能力！

简单总结一下本文就是先罗列了一下该论文的摘要，再具体介绍了一下模型细节，最后再具体探讨了几个创新的来结束该论文笔记。希望大家读完本文后能进一步加深对该论文的理解。有说的不对的地方也请大家指出，多多交流，大家一起进步～😁

论文分享：ClueFinder——借助NLP辅助分析Android第三方Lib

说明: 本文是NDSS 2018的论文Finding Clues for Your Secrets: Semantics-Driven, Learning-Based Privacy Discovery in Mobile Apps的阅读笔记, 作者Yuhong Nan, Zhemin Yang, Xiaofeng Wang, Yuan Zhang, Donglai Zhu 与Min Yang, 阅读笔记由上海交大GoSSIP软件安全小组温昊煌提供。

---

1. Abstract

文章出发点在于，目前的app主要都是以后台web服务+前端app构成，信息的传递过程复杂而难以定位。目前对于敏感信息的定位主要集中在定位系统级别的API上，但是这显然是远远不够的。app中可以得到的变量名、方法名、常量等等命名方式都是有其意义的，我们可以根据语义更有效地定位我们想要的敏感信息（即使app有轻微的混淆）。因此，文章提出了一种自然语言处理（NLP）的方法来自动定位我们感兴趣的信息源（变量、方法等），并且利用设计的一种基于学习的程序结构分析来筛选出真正含有敏感信息的内容。

2. Overview

2.1 语义证据发掘

它首先通过关键词、前缀、缩写等表示方法来识别出可能包含敏感信息的内容。例如方法、变量等。 得到这些元素之后，利用NLP技术进行过滤，过滤出真正含有敏感信息的元素。这里文章举了两个例子：“getStreetViewActivity”和”invalid_input_for_home_directory”，看起来像是相关，实则不然。因此这里我们需要根据语义来进行初步筛选。

2.2 基于学习的识别

仅仅基于语义做出判断是不科学的，我们还要结合语境上下文等因素做出判别，这时候我们需要一种基于学习的识别方式。（eg formatInvalidExp(“username”, Exception e)） 作者总共找出了5个特征训练出了一个SVM模式来帮助判别元素中是否含有真正的敏感信息。

2.3 实验结果

作者收集了44w+个app进行大规模分析。结果表明，有26.5%的app将用户隐私泄漏给其他lib，比之前的其他相关研究的数据要高。此方法识别的覆盖范围和精确度都要比其他方法更高。

2.4 假设前提

作者假定研究的app都没有被严重地混淆，仍然能从中提取有用的信息。实际上，app的开发者通常不会混淆数据相关的代码，因为这可能导致app的崩溃。research中表明50%的方法名没有被混淆。有高达98%的app都包含可读的字符串。

3. Design Of ClueFinder

执行流程：Locator反编译并找出可能含敏感信息elements——Checker通过NLP分析过滤掉一部分elements——Analyzer程序结构分析——Tracer追踪隐私信息的传播。

3.1 Semantics Locator

35data item from Google Privacy Policies——定义为private content，包括下图的这些。

扩展词集方法： – 1. 利用word2vec找出同义词。 – 2. 通过stemming从1w+个google app中找出相近的词语（例如有相同前缀的词）

定位思路：拿到一个element，它会先分词把name分成一个个token（根据分隔符、大小写）。从这些token中，若是从词集中匹配出可能包含敏感信息的词汇，则标记此element，进行下一步的检查。

3.2 Semantic Checker

包括两部分：POS（part-of-speech）标记、依赖关系分析

Checker是基于Stanford Parser做的，著名的NLP tool，专门做POS tagging和dependency relation parsing。具体分析例子如下：

3.3 Structure Analyzer

程序结构分析：通过一种叫Jimple的中间语言。

根据一系列的程序结构特征来判断一个敏感的token是否真正触碰到了用户的敏感信息。 观察得出的结论：在数据读写的操作中的elements几乎都与敏感的信息有关。

基于此观察，作者主要关注上述步骤得出的element在其调用语句中是怎样被使用的，以此来分析是否确实存在敏感信息的操作。

• 步骤1: 定位直接或间接与element相关的method invocation。

• 步骤2: 提取方法特征，通过机器学习分析判断。 主要基于以下这些特征

     -方法名中一些get/set/put/insert等可能进行data操作的关键token。

    -参数类型，主要关注data相关的，例如String、HashMap、Json。

    -返回类型，与参数类似。

    -base value类型，针对一些类的数据读写操作。例如hashMap.put和Log就是需要我们区分开。

    -常量，例如hashMap.put(“user”, $u), hashMap.put(“user”, “default”), 两者就是不同概念，因为前者输入了一个疑似user名的参数，而后者仅仅是个常量而已。

基于上述特征，Structure Analyzer通过训练一个SVM分类器来进行分析判断。训练样本使用了随机选择并人工标注的4326条语句。

3.4 Leakage Tracker

在追踪敏感信息的流向时，文章主要关注不受信任的三方库，因为如果要追踪所有的库对于大规模分析而言成本太高。当数据流入这些不受信任的库时，它们存在着被泄漏给第三方的风险。 对此，Tracker从上述得到的element中抽取数据相关的object，并通过数据流进行分析。

4. Evaluation

4.1 环境配置

主要语言：Java Python 数据流分析：Flow-Droid NLP工具：Standford Parser SVM：Scikit-learn 硬件环境：32 core server Linux 2.6.32 kernal 64GB Mem

4.2 训练数据

4326条数据（一半positive一半negative，因为SVM在平衡的数据集下效果是最好的），来自100个Google Play下的主流app（AUG 2016 top list）。 利用locater和checker抽取elements——由两位android专家人工标注。当两者意见同为pos或者neg时才采用（所以本来有7354条，2163条neg）。

4.3 有效性

文章对4326条标记的数据进行十字交叉验证，准确率达92.7%，召回率（代表查全程度）97.2%，F1-Score（综合）94.8%。

然后对随机爬取的100个app组成unknown set进行测试并人工验证，准确率达91.5%（没有召回率是因为人工遍历所有样本太花时间了）。这部分分析花了97min（平均每个app小于1min）。

对于错误判断的例子，作者指出这些都是稀有的个例：

False Positive: 函数名明明叫做saveAppKeyAndSecret也接受了key和secret却没有做什么save之类的敏感的操作，纯标题党= =

False Negative: outlier的干扰。例如一些app中会用1和-1表示gender，而我们一般假定gender是用string表示。

4.4 代码混淆

在上述进行实验的unkonwn set中约有11.3%（426/3775）的语句是被混淆处理过（Proguard）。然而这不一定影响到CludFinder，因为它是根据多个特征来进行判断分析的，除方法名外还有返回值、参数类型等也正影响。 系统级别的方法、数据相关的模块、第三方SDK经常保留了原来的代码，为了程序的正常执行。因此许多重要的语义信息都得到了保留。

4.5 性能对比

作者将ClueFinder与现有的几种类似工具做比较：API-based Labeling、UI-based labeling、Semantics-based taint tracking。结果显示CludFinder有以下优点：覆盖率更高、识别准确率跟高、分析时间更短。

与BidText工具（也是一种基于语义的分析跟踪工具）的性能对比如下：

4.6 大规模泄漏研究

报告对44w+app的分析与测量结果进行大规模泄漏研究

A. 测量指标设置

• 泄漏风险：主要关注将敏感数据泄漏给第三方库，不考虑泄漏给Internet（因为难以从静态分析得出）

• 收集app：测试样本的app主要从google play和tencent android market下载 Leakage Tracker的实现：分析敏感数据的流向，判断流向的API包名/方法名是属于app的还是属于第三方库的（例如com.facebook.xxx从前缀判断）。

B. 测量结果

总共有118296个app（26.5%）泄漏敏感数据到3502个第三方库。平均泄漏8.07项数据到1.97个库。表明信息的泄漏还是比较普遍的。

得出的几个结论：

1. Google Play2015年的应用中泄漏隐私数据最高，达到40%，这一情况在2016有所好转。

2. 经过随机的抽查，发现抽查的100个app中有59个的确通过网络形式将隐私信息泄漏，这一数据还应该更高，因为许多其他手段作者无法探测。

3. 第三方应用市场的应用（例如tencent market）引入第三方的库更多，根源在于其审查机制没有Google那么严格。

4. 第三方库分布和泄漏类型：大部分收集用户信息的库都是一些广告、分析等类型的库。

   
   

• 泄漏信息类型：如下表所示。许多app不一定直接通过系统API来收集信息，它们有可能从其他信息源（database、sp等）间接获取敏感信息，避免频繁调用API而造成用户或者审查的怀疑（真是费尽心思啊…）。并且，许多app收集了许许多多奇怪的信息（例如app list），而这些信息它们应该是不需要的。

  
  

5. After-thoughts

这篇文章的方向还是挺有意思的，NLP与安全的结合给了我们找出泄漏线索的新思路。亮点在于，这种方法相比此前的工作覆盖率更广、准确率更高。文章的工作一共收集了44w+个app进行实验，规模相当之大。它的实验工作也做得比较到位：从泄漏数量、信息种类、库的种类，到工具的效率，数据一应俱全，具有相当的说服力。也难怪文章50%的篇幅都是在讲evaluation的工作。

至于说实现部分，文章大概提供了一个框架式的思路。它都是从已有的轮子出发（Stanford的NLP Parser、python的scikit-learn等等）。这些方法是否拥有最好的效果，我们尚未知晓，因为文章没有对各种learning的算法进行比较。这可能是可以挖掘的一点（虽然已经是跨到ML领域的事情了）。但至少从目前的效果看，90%的准确率还是相当不错的。

对我们现有的工作而言，NLP和基于学习的做法也是一种更好的思路。当前的做法主要通过字符串匹配的方式来寻找我们感兴趣的加密或解密方法。在实战过程中，发现其中其实有许多不必要的方法也被过滤了进来。这使得在大规模分析中寻找我们感兴趣的方法的工作量有所增加。从这个角度上说，如果能借鉴文章中提到的NLP思路来分析函数名称并且能够通过基于学习的程序分析的方法来进一步筛选，我们将能够进一步精确地提取到我们需要的信息。将安全与人工智能相结合的方法，我感觉也是未来可以挖掘的点之一。