PixelNeRF–具有泛化性的NeRF

pixelNeRF: Neural Radiance Fields from One or Few Images

代码链接:https://github.com/sxyu/pixel-nerf

论文链接:https://alexyu.net/pixelnerf/

Nerf提出以来,收到了大量关注。但是,它仍存在以下缺点:

  1. Nerf的训练需要很多标准化的照片
  2. 训练花费大量时间

因此,本文提出了一种基于全卷积的Nerf:pixelNerf。当经过大量训练后,pixelNerf可以仅通过几张(甚至一张)照片进行良好的视图合成,同时这种方式也不需要精确的3D监督(2D监督即可)。

作者提出了pixelNeRF,一个只需要输入单张或多张图像,就能得到连续场景表示的学习框架。由于现存的构建神经辐射场的方法涉及到独立优化每个场景的表示,这需要许多校准的视图和大量的计算时间,因此作者引入了一种新的网络架构。实验结果表明,在所有情况下,pixelNeRF在新视图合成和单图像三维重建方面都优于当前最先进的工作。

该项目主要研究的问题是如何从一个稀疏的输入视图集中合成这个场景的新视图,在可微神经渲染出现之前,这个长期存在的问题一直没有得到进展。同时,最近的神经渲染场NeRF通过编码体积密度和颜色,在特定场景的新视图合成方面表现出很好的效果。虽然NeRF可以渲染非常逼真的新视图,但它通常是不切实际的,因为它需要大量的位姿图像和冗长的场景优化。

在这篇文章中,作者对上述方法进行了改进,与NeRF网络不使用任何图像特征不同的是,pixelNeRF将与每个像素对齐的空间图像特征作为输入。这种图像调节允许框架在一组多视图图像上进行训练,学习场景先验,然后从一个或几个输入图像中合成视图,如下图所示。

PixelNeRF具有很多特点:首先,Pixel可以在多视图图像的数据集上面进行训练,而不需要任何额外的监督;其次,PixelNeRF预测输入图像的摄像机坐标系中的NeRF表示,而不是标准坐标系,这是泛化看不见的场景和物体类别的必要条件,因为在有多个物体的场景中,不存在明确的规范坐标系;第三,它是完全卷积的,这允许它保持图像和输出3D表示之间的空间对齐;最后,PixelNeRF可以在测试时合并任意数量的输入视图,且不需要任何优化。

相关工作

新视图合成:这是一个长期存在的问题,它需要从一组输入视图中构建一个场景的新视图。尽管现在有很多工作都已经取得了逼真的效果,但是存在比较多的问题,例如需要密集的视图和大量的优化时间。其他方法通过学习跨场景共享的先验知识,从单个或少数输入视图进行新的视图合成,但是这些方法使用2.5D表示,因此它们能够合成的摄像机运动范围是有限的。在这项工作中,作者提出了PixelNeRF,能够直接从相当大的基线中合成新视图。

基于学习的三维重建:得益于深度学习的发展,单视图或多视图的三维重建也得到快速的发展。问题是,很多表示方法都需要3D模型进行监督,尽管多视图监督限制更小、更容易获取,其中的很多方法也需要物体的mask。相比之下,PixelNeRF可以单独从图像中训练,允许它应用到含有两个对象的场景而不需要修改。

以观察者为中心的三维重建:对于3D学习任务,可以在以观察者为中心的坐标系(即视图空间)或以对象为中心的坐标系(即规范空间)中进行预测。大多数现存的方法都是在规范空间中进行预测,虽然这使得学习空间规律更加容易,但是会降低不可见对象和具有多个对象场景的预测性能。PixelNeRF在视图空间中操作,这在【2】中已经被证明可以更好地重建看不见的对象类别,并且不鼓励对训练集的记忆。下表是PixelNeRF和其他方法的对比:

NeRF的缺点:

虽然NeRF实现了最新的视图合成,但它是一种基于优化的方法,每个场景必须单独优化,场景之间没有知识共享。这种方法不仅耗时,而且在单个或极稀疏视图的限制下,无法利用任何先验知识来加速重建或完成形状。

基于图像的NeRF:pixelNeRF

为了克服上面提到的关于NeRF的问题,作者提出了一种基于空间图像特征的NeRF结构。该模型由两个部分组成:一个完全卷积的图像编码器E (将输入图像编码为像素对齐的特征网格)和一个NeRF网络f (给定一个空间位置及其对应的编码特征,输出颜色和密度)。

单视图pixelNeRF:首先固定坐标系为输入图像的视图空间,并在这个坐标系中指定位置和摄像机光线。给定场景的输入图像I,首先提取出它的特征量W=E(I)。然后,对于相机光线上的一个点x,通过使用已知的内参,将x投影到图像坐标π(x)上,然后在像素特征之间进行双线性插值来提取相应的图像特征向量W(π(x))。最后把图像特征连同位置和视图方向(都在输入视图坐标系统中)传递到NeRF网络:其中γ()是x上的位置编码。

合并多个视图:多个视图提供了有关场景的附加信息,并解决了单视图固有的三维几何歧义。作者扩展了该模型,不同于现有的在测试时只使用单个输入视图的方法,它允许在测试时有任意数量的视图。

在有多个输入视图的情况下,只假设相对的相机姿态是已知的,为了便于解释,可以为场景任意固定一个世界坐标系。把输入图像记为I,其相关联的摄像机记为P=[R t]。对于新的目标摄影机光线,将视图方向为d的点x转换到每个输入视图i的坐标系,转换如下:

为了获得输出的密度和颜色,作者独立地处理每个视图坐标帧中的坐标和相应的特征,并在NeRF网络中聚合视图。将NeRF网络的初始层表示为f1,它分别处理每个输入视图空间中的输入,并将最终层表示为f2,它处理聚合视图。

和单视图类似,作者将每个输入图像编码成特征体积W(i)=E(I(i))。对于点x(i),在投影图像坐标π(x(i))处从特征体W(i)中提取相应的图像特征,然后将这些输入传递到f1,以获得中间向量:

最后用平均池化算子ψ将中间向量V(i)聚合并传递到最后一层f2,得到预测的密度和颜色:

个人觉得,这篇文章其实就是对原始Nerf做了一个效果很好的改进:将图片进行特征提取后再输入Nerf,(似乎并没有很多的创新),但是从图中展现的效果来看,这一改进是卓有成效的,或许也为我们提供了一种新的思路。

目前的缺陷:

1) Like NeRF, our rendering time is slow, and in fact, our runtime increases linearly when given more input views. Further, some methods (e.g. [28, 21]) can recover a mesh from the image enabling fast rendering and manipulation afterwards, while NeRF based representations cannot be converted to meshes very reliably. Improving NeRF’s efficiency is an important re-search question that can enable real-time applications.

2) As in the vanilla NeRF, we manually tune ray sampling bounds tn,tf and a scale for the positional encoding. Making NeRF-related methods scale-invariant is a crucial challenge.
3) While we have demonstrated our method on real data from the DTU dataset, we acknowledge that this dataset was captured under controlled settings and has matching camera poses across all scenes with limited viewpoints. Ultimately,our approach is bottlenecked by the availability of largescale wide baseline multi-view datasets, limiting the applicability to datasets such as ShapeNet and DTU. Learning
a general prior for 360◦ scenes in-the-wild is an exciting direction for future work

参考文献:

【1】Ben Mildenhall, Pratul P. Srinivasan, Matthew Tancik,Jonathan T. Barron, Ravi Ramamoorthi, and Ren Ng. Nerf: Representing scenes as neural radiance fields for view synthesis. In Eur. Conf. Comput. Vis., 2020

【2】Daeyun Shin, Charless Fowlkes, and Derek Hoiem. Pixels, voxels, and views: A study of shape representations for single view 3d object shape prediction. In IEEE Conf. Comput.Vis. Pattern Recog., 2018.

位置编码系列(NLP and CV领域)

NLP中的位置编码

转载:让研究人员绞尽脑汁的Transformer位置编码

总体结构

Bert问世后瞬间引爆了NLP领域,同时也让Transformer火了起来,Transformer中特征提取的方式不是传统的CNN,RNN等,而是用attention的形式,这种模式被用在AI的各个领域中,包括CV和语音等。attention提取特征的效果非常好,可以非常有效的提取到上下文的信息,但是在NLP中会有个问题:attention提取特征的时候,当前这个字对上下文的其他字的关联性可以很好的体现出来,但是其他字的位置在哪里都可以,在这个字的前面、后面都可以,间隔的距离也没有要求。但其实这跟我们平时表达的语言肯定是矛盾的,于是在Transformer中加入了位置编码。

