System One决策架构评测：从结构特性到场景适配

一、评测概述

当语言模型被用于完成一项判断任务时，常见的做法是让模型生成一段推理文本，再从文本中提取结论。这种方式灵活，但也带来了明显的工程代价：输出长度不可控、结论抽取需要额外解析、延迟随生成长度增长、批量候选比较时计算难以复用。System One架构提出的思路相反——既然任务的终点是决策，那就让模型从决策本身出发，直接输出选择、概率或分数，而不生成长篇推理文本。

本文的评测对象是这一决策模型架构及其四项结构特性：答案缺席识别（Null-aware）、顺序不变性（Permutation-invariant）、候选扩展（Option-scalable）与计算复用（Cacheable）。需要说明的是，本文不是对该架构做“好或不好”的单一判断，而是建立一套可观察、可验证的评测框架，帮助读者判断它在自己的业务场景中是否值得引入。

本文适合以下读者：正在评估决策类模型方案的开发者、需要为判断类任务做架构选型的系统架构师、关注线上稳定性与推理成本的运维人员，以及负责技术方案落地决策的技术负责人。

二、评测目标

本次评测围绕以下问题展开：

1. 功能完整性：架构是否覆盖选择、评分、答案缺席识别等典型决策形态，是否支持同一套计算逻辑处理多种输出类型。
2. 准确性：在答案缺席识别、候选比较等任务上，输出是否符合预期，是否能给出明确的null判断而非强行选择。
3. 稳定性与一致性：当候选顺序发生变化时，判断结果是否跟随候选身份而非列表位置。
4. 扩展性：候选集合扩大时，架构是否仍能在一次决策计算中完成比较，编码与决策是否解耦。
5. 计算效率与成本：候选表征与层投影是否可缓存，新请求到来时是否只需重新编码请求本身。
6. 易用性与可维护性：接入方式、输出格式、调试手段和与现有系统的适配成本。

这些维度之所以重要，是因为决策类任务与生成类任务的失败模式不同。生成类任务更关注文本质量与流畅度，而决策类任务的失败往往表现为：该说“不知道”时硬选了一个、换个顺序就改答案、候选变多就漏判、每次请求都重复计算候选表征导致成本失控。评测必须针对这些失败模式设计。

三、评测对象说明

该架构的核心设计视角是把候选集合、答案缺席和计算复用视为决策本身的结构，而不是事后附加的功能。其基本流程可以概括为：共享编码器分别表示请求和候选选项，轻量决策模块读取整个候选集合，只更新请求状态，最终在同一次决策头计算中完成比较。候选文本可以分批编码，编码完成后完整集合仍参与同一次比较；选项的语义表征及其层投影可以缓存，新请求每次只重新编码请求并计算判断。同一套计算支持Choice（从候选中选择）、Null（判定答案缺席）和Score（按标准评分）三类输出。

从评测角度看，这一设计意味着若干指标之间存在耦合：缓存能力影响成本，候选扩展能力影响批量场景下的吞吐，顺序不变性影响结果可信度，答案缺席识别影响业务安全性。评测不能把它们割裂开单独打分，而应观察它们在同一架构下是否协同成立。

四、评测维度设计

下表给出建议的评测框架，读者可根据自身业务补充权重。

维度	关注点	验证方式	结果解读
功能完整性	Choice/Null/Score三类输出是否可用	构造三类请求分别验证	输出格式是否稳定、是否需额外解析
准确性	答案缺席识别、候选比较正确率	带标注样本集，含正负样本	关注AUROC与固定误判率下的召回
顺序稳定性	换序后判断是否翻转	原始序、倒序、多种随机排列	翻转率越低越好，准确率应保持一致
候选扩展	候选数量增加时的表现	逐步扩大候选集规模	观察准确率衰减与延迟增长曲线
计算复用	缓存命中后的成本变化	固定候选集、变更请求	对比缓存前后资源消耗
易用性	接入复杂度、输出可解析性	实际接入与调试	是否需要后处理、文档是否清晰
可观测性	日志、指标、异常定位	注入异常输入	是否能区分“无答案”与“解析失败”

其中顺序稳定性值得单独强调。决策模型如果对候选排列敏感，意味着它的概率跟随的是列表位置而非候选身份，这在工程上是严重缺陷：同一批候选换个顺序就得出不同结论，线上结果将不可复现。评测时应按候选身份对齐结果，而不是按位置对齐。

五、评测环境与前提

评测前需明确以下条件，避免结论越界：

• 数据规模：候选集合大小、请求数量、正负样本比例需记录，答案缺席样本应单独构造，不能只用有答案样本评估。
• 调用方式：批处理与单请求模式的延迟特征不同，需分别记录。
• 资源配置：编码器与决策模块的部署资源应固定，缓存开关状态需明确标注。
• 测试边界：评测结论只适用于所测候选规模与数据分布，扩大到更大候选集或更长文本时需重新验证。
• 基线设置：应设置同规模基线方案，在相同数据与资源下对比，避免跨环境比较。

