一次 Jev 请求提多个问题：fan-out 模式实践

TypeSafe 的文档中有一种名为“推测式 fan-out”的模式。它不采用调用链（即第二个问题要等第一个问题的结果），而是把所有问题放进同一个请求发给 Jev，其中也包括最终可能用不上答案的问题。哪些答案对当前情况重要，由你的代码事后决定。S74 对每天要分拣数百条消息的网店来说，这意味着更少的网络等待和更简单的代码。不过，这一模式也有页面没有提到的局限。

文档中的示例是什么样的

示例对客服工单进行分拣。一个请求包含工单文本和五个问题：Choice category（代码中出现的取值为 bug_report、billing 和 feature_request）、Score bug_severity、Noul has_reproducible_steps、Noul refund_requested 以及 Score frustration。故障严重程度和是否描述了复现步骤只对故障报告有意义，退款问题只对账单类工单有意义，而不满情绪则由代码在每个工单上都检查。S74

随后代码进行分支。严重程度得分高于 1.5 且描述了复现步骤的概率高于 0.6 的故障报告交给开发人员，其余报告进入故障列表。退款请求概率高于 0.7 的账单工单会被加上标记，功能建议只做记录，而不满情绪高于 1.5 意味着无论属于哪个类别都优先回复。S74

文档把这一模式与另一种做法作对比：先确定类别，再用另一次调用补充严重程度。当推测式答案派上用场时，就省去了第二次调用；用不上时，代码直接不使用它。S74

模式承诺了什么，又没有说明什么

根据文档，问题是并行评估的，因此增加问题通常不会明显延长响应时间。S74 这是厂商说法，页面没有给出任何实测数值。S74 API 说明补充指出，请求中的所有问题都针对同一个共享的 state，并且同一请求中可以混合不同类型的问题。API 说明没有给出单个请求中问题数量的上限。S75

在成本方面需要谨慎。TypeSafe 按输入 token 计费，Jev 1.14 和 1.13 均为每百万 0.042 USD，输出 token 目前免费。S01 响应用一个 usage 对象报告整个请求的用量，而不是按问题分别报告。S75 但无论是模式页面还是 API 说明，都没有解释每增加一个问题会让请求多出多少输入 token。S74 S75 从模式的逻辑可以推出，共享文本只需发送一次，而不必在多次独立调用中重复发送；但实际节省多少，请用自己的数据根据 input_tokens 的数值核实。估算成本可以使用成本计算器。

此外还有大小限制。默认情况下，每个请求为 64k token，每个问题为 32k；加上请求头 TypeSafe-Danger-Zone-Long-Context: true 后，两项上限都提高到 262k。S01 更多细节见价格与限制指南。

示例中的阈值不是推荐值

示例中的 1.5、0.6 和 0.7 仅用于说明。对于 Score 问题，结果是各等级编号的加权平均值，等级从零开始编号，因此在三个等级时得分范围为 0 到 2。S04 fan-out 页面没有说明 bug_severity 和 frustration 各有几个等级。S74 因此无法从示例中读出阈值 1.5 的含义：在三个等级时它接近量表顶端，在五个等级（0 到 4）时则低于量表中点。这是我们自己的推算，不是厂商数据。

对于 Noul 问题，文档建议先以 0.7 作为“是”、0.3 作为“否”的阈值，再根据自己的结果调整。S06 如何设定和验证阈值，见confidence 与校准指南。

示例中还缺少一个分支，用来处理不属于代码中三个类别的工单。S74 在正式运行中，我们建议补上这样的分支，并把这类情况转交人工处理。

陷阱：所有问题共用一个 state

fan-out 容易诱使人把任何一个问题需要的内容都塞进同一个 state。然而，关于 Jev 1.13 弱点的页面（最近一次审阅于 2026年10月2日）提醒，当 state 中与决策无关的内容增多时，准确率会下降。该页面建议事先在代码中只挑选问题所需的字段。S07 该页面针对的是 1.13 版本；我们在文档中没有找到 1.14 的单独弱点概览。

我们的建议：把使用同一输入的问题放进同一个请求，例如针对同一条消息的文本。如果某个问题需要其他数据，例如订单历史，就单独发送，并配上它自己的、更短的 state。

这对斯洛伐克网店意味着什么

以消息“Balík neprišiel, chcem peniaze späť.”（“包裹没到，我要退款。”）为例。按照这一模式，一个请求可以包含：关于消息意图的 Choice 问题、关于退款请求的 Noul 问题，以及关于不满程度的 Score 问题。代码根据答案组织后续流程：意图决定进入哪个队列，退款概率决定是否给会计加标记，而强烈的不满会让消息排到前面。模型与代码之间的这种分工与文档示例一致。S74 关于按意图分拣消息，我们在客户消息分拣一文中有更详细的介绍。

不过，有两点需要你自己核实。该模式的文档完全没有提到斯洛伐克语，因此请先用自己的消息样本测试，再设定阈值；具体做法见斯洛伐克语测试指南。另外，由于代码要把多个独立答案组合成结果，也要做好它们相互矛盾的准备。相关问题的答案可能出现怎样的分歧，我们在关于 Choice 与 Noul 一致性的文章中讨论过。