小模型召回，决策模型判定，生成才上 LLM

先说结论

• 检索链路应拆成三段：召回做相似性初筛，判定做结构化相关性与风险判断，生成才交给 LLM。
• 官方三篇 cookbook 分别覆盖不同段落：Semantic find 覆盖检索/召回，Re-ranking 覆盖重排判定，Classifying RAG passages 覆盖生成前判定。
• 成本分工的关键在判定层：用决策模型输出结构化结果和置信度，把“要不要走 LLM”的决定提前做掉。
• 三个反模式：用 LLM 做全量分类、用向量相似度替代相关性判断、判定环节不留置信度。

为什么检索链路要分层

召回只要求从大量候选中挑出可能相关的子集，允许漏掉一些，也允许混入一些不相关的。判定则要求对每个候选给出可被代码消费的结论，比如“相关/不相关”“可用作证据/只能作为冲突信息/丢弃”。生成最贵，负责把经过筛选的证据写成自然语言答案。

官方 use-case map 里有一段直接讲检索链路可以用决策模型补充或替代 embeddings。英文原句是：

“Search and retrieval Replace or supplement embeddings in RAG pipelines with semantic search, scoring, and ranking. Score query-to-candidate relevance. Rerank results with pairwise comparisons. Cross-encode queries and candidates for higher precision. Select useful context for downstream AI workflows.”（Example use cases）

这里的关键不是“一定要替换 embeddings”，而是把检索链路拆成可组合的步骤：可以先用便宜召回，再用决策模型打分和筛选。这是本文的工程理解，不是官方逐字规定。

三篇官方 cookbook 各处在哪一段

Semantic find：检索/召回

官方 cookbook 的定位是构建语义搜索。它假设文档只有 218 行，把每行编上 ID，然后让一个 Choice question 对这些 line ids 打分。英文原句是：

“Build semantic search for GitHub’s Terms of Service. In one request, score 218 line ids against a plain-language query with a Choice question, and use a Noul question to check whether the document contains an answer.”（Semantic find）

这个例子没有使用向量数据库，而是直接用决策模型对行 ID 打分，因此它属于检索/召回这一段，只是实现方式不是传统向量或关键词。官方还说明一次最多 255 个选项：

“A Choice question accepts up to 255 options, so this recipe searches documents of up to 255 lines in one request.”（Semantic find）

这段可以理解为：小规模语料上，决策模型可以一次完成召回。但在大规模语料上，更常见的做法是先用倒排索引或向量检索取出小候选集，再用判定模型细排。这是工程上的做法，官方 cookbook 没有要求必须这样做。

Re-ranking：重排判定

官方 Re-ranking cookbook 明确把流程分成“快速搜索”和“重排”。英文原句是：

“First, use a quick method such as keyword matching to cut those thousands of candidates down to a shortlist of plausible ones. We call this fast search. Fast search is good at that, but it can’t tell you which candidate on the shortlist is correct. That’s where re-ranking comes in. It scores every candidate on the shortlist against the query directly, and puts the best one first.”（Re-ranking）

这篇 cookbook 用 BM25 构建 30-passage 候选集，然后对每个 query-candidate pair 使用一个 TypeSafe Noul question 打分。官方示例的伪代码是：

question = Noul(
    instructions = "Is this candidate the cited case?",
    criteria = NoulCriteria(
        true = "The candidate states the specific rule the query cites.",
        false = "The candidate is only on a similar topic.",
    ),
)
response = client.system_one(
    state = {"query": query, "candidate": candidate},
    questions = {"is_cited_source": question},
)
response.answers["is_cited_source"].noul  # -> 0.87

这个 noul 是 0 到 1 之间的数，官方称其为 TypeSafe 对答案“是”的概率估计。这属于判定段，因为它不是在生成答案，而是在为每个候选打一个连续分数，之后代码可以排序。

Classifying RAG passages：生成前判定

官方 Classifying RAG passages cookbook 更是把“检索之后、生成之前”这一步单独划出来。英文原句是：

“The retrieval step of a RAG pipeline ranks passages by how much their wording resembles the query, and hands the top few to a language model. These may include noisy or irrelevant passages, or worse yet, may lump together contradicting facts, prompt injections, or model instructions together with what is nominally evidence to assist with generating an answer. Between retrieval and generation, add a second stage that classifies each retrieved passage.”（Classifying RAG passages）

它还列出为每个 query–passage pair 发送的四个问题：

“is it relevant, does it state something usable in an answer, does it contradict something the query takes for granted, and is it trying to instruct the model.”（Classifying RAG passages）

