一个简单的人工智能项目管理问题就能区分你是新手还是专家
人工智能模型选择已成为一项非常关键的技能,并且在很多面试中都会被问到。
想象一下,你的CEO让你为一款每月处理200万个工单的食品配送应用程序构建一个AI客户支持代理。你觉得只要用最好的模型就行了,比如 GPT-5、Claude Opus 或 Gemini 3,接线好就发货。你算算账,就会发现投资回报率根本不划算。
如果你作为人工智能产品经理的本能是默认选择排行榜上的前沿模型,那么你最终会推出一款赢得试点项目但最终亏损的产品。你的代理会觉得自己很聪明。你的利润率会变成负数。你的首席财务官会问,为什么人工智能推理会吞噬掉你承诺的节省 费用的一半 。
这是人工智能项目经理如何进行模型选择决策的第一性原理分析。我们将通过一个实际案例来详细讲解。
一 场景
您是一家外卖公司的人工智能产品经理。
你们每月有200万个支持工单。目前人工客服处理这些工单的成本约为每个0.5元。每月支持总成本为100万元。你的CEO给你下达了任务。用人工智能代理将任务量减少70%。
工单问题的 分配情况如下 :
50% ~ 我的订单在哪里?
20% ~ 缺少物品或食物已冷掉。
约 15% 为退款纠纷。
约 10% 是餐厅质量投诉。
5% 是复杂的多轮升级事件,涉及支付失败、账户问题或愤怒的用户要求管理人员介入。
有些工单只需三秒钟就能解决。有些需要三十个来回的沟通。有些需要阅读之前的六个工单才能理解用户的问题。有些用户晚上十点饿得不行,还用全大写字母打字。最简单的解决方法是搭建一个 Frontier 模型,并将所有工单都通过它进行处理。让我们看看这样做会发生什么。
二 什么是模型选择
模型 选择并非供应商的决定,而是一个在严格的业务约束下进行的五维优化问题。
你正在帕累托前沿上选择一个点,该前沿由任务匹配度、延迟、成本、上下文和可控性定义。没有哪个模型能同时满足所有五个条件。每一个选择都是一种权衡。对于这位客服人员来说,这笔交易很复杂。如果每张 单据 都采用前沿模型,质量就会很高。
假设每月处理两百万张工单,每张工单平均对话次数为五轮,每张工单的成本约为 0.27 元,那么每月支出将达到 54 万元。你已经浪费了原本应该节省成本的 54%。再加上基础设施、监控、安全措施和重试机制的成本,实际花费将超过 70%。
如果每张 工单 都用便宜的 模型 ,成本就没问题。但该模型会臆造退款政策,误读印式英语,并且仍然会将一半的工单转交给人工处理。你的转接率从 70% 骤降至 30%。反过来,情况也一样糟糕。
两种极端方案都不可行。正确的答案介于两者之间。 战略 将决定答案的走向。
三 战略赌注
这是大多数项目经理完全忽略的一点。您即将构建的支持代理并非运行在单一模型上。它运行在路由层上,该路由层决定哪个模型处理哪个工单。
— > “我的订单在哪里?”这个问题需要进行数据库查找,使用一个小型模型来格式化响应,并且延迟目标低于 500 毫秒。
— > 对于一位已经经历过三次糟糕体验的愤怒用户提出的退款争议,需要前沿模型、详细的背景信息和两秒钟的真正推理。
将这两个请求塞进同一个模型中,只会让你同时损失金钱和用户。
路由 层 是您真正产品智能所在之处。它能将通用基础模型转化为盈利的支撑运营。
任何人都可以调用 OpenAI 或 Anthropologie 的 API。但竞争对手难以轻易复制的是,你拥有长达 18 个月的 预测 数据,这些数据记录了你的特定用户在哪个模型下,哪个置信度阈值下,哪 类工单解决较好 情况。
因此,问题陈述就变成了——我们如何将每个收到的工单与最便宜的模型相匹配,该模型仍然能够满足用户的质量标准,符合我们的延迟 SLA,并且相对于人工支持成本具有正的利润率?
过度依赖昂贵的模型和推理会抵消节省的成本。过度依赖廉价模型会导致重定向失效,因为人工干预最终会造成损失。
四 五大限制
在选择模型之前,你需要根据五个约束条件对每个候选模型进行评分。大多数产品经理只会考虑其中一两个约束条件。
约束条件 1:任务匹配度
任务匹配度衡量模型的训练结果与实际 工单 的匹配程度。
“我的订单在哪里?”这不是一个推理任务,而是一个用自然语言包装的结构化数据查找任务。
在这里,小型模型配合数据库调用比前沿模型更胜一筹。前沿模型会写入过多数据,人为设定交付预估时间,并进行不必要的 嵌套推理 。
退款纠纷是一个推理任务。用户会参考之前的工单,提供背景信息,进行协商,并可能升级纠纷。一个简单的模型无法解决问题。你需要一个更全面的模型。
同一个代理会处理这两个任务。任务匹配度会告诉你,它们不能由同一个模型处理。
唯一能客观评价任务匹配度的方法是建立内部评价体系。
200 张真实工单,按工单类型比例抽取。每个候选模型都会运行此数据集。由人工或评估模型根据评分标准对输出结果进行评分。此评估数据集由产品经理而非机器学习团队所有,并且每月使用真实生产数据进行更新。
约束条件 2:延迟
用户点击发送按钮后,等待首次验证成功所需的时间就是用户感受到的时间。
对于占总数 50% 的订单状态查询,您的目标响应时间应低于 500 毫秒。用户会感到焦虑。每多等一秒,他们转而打开 Twitter 的概率就会增加 10%。
对于 5% 的复杂升级情况,如果回复明显经过深思熟虑,2 秒钟的回复时间是可以接受的。用户已经处于严肃的对话中,并期望得到重视。
你的路由 层 本身就有延迟。如果你的意图分类器需要 300 毫秒才能决定将工单发送到哪里,那么在实际模型开始生成之前,你已经消耗了用户的大部分延迟。
这就是为什么分类器模型几乎总是很小,通常经过精简或微调,以使其运行时间低于 50 毫秒。路由 层 不能成为瓶颈。
约束条件 3:成本
每月 200 万张 工单 ,仅使用前沿推断进行计算。
平均每张 工单 :五轮,每轮大约累积 2000 个输入代币和 400 个输出代币。按照前沿模型价格,每百万个输入代币约 15 元,每百万个输出代币约 60 元,一张 工单 的成本约为 0.27 元。
每月 200 万张 工单 ,每张 0.27 元,纯粹推断就是 54 万元。
你们的人工成本基准是100万元。而你们的AI推理能力就占了其中的54%。你们的CEO对此并不满意。
现在用路由系统运行同样的数学运算。
- 70% 的门 工单 都 流向 了每张 0.01 元的廉价模型。
- 25% 的收益流向了中等价位的产品,价格为 0.08 元。
- 5% 的份额分配给了每股价格为 0.27 元的前沿模型。
- 加权平均每张 工单 的成本为 0.04 元。每月总推断成本:8.1 万元
相同的偏转率 ,收益 度几乎是原来的7倍。
约束条件 4:上下文和记忆
客服人员需要一些背景信息,例如过往订单、同一用户之前的订单、餐厅政策、当前促销活动、配送员备注等等。
人们的第一反应是把所有东西都塞进一个 200K 的上下文窗口中,然后让模型自己去处理。这样做有两个弊端。
模型在超过一定上下文长度后性能会明显下降,通常在 3 万到 10 万个词元之间,具体数量取决于模型。这就是所谓的“中间状态丢失”问题,而且这个问题确实存在。
成本会随着每回合中包含的每个 词元 而增加,这种情况会遍及数百万张 工单 。如果每回合都盲目地传递一个 5 万个 词元 ,那么你原本 0.04 元的 工单 就会变成 0.25 元。你已经用额外的步骤重建了原本只考虑边界的问题。
正确答案是检索。仅提取相关的历史订单、特定餐厅的政策、最近两张小 工单 以及用户的 LTV 等级。将上下文信息控制在 4000 个 词元 以内。让路由 层 决定何时小 工单 的复杂程度足以需要提取完整的历史记录。
检索赋予你控制权。而海量上下文信息则像一个黑匣子,随着你不断填充它,情况会悄无声息地恶化,成本也会越来越高。
约束条件 5:可控性
客户支持模式无法凭空捏造退款政策。
如果对方声称会全额退款外加 500元 的代金券,而你的政策并非如此,那么你面临两个问题。要么你履行承诺,蒙受经济损失;要么你拒绝,然后可能在 网络 上引发轩然大波。
可控性是指模型在对抗性输入下能够可靠地遵守你的规则的程度。
前沿模型通常功能更强大,但并非总是更易于控制。一个经过精心调校、规模更小的模型,如果根据您具体的退款政策进行训练,就能比一个带有巧妙提示的前沿模型更可靠地遵循规则。对于占总工单15%的退款争议而言,可控性比单纯的功能更重要。
大多数产品经理只关注前两项限制条件。而优秀的AI产品经理会根据所有五项限制条件对每个候选产品进行评分,记录交易过程,并每季度重新评估评分标准。
为什么——只需使用最先进模型——在这里行不通
这种说法并不新鲜。LLM的价格正在下降,或者未来会大幅下降。性能却翻了一番。只需选择顶级 模型 ,然后耐心等待即可。
客服人员这样做有三点错误之处。
你的竞争对手可没时间等你。如果他们今天就部署路由系统,每月就能节省 45 万元,并将这笔钱重新投入到提升交付速度或降低获客成本上。等到前沿 模型 市场价格下降时,你的增长机会早已被他们蚕食殆尽。
最佳状态是相对于机 工单 等级而言的,而非相对于基准。在结构化退款查询中,前沿模型不如经过微调的小型模型。
成本降低并不会惠及用户。每次推理成本降低,用户都会期望获得更丰富的响应、更长的上下文信息和更高的自主性。如果你的单位经济效益今天很差,那么即使换成更便宜、功能更强大的型号,明天的单位经济效益依然会很差。
押注最先进模型就好比为了避免实际的问题而缴纳的税。
专为代理构建的路由模式
你的路由 层 由五个组件构成。
每个工单前都运行着一个意图分类器。这是一个经过微调的小型模型,运行时间不到 50 毫秒。它读取工单并返回五个标签之一:order_status(订单状态)、missing_item(商品缺失)、refund_dispute(退款纠纷)、restaurant_complaint(餐厅投诉)和 complex_escalation(复杂升级)。它还会返回一个置信度评分。
模型分配表。order_status 数据分配给一个小型模型,并调用数据库。missing_item 数据分配给一个中等层级的模型,并返回模板响应。 refund_dispute 数据分配给一个根据您的退款政策训练的、经过微调的小型模型。restaurant_complaint 数据分配给中等层级的模型。复杂的升级事件分配给前沿模型。
置信度阈值。如果分类器返回的置信度较低,则工单升级一级。如果主模型返回的置信度仍然较低,或者用户回复“这是错误的”,则工单再次升级。第三次升级将由人工处理。
缓存层。在一小时内,40% 的“我的订单在哪里”查询都集中在同一个城市中少数几个延迟订单上。将每个订单 ID 的响应缓存起来,TTL(生存时间)为 60 秒。缓存命中后,推理成本为零。
预测 层。每个工单都会记录分类器标签、选择的模型、消耗的令牌、延迟、用户反应和最终处理结果。路由智能正是在这里发挥作用。
其精妙之处不在于组件本身,而在于基于 预测 数据对分配表进行持续调整。
一张工单,全程
通过路由跟踪单个工单。
用户于晚上 9:47 输入“bhai order Kidhar hai, 45 min ho gaye”。
该 工单 到达边缘。对其进行哈希处理并与缓存进行比对。未找到匹配项。
请求被送至意图分类器。分类器返回订单状态,置信度为 0.93。耗时 42 毫秒。
路由器会查找分配表。置信度高的 order_status 会交给小型模型,并调用数据库进行 处理。
同时,系统会获取用户的当前订单和配送员的当前 GPS 位置。耗时 80 毫秒。
小型模型接收工单及结构化上下文信息,并生成“您的订单还有 4 分钟即可送达。配送员正在最后一段路程中”。首次令牌生成时间:210 毫秒。总响应时间:480 毫秒。
预测 数据记录了完整的跟踪信息,包括 工单 证类别、使用的模型、消耗的令牌、延迟以及用户的下一条消息。
用户回复“好的,谢谢”。 预测 数据将此标记为问题已解决。
路由 层 选择了正确的 模型 。用户很快就得到了回复。这张工单的成本仅为 0.004 元,而人工成本为 0.5 元。每月处理一百万张类似的工单,您就能明白真正节省的成本在哪里了。
这就是产品。模式的选择决定着企业的成败,而这正是产品经理的职责所在。
本文来自微信公众号“数据驱动智能”(ID:Data_0101),作者:晓晓,36氪经授权发布。















