想象一下，你正在看一张电子表格。在其中一个单元格里，你看到了“Fallen”这个词。

如果不看表格的其他部分，“Fallen”这个词是有歧义的。它是那部由丹泽尔·华盛顿主演的 1998 年电影吗？是那本畅销小说吗？还是摇滚乐队 Evanescence 的首张录音室专辑？

作为人类，我们会立刻扫描行，看到“Evanescence” (艺术家) 和“2003” (年份) ；我们也会扫描列，看到“The Fame”和“Let Go”等其他条目。我们立刻就会明白: 这是那张专辑。

这个过程被称为表格实体链接 (Table Entity Linking, TEL) 。 它的任务是将表格中的一个提及项 (比如“Fallen”) 映射到知识库 (如 Wikidata 或 Wikipedia) 中特定的唯一条目。虽然这对人类来说似乎很容易，但机器却很难做到。为什么？因为大多数人工智能模型都被训练成从左到右线性地阅读文本。但表格是二维的。它们有行和列，而这两个维度意味着截然不同的东西。

在这篇文章中，我们将深入探讨一篇题为 “RoCEL: Advancing Table Entity Linking through Distinctive Row and Column Contexts” 的研究论文。我们将探索研究人员如何构建了一个模型，最终以不同的方式处理行和列，从而取得了甚至连强大的大语言模型 (LLM) 都难以匹敌的最先进结果。

平面阅读的问题

现有的实体链接 (EL) 方法大多将表格视为被打乱的句子。它们获取表格单元格，将其扁平化为文本序列，然后将其输入像 BERT 这样的模型。虽然这捕捉到了一些上下文，但它破坏了表格的结构完整性。

即使是专门为表格设计的模型，如 TURL，通常使用的机制也会不加区分地混合行和列的信息。

RoCEL 的作者认为这是一个错误，因为行和列在语义上是截然不同的 :

  1. 行上下文 (Row Context) : 提供描述性信息。行中的单元格通常描述属性或相关对象 (例如，这张专辑的发行年份) 。
  2. 列上下文 (Column Context) : 提供类别性信息。列中的单元格通常属于同一类型或类别 (例如，其他专辑的列表) 。

为了解决这个问题，研究人员提出了 RoCEL (Row-Column differentiated table Entity Linking，行列差异化表格实体链接) 。

图 1: 表格实体链接示例。蓝色文本代表实体提及项。

如上方的图 1 所示，理解“Fallen”需要整合行上下文 (发行年份、艺术家) 和列上下文 (其他专辑) 。RoCEL 的设计初衷就是在融合这两个维度以做出最终决定之前，先分别对它们进行建模。

理解表格上下文

在看架构之前，让我们先规范一下表格在机器眼中的样子。

一个表格 \(T\) 由行和列组成。我们感兴趣的是位于第 \(i\) 行和第 \(j\) 列的一个特定单元格，即提及项 (mention) , 记为 \(T_{ij}\)。

图 2: 表格上下文图解。

图 2 展示了可用的数据:

  • 元数据 (Metadata, \(T_{\Theta}\)) : 表格的标题或说明文字 (例如，“最畅销专辑……”) 。
  • 行 (Row, \(T_{i*}\)) : 同一水平线上的所有单元格。
  • 列 (Column, \(T_{*j}\)) : 同一垂直线上的所有单元格。
  • 表头 (Headers, \(T_{H*}\)) : 列顶部的标签。

任务的目标很简单: 给定一个提及项 \(T_{ij}\)，将其链接到知识库中的正确实体 \(e\)。

RoCEL 架构

RoCEL 的核心创新在于其双管齐下的方法。它不使用单一的“表格编码器”。相反，它使用一个行上下文编码器和一个列上下文编码器 , 每个编码器的架构都不同，以匹配该维度的语义本质。

让我们来看看高层架构:

图 3: RoCEL 的整体架构。“Fallen”是待链接的提及项单元格 \\(T_{ij}\\)。

正如你在图 3 中所见，该过程分为三个阶段:

  1. 行上下文编码: 基于行创建一个向量表示 (\(v^{mr}\)) 。
  2. 列上下文编码: 基于列创建一个向量表示 (\(v^c\)) 。
  3. 语义融合与实体链接: 结合它们以找到匹配的实体。

让我们分解每个阶段。

1. 行上下文编码: 捕捉依赖关系

