<svg xmlns="http://www.w3.org/2000/svg" style="display: none;"> <path stroke-linecap="round" d="M5,0 0,2.5 5,5z" id="raphael-marker-block" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0);"></path> </svg> <p><img src="https://i-blog.csdnimg.cn/blog_migrate/2f445db929a80faeb7802f8bc17260d1.png" alt="请添加图片描述" /></p> 

在前文中，已经对图卷积神经网络（Graph Convolutional Neural Networks, GCN）的理论基础和实践操作进行了深入探讨。相信你按照顺序阅读看到这里已经对GCN有一个全面而详细的认识，这里是一个额外的章节，准确的说是我的个人的实验部分，其主要目的是分享自己在学习GCN中的面对相关问题的思考。 如果你仅仅是想对GCN有一个初步的认识，当然可以不看这部分的内容。

当然我也希望这个文章能像这个题目一样，真正的帮助到有需要在此寻找答案的人。

这是原文的代码地址，感兴趣的读者自行下载即可 https://github.com/tkipf/pygcn

讯享网

😃要是觉得还不错的话，烦请点赞，收藏➕关注👍

GCN详解博文由于是我今年年初的创作。所以并没有对其论文进行精讲，但是相信有些查到这个文章的作者一定会有和我一样的疑问，就是为什么作者提供pytorch的GCN代码中在Cora数据集测试的准确率这么高，随随便便跑一次就能到83+。但是论文给出的结果是80左右。在后续的过程中我翻阅了其他人的论文多数都采用了80的结果，难道是我的实验环境有问题？？

我对TF版本的代码进行复现。得到了和论文中一致的实验结果，但是我发现明明是一样的数据集，为什么TF中却使用格式是这样的？

而pytorch版本的数据集却是这样的？？？

数据集的问题是不是影响准确率的关键呢？？这个问题在我的小脑袋瓜子里油然而生？？？

但是这个时候还是没有办法验证，于是我在主流的DGL中试图复现GCN在Cora数据集下的结果，同样得到了和原始论文中接近的结果。并且其DGL中使用的数据集是和TFGCN一样的数据集。

我心想难道我发现了提升了GCN性能的关键了嘛？顶刊在想我招手，于是我对此进行了详细的分析。没发现什么问题，因此我推断可能是数据集的问题，导致的结果出现了偏差，但是这似乎并没有办法验证我的想法。因为我不知道这个Cora数据集是如何被预处理了x，y，tx，ty，allx，ally这样的形式。于是乎我开始了自己找寻Cora数据集是如何被预处理了x，y，tx，ty，allx，ally这样的形式的道路。

我试图通过PYGCN的作者那里找到答案。作者在的原文

Note: There are subtle differences between the TensorFlow
implementation in https://github.com/tkipf/gcn and this PyTorch
re-implementation. This re-implementation serves as a proof of concept
and is not intended for reproduction of the results reported in [1].

This implementation makes use of the Cora dataset from [2].

翻译结果：

注：在 https://github.com/tkipf/gcn 提供的 TensorFlow 实现与此 PyTorch 重实现之间存在一些细微的差异。这个重实现主要是作为一个概念验证，并不旨在复现文献 [1] 中报告的结果。

本实现使用了来自 [2] 的 Cora 数据集。

作者说仅仅是为了展示这个torch的实现，所以不考虑太多细节问题，仅仅是为了展示其卷积行为。所以torch版本并不能对原文中的实验结果进行复现，这就表明作者实际上是知道结果不太准的，但是并没有提到Cora原始数据集是怎么变成x，y，tx，ty，allx，ally这种形式。所以俺去TF版本的github进行了刨根问题。

我翻看了tf版本的GCN实现代码，也没找到这个这个Cora是如何处理成x，y，tx，ty，allx，ally这种形式。仅仅找到了这个数据集是怎么来的：

翻译成中文