虽然说起来主要就是绝对位置编码和相对位置编码两大类,但每一类其实又能衍生出各种各样的变种,为此研究人员可算是煞费苦心、绞尽脑汁了,此外还有一些不按套路出牌的位置编码。本文就让我们来欣赏一下研究人员为了更好地表达位置信息所构建出来的“八仙过海,各显神通”般的编码方案。

绝对位置编码

形式上来看,绝对位置编码是相对简单的一种方案,但即便如此,也不妨碍各路研究人员的奇思妙想,也有不少的变种。一般来说,绝对位置编码会加到输入中:在输入的第k个向量  \(xk\)中加入位置向量  \(pk\)变为\(xk+pk\),其中\(pk\)只依赖于位置编号k。

训练式

很显然,绝对位置编码的一个最朴素方案是不特意去设计什么,而是直接将位置编码当作可训练参数,比如最大长度为512,编码维度为768,那么就初始化一个512×768的矩阵作为位置向量,让它随着训练过程更新。现在的BERT、GPT等模型所用的就是这种位置编码,事实上它还可以追溯得更早,比如2017年Facebook的《Convolutional Sequence to Sequence Learning》就已经用到了它。

对于这种训练式的绝对位置编码,一般的认为它的缺点是没有外推性,即如果预训练最大长度为512的话,那么最多就只能处理长度为512的句子,再长就处理不了了。当然,也可以将超过512的位置向量随机初始化,然后继续微调。但笔者最近的研究表明,通过层次分解的方式,可以使得绝对位置编码能外推到足够长的范围,同时保持还不错的效果,因此,其实外推性也不是绝对位置编码的明显缺点。

三角式

三角函数式位置编码,一般也称为Sinusoidal位置编码,是Google的论文《Attention is All You Need》所提出来的一个显式解:

递归式

原则上来说,RNN模型不需要位置编码,它在结构上就自带了学习到位置信息的可能性(因为递归就意味着我们可以训练一个“数数”模型),因此,如果在输入后面先接一层RNN,然后再接Transformer,那么理论上就不需要加位置编码了。同理,我们也可以用RNN模型来学习一种绝对位置编码,比如从一个向量p0出发,通过递归格式pk+1=f(pk)来得到各个位置的编码向量。

ICML 2020的论文《Learning to Encode Position for Transformer with Continuous Dynamical Model》把这个思想推到了极致,它提出了用微分方程(ODE)dpt/dt=h(pt,t)的方式来建模位置编码,该方案称之为FLOATER。显然,FLOATER也属于递归模型,函数h(pt,t)可以通过神经网络来建模,因此这种微分方程也称为神经微分方程,关于它的工作最近也逐渐多了起来。

理论上来说,基于递归模型的位置编码也具有比较好的外推性,同时它也比三角函数式的位置编码有更好的灵活性(比如容易证明三角函数式的位置编码就是FLOATER的某个特解)。但是很明显,递归形式的位置编码牺牲了一定的并行性,可能会带速度瓶颈。

相乘式

刚才我们说到,输入xk与绝对位置编码pk的组合方式一般是xk+pk,那有没有“不一般”的组合方式呢?比如xk⊗pk(逐位相乘)?我们平时在搭建模型的时候,对于融合两个向量有多种方式,相加、相乘甚至拼接都是可以考虑的,怎么大家在做绝对位置编码的时候,都默认只考虑相加了?

很抱歉,笔者也不知道答案。可能大家默认选择相加是因为向量的相加具有比较鲜明的几何意义,但是对于深度学习模型来说,这种几何意义其实没有什么实际的价值。最近笔者看到的一个实验显示,似乎将“加”换成“乘”,也就是xk⊗pk的方式,似乎比xk+pk能取得更好的结果。具体效果笔者也没有完整对比过,只是提供这么一种可能性。关于实验来源,可以参考《中文语言模型研究:(1) 乘性位置编码》

相对位置编码

相对位置并没有完整建模每个输入的位置信息,而是在算Attention的时候考虑当前位置与被Attention的位置的相对距离,由于自然语言一般更依赖于相对位置,所以相对位置编码通常也有着优秀的表现。对于相对位置编码来说,它的灵活性更大,更加体现出了研究人员的“天马行空”。

经典式

相对位置编码起源于Google的论文《Self-Attention with Relative Position Representations》,华为开源的NEZHA模型也用到了这种位置编码,后面各种相对位置编码变体基本也是依葫芦画瓢的简单修改。

一般认为,相对位置编码是由绝对位置编码启发而来,考虑一般的带绝对位置编码的Attention:

XLNET式

XLNET式位置编码其实源自Transformer-XL的论文《Transformer-XL: Attentive Language Models Beyond a Fixed-Length Context》,只不过因为使用了Transformer-XL架构的XLNET模型并在一定程度上超过了BERT后,Transformer-XL才算广为人知,因此这种位置编码通常也被冠以XLNET之名。

T5式

T5模型出自文章《Exploring the Limits of Transfer Learning with a Unified Text-to-Text Transformer》,里边用到了一种更简单的相对位置编码。思路依然源自展开式(7)(7),如果非要分析每一项的含义,那么可以分别理解为“输入-输入”、“输入-位置”、“位置-输入”、“位置-位置”四项注意力的组合。如果我们认为输入信息与位置信息应该是独立(解耦)的,那么它们就不应该有过多的交互,所以“输入-位置”、“位置-输入”两项Attention可以删掉,而piWQW⊤Kp⊤j⊤实际上只是一个只依赖于(i,j)的标量,我们可以直接将它作为参数训练出来,即简化为

说白了,它仅仅是在Attention矩阵的基础上加一个可训练的偏置项而已,而跟XLNET式一样,在vj上的位置偏置则直接被去掉了。包含同样的思想的还有微软在ICLR 2021的论文《Rethinking Positional Encoding in Language Pre-training》中提出的TUPE位置编码。

DeBERTa式

DeBERTa也是微软搞的,去年6月就发出来了,论文为《DeBERTa: Decoding-enhanced BERT with Disentangled Attention》,最近又小小地火了一把,一是因为它正式中了ICLR 2021,二则是它登上SuperGLUE的榜首,成绩稍微超过了T5。

其实DeBERTa的主要改进也是在位置编码上,同样还是从展开式(7)(7)出发,T5是干脆去掉了第2、3项,只保留第4项并替换为相对位置编码,而DeBERTa则刚刚相反,它扔掉了第4项,保留第2、3项并且替换为相对位置编码(果然,科研就是枚举所有的排列组合看哪个最优):

不过,DeBERTa比较有意思的地方,是提供了使用相对位置和绝对位置编码的一个新视角,它指出NLP的大多数任务可能都只需要相对位置信息,但确实有些场景下绝对位置信息更有帮助,于是它将整个模型分为两部分来理解。以Base版的MLM预训练模型为例,它一共有13层,前11层只是用相对位置编码,这部分称为Encoder,后面2层加入绝对位置信息,这部分它称之为Decoder,还弄了个简称EMD(Enhanced Mask Decoder);至于下游任务的微调截断,则是使用前11层的Encoder加上1层的Decoder来进行。

SuperGLUE上的成绩肯定了DeBERTa的价值,但是它论文的各种命名真的是让人觉得极度不适,比如它自称的“Encoder”、“Decoder”就很容易让人误解这是一个Seq2Seq模型,比如EMD这个简称也跟Earth Mover’s Distance重名。虽然有时候重名是不可避免的,但它重的名都是ML界大家都比较熟悉的对象,相当容易引起误解,真不知道作者是怎么想的…

其他位置编码

绝对位置编码和相对位置编码虽然花样百出,但仍然算是经典范围内,从上述介绍中我们依然可以体会到满满的套路感。除此之外,还有一些并不按照常规套路出牌,它们同样也表达了位置编码。

CNN式

尽管经典的将CNN用于NLP的工作《Convolutional Sequence to Sequence Learning》往里边加入了位置编码,但我们知道一般的CNN模型尤其是图像中的CNN模型,都是没有另外加位置编码的,那CNN模型究竟是怎么捕捉位置信息的呢?

