没人构建的“从支持工单到评估案例”流水线

每个运行 AI 功能的团队其实都正坐拥着他们所能拥有的最高信号评估数据集，但他们却没在利用它。这个数据集就在 Zendesk、Intercom、Freshdesk、Help Scout，或者任何支持团队工作的队列中。在那里提交的工单描述了模型在付费客户面前表现出的确切失败模式——语气错误、工具调用错误、违反政策、幻觉出的功能、上下文泄露。每一个都是由经历过失败的用户手写的、带有标注的负面案例，通常还免费附带了复现步骤和情绪标注。

与此同时，评估套件（Eval Suite）则存在于 Git 中。它是由半年前设置它的工程师手写的，从那时起可能只累积了大约五十个案例。“评估套件覆盖的内容”与“生产环境中实际出现的问题”之间的交集就像一张韦恩图，重叠的部分只有细细的一条，而两边则是互不相干的巨大圆圈。

填补这一鸿沟的做法（如果有人填补的话）通常是每个季度抽出一个下午——有时是整整一天——有人将工单导出为 CSV，在电子表格中打开它们，手动将它们改写为评估案例，然后将结果粘贴到测试文件中。这确实有效。但这也就是一次性的英雄主义努力，在交付的那一刻起就开始失效，而且做过一次的团队几乎从未以同样的频率做第二次。

为什么这个差距是结构性的，而非因为懒惰

这个流程之所以不存在，并不是因为没人注意到这些信号。每个读过 Hamel Husain 文章的 AI 工程师都知道，用户反馈信号——负面评分、支持工单、升级投诉——是他们应该挖掘的数据。它之所以不存在，是因为这两个系统由两个拥有不同语境的团队分别所有。

支持团队拥有 Zendesk。他们按照自己的分类体系（“账单”、“账户访问”、“物流”）对工单进行分类，配备人员以保证响应时间，并以 CSAT（客户满意度）作为衡量标准。他们没有“评估案例”的概念，也没有理由去学习它。工程团队拥有评估套件。他们按失败模式（“引用缺失”、“工具错误”、“Schema 违规”）对案例进行分类，配备人员进行模型迁移，并以回归覆盖率作为衡量标准。除了只读的 Slack 通知外，他们没有 Zendesk API 的访问权限，也没有时间去学习一个并非为他们设计的客户支持数据模型。

这种跨团队的转化工作——阅读工单、判断它是模型失败、产品失败还是误用失败、提取触发失败的输入、将其规范化为评估 Schema——是没有任何人专门负责的工作。因此，这项工作只能由那些在某个下午还有精力的人来完成，而且处理的通常是那一周恰好最受关注的案例。剩下的 90% 的工单就像信号一样，在原地腐烂。

Salesforce 在 2025 年末发布的一项 CRMArena 基准测试发现，尽管 LLM 智能体处理了 58% 的单轮客户支持任务，但仅解决了 35% 的多轮任务。失败点集中在支持工单最能捕捉到的确切模式中：对话早期提到的信息到需要执行操作时已被智能体遗忘；涉及退款和升级等受政策约束的安全操作；以及客户表达同一潜在需求时千奇百怪的措辞方式。这些失败是工程团队通过阅读自己的内部测试对话记录永远无法发现的。它们只会在工单中浮现，且仅在工单中浮现。

常态化流水线究竟需要什么

一个真正的“从支持到评估”的流水线不是一个简单的将工单复制到 JSON 文件中的任务调度器。它是一项分为四个阶段的纪律，每个阶段都必须有专人负责，否则就无法运行。

第一阶段是 带有溯源信息的摄取。工单进入一个暂存表——而不是评估套件本身——并保留完整的原始负载：工单 ID、时间戳、用户消息、客服回复（如果有）、模型调用的 Trace ID（如果你的系统有生成的话），以及支持人员的手写解决笔记。溯源很重要，因为两个月后，当有人查看一个已经失败了一周的评估案例时，知道它是否仍然相关的唯一方法就是循着链条追溯到原始工单，并询问底层产品行为是否已经改变。

第二阶段是 分拣与分类。并非每个工单都是评估案例。必须将属于案例的工单与不属于的分离开来，并为属于案例的工单贴上失败模式的标签。做得好的团队会运行一个轻量级的基于 LLM 的分类器——这本身也是一个经过评估的基础设施——它会提议一个标签和置信度分数，并设有一个队列，由人工审核低于阈值的所有内容。完全依靠手动无法扩展到每周 200 个工单以上。完全依靠自动化则会用模型自身的盲点悄悄改写你的评估集。混合模式是唯一可行的方法。

第三阶段是 规范化为评估 Schema。支持工单是用客户的散文式语言编写的。它们引用的内部功能名称可能后来已经更改。它们包含无法复现的截图。它们有时描述的是跨多个会话发生的失败。将工单转化为评估案例意味着提取复现失败所需的最小输入、预期行为（通常通过阅读支持人员的解决方案）以及用于捕获错误的断言。这是没人愿意做的一步，因为它速度慢、依赖判断且容易出错。但这也是决定生成的评估案例是否值得运行的关键步骤。

