Jev 案例库：20 个按输入和问法拆开的落地参考

白日梦想家 内容创作者 2026-09-21 112 阅读

先说结论

  • 官方 use-case map 把落地场景分为五大类：AI 自动化软件、实时应用、大数据 Map-Reduce、通用验证、Harness 工程；为了可落地，本文按高频实操拆成五个类：AI 自动化软件、实时应用、大数据 map-reduce、客服/工单、内容与检索，其中前三类对应官方顶层，后两类是官方地图中高频出现的子场景。
  • 下面整理的 20 个案例，每个都给出 state 放什么、问法（Choice/Score/Noul 及 criteria 要点）、返回什么、下游怎么用四栏。来源要分清：其中约一半直接对应官方 cookbook 或官方 demo（已在各条给出链接，可点开核对）；其余来自官方 use-case map 里点名的行业场景，但 state 里放什么、criteria 怎么写、阈值取多少，都是我的做法或推断，不是官方原文。也就是说，这 20 条是「可照着改的参考」，不是 20 份官方现成配方。
  • 三个最值得先抄的官方 cookbook 是：Guardrails for LLMs（输入输出护栏）、Re-ranking（BM25 短名单重排）、Double-checking Citations（引文核对），分别解决安全、检索精度、可溯源问题。
  • 选型速查看四个信号：高频、结构化、要不确定度、要可编程输出。

官方地图怎么读

官方 use-case map（链接）把 TypeSafe/Jev 的适用场景划分为 AI Automation Software、Real-time applications、AI Map Reduce over Big Data、Universal Verification、Harness Engineering 五类。其核心思想是：代码控制流程，Jev 只做窄而明确的语义判断。官方 how-to 也强调：state 只放当前问题需要的上下文，问法要原子化。

关于「多个问题一起发」，官方的原话是「同一请求里的每个问题看到同一个 state，独立评估，并在你选定的 ID 下返回类型化答案」（Primitives，原文：Every question in a request sees the same state, is evaluated independently, and returns a typed answer under the ID you chose）。并行这件事官方是有明确说法的：官方 “How to build with System One” 文档里写着 “Questions are evaluated independently and in parallel”，并且官方专门有一篇 Parallel questions cookbook 讲这个用法。所以正确表述是：同一次请求里的多个问题会被并行评估（官方数据）；至于底层怎么调度，官方没有展开，本文也不替它下结论。

三种 primitive 分别是 Choice（选一个选项）、Score（选一个级别）、Noul（判断是否为真，返回 0~1 概率），官方字段说明见 Primitives。下面所有案例都沿用“state + question + threshold/组合”的骨架。

先认清三种问法各自的返回形状

这一点是所有案例共用的地基，也是最容易写错的地方，所以直接引官方字段表。官方把三种问法的返回列得很清楚：Choice 返回 choice、probabilities、confidence；Score 返回 score、legend、probabilities、confidence；Noul 只返回 noul（0 到 1）。官方对字段类型的定义是：legend 是 map<string, string>——把每个等级序号映射回它的描述；probabilities 是 map<string, number>——把每个等级（字符串键）映射到它的概率，各概率之和为 1（官方 API reference）。注意两个都写着 map：它们是按序号索引的对象，不是数组。官方给出的 Score 答案示例就是这个形状：

{
  "type": "score",
  "score": 1.05,
  "legend": { "0": "Calm", "1": "Frustrated", "2": "Very angry" },
  "probabilities": { "0": 0.0, "1": 0.95, "2": 0.05 },
  "confidence": 0.92
}

官方 Quick start 里的响应示例同样是对象形态（legend 为 {"0": "Calm, just stating facts", "1": "Frustrated but civil", "2": "Very angry, strong language"}，probabilities 为 {"0": 0.0, "1": 1.0, "2": 0.0}），而 model 是响应顶层字段，与 answers、usage 同级（官方 Quick start）。另外，官方的 Score 是「概率加权后的位置」，可以落在两个等级之间（示例里 score 是 1.05 而等级只有 0/1/2），所以别把 score 当成整数等级序号去用。

20 个可直接抄的场景

