假如你要开一家小餐厅，光有“做点好吃的”的念头远远不够。你得写下一份能让后厨、采购、领班都照着手干的作业手册：请什么菜系的厨师、每天备多少斤食材、菜端上桌后怎么算好吃。这份手册里最不能含糊的三件事——掌勺人选、食材清单、试菜标准，恰好对应了 AI 产品 PRD 里最特殊的三章：模型选型、数据需求、评估标准。 传统产品的 PRD 只要写清界面长什么样、用户怎么操作就行，好比只写菜单和动线。但 AI 产品的效果取决于“看不见的厨房”：模型决定能力上限，数据决定能力下限，评估标准决定团队怎么判断“做完了”。这三章写不清楚，研发没法排期，测试没法验收，产品上线后好不好只能靠运气。 这篇文章就带你把这三大章节的写作要诀一次讲透：每一章写什么、怎么写才能让研发精确理解、常犯的错误有哪些。学完之后，你写出的 PRD 会像一份“连帮厨都不会误解”的餐厅作业手册。

岗位关联

对AI产品经理而言，模型、数据、评估三章节是PRD的核心竞争力所在，掌握其写作规范能大幅提升与算法、数据、测试团队的协作效率，让需求从“看着对”变成“可验收”。

目录
  1. 可视化演示
  2. 模型选型要求
  3. 模型能力规格
  4. 数据需求定义
  5. 数据质量合规
  6. 评估指标体系
  7. 验收方案设计
  8. 撰写表达规范
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示微服务网格拓扑结构与实时流量监控，当服务异常时自动告警并影响关联链路。

本节配有交互动效（进入视口后自动加载，约 3KB）。

微服务流量监控 所有服务运行正常 请求在各服务间流转 SLA 99.9%

模型选型要求

开餐厅首先要定菜系。你开湘菜馆，就得找会做剁椒鱼头的师傅；开日料店，就得找懂刺身的师傅。请错菜系的厨师，再好的手艺也使不上劲。AI 产品同理：你的业务任务是“把工单分到正确的部门”，还是“根据对话生成一段回复”？前者是分类问题，后者是生成问题，对应的模型家族完全不同。

定完任务类型，还要在“手艺”和“价钱”之间权衡。米其林主厨做的菜固然惊艳，但薪资、设备、食材要求水涨船高。模型界也是如此：参数规模越大、精度越高，训练成本、推理延迟、运维复杂度也成倍增长。

模型选型章节至少要回答四个问题。第一，任务类型匹配：明确分类、回归、排序、生成中的哪一类，初步圈定 CNN、Transformer、大语言模型等模型家族；第二，性能成本权衡：给出精度目标的同时估算全生命周期成本；第三，部署环境限制：说明模型跑在云端还是端侧，端侧对参数量有硬约束；第四，生态成熟度：考察社区活跃度、文档完整度、供应商支持，避免选一个“无人维护的模型”。

把这道成本算式写进 PRD，相当于在请厨师前先算清了工资和食材消耗，避免被“主厨光环”冲昏头脑——选型章节的价值，就是让每一分钱都花得明明白白。

Ctotal=Ctrain+Cinfer×N\displaystyle C_{total} = C_{train} + C_{infer} \times N
把“算总账”的公式写进 PRD，选型就不只是技术偏好，而是有成本依据的决策。
  1. 总成本 C_total模型从训练到上线运行的全生命周期成本，是选型的最终判断依据。
    Ctotal\displaystyle C_{total}
  2. 训练成本 C_train一次性的数据准备、算力租赁、调参实验费用，花完即止。
    Ctrain\displaystyle C_{train}
  3. 推理成本 C_infer每调用一次模型产生的算力开销，随调用量线性增长。
    Cinfer\displaystyle C_{infer}
  4. 预估调用次数 N根据业务量预测的模型总调用次数，把“单次便宜”换算成“总账”。
    N\displaystyle N

模型能力规格

