将决策工作负载从 Drex Max 迁移到 Gemini Decision 1

这次移植看起来像改个 URL，其实并非如此。Drex Max v1.1 和 Gemini Decision 1都会接收一段上下文和一组带类型的问题，并返回概率，所以迁移的第一个下午会很顺利：重命名字段、把客户端指向另一个基础路径、运行测试套件。真正出问题的是第二周，当流量上来时，两套计费模型对你在购买什么产生了分歧。本文讲述实际必须改变什么，写给已经有一个可用的 Drex Max v1.1 集成、并想知道更新模型那醒目的分数是否值得迁移的人。

先从这笔交易最诚实的版本说起。在 {{1}}Artificial Analysis Decision Index v2.1{{/1}} 上，{{2}}Drex Max v1.1{{/2}} 得 {{3}}73{{/3}} 分，而 {{4}}Gemini Decision 1{{/4}} 得 {{5}}66{{/5}} 分。较旧的模型胜出，而且以 {{6}}6.6 分{{/6}} 的优势胜出，其中大部分优势来自占综合评分 {{7}}30%{{/7}} 的那个组成部分。如果你的工作负载是文档分流，那么这次迁移就是伪装成升级的降级。如果是其他场景，请继续读下去，因为这两个端点的相似程度并不像它们的请求形态所暗示的那样高。

不在任何排行榜上的差异

Drex Max v1.1 为每个问题提供各自 131,072 token 的预算。Gemini Decision 1 则为整个请求提供 262,144 token，由输入和其中的每个问题共享。这两句话描述的是同一产品类别，却给出了相反的工程建议。

在 Drex 上，提出 200 个问题会消耗 200 个独立预算，而一个请求的实际上限是你的速率限制，而不是上下文。在 Gemini Decision 1 上，200 个问题和一份 200,000 token 的合同无法放进同一个请求：200,000 token 的输入会留下 62,144 给问题和指令，这很宽裕，但 250,000 token 的输入只留下 12,144，请求就会失败。这个上限是真实存在的，它是共享的，并且会随着你发送的内容多少而变化。

这是最有可能破坏正常运行的 Drex 集成的那一项变更，因为失败模式在低数据量下并不会表现为错误。一个测试套件在 30,000 个 token 的文档上通过 20 个问题，在两种系统中都能轻松容纳。生产环境使用 180,000 个 token 的记录和 900 个问题，只能容纳于其中一个系统，而另一个系统则不行。

每 token 价格掩盖了什么

Drex Max v1.1 的标价为每百万输入 token $0.03，这是发布价，而标准价为 $0.06；Gemini Decision 1 则为 $0.10。两者都不对输出收费。单看这一列，Drex 便宜 1.7 到 3.3 倍，这足以让高用量团队就此结束讨论。

按任务衡量，差距就缩小了。Artificial Analysis 将 Drex Max v1.1 定为每百万个决策任务 103 美元，将 Gemini Decision 1 定为 345 美元，比例约为 3.3——这是标价比较，而非发布价。原因是 Gemini Decision 1 为了得出答案会读取更多 token。它的共享上下文规模是两倍，而其组件得分表明，它在每个问题上投入的输入更多，而不是更少。按任务计算，实际差距大约是三比一，有利于 Drex，而发布折扣是临时条件，不会撑过你的第二次合同续约。

这意味着定价问题不是“哪个更便宜”，而是“你愿意为把多大比例的任务做对而支付3倍价格”。如果一条将支持工单路由到队列的规则比替代方案多错5%，那它毫无价值。而一条会标记合同条款以供法务审核的规则，立刻就能值回这一差价。

文档处理正是得分所在。

6.6个百分点的综合差距并非均匀分布，而迁移论证取决于弄清这一差距究竟体现在哪里。

• AA-Paperclip，权重 30% — Drex Max v1.1 得分为 72.8，在全有或全无测试中直接通过 63% 的文档；Gemini Decision 1 得分为 56.8，通过 33%。综合得分差异的大部分都来自这一组成部分。

• When2Call，10%——Drex 95.3 对 Gemini 的 80.5，在工具调用判断上相差 14.8 分，是 Drex 在任何地方保持的最大比例领先优势。

• EvalSafe-O*NET-AA，15% — 88.3 对 87.1。不过是舍入误差，而且这是该组中唯一一个与安全相关的测试。

• AA-Omniscience-Decision v1.1，15% — Drex 60.3，Gemini 66.3。Gemini 领先，这也是其发布报道以知识为切入点的原因。

• HLE-MultiChoice v1.1，15%——Drex 46.6，Gemini 48.7。差距很小，而且两个模型都经常选择拒答而非猜测，因此原始准确率远低于这些数字。

• AA-Symmetry v1.1, 15% — Drex 79.8 对 70.5。无论问题被重排、重新标注并取反后，答案是否依然成立——这几乎是榜单上最接近稳定性测试的指标。

