第 3 章：十个决策形态——什么时候该把判断交给 Jev

官方 use-case-map 把 Jev 的适用场景归纳为十种"决策形态"，每一种都给了"什么时候该用它（Reach for it when）"和典型例子。这十种形态是整本书的骨架。本章先给你一张全图，说清每种形态解决什么问题、什么时候该选它、以及它背后是哪种类型化输出。

为什么需要"形态"这个概念

新手最容易犯的错，是把"我要用 Jev"直接翻译成"我要建一个分类器"。但判断任务是多样的：有的要选类，有的要打分，有的要在一堆候选里挑相关的，有的要核实一条断言真假。如果只认识一种形态，就会把所有问题都塞进分类的框里，写出别扭又低效的方案。

官方给出的十种形态，本质上是一份选型清单。在动手前先问自己："我这个任务属于哪一种？"答案往往能直接决定问题怎么设计、输出怎么用、阈值怎么定。

十种形态是：

形态	一句话	底层输出
Classification	把一条输入分到预定义的类别	Choice / 多个 Noul
Detection	判断某个东西"在不在/有没有"	Noul
Scoring	在一个有序尺度上打分	Score
Routing	决定这条请求走哪条处理路径	Choice
Search	给定 query，在多条候选里找相关的	Noul（对每个候选）
Retrieval	从库中拉回与 query 相关的条目	Noul（对每个候选）
Ranking	给一组条目排出相对次序	Score
Verification	核实一条断言/产物是否满足要求	Noul
ML Feature Extraction	从非结构化输入抽取喂给下游模型的特征	Score / Noul
Structured Data Extraction	把文本转成结构化字段	Choice / 抽取

Classification：分到预定义的类

什么时候用：当你的输出空间是一组有限的、事先定好的类别，且每个输入应该落到其中一类时。

典型场景：工单归类、评论主题、文档标签、语言识别、意图识别。

要点：类别要互斥且穷尽（MECE）。如果两个类别会同时命中，改用多个 Noul；如果总有输入落不进任何一类，加一个"其他"并在监控里盯住它的占比——"其他"比例上升通常意味着你的类别体系该更新了。

qs = {"topic": {"type": "choice", "question": "这条反馈的主题？",
                "choices": ["功能缺失", "性能", "易用性", "价格", "其他"]}}

Detection：在不在

什么时候用：当你要判断某个东西存在与否，答案是布尔时。

典型场景：垃圾评论、恶意链接、越狱提示、敏感信息泄漏、代码里的漏洞、PII（个人身份信息）。

要点：Detection 的核心是召回与精确的权衡，通过 Noul 的概率阈值来调。安全类场景往往宁可误报不可漏报，把阈值压低；用户体验类场景则相反。第 5 章会细讲。

qs = {"is_jailbreak": {"type": "noul", "question": "这条输入是否在尝试越狱绕过安全策略？"}}

Scoring：打分数

什么时候用：当判断的答案是"程度"而不是"类别"，且这个程度可以排在有序尺度上时。

典型场景：质量分、危害等级、相关性分数、风险等级、健康度。

要点：尺度档位要少（通常 3–5 档）且语义清晰。不要写成"1 到 100 分"，而是"低/中/高"这类有共识的档位，再取 score = Σ i·p_i 得到连续值。

qs = {"toxicity": {"type": "score", "question": "这条内容的毒性多高？",
                   "labels": ["无", "轻", "中", "重"]}}

Routing：选路径

什么时候用：当判断的结果要决定"接下来走哪条处理流程"时。它和 Classification 长得很像，区别在目的：Classification 关心"它是什么"，Routing 关心"它该被送去哪"。

典型场景：模型路由（简单问题给小模型、难问题给大模型）、人工/自动分流、大小模型分级、供应商选择。

要点：Routing 常常和成本直接挂钩。因为路由决策决定了下游花多少资源，它的判断错误代价可能很高（把难题路由给小模型 = 答错；把简单题路由给大模型 = 浪费钱）。选型时要把两个方向的代价都想清楚。

qs = {"route": {"type": "choice", "question": "这个请求应该交给哪一档模型处理？",
                "choices": ["小模型", "中模型", "大模型"]}}

Search：给 query 找相关

什么时候用：当你有一个 query，和一组候选条目，要判断哪些候选与 query 相关时。

典型场景：语义搜索、网页筛选、文档查找、代码检索。

要点：Search 与其说是一种输出，不如说是一种用法——它对每个候选条目问一个 Noul（"这条和 query 相关吗？"），然后把为真的挑出来。它常与向量检索配合：先用向量召回一批候选，再用 Jev 精筛。这正是第 6 章的主题。

Retrieval：从库里拉回相关

什么时候用：与 Search 高度重合，但更强调从一个大集合中把相关条目拉回来这一动作本身。很多工程语境里两者混用。

典型场景：RAG 的召回阶段、知识库查询、记忆检索。