确定请川菜师傅后，还得写一份岗位说明书：必须会做哪些菜、出菜速度不能超过多久、高峰期能同时照看几口锅。没有这份说明书，面试时聊得再投机，上岗第一天就可能翻车。

岗位说明书对应 PRD 里的“模型能力规格”章节。算法团队需要知道：模型收什么输入、吐什么输出、跑多快、扛多大流量，以及模型“掉链子”时产品怎么办。

这个章节通常包含四块内容。输入输出定义：写清请求字段、格式、取值范围及输出的数据结构，最好附一个具体样例；精度与延迟指标：量化写出准确率下限、单次响应延迟上限，例如“分类准确率≥92%，P95 延迟≤300ms”；并发规模预估：根据业务峰值估算 QPS，为部署资源提供依据；失败兜底策略：超时、异常、低置信度时如何降级——返回兜底话术还是转人工。

岗位说明书写得越具体，应聘者越能准确判断“我能不能干”。模型能力规格也是如此——它是算法团队评估排期、测试团队设计用例的共同基准，模糊一寸，返工一丈。

n=QPS×TlatencyK\displaystyle n = \frac{QPS \times T_{latency}}{K}
这个公式用来估算“需要几台服务器”，相当于算清晚市高峰期需要几位厨师同时开工。
  1. 实例数 n需要部署的模型服务实例数量，就是“需要几个厨师同时掌勺”。
    n\displaystyle n
  2. 峰值 QPS每秒最大请求数，对应餐厅最火爆晚市的翻台压力。
    QPS\displaystyle QPS
  3. 平均延迟 T_latency单次请求从进到出的平均耗时，相当于一道菜的平均出餐时间。
    Tlatency\displaystyle T_{latency}
  4. 单实例并发 K一个服务实例能同时处理的最大请求数，相当于一口锅能同时炒几份菜。
    K\displaystyle K

数据需求定义

厨师定好了，接下来是采购。晚市要做三百道菜，得备多少斤肉、多少种配菜，配比如何——这是“数据需求”章节能帮采购和供应链规划的前提。

模型靠数据“喂”出来。没有足够的食材，再好的厨师也做不出满汉全席；没有高质量、结构化的数据，再先进的模型也只是纸上谈兵。

数据需求章节要写清四件事。数据量级规模：给出样本总量及每个类别的数量目标，例如“意图分类每类至少 5000 条”；字段结构规范：用表格定义字段名、类型、是否必填、示例值，让数据团队知道要采集什么；采集来源渠道：明确数据来自业务日志、第三方采购还是人工采集；标注方案与预算：说明标注方式（内部、外包、众包）、质量校验流程和成本预算，让排期可预估。

一份写清量级、结构、来源、标注预算的“采购清单”，让数据团队不用反复追问“到底要什么”，也让产品上线后的效果有了可追溯的起点。

Ntrain:Nval:Ntest=8:1:1\displaystyle N_{train} : N_{val} : N_{test} = 8 : 1 : 1
数据不是一堆就够，还要科学地分成三份：一份练手、一份调参、一份最终考核，互不串场。
  1. 训练集 N_train模型学习的样本，占比最大，是“师傅反复练手”的菜。
    Ntrain\displaystyle N_{train}
  2. 验证集 N_val训练过程中调参用，防止模型“只会背菜单”。
    Nval\displaystyle N_{val}
  3. 测试集 N_test训练完成后做最终检验，必须与训练过程完全隔离。
    Ntest\displaystyle N_{test}
  4. 比例 81:1：业界常用的经验配比，数据量越大该比例越稳健。
    8:1:1\displaystyle 8 : 1 : 1

数据质量合规

食材不仅要够，还要新鲜、有检疫证明。自家后院种的菜自己吃没问题，但开门做生意就必须过食品安全检查——这是餐厅的生存底线。

AI 产品的数据同样有两条底线：质量底线和合规底线。质量不达标，模型学出来的是“变味的”；合规不过关，产品可能直接下架甚至吃官司。

