Jev式评分与LLM解码及结构化输出对比解析
Jev-style scoring vs. LLM decoding vs. structured output, clearly explained:
Agent开发中分类路由是高频场景，这篇清晰拆解了Jev式评分的底层逻辑与适用边界，比盲目调大模型更省算力，建议结合文末指南落地测试。
Jev-style scoring vs. LLM decoding vs. structured output, clearly explained:
Jev 风格评分与 LLM 解码及结构化输出的清晰对比：
Many LLM requests do not need newly written text.
许多 LLM 请求并不需要生成全新的文本。
Routing, classification, policy checks, and ranking usually already have a known set of valid answers, and the only question is which answer best matches the input.
路由、分类、策略检查和排序通常已有已知的有效答案集合，唯一的问题是哪一个答案最匹配输入内容。
Consider a support ticket:
考虑一个支持工单：
"I was charged twice for the same subscription."
“我同一订阅被扣了两次款。”
The application must route it to either billing, technical support, or account access.
应用程序必须将其路由至账单部门、技术支持或账户访问部门之一。
With normal LLM decoding, the model goes through a full reasoning process. A decoding rule selects one token, appends it to the sequence, and runs the model again.
使用普通的 LLM 解码时，模型会经历完整的推理过程。解码规则选择一个 token，将其追加到序列中，然后再次运行模型。
This continues until the model responds with something like:
这一过程持续进行，直到模型响应如下内容：
"Based on the customer's query, this ticket should go to billing."
“根据客户的查询，此工单应转至账单部门。”
The application then has to parse that text to recover the decision it needed from the beginning.
随后，应用程序必须解析该文本，以提取出从一开始就需要的决策结果。
Structured output handles this better, but the underlying process is still generation.
结构化输出能更好地处理这种情况，但其底层过程仍然是生成。
A grammar or schema masks illegal next tokens at every step. The model cannot produce arbitrary prose, but it still generates/decodes the full JSON token by token:
语法或模式会在每一步屏蔽非法的下一个 token。模型无法生成任意散文，但它仍会逐 token 生成/解码完整的 JSON：
""" { "team": "billing" } """
""" { "team": "billing" } """
This is useful when the application needs unknown values, nested fields, or tool arguments. The schema guarantees the shape of the response.
当应用程序需要未知值、嵌套字段或工具参数时，这种方式非常有用。模式保证了响应的结构形状。
Jev-style scoring handles fixed-choice decisions differently.
Jev 风格评分以不同的方式处理固定选项的决策。
The application provides the query, the input state, and the allowed answers before inference.
在推理之前，应用程序提供查询、输入状态以及允许的答案列表。
This time, instead of decoding a sentence or JSON object, the model scores the predefined candidates:
这一次，模型不是解码句子或 JSON 对象，而是对预定义的候选项进行评分：
""" billing → 0.90 technical support → 0.10 account access → 0.00 """
""" billing → 0.90 technical support → 0.10 account access → 0.00 """
The application receives the selected label and its probability distribution directly.
应用程序直接接收所选标签及其概率分布。
The applicability entirely depends on the downstream use case. They expose different output contracts and perform different types of inference work.
适用性完全取决于下游用例。它们暴露不同的输出契约，并执行不同类型的推理工作。
- LLM decoding is ideal when the application needs newly written text. It can also return a label, but it must generate and parse that label like any other response.
- Structured output decoding is ideal when the values are not known beforehand, but the application requires a predictable schema. The model still generates the response token by token while the decoder prevents invalid structures.
- Jev-style scoring is ideal when the valid answers are already known. It cannot write an explanation or produce an unknown field value. Instead, it compares the supplied candidates and returns their probabilities without decoding a sentence or JSON object.
- 当应用程序需要全新撰写的文本时，LLM 解码是理想选择。它也可以返回标签，但必须像处理其他响应一样生成并解析该标签。
- 当值事先未知但应用程序要求可预测的模式时，结构化输出解码是理想选择。模型仍然逐 token 生成响应，而解码器防止出现无效结构。
- 当有效答案已知时，Jev 风格评分是理想选择。它无法撰写解释或产生未知的字段值。相反，它会比较提供的候选项，并返回它们的概率，而无需解码句子或 JSON 对象。
If you want to dive deeper into Jev, I also wrote a hands-on guide to building this Jev-style decision path with open models, entirely locally.
如果你想更深入地了解 Jev，我还写了一篇动手指南，介绍如何完全在本地使用开源模型构建这种 Jev 风格的决策路径。
Read it below.
请在下方阅读。
更进一步：量化金融体系
看懂新闻只是起点——沿量化金融路径，把它变成能交付的工程能力