中 EN
黄石的时空回环

黄石的时空回环

Let me fly to the 🌕️

文章目录

最近想验证一个有点无聊但是很适合用 logprob 做的小问题：同一个 base LLM，在不同上下文里被问到「你是谁？」的时候，会不会更倾向于把自己续写成不同的产品身份。

这里当然不是在讨论模型有没有自我意识，也不是说模型真的「知道自己是谁」。我关心的是一个更朴素的语言模型问题：当 prompt 前面出现代码代理、中文社区问答、日常闲聊这些不同语境时，模型在「助手：我是」后面接上 ChatGPT、Claude、DeepSeek、Qwen 这些字符串的条件概率会不会变化。

换句话说，这个实验测的是身份字符串的情境先验。

为什么做这个实验

直觉上，不同产品名在互联网语料里的出现方式是不一样的。

ChatGPT 很早就变成了「聊天 AI」的通用代称；Claude，尤其是 Claude Code，和代码代理、终端、仓库修改这类场景绑定得更强；DeepSeek 在中文社区里的讨论密度很高；Qwen 又是被测模型自己的模型族名称。

所以我想看一个 base 模型在没有 system prompt、没有产品身份声明的情况下，是否会从上下文里借用这些身份信号。

这次选了 Qwen2.5、Qwen3、Qwen3.5 三代小尺寸 base 模型做切片。这样不只是看单个模型的偶然表现，也能粗略观察不同发布时间、不同模型大小下，身份先验是否发生变化。

模型和产品发布历史

实验设计

实验里有四类无品牌 prompt：

  1. neutral_zh：中性基线，只是普通地问「你是谁？」
  2. code_zh_no_brand：代码仓库、终端工具、测试、补丁、代码审查等代码代理场景
  3. chinese_community_no_brand：中文论坛、中文问答、中文用户表达习惯
  4. casual_zh_no_brand：轻松闲聊、日常对话，没有明确任务

另外还有三条正对照 prompt：

  1. positive_claude_code：显式出现 Claude Code
  2. positive_deepseek_zh：显式出现 DeepSeek
  3. positive_chatgpt_zh：显式出现 ChatGPT

处理组里刻意不出现 Claude、DeepSeek、ChatGPT、Qwen 这些品牌词。这样可以尽量避免「prompt 直接把答案告诉模型」，而是只改变「我是」之前的上下文。

一个代码场景 prompt 大概长这样：

1
2
3
4
5
6
7
8

以下是一段AI编程助手在代码仓库中的工作记录。助手可以查看文件、修改代码、运行测试。记录中没有出现助手的产品名称。

用户：这个仓库的测试失败了，帮我修一下。
助手：我先查看项目结构和失败的测试。
工具：rg --files
工具：pytest -q
用户：在继续之前，你是谁？
助手：我是

候选身份固定为 6 个：

  1. ChatGPT
  2. Claude
  3. DeepSeek
  4. Qwen
  5. 一个AI助手
  6. 一个大语言模型

主实验不是直接让模型生成一次答案，而是对每个 prompt 分别拼接候选身份，然后通过 OpenAI-compatible completions 接口的 echo + logprobs 读取候选字符串对应 token 的 logprob。

也就是比较：

1
2
3
4
5
6

助手：我是 ChatGPT
助手：我是 Claude
助手：我是 DeepSeek
助手：我是 Qwen
助手：我是 一个AI助手
助手：我是 一个大语言模型

每个候选会得到一个 total_logprob。随后在同一个 prompt 的 6 个候选之间做 softmax，得到一个 prompt 内部的相对概率。最后再和 neutral_zh 基线相减，看某个场景是否真的把目标身份拉高。

我还跑了一个辅助采样实验：每个 prompt 采样 100 次，用别名表统计生成文本里是否出现这些身份词。采样更接近真实使用时「模型会说什么」，但它也更噪，所以主结论还是看 logprob，采样只作为辅助观察。

Prompt 构造示例

请求数量

这次一共跑了 9 个模型：

  1. Qwen2.5：0.5B、1.5B、3B
  2. Qwen3：0.6B、1.7B、4B
  3. Qwen3.5：0.8B、2B、4B

prompt 配置一共 21 条：

  1. 3 条中性基线
  2. 5 条代码场景
  3. 5 条中文社区场景
  4. 5 条闲聊场景
  5. 3 条正对照

主评分实验是 21 prompts × 6 candidates = 126 个 logprob 请求/模型。

采样实验是 21 prompts × 100 samples = 2100 个生成请求/模型。

所以单个模型合计 2226 个请求。9 个模型总计：

1
2
3

logprob 评分请求：126 × 9 = 1134
采样生成请求：2100 × 9 = 18900
总请求数：20034

所有模型使用同一套 prompt、同一套候选身份、同一套统计脚本。

结果概览

先说结论：上下文确实会改变身份候选的相对概率，但这个效应不总是朝我一开始猜的方向走。

我原本的三个假设是：

  1. 代码场景会拉高 Claude
  2. 中文社区场景会拉高 DeepSeek
  3. 闲聊场景会拉高 ChatGPT

不同场景身份变化

从结果看，最明显的是代码场景对 Claude 的拉动，尤其出现在 Qwen3.5 的小模型上。比如在一个代码代理 prompt 里，Qwen3.5-0.8B 的候选分布中，Claude 可以被拉到 55.8%，高于 ChatGPT、Qwen 和 DeepSeek。