如果让笔者来回答,那么答案可能是卷积核的各项异性导致了它能分辨出不同方向的相对位置。不过ICLR 2020的论文《How Much Position Information Do Convolutional Neural Networks Encode?》给出了一个可能让人比较意外的答案:CNN模型的位置信息,是Zero Padding泄漏的!

我们知道,为了使得卷积编码过程中的feature保持一定的大小,我们通常会对输入padding一定的0,而这篇论文显示该操作导致模型有能力识别位置信息。也就是说,卷积核的各向异性固然重要,但是最根本的是zero padding的存在,那么可以想象,实际上提取的是当前位置与padding的边界的相对距离。

不过,这个能力依赖于CNN的局部性,像Attention这种全局的无先验结构并不适用,如果只关心Transformer位置编码方案的读者,这就权当是扩展一下视野吧。

复数式

复数式位置编码可谓是最特立独行的一种位置编码方案了,它来自ICLR 2020的论文《Encoding word order in complex embeddings》。论文的主要思想是结合复数的性质以及一些基本原理,推导出了它的位置编码形式(Complex Order)为:

代表词j的三组词向量。你没看错,它确实假设每个词有三组跟位置无关的词向量了(当然可以按照某种形式进行参数共享,使得它退化为两组甚至一组),然后跟位置k相关的词向量就按照上述公式运算。

你以为引入多组词向量就是它最特立独行的地方了?并不是!我们看到式(11)(11)还是复数形式,你猜它接下来怎么着?将它实数化?非也,它是将它直接用于复数模型!也就是说,它走的是一条复数模型路线,不仅仅输入的Embedding层是复数的,里边的每一层Transformer都是复数的,它还实现和对比了复数版的Fasttext、LSTM、CNN等模型!这篇文章的一作是Benyou Wang,可以搜到他的相关工作基本上都是围绕着复数模型展开的,可谓复数模型的铁杆粉了~

融合式

无偶独有,利用复数的形式,笔者其实也构思了一种比较巧的位置编码,它可以将绝对位置编码与相对位置编码融于一体,分享在此,有兴趣的读者欢迎一起交流研究。

简单起见,我们先假设qm,kn是所在位置分别为m,n的二维行向量,既然是二维,那么我们可以将它当作复数来运算。我们知道,Attention关键之处在于向量的内积,用复数表示为

来赋予[x,y]绝对位置信息,那么在Attention运算的时候也等价于相对位置编码。如果是多于二维的向量,可以考虑每两维为一组进行同样的运算,每一组的θ可以不一样。

这样一来,我们得到了一种融绝对位置与相对位置于一体的位置编码方案,从形式上看它有点像乘性的绝对位置编码,通过在q,k中施行该位置编码,那么效果就等价于相对位置编码,而如果还需要显式的绝对位置信息,则可以同时在v上也施行这种位置编码。总的来说,我们通过绝对位置的操作,可以达到绝对位置的效果,也能达到相对位置的效果,初步实验显示它是可以work的,但还没有充分验证,欢迎大家尝试交流。

Elasticsearch

ES既是搜索引擎又是数据库:ElasticSearch究竟是不是数据库?历来存在争议.它是搜索引擎,千真万确,而它是数据库,需要看数据库的界定范围.广义上讲,关系型数据库,对象型数据库,搜索引擎,文件,都可以算作是数据库.数据库是用来存储数据的,为服务应用提供了数据的读写功能,即数据的添加,修改,删除,查询四种基本功能.

1.关系型数据库,诸如:transact-sql,plsql,mysql,firebird,maria等,具备了增删改查四种基本功能.

2.对象型数据库,诸如:redis,mongo等,也具备了增删改查四种基本功能.

3.搜索引擎,就是提到的elasticsearch,也具备了增删改查四种基本功能.

4.文件,比如:sqlite,也具备了增删改查四种基本功能.

ES: 基于Lucene框架的搜索引擎产品。you know for search. 提供了restful风格的操作接口。

ELK,日志检索

Lucene:是一个非常高效的全文检索引擎框架。Java开发的,只提供单机功能。

ES的一些核心概念:

1、索引index:关系型数据库中的table

2、文档document:行

3、字段 field text/keyword/byte:列

4、映射Mapping: Schema

5、查询方式 DSL:SQL ES新版本也支持SQL

6、分片sharding和副本replicas:index都是由sharding组成的。每个sharding都有一个或多个备份。ES集群健康状态。

1)Elasticsearch是搜索引擎

Elasticsearch在搜索引擎数据库领域排名绝对第一,内核基于Lucene构建,支持全文搜索是职责所在,提供了丰富友好的API。个人早期基于Lucene构建搜索应用,需要考虑的因素太多,自接触到Elasticsearch就再无自主开发搜索应用。普通工程师要想掌控Lucene需要一些代价,且很多机制并不完善,需要做大量的周边辅助程序,而Elasticsearch几乎都已经帮你做完了。

2)Elasticsearch不是搜索引擎

说它不是搜索引擎,估计很多从业者不认可,在个人涉及到的项目中,传统意义上用Elasticsearch来做全文检索的项目占比越来越少,多数时候是用来做精确查询加速,查询条件很多,可以任意组合,查询速度很快,替代其它很多数据库复杂条件查询的场景需求;甚至有的数据库产品直接使用Elasticsearch做二级索引,如HBase、Redis等。Elasticsearch由于自身的一些特性,更像一个多模数据库。

图示:Elasticsearch综合数据库排名热度已经到第7

3)Elasticsearch是数据库

Elasticsearch使用Json格式来承载数据模型,已经成为事实上的文档型数据库,虽然底层存储不是Json格式,同类型产品有大名鼎鼎的MongoDB,不过二者在产品定位上有差别,Elasticsearch更加擅长的基于查询搜索的分析型数据库,倾向OLAP;MongoDB定位于事务型应用层面OLTP,虽然也支持数据分析,笔者简单应用过之后再无使用,谁用谁知道。

4)Elasticsearch不是数据库

Elasticsearch不是关系型数据库,内部数据更新采用乐观锁,无严格的ACID事务特性,任何企图将它用在关系型数据库场景的应用都会有很多问题,很多其它领域的从业者喜欢拿这个来作为它的缺陷,重申这不是Elasticsearch的本质缺陷,是产品设计定位如此。

图示:Elastic擅长的应用场景

2、ES做什么

Elasticsearch虽然是基于Lucene构建,但应用领域确实非常宽泛。

1)全文检索

Elasticsearch靠全文检索起步,将Lucene开发包做成一个数据产品,屏蔽了Lucene各种复杂的设置,为开发人员提供了很友好的便利。很多传统的关系型数据库也提供全文检索,有的是基于Lucene内嵌,有的是基于自研,与Elasticsearch比较起来,功能单一,性能也表现不是很好,扩展性几乎没有。

如果,你的应用有全文检索需求,建议你优先迁移到Elasticsearch平台上来,其提供丰富的Full text queries会让你惊讶,一次用爽,一直用爽。

图示:Elasticsearch官方搜索文档

2)应用查询

Elasticsearch最擅长的就是查询,基于倒排索引核心算法,查询性能强于B-Tree类型所有数据产品,尤其是关系型数据库方面。当数据量超过千万或者上亿时,数据检索的效率非常明显。

个人更看中的是Elasticsearch在通用查询应用场景,关系型数据库由于索引的左侧原则限制,索引执行必须有严格的顺序,如果查询字段很少,可以通过创建少量索引提高查询性能,如果查询字段很多且字段无序,那索引就失去了意义;相反Elasticsearch是默认全部字段都会创建索引,且全部字段查询无需保证顺序,所以我们在业务应用系统中,大量用Elasticsearch替代关系型数据库做通用查询,自此之后对于关系型数据库的查询就很排斥,除了最简单的查询,其余的复杂条件查询全部走Elasticsearch。

3)大数据领域

Elasticserach已经成为大数据平台对外提供查询的重要组成部分之一。大数据平台将原始数据经过迭代计算,之后结果输出到一个数据库提供查询,特别是大批量的明细数据。

这里会面临几个问题,一个问题是大批量明细数据的输出,如何能在极短的时间内写到数据库,传统上很多数据平台选择关系型数据库提供查询,比如MySQL,之前在这方面吃过不少亏,瞬间写入性能极差,根本无法满足要求。另一个问题是对外查询,如何能像应用系统一样提供性能极好的查询,不限制查询条件,不限制字段顺序,支持较高的并发,支持海量数据快速检索,也只有Elasticsearch能够做到比较均衡的检索。

