面试里被问「如果让你给我们的产品加个 AI 功能，你会加什么」，我的第一反应通常是防御性的：先别想加什么，先看现在哪里卡住了。
这个反应不太讨喜。它听起来像在回避问题，面试官想要的往往是一个具体的功能。但我确实见过太多「先有模型，再找场景」的项目，做到一半发现原本三行规则就能解决，最后不了了之。
所以如果只能给一个判断，我会说：这道题真正的考点是我能不能忍住不加。
先确认这是不是概率问题
规则和模型的区别，不在技术高低，在输出是不是确定的。
同一个输入，规则永远给同一个答案，模型给的是一个分布。这意味着引入模型的同时，我也引入了一类新的失败：它会错，而且错得没有规律。
所以我习惯先问一句，这个环节的输入是不是可枚举的。表单校验、权限判断、金额计算、状态流转，这些用代码写出来又快又准，硬塞一个模型进去，得到的只是更慢更贵更不稳定的同一个结果。
有个反面例子很典型：用模型判断邮箱格式对不对。正则几行代码，微秒级，百分之百准，还不用联网。换成模型，先要处理调用延迟，再要处理它偶尔把明显错误的地址判成合法。收益是零，风险是新增的。
值得用模型的地方，通常是规则写不完的地方：违规内容的变体、用户用自然语言描述的需求、需要按人的偏好排序的信息流。这类问题的共同点是边界模糊，没法把情况列全。今天补一条规则，明天出现一个谐音变体，规则的维护成本会一点点往上堆，堆到某个点就不划算了。
还有一种情况容易被忽略——错误代价极高的场景。这里不是不能用模型，而是不能只用模型。模型给建议，人做决定，中间必须有一道明确的卡点。没有这道卡点，准确率再高我也不敢让它自动执行。
反过来，如果一个问题错误代价低、反馈快、人工处理又极其昂贵，那模型即使只有八十的准确率也可能值得上。因为它替代的不是完美的人工，而是没人处理的那部分。
数据比模型选型更早决定成败
很多讨论会直接跳到「用哪个模型」。我觉得这一步太早了，早到没有意义。
真正决定这个功能能不能做的是数据：有没有、干不干净、能不能合法使用。
有没有，指的是历史积累里是否包含这个任务的输入和结果。想做智能客服，得先有聊天记录，还得有「这次有没有解决」的标记。只有对话没有结果，模型学不到什么是对。
干不干净，指的是这些记录能不能直接拿来用。真实日志里错别字、重复提交、测试账号、内部调试的对话混在一起，清洗的工作量经常超过后面的开发。
能不能合法使用，指的是用户是否同意、是否涉及敏感信息、能不能脱敏。这一条在 ToB 场景里经常成为硬约束，而不是可以后补的手续。
这三条里任何一条不成立，讨论模型选型都是空转。我遇到过的情况是数据量看着很大，但真正带标注的只有很小一部分，最后方案从「微调」退回「提示词加检索」，不是因为模型不行，是因为没有燃料。
数据还有一个隐蔽的问题：它反映的是过去。用历史成交数据训练的估价模型，遇到市场快速变化的时候会失灵，因为它学到的规律建立在旧的价格关系上。这种失效在离线测试里看不出来，因为测试集也是历史的。等到线上连续亏损，才发现模型一直在用旧世界的逻辑回答新世界的问题。
标注也一样。监督学习需要有人告诉模型什么是对，那这个「什么是对」由谁定义、定义得一致不一致，直接决定模型学到什么。标注团队换了一批人，标准就可能漂。这类问题不会在指标上立刻显现，但会在半年后变成一个说不清原因的瓶颈。
冷启动的时候，我倾向先用规则或者人工顶一阵，把流程跑起来，同时把过程记录下来。等有了几百上千条真实样本，再考虑换模型。这个顺序慢，但它不会让我在没数据的时候硬做一个演示品。
选型是承认三样东西不能同时要
延迟、精度、成本，这三样在绝大多数场景里没法同时拿满。
要快要准，就得多花钱，用更大的模型、更好的硬件。要快要便宜，就得接受精度下降，用小模型或者量化后的版本。要准要便宜，往往就得慢，把任务挪到离线批处理。
我做选型的时候会先确定哪一项是硬约束。实时交互的场景里，延迟通常是硬的，用户等两秒就会走，这时候牺牲几个点的准确率换响应速度是划算的。离线生成的场景里，精度是硬的，多跑几个小时没人在意。
接口调用和私有化部署也是同一个逻辑。前期验证用商业 API，快，不用养团队，缺点是按量付费、数据出域。量上来或者涉及核心数据以后，切到自建，成本结构从按次变成固定，但要有人维护。这两条路没有优劣，只有我当下更怕哪一种成本。
自建那条路最容易低估的是人。模型能部署起来只是开始，后面还有版本升级、显存规划、故障排查、评测集维护。这些活不会因为模型开源就消失，反而因为没人兜底而更显眼。我判断要不要自建的时候，会先问一句：出了线上问题，谁能在一小时内定位。答不上来，就先别自建。
真到了「模型就是慢」的时候，能动的其实不只是模型。高频且变化不大的请求可以预计算，用户来的时候直接读缓存；耗时长的任务可以改成异步，先给一个占位结果，完成后再通知；还可以做级联，先用一个小模型把大部分明显的情况处理掉，剩下的少量交给大模型或者人工。这些做法的共同点是：不在模型本身上硬碰，而是在流程上绕。
我不太喜欢在面试里听「我们用最好的模型」。这句话没有信息量，因为它没有说放弃了什么。真正有用的回答会带一句「所以我们在某个指标上认了亏」，那才说明他想过。
指标得能翻译成用户行为
「准确率」这个词在产品讨论里几乎没有用。
不是说它不重要，是它不指向任何决策。九十二和九十四的差别，对应到用户那里是什么，对应到收入那里是什么，这才是要回答的。
分类任务里，我一般先问误判的两个方向哪个更贵。宁可错杀还是宁可漏掉，这个选择应该由业务定，不该由算法定。垃圾信息拦截错杀的是正常内容，代价是用户投诉；漏掉的是违规内容，代价可能是事故。两个方向的成本不同，阈值就该不同。这时候谈「准确率」是没有意义的，因为同样一个数字，可能对应完全相反的两种系统。
生成任务更难。没有唯一答案，就没有办法逐字比对。这时候我会往行为指标上靠：用户是否采纳了这个建议，采纳之后改了多少，改完是否还留在流程里，下次还会不会用。采纳率低可能是模型不准，也可能是入口藏得太深；修改率高说明方向对了但细节不行；用一次就再也不用的，问题通常不在模型本身。
技术指标仍然要看，但它负责解释现象，不负责下结论。模型 A 的准确率比 B 高两个点，如果 A 慢了一倍导致用户中途放弃，那两个点就没有意义。
至于坏案例，我的底线是它必须有去处。要么降级到规则，要么转人工，要么明确告诉用户这条结果不确定。把不确定的输出包装成确定的结论，是我最不能接受的一种产品设计——它把风险从系统转移给了用户，而用户没有能力识别。
这道题我到现在也没有标准答案。不同的产品，能用的数据、能承受的错误、能付的成本都不一样。我能确定的只是顺序：先判断要不要用，再看数据够不够，然后才是选型，最后是指标。顺序颠倒过来，做出来的东西通常很好看，但没什么用。
评论