0.1 轻量决策引擎的位置

0.1 轻量决策引擎的位置

本节摘要：在动第一行代码之前，先回答一个问题：已经有生成式 LLM 了，为什么还需要一台 laya？本节把决策工具按「单次延迟 × 成本方式 × 语义能力」排成四层谱系：规则与关键词毫秒级但不懂语义；生成式 LLM 懂语义但单次几百毫秒到秒级、按 token 计费；laya 把语义判断压进一次前向——官方 README 口径 32.8 毫秒、CPU 可跑、自托管；Jev 云端 API 以 236~276 毫秒居中且能力更强。随后给出适用清单（高频路由、内容审核、意图分类、多语言筛选）与不适用清单（开放生成、复杂推理），并转述官方诚实声明：底座检查点 zero-shot 接近随机猜，价值在微调——这决定了正确的上手姿势是「先跑通、再微调、后上线」。

学习目标

• 说出四层决策工具各自的延迟量级与成本方式。
• 解释「单次前向」与「逐 token 生成」的延迟差异从何而来。
• 用适用 / 不适用清单判断一个具体任务该不该交给 laya。
• 复述官方诚实声明的两条内容，以及它们对上线方式的影响。

一、四层决策工具谱系

软件里的「判断」由来已久，工具谱系从快到慢大致四层：

读这张表的正确姿势是「往下走一层，多付一次钱和多等一段时间，换来更强的语义能力」。规则层换同义表达就失效；生成式 LLM 什么都能聊，但你不会想让它守在每秒几千条消息的入口上——延迟和账单都撑不住。

中间两层是「判断专用」的工具：Jev 与 laya 同属 System 1 决策模型，都是「输入状态与带类型的问题，输出带类型的答案加概率」。差别在定位：Jev 是云端托管、能力上限更高；laya 是开源自托管、更轻更快。本书讲后者。

二、「单次前向」为什么快

延迟差异不是玄学，它来自两种根本不同的工作方式：

生成式 LLM（自回归）：逐 token 循环，生成 N 个 token 就是 N 次前向
┌──────────┐      ┌────┐   ┌────┐   ┌────┐         ┌────┐
│ 提示词    │ ───▶ │t_1 │ ─▶ │t_2 │ ─▶ │t_3 │ ─ ··· ▶ │t_N │   每步都带着越来越长的
└──────────┘      └────┘   └────┘   └────┘         └────┘   上下文重算一遍

laya（非自回归）：编码一次，决策头一次读出完整分布
┌────────────────┐      ┌────────────────┐      ┌─────────────────┐
│ 状态文本        │ ───▶ │ 单次前向编码    │ ───▶ │ choice / score / │
│ + 问题 + 选项   │      │ （无解码循环）  │      │ noul 的完整分布  │
└────────────────┘      └────────────────┘      └─────────────────┘
​

生成式 LLM 回答一个分类问题，也要一个 token 一个 token 地把答案「写」出来，写之前还要把整个提示词过一遍、写的过程中上下文越滚越长；laya 不写答案，它对每个选项打一个分，一次前向同时给出所有选项的概率。答案长度为零、无循环依赖，这就是几十毫秒与秒级的差距来源，也是 BERT 级参数量的模型在 CPU 上也能跑的原因。

推论一：判断题不需要生成。你的问题如果是「这条工单属于哪类」，你需要的只是一个分布，而不是一段话。

推论二：分布比文本更好接工程。概率可以设阈值、可以校准、可以在低置信时弃权转人工——文本只能再解析一遍。这条推论会在第 1.1 节展开成完整论证，并在第 7 章变成置信门控的实操。

再往下钻一层：官方口径的 32.8 毫秒是一次完整决策的端到端时间，拆开看大致三段（比例为量级示意，非精确值）：

这张表解释了两个常见现象：输入文本越长延迟越高（编码段与长度正相关），选项数量对延迟影响很小（决策头只在选项数上做轻量计算，量级判断）——后者正是高基数问题（第 6 章）算的是「质量账」而不是「速度账」的原因。

三、laya 适合什么

