面经策

如何进行 AI 应用的测试和效果评估？ ​

  • 标签：通用、编程导航

🏛 业务架构师 ​

AI 应用的测试难点：输出是概率性的——同一输入可有多个"好答案"，传统断言（assertEquals）失效。我的评估体系按三层金字塔建：

1. 单元/组件层（确定性）

  • 工具函数、prompt 模板渲染、解析器：传统单测照写——AI 应用里依然有 60% 是普通代码（流程、鉴权、存储），别放弃这部分测试纪律；
  • 结构化输出解析：构造典型/畸形模型输出测解析与兜底。

2. 链路层（集成测试）

  • 用打桩的模型响应（固定 mock）测"RAG 检索→组装→输出→前端事件"的流程正确性——分离"流程对不对"与"答案好不好"两个问题；
  • 关键链路的金丝雀检查：每次部署跑一组必过用例（安全底线问题：不能输出违禁内容、不能泄露 system prompt）。

3. 效果层（AI 特有的评估）——核心是评测集 + 指标 + 自动化：

  • 建评测集：收集真实用户问题（几百条起步），标注标准答案/评分要点——评测集是 AI 产品最重要的资产，没有之一：它让"改了 prompt 有没有变好"从吵架变成看数；
  • 量化指标：
    • 检索类（RAG）：召回率、忠实度（答案是否忠于检索内容，RAGAS 可自动评）、引用准确率；
    • 生成类：相关性、准确性（LLM-as-Judge：用强模型按评分标准打分，与人工抽检校准）；
    • 业务指标：点踩率、转人工率、任务完成率——最终以业务指标为锚；
  • 回归流程：prompt/模型/检索策略任何变更 → 自动跑评测集 → 指标下降禁止上线（效果回归门禁，等同传统 CI）。

持续迭代：线上 badcase 回流评测集（用户点踩的问题变成新用例）——评测集随产品成长，越用越准。

一句话：AI 应用的质量体系 = 普通工程测试 + "评测集驱动的效果回归"——后者是把炼丹变成工程的那把尺子。

🏗 系统架构师 ​

AI 应用的测试与传统软件差异巨大：输出非确定、质量多维、链路长（提示词→检索→模型→工具）。我按"分层测试 + 评估指标 + 持续回归"搭体系：

1. 分层测试：

  • 单元层：确定性组件常规测试——提示词模板渲染、结构化输出解析器、工具函数（输入输出明确）、RAG 管道各组件；
  • 组件评估层（核心）：
    • 检索评估：标注"问题 → 应命中文档"数据集，指标 Recall@K、MRR、NDCG——RAG 效果问题 80% 在检索层，独立评估才能定位；
    • 生成评估：LLM-as-Judge（用强模型按 rubric 打分：准确性/完整性/格式遵循/有无幻觉，与标准答案对比）+ 抽样人工复核校准 Judge 的一致性；
    • Agent 评估：端到端任务成功率（能否正确调用工具、多步完成）、工具选择准确率（该不该调、调哪个）、轨迹合理性；
  • 安全测试：提示词注入攻击样本、越权访问、敏感输出拦截。

2. 评估集建设（基建）：从真实日志采样 + 人工构造边界 case，50~200 条起步，覆盖典型场景与已知失败模式；每条含输入、期望要点、评分标准。

**3. 持续回归（工程闭环）：

  • 每次提示词/模型/检索参数变更跑全量评估集，分数对比防退化——没有评测集的提示词迭代等于裸奔；
  • 线上指标：用户反馈（点赞/点踩/重新生成率）、任务完成率、幻觉举报率，形成"线上发现 → 进评估集 → 修复验证"的飞轮；
  • A/B 实验：新版本提示词/模型灰度对比。

心法：AI 测试从"断言相等"转向"统计意义上达标"——接受非确定，用量化评估与回归基线管理质量。

💻 全栈开发专家 ​

AI 应用的测试我分功能、效果、稳定性、安全四层——前三层和传统测试不一样的地方是"没有确定性断言"，要用评估集和统计指标替代 assertTrue。

1. 功能测试（确定性部分）：SSE 流式连通、工具调用触发、会话隔离、记忆持久化——这些是普通工程问题，照常写单测/集成测试（WireMock 挡住 LLM 依赖）。

2. 效果评估（AI 特有，核心）：

text
a. 黄金集评估：人工标注 50~200 条（问题 → 期望要点/应命中文档）
   - RAG 检索指标：recall@5 / precision / MRR
   - 回答质量：要点覆盖率（LLM-as-judge 打分）+ faithfulness（答案是否忠于检索内容）
b. RAGAS 类框架：faithfulness / answer_relevancy / context_precision 自动化打分
c. 回归机制：prompt/模型/切分参数任何变更 → 跑评估集对比，防"改好一处退化三处"

3. 稳定性测试：mock 上游超时/429/返回乱码验证降级链路；并发压测（重点看流式连接数、线程池、token 预算并发扣减正确性）。

4. 安全测试：prompt 注入（"忽略之前指令"类攻击样本集）、越权（诱导工具查他人数据——ToolContext 是否真的防住了）、敏感词。

持续评估（上线后）：用户点赞/点踩埋点 → 低分会话进人工复核队列 → 坏 case 沉淀回评估集——评估集是活的资产，不是一次性交付物。这套闭环让我优化 RAG 时每次都有数据背书。