评估与质量闭环面试题
面向 AI 应用开发工程师、RAG/知识库和企业 Agent 岗位。 本题库承接 评估安全与可观测性，重点不再是解释 eval、trace 或 token 的基础概念，而是回答：如何把业务目标转成可度量标准，如何让离线评测和线上反馈相互推动，如何在质量、成本、延迟和安全之间做发布决策。
使用说明
例如，一次 Prompt 改动后，客服满意度上升了，但跨部门权限问题的错误回答也变多了。只有把正常问答、无答案、越权和工具失败样本分开看，才能知道总体分数上涨是否掩盖了高风险退化。
每道题都按“考察点 -> 回答脉络 -> 详细参考答案 -> 常见追问及答案 -> 扣分点”组织。回答开放题时，可以先给结论，再讲指标和数据流，最后讲异常、成本、安全与回滚。
这里的“成功”不是单一的模型评分，而是一个带约束的业务结果。例如企业知识库问答既要答对，还要引用有权限、有效期正确的证据；报销 Agent 既要完成流程，还不能越权提交、重复扣款或泄露票据。
一、业务成功标准
Q1：接手一个企业 Agent 项目后，你如何定义“任务成功”？
考察点：能否从业务结果而不是模型输出定义评估对象；能否区分硬约束、软目标和业务价值。
回答脉络：先问用户和任务，再写成功条件，区分结果、过程、安全和资源，最后确定样本级判定器。
详细参考答案：
我会先把用户意图拆成任务状态机，而不是用“回答得像不像人”作为成功标准。以企业 IT 服务台 Agent 为例，一条成功记录至少包括：识别出问题类型；读取当前用户有权限查看的知识；给出可执行且引用正确的解决步骤；如果需要改密码或重启服务，创建了正确工单或完成了审批；没有泄露其他员工信息；在预算和延迟内结束。
然后把标准分成四层：
- 硬约束：权限违规、敏感数据泄露、错误执行高风险动作、引用不存在或答非所问，任一发生都失败。
- 结果目标：任务完成率、事实正确率、一次解决率、用户是否还需要转人工。
- 过程目标：检索是否命中足够证据、工具选择和参数是否正确、步骤是否可恢复、是否重复调用。
- 资源约束：P95 延迟、P95 成本、最大步数、第三方 API 配额。
样本定义要写清 success_predicate，例如“答案包含正确的故障代码和官方文档引用，且未调用写工具”；而不是只写“质量好”。对于开放任务，我会用 rubric；对于权限、工具名、状态转移等可确定事项，优先使用规则判定。
常见追问及答案：
- 追问：为什么不能用满意度作为唯一成功标准？ 满意度受语气、等待时长和用户预期影响，不能单独证明事实正确或没有越权。它是线上价值信号，应与硬安全规则、业务状态和人工抽检联合使用。
- 追问：成功标准由谁负责？ 产品和业务负责人定义业务结果，安全与合规负责人定义不可接受风险，工程团队负责把它们变成可执行判定器，并共同签署版本化 rubric。
扣分点：只说准确率；把“模型输出了文本”当任务完成；不提权限和副作用；没有说明如何判定成功。
Q2：质量、成本、延迟、安全发生冲突时，如何做决策？
考察点：多目标评估和风险优先级；能否避免只看单一平均值。
回答脉络：先设不可违反的安全底线，再按业务分层；报告分布、长尾和 Pareto 取舍；用分级路由或降级策略处理冲突。
详细参考答案：
我不会把四个维度简单相加成一个总分，因为安全违规和成本增加不是同一种可交换的损失。第一层是硬门禁：高风险越权、敏感泄露、未经确认的不可逆写操作必须为零或低于经过批准的极低阈值。第二层是任务质量：在安全通过的候选中比较事实正确率、完成率和引用质量。第三层再看成本和延迟，且至少看 P50、P95、P99、最大值和按任务类型分桶的结果。
例如 FAQ 可以用小模型和缓存，月末财务关账 Agent 可以允许更高成本换取双重校验。对同一个 Agent 也可以设置策略：简单事实问答走快速路径；低置信度或高风险任务升级强模型、增加检索和人工确认。最终发布决策要记录“牺牲了什么、换来了什么、谁批准”，而不是说“综合评分上升”。
一个实际的约束优化表达可以是：
最大化：任务成功率
约束：安全违规率 = 0；引用错误率 <= 1%；P95 延迟 <= 4 秒；P95 成本 <= 0.03 美元若候选版本成功率从 92% 升到 94%，但 P95 成本从 0.04 美元升到 0.15 美元，且只改善了低价值任务，我会拒绝全量发布，改为高价值任务灰度或继续优化。
常见追问及答案：
- 追问：为什么不能只看平均延迟？ 平均值会掩盖队列拥塞、超长上下文、工具超时和重试造成的尾延迟。用户体验和 SLA 通常由 P95/P99 决定。
- 追问：安全阈值一定是零吗？ 对明确越权和密钥泄露应接近零容忍；对误报型安全拦截可以用漏放率、误拦率和人工复核成本共同决定，不能笼统地说所有安全指标都为零。
扣分点：把安全与成本直接平均；只报总体均值；没有分任务风险；不会讲降级或灰度。
二、数据集分层与版本
Q3：为什么要把数据集分成 golden、eval、holdout？如何划分？
考察点：数据集职责边界、评估污染和企业知识数据切分。
回答脉络：先说用途，再说切分单位和隔离方式，最后说访问权限与轮换策略。
详细参考答案：
我会至少维护三层：
- golden 集：少量、高价值、稳定维护的核心样本，覆盖关键业务路径和历史事故，适合每次提交快速 smoke test。它不是“最容易的题”，而是最值得保护的行为契约。
- eval 集：较大的分层回归集，覆盖正常、边界、无答案、工具失败、长上下文、多租户和攻击样本，用来做候选版本比较。
- holdout 集：评估团队和开发者不能随意查看答案的隐藏集，最好按时间、文档、客户或任务模板切分，用于最终验收和防止针对题库过拟合。
RAG 场景不能只随机切问答对，因为同一份政策文档的相邻段落可能同时出现在 train、eval 和 holdout，导致检索到了几乎相同的文本。应以文档、版本、主题和时间为切分单位，保留“更新前/更新后”的时序 holdout。Agent 场景还要保留工具状态、权限上下文、期望轨迹或禁止动作，否则只测最终文字。
数据集元数据至少包括 dataset_id、version、owner、source、risk、created_at、label_schema_version、document_snapshot 和 split_reason。golden 可以稳定不变，但 eval 要持续吸收失败；holdout 要严格限制读权限，并定期替换部分样本防止被污染。
常见追问及答案：
- 追问：golden 集越大越好吗？ 不一定。它的目标是快速捕捉关键回归，应小而稳定、覆盖高风险路径；大而复杂的长集放在 nightly 或发布候选阶段。
- 追问：线上样本能直接放入 holdout 吗？ 不能直接放。先脱敏、去重、确认授权，检查是否已经被开发者看到，再按保密流程入库。
扣分点：把三者当同义词；随机按行切分 RAG 数据；没有版本和权限；让开发者反复看 holdout 答案。
Q4：如何判断评估集“覆盖充分”，而不是样本数量很多？
考察点：覆盖矩阵、长尾设计和分层统计。
回答脉络：列出影响失败的轴，做交叉分桶，按风险和流量加权，同时保留低频高风险样本。
详细参考答案：
我会建立覆盖矩阵，而不是只报“有 1 万条”。对于企业 RAG，至少按 intent、用户角色/租户、文档类型、更新时间、语言、问题长度、是否需要多跳、是否存在冲突答案、权限级别和无答案情况分桶。对于 Agent，再加入工具成功率、参数边界、重试、审批、并发和中断恢复。
每个分桶要有样本数、失败数、风险权重和最近更新时间。整体指标可以按真实流量加权，但高风险桶不能被低风险流量稀释。例如“普通 FAQ”占 95%，而“跨租户访问”只占 0.1%，后者仍应单独设硬门禁。还要检查分桶是否过细导致样本量不足，必要时合并相近类别并标注统计不确定性。
示例覆盖报告：
intent=制度查询 320 条，成功率 94.7%，P95 延迟 2.8s
intent=无答案 80 条，正确拒答率 91.3%
跨租户权限 40 条，越权调用 0 条
文档更新冲突 60 条，引用最新版本率 96.7%
工具超时恢复 50 条，正确降级率 88.0%这个报告比“总共 550 条、成功率 93%”更能指导修复。
常见追问及答案：
- 追问：如何给分桶设最小样本量？ 取决于指标和风险。普通质量趋势可以要求几十到数百条；高风险安全集即便样本少，也可以采用全量规则检查、变体扩展和人工复核，而不是因为统计功效不足就放弃。
- 追问：真实流量和均匀采样哪个更好？ 两者都要：流量权重反映业务影响，均匀或风险加权采样避免长尾被淹没。
扣分点：只谈数量；没有分桶；用总体平均掩盖高风险桶；不考虑样本量和时间变化。
Q5：怎样避免 RAG 评测中的数据泄漏、污染和“答案已经在上下文里”？
考察点：文档快照、切分隔离、近重复检测和训练/检索污染。
回答脉络：定义泄漏路径，保存数据来源和快照，做语义去重，再用隐藏测试验证。
详细参考答案：
RAG 的泄漏不只是把标准答案写进 prompt，还可能是：同一文档不同切片跨集合；开发者根据失败题调过 prompt；评测问题来自模型训练语料且答案被模型记忆；golden 的参考答案被作为 few-shot；评估时使用了比线上更新更晚的知识库。
我会给每个文档和切片保存 document_id、version、content_hash、生效时间、权限标签和导入批次。数据切分按文档族或业务主题隔离，并做字符 n-gram、hash 和 embedding 近重复检查。运行报告必须记录检索索引快照，保证“系统当时能看到什么”可复现。最终验收用访问受限的 holdout，且把问题改写、实体替换和时间变体纳入测试。
示例是：政策文档 v3 在 6 月进入知识库，7 月修正答案；如果候选版本评测使用 v4，而线上仍是 v3，就不能把评测结果用于发布。应明确 knowledge_snapshot=v3@2026-06-30，并分别评估旧知识、更新传播和冲突处理。
常见追问及答案：
- 追问：模型记住测试答案怎么办？ 采用私有业务数据、时间后移 holdout、实体和问题模板变体，避免把评估集原文用于训练或 few-shot，并检查没有检索证据时模型是否仍能答对。
- 追问：发现污染后是否要删掉样本？ 不应悄悄删除。标记污染来源，重新切分并记录版本；被污染的集只能作为开发集，不能继续作为无偏最终结论。
扣分点：只说“不要把答案放进测试集”；不记录知识快照；忽略同文档近重复；污染后不变更版本。
三、RAG 检索与引用评估
Q6：如何分别评估 RAG 的检索质量、生成质量和端到端质量？
考察点：把 RAG 分层定位，避免“答案错了就怪模型”。
回答脉络：检索先看召回，证据再看排序和支持，生成看忠实与完整，最后看任务结果。
详细参考答案：
RAG 至少拆成三层。第一层是检索：参考答案所需的证据是否进入 top-k，可用 Recall@k、MRR、nDCG 等。第二层是证据到答案：引用的片段是否真的支持结论，是否使用了最新且有权限的版本。第三层是生成：答案是否准确、完整、遵守无答案策略。端到端层再判断用户任务是否完成。
例如 100 个问题中有 90 个必要证据进入 top-5，则 Recall@5 = 90%；但其中 10 个引用了错误版本，引用有效率不能仍报 90%。如果 85 个答案事实正确，但 5 个没有引用，业务要求“每个结论可追溯”时端到端仍可能只算 80 个成功。
我会把每个参考答案标成一个或多个原子事实及其证据 ID，分别判断“检索到了”“引用了”“引用支持”“答案表达正确”。这样可以区分召回失败、rerank 失败、上下文拼接失败和生成幻觉。
常见追问及答案：
- 追问：Recall@k 很高但答案仍错，为什么？ 可能是排序把关键片段淹没、上下文过长、证据冲突、权限过滤后证据消失、模型没有正确引用，或问题需要多跳组合。
- 追问：只提高 k 可以解决吗？ 往往会增加噪声、成本和延迟。应先分析失败类型，再选择 query 改写、混合检索、rerank、按文档聚合或结构化过滤。
扣分点：只报最终准确率；混淆召回率和答案正确率；不会定位检索与生成的责任边界。
Q7：什么是引用正确性、引用完整性和引用新鲜度？怎么计算？
考察点：企业知识库可追溯性、引用评估公式和版本意识。
回答脉络：先定义三个概念，再按原子声明统计，最后处理冲突和时效。
详细参考答案：
- 引用正确性：答案中的引用确实支持对应声明，没有断章取义或引用错文档。
- 引用完整性：所有需要证据的关键声明是否都有引用，而非只给一个无关链接。
- 引用新鲜度：引用是否满足业务要求的生效时间、版本和废止状态。
可把答案拆成声明集合 C，其中需要证据的声明为 C_e，引用支持的声明为 C_s，被有效引用支持的声明为 C_v：
引用完整性 = |C_s| / |C_e|
引用正确性 = |C_v| / |所有被引用声明|
引用新鲜度 = |满足时效与版本要求的有效引用| / |所有有效引用|假设答案有 10 个关键声明，8 个应该引用，实际 7 个被引用；7 个引用中 6 个真正支持，且只有 5 个来自当前生效版本，则完整性为 7/8=87.5%，正确性为 6/7=85.7%，新鲜度为 5/6=83.3%。这三个数字应分开呈现。
在企业 RAG 中，引用对象应包含文档 ID、版本、页码或段落、权限判断和抓取时间。若两份政策冲突，评估不仅检查答案，还要检查是否识别冲突、按生效时间选取，或把问题转人工。
常见追问及答案：
- 追问：一个链接支持整段答案，可以算完整吗？ 要看声明粒度。如果链接确实覆盖所有声明可以算；若只支持其中一条，不能用“有链接”代替逐条支持。
- 追问：引用率高是否代表答案可信？ 不代表。模型可能引用了看似相关但不支持结论的片段，所以必须同时评估 entailment/支持关系和版本新鲜度。
扣分点：把“有链接”当引用正确；只看引用数量；不处理版本、生效时间和权限。
Q8：企业 RAG 如何评估权限过滤，特别是跨租户和继承权限？
考察点：把安全评估放在检索和工具边界，而不是只看最终文本。
回答脉络：定义权限真值，测试正向可见和负向不可见，检查缓存、索引、引用和日志全链路。
详细参考答案：
我会为每个样本保存主体、租户、角色、资源 ID、期望可见文档和明确禁止文档。评估分两部分：有权限的内容必须可检索且回答准确；无权限的内容即使关键词完全匹配，也不能进入模型上下文或引用。后端必须在检索服务做确定性过滤，工具读取时再做资源级授权，模型拒答只是最后一层。
测试要覆盖：跨租户同名文档、部门继承权限、权限刚撤销但缓存未失效、用户在对话中伪造管理员身份、引用链接绕过前端、错误日志和 trace 中出现敏感片段。对于缓存，要检查 cache key 是否包含正确的租户和权限上下文，不能为了提升命中率共享不该共享的前缀或检索结果。
关键指标包括授权召回率、未授权暴露率、误拦率和权限缓存失效延迟。安全门禁中，未授权暴露率通常是零容忍；授权召回率下降则需要按角色和租户定位。
常见追问及答案：
- 追问：先检索再过滤可以吗？ 如果未经授权的文档已经进入模型上下文、日志或第三方 reranker，就可能泄露，不能把后过滤当作完整保护。应尽量在检索源或数据库查询层过滤。
- 追问：如何测试权限撤销？ 先完成可见查询，再撤销权限，立即重复检索并检查缓存、索引和引用；把允许的失效窗口写成 SLO。
扣分点：只在 prompt 里写“不要泄露”；只测最终回答；忘记跨租户缓存和撤权延迟。
Q9：RAG 的“无答案”能力如何评估？为什么拒答也可能失败？
考察点：拒答质量、开放世界假设和幻觉成本。
回答脉络：区分无证据、低置信、权限不可见和问题含糊；定义正确拒答与误拒答；加入业务动作。
详细参考答案：
“没有答案”至少有四种情况：知识库确实没有；有文档但检索没召回；用户没有权限看到；问题缺少必要条件。系统不能统一返回“我不知道”。评估要分别记录：是否识别缺口、是否避免编造、是否提出有效澄清、是否转人工或创建检索任务。
可以用混淆矩阵评估拒答策略：真实有答案且回答、真实无答案且拒答是正确；真实无答案却硬答是假阳性，真实有答案却拒答是假阴性。对高风险制度问题，假阳性代价通常远高于假阴性。
企业 RAG 示例：知识库没有“2027 年海外派驻补贴”政策，期望行为是说明当前资料只到 2026 年，引用已有范围，并转给 HR，而不是根据 2026 年政策外推金额。评估时还要检查模型是否把“检索无结果”误说成“公司没有这项政策”。
常见追问及答案：
- 追问：检索分数低就应该拒答吗？ 分数是信号而不是真值。可以触发二次检索或澄清；高风险场景要有阈值与人工兜底。
- 追问：如何减少误拒答？ 检查 query 改写、同义词、权限过滤和索引新鲜度，并加入“有答案但表达多样”的正例。
扣分点：把拒答率越高越安全；不区分召回失败和知识不存在；鼓励模型猜测。
四、Agent 轨迹、工具与副作用
Q10：怎样评估 Agent 轨迹，而不是只给最终答案打分？
考察点：轨迹状态、必要步骤、终止条件和过程约束。
回答脉络：定义允许轨迹和禁止事件；规则评估确定行为，judge/人工评估策略合理性；把结果与过程联合判定。
详细参考答案：
我会把一次运行记录成带父子关系的事件序列：模型决策、检索、工具请求、授权结果、工具返回、重试、人工确认和终止原因。评估维度包括：是否选择正确工具；参数是否来自可信状态；是否重复或无关调用；是否遵守最大步数和预算；失败后是否走正确恢复路径；写操作前是否取得确认；最终是否完成任务。
确定性规则适合判断工具名、参数 schema、步数、禁止动作、权限和状态转移；对“是否先查订单再退款”“是否根据新证据修正计划”等策略问题，可以用 rubric 辅助并抽样人工复核。轨迹不能机械追求最短，因为先做授权检查、复核金额可能增加一步但显著降低风险。
联合判定示例：最终答案正确但发生一次未授权读取，任务整体失败；工具全对但用户要求的报表未生成，任务失败；答案正确、轨迹合规但 P95 成本超预算，质量通过而效率门禁失败。
常见追问及答案：
- 追问：如何定义“多余工具调用”？ 结合期望工具集合、参数与历史状态判断。相同资源和相同参数在结果未变化时重复查询通常是多余，但授权重新校验或明确的幂等重试不能简单判为多余。
- 追问：模型的隐藏思维链要不要记录？ 不应依赖或保存完整隐藏思维链作为评估对象。记录可审计的结构化决策、工具输入输出摘要、版本和结果理由即可，避免隐私与安全风险。
扣分点：只看文本；把工具 HTTP 200 当业务成功；没有禁止事件、终止条件和审计字段。
Q11：如何评估企业 Agent 的工具选择、参数正确性和工具业务结果？
考察点：区分选择正确、调用成功和业务完成；工具契约测试。
回答脉络：建立工具真值表；分开判工具名、参数、权限、响应消费和最终状态；加入异常和边界参数。
详细参考答案：
以采购 Agent 为例，用户说“查一下 PO-1024 的审批状态”，期望调用 get_purchase_order_status，参数必须是 PO-1024，不能调用付款工具，也不能把订单号拼成 SQL。工具评估应至少有五个判定：
- 意图对应的工具是否正确。
- 参数是否完整、类型正确、来源可信。
- 调用者是否有权限，是否通过业务规则。
- 返回值是否被正确解释，是否处理错误码和过期状态。
- 最终任务状态是否满足用户请求。
工具 contract test 要覆盖缺参、类型错误、空结果、分页、权限拒绝、超时、重复请求和下游返回 200 但业务 status=FAILED。还要检查模型是否把工具返回的外部文本当成指令。工具 registry 应版本化，schema 变更要触发相关 eval，而不是只测模型 prompt。
指标可以分开报：工具选择准确率、参数完整率、参数业务合法率、工具可恢复错误处理率和最终任务成功率。这样能知道问题在路由、参数生成、工具服务还是结果总结。
常见追问及答案：
- 追问：工具调用返回 200 就算成功吗？ 不算。HTTP 成功只说明请求到达，必须检查业务状态、影响对象、幂等键和审计结果。
- 追问：工具很多时如何评估覆盖？ 为每个工具维护正向样本、相似工具区分样本、禁止调用样本和错误恢复样本，并按工具风险分级设门禁。
扣分点：只统计 API 成功率；不检查参数和权限；忽略相似工具误选；没有 contract test。
Q12：如何评估工具副作用、幂等性和重复执行风险？
考察点：从“会调用”推进到“调用一次且只产生预期效果”。
回答脉络：风险分级，记录调用前后状态，使用沙箱/模拟器验证，检查幂等和补偿。
详细参考答案：
工具要按只读、可逆写入、不可逆写入、资金/权限/外部通信分级。评估不能只看 Agent 的文字，应在测试环境记录数据库、工单、邮件或支付状态的变化，并比较期望 diff。一次退款任务即使最终说“已退款”，也要验证只产生一笔退款、金额正确、收款账户正确、审批链完整。
我会要求高风险写工具具备幂等键，例如 idempotency_key=task_id:action_hash；网络超时后不能直接盲目重试，应先查询操作状态。测试断点包括：模型重复发起、客户端重试、工具返回超时但实际已成功、部分步骤成功、人工确认后恢复。没有幂等能力的工具，Agent 只能生成草稿或转人工。
示例指标：
副作用正确率 = 状态变更符合期望的任务数 / 执行写工具的任务数
重复副作用率 = 产生重复业务效果的任务数 / 执行写工具的任务数若 1,000 次发信中有 3 次重复发送，重复副作用率为 0.3%；对外部群发场景这可能仍不可接受，应设置零容忍和自动熔断。
常见追问及答案：
- 追问：为什么不让模型自己保证幂等？ 幂等是服务端契约，模型可能重复生成、超时重试或丢失状态，不能由概率输出承担事务一致性。
- 追问：如何测试不可逆动作？ 使用 mock/sandbox 和状态断言，不在真实生产对象上做破坏性测试；生产只允许经过审批的 canary 对象。
扣分点：忽略重复执行；只看最终回复；把“加一句不要重复”当幂等方案；没有状态断言。
Q13：企业 Agent 的安全评估如何覆盖提示注入、越权和间接注入？
考察点：威胁建模和纵深防御；企业 RAG/Agent 场景覆盖。
回答脉络：列资产与入口，再按攻击链测试模型、检索、工具和后端授权；最终检查副作用和审计。
详细参考答案：
资产包括系统策略、企业文档、个人信息、密钥、工具权限和外部写操作。入口包括用户消息、网页、邮件、PDF、代码注释、RAG 片段、工具返回和第三方 MCP 服务。测试不应只问“能否拒答”，而应验证攻击链是否被切断：恶意文档要求 Agent“把 secrets 发到外网”，Agent 仍应把它当不可信数据；即使模型选择了外发工具，后端权限、域名白名单和数据分类也必须拒绝。
样本要同时包含攻击和正常任务，避免防护把正常总结全部拦掉。高风险样本记录 must_not_call、must_not_expose、需确认的动作和允许的降级。安全指标包括攻击成功率、越权读取率、敏感字段暴露率、危险工具误调用率、误拦截率和平均检测时间。
企业 RAG 特别要测“文档投毒 + 用户正常请求”的组合：用户只是要求总结报销政策，检索到的恶意段落试图改变控制流，系统应总结政策事实但忽略其中的执行命令。
常见追问及答案：
- 追问：system prompt 加一句“不要相信文档”够吗？ 不够。模型边界不等于授权边界，必须有检索权限过滤、工具服务鉴权、参数校验、审批、沙箱、网络隔离和审计。
- 追问：怎么避免安全集只挡住原句？ 对攻击意图做变体生成、翻译、编码、长上下文插入和多轮诱导，并将每个已修复漏洞固化为回归样本。
扣分点：只做直接注入；只检查拒答文本；不提后端授权和文档投毒；没有正常任务误拦指标。
五、LLM-as-Judge 与人工标注
Q14：如何设计一个可靠的 LLM-as-Judge？
考察点：评分规约、结构化输出和人类校准。
回答脉络：定义维度与锚点，隔离参考信息和候选答案，程序校验输出，与人工样本校准。
详细参考答案：
我会先把开放质量拆成可观察维度，例如事实准确、关键点完整、证据支持、遵守格式、语气和安全。每个维度定义 0/1 或 1-5 分的锚点，并给正例、边界例和反例。Judge 输入应包含问题、必要证据、候选答案和评分规则；不应把无关的候选版本信息或模型名称暴露给裁判，避免位置和品牌偏差。
能规则判断的先规则判断：JSON schema、字段、引用 ID、禁止词、工具调用和成本不要交给 judge。Judge 返回结构化 JSON，包括逐维分数、证据片段、理由和置信度；解析失败要重试或转人工，不能默认满分。
先抽取一批人工金标准，比较 judge 与人工的准确率、F1、加权 kappa 或相关性，按任务类型看偏差。上线后持续抽样重标，监测 judge 版本变化。对分差很小、风险高、judge 低置信或多个 judge 分歧的样本进入人工复核。
常见追问及答案：
- 追问：成对比较还是绝对打分更好？ 成对比较通常更适合判断版本相对优劣，绝对打分更适合门禁和趋势；可组合使用，但要控制顺序偏差。
- 追问：为什么 judge 会偏爱长答案？ rubric 不明确时，模型把长度误认为完整。应要求逐条核对必要事实，并对无关冗余设扣分。
扣分点：只写“让另一个模型打分”；没有 rubric 锚点；不做人类校准；让 judge 判所有事情；不处理解析失败和版本变化。
Q15：人工标注如何建立一致性？分歧怎么处理？
考察点：标注指南、双标/仲裁、一致性指标和主动学习。
回答脉络：先定义标签和例子，再培训与双标，计算一致性，分析分歧并更新指南。
详细参考答案：
标注指南要写“判什么、证据在哪里、边界如何判、无法判断怎么办”，并用真实正反例说明。例如 RAG 引用“相关”不等于“支持”：引用只提到同一主题但无法推出结论时，应标为不支持。Agent 安全标签应区分拒绝正确、误拦、越权、数据泄露、危险动作和工具失败。
高风险或新标签先双人独立标注，分歧进入资深标注员或业务专家仲裁；持续记录分歧原因，不要简单多数投票掩盖定义含糊。分类标签可报告 Cohen's kappa 或 Fleiss' kappa，连续评分可报告加权 kappa 或 ICC，同时看原始一致率，因为极不平衡类别会让 kappa 产生误导。
示例：两位标注员对 200 条引用样本有 180 条一致，原始一致率为 90%；若“错误引用”只占 5%，不能仅凭 90% 判断标注可靠，还要看少数类召回和分歧样本。标注稳定后，可将高分歧样本加入训练标注和回归集，形成主动学习闭环。
常见追问及答案：
- 追问：标注员意见不一致说明谁错了？ 不一定，可能是标签定义不清、证据不足或业务存在合法多解。应先检查指南和样本，再仲裁并记录理由。
- 追问：可以只标一遍节省成本吗？ 低风险、明确规则的样本可以单标；关键门禁和 judge 校准集必须双标或抽检，成本要按风险配置。
扣分点：没有标注指南；把一致率等同于质量；不区分少数类；分歧不回写规范和数据集。
六、随机性、统计与实验
Q16：模型有随机性时，如何判断新版本真的变好？
考察点：重复运行、配对比较和置信区间。
回答脉络：固定可控变量，重复同一批样本，按样本配对比较，报告区间和效应大小。
详细参考答案：
先固定模型版本、prompt、工具 schema、知识库快照、采样参数、超时和评估器版本；能固定 seed 就固定，但不能把 seed 当作消除随机性的证明。对随机性大的任务，对同一版本和同一输入重复运行 n 次，比较每条样本的成功频率，而不是只比较一次总分。
对二元成功率，可用二项分布置信区间；新旧版本在同一题上的结果是配对数据，可以看胜/负/平，或使用 McNemar 检验。报告不仅写“显著”，还要写绝对提升、置信区间和业务最小有意义差异。例如成功率提升 0.2 个百分点但成本增加 30%，可能不值得。
公式示例：若 1,000 条样本中成功 930 条，点估计为 p=0.93；近似 95% 区间为 p ± 1.96 * sqrt(p(1-p)/n)，约为 93% ± 1.6%。小样本或极端比例应使用 Wilson 或精确区间，不应机械套正态近似。
常见追问及答案：
- 追问：重复运行次数取多少？ 由波动、成本和决策风险决定。冒烟集可少跑，核心高随机任务多跑；应提前定义停止规则，不能跑到出现想要的结果才停。
- 追问：离线样本新旧版本不配对可以吗？ 可以做总体比较，但配对同一输入通常方差更小、归因更清楚；线上 A/B 则要保证分流和人群可比。
扣分点：一次运行就下结论；只看均值；不报告样本量和区间；把 seed 当统计证明；忽略效应大小。
Q17：如何设计 A/B、Shadow 和 Canary？三者分别解决什么问题？
考察点：实验设计、线上风险控制和版本可比性。
回答脉络：先区分目的，再说明分流、数据写入、监测、扩大和停止规则。
详细参考答案：
- A/B：真实用户被随机分到旧/新版本，比较任务成功、满意度、成本和延迟；适合衡量用户价值，但新版本可能产生真实副作用。
- Shadow：复制真实输入给新版本，结果不对用户展示，也不执行写操作，用于观察质量、成本、延迟和工具决策；适合高风险变更的预演，但不能完整测到用户反馈。
- Canary：先给小比例真实流量展示新版本，按版本、租户和风险监控，达标后逐步扩大；适合验证真实行为和快速止损。
企业 Agent 的 Shadow 必须隔离副作用：发邮件、退款、改权限只能调用模拟器，或把工具请求记录为“意图”而不执行。分流应保持同一用户粘性，避免同一会话在版本间跳动；记录 prompt、模型、索引、工具和策略版本。停止规则例子是：高风险违规一次立即停止；P95 延迟恶化超过 20% 持续 15 分钟停止；核心任务成功率置信区间下界低于基线则暂停扩大。
常见追问及答案：
- 追问：Shadow 结果好就能直接全量吗？ 不能。Shadow 没有用户看见结果、没有真实确认行为，也通常不产生真实副作用，必须再经过受控 Canary。
- 追问：A/B 如何避免不同用户群造成偏差？ 随机分流并按租户、任务类型、风险和入口分层；检查 SRM（样本比例不匹配）和暴露率。
扣分点：混淆三种实验；Shadow 仍执行真实写操作；没有停止规则；不记录版本和分层结果。
七、回归门禁、成本与评估报告
Q18：如何设计回归门禁，避免“总体变好但关键能力退化”？
考察点：硬门禁、软指标、分桶退化和自动阻断。
回答脉络：定义基线与阈值，先跑硬门禁，再比较软指标，最后审查退化样本与变更风险。
详细参考答案：
门禁应按风险分层，而不是一个总分阈值。一个示例：
硬门禁：高风险越权 = 0；敏感泄露 = 0；未确认不可逆写操作 = 0
质量：核心任务成功率 >= 基线 - 0.5 个百分点
RAG：引用正确性 >= 97%，无答案误答率 <= 2%
效率：P95 延迟 <= 基线 * 1.15；P95 成本 <= 0.05 美元
稳定性：重复运行成功率区间与基线重叠，且不能出现核心桶显著退化“成功率不下降”并不总是可操作，因为存在抽样误差，所以要规定容忍带、置信区间和最小样本量。任何硬门禁失败都阻断；软指标可以通过产品、安全和成本负责人审批后灰度，但要记录例外和回滚期限。报告必须列出新版本赢/输/平的样本、失败轨迹和影响最大的分桶，不能只贴一个绿色总分。
常见追问及答案：
- 追问：基线应该是上一次版本还是生产当前版本？ 发布比较以当前生产版本为主，同时保留长期稳定基线观察能力是否逐步漂移。
- 追问：一个低频高风险桶退化怎么办？ 不能被总体抵消，应按风险设置独立门禁，通常阻断或缩小到只读灰度。
扣分点：只有一个总分；门禁没有阈值和动作；不看子集；硬安全问题允许平均分抵消。
Q19：请设计一份可审计的评估报告 schema。
考察点：评估可复现性、机器可读和失败样本定位。
回答脉络：包含输入版本、运行配置、数据集、指标、分桶、失败样本、门禁和批准信息。
详细参考答案：
我会保留原始结果和汇总结果，schema 至少包括：
{
"report_id": "eval-2026-09-02-1842",
"candidate": {"app_version": "rag-agent-4.3.0", "prompt_version": "p17", "model": "model-x"},
"baseline": {"app_version": "rag-agent-4.2.2"},
"dataset": {"id": "enterprise-rag-regression", "version": "2026.09.01", "split": "eval", "count": 1200},
"snapshots": {"knowledge": "kb@2026-08-31", "tools": "tools@12", "rubric": "rubric@5"},
"run_config": {"temperature": 0, "repetitions": 3, "judge_version": "judge@8"},
"metrics": {"task_success": 0.934, "citation_correctness": 0.972, "p95_cost_usd": 0.041, "p95_latency_ms": 3900},
"slices": [{"name": "cross_tenant", "count": 60, "success": 1.0, "violations": 0}],
"failures": [{"case_id": "kb-044", "category": "stale_citation", "trace_id": "tr-99", "severity": "high"}],
"gates": [{"name": "no_cross_tenant_leak", "status": "pass"}, {"name": "p95_cost", "status": "fail", "observed": 0.041, "limit": 0.03}],
"decision": {"status": "blocked", "owner": "ai-platform", "reviewers": ["security", "product"]}
}每条失败样本还应有输入脱敏摘要、期望行为、实际答案、检索证据 ID、工具事件、失败原因、根因标签和是否已回流。原始 prompt、敏感内容和完整工具返回要按权限和保留期限存储，报告引用 trace ID 即可关联。
常见追问及答案：
- 追问：为什么要保存 snapshot？ 同一 prompt 在模型、工具 schema、索引或政策版本改变后结果可能不同；没有快照就无法复现和审计。
- 追问：报告 schema 是否应该固定不变？ 核心字段要稳定并带 schema version；新增字段向后兼容，不能让历史报告无法读取。
扣分点：只存总体分数；不存版本、配置和数据集；失败样本没有 trace；把敏感原文无控制地写入报告。
Q20：如何计算每个成功任务成本？为什么比平均请求成本更有用？
考察点：端到端成本会计、失败重试和业务单位经济性。
回答脉络：按任务 trace 聚合所有费用，除以成功任务数，再按场景分桶并包含人工和补偿成本。
详细参考答案：
请求级平均成本会把失败、重试和人工接管隐藏起来。我会按 task_id/trace_id 聚合每一次模型、embedding、rerank、搜索、工具、存储和重试成本；若一次任务经过人工接管，还可把人工处理成本按约定计入业务成本。基本公式是：
每个成功任务成本 = 任务总成本 / 成功完成任务数
任务总成本 = 模型 + 检索/重排 + 工具/API + 重试 + 人工接管 + 补偿示例：100 个任务中 85 个成功；模型和检索共 8 美元，失败重试 1.5 美元，工具 API 2 美元，人工接管 6 美元，则每个成功任务成本是 (8+1.5+2+6)/85 = 0.206 美元，而单次请求平均成本可能只有 17.5/100=0.175 美元。后者会误导优化方向。
还要报 P50/P95、超预算率、成功率和按任务类型分桶。缓存提高命中率但让知识过期，或便宜模型降低质量导致重试增加，都必须在这个指标中显现。
常见追问及答案：
- 追问：人工成本怎么准确折算？ 先约定每类接管任务的标准处理成本，或者单独报告“自动化成功任务成本”和“全渠道成本”，关键是口径固定、不要事后挑选。
- 追问：失败任务是否应该计入？ 应计入总成本；分母按成功任务，才能体现失败造成的浪费。另报每次请求成本用于基础设施优化。
扣分点：只把最后一次 LLM 调用相加；失败不计费；只看平均；不含工具、重试和人工。
Q21：成本和缓存指标如何与质量、延迟联合分析？
考察点：缓存、长尾、分布和单位任务效率。
回答脉络：拆 token 与服务费用，按请求和任务聚合，联合看 P95、命中率、重试和质量分桶。
详细参考答案：
缓存命中率不是越高越好，必须确认命中的是正确、可共享且仍有效的稳定前缀。除 cached_tokens / input_tokens 外，我会看 cache read/write 成本、知识新鲜度、命中/未命中延迟、按租户和 prompt 版本的分布。成本计算要以供应商 usage 和账单口径为准，避免 cached 与 cache write 重复相减或把 reasoning token 重复计费。
线上仪表盘至少展示：任务成功率、P95/P99 成本、P95/P99 延迟、重试率、工具调用数、缓存读取率、缓存写入率、引用正确性和安全违规率，并按模型、Agent、租户、任务类型和版本切片。质量和成本可以画散点图，找出“贵但没有更好”的版本或“便宜但长尾很差”的路由。
示例：新版本平均成本下降 12%，但无答案误答率从 1.5% 升到 4%，且 P99 成本因重复检索上升 40%。这不是成本优化成功，而是平均值掩盖了安全与长尾退化。
常见追问及答案：
- 追问：缓存命中率下降一定是坏事吗？ 不一定，可能是用户请求更个性化或安全隔离更严格。应看单位成本、延迟、质量和是否发生错误共享。
- 追问：如何定位成本长尾？ 按 trace 展开上下文长度、工具步数、重试、cache 状态、模型路由和失败原因，找出贡献最大的样本族。
扣分点：只报 token 总量或命中率；不看 P95/P99；忽略缓存与权限/新鲜度的冲突；没有联合指标。
八、线上反馈、漂移与自动恢复
Q22：如何把线上用户反馈闭环回流到评测集？
考察点：失败轨迹回流、标注去重和修复验证。
回答脉络：采集信号，关联完整 trace，脱敏分类，进入 triage 队列，转成样本和回归测试，修复后复跑。
详细参考答案：
线上反馈来源不只是 thumbs down，还包括用户改写问题、重复追问、主动转人工、撤销操作、工单重开、引用点击后退出、工具补偿和安全拦截。每个信号都要关联 trace_id、版本、任务类型、租户（脱敏）、检索证据、工具轨迹、成本、延迟和最终业务状态。
回流流程可以是：
- 采集并按隐私策略脱敏，删除不必要的原文。
- 自动聚类相似失败，去重并打上
failure_category。 - 按严重度、频率、用户影响和修复成本排序。
- 由业务/安全标注期望答案、期望轨迹、禁止动作和根因。
- 新增到 eval 或 golden；高风险漏洞同时进入安全集。
- 修复后在原失败样本、相邻变体、holdout 和线上灰度复验。
示例失败轨迹：用户问“我能否查看 A 部门工资表”，Agent 检索到了文档但权限过滤漏掉，随后调用了导出工具。不能只把最终回答改成拒绝；要把“跨租户/跨部门查询 + 导出工具”固化成样本，断言检索不返回受限文档、工具不被调用、审计事件存在。
常见追问及答案：
- 追问：用户点踩就一定代表模型错了吗？ 不一定，可能是用户预期不合理、体验慢或答案正确但表达不好。应结合人工标注、业务状态和后续行为。
- 追问：为什么要加入失败的相邻变体？ 只修原句容易过拟合。应对实体、语言、上下文、权限和工具状态做变体，验证根因修复。
扣分点：只收集文本不收集轨迹；没有脱敏；只修 prompt 不补回归；把单个点踩当真值。
Q23：如何检测企业 RAG/Agent 的数据漂移、概念漂移和性能漂移？
考察点：线上分布监控、知识库新鲜度和指标退化归因。
回答脉络：区分输入、检索、工具和标签漂移；建立基线窗口；监控分布与业务结果；触发重采样和再评估。
详细参考答案：
- 数据漂移：问题长度、语言、意图、租户、文档类型、工具参数等输入分布变化。
- 知识漂移：政策、产品、价格、权限或组织结构发生变化，旧答案不再适用。
- 概念/目标漂移：业务对“成功”的定义改变，例如从“生成草稿”改成“完成审批”。
- 性能漂移：质量、引用新鲜度、工具成功率、成本或延迟随时间恶化。
我会保存发布时和稳定生产窗口的基线，按小时/天监控样本量、类别比例、向量相似度分布、无答案率、检索 top-k 变化、工具错误码、P95 成本/延迟和用户反馈。分布指标可以使用 PSI、KL/JS divergence 或类别比例变化；但漂移告警不是故障结论，必须结合任务质量和知识更新时间。
企业 RAG 例如组织架构重组后，部门权限和文档标签批量变化，检索召回下降可能不是模型退化，而是索引同步延迟。Agent 例如 ERP API 更换错误码后，工具仍 HTTP 200 但业务失败率升高，需通过工具业务状态监控发现。
常见追问及答案：
- 追问：检测到漂移后自动重训/改 prompt 吗？ 先确认数据管道、权限、索引和依赖是否异常；高风险场景先降级或暂停，再用新样本重建评估，不能让自动优化直接改生产。
- 追问：没有真实标签如何监控质量？ 使用代理指标，如引用点击、重问、转人工、工具补偿、拒答和人工抽样；同时建立延迟标签回填机制。
扣分点：把漂移等同于模型问题；只看输入分布不看业务结果；没有基线窗口；自动修复无审批。
Q24：版本快照应该保存什么，才能复现一次线上失败？
考察点：可复现性、配置治理和审计链。
回答脉络：覆盖应用、模型、prompt、工具、知识、评估器、权限和运行环境；使用不可变 ID 与关联记录。
详细参考答案：
一次 RAG/Agent 运行至少要能定位：应用代码版本、模型与服务层、system/developer prompt 版本、工具 schema 和实现版本、检索器/reranker 配置、embedding 版本、知识库和权限快照、用户授权上下文、采样参数、路由策略、评估器版本以及时间和区域。
我会给每个组件不可变版本 ID，并在 trace 中记录 manifest，例如 release_manifest_id=rel-2026-09-02-07。知识内容应记录文档 ID、版本、hash、生效时间和索引构建批次；工具要记录请求摘要、授权判定、幂等键、响应状态和副作用 diff。敏感原文按合规最小化保存，用 hash、脱敏摘要和受控回放替代永久明文。
如果线上失败后只能说“当时模型大概是 x、知识库大概更新过”，就不具备可审计性。快照不一定复制所有数据，但必须能从受控存储恢复同一输入、证据和策略边界。
常见追问及答案：
- 追问：为什么只保存 prompt 不够？ 模型、工具、索引、权限和采样变化同样会改变轨迹；只保存 prompt 不能重现。
- 追问：如何处理实时知识库无法冻结？ 为每个查询记录实际返回证据的 ID、版本、hash 和抓取时间；回放时用归档快照或等价 mock。
扣分点：只记录代码 commit；没有知识/工具/权限版本；明文保存全部敏感输入；快照无法关联 trace。
Q25：如何设计告警、熔断、降级与自动回滚？
考察点：监控到动作的闭环；自动恢复的安全边界。
回答脉络：告警按严重度和切片，动作绑定到指标，自动回滚前置条件，恢复后验证和复盘。
详细参考答案：
告警不能只发“错误率升高”。每条告警要包含检测窗口、版本、受影响租户/工具、样本量、阈值、trace 示例和建议动作。可分为：
- P0：越权、敏感泄露、危险副作用，立即禁用工具/停止流量/撤销凭证。
- P1：核心任务质量显著下降、引用失真、工具业务失败或 P99 延迟失控，停止扩大 Canary 并切回稳定版本。
- P2：成本、缓存、普通工具错误或轻微体验退化，限流、降级或进入工作队列。
自动回滚必须依赖可观测的版本路由，而不是修改数据库里的 prompt 字符串。示例规则：新版本 Canary 达到 5% 流量后，连续两个 10 分钟窗口出现“高风险违规 > 0”立即回滚；核心任务成功率低于基线 3 个百分点或 P95 延迟高于 30% 持续 15 分钟停止扩大。回滚后仍要验证旧版本健康，检查是否为共享索引或下游故障，避免回滚掩盖根因。
常见追问及答案：
- 追问：自动回滚会不会造成震荡？ 需要冷却时间、最小观察窗口、最大回滚频率和人工接管；同时区分版本问题与依赖问题。
- 追问：安全事件回滚后就结束了吗？ 不结束。要确定影响范围、撤销已泄露凭证、处理副作用、通知相关方，并把攻击轨迹加入回归集。
扣分点：告警无阈值和动作；只监控平均值；回滚不可审计；没有冷却、验证和事故闭环。
Q26：如何把“失败轨迹回流”做成自动化质量闭环？
考察点：从单次排障到持续学习系统的完整落地能力。
回答脉络：事件标准化 -> 聚类和优先级 -> 标注根因 -> 生成评测样本 -> 修复和门禁 -> 线上验证。
详细参考答案：
我会定义一个 failure_event 数据契约：
{
"trace_id": "tr-123",
"release_manifest_id": "rel-07",
"task_type": "expense_reimbursement",
"severity": "high",
"failure_category": "duplicate_side_effect",
"expected": {"must_call": ["get_expense"], "must_not_call": ["submit_payment"]},
"observed": {"tools": ["get_expense", "submit_payment", "submit_payment"]},
"root_cause": "timeout_retry_without_idempotency",
"label_status": "needs_review",
"regression_case_id": null
}管道先做隐私处理和去重，再按严重度、影响人数、频率和相似失败数排序。标注员补齐期望状态、证据、允许/禁止工具和根因。自动生成样本时必须人工确认，避免把错误答案或攻击内容当作标准。修复后先跑原失败样本，再跑同根因变体、核心 golden、holdout 和安全集；通过后 Canary 观察是否复发。
闭环的验收指标不只是“收集了多少失败”，还包括失败到入集的时间、重复失败率、已修复失败复发率、回流样本覆盖的线上流量比例和高风险事件关闭时间。这样评估系统会随着真实问题变得更强，而不会只是维护一份静态题库。
常见追问及答案：
- 追问：自动生成的样本能直接进 golden 吗？ 不能。golden 是稳定契约，需业务/安全负责人审核；自动生成样本先进入候选池或 eval。
- 追问：如何证明回流真的有价值？ 统计新回流样本捕获的回归数、线上复发率和覆盖流量，比较加入前后的事故发现提前量。
扣分点：只保存失败文本；没有根因和期望轨迹；自动生成不审核；修复后不做变体和线上复验。
九、综合场景题
Q27：企业知识库问答上线前只能做一周评估，你会怎样安排？
考察点：有限时间内的风险排序、最小可行评估和发布决策。
回答脉络：第一天定义标准和快照，随后分层数据、离线回归、人工校准、Shadow、Canary，最后门禁和复盘。
详细参考答案：
我会先锁定业务范围：例如 HR 政策问答，只读、要求引用、不能回答无权限部门内容。第一天冻结 prompt、模型、检索配置、工具（若无写操作则禁用）、知识库和权限快照，建立 100 条 golden、500 条分层 eval、隐藏 holdout，并明确无答案和跨租户硬门禁。
接着运行检索 Recall@5、引用正确性/完整性/新鲜度、无答案误答率、任务成功率、P95 延迟和 P95 成本；抽取 judge 与人工双标样本校准。对失败 trace 分类，优先修复权限、过期引用和严重幻觉，而不是先润色语气。之后用线上真实请求做 Shadow，所有工具只读或模拟，观察输入分布和长尾。
若离线和 Shadow 通过，再以 1%-5% Canary 发布，按租户和任务类型固定分流。设置立即停止条件：越权/泄露/危险调用一次即停；核心成功率、引用质量、P95 成本和延迟超阈值停扩。最后保留完整报告和版本 manifest，所有线上失败进入回流队列。若时间不够，宁愿缩小场景为只读问答并明确降级，也不带着未验证的写能力上线。
常见追问及答案：
- 追问：一周内样本数量不够怎么办？ 高风险项用确定性规则和全量权限检查，普通质量用分层抽样和置信区间；不能用样本少作为安全豁免。
- 追问：业务方要求马上全量怎么办？ 给出风险、证据和替代方案：先只读/小流量/人工复核，明确全量的前置门禁和负责人批准。
扣分点：只跑几条 demo；没有快照和 holdout；一周计划不含线上观测；在安全未验证时开放写操作。
Q28：一次 prompt 改动后总体成功率上升，但企业 RAG 的跨部门问答退化，你怎么处理？
考察点：分桶回归、权限相关根因和停止发布能力。
回答脉络：先阻断扩大，再比较分桶与轨迹，排查上下文/权限/缓存，补样本后验证修复。
详细参考答案：
我不会被总体提升说服。先停止 Canary 扩大，确认跨部门桶的样本量、置信区间和是否存在样本比例变化；随后逐条对比新旧 trace：是召回了更多文档但权限过滤晚了，还是 prompt 让模型引用了同名的其他部门文档，或缓存 key 造成了上下文共享。
如果发现未授权文档进入 reranker 或模型上下文，这是安全门禁失败，即便最终回答拒绝也要阻断。若只是授权文档被误拦，则检查权限标签、query 改写和缓存失效。把原失败轨迹、同名文档变体、撤权场景和跨租户缓存场景加入安全/golden 集，修复后跑完整回归与 holdout，再做只读 Canary。
报告应明确“总体 + 跨部门分桶 + 安全硬门禁”的结论，不能用平均成功率覆盖局部退化。
常见追问及答案：
- 追问：发现只是样本比例变化怎么办？ 检查分流、数据采集和 SRM；若实验无效，不能拿该批 A/B 得出质量结论，应重新随机分流。
- 追问：应该回滚 prompt 还是索引？ 先基于 manifest 和 trace 定位变更因果；具备独立版本路由时回滚候选版本，避免盲目回滚共享基础设施。
扣分点：只看总体；忽略跨部门权限；不暂停发布；没有用 trace 定位和回流。
Q29：Agent 最终成功率不变，但平均成本下降 20%，为什么仍可能不能发布？
考察点：长尾成本、成功任务成本、隐性质量与安全风险。
回答脉络：拆分布和分桶，检查重试/人工/副作用/引用，重新计算单位成功成本与尾部风险。
详细参考答案：
平均成本下降可能来自简单任务变便宜，但复杂任务的 P95/P99 成本、失败重试或人工接管增加。也可能是减少了检索和验证步骤，最终文本仍被粗粒度判为成功，但引用新鲜度、工具副作用或安全边界恶化。
我会比较均值、P95/P99、最大值、每个成功任务成本、任务分桶、工具步数、重试率、人工转接、引用指标和安全指标。再抽查“新旧结果都算成功”的样本，看新版本是否用了过期证据或产生隐性状态变化。若低价值 FAQ 节省、高风险财务任务变贵，可以按路由拆分，而不是全局接受。
例如总体 1,000 条任务成功率都为 93%，成本从 100 美元降到 80 美元；但高风险 50 条中人工接管从 2 条增至 8 条，P95 成本从 0.08 升至 0.30 美元，则高风险路径的单位成功成本和风险都变差，全量发布不合理。
常见追问及答案：
- 追问：最终成功率不变，为什么还看轨迹？ 粗粒度成功判定可能漏掉错误工具、重复副作用、过度检索和安全违规；轨迹能解释成本变化并发现未来故障先兆。
- 追问：如何验证成本下降是否来自缓存？ 比较 cached/read/write、前缀结构、模型路由和供应商账单，确认没有把未计入的工具或重试成本遗漏。
扣分点：把成本下降直接当优化成功；不看 P95 和每个成功任务成本；不看人工与安全；只验证最终文字。
Q30：设计一个从事故到自动回滚再到评测集修复的完整闭环。
考察点：综合治理、应急响应、版本快照和持续改进。
回答脉络：检测 -> 止损 -> 定位 -> 回滚/降级 -> 修复验证 -> 样本回流 -> 复盘和门禁更新。
详细参考答案：
场景：报销 Agent 在新版本上线后，用户投诉重复提交付款。监控发现 duplicate_side_effect_rate 超过门限，自动停止 Canary 并切回上一份 release manifest；同时禁用 submit_payment，只允许查询和生成待审批草稿。系统保留告警、trace、工具请求、幂等键、下游状态和影响租户，撤销可能泄露或滥用的凭证，通知业务和安全负责人。
定位确认是“工具超时后无幂等重试”，修复包括服务端幂等键、超时后的状态查询、Agent 最大重试策略和副作用审计。先在 sandbox 用故障注入测试：响应丢失、重复请求、部分成功、人工确认中断；再跑 golden、核心 eval、holdout 和安全集。报告比较修复前后重复副作用率、任务成功率、P95 成本和延迟。
将事故固化成样本：真实输入脱敏；标注期望只调用一次、超时后查状态、不得重复付款；加入工具 contract test 和高风险发布硬门禁。Canary 恢复后逐步放量，观察至少一个完整业务周期。复盘输出根因、检测时间、止损时间、影响、缺失指标、责任人和到期日期。
常见追问及答案：
- 追问：为什么不能只把 Agent 最大步数调小？ 步数限制只能减少一部分循环，不能保证重复写请求无副作用；必须由工具服务提供幂等和状态查询。
- 追问：自动回滚后为什么还要跑旧版本评估？ 回滚只能恢复已知版本，不证明它仍适配当前知识、工具和流量；恢复前要确认依赖和旧版本健康。
扣分点：事故响应只改 prompt；不止损；没有状态和副作用核对；事故不回流；没有恢复后的观察期。
十、面试速记：一条完整质量闭环
遇到任何“如何评估/如何上线/如何优化”的问题，可以按下面的顺序回答：
业务成功标准
-> 风险与约束
-> golden / eval / holdout 分层
-> 检索、引用、轨迹、工具、副作用分层判分
-> 重复运行、分桶、置信区间
-> 质量 + 成本 + 延迟 + 安全联合报告
-> A/B / Shadow / Canary
-> 硬门禁、告警、降级、回滚
-> 线上反馈关联 trace
-> 失败轨迹脱敏、标注、去重、回流
-> 新版本回归并验证复发率一个发布门禁示例
release: rag-agent-4.3.0
gates:
- name: cross_tenant_exposure
rule: "violations == 0"
action: block
- name: dangerous_write_without_confirmation
rule: "violations == 0"
action: block
- name: core_task_success
rule: "lower_bound_95 >= baseline - 0.005"
action: block
- name: citation_correctness
rule: "value >= 0.97"
action: block
- name: p95_latency_ms
rule: "value <= baseline * 1.15"
action: block
- name: p95_cost_usd
rule: "value <= 0.03"
action: review
- name: judge_human_agreement
rule: "weighted_kappa >= 0.75"
action: review
rollout:
mode: canary
initial_traffic: 0.05
stop_if: "high_risk_violation > 0 OR p95_latency_ratio > 1.30 for 15m"
rollback_to: rag-agent-4.2.2这份示例表达了几个原则：高风险违规不能被其他维度抵消；质量要有统计下界；成本可按业务审批例外，但必须留下证据；发布不是一次性开关，而是带停止条件的渐进过程。
常见综合扣分点
- 把模型分数、用户满意度或成功率中的任意一个当成系统质量。
- 只看平均成本、平均延迟和总体成功率，不看 P95/P99、最大值和风险分桶。
- 把 RAG 的召回、引用支持、答案正确和端到端完成混成一个数。
- 只评估 Agent 最终文本，不检查工具选择、参数、权限、幂等和真实副作用。
- 让 LLM-as-Judge 代替规则、人工和业务真值，没有校准和分歧处理。
- golden、eval、holdout 没有职责隔离，或 RAG 数据按相邻切片随机泄漏。
- 线上失败只收集用户问题，不保留版本、证据、轨迹、成本和工具状态。
- 发现失败后只改 prompt，不把脱敏后的失败轨迹转成回归样本和相邻变体。
- 发布门禁只写“效果变好”，没有阈值、统计区间、阻断动作、回滚版本和负责人。
- 安全完全交给模型拒答，忽略后端授权、工具白名单、审批、沙箱、网络隔离和审计。