推测性扇出
推测性扇出
在一次调用里发送许多问题(包括推测性的),由你的代码决定哪些真正相关。
因为 TypeSafe 支持在单次 API 调用里发送多个问题,我们建议把系统需要的所有问题都放进同一个请求,事后再用代码决定哪些相关。所有问题都是并行求值的,所以多问几个通常对响应时间没什么影响。
示例:支持工单分流
设想你在做一个支持系统,需要给支持工单分流。你要先把工单归到一个类别。如果是 bug 报告,还要判断 bug 的严重程度。
与其先问类别、再发一次调用问严重程度,你可以在同一次里把两个都问出来。如果工单不是 bug 报告,直接忽略 bug 严重程度那个问题的结果就行。
%%{init: {"fontFamily": "Inter, sans-serif", "flowchart": {"rankSpacing": 35, "wrappingWidth": 300, "subGraphTitleMargin": {"top": 8, "bottom": 60}}}}%%
flowchart LR
t["support ticket"]
subgraph req["TypeSafe AI model<br/>evaluates each question<br/>against the ticket in parallel"]
direction TB
c["<b>Choice:</b> category"]
b["<b>Score:</b> bug severity"]
r["<b>Noul:</b> reproducible steps?"]
f["<b>Noul:</b> refund requested?"]
s["<b>Score:</b> frustration"]
%% invisible links: without an edge these share a rank and sit side by side
c ~~~ b ~~~ r ~~~ f ~~~ s
end
t -- "one request<br/>ticket + 5 questions" --> req
req -- "one response: 5 answers<br/>decisions + probabilities" --> route{"<b>filter, combine, and route</b><br/>in your code"}
route -- "bug_report" --> eng["read severity + repro steps<br/>escalate or backlog"]
route -- "billing" --> bill["refund requested<br/>send to billing"]
route -- "feature_request" --> feat["log it<br/>sent to devs"]
第 1 步:推测性扇出
{
"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"
]
}
}第 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)
整棵决策树所需的一切都来自一次调用。推测性问题在不相关时被忽略,在相关时则省下了一次往返。