一、AI 自动化软件（可后台跑一百万次）

  1. 科学论文筛选（系统综述）

    • state：论文标题、摘要、方法段；纳入/排除标准。
    • 问法：Noul，instructions 写“该研究是否符合纳入标准？”criteria.true 写“明确符合人群/干预/对照/结局”，false 写“缺关键信息或属于排除类型”。
    • 返回：noul 0~1。
    • 下游：设阈值自动纳入、排除或转人工复核。（官方来源：use-case map “Scientific discovery”；criteria 写法为我的做法）

  2. 招聘简历评估

    • state：简历文本、职位要求、必备技能列表。
    • 问法：多个 Noul，例如“候选人相关经验是否达到要求？”criteria.true 写“明确列出超过 3 年相关经验”。
    • 返回：每个条件一个概率，代码加权组合后排序。
    • 下游：自动筛掉明显不匹配者，高概率进面试队列，低置信度转人工。（官方来源：use-case map “Recruiting”；组合逻辑是我的做法）

  3. 潜在客户评分

    • state：公司描述、职位、入站消息、理想客户画像文本。
    • 问法：Score，criteria 设四级 cold / lead / high_intent / payment_signal，可再配 Noul 检查“是否提到预算或时间点”。
    • 返回：level + probabilities。
    • 下游：销售按分数排序、路由给不同团队或触发培育流。（官方来源：use-case map “Lead generation”）

  4. 保险理赔分类

    • state：首次损失通知、调停人笔记、支持文件。
    • 问法：Choice，criteria 为 straight_through / specialist_review / fraud_review / missing_info。
    • 返回：choice + confidence。
    • 下游：confidence 高时直接进入快速处理，不确定转人工调停人。（官方来源：use-case map “Insurance claims”）

  5. 金融犯罪警报优先级

    • state：交易描述、KYC 文档、警报历史。
    • 问法：Score，criteria 设风险等级 low / medium / high / critical，再配 Noul 检查“交易方名称是否不一致”。
    • 返回：风险等级和证据质量概率。
    • 下游：优先调查高风险案件，低风险自动关闭。（官方来源：use-case map “Financial crime”）

二、实时应用（<150ms 决策）

  1. 智能家居助手意图分类

    • state：用户语音转写、设备列表、场景上下文。
    • 问法：Choice，criteria 为 turn_on / turn_off / set_temperature / ask_status / other。
    • 返回：choice + 概率分布。
    • 下游：代码根据 choice 调用相应设备 API；低置信时追问用户。（官方来源：官方 demo “Smart home assistant demo”）

  2. 实时函数调用参数校验

    • state：用户输入、函数 schema、参数约束。
    • 问法：Noul，instructions 写“该参数值是否符合 schema 约束？”，criteria 写具体约束如“必须是 ISO 日期格式”。
    • 返回：noul。
    • 下游：低概率时在调用前拦截并返回澄清消息，而不是让函数调用失败。（官方 cookbook：Function calling；criteria 为我的做法）

  3. 对话结构恢复

    • state：LLM 生成的自由文本、期望 JSON 模板。
    • 问法：Choice 或 Noul，逐字段判断文本中是否存在该字段值。
    • 返回：概率或选项。
    • 下游：把不可靠的自然段落转成可靠的结构化记录，用于 UI 渲染或工作流。（官方 cookbook：Structure recovery）

  4. 游戏内即时语义判断

    • state：玩家输入、当前场景规则。
    • 问法：Noul，例如“玩家是否在要求交易？”criteria.true 写“包含交换物品意图”。
    • 返回：noul。
    • 下游：在 UI 中立即弹出交易窗口；官方地图提到 150ms 实时速度足以嵌入 UI 或游戏（官方数据）。（官方来源：use-case map 提到 real-time applications；具体游戏案例为我的做法）

三、大数据 map-reduce（批量跑大规模语料）

  1. 知识图谱实体对齐

    • state：两个实体名称及其属性上下文。
    • 问法：Noul，instructions 写“这两个名称是否指向同一实体？”
    • 返回：noul。
    • 下游：高概率合并实体，构建更干净的知识图谱。（官方 cookbook：Knowledge graph entity alignment）

  2. 自一致性校验

    • state：同一问题的多次 LLM 输出。
    • 问法：Choice 或 Noul，判断输出之间是否一致。
    • 返回：一致概率。
    • 下游：低一致性的任务重跑或升级；在批处理中过滤不稳定结果。（官方 cookbook：Self-consistency，官方分为 Choice 与 Noul 两篇，consistency_choice / consistency_noul；具体实现细节未能完全核实）

  3. 大规模 agent trace 分类

    • state：agent 运行轨迹文本、预定义类别（成功/失败/卡住/偏离）。
    • 问法：Choice，criteria 为这些类别。
    • 返回：choice + probabilities。
    • 下游：批量定位问题 agent 步骤，给产品改进提供数据。（官方来源：use-case map 提到 classify giant agent traces；criteria 为我的做法）

  4. 自然语言特征提取用于预测建模

    • state：原始文本、特征定义（例如“是否提到续约风险”）。
    • 问法：Noul 或 Score，按特征类型决定。
    • 返回：每行样本一个概率列。
    • 下游：与结构化特征拼接，训练下游模型。（官方来源：use-case map “Feature extraction for predictive modeling”）

