1.3 现有三种办法的困境
1.3 现有三种办法的困境
本节摘要：在 Jev 出现之前，软件里做语义判断通常有三种办法：关键词/正则（脆弱——语言的花样远超模式匹配）、小分类器（每个决策要标注、训练、部署、维护 N 个模型，需求一变就重训）、调用 LLM 加结构化输出（慢则秒级贵则分钱，概率未校准，输出还要防御性解析）。本节逐一拆解三种办法的失效方式，并给出 Jev 的第四种定位：零训练、零标注、开箱即用的判断原语。这张对比表也是第 10 章选型讨论的基础——四种办法各有胜场，Jev 不是万能答案。
学习目标
阅读完本节，你应当能够：
- 说出三种现有办法各自的典型失效场景。
- 解释"小分类器维护 N 个模型"的成本结构问题。
- 复述 Jev 的定位：判断原语，以及它仍然不替代确定性 if 的原因。
一、办法一：关键词 / 正则
if "紧急" in text or "马上" in text or "asap" in text.lower(): escalate()
**困境：脆弱。**语言表达同一意图的方式是开放的："我再等下去就要去投诉了"没有命中任何关键词，但它比包含"尽快"的客套话紧急得多。正则的维护是一场军备竞赛：每漏一个 case 加一条规则，每条规则又误伤一批。更糟的是，规则之间的交互随着数量增长而失控。
适用：机器可计算的条件（长度、格式、精确匹配）——这些本来就不该换成语义判断。
二、办法二：小分类器（fastText / BERT 微调）
困境：固定成本高、流动性差。
需求 → 收集标注数据 → 训练 → 部署 → 监控漂移 → 需求变了 → 重来
每个决策点一个模型：工单分类一个、紧急度一个、内容审核一个……标注数据从哪来？谁来维护？阈值怎么定？对于"判断标准会随业务演化"的场景（审核政策调整、新增产品线），小分类器的迭代成本让人宁愿回到人工。它胜在：判据稳定、有大量标注数据、日请求千万级时，单次成本最低、完全可控（第 10 章选型表会再见到它）。
三、办法三：LLM + 结构化输出
prompt = "判断以下工单是否紧急，只回答 JSON：{\"urgent\": true/false}"
困境：慢、贵、概率不可信。
- 延迟：3 秒到 5 分钟（官方 workflow 评测里 LLM 基线的端到端范围），做不了实时路径；
- 成本：按 token 计价且输出也计价，高频场景账算不过来；
- 概率：要么不给概率，要么给未经校准的"自信表述"——LLM 说"80% 把握"时，实际命中率可能只有 60%；
- 防御成本：JSON 解析失败、字段缺失、回答里夹带"当然！这里是您的 JSON："——都逼着你写一堆防御代码。
它胜在：判断需要推理（多跳、计算、长上下文综合）或顺路要在同一调用里生成内容时。
四、Jev 的定位：第四种办法
| 关键词/正则 | 小分类器 | LLM+结构化输出 | Jev | |
|---|---|---|---|---|
| 语义理解 | ✗ | ✓ | ✓✓ | ✓ |
| 延迟 | ~0ms | ~10ms | 3s~5min | 70~500ms |
| 单次成本 | 0 | 极低 | 高 | ~$0.00001 |
| 概率 | — | 可校准但费劲 | 未校准 | RLCD 校准 |
| 部署成本 | 低 | 高（标注/训练/运维） | 低 | 零（声明即用） |
| 判据可改 | 改规则 | 重训练 | 改 prompt | 改 instructions |
Jev 的定位：零训练、零标注、开箱即用的判断原语——像调用一个永不宕机的"人类直觉"函数。判据就是你在请求里写的自然语言 instructions，改判据 = 改一句话 + 跑一遍回归集（第 9 章）。
⚠️ 两条边界先立好（第 8、10 章展开）：
- 能用确定性
if的地方别换 Jev——if len(x) > 0换成语义判断是花钱买不稳定；- Jev 的"零幻觉"保证的是形状（不产出枚举外的值），不保证判断正确——这个区分是第 10 章核心批评的主角。
本节要点回顾
- 正则：脆弱，军备竞赛；机器可计算的条件本来就该留给它。
- 小分类器：判据稳定 + 超大量 + 有标注时仍是首选；判据常变时成本高。
- LLM 兜圈子：慢、贵、概率未校准；需要推理或顺路生成时仍不可替代。
- Jev：判断原语——声明即用、判据即自然语言、概率经校准。
四种办法的地图有了，Jev 长在正则与小分类器够不着、LLM 又太重的那块地上。下一章我们把 Jev 本身拆开看：输入什么、输出什么、怎么想它才不会用错。