你的销售团队正在悄悄运行的演示账户评估集
你公司最昂贵的评测集 (eval set) 并不在你的代码仓库里。它藏在销售工程师六个月前整理的一份幻灯片里,外加三个以你前五大客户命名的演示账号,以及一段半记不清的脚本,上面写着“点击这里,让智能体总结上个季度,见证奇迹的时刻”。它每周运行一两次,面向价值六位数或七位数的潜在客户。AI 团队里没有人曾为它完整跑过一次。
接着,你在某个周二发布了模型迁移。周四下午 4 点,销售工程师在值班频道发消息:摘要输出现在以“当然可以!这是摘要……”开头,而不是直接进入要点;数字被拼写成了单词而非阿拉伯数字;而潜在客户 —— 一位在四周前就预约了这次会议的财富 500 强 CFO —— 刚刚询问该产品是否一直这么啰嗦。发布说明称这是一次 1.2 个百分点的评测提升 (eval lift)。
提升是真实的。只是衡量它的评测集并未包含该产品整个季度处理的、在商业上最重要的交互。
销售演示本质上就是评测集,无论你是否这样看 待它们
从结构上看,评测集是一份冻结的输入列表,带有预期行为,可按需运行并评分。销售演示也是一份冻结的输入列表,带有预期行为,可按需运行并评分 —— 区别在于,输入是演示步骤,预期行为是“潜在客户点头”,而评分发生在一个直播间里,在那里,回归 (regression) 的代价是丢掉一笔无法成交的订单。
三个属性使得演示账号在形式上表现得极其像评测集:
- 它们很稳定。 同样的五六个演示账号被用于所有的潜在客户电话。其中的数据几乎不变。上个季度奏效的演示流程被期望在这个季度同样奏效,因为销售工程师 (SE) 围绕“它会奏效”这一假设构建了整个对话节奏。
- 它们经过了风格化处理。 演示数据是经过策划的 —— 干净、均衡,专门为了展示 AI 功能而挑选。这正是那种低噪音、简单模式下的输入,细微的行为转变(冗长度、格式、拒绝风格)在其中最为明显。
- 它们由注意到一切细节的人类进行测试。 Zoom 会议中的潜在客户不是扫一眼输出就划过去的普通用户。他们会盯着屏幕看上三十秒。一个结尾句号、一段额外的开场白、一段本该正确却出现幻觉的公司名称 —— 这些在演示中是显眼的失败,而在生产环境中则是沉默的故障。
一个在离线基准测试中得分很高,但在这些维度上略有漂移的模型,会通过你的发布审核,却在销售流程中折戟。总体的评测分数捕捉不到这一点,因为演示账号在总流量中占比极小。对业务最重要的那一小部分在发布决策中却没有任何权重。
为什么你现有的黄金集 (Golden Set) 无法覆盖这一点
大多数已上线一年的 AI 团队都构建了一两个黄金追踪数据集 (golden trace datasets) —— 采样的生产流量,经过冻结,由 LLM 裁判或程序化检查进行评分。这些是真正的评测,也是必要的。但它们在系统性上对演示数据的分布是视而不见的。
问题在于采样。生产流量由执行中庸任务的中庸用户主导。如果你每天流量的四分之一是来自一千个低价值账号的同样的枯燥摘要请求,那么均匀采样的黄金集大部分就是这些内容。而客户经理 (AE) 运行给企业潜在客户看的演示流程 —— 一个包含 CRM 查询、多文档摘要、图表生成、后续追问以及必须在 15 秒内给出的最终回答的六步编排过程 —— 看起来完全不像中庸的请求。它看起来更像是一场模型必须按顺序完美完成的风格化编排。
另外两个采样缺口使情况变得更糟:
- 数据不同。 演示账号持有的是经过策划、均衡的数据。生产账号持有的是凌乱、不完整、经常为空的数据。一个在空字段上产生幻觉的能力变差的模型,在生产流量上得分可能更高(因为空字段很常见,且回答“我没有足够的信息”是正确的),但在演示中得分会更低(因为每个字段都有内容,而对冲式的回答会显 得奇怪地逃避)。
- 预期不同。 生产环境有关于 p95 延迟、准确率、拒绝率的 SLO。演示则有审美上的期望:响应应该在屏幕共享解说的一呼一吸间完成,格式应该看起来精致,语气应该自信而不谄媚。你现有的评测无法对这些属性进行评分。
增加采样频率无法解决这个问题 —— 演示类的流量不被重视并不是因为样本量小。而是因为它是一个完全不同的分布,而你根本没有从中采样。
周四下午的失效模式
在我见过的每一家规模化发布 AI 功能的公司中,团队发现这一差距的方式都如出一辙。顺序如下:
- 模型迁移在周二发布。离线评测通过,且有小幅提升。生产流量上的金丝雀测试 (Canary) 在 24 小时内看起来很正常。
- 周三:无异常。
- 周四下午:一名正在运行高风险演示流程的销售工程师注意到,助手现在在结构化响应前增加了开场白,或者将 JSON 包裹在演示界面无法剥离的三反引号中,或者拒绝了一个曾经可以处理的步骤,或者生成了一个略有不同的图表标题,破坏了他们留档幻灯片中的截图。
- 销售工程师在 AI 值班频道发消息。AI 团队现在正在处理一起生产事故,抄送了销售主管,且涉及一笔 140 万美元 ARR 的订单。
- 修复方案要么是 (a) 完全回滚迁移,收回那 1.2 个百分点的提升,要么是 (b) 手动修补特定的演示行为,增加一个没人记录的隐形特殊情况。
无论哪条路都代价昂贵。更深层次的代价是 AI 团队现在对销售部门背负了信誉债 —— 每一次未来的迁移都会受到质疑,每一次未来的评测提升都会换来一句“但你在 Acme 的演示流程上测过了吗?”,信任环路因此收紧。
唯一能捕捉到这一点的是对演示流程进行一次单一的确定性运行 —— 这是一个五分钟的工作,原本应该是迁移的准入门槛。但没有人做,因为组织两边都没有人负责它。
真正“掌控”演示评估集是什么样的
这种修正应该是结构性的,而不是靠英雄主义。它要求将演示套件从口头相传的传统转变为 AI 团队可以据此评分的版本化产物。在不同公司中通用的模式包含四个部分。
SE 团队可以自行运行的演示追踪(demo-trace)摄取路径。 销售工程师在记录新的演示流程时,应该只需按下一个按钮就能将追踪贡献到评估套件中。这意味着一种低摩擦的采集方式(浏览器扩展、产品内的“保存此会话”功能,或者接收会话 ID 的 Slack 机器人),而不是给 AI 团队发 Jira 工单。如果贡献的难度超过十秒,SE 就不会去做,评估套件也会过时。贡献的追踪会被打上切片标签:哪种潜在客户类型、哪个行业、展示的是哪个功能。
发布前的演示回归网关。 在任何模型或提示词(prompt)更改通过金丝雀发布之前,演示套件都会以确定性种子端到端运行,并对输出进行比对——既包括程序化比对(格式正则匹配、长度阈值、JSON/schema 的结构检查),也通过 LLM 评审员(LLM judge)根据之前批准的输出进行评分。如果套件中的任何流程在硬约束检查中出现退化,发布将被阻断,直到团队明确接受该退化或进行修复。这与团队已在通用生产流量中使用的影子测试(shadow-testing)模式相同,只是按演示队列而非用户队列进行切片。
能向业务部门反馈演示健康状况的切片感知报告。 当销售负责人询问“新模型在周五的 Acme 电话会议中安全吗?”时,回答不能是“综合评估上升了 1.2 分”。而必须是“Acme 的流程追踪通过了七个步骤中的全部七步,且硬约束违规为零,LLM 评审员在语气评分上给出了 4.6 分(对比之前的 4.7 分)”。这是切片级的报告,而不是综合级的。仪表板必须指名具体的交易和潜在客户,而不是百分位数。
作为常驻任务的会议前冒烟测试。 在任何高风险演示的前一晚,套件会针对当前的生产模型运行潜在客户特定的流程。如果与 SE 上次的签署确认(sign-off)有任何差异,AI 值班人员会在会议前收到通知,而不是在会议期间。每次运行的成本仅为几分钱,却能避免谁都不想遇到的那种“周四下午”。
技术转型背后的运营转型
技术模式很简单,难点在于组织架构。演示套件必须在 AI 团队中有一个明确的负责人——通常是前线部署工程师或同时兼顾两方的提示词工程师——负责保持其更新,参加销售启动会,并与 SE 负责人进行每周例会。如果没有这个角色,套件就会偏离:SE 团队增加了未被摄取的新流程,AI 团队推送了未受管控的迁移,差距会在一个季度内再次拉大。
销售组织也必须做出妥协:放弃在潜在客户面前即兴发挥演示流程的自由。每一个重要的流程都必须作为版本化产物存在于评估套件中。即兴发挥的 SE 实际上是在对客户运行一次未经测试的 A/B 测试。对于一个崇尚适应能力的职能部门来说,这是一个艰难的文化要求——但替代方案就是每个迁移周期都会重复发生的“周四下午”。
评估团队也必须放弃一些东西:综合评分上升带来的舒适感。切片感知报告意味着一些在综合层面看起来是胜利的迁移会被搁置,因为演示切片没有变化或略有变坏。这种权衡是正确的——导致你丢掉 Acme 续约合同的 1.2 分提升根本不是提升——但这需要 AI 负责人以切片为术语向领导层解释“推迟”发布的原因,而这是大多数团队尚未建立的一种能力。
演示之外的模式
一旦你为演示建立了这种纪律,同样的模式也适用于公司内部其他所有无人负责的评估集。CEO 在每次模型更新后都会亲自检查的最爱查询。在融资电话会议上必须看起来完美无瑕的投资者演示。某一种特定请求模式占据主导地位的合作伙伴集成。在每周业务回顾中被引用的内部高管仪表板摘要功能。
这些都是 AI 团队没有记录、不据此评分,且只有在重要人物生气时才会发现的评估切片。成熟的模式在每种情况下都是一样的:命名切片、捕获输入、设置明确的通过标准、在每次发布前运行、单独报告。演示套件只是这些中最不容忽视的一个——也是最容易开始的一个,因为销售团队已经有一份他们每周都在使用的账户和流程清单。他们一直在帮你运行你的评估集。唯一缺失的是你从未向他们索要过数据。
如果你交付 AI 功能并且有销售流程,请在本季度进行审计。询问你最顶尖的五位 SE,他们使用哪些演示账户,运行哪些流程,以及他们悄悄绕过了哪些模型输出变化。你会发现一个隐藏在眼前的评估套件,而将其规范化的成本将小于下一个“周四下午”的成本。
- https://www.codeant.ai/blogs/llm-shadow-traffic-ab-testing
- https://www.statsig.com/perspectives/shadow-testing-ai-model-evaluation
- https://www.braintrust.dev/articles/llm-evaluation-guide
- https://medium.com/@jickpatel611/the-single-most-useful-eval-youre-not-running-805acb71e3e6
- https://www.getmaxim.ai/articles/building-a-golden-dataset-for-ai-evaluation-a-step-by-step-guide/
- https://www.langchain.com/articles/llm-evals
- https://agenta.ai/blog/prompt-drift
- https://www.comet.com/site/blog/prompt-drift/
- https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
- https://dev.to/wassimchegham/why-your-ai-agent-demo-falls-apart-in-production-1320
- https://heavythoughtcloud.com/knowledge/designing-a-golden-set
- https://www.presalescollective.com/content/the-future-of-pre-sales-how-demo-automation-and-ai-are-transforming-presales