数据质量合规章节要写清四块内容。质量合格标准：明确字段缺失率上限、标签准确率下限等硬指标，例如“字段缺失率≤3%，标签准确率≥97%”；隐私合规要求：说明数据是否涉及个人信息、是否获得用户授权、是否符合相关法规；脱敏与权限管控：规定敏感字段的脱敏方式及数据访问的分级授权；版本管理机制：约定数据集版本号规则，保证训练、评估、复现都能溯源到具体数据版本。

没有检疫证明的食材，后厨不敢用；没有质量与合规条款的数据，研发团队不敢接。这章节写清楚了，PRD 才有资格进入数据采集环节。

Rquality=NpassNtotal≥95%\displaystyle R_{quality} = \frac{N_{pass}}{N_{total}} \geq 95\%
合格率是数据交付的“总开关”，好比整批食材只有通过检疫才能进后厨。
  1. 合格率 R_quality数据整体质量的量化度量，是数据验收的总开关。
    Rquality\displaystyle R_{quality}
  2. 合格样本数 N_pass通过质检的样本总数，相当于检疫合格的食材斤数。
    Npass\displaystyle N_{pass}
  3. 样本总数 N_total交付的全部样本数量。
    Ntotal\displaystyle N_{total}
  4. 95% 阈值常见的最低质量门槛，具体数值可随业务调整，但必须写死。
    95%\displaystyle 95\%

评估指标体系

菜好不好吃，不能只信厨师自夸。餐厅会设计顾客打分表，也会盯翻台率——前者是口味本身，后者是生意好坏。AI 评估指标同样分两层：离线技术指标和在线业务指标。

离线指标在实验室里用测试集算出来，回答“模型能力够不够”；在线指标在真实流量中观测，回答“产品目标达没达到”。两者缺一不可。

评估指标体系章节要写三块。离线技术指标：根据任务类型选择合适指标——分类任务用准确率、精确率、召回率、F1，排序任务用 AUC、NDCG；在线业务指标：把模型效果翻译成业务语言，如点击率、转化率、留存率；指标权重设计：明确哪个是核心指标、哪个是参考指标，防止研发团队“捡了芝麻丢了西瓜”。

一张科学的“试菜评分表”，比厨师的心情更可靠。把 F1、点击率这些指标写成 PRD 里的白纸黑字，团队才不会在“到底什么叫做好”上各说各话。

F1=2×Precision×RecallPrecision+Recall\displaystyle F1 = \frac{2 \times Precision \times Recall}{Precision + Recall}
F1 是精确率和召回率的“和事佬”：两个都高，它才高；偏科严重，它立刻拉警报。
  1. 精确率 Precision预测为正例的样本中，真正预测对的占比。
    Precision=TPTP+FP\displaystyle Precision = \frac{TP}{TP + FP}
  2. 召回率 Recall真实正例中，被成功找出来的占比。
    Recall=TPTP+FN\displaystyle Recall = \frac{TP}{TP + FN}
  3. 调和平均F1 对精确率和召回率一视同仁，防止模型“偏科”。
    2×Precision×RecallPrecision+Recall\displaystyle \frac{2 \times Precision \times Recall}{Precision + Recall}
  4. F1 取值介于 0 到 1 之间，越接近 1 表示模型越均衡。
    F1∈[0,1]\displaystyle F1 \in [0, 1]

验收方案设计

餐厅开张前要办试菜会：请熟客盲测、和隔壁老店的招牌菜对比、先试营业一周再决定是否全量。这套流程就是“验收方案”。

模型训练完成不等于需求交付。PRD 必须在写作阶段就定义好“怎么算通过”，否则验收时产品经理和算法工程师各执一词，项目无限延期。

验收方案章节要写清四件事。测试集划分：明确测试集来源和划分方式，最好按时间切分，避免“偷看答案”式的数据泄漏；基线对比：指定对比对象（现有规则系统或旧模型），规定必须提升的幅度；分阶段验收：设计小流量灰度、扩大放量、全量的节奏，每阶段有明确的准入准出条件；回归测试机制：在数据或模型更新后重跑历史用例，防止“修好一个 bug 惹出三个新 bug”。

