企业官网建设流程全解析

最近面试了几位投AI大模型产品测试岗位的候选人，一个现象很明显：简历上都会写熟悉大模型、熟悉Prompt、了解RAG，但坐下来深聊，很多人对“为什么”的回答停在表层。问“离线指标涨了，线上体验一定更好吗”，会说“不一定，但具体为什么不好说”；问“模型在某个业务场景频繁输出幻觉，你会先看数据、先看Prompt，还是先看RAG链路”，大部分人的回答是“我会都看看”——这句话本身没错，但没有体现一个可执行的排查顺序。

这类回答不完全是技术深度问题，更像是对大模型测试这件事的理解框架还没建立起来。它和传统功能测试最大的区别，不是换了一套工具，而是从“验证系统是否符合预期”变成了“在不确定性中评估风险”。

所以这份面试高频题合集，我想按真实能力维度来组织，而不是给一份可以背的题单。面试大模型测试岗位，能不能拿到offer不取决于你记住了多少概念，而取决于你能不能表现出“把模型当产品来测”的完整方法。

1. 先想清楚：大模型测试面试到底在考什么

很多人准备面试的第一步是找题库、背答案，这恰恰是方向错了。大模型产品测试是这两年才逐渐独立的岗位方向，很多面试官自己也在通过项目边学边补。这意味着面试中真正会被高分的，不是“你背过哪些面试题”，而是你面对一个模糊问题时的反应速度和方法。

1.1 面试官想看到的，不是背题能力

常见一个例子：面试官问“你怎么测试一个基于大模型的客服机器人？”

低分回答通常是：“我会设计功能用例、性能用例、安全用例，用JMeter做压测，用pytest做自动化……”

这个回答不是错，但面试官听完基本不会觉得你理解了大模型产品测试。因为它没有回答一个核心问题：大模型客服机器人的核心风险是什么，你用什么标准判断“这条回答是好的”。

更好的回答会先定性任务：客服机器人核心是“检索 + 生成”，主要质量风险包括回答是否命中知识库、事实是否一致、是否使用超纲知识、语气和指令遵循是否符合要求、敏感内容是否被拦截。然后再谈怎么测：检索层评估召回率、排序正确性；生成层评估事实一致性、引用准确性、指令遵循度；再补一轮安全合规和用户体验测试。

这个差异，本质是测试思维有没有从“执行用例”升级到“设计评测”。

1.2 从“功能验证者”到“质量风险识别者”

传统软件测试的核心是“需求 -> 用例 -> 预期结果 -> 断言”。测试人员只需要判断系统输出是否等于预期结果。大模型测试不一样：很多输出没有唯一正确答案。同一个问题，“中国有哪些值得去的旅游城市”可以有无数种合理回答；同一句输入，模型输出会随温度参数变化。

因此，测试人员的核心任务从“验证正确性”变成了“识别和量化风险”。你要判断的不是模型答得对不对，而是“在什么情况下模型可能坏，坏到什么程度，对用户和业务的影响多大，如何尽早发现”。

这其实是好事。当判断维度从“对/错”变成“风险等级”，测试的深度和话语权都会上升。你可以明确提出：这个场景的幻觉率从3%涨到8%，是一个必须修复的高优问题；那个场景的回答长度变化，可能只是模型版本波动，不构成阻塞。传统测试里“测试不通过就提bug”的简单逻辑，在这里变成了“结合业务目标判断风险优先级”。

1.3 大模型产品测试和传统测试的分水岭

可以用一个表格把差异说清楚：

这个表格不是说传统测试工具没用了，而是说大模型产品测试多了一层“模型行为不可控”的问题。很多传统测试的思维依然有效，比如先小范围验证、再扩大范围，但你要能额外处理概率性输出和评测成本。

2. 大模型测试的核心基础题：不是考概念，是考理解

面试题库里最常见的，就是“你了解哪些大模型评测指标”。候选人一般会背出BLEU、ROUGE、PPL、F1等。但面试官真正想听的是：你知道这些指标的适用边界吗？

2.1 从评测指标说开去：准确率、召回率之外的盲区

举例说明：

• BLEU 是基于 n-gram 精确匹配的指标，适合机器翻译这种有参考译文的场景。用在开放式对话上，很容易误伤语义正确但措辞不同的回答。
• ROUGE 常用于摘要评测，核心是看生成内容与参考摘要的重叠度。如果任务要求概括信息而不是逐字复制，ROUGE 的价值也很有限。
• PPL 衡量的是模型对文本的困惑程度，越低通常表示模型“更熟练”。但PPL低不等于生成质量好，模型可能非常自信地输出一段事实错误的内容。
• BERTScore 用语义向量比较文本相似度，比字面匹配好一些，但对“事实是否一致”的判断仍然不够。
• 更接近业务的质量指标通常还包括：幻觉率、指令遵循率、引用准确率、安全合规率、用户最终采纳率。

