如果你做大模型应用大概率遇到过这种感觉某个模型回答看起来还算通顺但关键信息总有点“飘”明明给了参考资料它却像没读过一样。问题往往不出在模型参数上而是出在生成过程中的“上下文利用”上。模型在回答时通常只会按当前的概率一路往后写很少回头检查自己到底有没有完全理解输入的关键内容。DeepMind 最近有一项研究方向很直接在推理时把深层激活回灌到输入中可以降低困惑度。这个思路不改变模型权重也不重新训练而是通过调整推理过程本身来提升生成质量。它的价值不仅仅是多了一个学术结论更是在提醒做工程的人大模型质量优化的下一块空间可能不是继续堆参数而是重新设计“推理时计算”的方式。这篇文章会把这件事讲透什么是推理时回灌什么是深层激活什么是困惑度三者为什么能串在一起然后给出普通团队也能参考的工程思路和轻量实验方法。读完你至少能回答一个问题如果我改不动模型能不能用类似思路让生成结果更稳。1. 这篇文章真正要解决的问题大模型生成质量提升过去主要有三条路加数据、加参数、加训练技巧。但到了大模型阶段这三条路都变得很贵。训练一次大模型的成本动辄百万级普通团队根本没有反复试错的机会。于是业界开始把注意力转向另一条路推理时计算。也就是说模型参数不动但生成回答时多花一些计算量让结果更可靠。DeepMind 的研究正是这个方向。它的目标不是“让模型学得更好”而是“让模型在回答时用得更好”。具体手段是把模型在深层计算时生成的激活向量重新注入到推理流程中让模型能够重新“看到”自己已经理解过的信息。这样做的好处很直接模型对输入的把握更稳困惑度下降生成质量随之提升。这篇文章适合三类读者做大模型应用开发的工程师想在不重训模型的前提下提升回答质量。做推理优化、服务部署的人想理解“推理时计算”这条新路和传统加速优化有什么关系。做研究或论文复现的同学想快速搞清困惑度、深度激活、推理时回灌这几个概念之间的关系。一个明确判断放在这里这个方向并不会取代提示词工程或微调但它提供了一种新的视角——把推理过程本身当成一个可优化的对象。这种视角对成本敏感、又希望提升效果的团队尤其有价值。2. 先厘清三个关键词推理、深层激活、困惑度要理解这项工作先要把标题里的三个词拆开。2.1 “推理”在深度学习里有三种含义在 AI 领域“推理”这个词其实很拥挤不同场景下的含义完全不同。先做一个区分避免概念混淆。场景推理的含义典型代表大语言模型生成模型加载权重后根据输入逐 token 生成输出的过程GPT 系列、Llama、DeepSeek计算机视觉部署模型加载权重后对图片做检测、分类、分割的过程YOLO、TensorRT 部署传统符号推理/算法题从前提推导出结论的逻辑过程QBF 推理、图形推理题DeepMind 这篇文章里的“推理”指的是大语言模型的生成阶段。它关注的是当模型已经训练完成进入实际生成回答时能不能通过在生成过程中注入额外信息让结果更好。传统的大模型加速思路例如 TensorRT、vLLM、各种量化方案关注的是“同样的推理过程怎么跑得更快”。而 DeepMind 这个方向关注的是“推理过程本身能不能变得更好”。这是两个不同维度前者是效率维度后者是质量维度。2.2 深层激活是什么一句话解释深层激活就是模型在计算过程中每一层神经网络输出的中间向量也叫隐藏状态。大模型不是一个一步到位的函数而是几十层甚至上百层 Transformer 堆叠而成。输入 token 经过嵌入层变成向量然后逐层经过注意力、前馈网络等模块每一层都会产生新的向量表示。靠近输入的那几层特征相对浅层更多保留词法和局部语法信息靠近输出的那几层特征更抽象更接近“语义理解”的高阶表达。传统推理中这些中间向量是“用完即弃”的它们服务于最终输出但生成下一个 token 时模型并不回头去看自己前面已经算出的深层理解。相关研究把注意力集中在“深层激活”上正是因为它承载了模型对输入语义的高阶理解。如果能把这些语义信号重新利用起来模型在生成时对关键信息的把握就会更准。2.3 困惑度是什么困惑度是衡量语言模型对当前上下文把握程度的指标。通俗地说它表示模型在预测下一个 token 时有多“惊讶”。公式上困惑度是测试集上平均负对数似然的指数形式。数值越低代表模型对当前上下文的预期越稳定数值越高代表模型越不确定生成质量通常也会越差。这里要注意一个细节困惑度低不绝对等于回答正确率高但它和生成质量有很强的相关性。一个模型的困惑度如果显著降低通常意味着它对输入信息的利用更充分生成的连贯性和信息保留度都会更好。这也是用困惑度作为研究指标的原因——它敏感、可量化、能快速反映推理过程的变化。2.4 三个概念如何串联把三个词合成一句话在推理时把模型深层计算出的语义向量回灌到推理流程中使模型下一次生成时能重新利用这些深度理解从而降低预测的不确定性困惑度提升生成质量。如果只看表面很容易误以为这只是某种“特征增强”技巧。但它的本质其实是把模型在预填充阶段已经理解好的信息通过一种额外通道再次送到生成阶段。这相当于让模型在答题时可以反复查看自己刚才的演算草稿而不是只凭记忆一路写下去。3. 回灌深层激活的核心思路让模型在生成时“重读题目”3.1 预填充与解码普通推理的两段式大模型生成回答通常分两个阶段预填充阶段输入 prompt 一次性进入模型模型计算出每个 token 的中间状态生成第一个输出 token。解码阶段每生成一个 token就把新 token 追加到序列尾部继续前向计算直到遇到结束符或达到最大长度。在标准实现中预填充阶段计算的深层激活只服务于那一刻的输出。等模型生成到第 50 个 token 时它早就不“记得”自己在预填充阶段对输入做过怎样的深层理解了。它依赖的只是 KV Cache 里保存的键值对而 KV Cache 是注意力机制的状态缓存并不是完整的高层语义向量。3.2 回灌机制大致怎么运作从方向上看回灌的核心逻辑可以简化成四步模型读取输入完成预填充阶段计算。从某一个或某几个深层取出隐藏状态作为“深层激活”缓存。在后续解码阶段把缓存的高层激活以某种方式重新注入输入序列或注意力计算中。模型生成下一个 token 时同时参考原始输入和回灌的深层语义信息。下面是简化后的伪代码用来理解整个流程的骨架# 伪代码理解激活回灌的概念性流程 def generate_with_activation_feedback(model, tokenizer, prompt, max_new_tokens128): # 1. 预填充阶段 inputs tokenizer(prompt, return_tensorspt) outputs model(**inputs, output_hidden_statesTrue, return_dictTrue) # 2. 取出若干深层的隐藏状态作为语义记忆 deep_activations outputs.hidden_states[-4:] # 假设取最后4层 generated [] current_input inputs[input_ids] for _ in range(max_new_tokens): # 3. 正常前向计算 outputs model( input_idscurrent_input, output_hidden_statesTrue, return_dictTrue ) # 4. 将之前缓存的高层激活与当前深层激活融合 # 实际论文方案会更精细这里只是示意 fused_hidden fuse_hidden_states( outputs.hidden_states[-1], deep_activations[-1] ) # 5. 用融合后的表示预测下一个 token next_token_logits model.lm_head(fused_hidden[:, -1, :]) next_token next_token_logits.argmax(dim-1) generated.append(next_token.item()) # 6. 更新输入序列 current_input torch.cat([current_input, next_token], dim-1) # 7. 如果模型有“重新关注”机制则在这里更新回灌表示 deep_activations maybe_refresh_activations(model, current_input) return tokenizer.decode(generated)注意这是概念性伪代码真实论文中的实现方式可能更复杂例如通过额外的交叉注意力模块、可学习的融合权重、或特定层级的残差连接来实现。但核心思想是一致的把深层语义作为额外的上下文信号重新参与生成过程。3.3 为什么回灌能降低困惑度从直觉和已有研究来看回灌深层激活能降困惑度可能来自几个机制第一减少信息衰减。长输入中早期 token 经过多层注意力后对最终预测的影响可能被稀释。深层激活直接携带“模型早期理解好的语义”回灌后相当于绕过了长距离衰减。第二提供稳定的语义锚点。生成过程中模型每走一步都会产生新的上下文而新生成的 token 不一定完全可靠。如果把深层激活作为稳定的参考信号模型在预测时就不会被之前的错误生成带偏。第三强化关键 token 的注意权重。有些关键信息虽然在 prompt 里但模型可能“看过就忘”。回灌深层激活相当于把这些信息推到模型面前让注意力更容易对准关键部分。3.4 这个思路和提示词工程、CoT 的关系提示词工程是“在输入层面让模型发挥更好”例如把问题拆解成步骤、加入“请参考以下资料”。这种方法不需要改模型但能力有限——模型对长输入尾部或细微语义的把握并不会因为提示词更详细而稳定提升。CoT思维链是通过让模型先输出推理过程再给出答案相当于用“外部展示”逼着模型多算几步。回灌深层激活则不同它是在“内部计算”层面直接改变模型的上下文利用方式。两者可以叠加使用。更稳妥的判断是回灌是一种比提示词工程更底层、比微调更轻量的优化手段。它不需要改变模型参数但需要改变推理时模型的计算路径。这意味着它更适合服务端集中部署场景而不是端侧轻量化场景。4. 从研究论文到工程实践普通团队能借鉴什么DeepMind 的方案如果要全面落地大概率需要改造模型结构和推理框架普通团队短期未必能做到。但重要的是背后的思路可以迁移到许多工程场景。4.1 思路迁移一显式“重读”式提示词设计既然模型容易“看过就忘”那就让输入序列里被遗忘的关键信息反复出现。在构造 prompt 时可以设计“先引用、再回答”的结构。# 工程近似方案通过 prompt 结构实现“重读”逻辑 prompt_template 下面是一段参考资料以及一个需要回答的问题。 请先完成以下两步 第一步用不超过三句话总结参考资料中的关键事实。 第二步基于你的总结回答用户的问题。 参考资料 {context} 用户问题 {question} 你的总结 def build_repetitive_prompt(context: str, question: str) - str: return prompt_template.format(contextcontext, questionquestion)这样做的原理是强制模型输出总结时它必须先把注意力和深层语义集中到关键内容上后续生成回答时这份总结作为新生成的 token 出现在上下文中等于给了模型一个“由自己写出的压缩记忆”。这种写法不会像真实回灌那样修改模型内部计算但它借鉴了同一个核心思想让模型在生成时重新访问已经理解过的关键信息。4.2 思路迁移二关键上下文增强在实际项目中很多应用会在 prompt 中放入额外资料比如 RAG 检索结果。回灌思路带来的启发是不能只是把资料拼在 prompt 里还要想办法让模型知道哪些内容最重要。一个可行的做法是在相关资料前加上一个“重要性标记”例如参考资料以下第 2 段是本问题的核心依据 1. ... 2. 协议要求发票金额必须为含税总金额且需在三个工作日内确认。 3. ...虽然这是很朴素的提示词手段但它至少让模型在注意力分配时更有方向。更进一步可以使用特殊的 marker token 或在 embedding 层对关键文本做加权。这些都是“让深层语义更容易被模型抓住”的工程化尝试。4.3 思路迁移三检索 重述的推理策略另一种更接近回灌精神的做法是先生成一次“摘要/重述”再把重述结果拼回输入继续生成最终答案。这相当于在推理过程中把模型对输入的深层理解显式化再让模型基于这份理解继续工作。def generate_with_restatement(model, tokenizer, context, question): # 第一遍推理生成对关键事实的重述 first_prompt f请总结下面资料中的关键信息\n{context} restatement model.generate( **tokenizer(first_prompt, return_tensorspt), max_new_tokens128 ) restatement_text tokenizer.decode(restatement[0], skip_special_tokensTrue) # 第二遍推理基于重述结果生成最终答案 final_prompt f关键信息\n{restatement_text}\n\n问题{question} final_answer model.generate( **tokenizer(final_prompt, return_tensorspt), max_new_tokens256 ) return tokenizer.decode(final_answer[0], skip_special_tokensTrue)这种两遍推理策略是在不修改模型的前提下最接近“回灌”思想的工程实现。代价是生成时间变长收益是模型对上下文关键信息的把握更稳。4.4 什么时候用回灌思路什么时候别用回灌思路不是万能的。这里给出一个简单的适用性判断场景是否推荐回灌思路原因长文档问答关键信息散落多处推荐能显著减少关键信息被忽略的情况多轮对话上下文很长推荐能缓解早期信息被后续对话冲淡的问题短问题、高吞吐服务不推荐成本和延迟增加收益不明显延迟敏感型实时应用谨慎回灌和两遍推理都会增加响应时间端侧模型部署不推荐算力和内存受限深层激活缓存开销较大5. 用开源工具做轻量验证回灌思路的近似实验如果你没有条件修改模型结构又想验证“增强上下文信号能否降低困惑度”可以用开源工具做一个近似实验。实验的目的不是复现 DeepMind而是验证一个基础假设当模型在生成时获得关键信息的强化后困惑度是否显著下降。5.1 实验脚本对比不同上下文形式下的困惑度下面是一个基于 Hugging Face Transformers 的轻量对比脚本。# 文件路径evaluate_perplexity.py import math import torch from transformers import AutoTokenizer, AutoModelForCausalLM # 模型可根据实际条件选择例如 Qwen2.5-1.5B-Instruct MODEL_NAME Qwen/Qwen2.5-1.5B-Instruct tokenizer AutoTokenizer.from_pretrained(MODEL_NAME) model AutoModelForCausalLM.from_pretrained( MODEL_NAME, torch_dtypetorch.float16, device_mapauto ) model.eval() def compute_perplexity(text: str) - float: 计算一段文本的困惑度。 encodings tokenizer(text, return_tensorspt).to(model.device) input_ids encodings.input_ids with torch.no_grad(): outputs model(input_ids, labelsinput_ids) loss outputs.loss return math.exp(loss.item()) if __name__ __main__: original_context 项目合同规定设备验收合格后 15 个工作日内甲方应向乙方支付合同总金额的 90% 剩余 10% 为质保金在质保期满一年后支付。 question 甲方什么时候支付质保金 normal_prompt f{original_context}\n\n问题{question} strong_prompt ( f参考资料\n{original_context}\n f请特别注意质保金的支付条件是质保期满一年后。\n f问题{question} ) print(普通提示词困惑度:, compute_perplexity(normal_prompt)) print(强化提示词困惑度:, compute_perplexity(strong_prompt))运行方式pip install torch transformers accelerate python evaluate_perplexity.py这个脚本的逻辑很简单计算完整 prompt 的困惑度对比普通拼接和强化关键信息两种形式。如果“强化提示词”的困惑度明显更低说明关键信息被显式强调后模型的预测更稳定。这可以作为“回灌思路”的工程近似验证。5.2 模拟“回灌”的伪代码逻辑如果你想在研究层面加深理解可以基于上一节的伪代码扩展把它改造成一个可以跑通的最小实验框架。重点不是融合方式多么精确而是观察“把深层激活重新参与计算后困惑度是否下降”。# 文件路径feedback_demo.py # 注意这是一个结构演示脚本实际部署需要配合框架层的钩子定制。 from dataclasses import dataclass dataclass class ActivationsBuffer: 保存深层激活的缓冲区。 hidden_states: list None def save(self, hidden_states): self.hidden_states hidden_states def retrieve(self): return self.hidden_states def fuse_hidden_states(current_hidden, past_deep_hidden, alpha0.1): 概念性融合函数当前激活 过去深层激活的加权混合。 return current_hidden alpha * past_deep_hidden class FeedbackInferenceLoop: 一个演示“回灌”思想的推理循环外壳。 def __init__(self, model, alpha0.1): self.model model self.alpha alpha self.buffer ActivationsBuffer() def generate_token(self, input_ids, cacheNone): outputs self.model( input_idsinput_ids, past_key_valuescache, output_hidden_statesTrue, return_dictTrue ) # 取出最后一层的隐藏状态 last_hidden outputs.hidden_states[-1] # 如果缓冲区已有深层激活则进行融合 past_deep self.buffer.retrieve() if past_deep is not None: fused fuse_hidden_states( last_hidden, past_deep, alphaself.alpha ) else: fused last_hidden # 更新缓冲区每次生成后用当前深层激活覆盖 self.buffer.save(last_hidden) next_token_logits self.model.lm_head(fused[:, -1, :]) next_token next_token_logits.argmax(dim-1, keepdimTrue) return next_token, outputs.past_key_values这段代码有两个作用一是帮你理解回灌的基本实现结构二是为后续接入真实框架提供一个模板思路。实际工程中你需要把它接入 transformers 的generate流程中或者使用支持自定义钩子的推理框架。DeepMind 的论文如果公开了更精确的实现细节再按论文收敛即可。5.3 实际使用时的工程化改造建议用上面的脚本跑通概念后如果要用于真实项目需要考虑几个工程问题需要接入框架层而不是在 Python 层循环生成 token。直接在 Python 层逐 token 生成速度会很慢。需要控制深层激活缓存的大小。保存多层激活会显著增加显存占用。融合方式需要实验调优。是直接加还是拼接是只取最后一层还是取多层都需要实验确定。要与 KV Cache 配合。实际推理中省略 KV Cache 的实现只能用于演示。6. 运行结果与效果验证6.1 运行方式执行困惑度对比脚本时命令如下python evaluate_perplexity.py如果显存不足可以换更小的模型比如Qwen/Qwen2.5-0.5B-Instruct或把torch.float16改为torch.float32。6.2 预期输出与判断标准正常输出类似普通提示词困惑度: 23.45 强化提示词困惑度: 18.12判断标准很简单强化提示词的困惑度如果显著低于普通提示词说明“关键信息显式强化”方向有效。如果两者差异很小可能是模型较小、对语义不敏感或者测试文本本身不依赖长距离信息。这里要提醒一点困惑度下降是“必要不充分”条件。它说明模型对上下文的把握更稳定了但不代表业务指标一定提升。更完整的实验应该同时看回答的正确率或关键信息召回率。6.3 日志与指标可观测性在做这类实验时建议记录以下几类信息模型名称和版本。输入文本长度。是否使用了强化/重述策略。困惑度、生成延迟、显存占用。最终回答是否命中关键信息。这样方便横向对比也方便后续做回归测试。6.4 如果失败第一步排查什么如果实验结果不符合预期优先检查以下三点模型是否加载了正确的 dtypefloat16 精度下某些流程可能不严谨。输入是否过短短文本的困惑度差异本来就小。强化信息是否真的“强化”了如果只在 prompt 里重复了一遍普通表达并不足以让模型重视关键信息。7. 常见问题与排查思路问题现象可能原因排查方式解决方案运行脚本时显存不足模型过大或 batch 维度过高查看 GPU 显存占用换更小模型或使用device_mapauto困惑度数值为 NaN输入有问题或模型精度异常检查输入编码和损失值改用 fp32 重试强化提示词困惑度反而更高强化方式破坏了语义对比输出 logits 分布调整强化表达避免增加无关信息伪代码回灌生成速度极慢Python 层逐 token 循环查看 CPU/GPU 利用率改用支持自定义钩子的推理框架生成结果与困惑度不符困惑度是宏观指标人工检查关键信息召回增加业务相关评测集部署时显存占用飙升保存过多深层激活监控显存曲线只保存最后一层或两层激活8. 最佳实践与工程建议8.1 在成本与质量之间找平衡回灌思路的本质是“用推理时计算换生成质量”。它意味着更长的延迟、更高的显存消耗。在实际项目中建议对不同的用户请求做分级处理普通问题走标准推理复杂长文档问题走回灌或两遍推理路径。这种分级策略比“一刀切”更划算。8.2 与 KV Cache 和长上下文配合回灌与 KV Cache 并不冲突两者关注的计算阶段不同。KV Cache 解决的是“解码阶段避免重复计算历史 token”回灌解决的是“深层语义没有重新参与计算”。在推理框架层可以先缓存关键输入的深层激活在解码阶段做轻量融合。这样能减少重复计算开销又能获得语义强化的收益。8.3 建立完整的评估体系不建议只依赖困惑度做决策。一个更稳的评估体系应该包含三层模型层困惑度、生成稳定性指标。任务层关键信息召回率、回答正确率。业务层用户满意度、客服从答率、转化率。只有三层指标都对应得上才能确认这项技术真的对项目有价值。8.4 落地前的最小验证清单如果你计划在项目中借鉴回灌思路建议先按这个顺序做验证用评估脚本确认关键信息强化后困惑度确实下降。用两条标注样例检查生成质量是否提升。跑一个 50 条样本的小数据集量化收益。测量添加回灌/两遍推理后的延迟和显存变化。确认收益大于成本后再进入框架层改造。9. 总结与后续学习方向DeepMind 的这项研究真正值得关注的地方不是“困惑度降了多少”而是它指出了一条新路在模型权重不变的前提下通过改变推理时的信息流让生成质量变得更好。这条路的背后是大模型优化重心从“训练时”向“推理时”迁移的趋势。对普通开发者来说即使暂时无法完整复现 DeepMind 的方案也可以从三个方向入手用困惑度评估脚本量化自己项目中的 prompt 和信息增强是否有效。尝试“重述式”推理用两遍生成改善长文档回答质量。关注主流推理框架如 vLLM、TensorRT-LLM未来对“推理时计算”扩展的支持一旦底层支持工程落地的成本会大幅下降。如果你对这个方向感兴趣下一步可以深入研究三个主题隐藏状态的融合方式如何影响注意力分布、推理时计算与传统模型加速如何共存、以及迁移到多模态模型时深度激活回灌是否同样有效。
如果你做大模型应用大概率遇到过这种感觉某个模型回答看起来还算通顺但关键信息总有点“飘”明明给了参考资料它却像没读过一样。问题往往不出在模型参数上而是出在生成过程中的“上下文利用”上。模型在回答时通常只会按当前的概率一路往后写很少回头检查自己到底有没有完全理解输入的关键内容。DeepMind 最近有一项研究方向很直接在推理时把深层激活回灌到输入中可以降低困惑度。这个思路不改变模型权重也不重新训练而是通过调整推理过程本身来提升生成质量。它的价值不仅仅是多了一个学术结论更是在提醒做工程的人大模型质量优化的下一块空间可能不是继续堆参数而是重新设计“推理时计算”的方式。这篇文章会把这件事讲透什么是推理时回灌什么是深层激活什么是困惑度三者为什么能串在一起然后给出普通团队也能参考的工程思路和轻量实验方法。读完你至少能回答一个问题如果我改不动模型能不能用类似思路让生成结果更稳。1. 这篇文章真正要解决的问题大模型生成质量提升过去主要有三条路加数据、加参数、加训练技巧。但到了大模型阶段这三条路都变得很贵。训练一次大模型的成本动辄百万级普通团队根本没有反复试错的机会。于是业界开始把注意力转向另一条路推理时计算。也就是说模型参数不动但生成回答时多花一些计算量让结果更可靠。DeepMind 的研究正是这个方向。它的目标不是“让模型学得更好”而是“让模型在回答时用得更好”。具体手段是把模型在深层计算时生成的激活向量重新注入到推理流程中让模型能够重新“看到”自己已经理解过的信息。这样做的好处很直接模型对输入的把握更稳困惑度下降生成质量随之提升。这篇文章适合三类读者做大模型应用开发的工程师想在不重训模型的前提下提升回答质量。做推理优化、服务部署的人想理解“推理时计算”这条新路和传统加速优化有什么关系。做研究或论文复现的同学想快速搞清困惑度、深度激活、推理时回灌这几个概念之间的关系。一个明确判断放在这里这个方向并不会取代提示词工程或微调但它提供了一种新的视角——把推理过程本身当成一个可优化的对象。这种视角对成本敏感、又希望提升效果的团队尤其有价值。2. 先厘清三个关键词推理、深层激活、困惑度要理解这项工作先要把标题里的三个词拆开。2.1 “推理”在深度学习里有三种含义在 AI 领域“推理”这个词其实很拥挤不同场景下的含义完全不同。先做一个区分避免概念混淆。场景推理的含义典型代表大语言模型生成模型加载权重后根据输入逐 token 生成输出的过程GPT 系列、Llama、DeepSeek计算机视觉部署模型加载权重后对图片做检测、分类、分割的过程YOLO、TensorRT 部署传统符号推理/算法题从前提推导出结论的逻辑过程QBF 推理、图形推理题DeepMind 这篇文章里的“推理”指的是大语言模型的生成阶段。它关注的是当模型已经训练完成进入实际生成回答时能不能通过在生成过程中注入额外信息让结果更好。传统的大模型加速思路例如 TensorRT、vLLM、各种量化方案关注的是“同样的推理过程怎么跑得更快”。而 DeepMind 这个方向关注的是“推理过程本身能不能变得更好”。这是两个不同维度前者是效率维度后者是质量维度。2.2 深层激活是什么一句话解释深层激活就是模型在计算过程中每一层神经网络输出的中间向量也叫隐藏状态。大模型不是一个一步到位的函数而是几十层甚至上百层 Transformer 堆叠而成。输入 token 经过嵌入层变成向量然后逐层经过注意力、前馈网络等模块每一层都会产生新的向量表示。靠近输入的那几层特征相对浅层更多保留词法和局部语法信息靠近输出的那几层特征更抽象更接近“语义理解”的高阶表达。传统推理中这些中间向量是“用完即弃”的它们服务于最终输出但生成下一个 token 时模型并不回头去看自己前面已经算出的深层理解。相关研究把注意力集中在“深层激活”上正是因为它承载了模型对输入语义的高阶理解。如果能把这些语义信号重新利用起来模型在生成时对关键信息的把握就会更准。2.3 困惑度是什么困惑度是衡量语言模型对当前上下文把握程度的指标。通俗地说它表示模型在预测下一个 token 时有多“惊讶”。公式上困惑度是测试集上平均负对数似然的指数形式。数值越低代表模型对当前上下文的预期越稳定数值越高代表模型越不确定生成质量通常也会越差。这里要注意一个细节困惑度低不绝对等于回答正确率高但它和生成质量有很强的相关性。一个模型的困惑度如果显著降低通常意味着它对输入信息的利用更充分生成的连贯性和信息保留度都会更好。这也是用困惑度作为研究指标的原因——它敏感、可量化、能快速反映推理过程的变化。2.4 三个概念如何串联把三个词合成一句话在推理时把模型深层计算出的语义向量回灌到推理流程中使模型下一次生成时能重新利用这些深度理解从而降低预测的不确定性困惑度提升生成质量。如果只看表面很容易误以为这只是某种“特征增强”技巧。但它的本质其实是把模型在预填充阶段已经理解好的信息通过一种额外通道再次送到生成阶段。这相当于让模型在答题时可以反复查看自己刚才的演算草稿而不是只凭记忆一路写下去。3. 回灌深层激活的核心思路让模型在生成时“重读题目”3.1 预填充与解码普通推理的两段式大模型生成回答通常分两个阶段预填充阶段输入 prompt 一次性进入模型模型计算出每个 token 的中间状态生成第一个输出 token。解码阶段每生成一个 token就把新 token 追加到序列尾部继续前向计算直到遇到结束符或达到最大长度。在标准实现中预填充阶段计算的深层激活只服务于那一刻的输出。等模型生成到第 50 个 token 时它早就不“记得”自己在预填充阶段对输入做过怎样的深层理解了。它依赖的只是 KV Cache 里保存的键值对而 KV Cache 是注意力机制的状态缓存并不是完整的高层语义向量。3.2 回灌机制大致怎么运作从方向上看回灌的核心逻辑可以简化成四步模型读取输入完成预填充阶段计算。从某一个或某几个深层取出隐藏状态作为“深层激活”缓存。在后续解码阶段把缓存的高层激活以某种方式重新注入输入序列或注意力计算中。模型生成下一个 token 时同时参考原始输入和回灌的深层语义信息。下面是简化后的伪代码用来理解整个流程的骨架# 伪代码理解激活回灌的概念性流程 def generate_with_activation_feedback(model, tokenizer, prompt, max_new_tokens128): # 1. 预填充阶段 inputs tokenizer(prompt, return_tensorspt) outputs model(**inputs, output_hidden_statesTrue, return_dictTrue) # 2. 取出若干深层的隐藏状态作为语义记忆 deep_activations outputs.hidden_states[-4:] # 假设取最后4层 generated [] current_input inputs[input_ids] for _ in range(max_new_tokens): # 3. 正常前向计算 outputs model( input_idscurrent_input, output_hidden_statesTrue, return_dictTrue ) # 4. 将之前缓存的高层激活与当前深层激活融合 # 实际论文方案会更精细这里只是示意 fused_hidden fuse_hidden_states( outputs.hidden_states[-1], deep_activations[-1] ) # 5. 用融合后的表示预测下一个 token next_token_logits model.lm_head(fused_hidden[:, -1, :]) next_token next_token_logits.argmax(dim-1) generated.append(next_token.item()) # 6. 更新输入序列 current_input torch.cat([current_input, next_token], dim-1) # 7. 如果模型有“重新关注”机制则在这里更新回灌表示 deep_activations maybe_refresh_activations(model, current_input) return tokenizer.decode(generated)注意这是概念性伪代码真实论文中的实现方式可能更复杂例如通过额外的交叉注意力模块、可学习的融合权重、或特定层级的残差连接来实现。但核心思想是一致的把深层语义作为额外的上下文信号重新参与生成过程。3.3 为什么回灌能降低困惑度从直觉和已有研究来看回灌深层激活能降困惑度可能来自几个机制第一减少信息衰减。长输入中早期 token 经过多层注意力后对最终预测的影响可能被稀释。深层激活直接携带“模型早期理解好的语义”回灌后相当于绕过了长距离衰减。第二提供稳定的语义锚点。生成过程中模型每走一步都会产生新的上下文而新生成的 token 不一定完全可靠。如果把深层激活作为稳定的参考信号模型在预测时就不会被之前的错误生成带偏。第三强化关键 token 的注意权重。有些关键信息虽然在 prompt 里但模型可能“看过就忘”。回灌深层激活相当于把这些信息推到模型面前让注意力更容易对准关键部分。3.4 这个思路和提示词工程、CoT 的关系提示词工程是“在输入层面让模型发挥更好”例如把问题拆解成步骤、加入“请参考以下资料”。这种方法不需要改模型但能力有限——模型对长输入尾部或细微语义的把握并不会因为提示词更详细而稳定提升。CoT思维链是通过让模型先输出推理过程再给出答案相当于用“外部展示”逼着模型多算几步。回灌深层激活则不同它是在“内部计算”层面直接改变模型的上下文利用方式。两者可以叠加使用。更稳妥的判断是回灌是一种比提示词工程更底层、比微调更轻量的优化手段。它不需要改变模型参数但需要改变推理时模型的计算路径。这意味着它更适合服务端集中部署场景而不是端侧轻量化场景。4. 从研究论文到工程实践普通团队能借鉴什么DeepMind 的方案如果要全面落地大概率需要改造模型结构和推理框架普通团队短期未必能做到。但重要的是背后的思路可以迁移到许多工程场景。4.1 思路迁移一显式“重读”式提示词设计既然模型容易“看过就忘”那就让输入序列里被遗忘的关键信息反复出现。在构造 prompt 时可以设计“先引用、再回答”的结构。# 工程近似方案通过 prompt 结构实现“重读”逻辑 prompt_template 下面是一段参考资料以及一个需要回答的问题。 请先完成以下两步 第一步用不超过三句话总结参考资料中的关键事实。 第二步基于你的总结回答用户的问题。 参考资料 {context} 用户问题 {question} 你的总结 def build_repetitive_prompt(context: str, question: str) - str: return prompt_template.format(contextcontext, questionquestion)这样做的原理是强制模型输出总结时它必须先把注意力和深层语义集中到关键内容上后续生成回答时这份总结作为新生成的 token 出现在上下文中等于给了模型一个“由自己写出的压缩记忆”。这种写法不会像真实回灌那样修改模型内部计算但它借鉴了同一个核心思想让模型在生成时重新访问已经理解过的关键信息。4.2 思路迁移二关键上下文增强在实际项目中很多应用会在 prompt 中放入额外资料比如 RAG 检索结果。回灌思路带来的启发是不能只是把资料拼在 prompt 里还要想办法让模型知道哪些内容最重要。一个可行的做法是在相关资料前加上一个“重要性标记”例如参考资料以下第 2 段是本问题的核心依据 1. ... 2. 协议要求发票金额必须为含税总金额且需在三个工作日内确认。 3. ...虽然这是很朴素的提示词手段但它至少让模型在注意力分配时更有方向。更进一步可以使用特殊的 marker token 或在 embedding 层对关键文本做加权。这些都是“让深层语义更容易被模型抓住”的工程化尝试。4.3 思路迁移三检索 重述的推理策略另一种更接近回灌精神的做法是先生成一次“摘要/重述”再把重述结果拼回输入继续生成最终答案。这相当于在推理过程中把模型对输入的深层理解显式化再让模型基于这份理解继续工作。def generate_with_restatement(model, tokenizer, context, question): # 第一遍推理生成对关键事实的重述 first_prompt f请总结下面资料中的关键信息\n{context} restatement model.generate( **tokenizer(first_prompt, return_tensorspt), max_new_tokens128 ) restatement_text tokenizer.decode(restatement[0], skip_special_tokensTrue) # 第二遍推理基于重述结果生成最终答案 final_prompt f关键信息\n{restatement_text}\n\n问题{question} final_answer model.generate( **tokenizer(final_prompt, return_tensorspt), max_new_tokens256 ) return tokenizer.decode(final_answer[0], skip_special_tokensTrue)这种两遍推理策略是在不修改模型的前提下最接近“回灌”思想的工程实现。代价是生成时间变长收益是模型对上下文关键信息的把握更稳。4.4 什么时候用回灌思路什么时候别用回灌思路不是万能的。这里给出一个简单的适用性判断场景是否推荐回灌思路原因长文档问答关键信息散落多处推荐能显著减少关键信息被忽略的情况多轮对话上下文很长推荐能缓解早期信息被后续对话冲淡的问题短问题、高吞吐服务不推荐成本和延迟增加收益不明显延迟敏感型实时应用谨慎回灌和两遍推理都会增加响应时间端侧模型部署不推荐算力和内存受限深层激活缓存开销较大5. 用开源工具做轻量验证回灌思路的近似实验如果你没有条件修改模型结构又想验证“增强上下文信号能否降低困惑度”可以用开源工具做一个近似实验。实验的目的不是复现 DeepMind而是验证一个基础假设当模型在生成时获得关键信息的强化后困惑度是否显著下降。5.1 实验脚本对比不同上下文形式下的困惑度下面是一个基于 Hugging Face Transformers 的轻量对比脚本。# 文件路径evaluate_perplexity.py import math import torch from transformers import AutoTokenizer, AutoModelForCausalLM # 模型可根据实际条件选择例如 Qwen2.5-1.5B-Instruct MODEL_NAME Qwen/Qwen2.5-1.5B-Instruct tokenizer AutoTokenizer.from_pretrained(MODEL_NAME) model AutoModelForCausalLM.from_pretrained( MODEL_NAME, torch_dtypetorch.float16, device_mapauto ) model.eval() def compute_perplexity(text: str) - float: 计算一段文本的困惑度。 encodings tokenizer(text, return_tensorspt).to(model.device) input_ids encodings.input_ids with torch.no_grad(): outputs model(input_ids, labelsinput_ids) loss outputs.loss return math.exp(loss.item()) if __name__ __main__: original_context 项目合同规定设备验收合格后 15 个工作日内甲方应向乙方支付合同总金额的 90% 剩余 10% 为质保金在质保期满一年后支付。 question 甲方什么时候支付质保金 normal_prompt f{original_context}\n\n问题{question} strong_prompt ( f参考资料\n{original_context}\n f请特别注意质保金的支付条件是质保期满一年后。\n f问题{question} ) print(普通提示词困惑度:, compute_perplexity(normal_prompt)) print(强化提示词困惑度:, compute_perplexity(strong_prompt))运行方式pip install torch transformers accelerate python evaluate_perplexity.py这个脚本的逻辑很简单计算完整 prompt 的困惑度对比普通拼接和强化关键信息两种形式。如果“强化提示词”的困惑度明显更低说明关键信息被显式强调后模型的预测更稳定。这可以作为“回灌思路”的工程近似验证。5.2 模拟“回灌”的伪代码逻辑如果你想在研究层面加深理解可以基于上一节的伪代码扩展把它改造成一个可以跑通的最小实验框架。重点不是融合方式多么精确而是观察“把深层激活重新参与计算后困惑度是否下降”。# 文件路径feedback_demo.py # 注意这是一个结构演示脚本实际部署需要配合框架层的钩子定制。 from dataclasses import dataclass dataclass class ActivationsBuffer: 保存深层激活的缓冲区。 hidden_states: list None def save(self, hidden_states): self.hidden_states hidden_states def retrieve(self): return self.hidden_states def fuse_hidden_states(current_hidden, past_deep_hidden, alpha0.1): 概念性融合函数当前激活 过去深层激活的加权混合。 return current_hidden alpha * past_deep_hidden class FeedbackInferenceLoop: 一个演示“回灌”思想的推理循环外壳。 def __init__(self, model, alpha0.1): self.model model self.alpha alpha self.buffer ActivationsBuffer() def generate_token(self, input_ids, cacheNone): outputs self.model( input_idsinput_ids, past_key_valuescache, output_hidden_statesTrue, return_dictTrue ) # 取出最后一层的隐藏状态 last_hidden outputs.hidden_states[-1] # 如果缓冲区已有深层激活则进行融合 past_deep self.buffer.retrieve() if past_deep is not None: fused fuse_hidden_states( last_hidden, past_deep, alphaself.alpha ) else: fused last_hidden # 更新缓冲区每次生成后用当前深层激活覆盖 self.buffer.save(last_hidden) next_token_logits self.model.lm_head(fused[:, -1, :]) next_token next_token_logits.argmax(dim-1, keepdimTrue) return next_token, outputs.past_key_values这段代码有两个作用一是帮你理解回灌的基本实现结构二是为后续接入真实框架提供一个模板思路。实际工程中你需要把它接入 transformers 的generate流程中或者使用支持自定义钩子的推理框架。DeepMind 的论文如果公开了更精确的实现细节再按论文收敛即可。5.3 实际使用时的工程化改造建议用上面的脚本跑通概念后如果要用于真实项目需要考虑几个工程问题需要接入框架层而不是在 Python 层循环生成 token。直接在 Python 层逐 token 生成速度会很慢。需要控制深层激活缓存的大小。保存多层激活会显著增加显存占用。融合方式需要实验调优。是直接加还是拼接是只取最后一层还是取多层都需要实验确定。要与 KV Cache 配合。实际推理中省略 KV Cache 的实现只能用于演示。6. 运行结果与效果验证6.1 运行方式执行困惑度对比脚本时命令如下python evaluate_perplexity.py如果显存不足可以换更小的模型比如Qwen/Qwen2.5-0.5B-Instruct或把torch.float16改为torch.float32。6.2 预期输出与判断标准正常输出类似普通提示词困惑度: 23.45 强化提示词困惑度: 18.12判断标准很简单强化提示词的困惑度如果显著低于普通提示词说明“关键信息显式强化”方向有效。如果两者差异很小可能是模型较小、对语义不敏感或者测试文本本身不依赖长距离信息。这里要提醒一点困惑度下降是“必要不充分”条件。它说明模型对上下文的把握更稳定了但不代表业务指标一定提升。更完整的实验应该同时看回答的正确率或关键信息召回率。6.3 日志与指标可观测性在做这类实验时建议记录以下几类信息模型名称和版本。输入文本长度。是否使用了强化/重述策略。困惑度、生成延迟、显存占用。最终回答是否命中关键信息。这样方便横向对比也方便后续做回归测试。6.4 如果失败第一步排查什么如果实验结果不符合预期优先检查以下三点模型是否加载了正确的 dtypefloat16 精度下某些流程可能不严谨。输入是否过短短文本的困惑度差异本来就小。强化信息是否真的“强化”了如果只在 prompt 里重复了一遍普通表达并不足以让模型重视关键信息。7. 常见问题与排查思路问题现象可能原因排查方式解决方案运行脚本时显存不足模型过大或 batch 维度过高查看 GPU 显存占用换更小模型或使用device_mapauto困惑度数值为 NaN输入有问题或模型精度异常检查输入编码和损失值改用 fp32 重试强化提示词困惑度反而更高强化方式破坏了语义对比输出 logits 分布调整强化表达避免增加无关信息伪代码回灌生成速度极慢Python 层逐 token 循环查看 CPU/GPU 利用率改用支持自定义钩子的推理框架生成结果与困惑度不符困惑度是宏观指标人工检查关键信息召回增加业务相关评测集部署时显存占用飙升保存过多深层激活监控显存曲线只保存最后一层或两层激活8. 最佳实践与工程建议8.1 在成本与质量之间找平衡回灌思路的本质是“用推理时计算换生成质量”。它意味着更长的延迟、更高的显存消耗。在实际项目中建议对不同的用户请求做分级处理普通问题走标准推理复杂长文档问题走回灌或两遍推理路径。这种分级策略比“一刀切”更划算。8.2 与 KV Cache 和长上下文配合回灌与 KV Cache 并不冲突两者关注的计算阶段不同。KV Cache 解决的是“解码阶段避免重复计算历史 token”回灌解决的是“深层语义没有重新参与计算”。在推理框架层可以先缓存关键输入的深层激活在解码阶段做轻量融合。这样能减少重复计算开销又能获得语义强化的收益。8.3 建立完整的评估体系不建议只依赖困惑度做决策。一个更稳的评估体系应该包含三层模型层困惑度、生成稳定性指标。任务层关键信息召回率、回答正确率。业务层用户满意度、客服从答率、转化率。只有三层指标都对应得上才能确认这项技术真的对项目有价值。8.4 落地前的最小验证清单如果你计划在项目中借鉴回灌思路建议先按这个顺序做验证用评估脚本确认关键信息强化后困惑度确实下降。用两条标注样例检查生成质量是否提升。跑一个 50 条样本的小数据集量化收益。测量添加回灌/两遍推理后的延迟和显存变化。确认收益大于成本后再进入框架层改造。9. 总结与后续学习方向DeepMind 的这项研究真正值得关注的地方不是“困惑度降了多少”而是它指出了一条新路在模型权重不变的前提下通过改变推理时的信息流让生成质量变得更好。这条路的背后是大模型优化重心从“训练时”向“推理时”迁移的趋势。对普通开发者来说即使暂时无法完整复现 DeepMind 的方案也可以从三个方向入手用困惑度评估脚本量化自己项目中的 prompt 和信息增强是否有效。尝试“重述式”推理用两遍生成改善长文档回答质量。关注主流推理框架如 vLLM、TensorRT-LLM未来对“推理时计算”扩展的支持一旦底层支持工程落地的成本会大幅下降。如果你对这个方向感兴趣下一步可以深入研究三个主题隐藏状态的融合方式如何影响注意力分布、推理时计算与传统模型加速如何共存、以及迁移到多模态模型时深度激活回灌是否同样有效。
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