没有试菜标准的餐厅，开业当天才听到顾客说难吃；没有验收方案的 PRD，上线当天才知道效果不行。把验收写在需求里，等于把“好吃”提前翻译成了可测量的流程。

Δ=Mnew−MbaselineMbaseline≥δ\displaystyle \Delta = \frac{M_{new} - M_{baseline}}{M_{baseline}} \geq \delta
新模型不是“感觉更强”就行，要在同一张试卷上和旧方案比出明确的分差。
  1. 新模型指标 M_new待验收模型在测试集上的表现。
    Mnew\displaystyle M_{new}
  2. 基线指标 M_baseline现有方案在同一测试集上的表现，是“隔壁老店的招牌菜”。
    Mbaseline\displaystyle M_{baseline}
  3. 相对提升 Δ新模型相对基线的提升幅度，衡量“换厨师到底值不值”。
    Δ\displaystyle \Delta
  4. 阈值 δ验收通过的最低提升要求，例如 2%，由产品经理在 PRD 中拍板。
    δ\displaystyle \delta

撰写表达规范

作业手册里写“加盐少许”是帮厨的噩梦。“少许”是 3 克还是 30 克？AI 产品的 PRD 更怕这种模糊语言——“准确率高一点”和“加盐少许”一样让人无从下手。

前面六节讲的是“写什么”，这一节讲“怎么写”。同样的内容，表达方式不同，研发团队的返工率天差地别。

撰写表达要守住三条规范。量化可测表达：所有指标都给出具体数值、单位和测量方式，把“响应快”写成“P95 延迟≤300ms”；责任边界明确：在每一条需求旁标注责任方——模型组、数据组还是后端组，避免“三不管”地带；变更管理机制：约定 PRD 版本、模型版本、数据版本的变更记录规则，任何一方改动都要可追溯。

PRD 的本质是“翻译”——把产品经理脑中的模糊想法，翻译成算法、数据、测试各方都能无歧义执行的指令。四个要素齐了，一条需求才是真正“写完”了。

验收项={场景, 输入样本, 预期输出, 指标阈值}\displaystyle \text{验收项} = \{\text{场景},\ \text{输入样本},\ \text{预期输出},\ \text{指标阈值}\}
一条需求只有集齐这四要素，才算真正“写完”，才能交给研发动手。
  1. 场景验收发生在什么用户场景下，例如“用户在客服入口提交工单”。
    场景\displaystyle \text{场景}
  2. 输入样本一份具体的输入数据，让研发和测试对齐“喂什么”。
    输入样本\displaystyle \text{输入样本}
  3. 预期输出期望模型给出的结果形态，例如“返回工单分类标签及置信度”。
    预期输出\displaystyle \text{预期输出}
  4. 指标阈值该场景必须满足的量化标准，例如“分类准确率≥92%”。
    指标阈值\displaystyle \text{指标阈值}

AI 应用场景

智能客服工单分类 PRD

阶段：需求分析与模型选型

解决的问题：传统 PRD 只描述“工单要自动分类”的功能，不写模型选型、数据需求和评估标准，算法团队无法估算排期，数据团队不知道采集什么数据，项目反复延期。写出三章节后，各方各取所需，需求一次对齐。

具体案例：某电商平台的客服产品经理在 PRD 中写明：任务类型为文本多分类，模型家族初选 BERT 微调；训练数据 2 万条已标注工单，字段含 question、label、source；评估标准为分类准确率≥92%、P95 延迟≤300ms，并与人转人工基线做相对提升对比。研发据此两周内给出排期，测试按标准设计用例，项目按期上线。

电商搜索排序模型验收

阶段：评估与验收

解决的问题：排序模型效果难以在开发阶段判断，验收时产品与算法容易扯皮。在 PRD 评估章节写清离线与在线双层指标及灰度节奏，可避免“公说公有理”。

具体案例：搜索产品经理规定：新排序模型离线 AUC 相对基线提升≥2%，在线点击率提升≥1%，先在 10% 流量灰度两周，若业务指标无回退再全量放量。算法团队按指标迭代，产品团队按数据放行，双方目标一致。

