客服LLM选型要测真实工单

给 Node.js 客服机器人选 LLM API，先问哪个模型最强，很容易选错方向。原文的主张是：先把普通对话和高风险代码审查拆开，再用同一批脱敏样本检验质量、耗时和数据留存，最后决定谁处理什么请求。

这不是一份供应商排行榜，而是一套应用层的选型方法。它对前端和全栈开发者的价值，在于把流式响应、上下文裁剪、输出校验这些零散工作，串成了可以验收的运行规则。但文中的阈值是示例，没有实测结果支撑。

先分两条处理路径，再比较模型

作者建议先区分两类任务：FAQ、订单状态等普通问答走低延迟路径，使用紧凑上下文；「审查这段改动并返回问题」走质量路径，允许更长超时，要求结构化输出，证据不足时明确返回需要补充上下文。

理由并不复杂：等回复多花几秒，与漏掉一处权限漏洞，代价不同。拿所有请求的平均表现选模型，会掩盖高风险任务的失败。

Node.js 服务负责 HTTP 边界、鉴权、限流、取消请求和向浏览器传输流。模型适配器负责对接供应商，并且应该能够替换。这样，脱敏、超时、重试和输出校验都有固定的执行位置。

原文用 Python 展示接口契约，并未提供 Node.js 实现。请求包含 task、messages、diff、deadline_ms、trace_id；结果包含 status、findings、input_units、output_units、latency_ms、trace_id。其中，task 区分 chat 与 code_review，status 区分 complete、needs_context、failed。

这些字段的用处，是让业务层知道任务是否完成、用了多少资源、耗时多久。原始提示词不应随结果返回浏览器，默认日志也不应保存完整对话。

浏览器已经收到文字，不代表业务已经拿到可用结果。

首个 token 到达时间决定界面是否显得灵敏，结果通过校验的时间才决定审查能否进入下一步。生成后的解析、重试、结构修复，都应算进后者。浏览器收到 200 tokens 后断开，也不能记作完整交付；后端应在 API 支持取消时终止上游工作，并记录响应未完成。

真正需要管住的，是反复发送的上下文

作者把成本拆成四项：输入 tokens、输出 tokens、请求次数、留存字节数。不能只看一次回复有多短，因为系统规则、产品资料、历史工单和代码 diff，可能每轮都在重复发送。

他们提出的做法是：稳定规则单独管理，旧对话生成摘要，只检索当前问题相关段落，代码审查只发送足以判断问题的最小 diff，并为各部分设置硬上限。不过，规则单独存放不等于模型调用时自动免除相关输入成本，原文没有讨论这类供应商计费细节。

裁剪也有质量代价。原文举了一个假设：客服贴入 400 行改动，唯一关键的授权检查接近末尾。按字符数截断后，请求更便宜了，证据却没了。

作者建议记录 diff hash、省略行数和截断原因，把证据不完整的请求转入审查流程。这个例子不是实验数据，而是在说明：上下文预算不能只由字符串长度决定，还要考虑裁掉了什么。

留存同样需要取舍。作者偏好短期保留原始记录，较长期保留脱敏评估记录，并在审查窗口结束后删除原始提示词。这样会增加复现难度，工程师可能只能依靠脱敏样本排查；收益是删除请求的处理范围更明确，事故也不会暴露无限积累的客户对话。

原文没有给出具体保留天数。能拿走的是分层思路：摘要与精确事实分开保存，避免摘要丢掉否定词、版本号和客户最新约束；代码审查则在原始 diff 过期后，继续保留 commit identifier 与 diff hash。

用什么指标，才能选出适合业务的 API

作者建议从 100 个脱敏客服案例和代码审查样本起步，按任务与风险分组。审查样本至少覆盖正常改动、缺少测试、安全敏感改动、大 diff、畸形输入，另加客户意图模糊的对话。

每个样本要有预期问题类别，也要允许 needs_context。否则评估会奖励自信猜测，惩罚合理拒答。

下面这段代码展示了如何同时判断质量门槛和校验完成耗时：

from dataclasses import dataclass

@dataclass
class Decision:
    quality_ok: bool
    latency_ok: bool
    route: str

def choose_route(
    quality_score: float,
    p95_validated_ms: int,
    quality_floor: float = 0.90,
    latency_ceiling_ms: int = 2500,
) -> Decision:
    quality_ok = quality_score >= quality_floor
    latency_ok = p95_validated_ms <= latency_ceiling_ms

    if quality_ok and latency_ok:
        return Decision(True, True, "interactive")
    if quality_ok:
        return Decision(True, False, "interactive-with-queue-warning")
    return Decision(False, latency_ok, "review-or-human")

要看的是 quality_floor = 0.90 和 latency_ceiling_ms = 2500：两者都是策略示例，不是行业基准。p95_validated_ms 衡量的是结果通过校验的耗时，其第 95 百分位不应被首 token 时间替代。

供应商比较也应落到应用边界：流式输出、结构约束、取消请求、用量元数据、区域处理要求、数据留存控制、限流响应头，以及错误语义是否有文档。

原文提到 OpenAI Batch API 适合异步评估或排队审查，Anthropic 提供基于消息的请求与流式接口，Google Generative Language API 有自己的请求结构、配额和安全控制。这些只是接口差异的举例，没有提供横向测试结果。

重试规则也属于选型的一部分。网络故障和文档明确的暂时性错误，可以采用有上限的指数退避，并在 API 支持时使用幂等键。结构校验失败则不应原样重试，可用一次小而明确的请求修复，或转人工。限流响应应触发调度调整，继续增加并发只会扩大问题。

我的判断

我认同作者把「通过校验的结果」作为交付单位。对需要进入工单队列的审查结果，格式正确只是第一关，还要拒绝未知严重级别、缺少位置、没有证据的问题项。检索文本和客户输入也只能作为数据使用，工单访问权限必须由应用执行。

但这套方法仍是工程建议，不是已经验证的选型结论。文章没有公开候选模型、样本分布、评分细则、实际 p95 或成本对照。100 个案例适合作为起点，是否覆盖关键风险仍要检查；质量分达到 0.90，也不能直接理解为安全审查可靠。

任务分流还有分类成本。请求分错路径，可能让高风险任务进入快速通道。原文提出分类不确定时转人工，却没有展开如何识别这种不确定性。

与单一模型处理所有请求相比，两条路径增加了适配、评估和队列维护工作。对功能单一、风险较低的 FAQ，可以先采用单模型加严格校验；任务差异足够明显时，再引入分流。原文没有对照数据证明更复杂的路由一定划算。

能拿来做什么

• 给现有 Node.js 客服服务补上任务类型、截止时间和完成状态，让普通对话与代码审查能够分别设置上下文预算、超时及失败去向。
• 在前端流式界面区分生成中、完整结束和连接中断，并打通服务端取消路径，避免把收到部分文字统计成成功交付。
• 从真实业务整理 100 个脱敏案例，按任务与风险评分，同时记录校验完成耗时、修复率、队列等待和上下文大小，再决定是否更换 API。
• 为原始对话、脱敏评估记录和代码标识分别制定留存规则；审查结果提交后，再排队发送邮件或短信，避免通知超时被误记为 LLM 调用失败。