想一想数据库中的一行。“2003”与“Fallen”相关，因为它是其发行年份。行中的单元格之间存在很强的隐式依赖关系。读起来几乎像一个句子: “2003 年，Evanescence 的专辑 Fallen 在美国发行。”

由于这种顺序的、类似句子的依赖关系，作者使用了 BERT , 这是一个以处理自然语言序列而闻名的 Transformer 模型。

首先，他们将行序列化为文本格式。他们将每个单元格与其表头配对以明确含义 (例如，“Release Year: 2003”) 。

行序列化公式

在这个公式中:

  • \(p_{ik}\) 代表特定单元格的文本片段。
  • 注意特殊的标记 [START] 和 [END]，用于在序列中突出显示目标提及项 \(T_{ij}\)。
  • 所有内容都与表格元数据 \(T_{\Theta}\) 拼接在一起。

一旦构建好这个序列，它就会被输入到 BERT 中。模型利用自注意力机制 (self-attention) 来理解“Fallen”与“Evanescence”及“2003”之间的关系。

BERT 编码公式

我们要取 [CLS] 标记 (BERT 中用于表示整个序列的特殊标记) 的输出作为我们的行上下文提及项嵌入 (Row-Contextualized Mention Embedding) (\(v_{ij}^{mr}\))。

2. 列上下文编码: 捕捉类别

现在，考虑一下列。列中包含“The Fame”、“Fallen”和“Let Go”。不像行，这里没有“句子”。顺序并不重要。“The Fame”不是“Fallen”的主语。它们是恰好共享一个类别 (专辑) 的独立项目。

因此，将列视为一个序列 (像句子一样) 在语义上是错误的。这引入了一种不存在的人为顺序。

相反，RoCEL 将列视为一个无序集合 (unordered set) 。 目标是从这组实体中提取列的“主旨”或“类型”。为此，他们使用了一个名为 FSPool (Feature-wise Sort Pooling，特征排序池化) 的集合编码器 (Set-wise Encoder) 。

这个编码器的输入是该列中所有提及项的嵌入集合 (这些嵌入是我们从行编码器步骤中获得的) 。

FSPool 编码公式

这里，\(v_{j}^{c}\) 代表列嵌入 (Column Embedding) 。 它将该列中所有专辑的信息压缩成一个代表“音乐专辑”概念的单一向量。

3. 列编码器的预热 (Warm-up)

这里存在一个微妙的工程挑战。行编码器使用的是 BERT，它已经在海量文本上进行了预训练，已经“知道”很多东西。而列编码器 (FSPool) 则是随机初始化的。

如果我们从头开始训练整个模型，列编码器发出的嘈杂、随机的信号最初可能会混淆模型。为了解决这个问题，研究人员引入了一个预热阶段 (Warm-up Stage) 。 在训练主要的实体链接任务之前，他们使用辅助任务对列编码器进行预训练。

他们提出了两种方法来实现这一点:

A. 监督式列类型分类 (Supervised Column Typing) : 如果我们有关于列是什么的标签 (例如，“音乐专辑”) ，我们可以训练编码器来预测这个标签。

列类型分类损失公式

B. 无监督式集合重构 (Unsupervised Set Reconstruction) : 如果我们没有标签怎么办？我们可以使用自编码器 (auto-encoder) 方法。我们尝试将列项目的集合压缩成一个单一向量，然后看看能否从该向量重构出原始集合。如果重构准确，说明编码器已经成功捕捉到了列的关键信息。

集合重构损失公式

这个预热阶段确保了列编码器足够聪明，能够在真正的训练开始时贡献有意义的信号。

4. 融合与链接

最后，我们有了一个描述特定实体的行嵌入 (\(v_{ij}^{mr}\)) 和一个描述类别的列嵌入 (\(v_{j}^{c}\)) 。我们将它们拼接起来，并通过一个多层感知机 (MLP) 来混合特征。

融合 MLP 公式

这给了我们最终的提及项嵌入 \(v_{ij}^{mrc}\)。

为了在知识库中找到正确的实体，我们计算提及项嵌入与数据库中所有候选实体嵌入 (\(u_e\)) 之间的相似度 (点积) 。

相似度与 Argmax 公式

系统使用交叉熵损失进行训练，以最大化正确实体相对于其他实体的得分。

最终损失函数公式

实验结果

