传统软件测试的假设
传统软件测试建立在三个假设上：
- 输出确定：相同输入给相同输出，测试可以复现
- 正确性可判定：函数返回 42 是对还是错，有明确标准
- 维度单一：代码要么通过测试要么不通过，没有"有点通过"
AI 应用打破了这三个假设。
三个本质难点
难点 1：输出不确定
同一个 Prompt，Claude 今天的回答和明天的回答不一样。temperature=0 能降低随机性，但不能消除它。模型更新后，相同输入的输出会静默变化。
工程含义：
python
# 传统测试
assert calculator(2, 3) == 5 # 跑 100 次，100 次通过
# AI 评测
score1 = judge(llm.invoke("解释 Transformer")) # 4.2/5
score2 = judge(llm.invoke("解释 Transformer")) # 3.8/5
# 相差 0.4 分，正常波动还是问题？解法：多次采样取均值，不依赖单次结果判断质量。通常 3-5 次采样足够，成本 3-5 倍。
难点 2：质量主观
"解释 Transformer 是什么" 有无数种正确答案。面向 10 岁小孩的解释和面向机器学习工程师的解释，都可以是"好答案"，但它们完全不同。
质量的主观性体现在：
arduino
面向不同受众，相同问题有不同的好答案
→ 深度：入门 vs 专业
→ 风格：类比 vs 公式
→ 长度：100字 vs 2000字
面向不同目标，相同回答有不同的分值
→ 目标是"快速理解" → 简短清晰的答案得高分
→ 目标是"深入学习" → 详尽全面的答案得高分解法：在评测前明确场景和受众，把主观判断转化为具体的评分 Rubric，让 LLM-as-Judge 有明确标准可遵循。
难点 3：维度复杂
"AI 回答要好"拆开来是多个相互独立的维度，不能用单一分数表达：
准确性：内容与事实相符，没有幻觉
相关性：回答针对了用户的问题
完整性：覆盖了问题的核心要素
清晰度：表达组织良好，易于理解
有帮助：用户实际上能用上这个回答一个回答可以准确但不完整，或者完整但不清晰。用 1 个分数压缩 5 个维度，信息损失严重。
四种评测方法
没有万能的评测方法，每种都有代价，选择取决于场景和预算。
css
方法 准确性 速度 成本 适用场景
───────────────────────────────────────────────────────
人工评估 最高 慢（天） 高 建立 Baseline，周期性抽样
规则/自动指标 中 快（秒） 低 格式检查、关键词召回、结构验证
LLM-as-Judge 较高 中（分） 中 主流方向，需要防偏见设计
A/B 测试 高 慢（周） 高 生产环境，有真实用户行为数据人工评估
优势： 准确率最高，能捕捉细微的质量差异，是其他方法的 Baseline。
劣势： 慢、贵、难以规模化。一个评测员每天评估 50-100 个样本，1000 个样本需要 2 周。
用法： 为每个关键场景建立"黄金测试集"（约 100 个样本，人工标注），作为其他方法的参照标准。新方法的结果与黄金测试集对比，验证自动评测的可信度。
规则/自动指标
优势： 毫秒级，零成本，适合 CI 集成。
劣势： 覆盖范围有限，无法评估语义质量。BLEU/ROUGE 这类指标测表面词汇重合度，不测意思是否正确。
python
# 好用的自动指标
def check_format(output: str, schema: dict) -> bool:
"""输出格式是否符合 JSON Schema"""
...
def check_length(output: str, min_words: int, max_words: int) -> bool:
"""长度是否在合理范围"""
...
def check_no_hallucination_markers(output: str) -> bool:
"""是否包含已知幻觉标志词（'根据我的训练数据...'）"""
...
# 不好用的自动指标
rouge_score = rouge.compute(predictions=[output], references=[reference])
# ROUGE 对语义等价的不同表达给低分，对语义错误的字面相似给高分格式合规、长度检查、禁止词过滤------这是规则方法的适用范围。语义质量判断交给 LLM-as-Judge。
LLM-as-Judge
优势： 扩展性好，能理解语义，可以评测需要推理才能判断的质量维度。
劣势： 有偏见（后续第 03 篇详细讨论），成本约为人工评估的 1/10 但比规则方法高 100 倍。
python
JUDGE_PROMPT = """评估以下 AI 回答的质量（1-5分）：
维度：
1. 准确性：内容是否事实正确？
2. 相关性：是否针对了用户问题？
3. 清晰度：是否易于理解？
用户问题：{question}
AI 回答：{answer}
以 JSON 格式返回：{{"accuracy": int, "relevance": int, "clarity": int}}"""主要用于自动指标无法处理的语义质量维度。
A/B 测试
优势： 测的是真实用户行为，最接近业务价值。用户点赞/采纳/转化比模型自我评估更可信。
劣势： 需要足够的流量（统计显著性通常需要数百次曝光），周期长，需要在线实验基础设施。
用法： 验证大的功能变更（新模型版本、Prompt 重写）的业务影响，不适合快速迭代阶段的日常评估。
评测方法的组合使用
实践中，三种方法按层次组合，不是二选一：
csharp
开发阶段（快速迭代）：
规则检查（自动） + LLM-as-Judge（采样）
→ 每次提交 CI 跑格式检查，每天跑一次抽样质量评测
发布阶段（质量门控）：
LLM-as-Judge（全量或大样本） + 人工抽查关键用例
→ 质量分高于阈值才发布
生产阶段（持续监控）：
A/B 测试 + 实时规则检查 + 周期性人工抽样
→ 监控质量漂移，发现系统性问题总结
- 确定性陷阱：传统测试的"断言"思维在 AI 评测里行不通，多次采样+统计比单次断言更可靠
- 主观性不是障碍：主观质量可以通过明确场景、受众、评分标准转化为可操作的 Rubric
- 没有单一最优方法：规则快但覆盖窄，人工准但贵，LLM Judge 是性价比最高的主力方法，A/B 测试是最终的商业验证
下一篇进入具体操作：如何把"AI 回答要好"这个模糊目标，拆解成可量化的 L1/L2/L3 三层指标体系。
欢迎访问 PrimeSkills ------ 一个精心策划的 AI Agent 与技能市场，所有内容均经过真实企业级工作流验证。没有噱头，只有真正有效的东西。
更多实用知识和有趣产品，欢迎访问我的个人主页