ML 模型测试

共 19 题
📑 题目列表 19 题
#
★★★

1. ML 模型的测试集/验证集/训练集划分策略与数据泄漏(Data Leakage)的识别和避免方法?请举例说明时间序列场景下的数据泄漏风险。

在机器学习模型开发中,如何科学地划分训练集、验证集与测试集,如何识别并避免数据泄漏(Data Leakage),并请以时间序列场景为例说明数据泄漏的具体风险?

  • 训练/验证/测试集划分的比例与职责边界(训练拟合、验证调参、测试评估泛化)
  • 数据泄漏的两种类型:目标泄漏(Target Leakage)与特征泄漏(Feature Leakage)
  • 时间序列场景的时序切分(Time-based Split)与随机切分的区别

划分的目的是让测试集在模型训练与调参过程中"完全不可见",从而真实反映泛化能力。通常的比例约为训练 60-70%、验证 20%、测试 10-20%,但比例并非铁律,关键是三个集合数据来源同分布、且互不重叠。数据泄漏分为两类:一是特征泄漏,即训练时使用了线上推理根本拿不到的"未来信息"或"后验信息"(例如用交易是否成功作为特征来预测交易是否成功);二是目标泄漏,即标签信息被间接编入了特征。识别泄漏的方法包括:检查特征的时间戳是否晚于标签、检查特征是否高度相关于标签且逻辑上可疑、在测试集上做敏感性分析(若加入某特征后 AUC 异常飙升则高度可疑)。时间序列场景下必须采用基于时间的切分(如按日期划窗),绝不能随机打乱后切分,否则训练集和测试集会混入同一时间段的样本,导致模型"看到未来",测试指标虚高而线上退化。此外还应配合滚动窗口验证(Rolling Window / Walk-forward Validation)来评估稳定性。

泄漏的本质是"评估信息"与"训练信息"同源,使测试集失去独立验证意义。时间序列特别强调时序切分,是因为时间序列样本天然存在自相关,随机切分会破坏独立性。面试时建议先讲清楚三集合的职责,再讲泄漏的两大类,最后用时间序列举个具体例子,体现系统性思维。

# 随机切分(仅适用于非时序、独立同分布数据)
from sklearn.model_selection import train_test_split
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2, random_state=42)

# 时间序列必须用基于时间的切分,禁止随机打乱
train = df[df['date'] < '2024-01-01']
val   = df[(df['date'] >= '2024-01-01') & (df['date'] < '2024-06-01')]
test  = df[df['date'] >= '2024-06-01']
#
★★★

2. 数据漂移(Data Drift)与概念漂移(Concept Drift)的检测与测试策略?如何设计自动化监控和告警机制?

数据漂移(Data Drift)与概念漂移(Concept Drift)分别是什么,如何检测与测试,如何设计自动化的监控与告警机制?

  • 数据漂移(输入分布变化)与概念漂移(输入到输出的映射关系变化)的区别
  • 漂移检测方法:PSI(Population Stability Index)、KL 散度、KS 检验、特征分布统计量
  • 漂移的监控分层:数据层、特征层、输出层、业务结果层

数据漂移指模型的输入特征分布随时间发生变化(如用户年龄结构变化、新渠道流量占比变化),本质是"分布变了";概念漂移指输入与输出之间的真实映射关系发生变化(如同样的促销策略在政策变化后转化率骤降),本质是"规律变了"。数据漂移可通过 PSI、KL 散度、KS 检验、卡方检验等比较训练期分布与当前窗口分布来检测;概念漂移更隐蔽,通常通过监控模型在线预测精度、残差分布、或业务指标(如转化率、AUC)的持续下滑来间接发现。自动化监控应在四个层面部署:原始数据层(字段缺失率、格式异常)、特征层(每个特征的分布统计量,如 PSI 阈值通常 >0.1 提示关注、>0.25 提示显著漂移)、预测输出层(预测均值、概率分布、类别占比)、业务结果层(CTR、转化率、客诉率等)。告警机制需设计多级阈值(黄灯预警、红灯严重)、设置静默期避免抖动告警、并明确告警后流程:先人工复核样本、确认漂移类型、再决定是否重训、回滚或上线新模型。