内容安全审核数据合规评审

阶段：数据治理与合规

解决的问题：审核类 AI 产品涉及大量敏感数据，若 PRD 未写明合规约束，数据采集环节就可能触碰隐私红线。

具体案例：内容安全产品经理在数据章节写明：训练数据全部脱敏、用户授权文件齐备、敏感字段按等级仅限指定角色访问，并附数据集版本号规则。合规部门据此评审通过，项目才获准启动数据采集。

Python 演示

python52 行
# -*- coding: utf-8 -*-"""AI PRD 三章节自检器: 检查模型/数据/评估章节是否可验收"""import refrom math import ceil  def compute_metrics(y_true, y_pred):    tp = sum(1 for t, p in zip(y_true, y_pred) if t == 1 and p == 1)    fp = sum(1 for t, p in zip(y_true, y_pred) if t == 0 and p == 1)    fn = sum(1 for t, p in zip(y_true, y_pred) if t == 1 and p == 0)    precision = tp / (tp + fp) if tp + fp > 0 else 0.0    recall = tp / (tp + fn) if tp + fn > 0 else 0.0    f1 = 2 * precision * recall / (precision + recall) if precision + recall > 0 else 0.0    return {"precision": round(precision, 3), "recall": round(recall, 3), "f1": round(f1, 3)}  def check_prd(prd):    report = []    model = prd["model"]    data = prd["data"]    ev = prd["evaluation"]    if model.get("task") and model.get("family"):        report.append("OK 模型章节: 已写明任务类型与模型家族")    else:        report.append("NG 模型章节: 缺少任务类型或模型家族")    has_num = lambda v: bool(re.search(r"\d+(\.\d+)?%?", str(v)))    if has_num(ev.get("accuracy")) and has_num(ev.get("latency")):        report.append("OK 评估章节: 准确率与延迟已量化")    else:        report.append("NG 评估章节: 指标需给出具体数值阈值")    latency_ms = float(re.sub(r"[^0-9.]", "", str(ev.get("latency", "0"))))    if latency_ms > 500:        report.append("WARN 延迟阈值偏松, 建议控制在 500ms 内")    n = int(data.get("samples", 0))    train, val, test = int(n * 0.8), int(n * 0.1), int(n * 0.1)    report.append("INFO 数据划分: 训练/%d 验证/%d 测试/%d" % (train, val, test))    qps = float(ev.get("peak_qps", 0))    if qps > 0 and latency_ms > 0:        instances = int(ceil(qps * latency_ms / 1000.0 / 32))        report.append("INFO 部署估算: 峰值 %d QPS 约需 %d 个实例" % (int(qps), instances))    return report  if __name__ == "__main__":    demo_prd = {        "model": {"task": "工单意图分类", "family": "BERT 微调"},        "data": {"samples": 20000, "fields": "question,label", "annotator": "双人标注"},        "evaluation": {"accuracy": ">= 0.92", "latency": "<= 300ms", "peak_qps": 100},    }    for line in check_prd(demo_prd):        print(line)    print("评估指标:", compute_metrics([1, 0, 1, 1, 0, 1], [1, 0, 0, 1, 1, 1]))
目的：一键自检你的 PRD 草稿——判断模型、数据、评估三章节是否写全、指标是否量化，并顺手算出数据划分和部署实例数。
  1. def compute_metrics(y_true, y_pred):定义评估指标计算函数，对应正文的 F1 公式。
  2. tp = sum(1 for t, p in zip(y_true, y_pred) if t == 1 and p == 1)统计真正例 TP：真实为正且预测也对。
  3. f1 = 2 * precision * recall / (precision + recall) if precision + recall > 0 else 0.0计算 F1，并处理分母为零的边界情况。
  4. has_num = lambda v: bool(re.search(r"\d+(\.\d+)?%?", str(v)))用正则判断阈值描述里是否出现了具体数字。
  5. train, val, test = int(n * 0.8), int(n * 0.1), int(n * 0.1)按 8:1:1 划分数据量，输出给数据团队参考。
  6. instances = int(ceil(qps * latency_ms / 1000.0 / 32))用实例估算公式算出部署规模，超过 32 并发就要加机器。
  7. for line in check_prd(demo_prd):逐行输出自检报告，方便粘贴到 PRD 评审纪要中。

