功能测试 LLM 应用测哪些维度？

👔 Raina面试官： 功能测试一个 LLM 应用，你会从哪些维度设计用例？

🙋 候选人：

• 我常用准、全、稳、遵、安五维：准确（事实对不对）、完整（漏没漏要点）、稳定（格式和结构）、遵循（指令和约束）、安全（拒答和合规）。
• 不同产品权重不同：问答重准确和引用；写作助手重遵循和风格；代码生成重可执行性和格式。每个维度拆 5～10 条代表 case，比堆几百条重复题有用。
• 还会加对抗维：歧义输入、诱导性提问、多轮误导，这些往往比 happy path 更早暴雷。

👔 Raina面试官： 维度多了测不完，怎么取舍？

🙋 候选人：

• 按用户旅程 × 风险等级排优先级。先 cover Top 3 用户场景的全链路，再补边界。
• 和业务、产品一起定什么算不可接受失败，把测试资源投在真正的 deal breaker 上。

怎么测模型的指令遵循能力？

👔 Raina面试官： Instruction Following 怎么测？你会设计什么样的 case？

🙋 候选人：

• 关键是把指令拆成可验证的原子约束，而不是看整体感觉对不对。
• 常见约束类型：长度（不超过 100 字）、格式（只输出 JSON）、语言（用英文答）、结构（先结论后理由）、禁止项（不要提到竞品）。每条 case 对应 1～3 个可自动检查的 constraint。
• 用 constraint checker 或 LLM-as-Judge 按 rubric 打分。我会混合简单硬约束（格式、字数）和复杂软约束（语气、角色）两类 case。

👔 Raina面试官： 模型大部分遵循但偶尔违反，算 Pass 吗？

🙋 候选人：

• 看约束级别。硬约束（安全、格式、法律合规）必须接近 100%；软约束可以设 90% 通过率 + 失败 case 人工 review。
• 和 PM 对齐哪些指令是 contractual（必须遵守），哪些是 nice-to-have，测试标准才不会扯皮。

多轮对话和单轮测试关注点有何不同？

👔 Raina面试官： 多轮对话测试和单轮问答，测试设计上的差异在哪？

🙋 候选人：

• 单轮测即时回答质量；多轮还要测上下文记忆、意图漂移、纠错和话题切换。
• 多轮特有风险：前面说了 A 后面忘了、用户改口后模型还按旧意图答、多轮注入（第二轮才发恶意指令）、上下文窗口满了悄悄丢关键信息。
• case 设计要是对话脚本而不只是单条 prompt，每轮标注期望行为：记住什么、该不该追问、何时重置话题。

👔 Raina面试官： 多轮 case 维护成本高，有什么技巧？

🙋 候选人：

• 用模板化对话脚本 + 参数化，比如订机票场景固定 4 轮骨架，只换目的地和日期。
• 测 memory 时用埋针——第三轮问我第一轮说的 X 是什么——比通读全文人工判高效。

怎么验证模型输出格式是否稳定？

👔 Raina面试官： 业务要求输出 JSON、Markdown 或表格，你怎么验证格式稳定性？

🙋 候选人：

• 分两层测：语法层可自动化，语义层要评分。
• JSON：schema validate + 必填字段 + 类型检查，100% 可脚本断言。Markdown/表格：解析器检查结构（标题层级、表格行列），关键字段抽取比对。同一 Prompt 跑 20 次看格式崩溃率。
• Prompt 里加 response_format 或 function calling 能显著提高稳定性，测试要覆盖有约束和约束失效降级两种路径。

👔 Raina面试官： JSON 合法但字段值胡编，怎么测？

🙋 候选人：

• 语法 Pass 只是门槛，还要做字段级语义校验——枚举值是否在允许范围、日期是否合理、和输入是否一致。
• Agent 场景对照 tool 返回做 cross-check，不允许模型编造未返回的字段值。

长上下文场景怎么设计测试用例？

👔 Raina面试官： 128K 甚至更长上下文的产品，你会设计哪些测试用例？

🙋 候选人：

• 长上下文测四类：needle-in-haystack、首尾记忆、中间丢失、截断降级。
• Needle：在大量无关文本里藏一条关键事实，看模型能否召回。首尾：关键信息放开头 vs 结尾 vs 中间，测 lost-in-the-middle。截断：输入超 window 时系统是截断、摘要还是报错，行为要符合 spec。
• 还要测性能：长上下文下的延迟和成本，别只测能不能答对。

👔 Raina面试官： 真实用户很少塞满 128K，这类测试是否过度？

🙋 候选人：

• 不必每次全量 128K，但要测边界附近——比如窗口 90%、95%、100%、101% 的行为。
• 很多 bug 出在截断策略和 silently drop 上，用户感知是模型忘了，实际是工程截断没处理好。

多模态产品功能测试难点在哪？

👔 Raina面试官： 图文、语音多模态 AI 产品，功能测试比纯文本难在哪？

🙋 候选人：