第四阶段是 与回归套件挂钩。如果没人在出错时注意到，那么一个新的评估案例就毫无价值。从工单中挖掘出的案例必须流入同样的回归运行流程中，用于守卫 Prompt 更改或模型迁移。它们必须贴上所防御的失败模式标签，这样当评估失败时，排查路径就是“查看失败模式标签，找到来源工单，判断回归是否属实”。没有这种追溯链接的案例会在一个月内变成告警疲劳。

只有在工单中才会看到的失效模式

建立这项规范（而不是继续依赖工程师编写的合成评估案例）的原因在于，工单中出现的失效模式往往是工程师无法想象的。在认真开展这项工作的团队中，有三种模式经常反复出现。

第一种是政策驱动型失效 (policy-shaped failures)。客户提出的问题，模型在某个管辖区被允许回答，而在另一个管辖区则不行。或者，模型提供了一项退款，但公司政策规定这需要人工批准。工程师不会为这些情况编写评估案例，因为他们不了解政策 —— 政策存在于支持团队的脑海中，以及他们使用的处理宏 (resolution macros) 里。工单能揭露这些问题，因为违反政策正是触发工单的原因。

第二种是分布外措辞 (out-of-distribution phrasing)。工程师用工程师的语言编写评估案例：清晰、结构化，通常是对产品文档的改写。而客户用客户的语言：含糊不清、意图复杂，充斥着错别字和记忆模糊的产品内部术语。措辞的多样性是生产环境展现出来的，而内部测试 (dogfooded) 评估无法覆盖这一点。工单是现成的真实语料库。

第三种是多轮对话漂移 (multi-turn drift)。手写的评估套件中以单轮评估为主，因为它们易于编写且易于评分。真实的失效通常是多轮的 —— 客户在第二条消息中给了智能体一个关键约束，而智能体到第五条消息时已经忘记了。当客户粘贴完整的对话记录时，工单会捕获这些内容，而客户这样做的情况比工程师预想的要频繁。挖掘这些内容的团队会顺带获得一套多轮评估集。

评估流水线容易在哪里夭折

预料之中的有三个地方。第一是分类器漂移 (classifier drift)。基于 LLM 的分拣分类器是根据上季度的失效模式训练的。六个月后，模型升级了，产品上线了两个新功能，分类器就会悄无声息地将新的失效模式误分到“不相关”类别。解决方法是将分类器本身也纳入评估 —— 每月抽样 50 个工单，让人工重新分类，并观察一致率。如果分类器的一致率低于某个阈值，就进行重训或重写。

第二个是评估集膨胀 (eval-set bloat)。一旦流水线开始运行，评估集就会随着工单量线性增长。一年之内，一个起初只有 50 个案例的团队可能就会运行 2000 个案例，回归运行需要 40 分钟，工程师就开始在本地跳过它。这需要一套淘汰政策：对于连续 90 天保持“通过”状态且在套件中有重复的案例，应予以存档。对于与已移除功能相关的案例，应予以删除。评估集不是博物馆。

第三个是支持团队的配合 (support-team buy-in)。流水线依赖于支持专员编写对规范化真正有用的解决备注 —— 指出失效模式、描述预期行为、链接到相关的宏。如果工程团队在不涉及支持团队的情况下构建流水线，解决备注将继续显示为“根据宏 47 已解决”，规范化阶段将停滞不前。解决方案是对支持工作流进行微调：在标记为“AI 相关”的工单上增加一个结构化字段，用一句话记录预期行为。对于支持经理来说，这是 5 分钟的改动，但对于评估流水线来说，这是 10 倍的质量提升。

能够真正落地的规范形式

在 2026 年成功运行这套体系的团队都有一些共同的小习惯。他们有一名工程师 —— 不是一个团队，而是一个人 —— 其明确的职位描述包括“负责支持到评估的流水线”，并且每周审查分类器的输出结果。他们有一个 Slack 频道，分类器会实时发布新的候选评估工单，因此工作是增量式的，而不是每季度一次。他们有一个定期清理任务 (cron)，每月精简评估集。他们有一个仪表盘，显示每个失效模式标签每周有多少工单以及有多少回归套件案例 —— 当这些数字出现偏差时，就表明某个类别未得到充分检查。

那些没有这些习惯的团队，在六个月后会发现，他们的评估套件仍然在对编写时那些重要的失效模式进行评分，而忽略了在那之后出现的模式。他们会在工单中发现回归问题，但没有流程将该工单转化为案例。他们会每季度安排一个下午手动操作，而闭环永远无法形成。

支持工单是你所能产生的最昂贵的评估案例。有人遭遇了糟糕的体验，投诉了它，并为你写了下来。将其丢弃是 AI 团队所做的最昂贵的事情，而几乎每个团队都在这么做。这条流水线并不光鲜，涉及跨团队协作，操作起来甚至有些乏味。但它也是你本季度可以建立的杠杆率最高的评估基础设施。