小米 SOC 测开二面：知识库测试、幻觉治理与 AI 全流程测试设想

《面试题目》

1. 自我介绍
2. 学没学过 C 语言和操作系统？
3. 密码算法了解吗？
4. 研究生研究方向是什么？
5. 杭研院的情况
6. 实习项目如何设计测试用例？用例是如何分布的？
7. 知识库用了什么工具和测试思路？如何解决幻觉问题？如何更新？
8. 测试用例中 AI 的覆盖率是多少？
9. 如果让你写一个 AI 工具，完全用 AI 从端到端来进行一个版本的测试，你会怎么做？
10. 最大的难点在哪里？

《参考解析》

AI 时代的测试用例设计，主线仍是「等价类 + 边界值 + 场景法」，但要多两个维度。 第一个是不确定性维度：大模型输出不固定，所以判定标准要从「等于期望值」改成「满足约束」（格式合法、关键事实包含、不含禁用内容、引用可溯源），并引入多次采样的稳定性指标（同一输入跑 N 次的一致率）。第二个是评测集维度：从真实流量里采样做回归集，按题型/难度/业务线分层，控制样本分布避免过拟合，并保留一部分不参与调优的留出集。用例分布上，通常金字塔底层是单元与接口用例（确定性强、跑得快、占比最大），中间是集成与链路用例，顶层才是端到端与人工评审；AI 场景再加一类「评测集回归」和「对抗/越权用例」。

知识库的测试思路要覆盖「数据进、检索准、生成对、更新及时」四段。 入库：多格式解析（PDF/DOCX/Excel、扫描件、表格跨页）是否正确、切片是否切断语义、元信息（页码、文件名、权限标签）是否完整；检索：召回率与准确率、TopK 变化对结果的影响、权限过滤是否生效（越权要专门造用例）、专有名词与近似问法能否命中；生成：是否严格依据证据、是否拒答、引用是否可点回原文；更新：文档修改/删除后索引是否重建、缓存是否失效、旧版本答案会不会残留。幻觉的测试 case 设计常见五类：库里根本没有的问题（应拒答）、库里有但被改写/否定的问题（应忠于证据）、多个文档冲突的问题（应说明冲突而非硬选）、需要多跳推理的问题、以及带诱导的前提假设问题。指标上除了准确率还要看**「有依据回答率」和「错误自信率」**，后者最能体现幻觉治理水平。

用 AI 端到端跑一个版本的测试，方案可以按「四层自动化」来组织。 ① 需求与用例生成：把需求文档、接口文档、历史缺陷喂给模型生成用例草稿，人工只做评审与补充（这是当前最成熟、收益最确定的一环）；② 执行自动化：UI 层用支持自然语言指令的浏览器/移动端自动化（自愈定位、失败自动截图与归因），接口层用模型按 OpenAPI 自动生成参数组合与断言；③ 结果判定：用模型做语义断言（截图与需求比对、日志与预期比对），但必须限定在「可验证的判据」内，涉及金额、权限、数据一致性的断言仍用确定性脚本；④ 缺陷归因与回归：失败自动分类（环境、用例、真 bug、模型抖动）、聚类去重、并把确认过的缺陷转成永久回归用例。最大难点有三个：一是判据的可信度——模型判定本身会错，必须用双判、抽样人工复核和「只做加严、不做放宽」的策略兜底；二是非确定性带来的稳定性问题，同一版本重复跑结果不同，难以作为发布门；三是覆盖面与成本的平衡，AI 探索式测试覆盖面好但成本高、不可复现，所以它更适合做补充通道（探索、变异、异常场景挖掘），而不是替代确定性的主干回归。回答时先讲清「哪些交给 AI、哪些不能交」，比堆工具名更能体现判据意识。