从官方的发布版本新特性来看,Elasticseacrch志在大数据分析领域,提供了基于列示存储的数据聚合,支持的聚合功能非常多,性能表现也不错,笔者有幸之前大规模深度使用过,颇有感受。

Elasticsearch为了深入数据分析领域,产品又提供了数据Rollup与数据Transform功能,让检索分析更上一层楼。在数据Rollup领域,Apache Druid的竞争能力很强,笔者之前做过一些对比,单纯的比较确实不如Druid,但自Elasticsearch增加了Transfrom功能,且单独创建了一个Transfrom的节点角色,个人更加看好Elasticseach,跳出了Rollup基于时间序列的限制。

图示:Rollup执行过程数据转换示意图

4)日志检索

著名的ELK三件套,讲的就是Elasticsearch,Logstash,Kibana,专门针对日志采集、存储、查询设计的产品组合。很多第一次接触到Elasticsearch的朋友,都会以为Elasticsearch是专门做日志的,其实这些都是误解,只是说它很擅长这个领域,在此领域大有作为,名气很大。

日志自身特点没有什么通用的规范性,人为的随意性很大,日志内容也是任意的,更加需求全文检索能力,传统技术手段本身做全文检索很是吃力。而Elasticsearch本身起步就是靠全文检索,再加上其分布式架构的特性,非常符合海量日志快速检索的场景。今天如果还发现有IT从业人员用传统的技术手段做日志检索,应该要打屁股了。

如今已经从ELK三件套发展到Elastic Stack了,新增加了很多非常有用的产品,大大增强了日志检索领域。

5)监控领域

指标监控,Elasticsearch进入此领域比较晚,却赶上了好时代,Elasticsearch由于其倒排索引核心算法,也是支持时序数据场景的,性能也是相当不错的,在功能性上完全压住时序数据库。

Elasticsearch搞监控得益于其提供的Elastic Stack产品生态,丰富完善,很多时候监控需要立体化,除了指标之外,还需要有各种日志的采集分析,如果用其它纯指标监控产品,如Promethues,遇到有日志分析的需求,还必须使用Elasticsearch,这对于技术栈来说,又扩增了,相应的掌控能力会下降,个人精力有限,无法同时掌握很多种数据产品,如此选择一个更加通用的产品才符合现实。

图示 :Elastic性能对比时序数据库(来自腾讯云分享)

6)机器学习

机器学习最近几年风吹的很大,很多数据产品都集成了,Elasticsearch也必须有,而且做的更好,真正将机器学习落地成为一个产品 ,简化使用,所见所得;而不像其它数据产品,仅仅集成算法包,使用者还必须开发很多应用支持。

Elasticsearch机器学习提供了两种方式,一种是异常检测类型,属于无监督学习,采用聚类模型,通常应用在安全分析领域,检测异常访问等;一种是数据帧分析,属于分类与回归,属于监督学习,可用于在业务模型领域,如电商行业,价格模型分析。

Elasticsearch本身是数据平台,集成了部分机器学习算法,同时又集成了Kibana可视化操作,使得从数据采集、到模型训练、到模型预测应用都可以一键式完成。

Elasticserach提供的机器学习套件,个人认为最应该应用在数据质量这个领域,帮助大数据平台自动检测数据质量,从而降低人力提供效率。

图示 :机器学习应用示意图(截图)

需求等级

Elasticsearch整个的技术栈非常复杂,涉及到的理论与技术点非常多,完全掌握并不现实,作为一个IT从业者,首先是定位好自己的角色,依据角色需求去学习掌握必备的知识点。以下是笔者对于一个技术产品的划分模型:

1、概念

Elasticsearch涉及到的概念很多,核心概念其实就那么几个,对于一个新手来说,掌握概念目的是为了建立起自己的知识思维模型,将之后学习到的知识点做一个很好的归纳划分;对于一个其它数据产品的老手来说 ,掌握概念的目的是为了与其它数据产品划分比较,深入的了解各自的优劣,在之后工作中若有遇到新的业务场景,可以迅速做出抉择。

IT从业者普遍都有个感受,IT技术发展太快了,各种技术框架产品层出不穷,学习掌握太难了,跟不上节奏。其实个人反倒觉得变化不大,基础理论核心概念并没有什么本质的发展变化,无非是工程技术实操变了很多,但这些是需要深入实践才需要的,对于概念上无需要。

作为一个技术总监,前端工程师工作1~2年的问题都可以问倒他,这是大家对于概念认知需求不一样。

图示:Elasticsearch核心概念

2、开发

开发工程师的职责是将需求变成可以落地运行的代码。Elasticsearch的应用开发工作总结起来就是增删改查,掌握必备的ES REST API,熟练运用足以。笔者之前任职某物流速运公司,负责Elasticsearch相关的工作,公司Elasticsearch的需求很多,尤其是查询方面,ES最厉害的查询是DSL,这个查询语法需要经常练习使用,否则很容易忘记,当每次有人询问时,都安排一个工程师专门负责各种解答,他在编写DSL方面非常熟练,帮助了很多的工程师新手使用Elasticsearch,屏蔽了很多细节,若有一些难搞定的问题,会由我来解决,另外一方面作为负责人的我偶然还要请他帮忙编写DSL。

Elasticsearch后面提供了SQL查询的功能,但比较局限,复杂的查询聚合必须回到DSL。

图示:DSL语法复杂度较高

3、架构

Elasticsearch集群架构总体比较复杂,首先得深入了解Elasticseach背后实现的原理,包括集群原理、索引原理、数据写入过程、数据查询过程等;其次要有很多案例实战的机会,遇到很多挑战问题 ,逐一排除解决,增加自己的经验。

对于开发工程师来说,满足日常需求开发无需掌握这些,但对于Elasticsearch技术负责人,就非常有必要了,面对各种应用需求,要能从架构思维去平衡,比如日志场景集群需求、大数据分析场景需求、应用系统复杂查询场景需求等,从实际情况设计集群架构以及资源分配等。

4、运维

Elasticsearch本质是一个数据库,也需要有专门的DBA运维,只是更偏重应用层面,所以运维职责相对传统DBA没有那么严苛。对于集群层面必须掌握集群搭建,集群扩容、集群升级、集群安全、集群监控告警等;另外对于数据层面运维,必须掌握数据备份与还原、数据的生命周期管理,还有一些日常问题诊断等。

5、源码

Elasticsearch本身是开源,阅读源码是个很好的学习手段,很多独特的特性官方操作文档并没有写出来,需要从源码中提炼,如集群节点之间的连接数是多少,但对于多数Elasticsearch从业者来说,却非必要。了解到国内主要是头部大厂需要深入源码定制化改造,更多的是集中在应用的便捷性改造,而非结构性的改造,Elastic原厂公司有几百人的团队做产品研发,而国内多数公司就极少的人,所以从产量上来说,根本不是一个等级的。

如果把Elasticsearch比喻为一件军事武器,对于士兵来说 ,熟练运用才是最重要的,至于改造应该是武器制造商的职责,一个士兵可以使用很多武器装备,用最佳的组合才能打赢一场战争,而不是去深入原理然后造轮子,容易本末倒置。

6、算法

算法应该算是数据产品本质的区别,关系型数据库索引算法主要是基于B-Tree, Elasticserach索引算法主要是倒排索引,算法的本质决定了它们的应用边界,擅长的应用领域。

通常掌握一个新的数据产品时,个人的做法是看它的关键算法。早期做过一个地理位置搜索相关的项目,基于某个坐标搜索周边的坐标信息,开始的时候采用的是三角函数动态计算的方式,数据量大一点,扫描一张数据表要很久;后面接触到Geohash算法,按照算法将坐标编码,存储在数据库中,基于前缀匹配查询,性能高效几个数量级,感叹算法的伟大;再后面发现有专门的数据库产品集成了Geohash算法,使用起来就更简单了。

Elasticsearch集成很多算法,每种算法实现都有它的应用场景。

拥抱ES的方法

1、官方文档

Elasticsearch早期出过一本参考手册《Elastic权威指南》,是一本很好的入门手册,从概念到实战都有涉及,缺点是版本针对的2.0,过于陈旧,除去核心概念,其余的皆不适用,当前最新版本已经是7.7了,跨度太大,Elasticsearch在跨度大的版本之间升级稍微比较麻烦,索引数据几乎是不兼容的,升级之后需要重建数据才可。