六、评测方法

建议按以下流程执行：

1. 明确目标：先确定本次评测要回答的核心问题，例如“在答案缺席比例约5%的业务中，该架构能否稳定识别缺席”。
2. 设计样本：构造包含有答案、无答案、边界模糊三类请求的数据集，候选数量覆盖小、中、大三档。
3. 建立基线：在相同环境下记录基线方案的选择准确率、缺席识别指标与资源消耗。
4. 分维度验证：功能验证走通三类输出；准确性在标注集上计算指标；稳定性做多排列测试；扩展性做候选规模阶梯测试；复用性做缓存开关对比。
5. 控制变量：固定模型规模、资源配置、请求内容与候选内容，仅改变被测变量。
6. 记录过程：记录响应时间、错误类型、缓存命中情况、异常输入下的表现。
7. 分析边界：说明结论适用的候选规模、数据分布与部署条件。

示意性伪代码（通用示例，非特定接口）：

for request in dataset:
    candidates = load_candidates(request)
    for order in [original, reversed, *random_orders]:
        shuffled = permute(candidates, order)
        result = decide(request, shuffled)   # 输出 choice / null / score
        record(align_by_identity(result), order)
compare_flip_rate(records)

七、结果解读

结果解读应避免绝对化。以下几点可作为判断依据：

• 答案缺席识别：若在固定误判率（例如约5%的有答案请求被误判为无答案）下，缺席召回仍保持较高水平，说明该架构具备可用的null输出能力，业务上可减少“强行选择”带来的错误。若召回随候选规模扩大明显下降，则需在业务侧增加兜底策略。
• 顺序稳定性：若多排列测试下翻转率为零、各顺序准确率一致，说明概率跟随候选身份，结果可复现；若存在翻转，需排查是编码截断、位置编码还是决策头聚合方式导致。
• 候选扩展：观察准确率随候选数量增长的衰减斜率与延迟增长曲线。若延迟增长主要来自编码而非决策，说明决策头本身具备较好的扩展性。
• 计算复用：缓存开启后，固定候选集场景下资源消耗应明显下降；若下降不明显，需确认缓存粒度是否覆盖层投影。
• 性能与稳定性：延迟、吞吐受资源配置与批处理策略影响较大，评测结论必须绑定部署条件，不能跨环境直接套用。

需要注意，上述指标的差异可能来自数据分布、候选文本长度、编码器容量、缓存策略和并发模型，而非架构本身的单一原因。解读时应结合技术归因，而不是只看数字高低。

八、适用场景分析

• 证据定位与文档筛选：从一组文档中找出相关证据，候选集固定、请求多变，缓存收益明显，适合该类架构。
• 条件判断与规则校验：判断某项条件是否成立，输出为二值或分数，需重点关注Null能力，避免在信息不足时误判。
• 按标准评分：同一套计算支持Score输出，适合需要批量、可复现评分的场景。
• 高并发在线判断：候选可预编码、请求侧计算轻量，适合对延迟敏感的在线服务，但需压测验证并发下的稳定性。
• 候选频繁变化的场景：缓存收益下降，需评估重新编码成本是否可接受。

九、风险与限制

评测过程中存在若干不确定性：样本偏差可能导致指标偏乐观，尤其是答案缺席样本构造方式与真实分布不一致时；环境差异会使延迟与吞吐结论不可直接迁移；数据质量差、候选文本超长截断会引入额外误差；长期运行下的缓存一致性、版本升级后的表征漂移也需持续观察。此外，四项结构特性在同一架构下协同成立，但单独评测某一项时容易忽略其他项的约束，结论应整体看待。

十、选型与使用建议

建议按业务优先级分配评测权重：对结果可信度要求高的场景，优先验证顺序稳定性与答案缺席识别；对成本敏感的场景，优先验证缓存命中率与候选扩展曲线；对在线延迟敏感的场景，优先做并发压测与批处理策略验证。接入前应确认输出格式是否可直接消费、异常与null是否可区分、日志是否能支撑问题定位。不要以单次评测结论作为长期选型依据，应在业务数据分布变化后定期复测。

十一、总结

本文围绕System One决策架构，建立了覆盖功能完整性、准确性、顺序稳定性、候选扩展、计算复用、易用性与可观测性的评测框架，说明了测试流程、结果解读方式与适用边界。核心判断是：该架构把候选集合、答案缺席与计算复用作为决策的结构性设计，而非附加功能，因此评测应整体观察四项特性的协同表现，并结合自身业务的候选规模、数据分布与部署条件做出条件化结论。评测的价值不在于给出排名，而在于帮助团队明确“在什么条件下适用、在什么条件下需要兜底”。