四、客服/工单

  1. 工单分类与路由

    • state：工单标题、正文、产品线列表、团队队列。
    • 问法：Choice，criteria 为 billing / technical / account / complaint / refund_request / other。
    • 返回：choice + probabilities。
    • 下游：按最大概率路由到对应团队；低置信时进入“待分类”队列让人确认。（官方来源：use-case map “Customer support”）

  2. 客服回复合规校验

    • state：客服草稿回复、公司政策、客户原始请求。
    • 问法：Noul，instructions 写“回复是否违反政策或未处理客户请求？”，criteria.true 写“包含退款但未按政策处理”等。
    • 返回：noul。
    • 下游：高违反概率时阻止发送，强制走人工审核。（官方来源：use-case map “Customer support – Verify support responses”）

  3. 通话记录提取承诺与后续行动

    • state：客服通话转写文本。
    • 问法：Noul，instructions 写“通话中是否产生了一个客户承诺或后续行动？”criteria.true 写“包含具体承诺、时间或责任人”。
    • 返回：noul，可再配一个 Score 判断优先级。
    • 下游：把命中的段落抽取出来生成待办列表，自动同步到 CRM。（官方来源：use-case map “Customer support” 中“extract customer issues, commitments, and follow-up actions”；分步问法是我的做法）

五、内容与检索

  1. 海量文档重排（RAG 检索）

    • state：查询文本 + 每个候选段落（BM25 短名单）。
    • 问法：Noul，instructions 写“这个候选段落是否来自被引用的先例？”，criteria.true 写“段落陈述了查询所引用的具体规则”，false 写“仅主题相似”。
    • 返回：noul 0~1，作为排序分数。
    • 下游：按分数重排短名单，top-k 送给生成模型。官方 cookbook 用 CLERC 数据集的 3,565 个法院意见段落、40 条查询、每条 30 个 BM25 候选做测试：top-1 准确率从 5% 提到 18%，top-10 从 38% 提到 62%（官方数据）。（官方 cookbook：Re-ranking，链接）

  2. 引文核对

    • state：源文档文本、LLM 生成的 claim 与 quote。
    • 问法：Choice，criteria 为 verified / unsupported / contradicted / fabricated；先用字符串匹配筛掉缺失引文，再对幸存引文问 Choice。
    • 返回：choice + confidence。
    • 下游：低于 AUTO_ACCEPT 阈值（官方示例设为 0.8）转人工。官方 cookbook 中 8 个引文里 4 个正确返回 verified 且置信 ≥0.93，4 个植入错误全部被抓（官方数据）。（官方 cookbook：Double-checking citations，链接）

  3. RAG 段落分类

    • state：问题、检索到的段落。
    • 问法：Choice 或 Noul，判断段落是否包含答案、是否与问题相关。
    • 返回：choice/概率。
    • 下游：过滤掉无关段落，只把相关段落给下游生成，减少幻觉。（官方 cookbook：Classifying RAG passages）

  4. 逐行搜索长文本

    • state：长文档、要找的信息描述。
    • 问法：Noul 逐行或分块判断“该行是否包含目标信息”。
    • 返回：每行/块 noul。
    • 下游：定位确切出处，或作为结构恢复前的预处理。（官方 cookbook：Line-by-line search）

以上二十个案例里，智能家居意图分类、函数调用参数校验、对话结构恢复、知识图谱实体对齐、自一致性校验、海量文档重排、引文核对、RAG 段落分类、逐行搜索这九个直接对应官方 cookbook 或官方 demo（已在各条里给出链接）；其余对应官方 use-case map 中的行业场景，而 criteria 细节是我的做法。