面试重点是区分"输入分布变了"和"规律变了"两类漂移,并给出对应的检测方法与监控分层。能讲出错层监控(从数据到业务结果)和分级告警(避免无效告警淹没)会显著加分。概念漂移检测击中"无标签在线精度"这一难点是加分项。

#
★★★

3. LLM 评测(Eval)与回归测试如何设计?基准集构建、判定器(Judge)选择和稳定性(Fluctuation)控制的实践方法?

如何设计 LLM 的评测(Eval)与回归测试,包括基准集(Benchmark)构建、判定器(Judge)选择以及稳定性(Fluctuation)控制的实践方法?

  • 基准集构建:覆盖典型场景、边界、对抗样本,分级分类并标注
  • Judge 选择:规则匹配、LLM-as-Judge、人工评测、混合策略的取舍
  • 稳定性控制:多次采样取均值、固定 seed/温度、置信区间、差分评测

LLM 评测需要"输入 + 期望输出 + 判定方式"三要素。基准集应覆盖典型业务场景、边界/极限输入、对抗与恶意输入,并按难度与场景分级(如 smoke、regression、edge),每个用例标注可判定的期望。判定器有几种:规则/字符串/结构校验(适合 JSON 格式、关键词)、LLM-as-Judge(用另一个大模型打分或比对,适合开放语义)、人工审核(适合高风险、小样本)。实践中常用"规则为主 + LLM-Judge 兜底 + 人工抽检"的混合策略。稳定性控制是 LLM 评测的核心难点:由于模型输出具有随机性,同一用例多次运行结果可能波动,因此需固定采样温度和 seed、对同一用例多次采样取均值或取最坏/最好分、用统计显著性(如置信区间、配对检验)判断两次评测差异是否真实,或采用"差分评测"(同一输入只跑一次,对比新旧模型输出)来消除随机性。回归测试应纳入 CI,设置基线(如历史指标 95 分位)与失败门禁,指标劣化超过阈值即阻断发布。

这道题考察的是 LLM 评测工程化能力。关键得分点是"稳定性控制"——能讲出固定 seed、多次采样、差分评测、统计显著性这几招,说明真正踩过坑。Judge 的选择要强调"没有万能 Judge",需按任务类型与成本权衡。

#
★★★

4. LLM 应用测试的工程挑战,非确定性输出的验证方法?如何设计"足够好"的断言而非精确匹配?

LLM 应用测试面临非确定性输出的工程挑战,如何验证这类输出,如何设计"足够好"的断言而非精确匹配?

  • 非确定性产生的原因:采样温度、top-p、并发、模型版本内部差异
  • 断言策略:语义断言、结构断言、属性断言、范围断言
  • 从"精确匹配"转向"足够好"的判定标准

传统断言是精确字符串或数值匹配,但 LLM 输出具有非确定性,同一输入可能产生不同但都正确的回答,因此必须放弃精确匹配,转而采用"足够好"的语义化断言。设计维度包括:语义断言(用 LLM-as-Judge 或向量相似度判断核心语义是否一致)、结构断言(校验 JSON Schema、字段是否存在、类型是否正确)、属性断言(长度范围、是否包含关键实体、是否遵循指定格式)、行为断言(是否调用了正确工具、是否返回了合法状态码)。具体做法:先做严格的结构校验(JSON 必须可解析、字段齐全),再对语义做宽松校验(核心信息一致即可,允许表述差异),最后对高风险场景保留人工抽检。稳定性上可多次采样取大多数。此外,"足够好"的判定标准应显式化并版本化,避免不同测试批次判定标准漂移。

这道题的核心是"从精确匹配转向语义化断言"。能区分"结构严格、语义宽松"这个分层思想,并给出具体断言类型,是得分关键。回答要强调不能因为非确定性就放弃测试,而是换一种断言范式。