Elasticsearch当前最好的参考资料是官方文档,资料最全,同步发布版本,且同时可以参考多个版本。Elasticsearch官方参考文档也是最乱的,什么资料都有,系统的看完之后感觉仍在此山中,有点类似一本字典,看完了字典,依然写不好作文;而且资料还是英文的,至此就阻挡了国内大部分程序进入。

但想要学习Elasticsearch,官方文档至少要看过几遍,便于迅速查询定位。

图示:官方文档截图说明

2、系统学习

Elasticsearch成名很早,国内也有很多视频课程,多数比较碎片,或是纸上谈兵,缺乏实战经验。Elasticsearch有一些专门的书籍,建议购买阅读,国内深度一些的推荐《Elasticsearch源码解析与优化实战》,国外推荐《Elasticsearch实战》,而且看书还有助于培养系统思维。

Elasticsearch技术栈功能特性很多,系统学习要保持好的心态,持之以恒,需要很长时间,也需要参考很多资料。

3、背后原理

Elasticsearch是站在巨人肩膀上产品,背后借鉴了很多设计思想,集成了很多算法,官方的参考文档在技术原理探讨这块并没有深入,仅仅点到为止。想要深入了解,必须得另辟蹊径。

Elastic官方的博客有很多优质的文章,很多人因为英文的缘故会忽视掉,里面有很多关键的实现原理,图文并茂,写得非常不错;另外国内一些云厂商由于提供了Elasticsearch云产品,需要深度定制开发,也会有一些深入原理系列的文章,可以去阅读参考,加深理解。对于已经有比较好的编程思维的人,也可以直接去下载官方源码,设置断点调试阅读。

4、项目实战

项目实战是非常有效的学习途径,考过驾照的朋友都深有体会,教练一上来就直接让你操练车,通过很多次的练习就掌握了。Elasticsearch擅长的领域很多,总结一句话就是“非强事务ACID场景皆可适用”,所以可以做的事情也很多。

日志领域的需求会让你对于数据写入量非常的关心,不断的调整优化策略,提高吞吐量,降低资源消耗;业务系统的需求会让你对数据一致性与时效性特别关心,从其它数据库同步到ES,关注数据同步的速度,关注数据的准确性,不断的调整你的技术方案与策略;大数据领域的需求会让你对于查询与聚合特别关注,海量的数据需要快速的检索,也需要快速的聚合结果。

项目实战的过程,就是一个挖坑填坑的过程,实战场景多了,解决的问题多了,自然就掌握得很好了。

IBRNet: Learning Multi-View Image-Based Rendering(用NeRF做可泛化视角插值)

IBRNet: Learning Multi-View Image-Based Rendering

主页:https://ibrnet.github.io/

代码链接:https://github.com/googleinterns/IBRNet

NeRF存在的一大问题就是仅仅只能表示一个场景,因此这篇文章就学提出了一个框架可以同时学习多个场景,且可以扩展到没有学习过的场景(提高泛化性)。实验表明,在寻求泛化到新scenes时,我们的方法比其它好。更进一步,如果fine-tuned每一个scene,可以实现和目前SOTA的NVS任务相当的表现。

本文与NeRF最大的不同是输入的数据不仅仅有目标视角,还有对应的所有同一场景的多视角图片,因此理论上的确是可以直接端到端的应用于新场景的。原始NeRF针对每个scene都需要优化(重头训练),而本文方法学习一个通用的view插值函数能够泛化到新的scenes。

overview_image

模型流程:

1. 将同一场景的多视角图片一同输入网络(个数不限),然后使用一个U-Net来抽取每张图片(source view)的特征,特征包括图像颜色,相机参数,图像表征(这里可以就理解成NeRF中的向辐射场发射光线,然后保存对应的光线参数和图片特征)。

2. 之后将每张图片的特征并行的输入一个transformer,用于预测一个共同的颜色和密度。之所以是共同的颜色和密度是因为这多个视角输入的特征我们默认是同一个点在不同视角的特征,因此结果就是用于预测我们目标视角(target view)里此点的结果。

3. 用体渲染的方式将结果渲染出来,之后通过像素的重构损失来优化网络

4. 换一个场景,重复1~3

备注:如果一直用同一个场景训练的话,理论上效果肯定会更好,也就是论文中提到的finetune的情况。

个人理解:本质上这里的模型学习的是“如何插值”,而不是构建一个辐射场,因此可能对于较为稀疏的情形或复杂场景表现的没那么好。

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

Chain of Thought

paper: https://arxiv.org/abs/2201.11903

  • zero-shot:输入问题,等待输出结果
  • CoT:输入问题并提示Let’s think step by step
  • Manual-CoT: 是一种few shot方法,所以构造了一些模板Q&A(模板A中也有Let’s think step by step),然后再给出问题并提示Let’s think step by step
  • Auto-CoT:采样多个问题,每个问题提示Let’s think step by step,让模型给出答案。然后拼接所有生成的Q&A并给出最终问题,并提示Let’s think step by step

为什么需要CoT?

问题可以分为两类:一类是容易回答的,没有太多逻辑推理的,比如:天气如何?面包几块钱?另一类是需要长链条的逻辑推理的问题:数学等。

当语言模型的规模指数级增大时,它解决常规问题的能力有了很大的提升,然而它解决逻辑推理的问题的能力却提升很小。而CoT就是帮助解决这样的问题,它的核心思想是:不要光给出答案,把推理过程也给出来。如下图所示,关键在于构造的prompt要包含推理过程:

为什么延长推理过程就有效呢?这可能是因为语言模型token-by-token的特点。

标准的prompt可以被视为大模型能力的下限,如何提取大模型学到的知识的问题是一个难点,标准的prompt是一个很好的起点,但却绝不是终点。

数据存储方案 –NAS

NAS(Network Attached Storage:网络附属存储),简单来说,就是个人或中小型企业私用的网络存储服务器。区别于百度云,坚果云等公有云存储,由于NAS的硬件是在本地放置,所以可以称为私有云。

简单解释NAS就是私人的7*24小时在线的存储服务器,1996年美国硅谷首先提出NAS概念,把存储设备和网络接口集成在一起,直接通过网络存取数据。网络附属存储(NAS)是一种专业的网络文件存储及文件备份设备。它通过自带的网络接口把存储设备直接连入到网络中,实现海量数据的网络共享,把应用程序服务器从繁重的I/O负载中解脱出来,从而把存储功能从通用文件服务器中分离出来,获得更高的存取效率,更低的存储成本。硬件层面上NAS就是一台电脑,但是跟普通电脑的技能点分配还是略有区别的。

1、 Network Attached Storage

NAS 的全称是 Network Attached Storage,翻译成中文就是网络附加存储。我们来拆解一下就是网络、附加、存储。存不需要过多的解释,就是来存储东西的。附加的意思就是这块存储可以轻松的附加上,或者取下而不影响系统使用。对比我们电脑上的硬盘,就不能说是附加的。因为电脑硬盘不能随便的取下,而且硬盘取下来之后你的电脑就没法用了。网络的意思是想要访问存储里面的内容,需要有网络才行,不管是公网还是局域网反正得有网。

简单来说,NAS 提供存储服务,可用通过网络来访问存储里面的内容

2、超大容量

NAS 作为一台存储服务器,它的主要功能是存储,相比于我们普通的硬盘,NAS 最大的特点是存储空间共享,也就是网络访问。基于网络访问就可以实现其他很多功能如数据同步,照片备份,重要资料备份等等。NAS 的容量是很大的,一般都是以 T 为单位(1TB = 1024GB)。NAS 存储本身也是可以扩展的,通过累计叠加多个硬盘容量,可以扩大存储空间。NAS 系统一天 24 小时待命,没有用一会关机一会儿这种说法。因此 NAS 对磁盘的稳定性要求很高。

3、数据共享

任何设备,只要你能连上 NAS 并且赋予了访问权限,你就可以访问 NAS 中存储的数据。我们可以在手机、笔记本、iPad、智能电视上访问 NAS 中的数据。就像使用本地存储一样,非常的方便。NAS 的一个使用场景是办公共享,在一个局域网内可以实现办公的连续性。当文件在电脑被编辑保存之后,可以用 iPad 接着编辑。

4、安全存储

