级联与并行提问

这一类用法的动机都很直白：大模型的调用是贵的，而其中大部分请求其实很容易。 决策模型每问的价格比一次生成低一到两个数量级，于是「先问便宜的，不确定再问贵的」 就成了顺理成章的结构。

级联：只在自己有把握的地方定案

一个医疗幻觉检测的对比实验给出了很干净的量化：

让决策模型在它 ≥90% 确信的那 37% 上直接定案， 保住各个大模型原有的准确率，同时省掉 37% 的大模型调用。

这个结果之所以值得引用，是因为它把级联的收益说清楚了：省下来的比例 等于小模型在高置信区间上的覆盖率，而不是某个固定的百分比。 置信区间收得越紧，省的越多 —— 但前提是那个置信度真的可信 （这又回到了校准那一篇）。

级联有两个容易被漏掉的细节：

① 升级之后，大模型不该有无限的自由。 一个把不确定的行升级给大模型的实现， 强制大模型只能从同一组标签里选。不这么做的话，小模型的「不确定」 会被大模型的「自由发挥」换成一个你没法处理的输出。

② 选择一旦做出，就要锁住。 一个模型路由器的做法是：选定之后在整段会话里 保持这个选择，为的是 prompt cache 的连续性。每次都重新选，每次都会因为 前缀变了而丢掉缓存 —— 省下来的钱在缓存上又花回去了。

并行提问：省的是输入

决策模型允许把很多个问题放进同一次请求。官方的示例里就有一次调用问几十个问题的做法。

一个跑了 2,976 次调用的基准测试给出了具体数字：

也就是说，省下来的主要不是「模型算得快」，而是同一份 state 只发一次。 问题越多，这份固定开销被摊得越薄。当问题少到一两个时，并行和逐个发的差别 和重复请求的噪声是同一个量级 —— 不值得为此改架构。

反例：批处理会破坏排序

这是这一篇里最值得记住的一条，因为它反直觉：

一个 DuckDB 扩展默认按 40 行一批处理。基准测试发现， 按批处理过不了它的排序质量门，而一行一个请求能过。

原因不难还原：把 40 行塞进一次请求，模型要在一个请求里给出 40 个相对排序， 这比每次只比较少量候选要难。省钱和保真在这里是冲突的， 而「省钱」这一侧的收益是可见的（账单），「保真」这一侧的损失是不可见的 （除非你专门设了一个门去测它）。

这条对任何「批量提问」的设计都成立：并行提问适合彼此独立的问题 （分类、打分、判断），不适合需要互相比较的排序问题。

级联还有一个前提：错误要是随机的

级联在数学上成立，靠的是一个隐含假设：小模型犯的错是随机噪声， 所以大模型接手后能纠正。

但独立的 OOD 校准测试给出了相反的证据 —— Choice 与 Score 系统性地过度自信、Boolean 系统性地自信不足。系统性的偏差不是噪声： 它会让小模型在同一类样本上一致地给出高置信度，于是那些样本 永远不会被升级，而是被一致地答错。

这意味着级联的风险不是「准确率低一点」，而是某一整类输入被稳定地漏掉， 而且在整体指标上看不出来。要发现它，必须按子类去看准确率， 而不是看总体。

一句话

级联省的钱等于「高置信区间的覆盖率」；并行省的钱等于「被摊薄的固定开销」。 两者都有代价 —— 前者赌小模型的错是随机的，后者会伤到需要互相比较的任务。