准确率和召回率：一对必须做取舍的指标
以内容审核这个最经典的场景讲清楚。平台有一万条内容，其中 100 条违规。模型揪出 120 条说它们违规，其中 90 条真违规、30 条误伤。那么：精确率（precision）= 90/120 = 75%，意思是被判违规的里有七成五真违规；召回率（recall）= 90/100 = 90%，意思是真违规的里抓到了九成。常说的「准确率」在业务沟通里通常泛指「整体对不对」，但正式讨论一定要分清这两个，因为它们方向相反：把判定阈值调严，误伤少了（精确率升）但漏网多了（召回率降）；调松则反过来。
PM 的价值在于决定往哪边倾。尺度只有一个：漏掉和误伤，哪个代价大。涉政、涉黄的内容审核，漏一条可能出监管事故，召回率优先，宁可多误伤再靠人工复审捞回来；医疗初筛、金融风控告警同理。反过来说，电商搜索里把正常商品误判成违规下架，直接伤商家和 GMV，精确率就得往上抬。能讲出「我在 XX 场景选择了保召回，因为漏检代价是 XX」这种带因果的取舍，比背定义强十倍。
生成式场景没有标准答案，指标要换一套
准确率召回率管的是分类判断类任务，LLM 生成任务得用别的尺子：事实正确率（回答里有没有编，靠人工抽检或模型裁判）、忠实度（RAG 场景里回答是否严格基于检索到的材料，跑题和加戏都是扣分项）、拒答率（该拒的拒了没有，不该拒的乱拒没有——过度拒答是企业场景的高频投诉）。还有用户侧的结果指标：采纳率（代码补全里用户接受了多少比例的补全，Copilot 公开提过采纳率在三成上下这个量级）、会话解决率（客服场景多少会话没转人工就结束了）。PM 要把技术指标和业务指标之间的传导关系讲清楚，比如「事实正确率从 92% 提到 97%，转人工率降了 X 个点」。
延迟：平均数会骗人，要看分位数
LLM 产品有三个延迟概念要分清：首 token 延迟（TTFT，用户发出请求到看到第一个字的时间），这是「卡不卡」的直接感受，及格线大约 1 秒，超过 3 秒用户就开始怀疑坏了；生成速度（每秒多少 token），人阅读速度大约每秒 5-10 个汉字，生成比这个快就不影响体验；端到端总时长，长回答场景要控制。
关键是别用平均延迟做承诺，要用 P95、P99。平均 800 毫秒听着不错，但可能 5% 的请求超过 5 秒——对 DAU 几十万的产品，那 5% 就是每天几万人次的糟糕体验，而且往往集中在高峰时段，正好砸在最多的用户头上。压测和容量规划都要按 P99 谈。
并发和吞吐：体验的隐形地基
并发是系统同时处理的请求数，超了排队，排队就是延迟暴涨。LLM 服务的并发比传统 Web 服务金贵得多——GPU 推理的吞吐有限，还分「预填充」（读输入）和「解码」（吐输出）两个阶段，长输入占资源特别狠。PM 不需要会算 KV cache，但要会算容量账：预估峰值 QPS 是多少、按当前推理资源能扛多少、扛不住的时候是排队、限流还是降级（高峰期把免费用户从旗舰模型切到小模型，很多产品都干这个）。上线前拉着工程团队做压测，把「峰值翻倍怎么办」的预案写进发布 checklist，这是 PM 的基本功。
指标的落脚点是体验分级
最后把指标收拢成一句 PM 视角的话：技术指标的存在是为了定义「什么叫体验合格」。我的做法是把核心指标分成三档写进产品需求——红线（比如 P99 首 token 延迟 < 3 秒、事实正确率 > 95%）、目标线（P99 < 1.5 秒、正确率 > 97%）、上限（资源允许时追求的值）。上线验收看红线，迭代优化奔目标线。没有这套分级，「提升体验」永远是句空话，技术团队也不知道劲往哪使。