不做生成、只做打分，CLM还配叫『语言模型』吗？范式之争刚起

不做生成、只做打分CLM还配叫『语言模型』吗范式之争刚起【免费下载链接】CLM项目地址: https://gitcode.com/gh_mirrors/clm2/CLM导读2026年9月下旬一个名为 Contrastive-LMCLM的开源项目冲上 GitHub 热榜前几名随之而来的不是一片叫好而是一场关于命名的争论这个模型在推理时不做任何自回归生成只对状态-动作做向量打分与排序它凭什么还叫语言模型支持者认为这是 Agent 决策范式的重构——用对比学习取代生成式决策反对者则坚持语言模型的底线就是语言建模Language Modeling打分器再快也只是判别模型。本文基于仓库源码与社区讨论尝试把这笔定义账算清楚CLM 的技术本质到底是什么两派各自的依据又在哪里。『语言模型』的定义之争生成能力是否是必要条件先把概念还原到学术原点上。语言模型Language ModelLM的经典定义是对一段文本序列的概率分布建模P(w1, w2, ..., wn)。它关心的是语言本身的分布。围绕这个定义预训练时代分化出两大流派因果语言建模Causal Language ModelingCLM单向自回归根据前文预测下一个 token。GPT 家族是代表天然适配文本生成掩码语言建模Masked Language ModelingMLM双向建模根据上下文恢复被遮盖的 token。BERT 家族是代表擅长理解与表征学习。也就是说在社区已有话语体系里CLM这个缩写早就被因果语言模型占用了——这一点在近几年的社区科普中反复被强调MLM 还是 CLMCLM vs MLM 到底有什么区别是长盛不衰的选题。而 Contrastive-LM 的发布等于把这个缩写从生成范式的名下抢走改造成了对比范式。这是定义之争的第一层同一个缩写两种截然不同的训练目标。第二层更尖锐它连语言都不碰了。CLM-8B 的推理过程完全绕开词元预测——输入状态文本输出的是该选哪个候选动作的概率分布输出空间里没有任何自由文本。于是问题自然浮现一个不产出语言、只产出打分向量的系统还配叫语言模型吗打分式模型的真实定位它是决策器还是语言模型与其在命名上空对空不如先看仓库里这个模型到底做了什么。打开 README.md项目自称 A System One Model for Fast and Generalizable Decision-Making定位非常明确System One 决策模型而非对话/生成模型。双编码器把决策降维成向量检索核心架构在 heads.py 与 engine.py 中清晰可见一个冻结的 Qwen3-8B 编码器4096 维 last-token pooling 嵌入两个各约2000 万参数的可训练投影头state head / action head把 4096 维编码降维到 512 维推理时对 (状态, 候选动作) 计算缩放余弦相似度softmax就是答案分布——这正是 InfoNCE 训练目标的推理形态。engine.py 中answer()的核心只有几行状态过 state head、候选文本过 action head然后cos za zqanswers[qid] answer_from_logits(...)。所谓决策就是一次向量点积加 softmax。README 里把这句话写得很直白A typed question is a state plus a closed set of candidate actions (the options and their descriptions); a softmax over CLMs scoresisthe answer distribution。类型化问答把语言任务硬编码成选择任务仓库用三种问题类型覆盖了大多数 Agent 场景见 client.py 与 schema.pyNoul是非判断题输出命题为真的概率Choice从候选集合中选一输出分布Score按有序量纲打分输出期望等级与分布。以 README 的客服示例为例一次请求同时输出urgency紧急度department转给哪个团队frustration顾客愤怒程度三个答案input_tokens只统计编码器的实际开销。同样的原语还能直接对 free-form 候选做 best-of-N 排序Engine.rank这在 engine.py 里被实现为一次内部 Choice 问题。低延迟是怎么来的缓存 点积决定性优势来自状态与动作解耦动作是固定候选集其嵌入可以预计算并缓存。仓库在 cache.py 实现了一个仿 vLLM KV cache 思路的设备端向量竞技场Vector Arena启动时一次性预留显存默认 2%按维度分成 512 维投影池与 4096 维原始编码池LRU 淘汰、永不扩容。缓存命中直接跳过编码器调用与宿主-设备拷贝。实测数据在 examples/t_rex/results/clm_realtime.json真实跑 Chrome 小恐龙游戏 60 秒 × 5 个种子CLM 全部存活服务端 p50 延迟中位数16.5 ms模型推理 p50 仅2.6 ms60 秒内做出约 3340 次决策、零错误。README 给出的宏观数字是与 TypeSafe 的 Jev 相比在 computer-use、游戏、工具调用任务上最高 9× 延迟降低。作为验证器的另一面不生成并不等于不做语言理解。仓库展示了它作为verifier裁判的高光表现对每个编码任务采样多条候选轨迹DeepSWE 用 Opus 5Terminal-Bench 2.1 用 Fable 5由 CLM 或 Jev 选最优。微调后 CLM 在DeepSWE 38 个保留任务上达到 81.6%、Terminal-Bench 2.1 30 个保留任务上达到 87.6%的 SOTA且比 Jev 快 4.1–5.7 倍——而 Jev 在长程任务上甚至低于 pass1。评测脚本见 evaluation/bon_eval.py其逻辑就是给每步打分、对末 12 步取均值、选最高分轨迹——纯打分零生成。所以从技术本体看CLM 的定位无可争议它是决策器/判别器。问题只在于这个决策器要不要叫语言模型。站在两边的理由范式重构派与定义保守派范式重构派生成只是手段对齐才是目的这一派的论证可以归结为三点编码器仍然是语言模型。CLM-8B 的底座是冻结的 Qwen3-8B——一个不折不扣的自回归语言模型。语言理解能力由它提供投影头只是在语言表征上做判别。认为CLM 不是语言模型等于BERT 不是语言模型但后者从未被这样质疑过。训练目标仍是语言理解的强化版。三阶段数据配方README 的 Data Recipe分别是约 6000 万 Nemotron 问答对预训练、约 3000 万 Gemini 2.5 Flash-Lite 生成的合成难负样本中训练、约 100 万条 Agent 轨迹后训练。每个阶段都在教模型理解一段文本之后哪个文本动作最合适——这是标准的语义对齐只是用 InfoNCE 而非 next-token prediction 来实现。范式转移的时机已到。Agent 场景里 90% 的生成其实是伪生成工具调用、GUI 操作、轨迹选择、路由判断候选集在系统设计期就基本固定。与其让 8B 模型逐 token 地想出答案不如预计算候选嵌入、推理时一次点积。社区里已有文章把这一点概括为用对比学习替代 Agent 中大量生成式决策并测出最高 13× 加速的观察。这一派认为语言模型的名字保留下来是合理的——它提醒人们语言理解能力没有缺席缺席的只是低效的生成环节。定义保守派命名是契约不是修辞反对者的立场同样有据可依术语的学术契约不容模糊。Language Model自香农以来就指对语言序列的概率建模CLM 的对比目标对下一个 token 的分布一无所知。MLM 与 CLM 之争再热闹双方都还在预测被遮盖/下一个词元的框架内CLMContrastive直接跳出了这个框架。让同一缩写同时指代因果建模与对比建模只会给初学者和检索系统制造混乱。能力的边界是真实的。打分模型没有自由生成能力这意味着它无法开放域创作、开放式规划、跨候选集组合推理。Agent 一旦遇到候选集之外的新动作CLM 无计可施仓库的 roadmap 也承认现阶段聚焦决策、多模态尚在计划中。把它叫语言模型容易让人误以为它能替代 LLM 的生成能力——而实际上它是对 LLM 的补充。历史经验判别式模型有自己更准确的谱系。这类上下文 候选 打分的架构本质上是检索模型/判别模型/验证器社区已有成熟名称如 reranker、verifier、retrieval head。保守派认为更恰当的名字是对比式决策模型或状态-动作判别器把语言模型留给真正建模语言的系统。两派其实在吵同一件事的两个层面细看会发现两派的分歧不是事实分歧而是分类标准分歧重构派按组件分类底座是 LLM所以整体是 LLM 家族成员保守派按行为/能力分类不生成语言就不能叫语言模型。类比一下BERT 是语言模型吗按行为标准BERT 也是只做理解不做生成但业内普遍接受了 BERT 是预训练语言模型。区别在于 BERT 的训练目标仍是词元级语言建模MLM而 CLM 的训练目标是句子级对比对齐。这条线划在哪里正是争论的枢纽。命名之争背后的真问题平心而论这笔账最终要由工程生态来结。仓库里有一个耐人寻味的细节clm-serve对外提供的POST /v1/systemone接口完全兼容 TypeSafe 的 wire format——同一个请求既可以发给本地 CLM也可以发给 Jev见 examples/common.py 的Judge封装。也就是说在 Agent 工程层面生成式决策与打分式决策已经可以无缝替换调用方根本不关心背后是自回归还是对比学习。这恰恰是范式之争最有力的注脚当打分式决策能以 9× 的延迟优势、同等甚至更好的任务表现平替掉一部分生成式决策时争议的焦点就不再是它配不配叫语言模型而是**哪些决策任务根本不需要生成**。CLM-8B 的 zero-shot 表现与 Jev 持平、最高 9× 加速和作为 verifier 的 SOTA 成绩已经把这个问题从哲学推回了工程。对开发者而言正确的打开方式是把它当作一个低延迟决策模块接入 Agent 栈——工具选择、best-of-N 轨迹筛选、类型化状态问答这些场景它又快又准需要开放文本产出时再让真正的生成式 LLM 上阵。至于名字等社区吵完也许会出现更准确的术语——但 CLM 代表的状态-动作对齐 预计算缓存这条技术路线大概率会留下来并在多模态、更大底座的方向上继续演进这正是仓库 roadmap 列出的计划。范式之争刚起而技术已经在用延迟曲线投票了。【免费下载链接】CLM项目地址: https://gitcode.com/gh_mirrors/clm2/CLM创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考