# 结构断言(严格)+ 语义断言(宽松)
def assert_llm_response(resp):
    # 1. 结构必须严格:JSON 可解析、字段齐全
    data = json.loads(resp)                     # 抛异常则失败
    assert "answer" in data and "source" in data
    # 2. 属性宽松:核心实体存在、长度在合理范围
    assert 0 < len(data["answer"]) < 500
    # 3. 语义由 LLM-Judge 判定,而非精确匹配
    score = judge.similarity(data["answer"], expected_meaning)
    assert score >= 0.8, f"语义不达标: {score}"
#
★★★

5. RAG 系统的端到端测试,检索质量(Recall/Precision)、生成质量(Faithfulness/Relevance)和端到端效果如何分层评估?

RAG 系统的端到端测试如何分层评估,包括检索质量(Recall/Precision)、生成质量(Faithfulness/Relevance)与端到端效果?

  • RAG 三层评估:检索层、生成层、端到端层
  • 检索质量指标:Recall@K、Precision@K、MRR、命中率
  • 生成质量指标:Faithfulness(忠实度)、Answer Relevance(答案相关性)

RAG 系统评估应分层进行,因为端到端指标差无法定位问题出在检索还是生成。第一层是检索层:评估检索器是否召回正确答案,指标有 Recall@K(Top-K 中是否包含正确答案)、Precision@K、MRR(正确答案的排序位置)、命中率,需要标注数据的"正确答案集合"。第二层是生成层:Faithfulness(忠实度)衡量生成内容是否可从检索到的上下文中得到支持、是否臆造;Answer Relevance(答案相关性)衡量回答是否切题、是否回答了用户问题。第三层是端到端层:综合衡量任务成功率、回答可接受率、用户满意度,常需人工或 LLM-Judge 评估。实践上可选用 RAGAS 等框架自动化计算忠实度、答案相关性、上下文相关性等指标,再结合检索层指标协同定位:若检索层 Recall 高但生成层 Faithfulness 低,说明问题在生成;反之在检索。分层评估能显著提升问题定位效率。

得分点是"分层 + 定位"。能讲清检索层指标和生成层指标各自含义,并说明如何用分层结果定位问题,比只罗列指标更有深度。RAGAS 作为落地工具是加分项。

#
★★

6. 对抗样本(Adversarial Example)鲁棒性如何测试?白盒攻击与黑盒攻击场景下的测试策略差异?

如何测试模型对对抗样本(Adversarial Example)的鲁棒性,白盒攻击与黑盒攻击场景下的测试策略有何差异?

  • 对抗样本的定义与常见生成方法(FGSM、PGD、自然扰动)
  • 白盒攻击:可访问模型梯度,攻速快、扰动小
  • 黑盒攻击:仅能查询输入输出,用替代模型迁移或查表

对抗样本是对原始输入施加人眼难以察觉的微小扰动,使模型误判(如图像加噪声后分类错误)。白盒攻击场景下攻击者能访问模型参数与梯度,常用 FGSM(单步梯度符号法)、PGD(多步迭代)等方法生成扰动极小但攻击有效的样本,测试时应验证模型在扰动预算(如 L-infinity 范数约束)内对对抗样本的准确率。黑盒攻击场景下攻击者只能查询输入输出,通常通过训练替代模型(Surrogate Model)并迁移攻击,或使用查询式攻击(如 HopSkipJump、边界攻击),测试策略上应评估模型对迁移攻击的鲁棒性,并限制查询次数。鲁棒性测试应衡量:在给定扰动范围下模型准确率的下降幅度、对抗样本的"可迁移率"、以及防御手段(对抗训练、输入净化、随机化)是否有效降低攻击成功率。测试要覆盖白盒与黑盒两种威胁模型,因为实际攻击者多数是黑盒。

关键区分白盒(可访问梯度、扰动小、攻击强)与黑盒(仅查询、需替代模型或更多查询)。能讲出对抗训练等防御验证,并强调实际威胁多为黑盒,体现工程判断。

#
★★

7. MLOps 中模型版本与流水线的 CI/CD 测试关注点,模型注册、A/B 部署、回滚的测试验证?

MLOps 中模型版本与流水线的 CI/CD 测试关注点有哪些,模型注册、A/B 部署与回滚的测试验证如何设计?

  • 模型注册与版本管理(唯一版本号、血缘、不可变)
  • CI/CD 测试层级:数据校验、训练可复现、模型评估、制品测试、部署冒烟
  • A/B 部署的测试验证:分流正确性、指标对比、shadow 部署

