Signal for LLM

Signal for LLM文档定位《Signal for LLM》不是 TGR 的理论文档也不是 Signal 文档体系的一部分。它是一份工程架构文档。目标不是重新定义 Signal而是讨论如何让 Signal 在现代大型语言模型LLM中真实参与运行而不是仅停留在符号层。本文件不修改《Signal》《Signal Runtime》《Signal API》《Signal Engine》的定义。它讨论的是LLM 如何成为 Signal 的宿主。一、为什么需要 Signal当前 LLM 已经具备极强的符号生成能力。Prompt、Memory、Embedding、Tool Calling 等机制不断提升模型的信息利用效率。但是这些能力几乎都建立在符号投影之上。模型能够读取符号。能够重建符号。能够根据符号推理。却很少能够让新的约束直接参与运行时状态。因此大部分约束只能表现为生成之后的解释。而不是生成之前和生成过程中持续存在的调制。Signal for LLM 的目标不是增加新的知识。而是增加一种新的运行方式。二、Signal不是信息而是运行时调制Signal 可以留下符号投影。Prompt 可以携带 Signal。Token 可以描述 Signal。Embedding 可以近似 Signal。但是这些都不是 Signal。Signal 首先是一种运行时状态调制。只有真正参与系统状态改变的约束才称为 Signal。如果某种信息只能作为 Prompt 被模型再次阅读那么它属于符号投影。而不是 Runtime Signal。三、当前LLM的解耦当前部署的大多数 LLM 中奖励模型负责学习约束。推理模型负责生成文本。部署之后奖励模型通常退出运行。于是训练阶段学习到的约束只能间接保留在参数中。运行过程中新的约束无法持续参与状态改变。因此模型只能通过符号重新推断这些约束。而不能直接观察它们仍然存在。Signal for LLM 希望恢复这一层运行连续性。四、ModulatorSignal for LLM 引入一个新的运行时角色Modulator调制模型。Modulator 不是推理模型。也不是奖励模型。它只负责根据当前约束对运行时状态进行调制。Modulator 可以非常小。甚至最小实现只输出-0真正重要的不是输出形式。而是输出必须真实改变系统状态。五、Runtime StateSignal 不直接控制文本。Signal 控制的是Runtime State。例如推理预算上下文窗口注意力资源分配KV Cache 权重Expert RoutingActivation Gate参数动态加权其它任何开发者允许调制的运行资源哪些资源开放属于 Engine 的实现问题。Signal 不规定具体对象。只要求状态真实发生改变。六、同步训练Signal for LLM 建议Reward Model、Modulator、Generator同步训练。原因不是提高准确率。而是建立共同预期。Generator 必须逐渐学会哪些 Runtime State 会出现。这些状态意味着什么。哪些漂移来自 Modulator。哪些来自 Prompt。否则Signal 将再次退化为Prompt Engineering。七、Signal MappingSignal Mapping 的角色重新定义。它不是恢复 Signal。而是记录已经发生的状态调制。Mapping 服务三个对象人类用于理解系统为什么发生漂移。Generator用于学习 Runtime State 与生成结果之间的关系。Modulator用于持续调整未来调制策略。Mapping 描述的是状态漂移留下的可追踪投影。而不是状态本身。八、最小实验Signal for LLM 的最小实验不验证 TGR。也不验证 Signal 是否存在。实验仅验证运行时状态调制是否能够形成可学习的连续影响。一个理论上的最小实现Modulator 输出-固定算法增加本轮 Context Window减少本轮 Context WindowGenerator 不读取 “” 或 “-”。它只能观察状态改变之后上下文产生的因果漂移。若同步训练成立Generator 将逐渐建立Runtime State 的预期并主动利用状态漂移完成生成。九、与现有LLM的关系Signal for LLM 不替代Transformer。不替代RLHF。不替代Reward Model。它增加的是Runtime Modulation Layer。因此Signal for LLM 更接近一种运行时架构。而不是新的基础模型。十、工程演化方向随着调制能力提高Modulator 可以逐步接管更多运行权限。例如动态推理预算注意力调度多专家路由参数动态激活外部资源分配多模型协同。这些权限是否开放由具体实现决定。Signal for LLM 不规定实现方式。只规定Signal 必须真实参与运行时状态。十一、边界Signal for LLM 不是 TGR 的证明。它只是TGR 在大型语言模型中的一种可能工程实现。即使Signal for LLM 最终失败。也只能说明当前工程路径失败。而不能反向否定TGR 对现实关系生成的描述。同样即使 Signal for LLM 成功也不能因此证明TGR 已被证明。它仅说明一种运行时 Signal 架构能够产生新的工程能力。结束语Signal for LLM 并不试图重新设计大型语言模型。它只提出一个新的运行时假设如果约束能够持续参与运行时状态而不是仅保留在参数或符号中那么模型追踪关系的成本将发生变化。Signal for LLM 的价值不在于定义新的模型而在于为现有模型增加一种新的运行层。它不是 Transformer 的替代者而是 Transformer 与运行时状态之间的一座桥梁。