上下文管理

“上下文管理”属于 LLM 的外围技术层，而不是模型本身架构（Transformer、自注意力等）的内核部分。

一、LLM逻辑架构

对于推理业务，上下文概念是绕不过去的外围基础功能，负责连接用户需求和知识能力。

应用层 # 会话管理、提示工程
  ⬆️
上下文管理层 # KV Cache、上下文窗口管理  
  ⬆️
算法层 # Transformer、Self-Attention

1、模型内核层

LLM的物种级设计，只管 Transformer 本身的架构与注意力机制，即神经网络的结构和全连接能力。

2、系统功能层

这里是模型能力在推理时的基础功能扩展，而不是基础架构。

• 上下文窗口管理：比如 GPT-4 有 128k 上下文，Claude 有 200k 上下文，这决定了能放多少 token。
• 长上下文技术：例如 RAG（检索增强）、缓存记忆、窗口裁剪、位置插值、线性注意力等，都属于让模型“能够记住更多内容”的工程或算法方案。

3、应用和工程层

真正的“上下文管理”主要落在这里，对话裁剪、外部记忆、策略控制

• 对话管理：决定哪些历史消息进入 prompt，哪些丢弃，如何压缩。
• 外部记忆/数据库：将长对话、用户偏好、知识库存储在外部，在需要时拼接进上下文。
• 会话策略：比如 ChatGPT 如何在多轮对话里维持“角色”和“任务目标”，这是应用层逻辑。

二、CML位置

在上下文管理这一层，同样也会存在逻辑架构分层。

lCML 属于 上下文技术，但它不是对功能或架构方面的增强，而是更底层的上下文表达与组织方式，类似于“上下文接口层的标准化描述工具”，在更底层的表示层。

正如向量空间、张量计算最终衍生出了Transformer架构和Self-Attention机制，CML虽然不属于直接的上下文技术，但可以衍生出新的上下文技术，在压缩展开、跨系统跨模态共享、可视化审计方面可能带来革命性。从CML出发，完全可能衍生出一系列 上下文管理工具链，比如：上下文网关、中间件、记忆管理协议。

比如CML 驱动的上下文中间件：相当于在 LLM 之前加一层“上下文调度器”，所有输入输出都先转成 CML，再交给模型。核心难点是llm-->cml输出侧。LLM 是 token 生成器，不会直接吐“抽象语义树”或“图结构”，之所以能输出JSON，并不是外围适配器功能，而是内部计算在模仿JSON格式+一定的外部Schema约束。

这其实正是关键拦路虎，研究界正在尝试让 LLM 直接输出 AST（抽象语法树） 或 图结构，而不是字符串。要实现这种结果，要么底层创新，要么用专门的解码器，把 token 流实时解析成图结构。