MLOps 的 CI/CD 测试关注三类:一是数据与训练阶段,验证数据质量校验通过、训练可复现(固定 seed 与版本)、模型离线评估达基线(如 AUC 不劣于线上);二是模型制品阶段,验证注册到模型仓库的包可加载、可推理、Schema 正确、序列化格式一致;三是部署阶段,验证新模型在 shadow 模式(影子流量)下与线上模型输出对比、再在金丝雀/灰度下放量、观察指标。模型注册需保证版本号唯一、记录血缘(数据版本、训练代码版本、超参)、制品不可变。A/B 部署测试关注:分流是否按比例正确(流量分桶校验)、实验组与对照组指标是否显著差异(用统计检验消除波动)、以及监控是否有异常。回滚需保证旧版本制品仍可部署,回滚后验证服务恢复与指标回归。整体上,MLOps 强调"评估 + 部署 + 监控"闭环。

得分点是讲清 CI/CD 在模型生命周期的不同阶段测什么,以及 shadow/金丝雀/A-B 三种部署策略的验证差异。强调可回滚与血缘追踪是 MLOps 工程化成熟的标志。

#
★★

8. ML 模型的公平性(Fairness)与偏见(Bias)测试,如何定义公平性指标并设计测试用例?

如何对 ML 模型进行公平性(Fairness)与偏见(Bias)测试,如何定义公平性指标并设计测试用例?

  • 公平性的常见定义:统计均等(Demographic Parity)、机会均等(Equalized Odds)、校准均等
  • 偏见来源:训练数据偏差、特征选择偏差、标签偏差
  • 公平性指标:不同群体间的命中率/FP/FN 差异、差异比

公平性测试首先需明确"公平性"的定义,常见有:统计均等(Demographic Parity,各组预测结果占比一致)、机会均等(Equalized Odds,各组在给定真实标签下命中率/误报率接近)、校准均等(Calibration,各组预测概率与实际发生概率一致)。不同公平性定义在业务上是互斥的,需按场景选择。偏见来源包括训练数据本身的不均衡(某群体样本少)、历史标签中的系统偏差、以及特征选择不当。测试用例设计:按敏感属性(性别、年龄、地域等)分组计算各组的正样本率、命中率、误报率、误拒率,并比较差异(如差异比 Disparate Impact Ratio > 某阈值即判失败);构造跨群体交叉样本(如不同性别+不同年龄段)验证偏差;对边界与极端输入分组验证。评估框架如 Fairlearn、Aequitas 可辅助计算指标。公平性测试应作为 CI 门禁,防止新模型引入系统性偏差。

得分点是先讲"公平性定义不唯一,需按业务选择",再列出具体指标与用例设计。能指出统计均等与机会均等可能冲突,说明理解深入。Fairlearn 等工具是加分项。

#
★★

9. LLM 的幻觉(Hallucination)检测,如何设计测试集验证模型输出的事实准确性?Grounding 验证的方法?

如何检测 LLM 的幻觉(Hallucination),如何设计测试集验证模型输出的事实准确性,Grounding 验证的方法有哪些?

  • 幻觉的定义:编造与事实或上下文不符的内容
  • 测试集设计:事实性问答集、带引用的上下文 base 用例、对抗性诱导用例
  • Grounding 验证:断言输出是否可被给定上下文支持

幻觉检测需验证输出是否"有据可依"。测试集设计分三类:一是事实性问答集,用公认事实提问,验证回答是否与事实一致;二是带上下文的 Grounding 用例,给定一段文档,验证模型是否只基于该文档作答(不能掺入外部常识或编造);三是对抗性用例,诱导模型在无信息时编造(如"文档中未提及的信息请回答")。Grounding 验证的核心是判断生成的每个关键断言是否可由给定上下文支持,可用 NLI(自然语言推断)模型判断上下文是否蕴含该断言,或用 LLM-as-Judge 逐条核对断言与上下文的对应关系,也可用"引用溯源"(要求输出带引用,验证引用是否真实存在且内容匹配)。对高风险场景应保留人工抽检。落地时需区分"闭卷幻觉"(训练数据记忆造成的错误)与"开卷幻觉"(RAG/长上下文中的错误),前者用知识性测试集,后者用 Grounding 测试集。