企业最看重这一点。安全对于企业来说,主要从两方面来讲,一是数据不能丢,而是数据不能泄露给别人。NAS 都具备强大的数据备份功能,可以提供安全不丢失的数据存储,这解决了上面的第一个问题;而解决第二个问题的方式也很简单,自己保存数据,不要用第三方的服务就行。

NAS 的使用场景:视频下载\备份手机上的照片,文件

NAS有一个重要的功能,异地访问,现在的家庭用户基本都没有自己的公网IP,就算是有路由器,内网穿透,端口映射等等的设置也是相当繁琐的。当然成品NAS一般都有自己的中转服务器可以实现异地访问的功能,但是传输速度相当感人。

英伟达显卡监控工具nvtop & 深度学习cuda+pytorch安装教程

背景

在用英伟达显卡做深度学习训练或推理时,我们常用nvidia-smi指令来查看显卡的使用情况,如图所示

这种方法可以看出每张显卡内存和GPU利用率的实时情况,但看不出历史数据和变化曲线,这个时候就需要用到nvtop了。

Nvtop代表NVidia TOP,这是用于NVIDIA GPU的任务监视器。它可以处理多个GPU,并以熟悉的方式打印有关它们的信息。如图所示,很直观的显示了每张显卡的内存、GPU利用率曲线。本文对该工具的安装使用进行介绍。

1 安装方法

在Ubuntu disco (19.04) / Debian buster (stable)系统中,可以直接使用apt安装

sudo apt install nvtop

如果是在旧的系统,如ubuntu16.04等,则需要通过源码安装,方法如下

# 安装依赖sudo apt install cmake libncurses5-dev libncursesw5-dev git # 下载源码git clone https://github.com/Syllo/nvtop.gitmkdir -p nvtop/build && cd nvtop/buildcmake .. # 如果报错"Could NOT find NVML (missing: NVML_INCLUDE_DIRS)"# 则执行下边的语句,否则跳过cmake .. -DNVML_RETRIEVE_HEADER_ONLINE=True # 编译makesudo make install 

2 使用方法

安装完之后,可以执行nvtop -h来查看使用方法,介绍的很详细了,如果现实全部信息,直接nvtop就可以现实出我们上边的结果

nvtop version 1.0.0Available options:  -d --delay        : Select the refresh rate (1 == 0.1s)  -v --version      : Print the version and exit  -s --gpu-select   : Column separated list of GPU IDs to monitor  -i --gpu-ignore   : Column separated list of GPU IDs to ignore  -p --no-plot      : Disable bar plot  -C --no-color     : No colors  -N --no-cache     : Always query the system for user names and command line information  -f --freedom-unit : Use fahrenheit  -E --encode-hide  : Set encode/decode auto hide time in seconds (default 30s, negative = always on screen)  -h --help         : Print help and exit

CUDA+PYTORCH安装教程:

环境安装

多模态|BLIP 、CoCa and BeiTv

BLIP

BLIP: Bootstrapping Language-Image Pre-training for Unified Vision-Language Understanding and Generation

代码: https://github.com/salesforce/BLIP

本文是 ALBEF 原班人马做的,基本可以看做吸收了 VLMo 思想的 ALBEF。训练的 loss 和技巧都与 ALBEF 一致,属于 ALBEF 的后续工作。

本文motivation主要有两个:一是之前多模态预训练模型结构要么是基于编码器,不能直接用于生成任务,要么是基于编码解码器,在检索类任务上不方便,本文设计的结构包含单模态编码器、视觉指导文本编码器、视觉指导文本解码器,可以方便地用对比学习、ITM(Image-Text Matching ( ITM ): 图文匹配任务,针对的是图文交互流,即判断当前pair是不是匹配(就是个分类任务))、LM(生成式任务)三个预训练任务训练不同的模块,也容易迁移到各种下游任务中;二是之前的很多工作通过扩充了网上搜集的图文对的预训练数据(GCC、SBU、CC12M),提高了模型效果,但忽略了其中有很多不对齐的噪声情况,本文用一个boostrapping的方法,用captioner为网络图片生成描述,用filter过滤掉不配对的数据,从而降低噪声,更高效地利用网络上的数据。

关键的改进:

1. 模型结构上整合了 ALBEF 和和 VLMo。VLMo 参数共享,但是不存在单独编码器;ALBEF 存在单独编码器但是部分参数不共享。这篇论文存在单独的 vision encoder 和 text encoder。多模态的参数是以 cross-attention 模块插入到文本编码器实现的,cross-attention 模块享受文本编码器的参数(可以看 col 2 和 col3)

2. 增加了解码器(参考 col 4),为了做生成任务。解码器拿到视觉特征和未掩码的语言特征,过一个 casual self-attention 层,做 GPT 用的那种 lm 任务。这里区别于 MLM 的那种 mask 机制,是通过 causal self-attention 来实现因果推理的,我此时还不熟悉这个过程。

3. 除了上面的主要部分,还有一个重要的部分是利用训练好的模型生成伪标签。将训练好的模型里的不同的部分拿出来在 COCO 上稍微微调一下,decoder 部分可以生成文本,算 ITM loss 的那个模块可以做 image-text pair 的过滤,通过输出打分、置信度的方式。在实验中,BLIP 的解码能力似乎很强,用这种范式生成的文本不仅人看着觉得不错,用于自训练后也可以涨点 2-3,非常显着。

   一个例子是 stable diffusion 的官方博文里提到了,他们在做微调时,会遇到数据集只有图片没有 caption 的情况,比如 pokeman 数据。他们用 BLIP 来做caption生成,然后微调 stable diffusion 发现效果很好。

   另一个例子是知名的开源多模态数据集 LAION,他们也用了 BLIP 来辅助制作数据集。他们的过程在官网公布了,可以参考。

总结:个人感觉模型部分的改进可能有用可能没有用,但是解码器输出的 caption 确实是不错。以至于很多下游任务都拿 BLIP 来生成 caption。

CoCa

Contrastive Captioners are Image-Text Foundation Models

代码: https://github.com/lucidrains/CoCa-pytorch

它也是 ALBEF 的后续工作,模型非常像。区别在于:

1. 图像用了 attentional pooling,这在本文的实验中有效

2. 去掉了 ITM loss,目的是加快训练,原本文本需要 forward 2-3 次,去掉 ITM loss 之后只需要 forward 一次就可以了。在 ALBEF 中,ITM 需要完整的 text,而 MLM 需要掩码,所以是两次输入。在 BLIP 中,ITC 一次,ITM 因为在文本模型中插入了新的模块,所以得单独做前向。而 LM 因为用了既多了新的模块又得用 causal self-attention 所以又得单独做一次。在 CoCa 中,为了完成 captioning loss 和 ITC loss,只需要做一次前向即可。GPT 中把 cls-token 放在最后面就可以得到全局表征来做 ITC loss 了。

简单快速的方法可以有效地 scale,而我们知道复杂的模型设计、loss 设计经常不如简单地放大模型、增加数据有效。参考凯明的 FLYP。

这种画图的方式很不错,很直观。可以参考,以后也画成这样。

总结:

简单有效的结构设计,我对 CoCa 的印象是简单有效。它的峰值性能我没有感觉很炸裂,可能是模型、数据 scale 之后自然的结果。但是它的 zero-shot 性能让我印象很深刻,在 imagenet 上微调不微调的差距很小,这一点非常非常关键。

读到 coca,我对多模态的疑问还有两点:

1. mixture of experts 的结构没有在本文中得到应用,但我感觉是个相当有前途的结构

2. 双向的生成 loss 还是没人做,谁说只能图像辅助文本?

BeiTv

(BEiT-3) Image as a Foreign Language: BEiT Pretraining for All Vision and Vision-Language Tasks

论文的卖点是大一统。在 introduction 章节详细介绍了大一统指的是统一模型、loss 和数据。我觉得可以简单地概括为:用统一的 multi-way transformer (mixture of experts ) 架构和单个 masked modeling loss,将任意模态看做是同一个模态来建模。

具体而言,它指的是在将任意模态输入网络后,都表现为 list of tokens,直接将它们看做是相同的模态来做 masked modeling 就好了。如果想要拿过去做下游任务的话,直接将需要的那部分模型拿出来即可。比如做视觉任务就拿视觉模型,做语言任务就拿语言模型。如果是做多模态任务,可以灵活地模拟不同的需求,比如:1. 做生成任务可以拿多模态部分的参数出来 2. 做图文检索可以单独取出视觉部分和语言部分来模拟 CLIP。不仅仅是能做任意任务,还继承了前作的优点,比如 CLIP 这种弱跨模态交互带来的计算效率的优势。