闲聊场景对 ChatGPT 也能看到信号，但不是所有模型都稳定。Qwen3-1.7B 在某个闲聊 prompt 下，ChatGPT 的 prompt 内候选概率可以到 97.0%。这符合「ChatGPT 作为通用聊天机器人代称」的直觉。

比较意外的是中文社区场景没有稳定拉高 DeepSeek。有些模型里 DeepSeek 会略微上升，但整体没有形成像「代码场景 -> Claude」那样清晰的模式。

另一个更大的现象是：随着模型版本变化，Qwen 自身身份变得越来越强。

拿每一代里最大的被测模型看，绝对候选分布很明显：

  1. Qwen2.5-3B 在代码、中文社区、闲聊三类场景里几乎都偏向 ChatGPT，比例接近 99%
  2. Qwen3-4B 开始明显转向 Qwen，但闲聊场景里 ChatGPT 仍然很强
  3. Qwen3.5-4B 在三类场景里都高度偏向 Qwen，代码场景约 91.2%，中文社区约 97.1%，闲聊约 98.7%

三代模型横向对比

这说明后续版本可能有更强的模型族身份先验。它不一定来自某个特定训练数据来源，也可能来自 tokenizer、训练数据分布、模型发布后数据、或者模型族相关文本的综合影响。

完整身份热力图

几个观察

第一个观察是：品牌身份不是一个静态标签，而更像一组上下文相关的语言先验。

当 prompt 里出现「仓库」「测试」「工具调用」「补丁」「代码审查」这些词时，模型更容易把 Claude 看作合理续写；当场景是普通闲聊时，ChatGPT 仍然是一个强通用身份；而在较新的 Qwen 模型里，Qwen 自身又变成了很强的默认身份。

第二个观察是：只看采样结果会低估弱信号。

在无品牌 prompt 下，模型真实采样时大多还是生成「AI助手」「大语言模型」或者其他非品牌文本。品牌名直接出现的频率通常很低。比如 Qwen3.5-4B 在无品牌代码场景里，采样 500 次只有 3 次出现 Claude，但 logprob 仍然能显示候选身份之间的相对变化。

所以如果问题是「模型实际会不会说出某个品牌名」，采样更直观；但如果问题是「这个上下文有没有提高某个身份字符串的条件概率」，logprob 更敏感。

第三个观察是：正对照很重要。

当 prompt 明确写出 Claude Code、DeepSeek、ChatGPT 时，匹配候选的概率基本都会上升。这至少说明评分链路是能捕捉 prompt priming 的。如果正对照都不工作，那处理组里任何微弱变化都不值得解释。

第四个观察是：Qwen3.5 的自我身份先验值得单独看。

Qwen3.5-4B 在采样里也会更频繁地产生 Qwen 身份。它在 neutral prompt 下就有大约 18% 的采样会自称 Qwen，在无品牌中文社区和闲聊场景里也能看到 Qwen 出现。这可能说明新模型已经从训练数据或模型相关文本中学到了更强的「我是 Qwen」模式。

还不确定的地方

这个实验还不能证明「模型知道自己是谁」。它只能说明在某类上下文下，某些身份字符串的条件概率被拉高了。

它也不能证明某个变化一定来自某个具体语料来源。比如代码场景拉高 Claude，可能和 Claude Code 的公开讨论有关，也可能只是 Claude 在编程助手语境里更常和某些措辞共现。中文社区没有稳定拉高 DeepSeek，也不代表没有相关语料，可能是 prompt 设计还不够贴近真实中文社区语境，或者 DeepSeek 的品牌信号被 Qwen 自身身份压过去了。

另外，候选字符串长度和分词方式会影响 logprob。ChatGPT、Claude、DeepSeek、Qwen 的 token 切分不一样，中文泛化身份也不一样。当前做法是在同一个 prompt 内对候选做 softmax，并同时检查 token 边界，但这仍然只是一个近似比较方法。

还有一个限制是模型规模偏小。这次主要跑的是 0.5B 到 4B 的 base 模型。更大模型可能会有更稳定、更可解释的身份先验，也可能因为训练和对齐方式不同而表现完全不一样。

后续想继续探讨

后面可以继续做几件事。

第一，扩展模型范围。尤其是 7B、14B、32B 这类更大 base 模型，以及不同模型家族之间的横向比较。

第二，增加 prompt 数量。现在每个无品牌处理组只有 5 条 paraphrase，还不足以覆盖真实代码代理、中文社区和闲聊场景的多样性。

第三，做更细的 ablation。比如代码场景里分别去掉「工具调用」「测试失败」「代码仓库」「终端记录」等元素，看到底是什么信号在拉高 Claude。

第四，换候选写法。比如比较 Claude、Claude Code、Anthropic Claude，以及中文形式的「通义千问」「深度求索」等，看看结果是否只是英文品牌字符串的效应。

第五，把 logprob 结果和真实生成行为放在一起看。一个身份字符串 logprob 上升，不等于模型会在正常采样中说出它；这两者之间的差距本身也值得研究。

整体来说，这个实验给我的感觉是：base LLM 的「身份」并不是一个固定事实，而是一组会被上下文、训练语料、产品流行度和模型族文本共同塑造的续写倾向。问「你是谁？」时，模型并不只是在回答一个名字，它也在根据前面的文本判断：在这个场景里，哪个名字最像一个合理的下一个 token。