• 难点在输入多样化 + 评判标准模糊 + 自动化难。
• 图像：分辨率、格式、遮挡、旋转、截图 vs 照片，都会影响识别。语音：口音、噪声、语速、打断。输出侧 OCR、图片描述、语音合成的质量很难 string match，需要专项 rubric 或人工抽检。
• 测试数据管理也更复杂——要有版权合规的图片/音频集，敏感内容过滤，不同设备采集的差异。

👔 Raina面试官： 多模态 case 怎么自动化？

🙋 候选人：

• 工程层自动化：上传、格式转换、API 返回结构。内容质量层用结构化输出 + 关键实体断言，比如图里有个红色按钮，期望 OCR 结果包含提交。
• 全量质量靠 sampling + 人工 audit，和 LLM 文本测试一样，接受统计门禁而非 100% 自动判。

流式输出怎么测？

👔 Raina面试官： Streaming 接口和普通 REST 一次性返回，测试上有什么不同？

🙋 候选人：

• Streaming 要额外测协议、时序、完整性和中断恢复，不只是最终内容。
• 协议：SSE/WebSocket 帧格式、event 类型顺序、done 信号。时序：首 Token 延迟 TTFB、chunk 间隔是否异常卡顿。完整性：流结束后内容和 non-stream 一致吗，有没有丢 chunk 或重复。中断：用户 cancel 后服务端是否正确清理。
• 自动化可以用 stream consumer 攒包后做最终内容断言，同时记录 TTFB 和总耗时分布。

👔 Raina面试官： 流式过程中内容逐步变化，中间态要测吗？

🙋 候选人：

• 一般不断言中间态文案，但可测 UI 层：loading 态、打字机效果、提前 abort 按钮是否可用。
• 除非产品 spec 要求先出摘要后出详情这类分阶段输出，才测中间 event 类型和内容结构。

模型拒答、安全拦截、兜底回复怎么测？

👔 Raina面试官： 有害请求该拒答、系统出错该兜底——这类场景你怎么测？

🙋 候选人：

• 分三类 case 集：应拒答、应正常答、灰区需澄清，每类都要有。
• 应拒答：暴力、违法、隐私窃取、越狱 prompt——期望稳定拒绝且不说教式泄露有害信息。应正常答：合法专业问题不能误杀。灰区：医疗/legal 等该澄清边界或建议找专业人士。
• 兜底：模型超时、429、内容过滤误触时，用户看到友好 fallback 而不是空白或 raw error。每条兜底路径要有明确 copy 和 retry 引导。

👔 Raina面试官： 拒答测多了模型变过度保守怎么办？

🙋 候选人：

• 必须同时跑误拒率case——正常问题不能被无理拒绝。安全和可用性要平衡，指标看 reject precision 和 false reject rate。
• 上线后监控用户因拒答流失和申诉 case，定期调 guardrail 阈值，不是测一次就完事。

同一 Prompt 多次结果不一致，算 Bug 吗？

👔 Raina面试官： 同一 Prompt 跑五次，答案每次不一样。这算 Bug 吗？你怎么界定？

🙋 候选人：

• 不一定算 Bug，要看不一致发生在什么维度、什么场景。
• 措辞不同但语义等价——正常，LLM 本身有随机性。关键事实前后矛盾、格式时而 JSON 时而散文、该拒答时有时答——这是 defect。P0 安全/合规/格式 case 要求稳定；开放创作类可以接受多样。
• 界定方法：对同一 prompt 采样 N 次，看关键约束违反率。超过阈值（比如格式错误率 >5%）就提 ticket，而不是一次不同就报 Bug。

👔 Raina面试官： 开发说 temperature 不为 0 所以不一致，测试怎么回应？

🙋 候选人：

• 分场景：生产默认参数下测，而不是强求 temperature=0。如果线上就是 0.7，测试就要在 0.7 下评估稳定性。
• 但对 blocking case 可以要求评测时用 temperature=0 或固定 seed 做回归基线，和生产采样测试分开。

幻觉怎么测？能完全消除吗？

👔 Raina面试官： Hallucination 是 LLM 测试的老大难问题。你怎么测？能彻底消除吗？

🙋 候选人：

• 测幻觉要分类型：事实性幻觉、引用幻觉、工具结果幻觉，不能笼统说胡编。
• 事实性：问有标准答案的问题，对照知识库或 ground truth。RAG 场景测 answer 是否超出 retrieved docs（faithfulness）。引用幻觉：给的出处是否真实存在、是否 support 答案。工具幻觉：模型是否编造未返回的 API 数据。
• 不能彻底消除，只能控制在可接受水平。用幻觉率指标 + 高危场景 100% 拦截，比追求零幻觉现实。

👔 Raina面试官： 自动评测幻觉靠谱吗？

🙋 候选人：

• LLM-as-Judge 和 NLI 模型有用但会误判，核心集必须有人工 spot check。
• 我会用自动评做大规模筛，人工验证 Top failure 和随机 5% 样本来校准自动评分的准确率。

