CLM的适配边界候选集一变动态打分式决策就失灵实战踩坑记录【免费下载链接】CLM项目地址: https://gitcode.com/gh_mirrors/clm2/CLMCLMContrastive Language Models最近在 GitHub 热榜和各大技术社区刷了一波存在感斯坦福、NVIDIA 合作出品宣称抛弃自回归生成、用对比学习重构决策范式在 Agent 工具调用、高频决策场景里做到与 Jev 同级的准确率、最高 9 倍的延迟优势。社区评测里反复出现同一句话它适用于工具调用、GUI 操作等候选集合稳定的任务。这句话前半段是卖点后半段才是它的命门。CLM 的一切性能优势——预缓存嵌入、亚毫秒打分——都建立在一个隐含前提上候选动作集合在运行时是稳定、可复用的。一旦候选集开始动态增删打分式决策会以怎样具体的方式失灵本文直接进仓库源码把这条边界逐行拆开再用仓库自带 T-Rex 实测数据做验证。一次打分两个编码器CLM 的决策原语先把 CLM 的决策机制看清楚。它的推理核心在 src/clm/engine.py# engine.answer(): state 过 state head每个候选过 action head点积即得分 zq self._cached(f{ns}/state, dim, states, tokens, head.project_states) za self._cached(f{ns}/action, dim, cands, tokens, head.project_actions) ... cos za[k:k len(texts)] zq[i] answers[qid] answer_from_logits(questions[qid], keys, (scale * cos / temperature).tolist())一个choice问题该调哪个工具被拆成两半状态文本拼上问题说明过一次 state head每个候选的 description 文本各自过一次 action head。得分是exp(logit_scale) * cos(state_head(s), action_head(c))见 src/clm/heads.py然后对这个问题的候选集合做一次 softmax得到答案分布。仓库的 playground 把这个过程可视化得相当直观这套机制有两个值得注意的设计事实。第一打分是问题内相对的不是绝对的。概率 softmax(scale * cos)分母只包含本次请求里携带的候选。CLM 从不对候选做任何改写或生成——Engine.rank把自由候选包成一个 choice 问题src/clm/schema.py 里写得很直白a candidate reaches the encoder exactly as the caller wrote it。候选文本怎么来的、写得好不好CLM 一概不负责。第二候选之间彼此孤立。每个候选独立编码成向量打分就是状态向量和候选向量的逐个点积复杂度 O(N)。这正是它快的根源——但也意味着模型永远看不到候选列表的整体形态候选间是互斥还是递进、有没有层级、是不是同一组动作的变体它无从判断。它能做的只有一件事把状态向量放进候选向量堆里找最对齐的那个。预缓存失效候选一变CLM 退化成什么CLM 的低延迟神话由三层缓存支撑全部以文本不变为前提src/clm/embedder.py编码器侧 LRU 缓存键是文本本身容量 20 万条src/clm/cache.pyVectorArena在显存里预划一块固定大小的向量池默认设备显存的 2%命中的候选跳过编码器调用、跳过 host-to-device 拷贝、跳过 projection head 前向热重载机制HeadPair.namespace f{name}{generation}权重一变 generation 递增旧投影立即作废。缓存命中时一个决策的服务端耗时只有 2.6msT-Rex 实测model_ms_p50。README 的缓存对照表把这条边界画得很清楚3 个动作50 个动作每次都是新状态28.6 → 28.0 ms28.8 → 28.1 ms回访已有状态20 个场景1.7 → 0.6 ms2.0 → 0.7 ms注意第一行状态一变缓存的省力就全部归零——因为状态几乎总是新的能复用的是候选。所以动态候选集对 CLM 是双重打击新增候选 一次必付的编码成本。新候选的文本从没进过缓存必然 miss要走完整编码器前向。延迟从个位数毫秒弹回 ~28ms 量级usage.input_tokens也会把新候选的 token 如实计入。候选集更新频率越高CLM 的快就越接近普通 embedder 的水平。候选增删 softmax 分布被外力重排。这才是更深的问题。由于概率是相对归一化的加入一个语义接近的难候选这正是 CLM 中训练 30M 合成难负样本要防的东西会直接分流现有概率、可能翻转 top-1删掉最高分候选后其余概率会被重新归一化放大但第二名本来就差多少这个信息已经丢了——CLM 只会排序不度量差距。confidence top - mean(rest)src/clm/schema.py也随之剧烈抖动候选集大而杂时top 概率天然被稀释置信度虚低候选集被裁到只剩两个时任何分数差都被放大成接近 1 的自信。更隐蔽的一层动作候选是逐条独立嵌入的新候选永远不会被纳入上下文做整体推理。生成式模型能把完整候选清单塞进上下文看到这 5 个函数里 A 和 B 是同一 API 的别名这类关系CLM 的候选之间没有交互通道。候选集从固定变为开放后它在训练分布外的新候选上没有任何质量保证——中训练阶段的难负样本Gemini 2.5 Flash-Lite 合成强化的是区分相似候选前提是候选形态在分布内。实测记录固定候选集上CLM 的真实成色仓库自带一个能直接对照的实验T-Rex 小恐龙游戏CLM 对 Jev。两者用同一个客户端、同一份 Choice 请求examples/t_rex/trex/backends.py候选永远是jump / duck / run三个动作——这是 CLM 最理想的固定候选工况。实测结果见 examples/t_rex/results/clm_realtime.json 与同目录的jev_realtime.json指标CLMJev存活5 seed × 60s5/55/5平均决策次数 / seed3341.81119.0与 planner 最优动作一致率0.6580.987端到端延迟 p5016.5 ms149.8 ms纯模型打分 p502.6 ms131.9 msshield 兜底干预全 5 seed4883 次28 次这份数据把 CLM 的成色和短板同时摆在桌上。速度是真的2.6ms 一次打分让它能在 60 秒里做 3341 次决策是 Jev 的 3 倍决策密度游戏场景里想得慢就是原罪这正是 System One 模型的价值。但打分质量有水分与 planner 的一致率只有 0.658远低于 Jev 的 0.987导致 4883 次决策要靠 harness 的 shieldplanner 标为 unsafe 的动作被替换兜底——而 Jev 只需要 28 次。换句话说哪怕在候选完全固定的理想工况CLM 也只是快而不准到能自保必须依赖外部物理规划器背书。再放大到 verifier 场景看给 38 个 DeepSWE、30 个 Terminal-Bench 2.1 任务各预采样若干候选解Opus 5 / Fable 5CLM 挑最优轻量微调后达到 81.6% 和 87.6%、快 4.1–5.7 倍见 README.md 与 evaluation/bon_eval.py。注意这个流程的结构候选解在打分前已经全部生成好、固定住CLM 只做一次排序选择窗口聚合逻辑也完全确定末 K 步均值。这是 CLM 的甜区——也反过来证明它的全部算法假设就是候选先到齐我只排序。边界结论CLM 适合什么绝不适合什么把源码事实和实测数据收拢CLM 的适配边界可以画得非常明确。它适合的是候选集先于决策而闭合的场景best-of-N 验票员。候选解预采样、固定、离线或批量嵌入CLM 只做最高分的排序——DeepSWE / Terminal-Bench 的成绩就是这么来的这也是 README 明确定位的verifier角色工具路由。候选 已注册工具集改动频率低新增工具是一次性成本状态天天变、工具半年不变正是缓存表里第二行回访状态的最优工况固定动作空间的实时控制。T-Rex、Super Mario 这类动作全集封闭的任务动作向量一次嵌入终身复用2.6ms 的决策周期才让它有资格做实时控制。它绝不适合的是候选集随推理逐轮演化的开放式任务开放式编程 Agent。每一步可能产生全新的函数名、新的代码片段、新的候选方案——候选本质上是上一个生成步的输出是开放流而非闭合集。此时预缓存每次都在失效、编码成本全额回归而且新候选完全在训练分布外需要对候选做改写/合并/推理的任务。CLM 对候选文本一字不动地编码候选写得好坏它不管、候选间的互斥与层级关系它看不见指望它像生成式模型那样看着整个选项列表想问题是架构上就不支持的需求候选数量不可控的场景。examples/common.py里对 Jev 255 个选项上限做的 chunk tournament 本身就是一种妥协 hack说明候选规模一大任何打分式方案的工程形态都会变得拧巴。社区对 CLM 的总结其实早就点破了这一点它适配工具调用、GUI 操作等候选集合稳定的任务。这不是谦虚是架构的诚实——CLM 把决策重定义成了在闭合候选集上找最近邻用生成能力的让渡换来了两个数量级的延迟优势。落地时最该做的判断不是CLM 好不好而是我的候选集在决策时是不是闭合的。如果答案是否要么在系统设计上把候选先固化下来预采样、快照、延迟刷新把 CLM 留在它擅长的排序位上要么就老实承认这一步决策需要的是会生成的模型而不是会打分的模型。CLM 不是万能的决策引擎它是把系统一这个定位贯彻得最彻底的一次工程实践——而它的边界恰好就是那条候选集开始流动的线。【免费下载链接】CLM项目地址: https://gitcode.com/gh_mirrors/clm2/CLM创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 CLM的适配边界：候选集一变动态，打分式决策就失灵？实战踩坑记录
CLM的适配边界候选集一变动态打分式决策就失灵实战踩坑记录【免费下载链接】CLM项目地址: https://gitcode.com/gh_mirrors/clm2/CLMCLMContrastive Language Models最近在 GitHub 热榜和各大技术社区刷了一波存在感斯坦福、NVIDIA 合作出品宣称抛弃自回归生成、用对比学习重构决策范式在 Agent 工具调用、高频决策场景里做到与 Jev 同级的准确率、最高 9 倍的延迟优势。社区评测里反复出现同一句话它适用于工具调用、GUI 操作等候选集合稳定的任务。这句话前半段是卖点后半段才是它的命门。CLM 的一切性能优势——预缓存嵌入、亚毫秒打分——都建立在一个隐含前提上候选动作集合在运行时是稳定、可复用的。一旦候选集开始动态增删打分式决策会以怎样具体的方式失灵本文直接进仓库源码把这条边界逐行拆开再用仓库自带 T-Rex 实测数据做验证。一次打分两个编码器CLM 的决策原语先把 CLM 的决策机制看清楚。它的推理核心在 src/clm/engine.py# engine.answer(): state 过 state head每个候选过 action head点积即得分 zq self._cached(f{ns}/state, dim, states, tokens, head.project_states) za self._cached(f{ns}/action, dim, cands, tokens, head.project_actions) ... cos za[k:k len(texts)] zq[i] answers[qid] answer_from_logits(questions[qid], keys, (scale * cos / temperature).tolist())一个choice问题该调哪个工具被拆成两半状态文本拼上问题说明过一次 state head每个候选的 description 文本各自过一次 action head。得分是exp(logit_scale) * cos(state_head(s), action_head(c))见 src/clm/heads.py然后对这个问题的候选集合做一次 softmax得到答案分布。仓库的 playground 把这个过程可视化得相当直观这套机制有两个值得注意的设计事实。第一打分是问题内相对的不是绝对的。概率 softmax(scale * cos)分母只包含本次请求里携带的候选。CLM 从不对候选做任何改写或生成——Engine.rank把自由候选包成一个 choice 问题src/clm/schema.py 里写得很直白a candidate reaches the encoder exactly as the caller wrote it。候选文本怎么来的、写得好不好CLM 一概不负责。第二候选之间彼此孤立。每个候选独立编码成向量打分就是状态向量和候选向量的逐个点积复杂度 O(N)。这正是它快的根源——但也意味着模型永远看不到候选列表的整体形态候选间是互斥还是递进、有没有层级、是不是同一组动作的变体它无从判断。它能做的只有一件事把状态向量放进候选向量堆里找最对齐的那个。预缓存失效候选一变CLM 退化成什么CLM 的低延迟神话由三层缓存支撑全部以文本不变为前提src/clm/embedder.py编码器侧 LRU 缓存键是文本本身容量 20 万条src/clm/cache.pyVectorArena在显存里预划一块固定大小的向量池默认设备显存的 2%命中的候选跳过编码器调用、跳过 host-to-device 拷贝、跳过 projection head 前向热重载机制HeadPair.namespace f{name}{generation}权重一变 generation 递增旧投影立即作废。缓存命中时一个决策的服务端耗时只有 2.6msT-Rex 实测model_ms_p50。README 的缓存对照表把这条边界画得很清楚3 个动作50 个动作每次都是新状态28.6 → 28.0 ms28.8 → 28.1 ms回访已有状态20 个场景1.7 → 0.6 ms2.0 → 0.7 ms注意第一行状态一变缓存的省力就全部归零——因为状态几乎总是新的能复用的是候选。所以动态候选集对 CLM 是双重打击新增候选 一次必付的编码成本。新候选的文本从没进过缓存必然 miss要走完整编码器前向。延迟从个位数毫秒弹回 ~28ms 量级usage.input_tokens也会把新候选的 token 如实计入。候选集更新频率越高CLM 的快就越接近普通 embedder 的水平。候选增删 softmax 分布被外力重排。这才是更深的问题。由于概率是相对归一化的加入一个语义接近的难候选这正是 CLM 中训练 30M 合成难负样本要防的东西会直接分流现有概率、可能翻转 top-1删掉最高分候选后其余概率会被重新归一化放大但第二名本来就差多少这个信息已经丢了——CLM 只会排序不度量差距。confidence top - mean(rest)src/clm/schema.py也随之剧烈抖动候选集大而杂时top 概率天然被稀释置信度虚低候选集被裁到只剩两个时任何分数差都被放大成接近 1 的自信。更隐蔽的一层动作候选是逐条独立嵌入的新候选永远不会被纳入上下文做整体推理。生成式模型能把完整候选清单塞进上下文看到这 5 个函数里 A 和 B 是同一 API 的别名这类关系CLM 的候选之间没有交互通道。候选集从固定变为开放后它在训练分布外的新候选上没有任何质量保证——中训练阶段的难负样本Gemini 2.5 Flash-Lite 合成强化的是区分相似候选前提是候选形态在分布内。实测记录固定候选集上CLM 的真实成色仓库自带一个能直接对照的实验T-Rex 小恐龙游戏CLM 对 Jev。两者用同一个客户端、同一份 Choice 请求examples/t_rex/trex/backends.py候选永远是jump / duck / run三个动作——这是 CLM 最理想的固定候选工况。实测结果见 examples/t_rex/results/clm_realtime.json 与同目录的jev_realtime.json指标CLMJev存活5 seed × 60s5/55/5平均决策次数 / seed3341.81119.0与 planner 最优动作一致率0.6580.987端到端延迟 p5016.5 ms149.8 ms纯模型打分 p502.6 ms131.9 msshield 兜底干预全 5 seed4883 次28 次这份数据把 CLM 的成色和短板同时摆在桌上。速度是真的2.6ms 一次打分让它能在 60 秒里做 3341 次决策是 Jev 的 3 倍决策密度游戏场景里想得慢就是原罪这正是 System One 模型的价值。但打分质量有水分与 planner 的一致率只有 0.658远低于 Jev 的 0.987导致 4883 次决策要靠 harness 的 shieldplanner 标为 unsafe 的动作被替换兜底——而 Jev 只需要 28 次。换句话说哪怕在候选完全固定的理想工况CLM 也只是快而不准到能自保必须依赖外部物理规划器背书。再放大到 verifier 场景看给 38 个 DeepSWE、30 个 Terminal-Bench 2.1 任务各预采样若干候选解Opus 5 / Fable 5CLM 挑最优轻量微调后达到 81.6% 和 87.6%、快 4.1–5.7 倍见 README.md 与 evaluation/bon_eval.py。注意这个流程的结构候选解在打分前已经全部生成好、固定住CLM 只做一次排序选择窗口聚合逻辑也完全确定末 K 步均值。这是 CLM 的甜区——也反过来证明它的全部算法假设就是候选先到齐我只排序。边界结论CLM 适合什么绝不适合什么把源码事实和实测数据收拢CLM 的适配边界可以画得非常明确。它适合的是候选集先于决策而闭合的场景best-of-N 验票员。候选解预采样、固定、离线或批量嵌入CLM 只做最高分的排序——DeepSWE / Terminal-Bench 的成绩就是这么来的这也是 README 明确定位的verifier角色工具路由。候选 已注册工具集改动频率低新增工具是一次性成本状态天天变、工具半年不变正是缓存表里第二行回访状态的最优工况固定动作空间的实时控制。T-Rex、Super Mario 这类动作全集封闭的任务动作向量一次嵌入终身复用2.6ms 的决策周期才让它有资格做实时控制。它绝不适合的是候选集随推理逐轮演化的开放式任务开放式编程 Agent。每一步可能产生全新的函数名、新的代码片段、新的候选方案——候选本质上是上一个生成步的输出是开放流而非闭合集。此时预缓存每次都在失效、编码成本全额回归而且新候选完全在训练分布外需要对候选做改写/合并/推理的任务。CLM 对候选文本一字不动地编码候选写得好坏它不管、候选间的互斥与层级关系它看不见指望它像生成式模型那样看着整个选项列表想问题是架构上就不支持的需求候选数量不可控的场景。examples/common.py里对 Jev 255 个选项上限做的 chunk tournament 本身就是一种妥协 hack说明候选规模一大任何打分式方案的工程形态都会变得拧巴。社区对 CLM 的总结其实早就点破了这一点它适配工具调用、GUI 操作等候选集合稳定的任务。这不是谦虚是架构的诚实——CLM 把决策重定义成了在闭合候选集上找最近邻用生成能力的让渡换来了两个数量级的延迟优势。落地时最该做的判断不是CLM 好不好而是我的候选集在决策时是不是闭合的。如果答案是否要么在系统设计上把候选先固化下来预采样、快照、延迟刷新把 CLM 留在它擅长的排序位上要么就老实承认这一步决策需要的是会生成的模型而不是会打分的模型。CLM 不是万能的决策引擎它是把系统一这个定位贯彻得最彻底的一次工程实践——而它的边界恰好就是那条候选集开始流动的线。【免费下载链接】CLM项目地址: https://gitcode.com/gh_mirrors/clm2/CLM创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考