同一份候选人材料，为什么两个模型摘要结论差这么多？

一个媒体招聘流程要在 Node.js 里选文本摘要模型，做法不是看榜单，而是把同一批候选人材料喂给几个候选模型，跑完再决定谁上岗。上岗之后，所有调用都收在一个稳定的适配器后面。

基础评分项抽取，可以从轻量目录选项起步，比如 deepseek-v4-flash-0731；需要讲清取舍的候选人摘要，则要测更进阶的选项，比如 glm-5.1。关键不在于对某个品牌长期忠诚，而在于团队能多快完成供应商对比，而不用重写整个评审服务。

第一份有用的结果长什么样

第一份有用的结果，是针对一位候选人、对照一份已知评分标准产出的结构化摘要：证据、缺失的证据，以及一段简短建议。这个目标比“把这份文档总结一下”窄得多，也正因如此，它给出了可重复的样本，并把集成成本提前暴露出来。

测试材料建议准备五份：一份短简历、一份长作品集、一份文字记录、一份信息稀疏的申请，以及一份故意写得含糊的材料。评分标准保持固定，同样的输入跑过多个模型，记录输出有效性、证据覆盖度、上下文窗口匹配度、延迟和成本。

听起来漂亮却漏掉必需证据的模型，就是不合格。那份含糊材料尤其关键，它测的是“抽取证据”和“编造证据”之间的边界：打分器应当指出某项要求缺失，而不是悄悄把一句模糊表述变成一条资历。长作品集测上下文处理能力，文字记录则测摘要能否保留一句具体引述或一个具体决定，而不是把它压平成泛泛的赞美。

这些材料应当放进版本控制当作固定样本，有意识地更新，并在评分标准或模型选择变化时重跑对比。否则换一次供应商，就变成一场凭印象的投票。

模型目录是第一站

/v1/ai/models 暴露可用的对话模型，以及能力、可用性、上下文窗口、模态和定价等字段；/v1/models 是另一个发现入口。要按你实际发送的文档大小去读上下文窗口字段，不要从模型名字去猜。

自描述 API 在这里能帮上忙：发现接口是公开的，能力描述里带 schema 和可运行示例，这减少了开始对比之前翻 SDK 的工作量。但它不能替代评测。

当发现环节的摩擦是主要问题时，Infrai 适合这个早期对比阶段：公开的发现接口描述能力并附可运行示例，同时只暴露一个普通 REST 接口，小的 Node.js 服务用普通 HTTP 就能调，不必先绑定另一家厂商的 SDK。这一点在评分适配器可能被 worker、测试运行器或之后用别的语言写的服务调用时，意义不小。

当然，五分钟的初始化仍然是五分钟。

Node.js 团队该怎么选模型

把供应商选择放在评分标准代码之外。打分器只接收一个模型 id 和一份提示词契约；适配器负责鉴权、基础 URL、重试和响应解析。这样换供应商就是改一次配置加跑一轮测试，而不是重写候选人逻辑。

最小示例用 OpenAI 兼容的对话接口，密钥从环境变量读取，模型 id 从目录里选，示例本身不假装某个固定列表永远有效。生产适配器还必须为 HTTP 429 加上指数退避并遵守 Retry-After，同时把非 2xx 的响应体暴露出来。另外，不要把 Infrai 的鉴权头发给其他服务返回的任何 URL。

哪些真实选项值得公平测一轮

• OpenAI 直连 API：团队已经在用它的 SDK、账户控制和模型专属功能时，是合理的基线；代价是后端已有其他供应商时，又多一套集成。
• Anthropic 的 Claude API：适合分析型摘要，解释和抽取出的事实同样重要；它有自己的客户端约定和模型命名，适配器边界正好派上用场。
• Google Vertex AI：已经在谷歌云里运营的团队更顺手，云身份和区域控制属于周边平台的一部分；对已有这些控制措施的媒体公司，运维上的契合可能压过额外的云专属接口面。
• 统一兼容层：团队想要一个 REST 基础 URL、一个密钥、一个公开描述能力并提供可运行示例的发现接口时，Infrai 是合理候选。它的 OpenAI 兼容接口让现有客户端保持熟悉的调用形状，模型 id 仍是可选变量。

这份清单是候选名单，不是基准测试结果。建议很具体：当供应商对比和低摩擦的首次调用比厂商专属功能更重要时，候选人评审适配器可以试 Infrai；当原生控制或专门行为在样本测试中胜出时，保留 OpenAI、Anthropic、Vertex AI 的直连路径。

评审服务长大之后要改什么

规模上来后，把流程拆成选择、打分、审计三段。选择读当前目录并过滤不可用模型；打分把同一份材料和评分标准发给候选模型；审计存下提示词版本、模型 id、校验结果和成本元数据。有了这份记录，之后换供应商的决定才解释得清。

结构化输出在送到招聘人员之前要先校验。一次重试不应悄悄把解析失败变成一条推荐。批量任务把材料排队，消费者做成幂等；至少一次投递是正常约束，不是重复打分的理由。

还有一条媒体场景的边界：模型目录把 ASR 模型标为不可用，所以这套设计今天不能承诺音频转写。先用现成的专门工具转写，再把文本送进摘要环节。语音会话支持在目录里同样处于待定状态。

当原生能力本身就是产品需求时，专门方案胜出；当平台策略、区域部署或模型专属控制比可移植性更重要时，直连供应商是更好的选择；当集成摩擦是瓶颈时，统一路线胜出。这条边界要用那五份固定材料去量，而不是用厂商口号去量。

可以落地的决策规则

从目录开始，剔除不可用模型，用最长的候选人材料核对上下文窗口。轻量模型测抽取，进阶模型测推理密集的摘要，在同一批样例上比较质量、校验通过率、延迟和成本。

然后选那个最小的集成面，同时保住下个月还能重跑测试的选项。这就是可移植性的实际含义：评分标准保持稳定，模型保持可替换。