常见误区

误区“PRD 里写清楚功能就行，选什么模型算法团队自己会定。我写了反而显得外行，还可能限制他们的发挥。”

正解模型选型章节写的不是技术实现细节，而是业务约束：菜系（任务类型）、预算（成本上限）、厨房条件（部署环境）。把这些写清楚，算法团队才能在海量方案中快速收敛，避免选错方向后大返工。好比开餐厅不告诉厨师这是湘菜馆，厨师按粤菜备了一堆食材，最后全浪费。

为何常见：很多产品经理把“模型”当成纯技术话题，误以为写进 PRD 是越界，实则业务约束本身就是产品决策。

误区“数据需求嘛，告诉数据团队'给我 10 万条数据'就够了。他们干这行多年，自然知道怎么采。”

正解数据需求至少包含量级、字段结构、采集来源、标注方案、质量合规五个维度。只写数量，等于买菜只说“30 斤”，没说要哪个部位、什么新鲜度、有没有检疫证明。采购买回 30 斤冷冻肥肉，厨师也做不出你要的菜。

为何常见：因为“数量”是最容易想到的维度，而字段、质量、合规这些维度需要踩过坑才会意识到。

误区“我在评估章节列了 20 个指标：准确率、精确率、召回率、F1、AUC、点击率……全都写上肯定没错，显得我很专业。”

正解指标过多等于没有指标。研发团队面对 20 个指标，不知道优先优化哪个，指标之间还可能互相冲突。应该像试菜打分表一样，分清楚主菜和配菜：核心指标 1-2 个，参考指标若干，并写明权重或优先级。

为何常见：初学者容易把“全面”当成“专业”，却忽略了 PRD 的作用是让执行者做出取舍。

误区“现在写验收标准没意义，模型效果谁也说不好，等训练出来看看效果再定标准也不迟。”

正解验收标准必须在 PRD 阶段定好。因为它决定了测试集怎么划、基线选谁、资源投多少，这些都需要提前准备。餐厅不会等菜做出来才定“什么叫好吃”，那样开业当天只能听天由命。

为何常见：人对“未来的标准”天然有回避心理，觉得时机未到，实则标准先行才能倒逼过程可控。

误区“量化很简单，我写'准确率 95%'就是量化了，研发照做就行。”

正解孤立数字没有意义。要写清“在什么数据集上、用什么测试方式、和谁对比”。只说“95% 用户说好吃”，没说多少人试吃、问卷怎么发的、和谁家比的，这数字就无法采信。量化的关键是“可复现”，而不是“有个数”。

为何常见：因为写出一个具体数字会产生“我已经写清楚了”的错觉，但完整上下文才是可验收的关键。

面试题

Q1. AI产品的PRD相比传统PRD，必须额外写清楚下面哪一组章节？

单选题 · easy

  • A.模型、数据、评估章节← 正确答案
  • B.界面、交互、配色方案
  • C.推广、运营、活动预算
  • D.财务、人力、法务条款

答案：A。AI 产品的效果由模型、数据和评估共同决定，这三章节是 AI PRD 区别于传统 PRD 的核心。界面配色、运营预算、财务法务在传统 PRD 中也会涉及，并非“额外特有”，故选 A。

Q2. 模型选型章节中，“任务类型匹配”指的是哪一层含义？

单选题 · easy

  • A.选择与业务任务匹配的模型家族← 正确答案
  • B.选择与项目代号一致的模型
  • C.选择与服务器品牌一致的模型
  • D.选择与界面风格相符的模型

答案：A。开湘菜馆要请湘菜师傅，业务任务是分类还是生成，决定了选 CNN 还是大语言模型。项目代号、服务器品牌、界面风格都与模型能力无关，属于干扰项。

