从“词与词的注意”到“特征与特征的组合”

——用特征交互重新理解 Transformer 的 QK，并设计一个可视化分析工具

很多人解释 Transformer 的 Attention 时，会说：

Q 去查询 K，然后决定应该关注哪个 Token。

这个说法没有错，但它容易让人产生一个误解：

好像 Attention 只是在“词与词之间建立联系”。

实际上，如果进一步研究 Transformer 内部的 QK 机制，会发现一个更有意思的解释：

QK 可能更适合被理解为“当前状态中的特征，与其他位置上的特征进行匹配，并对部分特征进行强化或抑制”。

因此，我们希望开发一个实验性工具，不只是显示 Attention Matrix，而是尝试回答：

一个词包含哪些特征？另一个词包含哪些特征？QK究竟强化了哪些特征？这些特征组合之后，又形成了什么新的表示？

一、先改变一个基本理解：Attention不是简单的“词找词”

假设输入：

母亲像一座山。

传统解释可能是：

母亲 → 山

Attention告诉我们：

当前 Token 对“山”具有较高的注意力。

但这还不够。

因为“母亲”和“山”之间并不是完全相同。

“母亲”可以包含：

女性
生育
抚养
保护
温暖
家庭
依靠
坚韧

“山”可以包含：

高大
坚固
稳定
屹立
永恒
险峻
阻挡

当出现：

母亲像一座山。

真正有意义的并不是：

母亲 ≈ 山

而可能是：

母亲
 ↓
激活某些特征
 ↓
保护、稳定、坚韧、依靠……
 ↓
与“山”的相关特征发生匹配
 ↓
山的“坚固、稳定、屹立”等特征被选择
 ↓
形成新的组合表示

因此，Attention的重要对象不应该只理解为：

Token。

还应该考虑：

Feature。

二、比喻为什么具有不对称性？

这是这个模型非常重要的一个测试案例。

比较：

母亲像一座山。

和：

山像母亲。

两句话显然不是同一个意思。

如果简单使用词向量相似度：

similarity(母亲, 山)

很难解释这种不对称性。

但 QK 本身就是不对称的。

可以抽象成：

Q(A) × K(B)

而反过来：

Q(B) × K(A)

一般并不相同。

因此：

母亲像山

可以理解为：

Q(母亲) × K(山)

而：

山像母亲

则是：

Q(山) × K(母亲)

二者选择的特征可能完全不同。

因此，工具必须能够分析：

不是“两个词是否相似”，而是“当前 Query 的哪些特征与 Key 的哪些特征发生了匹配”。

三、每一个对象都可以看成一个“特征集合”

在这个实验模型中，不应该把一个 Token 看成一个不可分割的向量。

可以暂时把它理解成：

Token
 ↓
Feature集合

例如：

母亲
├── 女性
├── 生育
├── 抚养
├── 保护
├── 温暖
├── 家庭
├── 依靠
└── 坚韧

以及：

山
├── 高大
├── 坚固
├── 稳定
├── 屹立
├── 永恒
├── 险峻
└── 阻挡

这里的“特征”并不要求一开始就是真正的人类可读概念。

在实际 Transformer 中，它们可能是：

• SAE Feature
• Cross-Layer Transcoder Feature
• 某个隐藏表示方向
• 某个神经网络内部可解释 Feature

因此第一版程序应该允许：

Feature_001
Feature_002
Feature_003
...

以后再把它们映射为自然语言描述。

四、QK应该分析什么？

标准 Attention 的核心可以简化为：

Score = Q × K

因此程序不要只记录：

Token A → Token B = 0.82

而应该进一步尝试拆解：

Token A
├── Feature A1
├── Feature A2
├── Feature A3
└── Feature A4

Token B
├── Feature B1
├── Feature B2
├── Feature B3
└── Feature B4

然后分析：

A1 × B1 → +0.8
A1 × B2 → -0.1
A2 × B1 → +0.3
A2 × B2 → +1.7
A3 × B3 → -0.4
...

于是原来的：

A → B

变成：

A1 ─────→ B1
A1 ─────→ B2
A2 ─────→ B1
A2 ─────→ B2
A3 ─────→ B3

这就是：

Feature × Feature Interaction Graph

五、一个更重要的假设：QK不仅决定“看谁”，还可能决定“强化什么”

因此程序需要把两个层面区分开。

第一层：位置选择

例如：

当前Token
 ↓
候选Token A   +0.2
候选Token B   +2.1
候选Token C   -0.4
候选Token D   +0.1

这是传统 Attention 的结果。

第二层：特征选择

进一步分析：