作者指出这个Cora的数据分割版数据集并不是他处理得到的而是作者从网络上找到。而其pytorch版本的数据集使用的是原始数据集。据我分析，由于其论文中指出其使用的数据本身使用的就非原始版本，所以人家这个torch版本纯就是开源压榨自己实践给大家看看的。在此我断定那就是数据集的问题了，原作者也懒得观察人家这个数据集到底是怎么划分的所以仅仅使用顺序节点作为测试和训练所以这个数据的分布有问题，导致某一个简单的类别分的比较多才造成了结果的上升。但是我现阶段还是不想手动的去修改分布，一方面是有难度另一方面是还是不能作为基准这是我个人的猜想而已。也不利于后续做实验。所以所以我顺着这个链接找到了提供这个数据集的原始论文。

我希望论文的原始作者能够提供这个Cora到x，y，tx，ty，allx，ally的数据预处理代码，这样的话。我就对数据进行预处理然后接上torch版本的GCN看看能不能复现论文中的结果。从此俺就能无缝的做实验了，还有一个基准，而不必依赖于这个被划分好的数据集，可以在原始数据集上大展身手。

事实却是，这个大佬确实是大佬，我点开github人家这难以企及的高度，咱也没法问人家啊，并且在这个项目的Issues里面一大群人问大佬这个问题，没得到回复，我看简历人家忙着创业呢，另外这大老是metaAI的前员工，我寻思得了这线索又断了。不过我发现大多数人都和我有一样的需求，但是我是真闹心啊，怎么也找不到答案了。没办法了自己复现吧。

找了一路的线索断了，碎碎念了半天，走到头发现还需要靠自己，并且俺找这个代码找了三天。浪费了大量的时间，太难受了自己来吧。一顿心里挣扎，开工。

首先说下我的思路，我的目的是将Cora数据转换成x，y，tx，ty，allx，ally这样的形式。将处理文件给tfGCN作为原始数据集进行预测训练得到训练的结果。看看是不是和论文原始提供的一致，如果一致的话说明我处理的是有效的并且符合原作者的处理思路。

第二点就是我使用将Cora数据转换成x，y，tx，ty，allx，ally这样的形式。仅仅是一种数据集的划分方式直接接上pyGCN的代码，看看这个准确率是不是下降到了论文中的水平这样就能证明论文的GCN是有效的。其原始方案性能比论文中好，仅仅是处理数据集的分布方式有问题，并不是模型的问题。因此想好了问题的开工开工。

首先，就是分析x，y，tx，ty，allx，ally这数据集，看看其具体的什么构成的文件的形态是什么样子才能构建啊。

讯享网

看一下输出结果吧，好分析下然后在模仿人家啊：

讯享网

看了下其实就是选择了140个节点作为测试，x这个集合是1708节点allx集合的子集。tx就是测试集合。tx的形状是1000所以就是1000个节点。1708+1000=2708 正好是全部的节点。

在此解释下：

数据集内容说明
Cora数据集包含以下文件，用于图神经网络研究中的节点分类任务：

• : 训练集节点特征向量，保存为 。实际展开后的大小为： 。
• : 测试集节点特征向量，保存为 。实际展开后的大小为：。
• : 包含有标签和无标签的训练节点特征向量，保存为 。实际展开后的大小为：。可以理解为除测试集以外的其他节点特征集合，训练集是它的子集。allx和tx共同构成了全部的数据集节点特征
• : 训练节点的标签，采用one-hot表示，保存为 。
• : 测试节点的标签，采用one-hot表示，保存为 。
• : 对应的标签，采用one-hot表示，保存为 。
• : 保存节点之间边的信息，格式为 。
• : 保存测试集节点的索引，为 类型，用于后面的归纳学习设置。

我想着先看看TF代码中测试验证训练数据的类别分布情况吧，我推测是不是torch 版本选择数据集仅仅是按顺序选择的没有考虑分布的问题呢，这才导致了训练的问题？？？？

