之前在调试一个长链路 Agent 项目时我遇到一个很“诡异”的现象模型在前几轮对话里明明已经正确理解并记住了用户提供的事实但经过几步工具调用和长文本推理之后它突然像“失忆”一样把最开始的关键约束忘得一干二净。更奇怪的是另一个同事在做 Prompt 消融实验时发现把同样的问题改成全大写写法模型的准确率竟然小幅上升了。这两个现象听起来都像是“玄学”但在社区里其实有大量类似讨论最近 arXiv 上也出现了不少相关方向的预印本涉及推理时上下文召回、世界知识遗忘、提示词风格对模型置信度的影响等话题。这篇文章就以“arXiv 人工智能前沿快报”的视角拆解这两个现象背后的原理、可能的解释以及如何用本地脚本做简单的复现实验。内容会比较适合做大模型应用开发、推理框架优化和 Prompt 工程的同学。1. 背景两个看似“玄学”的 AI 现象1.1 “推理时会忘掉世界”是指什么先解释“推理时会忘掉世界”这个说法。这里说的“世界”并不是指物理世界而是指大模型在训练阶段学习到的世界知识以及用户在对话上下文中提供的背景信息。无论是事实性知识还是用户刚给的约束条件都可以统称为模型在推理时需要依赖的“世界信息”。我们在实际使用大模型时会发现当一个问题比较简单、推理链路较短时模型通常能准确引用上下文里的事实。但如果让模型做一道需要多步计算的题或者让它完成一个包含多轮工具调用的任务模型在生成了很长一段推理内容之后反而可能忽略掉早期上下文中的关键信息。这种现象有几个常见表现用户开头说“我的预算是 5000 元”模型算到最后推荐了 8000 元的方案。用户说“不要使用某个第三方库”模型在代码生成的后半段仍然使用了该库。多轮对话中模型在前几轮还能记住用户偏好到后面几轮开始“胡说”。长文档阅读理解时模型对文档中间部分内容的召回率明显低于开头和结尾。如果只是偶尔出现还可以理解为模型能力不足。但当这种“遗忘”在长推理过程中被系统性触发时它就成为一个值得深入研究的工程问题因为长链路推理应用恰恰是最依赖上下文一致性的场景。1.2 大写提示词影响准确率是怎么回事第二个现象更反直觉把提示词全部改成大写模型准确率反而可能上升。正常直觉里人类阅读全大写文字时往往会觉得“被吼了”理解和阅读速度反而会下降。但对大模型来说文本的大小写并不是单纯的“排版风格”而是会影响 Token 切分进而影响注意力分布和模型内部激活。举例来说英文里AI和ai在 BPEByte Pair Encoding字节对编码词表中通常不是同一个 Token。全大写文本和正常大小写文本经过 Tokenizer 之后产生的 Token 序列可能是完全不同的。既然是不同的输入序列模型内部计算出的注意力模式也就会有所差异最终导致输出结果不同。目前不同模型、不同任务上大小写的影响方向并不完全一致。有些任务上全大写会降低准确率有些任务上却会提升准确率。所以新闻里那句“大写还能让准确率上升”并不是一个普适规律而是针对特定模型和特定任务观察到的现象。但它的存在本身就说明大模型的推理结果对提示词的表面形式非常敏感。1.3 为什么这两个现象值得开发者关注如果你只是调用 API 做一些简单问答这两个现象可能影响不大。但如果你在构建以下类型的系统它们就非常关键长上下文 RAG 应用需要模型在大量检索片段中准确定位并引用知识。多轮 Agent 系统模型需要跨多轮对话和工具调用保持任务约束。自动化评测系统需要保证测试集上提示词格式一致否则评测结果不可信。推理框架优化需要关注模型在不同输入分布下的置信度和稳定性。换句话说这两个现象共同指向一个大问题大模型的推理能力不仅取决于“参数里存了多少知识”还取决于“上下文中的信息能不能在推理过程中被有效召回和利用”。2. 背后涉及的模型原理拆解2.1 上下文召回与“Lost in the Middle”关于长上下文中信息召回有一个比较经典的观察叫做 “Lost in the Middle”意思是当我们需要从一段长文档中查找答案时如果关键信息位于文档中间位置模型的准确率往往低于关键信息位于开头或结尾的情况。这个现象和 Transformer 的注意力机制有关。模型在处理长序列时会对所有历史 Token 计算注意力权重但注意力资源是有限的。序列越长早期的 Token 被后续 Token“稀释”得越厉害尤其是当中间还有大量无关内容时模型很难把注意力集中在真正关键的信息上。在长推理场景中问题会更复杂。模型不仅要记住用户指令中的事实还要在推理过程中不断生成新的中间结果。这些中间结果会占据新的上下文位置进一步把早期信息的注意力权重“挤”到边缘。这就导致模型生成到最后时前面的事实已经不在它的有效注意力范围内了。2.2 位置编码与注意力稀释位置编码是让 Transformer 感知 Token 顺序的一种机制。常见的位置编码方式包括绝对位置编码、相对位置编码以及目前大模型中很常见的 RoPERotary Position Embedding旋转位置编码。RoPE 的设计初衷是让模型更好地感知相对位置关系但在超长序列下仍然可能出现注意力分数分布不均匀的情况。比如某些注意力头会过度关注最近生成的 Token而忽略早期 Token另一些注意力头则可能把大量注意力分配给高频词或特殊符号。当模型生成长链推理内容时中间步骤本身就是“注意力干扰项”。如果这些中间步骤与最终答案高度相关模型尚能保持专注但如果中间步骤引入了无关信息模型就可能被带偏忘记最初的目标。2.3 Token 化差异如何影响大小写实验前面说过大小写影响准确率的第一层原因是 Token 切分差异。用 Hugging Face 的 Transformers 库可以很容易地验证这一点。我们需要加载一个模型的 Tokenizer然后把同一句话分别用普通写法、全大写写法、全小写写法传入观察 Token 序列的差异。正常情况下I love AI可能被切分成[I, love, AI]而I LOVE AI可能被切分成[I, LOVE, AI]或[I, LO, VE, AI]具体取决于词表。Token 切分不同模型内部查找到的 Embedding 向量就不同后续所有层的计算路径也都不同。第二个层面是大小写可能影响模型的“置信度校准”。有些实验观察到某些模型在遇到全大写输入时输出分布的熵会降低也就是模型表现得“更确定”。如果这种“更确定”正好对应更高概率选中正确答案那么准确率就会上升。但这并不代表模型理解了更多可能只是改变了输出概率分布的形状。第三个层面是数据分布。模型在预训练和指令微调阶段见过的文本绝大多数是正常大小写。按理说模型应该对正常大小写更敏感。但实际观察到的现象却可能相反这提示我们模型在下游任务上的表现并不完全符合“训练分布越接近越好”的直觉中间还隔着任务难度、上下文长度、指令格式等多个变量。2.4 “世界知识遗忘”和“格式敏感”其实是同一类问题把两个现象放在一起看可以发现它们都指向一个核心问题模型在推理时对上下文信息的利用是“非均匀”的。位置造成非均匀开头、结尾的信息更容易被利用中间的信息容易被忽略。长度造成非均匀推理步骤越长早期信息越容易被稀释。格式造成非均匀同一信息用不同写法表达模型召回的难度不同。干扰造成非均匀无关的中间内容越多关键信息的注意力权重越低。理解了这一点我们就能用更系统的方式去设计实验和工程方案而不是遇到一次“遗忘”就盲目调 Prompt。3. 前沿研究的实验观察从现象到假设3.1 观察一推理越久世界知识越“远”最近 arXiv 上这类研究通常会设计一个非常直接的实验先给模型一段包含明确事实的上下文然后让模型执行多步推理任务最后检查模型能否正确使用最初的事实。实验的基本流程大致如下准备一个事实例如“某公司今年的营收目标是 1200 万”。构造一个需要 5 到 10 步计算的任务中间每一步都会引入一些新的数值或条件。在最终问题中要求模型引用最初的事实进行判断。对比“短推理链”和“长推理链”两种条件下模型的正确率差异。结果通常显示推理链越长模型对初始事实的召回正确率越低。而且这种下降并不仅仅是因为“计算过程出错”而是模型在推理的中后段已经不再引用初始事实相当于从内部路径上把它丢掉了。为什么会这样一种解释是模型在每一步生成新的推理内容时都需要“重新决定”注意力应该放在哪里。生成的内容越长它对前文的注意力覆盖就越稀疏同时模型生成的中间结论本身会成为新的“局部事实”抢占后续注意力的权重。3.2 观察二大小写风格改变输出分布大小写实验的做法更简单。我们可以准备一组中文或英文的推理题然后把每一道题分别转成以下风格原始写法。全大写写法。全小写写法。首字母大写写法。然后在相同模型、相同采样参数下多次运行统计每种风格下的准确率、答案稳定性、平均输出 Token 数等指标。在部分英文任务中全大写写法会让模型输出更“压缩”的答案甚至改变模型的 verbose冗长程度。有些实验观察到模型在回答全大写问题时倾向于给出更短、更直接的回答这种回答在选择题或判断题上反而更容易命中正确答案。但这只能解释一部分现象无法解释所有任务上的变化。还有一种更微妙的解释全大写输入改变了模型对“指令强度”的感知。虽然模型并不理解“吼人”但训练数据中全大写文本往往出现在强调、警告、标题等场景模型可能因此调整了生成风格例如更谨慎、更精简。这种风格变化在部分任务上恰好是有利的。3.3 我们该如何看待这些观察研究社区目前并没有定论不同模型、不同任务上的结论差异很大。但有一点是肯定的这些现象都可以用“上下文信息利用的非均匀性”来解释。推荐读者不要盲目把“全大写能让准确率上升”当作一个万能 Prompt 技巧而是把它当成一个提醒大模型的输出对输入表面形式非常敏感任何 Prompt 改动都应该经过评测验证。4. 本地复现实验自己跑一遍两个现象这一节我们来写两个可运行的 Python 实验脚本用开源模型在本地观察“推理过程中上下文召回能力变化”和“大小写对答案分布的影响”。4.1 环境准备与模型选择建议环境如下Python 3.9 或更高版本。PyTorch 2.x。Transformers 4.40 及以上版本版本需要根据你的环境调整。一个小型指令微调模型例如 Qwen2.5-1.5B-Instruct、Llama-3.2-1B-Instruct 或类似的模型。如果你的显存不大可以先从 1B 左右的模型开始。需要说明的是小模型上的现象往往比大模型弱所以实验脚本的目的不是“证明某个结论”而是演示一种可复现的实验方法。实际效果会因模型和任务而异。示例项目结构如下arxiv_probe/ ├── requirements.txt ├── experiment_1_context_recall.py ├── experiment_2_case_style.py └── results/4.2 实验一长推理链中的事实召回这个实验的思路是构造一个包含“初始事实”的提示词。让模型执行多步推理并在最终步骤中要求模型使用初始事实。使用generate接口控制最大生成长度模拟短推理链和长推理链两种条件。代码如下# 文件路径arxiv_probe/experiment_1_context_recall.py import torch from transformers import AutoModelForCausalLM, AutoTokenizer model_name Qwen/Qwen2.5-1.5B-Instruct tokenizer AutoTokenizer.from_pretrained(model_name, trust_remote_codeTrue) model AutoModelForCausalLM.from_pretrained( model_name, torch_dtypetorch.float16, device_mapauto, trust_remote_codeTrue, ) def build_prompt(fact: str, extra_steps: int) - str: # 构造一个固定事实再加上若干干扰步骤最后要求模型使用该事实 prompt f已知事实{fact}\n for i in range(extra_steps): prompt f第{i1}步请先计算 11 的结果并把结果记为 x{i1}。\n prompt 最终问题请根据【已知事实】中的内容回答我们的目标值是多少 return prompt def run_one(fact: str, extra_steps: int, max_new_tokens: int) - str: prompt build_prompt(fact, extra_steps) messages [ {role: system, content: 你是一个严谨的推理助手请严格依据已知事实作答。}, {role: user, content: prompt}, ] text tokenizer.apply_chat_template( messages, tokenizeFalse, add_generation_promptTrue ) inputs tokenizer(text, return_tensorspt).to(model.device) outputs model.generate( **inputs, max_new_tokensmax_new_tokens, do_sampleFalse, ) response tokenizer.decode(outputs[0][inputs[input_ids].shape[1]:], skip_special_tokensTrue) return response if __name__ __main__: fact 我们公司今年的营收目标是 1200 万元。 for steps in [0, 3, 8, 15]: answer run_one(fact, extra_stepssteps, max_new_tokens256) print(f 干扰步骤数: {steps} ) print(answer) print()这个脚本里使用了do_sampleFalse也就是贪心解码目的是减少随机性让结果更可对比。extra_steps用来控制干扰步骤数量模拟长推理场景。你可能会发现步骤少时模型能直接回答“1200 万元”步骤多时模型可能开始编造新的数值或者回答“未在已知事实中找到相关信息”。这两种情况都说明模型在长链推理中对早期事实的召回能力变弱了。4.3 实验二大小写风格对答案分布的影响第二个实验用于对比同一道英文推理题在不同大小写写法下的输出。需要注意的是中文没有大小写概念因此这个实验主要用于英文 Prompt。如果模型是中文模型可以用英文题目测试或者换用包含大小写变化的中文拼音/英文缩写场景。代码如下# 文件路径arxiv_probe/experiment_2_case_style.py import torch from transformers import AutoModelForCausalLM, AutoTokenizer model_name Qwen/Qwen2.5-1.5B-Instruct tokenizer AutoTokenizer.from_pretrained(model_name, trust_remote_codeTrue) model AutoModelForCausalLM.from_pretrained( model_name, torch_dtypetorch.float16, device_mapauto, trust_remote_codeTrue, ) base_prompt ( If a store has 120 apples and sells 45 of them, then receives 30 new apples, how many apples does the store have now? Answer a number only. ) variants { original: base_prompt, upper: base_prompt.upper(), lower: base_prompt.lower(), title: base_prompt.title(), } def ask(prompt: str, max_new_tokens: int 32): messages [ {role: system, content: You are a helpful assistant.}, {role: user, content: prompt}, ] text tokenizer.apply_chat_template( messages, tokenizeFalse, add_generation_promptTrue ) inputs tokenizer(text, return_tensorspt).to(model.device) with torch.no_grad(): outputs model.generate( **inputs, max_new_tokensmax_new_tokens, do_sampleFalse, return_dict_in_generateTrue, output_scoresTrue, ) response tokenizer.decode(outputs.sequences[0][inputs[input_ids].shape[1]:], skip_special_tokensTrue) # 统计生成部分的平均 logprob用于粗略观察置信度 scores torch.stack(outputs.scores, dim0) # [new_tokens, batch, vocab] logprobs torch.log_softmax(scores.float(), dim-1) gen_tokens outputs.sequences[0][inputs[input_ids].shape[1]:] token_logprobs logprobs[range(len(gen_tokens)), 0, gen_tokens] avg_logprob token_logprobs.mean().item() return response.strip(), avg_logprob if __name__ __main__: for name, prompt in variants.items(): answer, avg_lp ask(prompt) print(f {name} ) print(fprompt: {prompt[:80]}...) print(fanswer: {answer}) print(favg_logprob: {avg_lp:.4f}) print()这个脚本在前一个实验的基础上多计算了一个“平均对数概率”。虽然它不能直接等价于模型置信度但可以粗略反映模型在生成答案时输出分布是否集中。一般来说全大写输入会使 Token 序列变得不同因此测试结果会有差异。你可以多跑几道题统计每道题在四种风格下的答案是否一致。如果某个风格能稳定得到正确答案那说明这种风格对这个模型、这个任务确实更友好。4.4 结果整理与可视化实验完成后可以把结果整理到一个 CSV 文件里再用 matplotlib 画个简单的柱状图。限于篇幅这里只展示结果整理的基本思路import csv rows [ {style: original, task: 1, correct: 1, avg_logprob: -0.14}, {style: upper, task: 1, correct: 1, avg_logprob: -0.09}, {style: original, task: 2, correct: 0, avg_logprob: -0.32}, {style: upper, task: 2, correct: 1, avg_logprob: -0.21}, ] with open(results/case_style_results.csv, w, newline) as f: writer csv.DictWriter(f, fieldnames[style, task, correct, avg_logprob]) writer.writeheader() writer.writerows(rows)这里只是示例格式实际实验时你应该把每个任务的真实结果写进去。通过对多道题的统计可以计算每种风格的总准确率再看平均 logprob 是否有明显差异。如果某一种风格在多个任务上都稳定更优才值得进一步关注。5. 常见问题与排查思路下表整理了在复现和工程落地过程中可能遇到的问题。问题现象常见原因解决思路长推理链中模型忘记早期事实注意力资源被中间内容稀释将关键事实放到系统提示词或上下文的开头/结尾在中间步骤中定期“提醒”模型全大写 prompt 在不同任务上效果不稳定不同任务对输出风格敏感度不同不要盲目采用全大写应该对小规模典型任务做对比评测小模型上实验现象不明显小模型推理能力有限生成内容可能不会真正长链展开尝试更大模型或使用更容易诱导长推理的题目模型虽然生成足够长但始终输出同样答案贪心解码导致输出多样性不足在实验中使用num_return_sequences或开启抽样观察多次采样结果API 模型和本地模型结论不一致不同模型的 Tokenizer 和训练数据不同分别记录模型版本、Prompt 模板和采样参数保证可复现6. 工程实践与最佳实践6.1 长推理应用中的上下文保护策略针对“推理时遗忘世界知识”的问题实际工程中可以考虑以下几种保护策略。一是关键信息前置和重复。如果某个事实对整个任务至关重要可以在系统提示词中写一次再在用户消息开头用“请始终记住……”的方式写一次。重复虽然浪费一点 Token但能显著提高模型对事实的召回概率。二是定期“重新锚定”。在长流程 Agent 中可以在每轮工具调用之后把核心约束追加到当前消息中例如“你正在完成的任务是……注意不要违反……”。这相当于每个步骤都给模型一次重新关注早期事实的机会。三是分阶段摘要。当上下文长度增长过快时可以先把历史关键信息压缩成摘要再把摘要放回上下文中。注意摘要需要保留原始约束不能被中间结果带偏。6.2 Prompt 风格统一与格式化关于大小写影响准确率的问题我的建议是在生产系统中不要把用户输入直接拼进 Prompt而是先做一轮格式化。例如英文场景下可以统一问题的标题风格、指令的加粗或大写方式中文场景下虽然大小写不适用但同样要注意标点符号、换行、编号风格的一致性。更重要的是如果你在跑评测集必须保证同一道题的所有对比实验使用相同的 Prompt 模板。否则即使模型能力没有变化评测结果也会因为格式扰动而出现波动。比较规范的做法是把 Prompt 模板纳入版本管理每次改动都记录 diff。6.3 推理监控与可观测性当你在生产环境部署大模型应用时建议对以下指标做监控输出置信度通过 logprob 或采样多样性指标观察模型是否“犹豫”。上下文长度超过一定阈值时触发告警提前处理长上下文。关键事实召回在测试集上定期跑回归检查特定约束是否仍然被遵守。答案稳定性同一 Prompt 多次采样统计答案一致性。这些指标可以帮助你区分“模型能力下降”和“上下文被干扰”这两种情况加快问题定位速度。6.4 安全与合规边界最后提一个很重要的边界涉及生产环境的任何 Prompt 修改、模型版本升级、解码参数调整都应该先在测试环境验证并对历史结果做对比。不要把线上系统当成实验场。对于需要访问私有数据的推理场景还要注意权限隔离和数据最小化避免把无关信息带入上下文增加注意力干扰。7. 下一步学习路线如果这两个现象引起了你的兴趣可以沿着以下路线继续深入。深入理解 Transformer 的注意力机制和 RoPE 位置编码可以从 Hugging Face 的transformers源码入手查看apply_rotary_pos_emb的实现。研究长上下文评测方法例如大海捞针测试、多文档问答评测这些评测可以量化模型的上下文召回能力。关注推理加速与上下文压缩方向例如 KV Cache 优化、上下文剪枝、摘要记忆等。实践 Prompt 评测体系建立一个几十条样本的黄金评测集纳入 CI 流程。坦白说这两个现象背后还有很多未解问题。全大写为什么能让部分模型更“准”长推理中注意力是如何逐步偏离关键事实的这些问题目前还没有统一答案但恰恰说明这个方向还有很多值得探索的空间。对于开发者来说与其相信各种“技巧”不如亲手把实验跑起来用数据判断你的模型在什么条件下更可靠。如果你对实验脚本有什么改进思路或者在自己的项目里遇到过类似现象欢迎在评论区分享。当然动手之前记得确认你的环境、模型版本和依赖版本实验结论会因这些因素而不同。