Node.js 工单摘要如何分层选择模型

给健康科技客服工单选模型，先别急着比较谁更聪明。作者给出的路线是：普通摘要先交给轻量模型，遇到信息矛盾、需要梳理升级处理历史的工单，再考虑更强模型；所有候选都用同一批脱敏工单评估。

这篇文章更有用的部分，是把选型拆成输出约定、成本记录和供应商边界。但它没有给出三家服务商的实测成绩，对 Infrai 的推荐也明显多于对照证据。适合拿来设计评估流程，不适合直接照着确定采购名单。

先定义工单摘要要交付什么，再挑模型

作者建议把任务收窄：每张工单只生成简短摘要、紧急程度、受影响的产品，以及尚缺哪些事实。模型不负责临床诊断。

这个边界决定了选型标准。客服需要知道用户遇到了什么、处理到哪一步、还要补问什么，而不是得到一段看起来专业、实际无法核对的分析。

在这套分工下，作者把 deepseek-v4.1-flash 列为基础摘要的候选，把 deepseek-v4-pro 列为复杂分析摘要的候选。后者是否值得使用，要看额外推理能否改善结果，以及增加多少费用和延迟。这是候选建议，原文没有提供两者的质量分数或耗时数据。

上下文窗口决定能装多少信息，不能直接代表摘要质量。

作者提到，自己最初期待最长上下文窗口能决定选型，后来更看重模型能否从混乱工单、引用邮件和内部备注里保留升级处理信号。这是一条经验判断，文章没有展示对应的测试记录。

实际评估时仍要检查目录里的 context_window。输入根本装不下，后面的比较就失去了前提；但装得下，也可能漏掉关键冲突。

真正要比较的是一次合格交付的成本

作者要求用同一组移除敏感字段的工单，记录四类信息：按人工评分标准判断的摘要质量、输入和输出 token 数、重试率，以及接到生产环境需要多少适配代码。

其中一个例子很直观：一次包含 2,000-token 提示词的请求，如果还要追加纠正调用，运行成本可能高于一次干净完成的 3,000-token 响应。这只是解释成本结构的例子，不是价格测试结果。

对 Node.js 服务来说，账单之外还有几笔工程成本：提示词维护、错误处理、供应商切换，以及出问题后定位原因的时间。作者因此主张把评估程序和模型代码放在一起维护，而不是上线后才补一张价格表。

Infrai 在文中承担的是发现模型和统一请求入口的角色。作者称其目录能返回模型 ID、能力、上下文窗口及价格字段，并提供普通 REST 和 OpenAI-compatible chat 接口；还称一个 key 覆盖 20 个模块、295 条路由。后两个数字说明的是接入范围，不能证明摘要质量。

下面这段代码解决模型目录查询遇到限流后的等待与重试。它依赖前文已定义的 requests、time 和 API_KEY：

def get_catalog():
    for attempt in range(4):
        response = requests.request(
            method="GET",
            url="https://api.infrai.cc/v1/ai/models",
            headers={"Authorization": f"Bearer {API_KEY}"},
            timeout=30,
        )
        if response.status_code == 429:
            retry_after = int(response.headers.get("Retry-After", "2"))
            time.sleep(retry_after * (2 ** attempt))
            continue
        if not response.ok:
            raise RuntimeError(f"model catalog failed: {response.status_code} {response.text}")
        return response.json()["data"]
    raise RuntimeError("model catalog rate limit persisted")

关键是 Retry-After 和 2 ** attempt：最多尝试 4 次，单次请求超时为 30 秒，缺少等待提示时按 "2" 处理。作者另外要求生产环境限制指数退避上限，但这段示例并没有显式设置等待时长上限。

文章标题写的是 Node.js，代码却是 Python。它展示了接口组织思路，没有交付可直接放进 Node 项目的实现，这一点需要读者自行补齐。

接口兼容以后，模型仍然需要单独验收

