TS TypeSafe 文档中文版
原文 ↗

推测式扇出

在单次调用中发送许多问题，包括推测性的问题，并让你的代码决定哪些相关。

由于 TypeSafe 支持在单次 API 调用中发送许多问题，我们建议把系统需要的所有问题都放进一个请求，然后事后用代码决定哪些相关。所有问题都是并行评估的，因此增加更多问题通常对响应时间几乎没有影响。

示例：支持工单分诊

设想你正在构建一个需要对支持工单进行分诊的支持系统。你需要把工单归类到一个类别。如果它是缺陷报告，你还需要确定缺陷的严重程度。

与其先问类别、再在后续调用中问严重程度，你可以同时问两者。如果工单不是缺陷报告，你只需忽略缺陷严重程度那个问题的结果。

%%{init: {"fontFamily": "Inter, sans-serif", "flowchart": {"rankSpacing": 35, "wrappingWidth": 300, "subGraphTitleMargin": {"top": 8, "bottom": 60}}}}%% flowchart LR t["支持工单"] subgraph req["TypeSafe AI 模型<br/>针对工单<br/>并行评估每个问题"] direction TB c["<b>Choice:</b> 类别"] b["<b>Score:</b> 缺陷严重程度"] r["<b>Noul:</b> 可复现的步骤？"] f["<b>Noul:</b> 请求了退款？"] s["<b>Score:</b> 挫败感"] %% invisible links: without an edge these share a rank and sit side by side c ~~~ b ~~~ r ~~~ f ~~~ s end t -- "一次请求<br/>工单 + 5 个问题" --> req req -- "一次响应：5 个答案<br/>决策 + 概率" --> route{"<b>在你的代码中<br/>筛选、组合并路由</b>"} route -- "bug_report" --> eng["读取严重程度 + 复现步骤<br/>升级或进入待办"] route -- "billing" --> bill["请求了退款<br/>发送给账单团队"] route -- "feature_request" --> feat["记录下来<br/>发送给开发者"]

第 1 步：推测式扇出

questions
{
  "state": "Hi, I placed an order (#98423) last Thursday and was charged twice. I also can't log in after the site update, and adding Apple Pay would be really helpful. This is getting frustrating.",
  "questions": {
    "category": {
      "type": "choice",
      "instructions": "Determine the broad category of this support ticket",
      "criteria": {
        "bug_report": "The user is reporting something that is broken or producing errors",
        "billing": "Charges, invoices, refunds, subscriptions",
        "feature_request": "The user is requesting new functionality",
        "account": "Login, permissions, profile, security"
      }
    },
    "bug_severity": {
      "type": "score",
      "instructions": "How severe is the reported issue",
      "criteria": [
        "Cosmetic; no impact to functionality",
        "Broken or degraded feature; workaround exists",
        "Blocking issue; no workaround exists"
      ]
    },
    "has_reproducible_steps": {
      "type": "noul",
      "instructions": "The user describes specific steps to reproduce the issue"
    },
    "refund_requested": {
      "type": "noul",
      "instructions": "The user is explicitly asking for a refund or credit"
    },
    "frustration": {
      "type": "score",
      "instructions": "How frustrated the user appears",
      "criteria": [
        "Calm, matter-of-fact",
        "Frustrated but civil",
        "Very angry"
      ]
    }
  }
}

这个示例是可交互的；到官网原页面可以直接在 Playground 里运行。

注意

推测性问题： bug_severity 和 has_reproducible_steps 只在工单是缺陷报告时才有意义。refund_requested 只对账单相关的问题有意义。我们把它们全部预先包含进来，因为增加问题通常对响应时间几乎没有影响。如果工单最终是一个功能请求，缺陷严重程度的结果就会变得无关紧要，此时你的代码路径直接忽略它即可。

第 2 步：用代码路由

你的代码根据分类结果决定哪些相关：

triage.py
category = response.answers["category"]
bug_severity = response.answers["bug_severity"]
bug_repro = response.answers["has_reproducible_steps"]
refund = response.answers["refund_requested"]
frustration = response.answers["frustration"]
 
if category.choice == "bug_report":
    if bug_severity.score > 1.5 and bug_repro.noul > 0.6:
        escalate_to_engineering(ticket_id, severity="high")
    else:
        add_to_bug_backlog(ticket_id)
 
elif category.choice == "billing":
    if refund.noul > 0.7:
        route_to_billing_with_flag(ticket_id, refund_likely=True)
    else:
        route_to_billing(ticket_id)
 
elif category.choice == "feature_request":
    log_feature_request(ticket_id)
 
# Frustration is useful regardless of category
if frustration.score > 1.5:
    flag_for_priority_response(ticket_id)

完整决策树所需的一切都来自一次调用。推测性问题在不相关时被忽略，在相关时则省去一次往返。