当前Feature
      ↓
 ┌────┼────┐
 ↓    ↓    ↓
B1   B2    B3
+2.0 +0.1 -0.7

于是我们真正想观察：

为什么B被选择？

答案可能不是：

因为B这个词重要。

而是：

因为B内部某些Feature与当前Query Feature发生了强匹配。

六、特征组合可能产生新的Feature

这是本项目最重要的研究方向。

假设：

母亲
 ↓
保护 + 温暖 + 坚韧

而：

山
 ↓
稳定 + 坚固 + 屹立

经过 QK 交互之后：

保护 × 稳定
温暖 × 坚固
坚韧 × 屹立

可能形成新的组合表示：

可靠
坚定
庇护
依靠

注意：

这些新特征不一定是输入中的任何一个词。

所以模型可能发生：

原始Token
 ↓
原始Feature
 ↓
Feature Interaction
 ↓
Feature Combination
 ↓
New Feature
 ↓
新的概念表示

因此程序应该允许出现：

Feature A
      +
Feature B
      ↓
Combined Feature C

而不是强制认为：

输出 = 输入词的复制

七、Q、K、V应该重新理解

为了便于程序设计，可以暂时采用下面的解释模型。

Q：当前需要匹配什么？

Q可以理解为：

当前状态正在寻找哪些特征。

例如：

当前：
Aunt

可能激活：
“亲属”
“人”
“称谓”

于是产生 Query：

Q = [亲属, 人, 称谓, ……]

K：这个位置提供什么特征？

Key可以理解为：

这个位置具有什么可供匹配的特征。

例如：

Sally

K = [人名, 女性, 人, ……]

于是：

Q(Aunt) × K(Sally)

可能得到较高匹配。

V：真正传递什么？

如果 QK 决定：

“这个位置值得关注。”

那么 V 更接近：

从这个位置把什么表示带回来。

因此：

QK
 ↓
选择 / 强化相关位置
 ↓
V
 ↓
传递该位置的信息

可以暂时理解为：

Q：我现在需要什么？
K：我这里有什么？
QK：我们匹配程度如何？
V：那我把什么东西带过去？

这不是对 Transformer 数学定义的替代，而是为了建立可解释的分析层。

八、程序的核心目标

开发一个：

Transformer Feature Interaction Analyzer

中文可以叫：

Transformer 特征交互分析器

第一版不追求训练模型，而是追求：

输入一句话 → 分析模型内部某一层/某一个 Attention Head → 把 Token、Feature、QK、V、输出之间的关系可视化。

九、第一版输入

程序首先支持：

模型：
GPT / Llama / Qwen / Gemma 等可加载模型

输入文本：
母亲像一座山。

指定：
Layer
Attention Head
Token

例如：

文本：
母亲像一座山。

Layer：
8

Head：
3

Query：
母亲

十、第一阶段必须实现的功能

Token视图

显示：

[母亲] [像] [一] [座] [山] [。]

点击一个 Token 后显示：

Query Token：
母亲

Attention：

母亲   0.03
像     0.08
一     0.01
座     0.02
山     0.71
。     0.05

十一、第二阶段：QK矩阵分解

显示：

Query Feature
        ↓
┌──────────────────────┐
│ Feature Interaction   │
├──────────────────────┤
│ F001 × F018 = +1.72  │
│ F001 × F034 = +0.31  │
│ F007 × F018 = -0.62  │
│ F012 × F055 = +0.48  │
└──────────────────────┘

按照贡献绝对值排序。

用户可以设置：

Top 10
Top 50
Top 100

十二、第三阶段：交互图

最终显示成：

             母亲
               │
       ┌───────┼────────┐
       ↓       ↓        ↓
     F001     F007     F012
       │        │        │
       │ QK     │ QK     │
       ↓        ↓        ↓
     山:F018  山:F034  山:F055
       │        │        │
       └────────┼────────┘
                ↓
           Combined Feature
                ↓
             下一层

用户可以拖动节点。

可以缩放。

可以隐藏弱连接。

十三、第四阶段：对比“母亲像山”和“山像母亲”

这是一个非常重要的实验功能。

输入：

A：
母亲像一座山。

B：
山像一位母亲。

程序自动比较：

QK Interaction A
        VS
QK Interaction B

然后显示：

共同Feature

A中特有Feature

B中特有Feature

最终回答：

两个句子虽然使用相同或相近的词，但为什么内部计算不同？

十四、第五阶段：干预实验

这是后续版本非常重要的功能。

例如：

删除 Feature F018

或者：

将 F018 activation × 0.5

然后重新计算。

比较：

原始：
山 Attention = 0.71