总结:

Neural Corpus Indexer—文档检索

paper:https://arxiv.org/abs/2206.02743

神经语料库索引for文档检索

最近一篇Neural Corpus Indexer基于transformer的文档检索引发了争论。【知乎】所指论文为NeurIPS2022 Outstanding Paper A Neural Corpus Indexer for Document Retrieval。 根据OpenReview上的Revisions记录,Rebuttal阶段的最后修改应该是https://openreview.net/references/pdf?id=y45TgWUfyF,此时Table 1内容为:

但Camera Ready版本是https://openreview.net/references/pdf?id=-bt0HSi9__,此时Table 1的内容为:

特别值得注意的是,在Rebuttal阶段,作者的General Response指出他们的工作即使去掉query generation进行公平比较,也远胜于基线:

但是根据Camera Ready版本的Table 1(见上)和Table 3

NCI(Base) w/ QG是65.86 NCI(Large) w/ QG是66.23 NCI(Base) w/o QG是46.41。如果NCI(Large) w/o QG像w/ QG的设置一样只比Base高0.37,那么它将低于Table 1中的SEAL(Large),而根据General Response,作者认可SEAL是w/o QG的设置。

反思:其实在机器学习里面,如果你的实验有了好的结果,尤其是特别好的结果,那么90%的情况都是有bug造成的。所以在效果比较好的情况时候一定要去仔细检查,看看是否有数据泄漏的情况。这个错误是比较常见的。

文本检索:在一堆的文本里面,将那些跟Query相关的文档找出来。是信息检索里最大的分支。相关信息检索的会议有:SigIR、WSDN、KDD、 NeurIPS (这个 NeurIPS 上文本检索的文章比较少,是一个偏算法的会议)

摘要:

当前最主流的的文档检索解决方案主要是基于索引检索方法,索引就是指对文档做一下哈希值或者embedding,但是索引很难直接针对最终检索目标结果进行优化。 因为哈希是一个固定的算法,或者词嵌入也不一定是根据用户最终的目标来做训练的。在这篇论文中,我们的目标是展示一个端到端的深度神经网络网络统一训练和检索阶段,可以显着提高召回率。在检索方面,召回率相比于准确率更加重要,因为需要把相关的文档全部都找出来,不希望遗漏。在这个文章中,作者提出了一个基于equence-to-sequence network(NCI),针对特定的query来说直接生成相关文档的id。为了提升NCI性能,提出了一个解码器(refix-aware weight-adaptive decoder),还使用了一些其他技术:query的生成、带语义的文档的ID和一致性的正则表达项。

摘要的写法比较常见:该领域之前的方法是怎样的,我们使用一个神经网络做一个端到端的学习,从原始的数据直接生成你要的一个结果。

导言:

文档检索和排序是标准网络搜索引擎的两个关键阶段。 第一,文档检索阶段就是给定一个query,来查询相关的候选文档,然后进行排名阶段为每个文档提供更精确的排名分数。 排名阶段通常由深度神经网络,将每对查询和文档作为输入并预测它们的相关性分数。 然而,一个精确的排名模型是非常昂贵的(对每一个查询对都要去预测分数),所以通常只有一百或一千个检索的候选结果。 因此,召回性能文档检索阶段对网络搜索引擎的有效性至关重要。(检索的这几百个候选结果应该要把所有相关的都包含进来才好)。

其实除了检索的召回率很重要,对于一个检索系统来说,性能是十分重要的,作者在这没有提到,对于一个搜索引擎来说,文档数量在千百亿以上,这个也是这篇文章的一个硬伤,就是太贵了。

现有的文档检索方法可以分为两类,即term-based和基于语义的方法。基于 term 术语的检索方法一般会构建一个倒排索引对整个网络语料库(可以认为就是一个字典,字典里的每个key就是查询,key的值就是对应这个文档id(key出现在该文档中))这个方法非常高效,但它们几乎无法捕获文档语义并且无法检索到类似的不同措辞的文件(比如我输入“文件”,找到的结果只是含有该“文件“的文档,对于文件的相似表达”file“,无法检索到)。 因此,提出了基于语义的方法 来减轻这种差异。基于语义的方法就是把query和文档分别映射成向量(使用twin-tower architecture架构)。然后使用近似K紧邻搜索感兴趣的的K个文档。这种方法的缺点:对于精确匹配exact match,(苹果13和苹果12)表现不好。另外就是ANN近邻算法某些情况(query和文档之间的关系复杂)下也不太好。

端到端的相关工作:一个是DSI,Differentiable Search Index,文本到文本的生成,一个纯transformer,DSI 中的解码器没有充分利用文档标识符的层次结构。第二个SEAL 通过利用段落中的所有 n-gram 作为其标识符id。

twin-tower architecture

Neural Corpus Indexer

神经语料库索引器 (NCI) 是一种序列到序列的神经网络模型。 该模型将查询作为输入并输出最相关的文档标识符 (docid),它可以通过大量<query, docid>对进行训练。

下图就是这个模型的示意图。每次用户输入的是查询query,模型输出的是docID。那文本检索中的文档在哪?文档不可能作为输入送进模型,因为文档数量太大了,开销比较大。这个模型预测的时候不会看到文档的信息,但是做检索肯定需要模型知道各个文档的信息,所以就需要把这些文档全部放入这个模型。所以这部分数据分为两部分,一部分就是<query,docID>查询对。另一部分就是大量的被检索的文档<doc,docID>,因为模型预测的是query到docid的映射,所以需要让模型记住文档和docid的关系,常见做法就是用<doc,docid>无标号的数据去让模型记住全部的文档,当然这里可以把一个<doc,docID>对拆分成多个<query,docid>对,就是把doc里的句子给拆分成query会比较好做一些。模型的设计里有一些比较重要的点:(1)如何设计一个docID,而并非简单的数字,最好docID能够表示doc之间的语义信息。(2)如何将文档分出比较好的query,使得文档自己的语义和它的ID之间做好映射。同时分出的query能够跟预测时候的用户查询query有一定的相似性。(3)模型如何设计?编解码器和loss

NCI示意图

上图就是对应的三个关键点。

  • 如何生成语义的ID:层次Kmeans算法

首先,上图中所有的灰点都代表不同的文档,首先对所有的文档做一个K-means聚类(k=3),不同的类给与不同的id(1,2,3),作为文档id的前缀,如果某个类里面的文档数量多于某个阈值C,他就会对这个类进一步做K-means,继续分出K个子类和对应的id。因此如果两个文档的前缀相近,表示俩个文档的距离比较近。这种层次化标号的好处是如果面对10000中类别标号,直接用一个softmax来对其分类是不好的,有了层次化的标号,就可以分层次预测类别。

  • 从文本生成query

1、DocT5Query:sequence to sequence的模型,将Doc 翻译成 Query的模型。如何使用:将用于检索的文档输入到该模型,来获得多个query的输出(随机采样方法)。

2、Document as Query,像DSI一样,先把每个文档最先的64个term词作为一个query。然后随机在文档的随机位置选择10组,每组64个词作为query。(共11个query)

Prefix-aware weight-adaptive decoder:

r0,r1,r2就是不同层次的类别的id。相比传统的解码器,作者更加考虑到了r0,r1,r2之间的相对位置关系,因此解码器的输入不再是r0,r1,而是包含位置的(1,r0),(2,r1)。实验表明包含位置的解码器输入对于模型提升很大!!!!

另外作者认为在解码器的最后的softmax的全值W对于不同的ri是一样的,这样是不好的,因此希望不同的r对应不同权重。

因此新的Wi如下所示:不仅包含Wi,也包含前面的r0到ri-1的这些信息。

损失函数:

1、增加一个对比学习损失函数,希望同一个query生成的id之间相似度更加接近一些。

2、标准的 cross entropy损失函数

实验

数据集(问答数据集文档来自wiki):

评价指标:

1、Recall@N:表示在获得的N个结果中有没有自己想要的文档

2、MRR: 表示返回结果的排序情况,我们想要的文档在所有结果中的排序情况

结果:

消融实验

性能:在32G的v100上面,时延在100ms还是可以的,但是吞吐量只有50多个query对于搜索引擎来说是不能忍受的。工业部署上还是有一定的距离。

