平安科技测开二面：怎么判断 AI 的结果是否正确

《面试题目》

1. 自我介绍。
2. AI 相关的内容（围绕你做过的 AI 项目展开）。
3. 怎么判断 AI 的结果是否正确？

原帖未记录更多题目与后续流程。

《参考解析》

「怎么判断 AI 的结果是否正确」是这类面试的分水岭

传统测试的核心是断言：给定输入，输出是否等于期望值。AI 系统的输出是自然语言或概率分布，没有唯一正确答案，所以判断方法要按「有没有标准答案」分两类来讲——能主动做这个分类，答案的层次就出来了。

有标准答案时：把 AI 当普通被测系统

如果任务是分类、抽取、意图识别这类判别式任务，输出是可枚举的，那就老老实实建评测集：

• 金标准数据集（golden set）：从真实业务数据里抽一批样本，人工标注正确答案；规模不用很大（几百到几千条），但要覆盖各类边界（长文本、空输入、多意图、脏数据、专业术语）。这个集合要版本化维护，每次换模型/改 prompt 都跑一遍做回归。
• 指标：准确率、精确率、召回率、F1、以及业务口径的指标（首答解决率、需转人工的比例）。多分类要看混淆矩阵，找出模型系统性犯错的类别。
• 断言要写到字段级：结构化输出（JSON）要校验 schema、必填字段、枚举值、数值范围；抽取类任务按字段做逐项比对，而不是整体判对错。

没有标准答案时：四层校验叠加

生成式任务（客服回答、文案、总结）没有唯一答案，靠单一方法不可靠，实务里是多层叠加、层层收窄：

1. 规则与格式校验（最先做、成本最低）：长度、敏感词、必填要素（比如客服回答必须包含金额和期限）、是否符合业务口径、是否泄露不该出现的信息。JSON 输出就直接校验 schema。这一层能过滤掉大部分低质输出。
2. 事实一致性 / 溯源校验：RAG 场景最好的抓手是引用——答案里的每个事实能不能在召回的原文片段里找到依据；找不到就标记为「可能幻觉」。也可以做自洽性检查（同一问题多采样几次，答案是否稳定）和交叉验证（换一种问法问同一个事实，答案是否一致）。
3. 模型评审（LLM-as-a-judge）：用另一个模型按 rubric 打分（相关性、完整性、是否有害、是否答非所问）。要注意它自身的偏差——位置偏差（偏好第一个选项）、长度偏差（偏好长答案）、自我偏好（偏好同族模型的输出），所以要做成对比较 + 位置交换，并定期用人工标注校准它和人的一致率（比如 Kappa 系数）。
4. 人工抽检与线上回流：按置信度分层抽样（低置信度全看、高置信度抽看），把线上 badcase 沉淀成新的评测样本，形成「发现问题 → 进评测集 → 修复后再跑」的闭环。原帖这类岗位的面试官往往最想听到这一条，因为它证明你理解评测集是长期资产。

AI 项目的测试还要关注什么

除了「答案对不对」，AI 系统还有一整类非功能问题值得主动提：

• 稳定性与确定性：同一输入多次调用结果漂移多大（temperature、模型版本、路由到不同渠道都会影响）；模型版本升级要有回归基线和灰度。
• 性能与成本：首 token 延迟、整段响应时间、并发下的排队情况、token 消耗与单次成本——这直接影响能不能上线。
• 安全与合规：提示注入（用户诱导模型越过系统指令）、越权（RAG 检索到别的租户/无权限的文档）、有害内容、隐私数据外泄。这些要用攻击性测试用例集去测，不能只测正常路径。
• 降级与兜底：模型超时/限流/服务不可用时，系统是否走规则兜底或转人工；这条在金融类业务里是硬要求。

自我介绍与「AI 相关内容」怎么准备

这两题通常会串成一条线：自我介绍里挑一个 AI 相关项目，然后面试官顺着问。项目介绍按固定结构准备——业务问题 → 系统形态（RAG / Agent / 判别模型）→ 你负责的部分（数据、评测、平台、还是模型）→ 评测方法与指标 → 结果与踩过的坑。做测开的同学最好突出评测与质量保障这一段：评测集怎么建的、指标怎么定的、发现了哪些模型问题、怎么推动修复、修复后指标变化多少。这些数字比任何技术名词都有说服力。