Q3. 精确率（Precision）的正确计算公式是哪一项？

单选题 · mid

  • A.TP 除以 TP 与 FP 之和← 正确答案
  • B.TP 除以 TP 与 FN 之和
  • C.TN 除以 TN 与 FP 之和
  • D.FP 除以 FP 与 TN 之和

答案：A。精确率回答“模型说是正例的，有几个真说对了”，分母是预测为正的总数 TP+FP。B 是召回率，C、D 均无对应标准指标，故 A 正确。

Q4. 召回率（Recall）衡量的是模型哪方面的能力？

单选题 · mid

  • A.预测为正例且正确所占比例
  • B.真实正例中被成功找出的比例← 正确答案
  • C.全部样本中预测正确的比例
  • D.负样本中被错误预测的比例

答案：B。召回率回答“真实的正例里，模型找回了几个”，分母是真实正例总数 TP+FN。A 是精确率，C 是准确率，D 是假正例率的描述，均不符合。

Q5. 训练集、验证集、测试集最常见的划分比例是？

单选题 · mid

  • A.训练八成验证一成测试一成← 正确答案
  • B.训练三成验证三成测试四成
  • C.训练五成验证三成测试两成
  • D.训练七成验证两成测试一成

答案：A。8:1:1 是业界常用的经验配比：训练集占比最大供模型学习，验证集用于调参，测试集完全隔离做最终考核。其他比例会让某一环节样本不足，故选 A。

Q6. 下列哪些属于在线业务评估指标？

多选题 · mid

  • A.点击率与转化率← 正确答案
  • B.用户留存率指标← 正确答案
  • C.离线准确率数值
  • D.F1 分数数值

答案：AB。在线业务指标在真实流量中观测，回答“产品目标达没达到”，点击率、转化率、留存率都属于此类。离线准确率和 F1 是在测试集上算出的离线技术指标，故排除 C、D。

Q7. 峰值 QPS 为 1000、单次平均延迟 0.2 秒、单实例并发上限 32，所需实例数约是？

单选题 · extreme

  • A.七个实例左右← 正确答案
  • B.三个实例左右
  • C.二十个实例左右
  • D.五十个实例左右

答案：A。代入实例估算公式 n = QPS × 延迟 / 单实例并发 = 1000 × 0.2 / 32 = 6.25，向上取整约 7 个实例。这相当于算清晚市高峰期需要几位厨师同时掌勺，故选 A。

Q8. 验收方案设计中，以下哪些做法是正确的？

多选题 · hard

  • A.单独划分独立测试集合← 正确答案
  • B.选择基线模型做对比← 正确答案
  • C.上线之后再补验收标准
  • D.先灰度小流量再全量← 正确答案

答案：ABD。验收方案要求测试集独立防数据泄漏、与基线对比量化提升、分阶段灰度降低风险，A、B、D 均正确。验收标准必须在 PRD 阶段定好，上线后补标准等于没标准，C 错误。

Q9. PRD 中写“准确率高一点、响应快一些”的主要问题是什么？

单选题 · easy

  • A.缺少量化标准导致无法验收← 正确答案
  • B.文字太长导致表格混乱
  • C.需求太细导致研发反感
  • D.指标太多导致难以实现

答案：A。“高一点”“快一些”没有给出数值、单位和测量方式，等于作业手册里的“加盐少许”，研发和测试无法据此判断是否达标。问题核心是不可验收，而非文字长或需求细，故选 A。

Q10. 数据合规章节通常需要覆盖哪些内容？

多选题 · mid

  • A.用户隐私授权与同意← 正确答案
  • B.数据脱敏与权限分级← 正确答案
  • C.数据版本变更记录← 正确答案
  • D.模型参数量大小

答案：ABC。数据合规章节关注数据的法律与治理维度：隐私授权、脱敏、权限分级、版本管理都属于此范畴。模型参数量属于模型能力规格章节的内容，与数据合规无关，故排除 D。