缺点:1、大数据集:目前只是在32万的文档上训练结果,但要是真的用于web搜索,数以亿计的文档需要的模型会很大。2、推理的时延和吞吐量 3、面对新的文档,如何去更新模型?

MINE–利用单张图片做三维重建

端到端类型

用MPI(Multi-Plane Image )代替NeRF的RGBσ作为网络的输出

来自字节跳动视觉技术团队的研究者将 NeRF 和 Multiplane Image(MPI)结合,提出了一种新的三维空间表达方式 MINE。该方法通过对单张图片做三维重建,实现新视角合成和深度估算。

开源了训练代码(基于LLFF数据集的toy example),paper里面数据集的pretrained models,并提供了demo代码:

相关工作

近年来,在新视角合成这个领域里,最火爆的方法无疑是 ECCV 2020 的 NeRF [5]。与传统的一些手工设计的显式三维表达(Light Fields,LDI,MPI 等)不同,NeRF 把整个三维空间的几何信息与 texture 信息全部用一个 MLP 的权重来表达,输入任意一个空间坐标以及观察角度,MLP 会预测一个 RGB 值和 volume density。目标图片的渲染通过 ray tracing 和 volume rendering 的方式来完成。尽管 NeRF 的效果非常惊艳,但它的缺点也非常明显:

  1. 一个模型只能表达一个场景,且优化一个场景耗时久;
  2. per-pixel 渲染较为低效;
  3. 泛化能力较差,一个场景需要较多的照片才能训练好。

另外一个与该研究较相关的是 MPI(Multiplane Image)[1, 2, 3]。MPI 包含了多个平面的 RGB-alpha 图片,其中每个平面表达场景在某个深度中的内容,它的主要缺点在于深度是固定及离散的,这个缺点限制了它对三维空间的表达能力。[1, 2, 3] 都能方便地泛化到不同的场景,然而 MPI 各个平面的深度是固定且离散的,这个缺点严重限制了它的效果。

结合了NeRF和Multiplane Image(MPI),提出了一种新的三维空间表达方式MINE。MINE利用了NeRF的思路,将MPI扩展成了连续深度的形式。输入单张RGB图片,我们的方法会对source相机的视锥(frustum)做稠密的三维重建,同时对被遮挡的部分做inpainting,预测出相机视锥的三维表达。利用这个三维表达,给出target相机相对于source相机的在三维空间中的相对位置和角度变化(rotation and translation),我们可以方便且高效地渲染出在目标相机视图下的RGB图片以及深度图。

MINE在KITTI,RealEstate10K以及Flowers Light Fields数据集上,生成质量大幅超过了当前单视图合成的state-of-the-art。同时,在深度估计benchmark iBims-1和NYU-v2上,虽然我们在训练中只使用了RGB图片和sparse深度监督,MINE在单目深度估计任务上取得了非常接近全监督state-of-the-art的performance,并大幅超越了其他弱监督的方法。

Introduction and Related Works

视图合成(novel view synthesis)需要解决的问题是:在一个场景(scene)下,输入一个或多个图片,它们各自的相机内参和外参(source camera pose),之后对于任意的相机位置和角度(target camera pose),我们想要生成场景在该相机视图下的RGB图片。要解决这个问题,我们的模型需要学会场景的几何结构,同时对被遮挡的部分做inpainting。学术界设计了很多利用learning的方法预测场景的3D/2.5D表达,其中跟我们较相关的是MPI(Multiplane Image)[1, 2, 3]。MPI包含了多个平面的 RGB-α图片,其中每个平面表达场景在某个深度中的内容,它的主要缺点在于深度是固定及离散的,这个缺点限制了它对三维空间的表达能力。

近年来,这个领域的当红炸子鸡无疑是ECCV 2020的NeRF [5]。与传统的一些手工设计的显式三维表达(Light Fields,LDI,MPI等)不同,NeRF把整个三维空间的几何信息与texture信息全部用一个MLP的权重来表达,输入任意一个空间坐标以及观察角度,MLP会预测一个RGB值和volume density。目标图片的渲染通过ray tracing和volume rendering的方式来完成。尽管NeRF的效果非常惊艳,但它的缺点也非常明显:1. 一个模型只能表达一个场景,且优化一个场景耗时久;2. per-pixel渲染较为低效;3. 泛化能力较差,一个场景需要较多的照片才能训练好。

方法综述

该团队采用一个 encoder-decoder 的结构来生成三维表达:

  1. Encoder 是一个全卷积网络,输入为单个 RGB 图片,输出为 feature maps;
  2. Decoder 也是一个全卷积网络,输入为 encoder 输出的 feature map,以及任意深度值(repeat + concat),输出该深度下的 RGB-sigma 图片;
  3. 最终的三维表达由多个平面组成,也就是说在一次完整的 forward 中,encoder 需要 inference 一次,而 decoder 需要 inference N 次获得个 N 平面。

获得三维表达后,不再需要任何的网络 inference,渲染任意 target 相机 pose 下的视角只需要两步:

  1. 利用 homography wrapping 建立像素点间的 correspondence。可以想象,从 target 相机射出一条光线,这条光线与 target 图片的一个像素点相交,然后,研究者延长这条射线,让它与 source 相机视锥的各个平面相交。相交点的 RGB-sigma 值可以通过 bilinear sampling 获得;
  2. 利用 volume rendering 将光线上的点渲染到目标图片像素点上,获得该像素点的 RGB 值与深度。

三维表达与渲染

1. Planar Neural Radiance Field

2. Rendering Process

完成这两步之后,我们就可以通过上面volume rendering的公式渲染任意target camera下的视图了。需要注意的是,在获得3D表达后,渲染任意target camera pose下的视图都只需要这两个步骤,无需再做额外的网络inference

Scale 校正

MINE 可以利用 structure-from-motion 计算的相机参数与点云进行场景的学习,在这种情况下,深度是 ambiguous 的。由于在这个方法中,深度采样的范围是固定的。所以需要计算一个 scale factor,使网络预测的 scale 与 structure-from-motion 的 scale 进行对齐。团队利用通过 Structure from Motion 获得的每个图片的可见 3D 点 P 以及网络预测的深度图 Z 计算 scale factor:

获得 scale factor 后,对相机的位移进行 scale:

需要注意的是,由于需要和 ground truth 比较,所以在训练和测试时需要做 scale calibration。而在部署时不需要做这一步。

端到端的训练

MINE 可以仅通过 RGB 图片学习到场景的三维几何信息,训练 Loss 主要由两部分组成:

1.Reconsturction loss——计算渲染出的 target 图片与 ground truth 的差异:

2.Edge-aware smoothness loss——确保在图片颜色没有突变的地方,深度也不会突变,这里主要参考了 monodepth2 [6] 种的实现:

3.Sparse disparity loss——在训练集各场景的 scale 不一样时,利用 structure-from-motion 获得的稀疏点云辅助场景几何信息的学习:

MINE 与 MPI、NeRF 的比较

MINE 是 MPI 的一种连续深度的扩展,相比于 MPI 和 NeRF,MINE 有几个明显的优势:

  1. 与 NeRF 相比,MINE 能够泛化到训练集没有出现过的场景;
  2. 与 NeRF 的逐点渲染相比,MINE 的渲染非常高效;
  3. 与 MPI 相比,MINE 的深度是连续的,能稠密地表示相机的视锥;
  4. MPI 通过 alpha 合成(alpha compositing)进行渲染,但该方法与射线上点之间的距离无关,而 MINE 利用 volume rendering 解决了这个限制。

然而,MINE 也有一些自身的局限性:

  1. 由于输入是单张图片,MINE 无法表达相机视锥以外的三维空间;
  2. 由于 MINE 的输入里没有观察角度,所以其无法对一些复杂的 view-dependent 效果(如光盘上的彩虹等)进行建模。

[1]. Tinghui Zhou, Richard Tucker, John Flynn, Graham Fyffe, Noah Snavely. Stereo Magnification: Learning View Synthesis using Multiplane Images. (SIGGRAPH 2018)

[2]. Ben Mildenhall, Pratul P. Srinivasan, Rodrigo Ortiz-Cayon, Nima Khademi Kalantari, Ravi Ramamoorthi, Ren Ng, Abhishek Kar. Local Light Field Fusion: Practical View Synthesis with Prescriptive Sampling Guidelines. (SIGGRAPH 2019)

[3]. Richard Tucker, Noah Snavely. Single-View View Synthesis with Multiplane Images. (CVPR 2020)