干预：
山 Attention = 0.32

再观察：

最终输出概率

是否发生对应变化。

这样才能从：

“这个Feature看起来很重要”

进一步走向：

“这个Feature确实对模型行为产生因果影响。”

十五、必须区分三个概念

程序设计中不要混淆：

Attention Weight

模型最终给某个位置多少Attention。

QK Attribution

哪些Query/Key Feature导致这个Attention Score增加或减少。

OV Attribution

被关注之后，哪些Value信息被传递出去。

因此界面应该明确显示：

              Attention
                 │
        ┌────────┴────────┐
        ↓                 ↓
       QK                 OV
   为什么关注？        传递什么？
        │                 │
   Feature × Feature   Feature → Feature

十六、不要把“Feature”简单等同于“人类概念”

这是开发中非常重要的限制。

不能直接假设：

Feature_001 = 母爱
Feature_002 = 坚韧
Feature_003 = 山

真实模型中的 Feature 可能：

• 多义
• 重叠
• 分布式
• 上下文相关
• 跨层存在
• 一个概念由多个 Feature 共同表示

所以程序必须保留：

Feature ID
Activation
Contribution
Layer
Head
Token Position

自然语言解释只是附加信息。

十七、程序的数据结构建议

每个 Token：

TokenNode
{
    id
    text
    position
    layer
}

每个 Feature：

FeatureNode
{
    id
    layer
    activation
    description
}

QK关系：

QKEdge
{
    queryFeature
    keyFeature
    score
    contribution
}

Attention关系：

AttentionEdge
{
    queryToken
    keyToken
    score
}

V关系：

VEdge
{
    sourceFeature
    targetFeature
    contribution
}

十八、最终图结构

最终希望得到：

Token
 ↓
Feature
 ↓
QK Interaction
 ↓
Feature
 ↓
Attention
 ↓
V Information Transfer
 ↓
Feature
 ↓
Next Layer
 ↓
Output

这实际上形成一张：

Transformer Computational Graph

而不是简单的 Attention Heatmap。

十九、开发路线

Version 0.1

先不做复杂 Feature。

实现：

文本
 ↓
Tokenizer
 ↓
Transformer
 ↓
Attention Head
 ↓
QK Matrix
 ↓
可视化

Version 0.2

加入：

Q Feature
K Feature
Feature Interaction

Version 0.3

加入：

OV
Feature → Feature

形成：

QK + OV

Version 0.4

加入：

Cross-Layer

观察：

Layer 3 Feature
 ↓
Layer 5 Feature
 ↓
Layer 8 Feature

Version 0.5

加入：

Intervention

允许：

Feature × 0
Feature × 0.5
Feature × 2

然后比较模型输出。

Version 0.6

加入：

StructNN

把自然语言的显式结构：

主语
谓语
宾语
修饰关系
因果关系

与 Transformer 内部的：

Feature
QK
OV
Circuit

放在同一个界面中。

二十、最终目标

这个项目不是为了证明：

Transformer内部就是一棵语法树。

也不是为了证明：

每一个Feature都对应一个人类概念。

真正的问题应该是：

Transformer在处理自然语言时，是否会形成某种隐式结构？

进一步：

这种隐式结构是否可以通过Feature、QK Interaction、OV Information Flow和Causal Intervention逐步还原？

最终希望能够比较：

             人类显式结构
                  │
                  │
                  ↓
            StructNN Graph
                  │
                  │
                  ↓
              对照分析
                  ↑
                  │
                  │
        Transformer Circuit
                  ↑
          QK + OV + Feature
                  ↑
             Transformer

如果两者在大量不同句子上出现稳定对应关系，那么我们就可以进一步研究：

自然语言的结构，是不是Transformer内部某种Feature Interaction的外部可读版本？

这比单纯问：

“Attention到底关注了哪个词？”

更深入一个层次。

最核心的设计思想

整个项目暂时只需要记住一句话：

不要把 Transformer 看成“词与词之间互相注意”，而应该尝试把它分析成“不同位置上的特征，通过非对称的 QK 交互进行匹配、强化和抑制，并通过 V 把部分信息重新组合到当前表示中”。

因此：

Token
 ↓
Feature
 ↓
Feature × Feature
 ↓
强化 / 抑制
 ↓
组合
 ↓
New Feature
 ↓
New Representation
 ↓
下一步计算

这就是本项目最核心的实验假设。

注意：这是一个用于解释和实验的模型，不是对 Transformer 内部机制的最终定论。程序必须同时保留原始 Transformer 数学计算结果，以便比较“解释模型”和“真实模型”的差异。