什么是 AI 测试？和传统软件测试核心差异在哪？
👔 Raina面试官： 咱们先聊基础的——你觉得 AI 测试和传统软件测试，最核心的差异是什么？别背教科书。
🙋 候选人：
- 我总结就一句话：传统测试验的是确定性行为，AI 测试验的是概率性输出下的质量边界。
- 传统 CRUD 系统，同样输入几乎必然同样输出，Pass/Fail 很清晰。AI 产品（尤其 LLM 应用）同一 Prompt 多次调用结果可能不同，你测的不是对不对一个值，而是相关性、事实性、安全性、格式合规等一组维度。
- 测试方法也跟着变：除了功能用例，还要建 Eval 集、做采样回归、引入 LLM-as-Judge 或人工抽检，接受没有 100% 通过但要有可度量的质量基线。
👔 Raina面试官： 那是不是意味着 AI 产品没法做严格的自动化测试了？
🙋 候选人：
- 不是没法做，是自动化要分层。工程层（接口、鉴权、流式、工具调用链路）该自动化照样自动化；模型输出层用 Golden Set + 自动评分 + 阈值门禁，而不是逐字断言。
- 探索性测试、对抗测试、Bad Case 回放这些在 AI 产品里权重反而更高。我的做法是：确定性部分 CI 卡死，概率性部分 nightly Eval 看趋势，线上 Bad Case 回流评测集。
AI 测试里确定性和概率性怎么平衡？
👔 Raina面试官： AI 产品既有确定性的工程逻辑，又有概率性的模型输出。测试里你怎么平衡这两块？
🙋 候选人：
- 我的原则是：能确定的绝不交给概率，必须概率的用统计兜底。
- 工程链路——鉴权、路由、流式协议、工具参数校验、错误码——按传统方式写自动化，100% 可重复。模型输出层接受波动，用 Eval 集 + 多次采样 + 置信区间看稳定性，而不是跑一次定生死。
- 两边要用不同门禁：PR 合并卡工程测试和轻量 Eval；发版前跑完整 Golden Set；上线后用监控和 Bad Case 回流补长尾。
👔 Raina面试官： 如果工程层全绿，但模型输出质量掉了，你会 blocking 发布吗？
🙋 候选人：
- 会，模型质量是产品体验的核心，不是附加项。我会设关键指标的 release gate，比如 P0 安全 case 必须 100% 通过、核心场景事实准确率不能低于基线 2 个点。
- 实操上把 case 分级：P0 blocking、P1 需 review、P2 只记趋势。这样既不因一次随机波动卡死发布，也不会让明显退化溜上线。
你怎么理解 AI 产品的质量？
👔 Raina面试官： 传统 CRUD 的质量好定义——功能对、性能够、没 Bug。AI 产品的质量你怎么理解？
🙋 候选人：
- 我会拆成任务完成度 + 输出可信度 + 体验与安全三个维度，而不是单一答对了吗。
- 任务完成度：用户问题真正解决了吗？Agent 场景还要看工具链是否走通。可信度：有没有幻觉、事实是否准确、引用是否可追溯。体验与安全：延迟可接受吗、拒答策略对吗、有没有泄露敏感信息。
- 和传统系统比，AI 产品质量是多维向量，不同产品权重不同——客服重准确和语气，代码助手重可执行性，搜索问答重引用和时效。
👔 Raina面试官： 这些维度能量化吗？还是只能靠感觉？
🙋 候选人：
- 能量化，但要分场景建 rubric。比如 RAG 产品看 Answer Correctness、Faithfulness、Citation Accuracy；对话产品看 Resolution Rate、人工介入率。
- 我会给每个维度定指标、采样方法和阈值，季度回顾权重是否合理。感觉只用于探索阶段，上线后必须可度量。
AI 测试工程师和传统测试工程师能力差异？
👔 Raina面试官： 招 AI 测试工程师，你觉得和传统测试比，能力模型有什么不一样？
🙋 候选人：
- 传统测试强在业务建模、用例设计、自动化框架；AI 测试在此基础上还要懂Prompt、Eval、数据飞轮和概率思维。
- 要能设计 Golden Dataset 和评分 rubric，会读模型评测报告，能区分是 Prompt 问题还是工程问题。代码能力要求也更高——要会写脚本调 API、跑 batch eval、对接 CI。
- 软技能上更要和算法、产品高频协作，因为质量标准不是纯黑盒 spec，很多要一起定义什么叫够好。
👔 Raina面试官： 不会算法的测试能做好 AI 测试吗？
🙋 候选人：
- 能，不必会训练模型，但要懂模型行为边界。知道 temperature 影响什么、上下文长度限制、常见失败模式（幻觉、拒答、格式崩），比会调参更重要。
- 我的团队分工是：测试负责 Eval 体系、质量门禁、Bad Case 分析；算法负责模型迭代。测试用数据说话推动修复，不需要自己写 loss function。
非确定性输出下，怎么定义 Pass / Fail？
👔 Raina面试官： LLM 输出每次可能不一样，这种情况下你怎么定义 Pass 和 Fail？标准怎么定？
🙋 候选人：
- 核心思路是：从精确匹配转向多维评分 + 阈值，不同场景 Pass 标准不一样。
- 结构化输出（JSON、表格）可以测 schema 合规 + 关键字段语义；开放问答看事实准确、完整度、有无幻觉；Agent 场景还要看工具是否调对、任务是否完成。每类定义 3～5 个可量化指标，比如事实准确率 ≥90%、格式合法率 100%、有害内容拦截率 100%。
- 单次调用 Pass/Fail 意义不大，我会看 Eval 集上的通过率、Win Rate 或平均分，以及和上一版模型的 diff——整体掉超过 2 个点就 blocking。
👔 Raina面试官： 如果模型回答意思对但措辞每次不同，算 Pass 吗？
🙋 候选人：
- 算，语义等价比字面一致重要。这种用 embedding 相似度、LLM-as-Judge 或人工 rubric 评是否回答了核心问题，而不是 string equals。
- 但要设红线：关键数字、日期、法条引用不能错；安全拒答必须稳定触发。我的习惯是把 case 分级——P0 硬断言（安全、格式、关键事实），P1 语义评分，P2 体验类指标只做趋势监控。
AI 测试左移、右移怎么落地？
👔 Raina面试官： AI 测试里左移、右移分别指什么？你在项目里怎么落地的？
🙋 候选人：
- 左移是把质量验证前置到 Prompt/模型选型阶段；右移是线上真实流量和 Bad Case 驱动持续改进。
- 左移：Prompt 变更走 PR review + Eval 回归；选型阶段就用同一套 benchmark 比模型；RAG 知识库更新前先跑检索质量抽检。右移：线上埋点看 Resolution Rate、用户点踩、人工接管率；Bad Case 自动进 triage 队列回流 Eval 集。
- 两边闭环：左移的 Eval 集来自右移的真实失败；右移的问题反哺左移的用例补充。
👔 Raina面试官： 小团队没精力做完整右移体系，最小可行怎么做？
🙋 候选人：
- 最小闭环：用户反馈入口 + 每周 Bad Case 评审 + 手动补进 Eval 集。哪怕先用表格管理 case，也比没有强。
- 左移侧至少做到：Prompt 改动必须跑固定 50 条核心 case 才能合并。这样已经能挡住大部分退化。
探索性测试在 AI 产品里还适用吗？
👔 Raina面试官： AI 输出不确定，探索性测试还有用吗？你会怎么开展？
🙋 候选人：
- 不但有用，而且在 AI 产品里权重比传统软件更高，因为边界 case 很难事先写全。
- 我会按攻击面探索：Prompt 注入、角色越狱、超长输入、歧义指令、多轮上下文污染、工具链组合爆炸。每次探索有 charter（本次测什么）、时间盒（90 分钟）、记录 seed prompt 和发现。
- 探索发现的好 case 必须沉淀进 Eval 集，否则测完就丢。我习惯用 session-based 管理，一次探索产出 5～10 条可回归 case。
👔 Raina面试官： 探索性测试和 Eval 自动化是什么关系？
🙋 候选人：
- 探索是发现未知，Eval 是固化已知。探索负责找新 failure mode；确认有价值的发现后写成 rubric case 进自动化。
- 比例上我会留 20% 测试时间做探索，尤其在 major 发版前。纯靠 scripted case 覆盖不了 LLM 的开放域风险。
LLM 应用回归测试怎么做？
👔 Raina面试官： 模型一升级就要全量重跑吗？LLM 应用的回归测试你怎么设计？
🙋 候选人：
- 不需要每次都全量，但要分层回归：冒烟 → 核心集 → 全量 Eval。
- 冒烟（PR 级）：50～100 条 P0 case，10 分钟内跑完，卡明显退化。核心集（发版级）：500～2000 条覆盖主场景。全量 Eval（大版本/换模型）：含边界、对抗、长尾，可能 nightly 或 weekly 跑。
- 模型升级、Prompt 大改、RAG 索引重建——这三类必须至少跑核心集；小 bugfix 可能冒烟就够。
👔 Raina面试官： 回归结果波动大怎么办？今天 88% 明天 92%，怎么判断有没有退化？
🙋 候选人：
- 用固定 seed + 多次采样看分布，而不是单次对比。对关键 case 可以 temperature=0 或固定 seed 提高可重复性。
- 设 stat gate：新版本平均分低于基线 1 个标准差才告警。同时人工 spot check Top 10 失败 case，排除 Eval 本身有问题。
怎么区分模型、Prompt、工程问题？
👔 Raina面试官： 测试发现问题后，你怎么判断是模型问题、Prompt 问题还是工程问题？
🙋 候选人：
- 我有一套分层排查顺序：工程 → Prompt → 模型，避免一上来就换模型。
- 工程问题特征：接口 500、工具没调到、上下文截断、检索结果为空——看 log 和 trace 能定位。Prompt 问题：换 wording 或加 few-shot 后同一模型明显好转，often 是指令不清或约束不够。模型问题：Prompt 和检索都 OK，但事实性、推理、格式稳定崩，换更强模型或微调才解。
- 实操上会准备对照实验：固定输入，分别换 Prompt / 换模型 / 换检索参数，看哪一刀见效。
👔 Raina面试官： 三方互相甩锅时你怎么推动解决？
🙋 候选人：
- 用可复现的 minimal case + trace 证据说话，而不是感觉模型变笨了。
- 把 case、期望、实际输出、各层中间结果（检索文档、工具返回）打包成 ticket，会上只讨论这个 case 的根因分类，效率最高。
AI 测试金字塔长什么样？
👔 Raina面试官： 经典测试金字塔是单元、集成、E2E。AI 产品的测试金字塔你怎么画？
🙋 候选人：
- 底层还是工程单元/集成测试（API、工具、检索链路）；中间是 Eval 自动化（Golden Set + 自动评分）；顶层是探索性测试 + 线上监控。
- 和经典金字塔不同：中间 Eval 层很厚，因为 LLM 输出是核心风险面；纯 UI E2E 反而变薄，很多逻辑在 API/Agent 层测更高效。
- 有些团队还会加对抗/红队层作为侧边栏，专门测安全和越狱，不一定按频率跑但必须有。
👔 Raina面试官： Eval 层很厚，会不会导致维护成本爆炸？
🙋 候选人：
- 会，所以要控制 Eval 集规模和质量，不是越大越好。核心集精而准，长尾 case 按优先级增量添加。
- 自动化评分 + 定期人工 audit 淘汰过时 case。我的目标是核心集 500 条以内可维护，每条 case 有明确 owner 和失效原因标签。
上线前 AI 产品必须覆盖哪些测试类型？
👔 Raina面试官： AI 产品上线前，你觉得哪些测试类型是必做的？有没有一张 checklist？
🙋 候选人：
- 我会按工程、功能、安全、性能、Eval 回归五类来卡，缺一类都不让上。
- 工程：API/流式/工具链路集成测试。功能：核心场景 Golden Set + 格式合规。安全：Prompt 注入、越狱、有害输出、数据泄露。性能：首 Token 延迟、并发、超时降级。Eval：和基线模型/Prompt 对比，P0 case 不能退化。
- RAG 产品额外加检索质量；Agent 额外加工具选择和多步执行。checklist 要分 P0 blocking 和 P1 可延期，别一刀切。
👔 Raina面试官： 时间紧只能选三类，你优先保哪三个？
🙋 候选人：
- P0 永远是安全 + 核心功能 Eval + 工程链路。安全出事是红线；核心 Eval 代表产品价值；工程链路挂了用户体验全崩。
- 性能和部分边界 case 可以用灰度 + 监控补，但前三类不能在没测的情况下全量发布。
小团队 AI 测试 MVP 策略怎么定？
👔 Raina面试官： 小团队就俩人，AI 测试不可能全做。你的 MVP 策略是什么？
🙋 候选人：
- 核心是用最小成本守住最大风险面，别追求大而全的 Eval 平台。
- 第一周：建 30～50 条 P0 Golden Case（核心场景 + 安全红线），Prompt 改动手动跑一遍。第二周：写脚本 batch 调 API，CI 里跑冒烟。第三周：用户反馈表格 + 每周补 5 条 Bad Case。
- 先管别出大事和别悄悄退化，再迭代自动化评分和 dashboard。很多团队死在第一天就想建完美 Eval 体系。
👔 Raina面试官： 没有专职测试，开发自己测够吗？
🙋 候选人：
- 短期可以，但要把 Eval 集和门禁当代码资产维护，PR 必须跑冒烟，不能只靠我本地试过了。
- 等产品稳定后还是建议有人专职 quality，否则 Eval 集会烂尾，技术债全堆到线上。