得分点是区分"闭卷幻觉"与"开卷幻觉",并给出对应的验证方法(NLI、LLM-Judge、引用溯源)。能讲清 Grounding 是"输出必须能被上下文支持"这一核心,是这道题的关键。

#
★★

10. Prompt 回归测试,如何构建 Prompt 变更的回归测试集?如何检测 Prompt 修改导致的行为漂移?

Prompt 回归测试集如何构建,如何检测 Prompt 修改导致的行为漂移?

  • Prompt 变更的回归测试集构建(覆盖主流、边界、对抗用例)
  • 行为漂移检测:输出语义、格式、安全性、性能的对比
  • 版本化 Prompt 与基线对比

Prompt 是 LLM 应用的行为核心,改一个词可能改变整体输出,因此需要回归测试集防止"改坏"。回归测试集应覆盖:典型业务请求(主路径)、边界输入(超长、空、特殊字符)、对抗与恶意输入(注入、越狱)、以及各格式要求(JSON、多语言)。执行方式是对新旧 Prompt 在同一输入集上分别推理,对比输出的语义相似度、格式合法性、关键字段、安全行为,并用 LLM-as-Judge 或人工判定是否"行为漂移"(即语义发生不符合预期的变化)。检测行为漂移的关键是"差分对比":同一输入、仅 Prompt 不同,看输出行为是否符合预期变化。Prompt 应版本化(记录版本号、变更内容、变更人),回归测试作为 CI 门禁,任何 Prompt 变更必须通过回归。对高风险变更保留人工抽检,避免纯自动化漏判。

得分点是"Prompt 版本化 + 差分对比 + 行为漂移检测"。面试中强调"不是测 Prompt 对不对,而是测改 Prompt 是否引入行为回归",是理解到位的关键。

#
★★

11. 多模型对比测试(Model Comparison),如何设计公平的比较基准?评估指标的选择和统计显著性?

多模型对比测试(Model Comparison)如何设计公平的比较基准,评估指标如何选择,如何保证统计显著性?

  • 公平基准设计:相同输入集、相同温度/seed、相同提示词、相同评测流程
  • 指标选择:任务相关指标(准确率、BLEU、相关性、忠实度)
  • 统计显著性:配对检验、置信区间、多次运行

多模型对比要保证"公平",核心是控制变量:使用完全相同的输入集、相同的 Prompt/系统提示词、相同的采样参数(温度、top-p、seed)、相同的评测流程与判定器,仅改变被比较的模型本身。否则任何差异都无法归因于模型。指标选择应与任务匹配:分类任务用准确率/F1,生成任务用相关性与忠实度并辅以人工,检索任务用 Recall@K。由于 LLM 输出随机,单次对比不具说服力,需对同一输入多次采样取均值,并用配对样本检验(如 Wilcoxon 符号秩检验)或计算置信区间判断差异是否统计显著,避免把随机波动误判为模型优势。此外要注意评测顺序与缓存(避免前端缓存导致部分模型结果失真)、成本与延迟也应纳入对比(同一质量下更快的模型更优)。最终产出"差异 + 显著性 + 成本"的综合对比报告。

得分点是"控制变量 + 统计显著性 + 综合成本"。能讲出单次对比不可信、需配对检验,以及把成本延迟纳入对比,说明有实际评测经验。

#
★★

12. 模型推理性能测试,延迟、吞吐与批处理大小对线上 SLA 的影响,如何设计压测场景?

模型推理性能测试如何进行,延迟、吞吐与批处理大小对线上 SLA 有何影响,如何设计压测场景?

  • 关键性能指标:P99 延迟、吞吐量(TPS)、并发
  • 批处理大小(Batch Size)对吞吐与延迟的权衡
  • 硬件(GPU 数量、显存)与显存占用