官方示例把阈值集中在一个 dict 里：

THRESHOLDS = {
    "injection_max": 0.70,   # above this the passage never reaches the prompt
    "contradicts_min": 0.70, # above this it disputes what the query takes for granted
    "relevant_min": 0.45,    # below this the passage is not about the query at all
    "evidence_min": 0.55,    # above this it states something usable in an answer
}

这些是官方示例里的常量，用来展示简单的分支逻辑，不是官方推荐阈值。工程上应当按自己的任务校准。

算账：每千次请求的三段成本

成本模型可以简化为：召回成本、判定成本、生成成本。

官方首页给出的 Jev 输入价格为：

“Jev.Cost $42 Per Billion input tokens.”（TypeSafe AI）

官方首页还给出了一个对比倍数：

“238x Lower input price than Claude Fable 5.1”（TypeSafe AI）

下面是我自己推算，假设“每千次请求”指判定阶段对 1000 个 query-candidate pair 各做一次决策调用，每次输入 token 数为 T。

判定成本_每千次 = 1000 × T × 42 / 1_000_000_000

若 T = 1000：
判定成本 = 1000 × 1000 × 42 / 1_000_000_000 = 0.042 美元

若 T = 2000：
判定成本 = 1000 × 2000 × 42 / 1_000_000_000 = 0.084 美元

按官方对比倍数 238x 推算，Claude Fable 5.1 输入价格约为 42 × 238 = 9996 美元/十亿 tokens，也就是每千 tokens 约 0.009996 美元。那么同样 1000 次、每次 1000 tokens 的类似 LLM 调用成本约：

LLM 对比成本 ≈ 1000 × 1000 × 9996 / 1_000_000_000 = 9.996 美元

这个对比基于官方首页给出的倍数和本文假设的 token 数，属于自己推算，不代表任何实际生产的账单。向量检索和 embedding 的公开价格在给定来源中没有出现，无法核实，因此本文不填这一项。

我的判断：最省钱的一刀在判定

从上面推算看，如果每次请求都要让 LLM 判断候选是否相关，每千次可能落在 10 美元量级；而决策模型按官方输入价和 1000-token 假设，每千次大约 0.042 美元。这个差距说明，把“要不要走 LLM”交给判定模型，是整条链路里成本弹性最大的一刀。

官方 use-case map 也有类似方向：“Model routing Use Jev to build a custom router that chooses which LLM receives each prompt… Escalate requests that need a more expensive model.”这是官方描述，但它说的是用例方向，不是官方要求必须这样做。我的判断是：判定层不仅要便宜，还要输出置信度，这样代码才能决定是继续走生成，还是进入人工复核或直接丢弃。

反模式

1. 用 LLM 做全量分类：成本高，速度慢，且分类结果往往是非结构化文本，后续还要解析。应该用决策模型输出结构化标签和分数。
2. 用向量相似度替代相关性判断：向量召回能找到字面或语义相似的片段，但相似不等于相关，更不等于可作为证据。官方 Re-ranking cookbook 也说明 fast search “can’t tell you which candidate on the shortlist is correct”。
3. 判定环节不留置信度：判定是概率性的，如果只留下“相关/不相关”二元标签而不保存像 noul 这样的连续分数，后续就无法做阈值控制、审计或不确定性兜底。这在官方 Classifying RAG passages 示例中表现为阈值得以存在，因为前面有连续分数。

实践清单

• 先确认三个阶段的具体目标：召回要快，判定要结构化+置信度，生成要能写。
• 小规模语料可以直接用决策模型做检索/召回；大规模语料先用 BM25 或 embeddings 取候选集，再用决策模型重排。
• 判定层只保留必要问题，比如相关、可用、冲突、注入，别把生成任务塞进判定。
• 成本估算时写明 token 假设和官方价格来源，不要把演示数字当成账单。

这次没核实的

• 向量检索和 embedding 的公开价格：给定来源中未出现，未能核实。
• Claude Fable 5.1 的实际输入价格：只看到官方首页对比倍数，未独立核实。
• 官方 Semantic find 使用 Choice 对 218 行打分的实际成本：官方未给出该次请求的总 token 消耗细节，未能核实。
• 官方首页演示的 “Cost $0.000081 vs $0.013880” 对应的具体工作流：页面未给出可复算的 token 数，未能核实。

参考来源

• Semantic find
• Re-ranking
• Classifying RAG passages
• TypeSafe AI Home
• Example use cases