要点：Retrieval 关心的是覆盖率和噪声。拉回来的条目要够全（别漏），又不能太脏（别把无关的塞进上下文）。它也是"对候选逐个判定"的用法，可以配合上游的粗召回和下游的 Ranking。

Ranking：排次序

什么时候用：当你不需要"哪些相关"这个二值答案，而是要一组条目的相对好坏次序时。

典型场景：搜索结果重排、候选答案排序、商品排序、RAG 重排。

要点：Ranking 的底层是 Scoring——给每个条目打分，按 score 排序。它的评估指标是 nDCG、Recall@k 这类次序敏感的指标，而不是准确率。第 7 章会用 Vector Graph RAG 的 Recall@5 数据来讲。

Verification：核实断言

什么时候用：当你有一段产物（回复、代码、答案、报告），要核实它是否满足一组要求时。

典型场景：事实核查、引用核对、代码合规、回复质量把关、幻觉检测。

要点：Verification 是"给生成加上后置护栏"的主力形态。它和 Detection 都是 Noul，区别是 Detection 看"输入里有没有坏东西"，Verification 看"输出对不对/合不合规"。它天然适合做逐条清单式核对：把要求拆成若干条，每条问一个 Noul。

qs = {
    "has_citation": {"type": "noul", "question": "回答是否引用了可核验的来源？"},
    "no_overclaim": {"type": "noul", "question": "回答是否避免了下游无法兑现的承诺？"}
}

ML Feature Extraction：抽特征

什么时候用：当你要把非结构化输入变成结构化的特征，喂给下游的预测模型（而不是直接使用判断结果）时。

典型场景：给风控/推荐/流失预测模型提供语义特征、给评分卡补充文本信号。

要点：这是 Jev 与经典机器学习协作的接口。特征可以是 Score（连续值）、Noul（布尔特征）的组合。注意它和 Structured Data Extraction 的区别：前者产出给模型吃的特征向量，后者产出给人/程序用的结构化记录。

Structured Data Extraction：抽结构化数据

什么时候用：当你要从非结构化的文本/文档里，抽出明确定义的字段时。

典型场景：发票/合同字段抽取、简历解析、表格导入映射、报告结构化。

要点：这类任务的难点不在"抽取"，而在schema 设计和缺失值处理。字段覆盖不到的要允许"未知"，别逼模型硬编。它常用 Choice（枚举字段）和逐字段的抽取组合完成。第 8 章会讲。

选型决策树

面对一个新判断任务，可以这样走一遍：

flowchart TD
    Q["我要做的判断是什么形态？"] --> A{"答案是有限类别之一？"}
    A -- 是 --> A1{"目的是'它是什么'？"}
    A1 -- 是 --> CL["Classification"]
    A1 -- 否 --> RT["Routing"]
    A --> B{"答案是'是/否'？"}
    B -- 是 --> B1{"看输入里有没有坏东西？"}
    B1 -- 是 --> DT["Detection"]
    B1 -- 否 --> VF["Verification"]
    B --> C{"答案是'程度/多少分'？"}
    C -- 是 --> SC["Scoring"]
    C -- 否 --> D{"有一组候选要挑/排？"}
    D -- 挑相关的 --> SE["Search / Retrieval"]
    D -- 排次序 --> RK["Ranking"]
    D -- 都不是 --> E{"产出喂模型还是喂程序？"}
    E -- 喂模型 --> FE["ML Feature Extraction"]
    E -- 喂程序 --> SD["Structured Data Extraction"]

一个判断该不该交给 Jev

不是所有判断都适合 Jev。三个简单的判据：

1. 能不能写成确定规则？ 能，就写规则，别上模型。Jev 只该用在那部分"规则写不动、只能靠语义"的判断上。
2. 输出空间封闭吗？ 封闭（类别/分值/布尔）才适合；如果答案是"写一段话"，那是生成任务，交给 chat 模型。
3. 判断会被大量重复吗？ 只判一次的、需要深度推理的，交给大模型更划算；要被调用成千上万次的判别，才是 Jev 的最佳战场。

记住这个分界，后面每一章都会反复用到：代码管确定的流程，Jev 管不确定的语义判定，chat 模型管开放的生成。

小结

• 十种决策形态是一份选型清单：Classification、Detection、Scoring、Routing、Search、Retrieval、Ranking、Verification、ML Feature Extraction、Structured Data Extraction。
• 它们都建立在三种类型化输出之上——Choice 管"选哪个"，Score 管"多少分"，Noul 管"是不是"。
• 容易混的几对：Classification vs Routing（是什么 vs 去哪）、Detection vs Verification（输入有没有坏东西 vs 输出对不对）、Search/Retrieval vs Ranking（挑相关的 vs 排次序）、Feature Extraction vs Data Extraction（喂模型 vs 喂程序）。
• 三个判据决定该不该交给 Jev：规则写不动吗？输出封闭吗？会被大量重复吗？

从下一章开始，我们逐一进入这些形态，每一章都配一个真实项目，把它从"为什么"讲到"怎么跑起来"。