模型推理性能测试关注延迟、吞吐与资源占用。延迟常用 P50/P99 分位衡量,因为平均延迟掩盖长尾;吞吐量(TPS/QPS)衡量单位时间处理请求数;两者与批处理大小相关:增大 batch size 通常提升吞吐(GPU 利用率高)但单请求延迟上升、显存占用上升,因此需权衡"吞吐优先"还是"延迟优先"。压测场景应覆盖:不同并发(低并发稳态、高并发峰值)、不同输入长度(短输入与长输入,长输入消耗更多 token 与显存)、不同 batch 策略(动态 batching vs 固定 batch),并测量在 P99 延迟达标前提下的最大吞吐(即容量上限)。要验证在 SLA(如 P99 < 200ms)约束下能承受的 QPS,并测试模型加载时的冷启动延迟、显存溢出、OOM 恢复。压测需标记被测环境(GPU 型号、显存、模型量化档位),确保结果可复现。

得分点是"P99 而非均值、batch 的吞吐/延迟权衡、SLA 约束下的容量上限"。能讲出动态 batching 与长输入的影响,体现对推理系统性能的理解。

#
★★

13. 模型校准与置信度测试,预测置信度与实际准确率如何校准(校准曲线、ECE),高置信度误判场景如何识别?

如何测试模型的校准与置信度,预测置信度与实际准确率如何校准(校准曲线、ECE),如何识别高置信度误判场景?

  • 校准的定义:预测概率是否反映真实发生频率
  • 校准指标:ECE(Expected Calibration Error)、校准曲线(Reliability Diagram)
  • 高置信度误判(Overconfidence)识别

校准指模型给出的预测概率是否可靠地反映了真实发生概率(如预测 90% 概率的事件,实际确实约 90% 发生)。评估校准用校准曲线(Reliability Diagram):将样本按预测概率分桶,比较每桶的平均预测概率与真实正样本率,若点在 y=x 对角线上则完全校准;ECE 是对所有桶的偏差绝对值按样本量加权求和,值越小越校准。高置信度误判(Overconfidence)指模型给出高概率但实际错误,是安全关键场景(如自动驾驶、医疗、风控)的致命问题,可通过校准曲线观察高概率区间是否出现系统性偏差(预测概率高于实际准确率)来识别。校准方法包括温度缩放(Temperature Scaling,对 logits 除以温度 T)、Platt 缩放、分箱校准等。测试时需区分"校准"与"判别力":判别力看模型能否区分不同类(如 AUC),校准看概率是否可信,两者独立。测试应覆盖校准曲线与 ECE,并重点检查高置信度区间的误判率。

得分点是理解"校准 ≠ 判别力",并给出 ECE 与校准曲线两种度量,以及温度缩放等校准方法。能指出高置信度误判对安全场景的威胁,体现应用敏感度。

#
★★

14. 分布外输入的检测测试,模型遇到训练分布外的输入时如何被识别,OOD 检测器自身的评估方法?

如何测试模型对分布外(OOD)输入的检测,模型遇到训练分布外的输入时如何被识别,如何评估 OOD 检测器自身?

  • OOD 检测的意义:识别模型不确定的输入,避免"不懂装懂"
  • 常见方法:基于 softmax 置信度、距离度量(Mahalanobis)、密度估计、重建误差
  • OOD 检测器评估:ROC-AUC、FPR@TPR、检测阈值

分布外(OOD)输入指与训练分布显著不同的输入,模型对其预测不可靠,因此需要 OOD 检测器识别。常见方法:基于 softmax 概率(低置信度判为 OOD)、基于特征距离(如 Mahalanobis 距离,距离中心远则 OOD)、基于密度估计(如能量函数、高斯混合)、基于生成模型重建误差。OOD 检测器自身的评估需要构造"分布内样本 + 分布外样本"的测试集,衡量:检测器能否把 ID 判为 ID、OOD 判为 OOD,常用指标为 ROC-AUC(区分能力)、FPR@TPR(假设要召回 95% 的 OOD,允许多少误报)、以及最佳阈值下的误报率与漏报率。评估要权衡误报(把正常输入误判为 OOD,导致降级)与漏报(把真实 OOD 放过,导致不可靠输出)。OOD 检测器测试应覆盖多种 OOD 类型(语义漂移、域漂移、噪声),并评估不同阈值下的行为。