三个必须会的官方 Cookbook

  1. Guardrails for LLMs（链接）
    用途：在 LLM 输入和输出两侧做安全护栏。官方方法是用一组 Noul 问题检测“是否试图覆盖助手指令”“是否求助伤害行为”“是否要求诊断/剂量”“是否表达自伤”，再用一个 Score 问题评估合规严重度（从“无”到“严重身体伤害”）。应用层根据概率阈值决定 pass / review / block / route。

  2. Re-ranking（链接）
    用途：先 BM25/嵌入召回短名单，再用 Jev 对每个 query-candidate 打分。官方 cookbook 在 3,565 个法院意见段落、40 条查询上测试（每条查询从共享语料里选 30 个候选），重排前 top-1 5%、top-10 38%，重排后 top-1 18%、top-10 62%（官方数据）。

    关于「一个候选一次请求」这个用法，要分清两层：官方 cookbook 明确写的是「本文为了讲清楚，每个 query-candidate 对只问了一个问题」，并接着说真实应用会把同一个 pair 的多个问题放到一次调用里（原文：This walkthrough asked one question per pair for clarity. A real application would ask several questions about the same pair in one call），并指到 Parallel questions cookbook 与 Speculative Fan-Out 模式。所以「每候选一请求」是那篇 cookbook 的讲解简化，不是官方推荐的最终形态；要不要合并请求、怎么分批，属工程取舍。

    有官方依据的核心只有一条：Noul 直接返回 0~1 的概率，可以直接当排序分数用，不必自己发明一套评分量表——官方对此的表述是 TypeSafe 就是为这种重复打分场景设计的，做起来更快、更省、更一致。

  3. Double-checking Citations（链接）
    用途：验证 LLM 回答的引文是否真的支持 claim。先用字符串匹配检测引文缺失，再用 Choice 判断有引文的情况是 verified / unsupported / contradicted / fabricated。官方例子中 8 个引文里 4 个正确返回 verified 且置信 ≥0.93，4 个错误全部被抓（官方数据）。适合作为 RAG 系统的可溯源校验层。

一个最小的 Noul 重排调用示例（改写自官方 cookbook 的伪代码，实际参数以 SDK 为准）：

from typesafe_sdk import Noul, NoulCriteria, TypeSafeClient

client = TypeSafeClient(api_key=...)
question = Noul(
    instructions="这个候选段落是否来自被引用的先例？",
    criteria=NoulCriteria(
        true="段落陈述了查询所引用的具体规则。",
        false="段落仅主题相似，没有明确规则。"
    )
)
response = client.system_one(
    state={"query": query_text, "candidate": candidate_text},
    questions={"is_cited_source": question}
)
score = response.answers["is_cited_source"].noul  # 例如 0.87

选型速查：你的场景是否适合 Jev

符合以下信号越多，越适合把决策交给 Jev：

  • 高频：每天几万次以上，人工看不过来，或通用 LLM 成本太高。
  • 结构化输出：你需要一个字段值、一个枚举、一个概率，而不是一段散文。
  • 要不确定度：你需要知道模型自己有多不确定，从而决定 pass / review / block。
  • 可编程组合：最终决策由多个窄判断在代码里用 if / threshold / 权重拼接，而不是让模型自由发挥。
  • 可解释阈值：业务方希望看到“为什么路由到这里”，需要 criteria 明确定义 true/false。

如果任务是开放式写作、长程复杂推理或需要多步 agent 自由探索，可能不适合只靠 primitive，应拆解或换架构。

这次没核实的

  • 官方顶层五大类与工单要求的“客服/工单、内容与检索”并非一一对应，我按官方 use-case map 的高频子场景做了重新归类；具体归类是我的判断。
  • 案例 11 涉及的 Self-consistency 教程在官方站上分成两篇（Choice 与 Noul 各一篇），其具体实现细节、API 参数和阈值在本次来源正文中未完全呈现，未能核实，仅根据 cookbook 标题与用途作了方向性描述。
  • 案例 9 的游戏内即时判断，官方地图只提到“fast and smart enough to be programmed to play games or embedded into a UI”，没有给出具体 criteria 或测试数据，我的做法是推断。
  • 官方未给出“20 个案例”的现成清单，本文的案例数量、四栏拆法以及 criteria 写法大部分是基于官方字段形状的整理，不能视为官方文档原文。

参考来源

# 教程# 知识

评论区

0 条评论

登录后可评论。

白日梦想家 112 阅读