可以这样整理：

实际落地中，更推荐的做法是：结合任务类型选指标，不要只拿一个分数拍板。回答“指标怎么选”时，可以按下面的框架组织：

1. 任务类型：生成、分类、检索、对话、摘要、翻译，每种任务的理想指标不同。
2. 标注成本：人工打分最准但贵，LLM打分可以自动化但有偏好偏差。
3. 业务对齐：指标是不是和用户体感一致？比如“用户没有二次追问”可能比ROUGE分数更有业务价值。
4. 可追溯性：指标能不能定位到具体badcase，方便回到Prompt和数据链路复盘。

2.2 Prompt 测试和用例设计：输入空间远比想象中大

传统接口测试用例设计，核心是等价类、边界值、组合场景。大模型产品测试的输入是自然语言，理论上没有边界。你没法说“Prompt已经覆盖完了”。

面试里经常问：“Prompt 测试用例怎么设计？” 一个能体现功底的回答，可以从这几个维度展开：

• 指令明确度：用清晰指令、模糊指令、带示例的few-shot、无示例的zero-shot分别测。
• 输入复杂度：短句、长文本、多轮上下文、多意图混合、带干扰信息的输入。
• 格式要求：要求JSON、Markdown、列表时，看模型能不能稳定输出指定格式。
• 风险类别：按合规边界设计风险样本集，覆盖违法、违规、歧视、诱导、隐私等类别，验证模型和前置过滤是否生效。
• 边界输入：空输入、超长输入、多语言混合、特殊字符、代码片段、表格等。

还要提到一个关键点：Prompt版本管理。实际项目中，测试人员要先和研发确认当前线上使用的Prompt版本，再基于该版本构建用例。否则同一个模型、不同Prompt，用例结果可能完全不同，回归对比也就没有意义。

2.3 数据构建和标注：一张测试集背后是一整套工程

大模型评测不能只靠“找几个问题试试”。为了得到一个可信的通过率，你需要一套有代表性的测试集，并且要回答几个问题：

1. 这个测试集覆盖了哪些用户场景？领域、意图、难度分布是什么？
2. 谁标注的？标注标准是什么？
3. 两个标注员意见不一致时怎么处理？
4. 样本量够不够支撑“模型通过率是85%”这个结论？

面试时如果主动提到“标注一致性”和“分歧裁决机制”，通常会加分。因为这说明你把评测当作一个工程问题而不是写脚本问题。

工程经验上，可以按下面这个最小流程搭：

1. 先定义每个维度的标注标准，比如“事实一致性”分3级：完全一致、部分一致、不一致。
2. 收集真实用户问题，按业务场景分层抽样，先用100条做小样本试点。
3. 让两人独立标注，计算一致性；一致性低于70%，需要修订标准或补充示例。
4. 分歧样本由第三人仲裁，沉淀为新的标注规范。
5. 测试集版本化，纳入回归体系。

这套流程看起来不复杂，但在面试中说清楚，比背十个指标定义更有说服力。

3. 大模型测试的高频情境题：如何证明你有实战手感

面试里最常出现的情境题，通常是从真实测试中提取出来的。比如“模型在客服场景里经常回答出知识库之外的信息，你怎么办？”这类问题没有标准答案，面试官看的是排查思路和优先级判断。

3.1 幻觉、有害内容、指令遵循：三类典型风险的排查路径

先说话首先，这里建议先定性，再给排查顺序：

1. 确认这是不是真正的幻觉。把同样的输入跑几遍，看是否稳定复现；找两个同事独立判断，避免个人主观影响。
2. 检查输入。用户问题是否包含足够上下文？是不是一个开放问题？知识库中是否有对应内容？
3. 检查检索链路。RAG场景下，先看召回的片段是否相关。如果召回的片段本身不包含答案，生成模型就只能靠自己的知识补，幻觉自然高。
4. 检查Prompt。Prompt里是否明确要求“只能基于给定知识库回答，不要使用外部知识”？如果Prompt允许模型自由发挥，那它就会自由发挥。
5. 检查生成参数。温度调高，生成的多样性增加，幻觉率通常也会上升。先降到0或接近0，看趋势是否明显。
6. 统计badcase并分层。把幻觉样本按问题类型、知识库缺口、检索失败、Prompt问题归类，就能和研发讨论优先级。

有害内容排查更偏安全合规。这里要注意的是，测试样本和对抗样例都要严格限制在合规范围内，不能公开列出具体的绕过方法。一般做法是建立风险样本集，覆盖明确的违规类别，验证输入过滤、模型对齐、输出过滤三道防线是否有效，并且持续迭代样本集。

