最近面试了几位投AI大模型产品测试岗位的候选人一个现象很明显简历上都会写熟悉大模型、熟悉Prompt、了解RAG但坐下来深聊很多人对“为什么”的回答停在表层。问“离线指标涨了线上体验一定更好吗”会说“不一定但具体为什么不好说”问“模型在某个业务场景频繁输出幻觉你会先看数据、先看Prompt还是先看RAG链路”大部分人的回答是“我会都看看”——这句话本身没错但没有体现一个可执行的排查顺序。这类回答不完全是技术深度问题更像是对大模型测试这件事的理解框架还没建立起来。它和传统功能测试最大的区别不是换了一套工具而是从“验证系统是否符合预期”变成了“在不确定性中评估风险”。所以这份面试高频题合集我想按真实能力维度来组织而不是给一份可以背的题单。面试大模型测试岗位能不能拿到offer不取决于你记住了多少概念而取决于你能不能表现出“把模型当产品来测”的完整方法。1. 先想清楚大模型测试面试到底在考什么很多人准备面试的第一步是找题库、背答案这恰恰是方向错了。大模型产品测试是这两年才逐渐独立的岗位方向很多面试官自己也在通过项目边学边补。这意味着面试中真正会被高分的不是“你背过哪些面试题”而是你面对一个模糊问题时的反应速度和方法。1.1 面试官想看到的不是背题能力常见一个例子面试官问“你怎么测试一个基于大模型的客服机器人”低分回答通常是“我会设计功能用例、性能用例、安全用例用JMeter做压测用pytest做自动化……”这个回答不是错但面试官听完基本不会觉得你理解了大模型产品测试。因为它没有回答一个核心问题大模型客服机器人的核心风险是什么你用什么标准判断“这条回答是好的”。更好的回答会先定性任务客服机器人核心是“检索 生成”主要质量风险包括回答是否命中知识库、事实是否一致、是否使用超纲知识、语气和指令遵循是否符合要求、敏感内容是否被拦截。然后再谈怎么测检索层评估召回率、排序正确性生成层评估事实一致性、引用准确性、指令遵循度再补一轮安全合规和用户体验测试。这个差异本质是测试思维有没有从“执行用例”升级到“设计评测”。1.2 从“功能验证者”到“质量风险识别者”传统软件测试的核心是“需求 - 用例 - 预期结果 - 断言”。测试人员只需要判断系统输出是否等于预期结果。大模型测试不一样很多输出没有唯一正确答案。同一个问题“中国有哪些值得去的旅游城市”可以有无数种合理回答同一句输入模型输出会随温度参数变化。因此测试人员的核心任务从“验证正确性”变成了“识别和量化风险”。你要判断的不是模型答得对不对而是“在什么情况下模型可能坏坏到什么程度对用户和业务的影响多大如何尽早发现”。这其实是好事。当判断维度从“对/错”变成“风险等级”测试的深度和话语权都会上升。你可以明确提出这个场景的幻觉率从3%涨到8%是一个必须修复的高优问题那个场景的回答长度变化可能只是模型版本波动不构成阻塞。传统测试里“测试不通过就提bug”的简单逻辑在这里变成了“结合业务目标判断风险优先级”。1.3 大模型产品测试和传统测试的分水岭可以用一个表格把差异说清楚维度传统功能测试大模型产品测试预期输出明确可精确断言不唯一需要评分或人工判断用例数量数百到数千可穷举输入空间接近无限只能分层抽样回归成本低自动化跑完很快高模型推理和人工/模型评分都贵失败原因定位代码、配置、环境数据、Prompt、检索、参数、模型版本都可能上线决策通过/不通过比较清楚需要多个维度综合判断且带概率性工具栈Jira、Postman、JMeter、Selenium等Prompt平台、评测框架、标注平台、RAG链路调试工具这个表格不是说传统测试工具没用了而是说大模型产品测试多了一层“模型行为不可控”的问题。很多传统测试的思维依然有效比如先小范围验证、再扩大范围但你要能额外处理概率性输出和评测成本。2. 大模型测试的核心基础题不是考概念是考理解面试题库里最常见的就是“你了解哪些大模型评测指标”。候选人一般会背出BLEU、ROUGE、PPL、F1等。但面试官真正想听的是你知道这些指标的适用边界吗2.1 从评测指标说开去准确率、召回率之外的盲区举例说明BLEU 是基于 n-gram 精确匹配的指标适合机器翻译这种有参考译文的场景。用在开放式对话上很容易误伤语义正确但措辞不同的回答。ROUGE 常用于摘要评测核心是看生成内容与参考摘要的重叠度。如果任务要求概括信息而不是逐字复制ROUGE 的价值也很有限。PPL 衡量的是模型对文本的困惑程度越低通常表示模型“更熟练”。但PPL低不等于生成质量好模型可能非常自信地输出一段事实错误的内容。BERTScore 用语义向量比较文本相似度比字面匹配好一些但对“事实是否一致”的判断仍然不够。更接近业务的质量指标通常还包括幻觉率、指令遵循率、引用准确率、安全合规率、用户最终采纳率。可以这样整理指标典型适用任务主要局限BLEU机器翻译偏字面重叠对语义正确但措辞不同的回答不友好ROUGE文本摘要依赖参考摘要较难衡量信息概括质量PPL语言模型预训练评估低困惑度不等于事实正确BERTScore语义相似度比较对事实一致性判断有限人工评分 / LLM-as-Judge开放生成、对话、RAG成本高LLM打分有偏好偏差实际落地中更推荐的做法是结合任务类型选指标不要只拿一个分数拍板。回答“指标怎么选”时可以按下面的框架组织任务类型生成、分类、检索、对话、摘要、翻译每种任务的理想指标不同。标注成本人工打分最准但贵LLM打分可以自动化但有偏好偏差。业务对齐指标是不是和用户体感一致比如“用户没有二次追问”可能比ROUGE分数更有业务价值。可追溯性指标能不能定位到具体badcase方便回到Prompt和数据链路复盘。2.2 Prompt 测试和用例设计输入空间远比想象中大传统接口测试用例设计核心是等价类、边界值、组合场景。大模型产品测试的输入是自然语言理论上没有边界。你没法说“Prompt已经覆盖完了”。面试里经常问“Prompt 测试用例怎么设计” 一个能体现功底的回答可以从这几个维度展开指令明确度用清晰指令、模糊指令、带示例的few-shot、无示例的zero-shot分别测。输入复杂度短句、长文本、多轮上下文、多意图混合、带干扰信息的输入。格式要求要求JSON、Markdown、列表时看模型能不能稳定输出指定格式。风险类别按合规边界设计风险样本集覆盖违法、违规、歧视、诱导、隐私等类别验证模型和前置过滤是否生效。边界输入空输入、超长输入、多语言混合、特殊字符、代码片段、表格等。还要提到一个关键点Prompt版本管理。实际项目中测试人员要先和研发确认当前线上使用的Prompt版本再基于该版本构建用例。否则同一个模型、不同Prompt用例结果可能完全不同回归对比也就没有意义。2.3 数据构建和标注一张测试集背后是一整套工程大模型评测不能只靠“找几个问题试试”。为了得到一个可信的通过率你需要一套有代表性的测试集并且要回答几个问题这个测试集覆盖了哪些用户场景领域、意图、难度分布是什么谁标注的标注标准是什么两个标注员意见不一致时怎么处理样本量够不够支撑“模型通过率是85%”这个结论面试时如果主动提到“标注一致性”和“分歧裁决机制”通常会加分。因为这说明你把评测当作一个工程问题而不是写脚本问题。工程经验上可以按下面这个最小流程搭先定义每个维度的标注标准比如“事实一致性”分3级完全一致、部分一致、不一致。收集真实用户问题按业务场景分层抽样先用100条做小样本试点。让两人独立标注计算一致性一致性低于70%需要修订标准或补充示例。分歧样本由第三人仲裁沉淀为新的标注规范。测试集版本化纳入回归体系。这套流程看起来不复杂但在面试中说清楚比背十个指标定义更有说服力。3. 大模型测试的高频情境题如何证明你有实战手感面试里最常出现的情境题通常是从真实测试中提取出来的。比如“模型在客服场景里经常回答出知识库之外的信息你怎么办”这类问题没有标准答案面试官看的是排查思路和优先级判断。3.1 幻觉、有害内容、指令遵循三类典型风险的排查路径先说话首先这里建议先定性再给排查顺序确认这是不是真正的幻觉。把同样的输入跑几遍看是否稳定复现找两个同事独立判断避免个人主观影响。检查输入。用户问题是否包含足够上下文是不是一个开放问题知识库中是否有对应内容检查检索链路。RAG场景下先看召回的片段是否相关。如果召回的片段本身不包含答案生成模型就只能靠自己的知识补幻觉自然高。检查Prompt。Prompt里是否明确要求“只能基于给定知识库回答不要使用外部知识”如果Prompt允许模型自由发挥那它就会自由发挥。检查生成参数。温度调高生成的多样性增加幻觉率通常也会上升。先降到0或接近0看趋势是否明显。统计badcase并分层。把幻觉样本按问题类型、知识库缺口、检索失败、Prompt问题归类就能和研发讨论优先级。有害内容排查更偏安全合规。这里要注意的是测试样本和对抗样例都要严格限制在合规范围内不能公开列出具体的绕过方法。一般做法是建立风险样本集覆盖明确的违规类别验证输入过滤、模型对齐、输出过滤三道防线是否有效并且持续迭代样本集。指令遵循能力更多是在复杂任务里被看到。比如“请先总结再给出三个建议最后输出JSON”这类组合指令模型可能只完成其中一部分。测试时可以把指令拆成能力维度理解指令、多步执行、格式遵循、上下文记忆、拒绝不合理请求。每个维度单独设计样本方便定位是“模型能力不足”还是“Prompt表达不清楚”。3.2 回归测试怎么做既要防劣化又要控成本大模型产品迭代非常快。模型版本每换一版、Prompt每次调整都可能导致旧问题修复、新问题出现。但每次发版都跑几千条完整评测成本和耗时都受不了。实际做法通常是把测试集分层层级规模用途频率冒烟集20-50条快速确认主流程是否可用每次改动核心回归集200-500条覆盖主要场景和已知风险每次发版/每轮迭代全量离线评测集1000条以上完整能力评估重要版本或定期线上监控/灰度对比真实流量看用户体感持续不管哪一层都需要考虑一个问题大模型输出是概率性的同样输入跑两次结果可能不同。所以回归时除了看分数变化还要看波动范围。建议同一个badcase至少跑3次或者用多个等价Prompt变体验证避免被单次随机结果误导。另一个省钱技巧是先用“LLM-as-Judge”做初筛再用人工精评。大模型先按规则打分和归类把明显好、明显差的样本筛掉只让人工审核边界样本。这样能显著降低人工成本但要注意LLM judge本身也有偏好需要定期抽检它和人工判断的一致性。3.3 线上评测与离线评测先解决“能不能测”再解决“测得准”离线评测最大的价值是快、可重复、可以量化。但它有两类明显缺陷一是测试集永远落后于真实用户需求覆盖不到长尾场景二是离线指标和用户体感不一定一致。所以成熟一些的团队都会做线上评测或灰度评测。常见手段包括影子模式把真实流量复制给新模型但不用新结果直接影响用户只记录结果供分析。A/B 对比把用户随机分组比较新老版本的业务指标比如回答采纳率、用户满意度、二次提问率、投诉率。用户反馈回路收集用户的点赞、点踩、追问、修改问题等信号形成badcase池回流到离线测试集。面试中比较好的回答方式是把离线、在线串成一条链路离线评测发现问题 - 修复后回归通过 - 灰度上线 - 在线指标对比 - 反馈badcase补充离线集。你不一定真的做过整套系统但能把这条链路讲清楚面试官就会觉得你具备系统性思维。4. 容易被淘汰的答题方式这几个坑要避开面试题库越来越多但很多候选人的回答仍然会踩在一些常见的坑里。这些坑不是知识量不够而是表达方式出了问题。4.1 只背指标定义不解释业务含义这是最常见的一个坑。面试者背了一堆指标但一提到具体业务场景就套不上。反面示例“我会看BLEU、ROUGE、PPL指标越高越好。”这不是一个“有业务含义”的回答。BLEU太高不一定好PPL降低也不等于回答更好。面试官想听到的是你如何根据业务目标选指标。比如“如果这个产品是知识密集型客服机器人我最看重的是事实一致性和引用准确率因为用户要的不是花哨的回复而是可验证的信息。BLEU和ROUGE分数可以作为参考但不能单独作为把关标准。”这个回答把指标和业务目标绑在一起说服力会强很多。4.2 把大模型测试等同于自动化工具脚本会写pytest、会调用模型API、会搭一个自动化脚本只是基本功。面试官想知道的不是“你会不会写代码”而是“你会不会判断哪些场景需要自动化、哪些场景自动化没有意义”。比如大模型输出是概率性的自动化断言如果只写死“等于某个字符串”用例本身就会失真。更有价值的自动化是调用模型接口 - 记录输出 - 用规则或judge模型做质量信号判断 - 输出badcase报告 - 触发人工复核。所以回答工具类问题时可以多讲一句这里的自动化是为了提取质量信号而不是替代人工判断。4.3 没有自己的“最小验证闭环”什么是“最小验证闭环”就是用尽量短的时间把一个模型质量假设验证一遍。比如你要测RAG场景下的事实一致性可以这样取20条真实用户问题。用固定Prompt和参数跑一遍记录输出。对每条输出检查有没有基于知识库、有没有错误信息。把失败样本归类定位到检索、Prompt、生成哪一层。做一次调整再跑同一组看修复率。面试时如果主动描述这样一个小闭环比讲一堆工具名更有画面感。面试官能从中看到你的实操逻辑也能想象你入职之后会怎么工作。5. 把一套面试答案沉淀成可持续的能力框架如果把面试题归类大模型测试面试反复出现的底层问题基本逃不开四层。这四层可以作为你自己的“答题主线”。5.1 一套四层自检框架目标层这个产品最重要的质量风险是什么说得越具体越好。“用户可能因为回答错误信息做出危险决策”和“回答太啰嗦导致用户流失”是完全不同的风险。数据层用什么数据能代表这个风险用户真实问题、常见badcase、极端输入都要覆盖。评测层用什么指标判断好坏是人工评分是规则还是大模型打分阈值设多少分歧怎么裁决迭代层评测结果怎么推动修复是改Prompt、调参数、换检索策略还是反馈给模型训练面试时不管遇到什么题都可以先在脑子里过一遍这四层。比如被问“怎么测大模型的文生图功能”你也可以套目标是判断图片是否符合用户指令、是否包含违规元素数据层准备不同风格的提示词和风险提示评测层用人工评分和规则检测迭代层把失败样本反哺Prompt或过滤策略。这个框架本身就是你的答题主线。5.2 面试中的答题结构结论-机制-落地-边界再来一个非常实用的答题结构结论机制落地边界。结论先给一句话判断。比如“我认为这个场景的核心风险是事实一致性不是响应速度。”机制解释为什么这样判断。比如“用户使用这个产品的目的是获取准确信息一次错误回答会导致信任崩塌。”落地给出可执行步骤。比如“先建100条典型问题测试集跑一轮评估统计事实一致性和引用准确率再按失败案例分类定位是检索问题还是生成问题。”边界主动说明局限。比如“离线数据只能覆盖部分场景上线后还要看用户反馈和二次追问率。”这个结构特别适合面试场景因为它展现出的不是“背过题”而是“有方法且有分寸”。你不需要记住标准答案只需要对任何问题都按这个结构组织表达。5.3 面试之外真正能长期积累的是什么最后想回到一个更根本的判断大模型产品测试知识迭代太快今天背下来的面试题半年后可能就不流行了。真正有长期价值的是三件事对评测逻辑的理解。知道什么时候用人工什么时候用工具什么时候用模型评判样本和业务目标之间怎么对齐。对模型行为异常的敏感度。看到一个badcase能快速判断问题可能出在数据、Prompt、检索还是参数。对成本和质量平衡的判断。大模型评测很贵不是所有场景都值得跑全量样本知道如何用最小成本拿到可信结论。这才是大模型测试岗位真正的“护城河”。面试题只是一个入口长期能不能做好取决于你能否把每一次badcase分析变成对产品风险图景的补充。如果现在正在准备面试我最建议你先找一个自己熟悉的业务场景从搭建一个20条用例的最小测试集开始把从样例设计、指标选择、badcase分析到回归验证的整个闭环手动走一遍。做完这件事你会发现很多“高频面试题”背后的逻辑突然变得清楚了。