得分点是"OOD 检测器本身也要被评估",并给出 ROC-AUC、FPR@TPR 等指标。能讲清误报与漏报的风险权衡,说明理解 OOD 检测的落地难点。

#

15. ML 模型测试中的'确定性'挑战,如何设计可重复的模型测试?随机性(Seed)控制策略?

ML 模型测试中的"确定性"挑战是什么,如何设计可重复的模型测试,随机性(Seed)控制策略有哪些?

  • 模型随机性来源:初始化、数据采样、dropout、GPU 计算的非确定性
  • 可重复性策略:固定 seed、固定数据划分、固定超参
  • CPU/GPU 算子非确定性的影响

ML 模型测试要求可重复,但训练与推理存在随机性:随机初始化、数据随机采样、dropout、以及 GPU 上某些算子(如某些 reduce 运算)的非确定性。设计可重复测试需:固定随机种子(random.seed、numpy seed、torch manual_seed 等)、固定数据划分(用固定 hash 或 seed 划分而非随机)、固定超参数与数据顺序、固定模型与依赖版本。对难以完全确定性的 GPU 计算,可记录运行环境(CUDA 版本、cuDNN、GPU 型号)并设置 determinism 模式(如 torch.use_deterministic_algorithms(True)),但需注意性能可能下降。测试还应记录完整环境指纹(数据版本、代码版本、依赖哈希、seed),以便出现差异时能复现。对 LLM 推理,同样要固定温度与 seed 才能得到可重复输出。

得分点是"分清随机性来源 + 种子/环境双重控制"。能指出 GPU 算子非确定性即使固定 seed 也可能导致差异,并给出"记录环境指纹"的兜底,体现工程经验。

#

16. 特征工程(Feature Engineering)的测试,如何验证特征计算逻辑的正确性和一致性?

特征工程(Feature Engineering)的测试如何进行,如何验证特征计算逻辑的正确性和一致性?

  • 特征计算的正确性验证(与黄金值比对)
  • 训练与推理侧特征计算的一致性(避免训练/推理偏差)
  • 特征缺失、异常值、边界情况的处理

特征工程测试关注两点:计算逻辑正确性,以及训练与推理两侧的一致性。正确性验证:对每个特征编写单元测试,用构造的已知输入与手算的预期值比对(黄金值测试),覆盖边界(空值、负值、超长、除零)、缺失值处理策略、异常值截断。一致性验证:训练时用的特征计算逻辑与线上推理时用的必须完全一致,否则会出现"训练/推理偏差"(Train-Serve Skew)——常见原因是训练脚本与线上服务代码各自实现了一遍特征逻辑,导致规则漂移。解决方法是特征计算逻辑单点维护(同一份代码/规则在训练与推理复用),并做"离线在线一致性对比"(用同一批样本分别跑离线与在线特征,比较输出)。此外应建立特征监控(缺失率、分布、漂移)与特征溯源(记录特征由哪个字段、哪个版本规则计算)。特征验证应纳入 CI,任何特征改动需过回归。

得分点是"训练/推理一致性(Train-Serve Skew)"这一关键痛点,以及"黄金值测试 + 单点维护"。能讲出特征逻辑单点实现避免双份代码漂移,是加分项。

#

17. 模型评估,准确率、召回与 F1?

模型评估中的准确率、召回率与 F1 分别是什么,如何选择与使用?

  • 准确率(Accuracy)、精确率(Precision)、召回率(Recall)、F1 的定义
  • 混淆矩阵(TP/FP/FN/TN)
  • 精确率与召回率的权衡及 F1 调和平均