运行结果如下：

讯享网

看上文数量上其实看不出这个类别的分布情况，但是看训练集合y中类别情况是一致的。这就验证了我的猜想，很有可能是是数据分布出了问题，torch版本的代码中仅选择了前140和顺序选择的1000个节点用来做测试，并没有考虑分布问题，原始杂乱的Cora难道就会提前考虑分布问题吗？？显然不会考虑那就是分布出了问题代来的torch版本的性能提升。

不过我还是对tf版本的Cora数据进行了分布的计算：

结果可想而知，可以看到数据集合中测试集合全部集合的类别分布是相同的并且两个数据集的类别分布差值很小。测试集的分布相对接近整体数据集的分布，偏差在可接受范围内。所以其1000个数据节点的设定是按照原始数据集的分布均匀设定的。这表明测试集的 1000 个数据节点是根据原始数据集的类别比例来均匀设定的，确保了测试集能够代表性地反映整个数据集的特点。

可以说明其pytorch版本差异就是来源于数据集

讯享网

那就按分析出来的分布情况去设计测试集合就可以了，训练集合就采用每个类别20个节点进行测试呗：

然后看下模型的展示出来的数据个数和分布情况：

讯享网

新构建的这个和tf使用的还是看起来很一致的。

看下数据的分布情况：

讯享网

上面代码整体是将测试集合特征节点最后一千个节点进行作为测试，并且其类别分布和整体一致。作为最终的测试数据。
其整体顺序是被打乱的主要是不想让相同类的数据索引数紧挨着，使用140个数据节点作为训练，每个类别20个并最终做进行了打乱。最终得到的数据形态
0-139是训练后面的到1707是没用上作为无标签只使用特征， 后面的1000作为最终的测试集合。

将修改后的数据处理代码对pyGCN中使用的load_data进行修改。将训练集合的类别分布做的和tf代码中的一致。测试集合的也一致的和总体一致。

我在此分享我修改的load_data的代码部分：

使用我代码中的文件去替换掉你GCN中的文件内容，如果你在训练中使用的是得到的数据将会得到论文中的结果。最终可得计算准确率百分之80和论文中一致。如果不修改这个loadedate则会出现较高的acc准确率，经分析其主要原因就是类别分布是随机可能将大量的简单的分类节点作为测试集合所以准确率上升。主要是其类别分布有问题导致的准确率上升，这并不是真实的代码性能提升。

上面啰啰嗦嗦说了大变天，怎么修改代码得到和论文中一样的结果，但是这个x，y，tx，ty，allx，ally文件怎么得到？？？？？？？

讯享网

各位在jupyter中复制我的代码顺序执行即可得到x，y，tx，ty，allx，ally的文件，这样就实现了从Cora到x，y，tx，ty，allx，ally的文件的完美转换。具体的在tf中的结果就请各位自己去试试吧，童叟无欺放心使用。

对了还有一个后缀是graph的文件生成结果如下就是边信息的编码文件而已：

我已经做了详细的注释各位自行修改哦，接着各位再用我上面分析数据的代码去分析新生成的数据，就可以看到其和TF中提供的数据是高度一致的。

细心的同学可以看到我们可以还有最后一个没生成结束那就是testindex文件，这个文件就是存储用来测试节点的索引号。其索引的顺序是被打乱的。这是为什么呢，

这个问题的思索我搜索了互联网的各种各样的角落都没好到我想要的答案，因此我将答案写在这里，希望能帮到路过的你，我对一些细节并没有像其他博文一样进行初学者是讲解，我相信这么刨根问底的你也不会是一个初学者。一定能够轻松的搞定的，感谢你的观看。如果您觉得还不错的话，可以奖励打赏小弟一杯咖啡钱，创作不易。如果你对此感兴趣，不妨点赞、收藏并关注，这是对我工作的最大支持和鼓励。非常感谢！如果有任何问题，欢迎随时私信我。期待与你的互动！