LLM、决策模型（Jev、CLM）与抽取模型（Clairic）：到底什么时候用哪个？
上个月，TypeSafe 的 Jev 和 OpenAI 的 Decisions API 带来了一波 demo 热潮——从给 agent 秒加护栏，到直接按设计系统生成 UI 界面。紧接着，斯坦福 Hazy Research 和 NVIDIA 开源了对比语言模型（Contrastive Language Models，CLM-8B），Cloudflare 又发布了 Clairic，一个主打「系统一」的抽取模型。新模型品类冒出来的速度让人眼花缭乱，有这种感觉的不止你一个。
为什么 AI 突然被拆成抽取模型、决策模型、生成模型三类？它们在一个真实的代码库里究竟该放在哪一层？我们抛开炒作，把「什么时候用哪个、它们怎么配合、在哪里会翻车」讲清楚。
30 秒建立心智模型
在 IBM Technology 的拆解视频《What Is Jev? The AI Model That Doesn't Generate Text》里，Martin Keen 一上来就问了个简单的问题：「如果一个 AI 模型不需要生成文本呢？」
过去这些年，我们把生成式 LLM（也就是「系统二」：慢、逐 token 输出）用在了很多根本不需要写文章的任务上。如果你的后端只是想从发票里抠出一个开票日期，或者把工单分到四个类别之一，却要等上 3 秒让 LLM 一个字符一个字符地吐 JSON，那就是白白浪费延迟和 token 成本。
现代 AI 栈的做法是：在你的 LLM 前面，把「快、单次通过」的「系统一」模型拆成两层。
flowchart LR
A[Messy Input PDF or Email] --> B[1. Extraction Model Clairic]
B -->|Typed Values| C[2. Deterministic Code SQL or Math]
C -->|Verified State| D[3. Decision Model Jev or CLM-8B]
D -->|Probabilities| E{Confidence Gate}
E -->|High P| F[Auto-Execute API]
E -->|Low P| G[Human Review or LLM]
style A fill:#475569,color:#fff,stroke:#334155
style B fill:#047857,color:#fff,stroke:#022c22
style C fill:#b91c1c,color:#fff,stroke:#7f1d1d
style D fill:#1d4ed8,color:#fff,stroke:#1e3a8a
style E fill:#6b7280,color:#fff,stroke:#4b5563
style F fill:#15803d,color:#fff,stroke:#14532d
Martin Keen 在 IBM Technology 的视频里给了一个最清晰的理解方式：
- 生成式 LLM 负责写出答案。
- 决策模型负责在你已经定义好的答案中做判断。
当你的代码走到某个依赖复杂人类上下文的 if/else 分支时，先问自己一句：“我是需要新内容，还是在已知选项里挑一个？”
底层原理：动作缓存为什么这么快
一个模型怎么能在 50–150 毫秒内选出一个动作，却完全不生成文字？开源权重的对比语言模型（Contrastive Language Model，CLM-8B）把架构讲得很清楚：它不预测下一个词，而是用双编码器把当前状态向量和候选动作向量目录做比对。
你看到那些“从设计系统直接生成 UI 界面”的演示时，模型其实并没有在写 React 代码。你的设计系统组件在启动时只嵌入一次并缓存起来。运行时，模型把用户状态嵌入，然后对上1000 个候选组件打分，整个过程大约 58 毫秒。
flowchart TD
subgraph Cached Once at Startup
A1[Component RefundBanner] --> E2[Action Encoder]
A2[Component OrderTimeline] --> E2
E2 --> V2[(Cached Action Vectors)]
end
subgraph Runtime
S[Current User State] --> E1[State Encoder]
E1 --> V1[State Vector]
V1 & V2 --> Sim{Dot-Product}
Sim --> Out[Probabilities per Component]
end
style V2 fill:#4b5563,color:#fff,stroke:#1f2937
style V1 fill:#4b5563,color:#fff,stroke:#1f2937
style Sim fill:#1d4ed8,color:#fff,stroke:#1e3a8a
style Out fill:#15803d,color:#fff,stroke:#14532d
提取模型（Clairic）：先拿到类型化数值，再做决策
决策模型只有在你能提前列出所有选项时才管用。可如果你需要从一份乱七八糟的 PDF 里抠出 disputed_amount 或 transaction_date 呢？你不可能把每一个可能的数字都塞进一个 Choice 枚举里。这就是 Cloudflare 的 Clairic 的用武之地：它一次遍历就能提取出强类型的值，完全绕开 LLM 生成 JSON 时胡编乱造的问题。
flowchart LR
Input[Raw Bank Statement] --> Clairic{Clairic Extraction}
Clairic --> O1[merchant Target span 27..33]
Clairic --> O2[amount 145.50 Float]
Clairic --> O3[tracking NULL p_null 1.0]
style Clairic fill:#047857,color:#fff,stroke:#022c22
style Input fill:#475569,color:#fff,stroke:#334155
style O1 fill:#f59e0b,color:#000,stroke:#b45309
style O2 fill:#f59e0b,color:#000,stroke:#b45309
style O3 fill:#f59e0b,color:#000,stroke:#b45309 为什么这比 LLM 的 JSON 模式强：零幻觉字符串：文本字段返回源文档中精确的起始和结束字符偏移量（span 27..33）。显式 p_null：与其编造一个追踪号，Clairic 直接返回 p_null 1.0，这样你的代码就能明确知道该字段缺失。3. 综合运用：RAG + 系统一 + LLM 在现代企业应用中，它们实际上如何协同工作？我们来看一个实际的银行纠纷处理流程。一个实用的流程是这样的：RAG 检索相关的合同、政策、邮件或文档。Clairic 从检索到的文档中抽取字段，比如金额、日期、账号或风险指标。你的应用使用这些字段进行校验、工作流路由，或者生成最终的 LLM 回复。以银行场景为例：RAG 找到客户的纠纷政策和案件历史；Clairic 从上传的对账单中抽取争议金额、交易日期、商户和卡号；然后由决策模型或工作流判定是批准、要求补充材料，还是升级处理。sequenceDiagram
autonumber
participant App as Banking Backend #047857
participant RAG as Vector DB
participant Ext as Clairic Extraction
participant Dec as Jev Decision
App->>RAG: Query Target merchant dispute policy
RAG-->>App: Policy requires receipt if over 100
App->>Ext: Raw PDF Bank Statement
Ext-->>App: merchant=Target, amount=145.50
Note over App: Code verifies transaction in SQL DB
App->>Dec: State: Extracted Data + RAG Policy
Note over Dec: Evaluates defined outcomes
Dec-->>App: Choice request_documents, conf 0.94
注意：当阈值大于 0.85 时触发工作流
不容忽视的问题：“格式正确但内容错误”的陷阱
Jev 和 Clairic 都有一个核心问题：它们输出的结构化结果可能格式完全正确，但事实是错的。因为它们保证了模式合规（比如始终返回合法的 JSON 布尔值或严格的枚举值），开发者很容易偷懒，直接把输出灌进生产数据库。这类“系统一”模型在窄任务上速度极快、成本极低，但它们无法可靠替代以下场景：
- 确定性代码：如果能用正则表达式或简单的字符串分割搞定，就写代码，别用 AI。
- 领域逻辑：Clairic 擅长提取发票总额，但它不该去算税。让确定性代码来做数学运算。
- 完整推理（系统二）：如果一张工单需要多步排查、查文档或撰写细致的回复，Jev 做不了。你仍然需要一个重量级的推理大模型。
把“系统一”模型当作高效的模糊匹配器，但要让确定性代码充当最后的把关人。
“什么时候用什么”速查表
flowchart TD
Start[任务：处理杂乱文本] --> Q1{需要精确计算？}
Q1 -->|是| Code[确定性代码]
Q1 -->|否| Q2{选项已知？}
Q2 -->|是：路由分类| Jev[决策模型 Jev]
Q2 -->|否：提取值| Clairic[提取模型 Clairic]
style Code fill:#ef4444,color:#fff,stroke:#991b1b
style Jev fill:#3b82f6,color:#fff,stroke:#1e40af
style Clairic fill:#10b981,color:#fff,stroke:#047857
style Start fill:#475569,color:#fff,stroke:#334155
style Q1 fill:#475569,color:#fff,stroke:#334155
style Q2 fill:#475569,color:#fff,stroke:#334155
💡 简单规则
需要回答“信息在哪里、含义是什么”——用 RAG。
需要回答“这份文档里的精确结构化数值是什么”——用 Clairic。
需要回答“这些预设路线里该走哪一条”——用 Jev。
轮到你了：你也遭遇模型疲劳了吗？
不到两个月，我们从“直接给 LLM 写提示词”，变成了要同时应付提取模型（Clairic）、闭源决策 API（Jev、OpenAI Decisions）、开放权重对比模型（CLM-8B）和推理型 LLM。新模型类型来得这么快，你是不是也有点招架不住？
你在自己的项目里试过把 Jev、CLM-8B 或 Clairic 放在 LLM 前面吗？或者发现过什么有趣的场景——一个快速概率门控比文本生成更管用？欢迎在评论区聊聊你的想法、质疑，或者架构上的踩坑故事。
参考链接
- IBM Technology：What Is Jev? The AI Model That Doesn't Generate Text
- Stanford Hazy Research & NVIDIA：Contrastive Language Models（CLM-8B）