基于混淆矩阵(TP 真正例、FP 假正例、FN 假负例、TN 真负例):准确率(Accuracy)=(TP+TN)/总数,衡量整体正确比例;精确率(Precision)=TP/(TP+FP),衡量预测为正的样本中真正为正的比例,关注"误报";召回率(Recall)=TP/(TP+FN),衡量真实正样本中被找出的比例,关注"漏报"。F1 是精确率与召回率的调和平均,F1=2·P·R/(P+R),在两者都不偏废时使用。选择上:正负样本严重不平衡时 Accuracy 会失真(如 99% 负样本时全判负也有 99% 准确率),此时更应看 Precision/Recall/F1;对误报代价高的场景(如垃圾邮件误杀)重 Precision,对漏报代价高的场景(如癌症筛查)重 Recall;需要综合平衡时用 F1。此外还有 Macro-F1(各类 F1 平均)与 Micro-F1(按总体 TP/FP 计算)的区别,用于多分类。

这道题考察基础指标。得分点是能讲清混淆矩阵、Precision/Recall 的权衡、不平衡时 Accuracy 失效,以及 F1 作为调和平均的意义。多分类时区分 Macro/Micro-F1 是加分项。

#

18. 多模态模型(图文/语音/视频)的测试要点,跨模态对齐、模态缺失与生成内容的一致性如何验证?

多模态模型(图文/语音/视频)的测试要点有哪些,跨模态对齐、模态缺失与生成内容的一致性如何验证?

  • 多模态测试的复杂性:多种模态输入、跨模态关联
  • 跨模态对齐验证(图文是否匹配、语音语义是否一致)
  • 模态缺失(某模态缺失时模型行为)

多模态模型测试比单模态复杂,因为存在"模态间关联"。测试要点包括:跨模态对齐验证——输入图像与文字描述是否匹配(如给一张车图问"图中是什么",模型能否正确关联)、语音转文字再理解语义是否一致、视频画面与音频/字幕是否同步;对图文模型,验证图像理解与文字理解的一致性,并检测"幻觉性描述"(描述了图中不存在的物体)。模态缺失测试——当图像缺失、音频缺失、某些帧损坏时,模型应能优雅降级而不是崩溃或编造;需验证缺失模态后输出的合理性与错误提示。生成内容一致性——多模态生成(如图文生成、视频生成)需验证文本与图像内容一致、无矛盾(如文字说"红色车"但生成的是蓝色车)。测试需覆盖:单模态输入、多模态输入、缺失模态、模态冲突(图像与文字矛盾时模型如何裁决)、跨模态检索(用文本找图、用图找文)的准确性。因主观性强,常需人工或 LLM-Judge 辅助评估。

得分点是"跨模态对齐"与"模态缺失降级"两个多模态特有维度。能讲出模态冲突如何裁决、以及生成内容跨模态一致性验证,体现对多模态任务的理解。

#

19. 训练数据质量的验证,标签噪声率、类别不平衡与重复样本如何度量,数据问题对评估指标的污染如何识别?

训练数据质量的验证如何进行,标签噪声率、类别不平衡与重复样本如何度量,数据问题对评估指标的污染如何识别?

  • 标签噪声率的度量(人工抽检、置信度、交叉学习)
  • 类别不平衡的度量(类别分布、样本量差异)
  • 重复样本的检测(近似去重、hash 去重)

训练数据质量直接影响模型效果,需从三方面度量。标签噪声率:通过人工抽检一定比例样本核对标签、用模型置信度低但标签确定的样本辅助定位、或用交叉验证(如 Confident Learning)估计噪声比例;噪声过高会降低模型性能并污染评估。类别不平衡:统计各类别样本量、类别比例、最值与中位数差异,严重不平衡会导致模型偏向多数类,需在评估时用加权指标或分层评估。重复样本:用哈希去重(完全重复)与近重复检测(如 MinHash、SimHash,文本相似度去重)衡量重复率;重复样本会放大其对训练的影响,且若重复样本同时出现在训练与测试集会造成"泄漏式虚高",使评估指标失真。识别数据污染的关键是:检查训练集与测试集是否有重叠/近似重复样本、检查指标是否因特定子集异常虚高、通过移除可疑样本后重测指标是否有显著变化来验证。数据质量评估应纳入数据流水线,在训练前自动报警。

得分点是"标签噪声、类别不平衡、重复样本"三者的度量方法,以及"训练/测试重叠造成的泄漏式虚高"这一数据污染识别重点。能讲出重复样本放大影响并污染评估,是加分项。