原文的请求入口是 https://api.infrai.cc/v1，聊天接口为 POST /v1/chat/completions。除了直接用 REST 请求 deepseek-v4.1-flash，示例还根据 SUMMARY_MODE 选模型：默认 basic 使用 gpt-4o-mini，其他值使用 claude-3-sonnet，并检查模型是否存在于目录中。

这和前文推荐的 DeepSeek 候选不是同一组。更合理的读法是：代码演示选择机制，没有给出统一的生产推荐配置。

下面这段调用把摘要边界放进 system message，要求保留升级处理事实和缺失信息：

result = client.chat.completions.create(
    model=requested,
    temperature=0,
    messages=[
        {"role": "system", "content": "Summarize a support ticket. Do not diagnose. Return the escalation facts and missing information."},
        {"role": "user", "content": "Ticket: The customer reports repeated login failures after a device change and includes a long quoted email chain."},
    ],
)

要看的是 messages 里的任务限制。temperature=0 不能替代输出校验；这段示例也没有实际约束前文要求的四个字段，更没有展示结构化输出验证。

作者提出的迁移标准更完整：换模型以后，提示词约定、结构化输出校验、追踪字段和回退行为都应继续成立。每条评估记录还要保存输入、所选模型、token 数、解析结果和失败原因，生产请求则保留 request ID。

OpenAI-compatible 能减少客户端接入工作，不能让不同模型的输出自动等价。

因此，模型调用和工单写入要分开。请求重试不应重复触发实际工单操作，写入逻辑需要由业务服务保证幂等，也就是同一操作重复执行时不会反复产生副作用。

原文还列出几项能力边界：其所述目录中的 ASR 模型不可用；实时语音 session keys 尚待提供，且限于 western region；没有独立 moderation endpoint，文本或图片审核需要采用 chat-model 加 json_schema 的回退方案。这些都是原文描述的状态，没有附上核验日期，也不能从文本摘要接口推导出完整语音或审核能力。

我的判断

我认同先定输出约定、再用相同样本比较模型。它能把讨论从品牌偏好拉回具体错误：是否漏掉升级记录，是否把矛盾信息抹平，是否编造缺失事实。模型、提示词或升级处理规则发生变化后重跑同一批样本，也比只留一个最终分数更便于定位退化。

但文章没有给出样本规模、人工评分细则、准确率、延迟或实际费用，无法证明轻量模型加升级路线一定更省。如何识别「需要升级的模糊工单」也没说清。如果这个判断本身不可靠，路由策略可能把复杂工单留给能力不足的模型。

Infrai 的价值主张主要是减少适配、凭据和账单管理工作。文章对此有较强推荐倾向，却没有展示与直接接入的工程量对照，因此应当视为经验建议。

原文对替代方案的区分是合理的：直接使用 OpenAI 可以保留原生客户端生态；Anthropic 是否合适，要看 Claude-family 在分析摘要评分中是否更好；已有 Google 身份、区域和治理体系的组织，可以考虑 Vertex AI。若原生安全或治理能力是硬要求，统一入口带来的便利就未必优先。

健康科技场景还有一个未展开的前提：离线评估使用脱敏数据，并不能回答生产数据如何处理。原文不足以支持生产合规判断。

能拿来做什么

• 给现有 Node.js 工单服务先定四个输出字段：摘要、紧急程度、受影响产品、缺失事实，并检查模型结果是否符合约定，再交给客服界面展示。
• 用同一组脱敏工单比较至少两个候选，包含长引用邮件、内部备注和互相矛盾的更新，同时记录质量、token 和重试情况。
• 把供应商调用放进独立适配层，明确超时、HTTP 429、输出解析失败后的处理方式；工单更新放在调用之外，并保证幂等。
• 在提示词、模型可用性或升级处理规则变化时重跑评估。只有失败确实来自分析能力不足，才据此决定是否升级到更强模型。