在做决定之前，其中两行值得再仔细看看。在文档抽取方面，按严格指标衡量，Drex 的可靠性接近两倍；而在对称性上，它稳定了九个点——这意味着基于 Drex 的流水线更少产生那种同一问题换一种问法就会翻转的答案。如果你的产品向用户呈现单一答案，那么不稳定就是一条缺陷报告。如果它用于下游评分，那么不稳定就是可以通过平均消除的方差。

速度，以及保留两者的理由

Drex Max v1.1 运行一项任务的中位耗时为 283 毫秒。Gemini Decision 1 运行同一任务则为 211 毫秒。较新的模型尽管做了更多工作，速度却更快——这是迁移唯一毫无保留地带来好处的地方。对于用户操作前的同步检查而言，70 毫秒并非无足轻重。

速度、价格和准确率很少能如此整齐地指向同一个方向，而在这里它们并没有：Gemini 更快但更差，Drex 更慢但更好，成本比跟随的是质量比而非延迟比。这正是两个设计真正不同的模型的标志，而不是其中一个是严格意义上的升级。

这才是真正值得推荐的做法。只有一个评分模型的决策服务，就只有一个故障点和一种判断。同时运行两个模型要多做一次集成，但换来的是一个分歧信号：当两个模型都以高置信度给出不同答案时，说明这个案例确实存在歧义，可能本就不该自动化处理。这种模式很老派，也没什么新意，但它能捕捉到任何单一模型的置信度分数都发现不了的错误。

移植调用本身

机械部分比会计部分小，不过在开始之前有三个陷阱值得点明。

首先，Drex 通过 /v1/systemone 调用，并将模型 ID 固定为 drex-max；快速入门中的 drex-latest 别名并不是固定 ID，使用它意味着模型会在你未部署的情况下在背后发生变化。Gemini Decision 1 则有相反的问题：根本没有别名，只有 gemini-decision-1，而命名 gemini-decision 的请求将无法解析。两边都要固定，并将模型 ID 视为配置中的版本号，而不是源代码中的常量。

其次，媒体限制不能直接沿用。Drex Max v1.1 每次请求最多接受 8 张图像。Gemini Decision 1 接受文本、图像、音频、视频和 PDF，限制为内联 base64 100 MB、每个 PDF 50 MB、每个 HTTPS URL 15 MB，并且直接拒绝 YouTube 链接和 gs:// URI。一个每次请求批量处理八页扫描件的 Drex 流水线，会变成一个要么将这些页面作为一个 PDF 发送、要么拆分该批次的 Gemini 流水线。

第三，题型相近，但边界并不完全相同。两者都支持是/否、选择和评分。Gemini 将选择和评分限制为 2–255 个选项或等级，并将是/否概率限制在 0.01–0.99，因此你的 Drex 代码中设置的任何高于 0.99 的阈值在移植后都会静默地永不触发。检查代码库中的每一个阈值常量，而不仅仅是配置文件中的那些。

路由器适用于哪些场景，以及不适用于哪些场景

OrcaRouter 既不承载 gemini-decision-1，也不承载 drex-max。这两个都是仅提供概率的端点，而我们这种形态的路由器前端面向的是 chat-completions 目标；作出相反的说法就等于声称其可用性，而这种说法会在第一次请求时就失败。在这次迁移中，路由器的用途是流水线中不属于评分器的那一部分。

几乎每个决策服务在评分之前都会先起草：生成式模型会提取候选条款、提出评分标准，或把记录总结进决策模型随后读取的共享上下文。正是这个起草调用，让供应商选择真正重要，也正是第二份合同带来痛点的地方，而它可以在同一个端点上跨 200 多个模型运行，并按 0% 加价率透传提供商目录价。Routing DSL 在这里比在聊天产品中更重要，因为起草调用是异构的——初筛用便宜模型，18 万 token 的记录用长上下文模型——而把这种安排表达为规则，胜过把它表达为三套 SDK。

诚实的限制：故障转移保护的是起草调用，而不是评分调用。决策请求只有一个发送位置，一旦该位置不可用，你的服务就不可用。如果这种依赖关系不可接受，那么上面的双模型模式就不只是一种准确性措施——它是唯一可用的真正冗余，因为它是获得两个独立评分端点的唯一方式。

底线

如果你的决策是知识型的、速度很重要，或者你想要一个大到足以一次性容纳整条记录的共享上下文，就迁移到 Gemini Decision 1。如果它们是文档型的，就继续使用 Drex Max v1.1——而通过率表明它们很可能就是文档型的，因为大多数决策工作负载仔细一看，本质上都是文档抽取。如果错误答案代价高昂，就两者都运行，并在向任何人承诺节省之前，为 3:1 的成本比预留预算。迁移是一天的工作量外加一个季度的重新调优；是否要迁移，取决于你的工作负载实际上更像索引中的哪个组成部分。