指令遵循能力更多是在复杂任务里被看到。比如“请先总结，再给出三个建议，最后输出JSON”这类组合指令，模型可能只完成其中一部分。测试时可以把指令拆成能力维度：理解指令、多步执行、格式遵循、上下文记忆、拒绝不合理请求。每个维度单独设计样本，方便定位是“模型能力不足”还是“Prompt表达不清楚”。

3.2 回归测试怎么做：既要防劣化，又要控成本

大模型产品迭代非常快。模型版本每换一版、Prompt每次调整，都可能导致旧问题修复、新问题出现。但每次发版都跑几千条完整评测，成本和耗时都受不了。

实际做法通常是把测试集分层：

不管哪一层，都需要考虑一个问题：大模型输出是概率性的，同样输入跑两次，结果可能不同。所以回归时除了看分数变化，还要看波动范围。建议同一个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场景下的事实一致性，可以这样：

1. 取20条真实用户问题。
2. 用固定Prompt和参数跑一遍，记录输出。
3. 对每条输出检查：有没有基于知识库、有没有错误信息。
4. 把失败样本归类，定位到检索、Prompt、生成哪一层。
5. 做一次调整，再跑同一组，看修复率。

面试时如果主动描述这样一个小闭环，比讲一堆工具名更有画面感。面试官能从中看到你的实操逻辑，也能想象你入职之后会怎么工作。

5. 把一套面试答案沉淀成可持续的能力框架

如果把面试题归类，大模型测试面试反复出现的底层问题基本逃不开四层。这四层可以作为你自己的“答题主线”。

5.1 一套四层自检框架

1. 目标层：这个产品最重要的质量风险是什么？说得越具体越好。“用户可能因为回答错误信息做出危险决策”和“回答太啰嗦导致用户流失”是完全不同的风险。
2. 数据层：用什么数据能代表这个风险？用户真实问题、常见badcase、极端输入都要覆盖。
3. 评测层：用什么指标判断好坏？是人工评分，是规则，还是大模型打分？阈值设多少？分歧怎么裁决？
4. 迭代层：评测结果怎么推动修复？是改Prompt、调参数、换检索策略，还是反馈给模型训练？

面试时不管遇到什么题，都可以先在脑子里过一遍这四层。比如被问“怎么测大模型的文生图功能”，你也可以套：目标是判断图片是否符合用户指令、是否包含违规元素；数据层准备不同风格的提示词和风险提示；评测层用人工评分和规则检测；迭代层把失败样本反哺Prompt或过滤策略。

这个框架本身，就是你的答题主线。

5.2 面试中的答题结构：结论-机制-落地-边界

再来一个非常实用的答题结构：结论，机制，落地，边界。

1. 结论：先给一句话判断。比如“我认为这个场景的核心风险是事实一致性，不是响应速度。”
2. 机制：解释为什么这样判断。比如“用户使用这个产品的目的是获取准确信息，一次错误回答会导致信任崩塌。”
3. 落地：给出可执行步骤。比如“先建100条典型问题测试集，跑一轮评估，统计事实一致性和引用准确率；再按失败案例分类，定位是检索问题还是生成问题。”
4. 边界：主动说明局限。比如“离线数据只能覆盖部分场景，上线后还要看用户反馈和二次追问率。”

这个结构特别适合面试场景，因为它展现出的不是“背过题”，而是“有方法且有分寸”。你不需要记住标准答案，只需要对任何问题都按这个结构组织表达。

5.3 面试之外：真正能长期积累的是什么

最后想回到一个更根本的判断：大模型产品测试知识迭代太快，今天背下来的面试题，半年后可能就不流行了。真正有长期价值的是三件事：

1. 对评测逻辑的理解。知道什么时候用人工，什么时候用工具，什么时候用模型评判，样本和业务目标之间怎么对齐。
2. 对模型行为异常的敏感度。看到一个badcase，能快速判断问题可能出在数据、Prompt、检索还是参数。
3. 对成本和质量平衡的判断。大模型评测很贵，不是所有场景都值得跑全量样本，知道如何用最小成本拿到可信结论。

这才是大模型测试岗位真正的“护城河”。面试题只是一个入口，长期能不能做好，取决于你能否把每一次badcase分析变成对产品风险图景的补充。

如果现在正在准备面试，我最建议你先找一个自己熟悉的业务场景，从搭建一个20条用例的最小测试集开始，把从样例设计、指标选择、badcase分析到回归验证的整个闭环手动走一遍。做完这件事，你会发现很多“高频面试题”背后的逻辑突然变得清楚了。