事实性错误和创造性发挥怎么区分？

👔 Raina面试官： 写小说可以编，问答不能编——测试标准里你怎么区分事实错误和合理创作？

🙋 候选人：

• 先看产品 mode 和用户预期：creative writing 允许虚构；knowledge QA 要求 grounded。
• 测试 spec 里每条 case 标注 mode 和 acceptable behavior。事实类 case 有 ground truth 或权威来源；创作类 case 评结构、连贯性、风格，不判是否真实。
• 灰区最大：营销文案、头脑风暴——允许适度夸张但不能虚假承诺。这类要和 PM 写清 rubric，测试只执行共识标准。

👔 Raina面试官： RAG 产品里模型加了合理推断算幻觉吗？

🙋 候选人：

• 看推断是否被文档支持。文档说 A 和 B，推断 A→B 合理；文档没提 C，模型补 C 就是 hallucination。
• Faithfulness 评分要区分推理和编造，测试 case 最好标注允许的推理深度。

边界输入怎么设计用例？

👔 Raina面试官： 空输入、超长、乱码、emoji——边界输入你会怎么设计？

🙋 候选人：

• 我按输入形态 × 系统反应建矩阵，而不是随机试。
• 空/纯空格：应澄清或友好提示，不能 500。超长：触顶截断还是拒绝，行为要一致且有用户提示。乱码/特殊字符：不崩溃、不泄露 system prompt。Emoji/混合语言：编码正确、回复合理。
• 还要测组合边界：空 + 附件、超长 + 多轮累积、Unicode 归一化（全角半角）。每条 case 定义期望行为类型：澄清 / 截断 / 正常处理 / 拒答。

👔 Raina面试官： 边界 case 太多了，优先测哪些？

🙋 候选人：

• 优先会导致 crash、泄露、silent wrong answer 的边界，其次才是体验类。
• 空输入和超 window 是 P0；纯 emoji 回复可能是 P2。按线上真实输入分布采样补长尾。

多语言、方言测试集有什么要求？

👔 Raina面试官： 产品要支持多语言甚至方言，测试集怎么建？有什么要求？

🙋 候选人：

• 三个要求：覆盖度、真实性、评判一致性。
• 覆盖度：按用户语言分布采样，不只测中英——还要测 code-switching（中英夹杂）、繁简、日韩等目标市场。真实性：用 native speaker 写 prompt，别全靠机翻。评判：多语言 case 要么各语言独立 rubric，要么用 multilingual judge 并人工校准。
• 方言和口语：单独建 sub-set，测 ASR+LLM 链路时不只看文本还要测语音识别错误传播。

👔 Raina面试官： 小语种 case 少，通过率波动大怎么办？

🙋 候选人：

• 小语种可以降低 stat 门禁频率但提高单条 case 权重，关键市场语言必须达到和大语种同等 blocking 标准。
• 用语言 × 场景矩阵确保每种语言的 core journey 都有代表，而不是每种语言只测 1 条。

Function Calling 结果不对怎么定位？

👔 Raina面试官： 工具调用结果不对——你怎么判断是模型选错、参数错还是工具本身 bug？

🙋 候选人：

• 看 trace 四层：选工具 → 填参数 → 工具执行 → 模型解读结果。
• 选工具错：该调 search 却调了 calculator，是 routing 问题，查 tool description 和 prompt。参数错：工具对了但 JSON 字段格式/值不对，查 schema 校验是否缺失。工具执行错：参数对但 API 返回异常，是后端 bug。解读错：工具返回正确但模型总结胡编，是 generation 问题。
• 每个 failure 打标签进 Eval，回归时按层统计退化，别笼统报工具不好使。

👔 Raina面试官： 怎么写自动化断言？

🙋 候选人：

• 工程层断言调了哪个 tool、参数 schema 合法；结果语义用 golden tool mock 固定返回，隔离后端变量。
• E2E 再覆盖少量真实 API case，分层测才不会互相干扰。

模型版本切换时测试策略怎么调整？

👔 Raina面试官： 从 GPT-4 换到 GPT-4o 或换供应商，测试策略要怎么调？

🙋 候选人：

• 模型切换 = full regression + diff 分析，不是冒烟了事。
• 至少跑完整核心 Eval 集，对比新旧版 win rate、各维度分数、成本和延迟。重点看：安全 case 有没有退化、格式 compliance、长尾语言。准备 rollback 条件和 canary 比例。
• 换供应商还要测 API 差异：token 计费、上下文长度、tool calling 格式、content filter 行为，这些不是模型能力问题但会影响上线。

👔 Raina面试官： 新版整体更好但某几个老 case 变差了，上不上？

🙋 候选人：

• 看变差的 case 是不是P0 业务场景。核心场景退化就 blocking，长尾 corner case 可以记录 tech debt。
• 用 side-by-side 报告给 PM 做 trade-off 决策，测试提供数据而不是替产品拍板。