LLM 输出评估

把"感觉大概还行"变成"有指标、可对比、能回归"的评估体系。

使用步骤

1. 构建评测集（Golden Set）

• 一组代表性输入 + 期望答案/标注（人工写最可靠）。
• 覆盖正常、边界、易错、对抗场景。
• 少量高质量（如 50~200 条）优于海量低质。

2. 选择评估维度与指标

常用维度及对应量化方式：

• 正确性/精确度：与参考答案的匹配度（自动/人工）。
• 忠实度（faithfulness）：答案是否忠于给定资料，是否有幻觉（RAG 重点）。
• 相关性（relevance）：是否答非所问。
• 格式合规：是否按要求的 JSON/表格/字数。
• 可用自动化指标：ROUGE、BLEU、语义相似度（embedding 余弦）、是否包含关键实体；以及基于 LLM 的 judge 打分。

3. 定义评分方式

• 人工评分：按 1~5 分 + 规则，多人去顶去底取均值，确保标准统一。
• LLM-as-a-judge：用强模型按 rubric 对输出打分，注意校验其倾向与偏差。
• 混合：自动化筛一批，人工复核疑难点。

4. 跑评估并记录基线

评测集规模 / 维度 / 平均得分 / 单项通过率 / 失败样例

一次性记录为基线版本，之后任何改动都要与之对比。

5. 回归与对比

• 新 prompt / 新模型 / 新 RAG 配置上线前，跑同一评测集对比。
• 汇总"变好/变差"的分项，定位原因。
• 把评估集与脚本纳入仓库版本管理，做到可持续回归。

6. 产出报告

结论（是否可上线/是否采纳改动）
各维度得分对比（旧 vs 新）
典型失败样例 + 原因归类
建议的下一步

自查清单

• 评测集是否含边界与易错场景。
• 是否有明确的评分 rubric（避免主观漂移）。
• 是否保存基线版本用于回归。
• 是否同时看"有指标"和"失败样例"而非只看平均分。

参考关联

• RAG 系统的评估见 rag-builder；优化 prompt 后用此技能验证见 prompt-optimizer。