区分行和列真的有帮助吗？研究人员在四个基准数据集 (TURL-Data, T2D, Wikilinks-R, 和 Wikilinks-L) 上测试了 RoCEL，并与几个最先进的基准模型进行了对比。

基准模型包括:

  • 基于单元格 (Cell-based) : 仅使用提及项文本 (例如 Wikidata Lookup) 。
  • 基于文本 (Text-based) : 将表格扁平化为文本 (例如 BERT, BLINK) 。
  • 基于表格 (Table-based) : 使用表格结构但通常混合上下文 (例如 TURL) 。

主要结论: RoCEL 胜过所有这些模型。

表 12: RoCEL 与基准模型的比较

如上方的结果表所示，RoCEL (特别是使用了预热策略的 R-C 和 R-S 版本) 在域内和域外数据集上都达到了最高的准确率。它以显著优势击败了 TURL，证明了行和列语义的分别建模优于统一方法。

消融实验: 什么更重要？

研究人员还拆解了模型，看看哪些部分起的作用最大。他们逐一移除了不同的上下文。

表 2: 展示移除上下文影响的消融研究

结果 (表 2) 很有启发性:

  1. 行上下文是王道: 移除行上下文导致性能下降最大 (\(86.9 \rightarrow 83.2\)) 。实体的描述 (例如艺术家姓名) 是最关键的线索。
  2. 列也很重要: 移除列也会损害性能，证实了知道类别有助于消歧。
  3. 元数据有帮助: 即使是表格标题也能提供有用的上下文。

我们不能直接用 ChatGPT 吗？

在生成式 AI 时代，一个自然的问题是: “为什么要构建专门的模型？Llama-3 或 GPT-4 不能搞定这个吗？”

研究人员在这个任务上测试了 Llama-3-8B。他们提供了各种文本格式 (JSON, Markdown 等) 的表格上下文。

图 5: 用于基于文本的方法的布局

他们尝试只给 LLM 行、只给列，或者给整个表格 (多行) 。

表 5: Llama3 的准确率

结果出奇地差 (准确率约为 52-58%，相比之下 RoCEL 为 86%+) 。

为什么？

  1. 上下文过载: 当表格被序列化为一维提示词 (prompt) 时，LLM 难以解析严格的二维结构。
  2. 噪声: 当提供“多行”上下文 (更多表格数据) 时，LLM 的表现实际上比只看一行时下降了。这表明 LLM 被额外的表格噪声搞糊涂了，而不是利用它来推断列类型。

虽然像 GPT-4 这样的大型模型表现会好一些，但 RoCEL 以极少的参数量 (3.4 亿 vs 数十亿) 和显著更快的推理速度达到了有竞争力甚至更优的结果，使其成为处理数百万条数据库记录的更实用的解决方案。

预热任务的影响

最后，研究人员验证了他们的“预热”策略。预训练列编码器真的有帮助吗？

图 6: 有无预热的链接准确率

图 6 显示，经过预热的模型 (SR 代表集合重构，CT 代表列类型分类) 始终击败没有预热 (NW) 的模型。有趣的是，列类型分类的数据效率非常高——仅用 1% 的训练数据就能提供巨大的提升。

他们还检查了编码器是否真的学会了“类型”。

图 7: 列类型分类 F1 分数

图 7 显示，随着我们增加预热数据，模型在预测正确的列类型 (例如，识别某一列为“电影”或“城市”) 方面变得非常有效，证实了编码器正在按预期工作。

结论

RoCEL 论文给我们上了关于 AI 架构宝贵的一课: 结构意味着语义。

通过不把表格仅仅视为一袋词 (bag of words) ，而是视为一种结构化对象——其中水平线代表描述，垂直线代表类别——研究人员构建了一个更贴近人类解读数据方式的模型。

给学生的关键要点:

  • 上下文区分: 不要对所有输入一视同仁。如果数据有结构，就把这种结构构建到你的模型中。
  • 集合 vs. 序列: 知道何时使用 RNN/Transformer (用于序列) 以及何时使用池化机制 (用于集合) 。
  • 辅助任务: 如果你的网络的一部分很难训练 (比如列编码器) ，在主赛事开始前创建一个预热任务来让它做好准备。

随着我们迈向更复杂的数据处理，像 RoCEL 这样的专用架构表明，虽然 LLM 是强大的通才，但在像表格实体链接这样的精确任务上，有针对性的、具有结构意识的模型仍然占据着王座。