前阵子整理自己的阅读笔记，发现过去大半年反复翻的那十来篇工作，居然刚好落在图神经网络、大模型优化、表格分析这三条线上。一开始我以为是巧合，毕竟这三块平时在社区里各聊各的，连会议都不太重叠。直到把笔记摊开按“它到底解决了什么约束”重新排了一遍，才意识到它们被放进同一份清单是有道理的：表格数据本身就是一种图，大模型优化的那些手段在图上早就被踩过一遍，而表格分析里最难的从来不是建模，是把结构喂对。
我这份清单不给具体标题和链接，只讲每篇在解决什么问题、核心思路是什么、我从里面拿走了什么能直接用的东西。原因很简单，论文的价值不在名字，在于你能不能把它拆成零件装进自己的项目里。这篇就按三条线拆，每篇讲清楚“为什么值得读”和“读完之后我能改哪一行代码”。读者对象是已经跑过几个项目、手上有一堆效果上不去的中等规模任务、想从论文里找思路而不是找 SOTA 数字的人。
1. 这三条线被放进同一份清单的底层原因
1.1 表格的结构本质就是一张异构图
很多人做表格理解第一反应是把它拍平成文本序列，然后丢给一个编码器。这条路能跑通，但天花板很明显：一旦表头是多级的、单元格有合并、跨行跨列存在从属关系，序列化之后这些信息就丢了。而从图的角度看，单元格是节点，同行同列是边，表头到数据区的从属关系是另一类边，多级表头天然构成一棵树。
我在一个报表抽取的项目里做过对照实验，同一个模型结构，把表格按行列关系建成图之后，涉及合并单元格的字段准确率有明显提升。这不是模型变强了，是输入的信息变全了。理解了这一点，图神经网络这条线上的方法就不再是“另一个领域的工具”，而是处理表格的备选主干。清单里第 3 篇讲异构关系建模的工作，我后来直接搬到了表格场景，改的只是边的定义。
1.2 GNN 和大模型优化在解同一类约束
把两边的技术放到一起看，会发现它们处理的矛盾几乎一模一样。图这边的问题是邻居爆炸：跳数一多，感受野指数级膨胀，全量计算根本跑不动。大模型那边的问题是注意力计算的平方级开销：序列一长，显存和时间都撑不住。
解法也惊人地相似。图这边用邻居采样，每层只取固定数量的邻居，用估计换可行；大模型那边用稀疏注意力、KV 缓存淘汰、分块计算，本质也是“只算一部分，剩下的用近似补”。清单里第 2 篇讨论采样偏差，第 5 篇讨论稀疏化带来的精度损失分布，这两篇前后脚读，会发现它们在讨论同一个统计学问题：你砍掉的那部分信息，会不会恰好是最关键的。
1.3 三类可以直接搬走的零件
读完这十篇，我给自己总结了三类能复用的东西。第一类是稀疏化策略，包括怎么采样、怎么淘汰、怎么控制方差。第二类是结构化先验的注入方式，包括位置编码变体、边特征、类型特定的变换。第三类是评测陷阱的识别，这块最容易被忽略，表格任务上尤其严重，因为很多基准的标注质量参差不齐。
下面按三条线逐个说。每篇我会交代三件事：它盯的是哪个具体瓶颈、核心机制是什么、我在自己项目里怎么验的。有些验证成功了，有些没成功，失败的部分我也写出来，因为那往往比成功更有信息量。
2. 图神经网络这条线：从堆层数到算得动
2.1 清单第 1 篇：深层图网络退化的真正来源
这篇是我今年读得最仔细的一篇。它讨论的问题很经典：图网络堆到十几层之后，节点表示会趋于一致，分类性能反而下降。常见的解释是过平滑，但这篇把它拆得更细，指出退化其实来自两个不同的机制，一个是表示趋同，另一个是梯度传播路径上的信息稀释，两者表现相似但修法不同。
作者的做法是逐层加一个可学习的衰减系数，配合残差连接和跳跃连接，让浅层信息能绕过中间层直接传到输出端。我喜欢这个设计的原因是它没有引入新的模块，只是在原有的消息传递公式上加了两个标量。代码改动量极小，我在一个节点分类任务上试过，把层数从 3 层提到 8 层，加上这套机制之后没有出现性能掉落，而原来的版本在 5 层就开始退化了。
一个实操判断：图上的层数不是一个可以盲调的普通超参，它和图的同质性高度相关。同质性高的图，邻居和中心节点标签一致的概率大，多传几层确实有收益；同质性低的图，传得越远噪声越多。
判断方法很简单，随机抽一批节点，统计它们的邻居中有多少比例和自己是同类标签。这个比例低于 0.5 的时候，我基本不会把层数设超过 3，再怎么加残差也救不回来。这个结论我在三个不同来源的数据上都验证过，方向一致。
2.2 清单第 2 篇：采样带来的偏差比显存更值得关心
邻居采样是让图网络跑上大规模图的关键手段，但这篇把注意力放在了很少有人细究的地方：采样是有偏的。每层随机采固定数量的邻居，实际上是在用一个子图估计全图的聚合结果，这个估计的方差和采样数成反比，但偏差不会因为采样数增加而消失。
作者做了两件事。一是给出了方差的一个近似表达式，能让你在训练前估算需要多大的采样宽度；二是对比了几种降低方差的做法，包括重要性采样和用历史表示做缓存。后者很有意思，它把上一轮训练算出来的节点向量存下来，采样没覆盖到的邻居直接拿缓存值顶替，代价是额外占一份存储。
我在一个中等规模的图上试过缓存方案，训练速度提升明显，但收敛后的指标比全采样低了不到一个点。这个折中能不能接受，取决于你的存储预算。经验值是缓存开销大致等于节点数乘以隐藏维度乘以精度字节数，一万个节点、128 维、单精度，大概是五兆左右，规模再大就要认真算账了。
2.3 清单第 3 篇：异构图上把关系类型当成一等公民
真实业务里的图几乎都是异构的：用户、商品、订单、地址，节点类型和边类型都不一样。这篇的核心主张是不要把不同类型的边混在一起做同一种聚合，而是给每种关系类型配独立的变换，聚合之后再融合。
代价是参数量的爆炸。关系类型有二十种，参数量就是二十倍。作者用了一个低秩分解来缓解，把每种关系的变换矩阵拆成共享基和类型特定系数，实际参数量接近线性增长而不是乘积增长。这个技巧我在一个多类型边的推荐场景里用过，参数量从原来的数倍降到了可接受范围，效果没有明显损失。
更值得记的是它对元路径的处理方式。手工设计元路径是件很费人的事，这篇用了可学习的路径权重，让模型自己在若干候选路径上分配注意力。省下来的不只是人力，还有一个隐性收益：不同业务场景下最优路径本来就不一样，让模型自己学比拍脑袋定更稳。
2.4 清单第 4 篇：图自监督预训练到底预训练了什么
这篇我读完的感受是“泼冷水”，但是有价值的冷水。图上的自监督预训练这两年很热，各种代理任务层出不穷，但这篇系统对比了不同代理任务在迁移到下游时的实际增益，结论是相当一部分增益来自训练过程的副作用，而不是任务本身学到了有用的结构知识。
具体来说，边重建任务学到的主要是节点度的分布，特征掩码任务学到的主要是局部邻域的平滑性，这两者在很多下游任务上带来的提升是可以被简单的正则化替代的。真正有独特价值的是对比类任务，但它的效果对负采样的质量极其敏感，负样本选得不好，学到的表示会塌缩。
我在一个小规模图上试过把预训练任务从边重建换成对比学习，下游 F1 有小幅提升，但训练成本翻了一倍多。结论是：数据量足够的时候，直接从零训练往往比折腾预训练更划算；数据量很小、标签极少的场景，预训练才有明显价值。这条经验帮我省了不少盲目尝试的时间。
3. 大模型优化这条线：省下来的其实是时间
3.1 清单第 5 篇：稀疏注意力砍掉的部分会不会伤到关键信息
长序列上的注意力优化方案非常多，这篇的价值在于它没有停留在“我的方案快了多少倍”，而是分析了稀疏化之后的精度损失在序列中的分布。作者发现损失并不是均匀分布的，它高度集中在需要跨距离精确匹配的任务上，比如需要把序列开头的一个实体和结尾的一个属性对应起来的场景。
这个观察直接指导了工程选型。如果你的任务是长文档摘要、日志聚合这类对精确远程依赖要求不高的场景，粗粒度稀疏化完全够用；如果是需要精确检索的任务，比如在长表格里定位某个单元格的具体数值，就得保留至少一条完整的注意力通路，或者干脆换成检索式的架构。
我在一个长文档抽取任务上踩过坑。当时为了压显存把注意力窗口设得比较小，短样本上指标几乎不掉，一上长样本就开始崩，而且崩得很隐蔽：模型不是抽不出来，而是抽错位置。后来把窗口放大到覆盖表头和首个数据块的距离，问题才消失。这个教训是：稀疏参数不要拍脑袋定，先测一下你的任务里关键依赖的平均跨度。
3.2 清单第 6 篇：参数高效微调的适用边界在哪
低秩适配这类方法现在几乎成了标配，但这篇认真讨论了它在什么情况下会失效。作者对比了不同秩、不同数据量下的表现，发现一个反直觉的现象：在小数据量下，秩设得偏小反而比设大更稳，原因是大秩带来的额外容量在小样本上容易过拟合，起到的是负作用。
另一个更有用的结论是关于任务类型的。如果下游任务和预训练分布差异不大，低秩适配可以逼近全量微调；如果差异很大，比如要从通用语料迁移到高度专业领域的结构化数据上，低秩适配的差距会拉得很开，这时候要么加秩、要么把适配层插到更靠前的位置、要么老老实实做全量微调。
我给自己的判断标准是这样的：先看手上有多少标注样本，几千条以上且领域差异大，直接考虑全量微调或者至少中秩适配；几百条以内，小秩适配加上严格的正则更稳妥。这套标准不是绝对的，但它给了我一个起点，不用每次从零试。
3.3 清单第 7 篇：推理阶段的调度才是吞吐的真正瓶颈
这篇讲的是推理服务里的批处理和缓存管理。核心观点是：训练阶段的优化关注的是单次前向的计算量，而推理阶段真正的瓶颈往往在调度上。请求是流式到达的，长度参差不齐，如果按批次对齐填充，大量算力会浪费在填充位上。
作者的方案是把缓存按块管理，不同请求的缓存块可以分散存放，新的请求随时可以插进来，不必等当前批次结束。这个思路现在已经被广泛采用，但论文里给出的那组消融实验仍然值得看，因为它量化了不同策略下的浪费比例。按最长序列对齐填充，浪费可以到百分之几十；改成连续批处理之后，浪费降到个位数。
我在一个内部服务上做过对照，同样的硬件，把静态批次换成连续批处理，吞吐提升接近一倍，首字延迟略微上升。这个折中要看业务形态：交互式场景对首字延迟敏感，后台批处理场景更看重吞吐。参数上我一般把最大批处理规模设在显存能容纳的八成左右，留出余量应对长度突增的请求。
3.4 这三条优化思路在图上同样成立
把第 5 篇和第 2 篇放在一起看，会发现稀疏注意力和邻居采样在数学上是同一类操作：都在用部分信息估计全量聚合的结果，都需要控制方差，都面临“砍掉的部分是否关键”这个问题。区别只在于图上的邻居是离散的、结构固定的，而序列上的位置是连续的。
这个类比有实际用处。图采样里用重要性采样降低方差的做法，可以搬到注意力稀疏化上，按注意力权重的估计值决定保留哪些位置；反过来，注意力里的分块计算思路，也可以用在超大图的子图划分上。我在一个跨模态检索的项目里试过把两者结合，先把候选集按结构分块，块内再做精细匹配，效果比单一方案好。
4. 表格分析这条线：最难的环节在建模之前
4.1 清单第 8 篇：序列化方式对结果的影响超出预期
这篇是我推荐给所有做表格任务的人第一篇读的。它做的事情很朴素：拿同一个模型，同一批表格，只改序列化方式，对比结果。序列化方式包括按行展开、按列展开、转成标记语言、转成结构化文本，以及各种混合顺序。
结果差异大得惊人，同一模型在同一个基准上，仅因为序列化顺序不同，指标能差出十几个点。作者的分析是，不同的序列化方式决定了模型能从上下文里学到什么样的局部模式。按行展开时，模型容易学到行内的一致性；按列展开时，模型更容易做跨行比较。如果你的任务涉及列级别的聚合统计，按列展开通常更有利。
我在一个财务报表抽取任务上按这个思路做了调整。原来的做法是整表按行拍平，遇到需要计算某列合计的问题就经常出错；改成分块处理，每个块先按列组织再拼接，合计类问题的准确率有明显改善。当然代价是序列变长了，需要配合截断策略，这块我后面会说。
4.2 清单第 9 篇：单元格定位需要显式的坐标信号
这篇解决的是一个很具体但很烦人的问题：模型能读懂表格内容，但说不清某个值在哪个单元格。做审核、做溯源、做多表关联的时候，这个能力是刚需，光给出一个答案不够，得指出来源。
作者的思路是给每个单元格加上显式的行列坐标标记，同时在序列里插入边界符，让模型在生成时可以直接引用坐标而不是复述内容。这个设计的巧妙之处在于它把定位问题从生成问题变成了引用问题，输出空间从整个词表缩小到了坐标组合，准确率提升很明显。
我在自己的抽取流程里做了简化版：给每个单元格分配一个短 ID，输入时前置一份 ID 到内容的映射，输出时只要求模型返回 ID 列表。这个改法工程上简单得多，不需要改模型结构，效果上够用。唯一需要注意的是 ID 的数量会撑长输入，表格特别大的时候要分段处理，段与段之间保留表头信息做对齐。
4.3 清单第 10 篇：数值推理靠模型硬算基本没戏
这篇的结论很直接：让语言模型直接做表格上的数值比较、求和、排序，错误率高得离谱，而且错误模式很有规律，多位数比较、跨行聚合、带单位的换算这三类错得最多。作者的方案是把数值计算拆出去，模型只负责把自然语言问题翻译成可执行的表达式，执行交给确定性的计算模块。
这个思路现在已经被验证得很充分了。我在一个对账场景里照做过，把求和、差值、占比这三类运算全部外置，模型只输出表达式，准确率从原来的七成多提到了九成五以上。剩下的错误基本都出在表达式翻译环节，也就是模型没理解清楚问题要算什么，而不是算错。
一个容易忽略的细节：外置计算之后，评测指标的意义变了。原来一个字面匹配准确率就能衡量，现在要分开看表达式抽取的正确率和执行结果的正确率，混在一起看会掩盖真正的问题所在。
4.4 表格任务上常见基线打不过的原因
这几年我见过好几次“复杂模型打不过简单基线”的情况，原因往往不在模型，在数据处理。最常见的是表头识别错误：多级表头没拆开，导致列名和数据的对应关系从一开始就错了，后面模型再强也救不回来。其次是空值和占位符处理不一致，同一列里混着空字符串、短横线、零、空值标记，模型学到的分布是乱的。
还有一个隐蔽的问题是表格截断。宽表或者长表超过上下文长度时，简单地从中间截断会破坏行列对齐，模型看到的是半张表。我的做法是先按语义单元切块，每个块保留完整表头，块之间用重叠窗口衔接，重叠部分至少覆盖一到两行，保证跨块的问题能对上。这套处理做扎实之后，很多所谓“模型能力不足”的问题会自己消失。
5. 我自己的读法：十篇怎么变成三个能跑的模块
5.1 复现顺序：先跑通哪一个
如果时间有限只能挑一篇动手，我会选第 8 篇，也就是序列化方式那篇。原因是它不需要改模型，不需要额外数据，只需要改数据预处理，投入产出比最高。很多人卡在表格任务上，第一步就错了，后面所有优化都在错误的地基上做。
第二步我会做第 10 篇的外置计算。同样是工程改动为主，把数值运算从模型里剥离出去，可靠性提升立竿见影。第三步才是第 3 篇和第 9 篇这类涉及结构改造的工作，需要改模型输入格式甚至网络结构，投入大，适合在基础流程稳定之后再上。
图这条线上，我建议先做第 1 篇的层数诊断，成本极低，一个统计脚本就能跑。第 2 篇的采样优化留到数据规模真的撑不住的时候再做，小图上做采样只会引入不必要的方差。大模型这条线上，第 7 篇的调度优化适合已经有服务在跑的场景，第 6 篇的适配策略适合刚起步做微调的场景，两者优先级取决于你当前在哪个阶段。
5.2 复现时最容易翻车的三个地方
第一个是数据划分。图数据上的划分尤其容易出问题，随机划分节点会让训练集和测试集之间存在大量边连接，指标虚高。正确做法是按连通分量或者按时间划分。我见过不止一次报告出来的指标比实际部署效果好一大截，回头查都是划分泄漏。
第二个是评测口径不一致。表格任务的基准里，同一个问题可能有多种等价表述，严格的字面匹配会把正确答案判错，宽松匹配又会放过错误答案。我现在的做法是准备一小批人工标注的验证集，二十到五十条就够，所有改动都在这上面过一遍，不被公开基准的数字牵着走。
第三个是忽略了推理成本。论文里的方案大多在受控环境下测的，实际部署时批大小、序列长度分布、硬件特性都会让结论变形。我给自己定的规矩是：任何优化在落地前，必须在接近真实的流量分布上测一遍尾延迟，不只看平均值。平均值好看但尾部抖动大的方案，线上会非常难受。
5.3 把论文里的技巧偷进项目的判断标准
最后说我筛选技巧的标准，一共三条。第一，改动是否局部。能在不改动整体架构的前提下插入的，优先考虑；需要动数据流和训练流程的，慎重。第二，失败模式是否可观测。好的技巧在失效的时候会有明确信号，比如指标突然跳水或者某个子集明显变差；坏技巧失效时悄无声息，你根本不知道它没起作用。
第三，收益是否和数据规模挂钩。有些技巧在小数据上有效，数据一多就失效；有些反过来。搞清楚这一点，你才知道什么时候该把它摘掉。我在一个项目里留了一个两年前加的模块，一直没敢删，后来做消融才发现它早就不起作用了，纯粹是心理安慰。定期清理这类历史包袱，比不断加新技巧更重要。
这三条标准不完美，但它们帮我避开了一类最常见的浪费：花两周复现一个论文方案，最后发现收益在噪声范围内。现在我的习惯是先花半天做一个最小验证，只测最关键的那个假设，通过了再投入。十篇论文里真正被我完整复现的只有三篇，但每一篇的边角料都用上了，这个比例我觉得是健康的。
