从模型视角看上下文工程

🎣从模型视角看上下文工程

type

status

date

slug

summary

从模型视角看上下文工程

模型训练完成后固定的参数

训练完的 Transformer 其实已经“死”了。

所有权重、所有偏置、所有 LayerNorm 的 γ/β、词表 embedding、输出头的投影矩阵……全部冻结，再也不会变了。

从这一刻起，它不再是一个学习机器，而变成了一个极其巨大、极其复杂的静态函数：

输入一段向量序列 → 输出下一个位置的 token 概率分布。

剩下的所有“智能”，本质上都来自于：

这个静态函数本身有多强（训练决定了上限）

你到底喂给它什么样的向量序列（上下文工程决定了实际发挥）

推理的过程

假设模型已经生成了 N−1 个 Token，现在它将利用这 N−1 个 Token 作为上下文，来预测第 N 个 Token。模型实际在做：

把前面 1~t-1 个 token 全部 embed + 加 positional encoding

通过固定的 Wq/Wk/Wv 得到 Q/K/V

当前 token 的 Q 跟前面所有 token 的 K 做点积 → 算注意力权重

用这些权重对前面所有 token 的 V 加权求和 → 得到当前位置的 attention 输出

再经过若干层 FFN + 残差 + norm 不断变换

最后到输出头 → 打分整个词表 → softmax（或各种采样方式）

真正决定“模型此时此刻在想什么”的，是当前这一步里，所有历史 token 的 K 和 V 到底长什么样。

而 K 和 V 来自哪里？

→ 来自你喂进去的全部上下文（包括 system prompt、user 历史、assistant 历史、这次的问题、你塞进去的任何参考资料、格式要求、思考链示例……）

换句话说：

Prompt → 主要通过影响 Q 的走向，决定模型“以什么视角、用什么语气、按什么规则”思考

Context（尤其是塞进的长文本、例子、事实、资料）→ 主要通过提供更丰富、更高质量的 K/V，让模型有更多“可被注意到的好东西”可以参考

Context Engineering 的底层机制

将 LLM 的固定权重和参数视为一个巨大的、静止的知识网络。

Prompt 告诉模型如何思考和如何说话（设置角色、格式、风格）。它通过 Q 向量激活了网络中特定的权重。

Context：告诉模型什么是对的，它通过注入全新的 K 和 V 向量，临时扩展了模型的知识基础，使得基于当前的事实而非训练时的旧知识进行生成。

因此，对 Prompt 和 Context 的任何微小改动，都会导致 Transformer 内部的注意力分数、上下文向量 A，乃至最终的概率分布发生变化，从而完全改变模型选择下一个 Token 的路径。

User、System、Assistant 角色标签是 OpenAI 训练模型时所使用的元数据。这些 Token 就像强力的语义标签，告诉 Transformer：

System 后面的内容是必须遵守的规则。

User 后面的内容是需要解答的问题。

Assistant 后面的内容是参考的回答格式。

模型会根据这些信号，调整其内部的注意力权重，最终引导 Softmax 概率分布，使生成的 Token 最大限度地满足这些角色的要求和约束。

把大模型想象成一个失忆但超级博学的古老图书馆管理员

他脑子里所有的书（知识）都固定了，再也加不进新书

他也记不住你上次问过什么（没有长期记忆）

但是——

你每次进门时可以带一大堆自己准备的书给他看（上下文）
你还可以告诉他今天要扮演什么角色、用什么态度说话（prompt）

他会根据你这次带给他的书 + 你对他的角色要求，快速翻阅、联想、拼凑出一段最符合当前情境的回答。

上下文工程的核心工作就是：

如何以最高的性价比，帮这个失忆但博学的管理员准备一套“当下最合适的参考书目 + 阅读指示”。

角色标签（system/user/assistant）为什么这么重要？

因为它们在预训练/后训练阶段被大量使用，模型对这几个特殊 token 形成了极强的模式识别能力。

当模型看到：

这些特殊标记本身就会强烈激活模型相应的“行为模式电路”，相当于直接按下了大脑里的几个巨型开关。

写在最后

模型本身的能力上限由训练决定，我们能控制的只有激活路径

好的上下文工程 ≈ 用最少的 token 数量，制造最大的“有效信息密度差”

Prompt 主要管风格、角色、思考方向；Context 主要管事实、例子、约束边界

大多数时候，真正拉开差距的不是你写了多高明的 prompt，而是你到底让模型“看见”了哪些关键信息

“我不是在和模型说话，我是在决定它此刻能看见的世界。”

https://arxiv.org/abs/1706.03762

MySQL-存储引擎

Kubelet → CRI → containerd/CRI-O → runc/kata：Kubernetes 容器运行时完整调用链