共同特征有三条：一是判断有明确选项或刻度（choice / score / noul 装得下）；二是调用频率高到延迟和成本成为一等约束；三是数据敏感或体量大到自托管有吸引力。三条都占，laya 基本就是正确答案；占一两条，去第 9 章三向选型里再核对一次。

四、laya 不适合什么

• 开放生成：写文案、写代码、总结长文。laya 没有生成循环，它不产出新文本，只在你给的选项上打分。
• 多步推理：数学计算、长链逻辑推演。这是 System 2 的地盘——可以用 laya 做前置分流（判断「这条要不要升级给大模型」），但别让它做推理本身。
• zero-shot 直接上线：这条最容易被忽略。官方 README 明确声明：底座检查点 zero-shot 表现接近随机猜，laya 的价值在微调。换句话说，装好就问、拿到一个看起来合理的概率、然后直接上线——是最典型的误用路径。正确的节奏是第 3 章跑通、第 5 章微调、第 7 章校准，最后才谈上线。

五、laya 与 Jev：同门两条路线

把两者放在一张表上，差异一目了然：

注意倒数第二行：laya 官方并不讳言自己的短板，这反而是选型时可信度加分的信号。第 4 章会展示两者同线协议（POST /v1/systemone）——Jev 客户端改一个 baseUrl 就能直连 laya-serve，这意味着「重要链路用 Jev、高频长尾用 laya」的混合架构成本极低。

六、上线前的两条诚实提醒

1. zero-shot 接近随机猜（官方声明）。 拿到底座检查点直接问业务问题，输出的概率分布大概率不可用。别把 demo 里的好看数字当能力——那是微调后才该出现的东西（typed 基准微调后 0.362 升到 0.766，官方口径，第 5 章展开）。
2. 高基数场景 Jev 更强（官方承认）。 选项约 20 个以上时，先考虑第 6 章的两段式（shortlist 加 tournament），两段式仍不够再换 Jev，混合架构下这只是一条链路的事。

七、成本视角：延迟之外的账

延迟之外还有一本账。同样「每天一百万次判断」，三种引擎的成本结构完全不同：

给自己算这笔账的方法：用第 3.2 节的基准方法测出自己环境的单次延迟与吞吐，乘以业务调用量，再对照各 API 的官方定价页——本书不代填价格数字，只给算式结构。自托管的隐性成本也要记进账：部署与监控（第 4 章）、微调投入（第 5 章）、能力上限（高基数不如 Jev，官方承认）。但「固定成本封顶」这条对调用量可预期的业务是最强的成本防御：流量高峰不会变成账单高峰。

八、迁移路径：从关键词系统渐进接入

已有规则或关键词系统的团队不必推倒重来，渐进三步走：

这条路径成立的前提，仍是官方诚实声明的反面：影子期看到的判断质量取决于检查点是否已微调（第 5 章）——zero-shot 阶段的影子数据只能看接口形态与延迟，不能当能力证据。

回到本节开头的问题：为什么已经有了生成式 LLM 还需要 laya？现在可以给完整答案：不是因为后者更聪明，而是因为在「高频、封闭选项、要概率不要文章」的那一大类判断里，它用几十毫秒与固定成本把这件事做对了——而这类判断，恰好藏在几乎每个系统的每一条入口链路上。

本节要点回顾

• 四层谱系：规则（快而笨）→ laya（快而懂语义）→ Jev（懂语义、托管）→ 生成式 LLM（慢而全能）。
• laya 快的根源是非自回归：编码一次、打分一次，无解码循环，CPU 可跑。
• 适用：高频路由、内容审核、意图分类、多语言筛选；不适用：开放生成、多步推理、zero-shot 直接上线。
• 与 Jev 同线协议、可混部：重要链路 Jev、高频长尾 laya。
• 两条诚实提醒：zero-shot 接近随机（先微调）、高基数不如 Jev（走两段式或换 Jev）。

位置想清楚了，接下来是路线问题：你属于哪种读者、该按什么顺序读这本书、动手前要准备什么。下一节给出三条学习路线和一份三分钟就能跑完的环境自检。