客服自动回复质量评估方案
团队上线了"客服自动回复"功能，需要评估 20 条回复的质量。本项目将模糊的业务诉求转化为 4 个可自动量化的指标，并用 LLM-as-a-Judge（DeepSeek）作为主引擎逐条打分， 最终产出评估报告（综合分、各指标分布、最差 3 条 case 分析）。
核心结论：20 条回复综合得分 73.4/100（合格 C）。最大共性问题不是"说错"，而是 "正确但被动/推诿"——把本该由客服解决的事推给用户（"联系客服""去看详情页"）， 缺少"我帮您"式的主动服务。
注：评估主引擎为 LLM，即便
temperature=0，不同模型版本/时段下个别 case 分数仍可能有 ±5 分 的轻微波动，综合分与等级稳定在"合格 C"附近。下方数字为一次代表性运行的产物，最新结果以results/evaluation_report.json为准。
业务方诉求 "准确、有用、语气好、不能瞎编" 拆解为 4 个可量化指标，每项 1-5 分整数。
打分制式与权重见下表。
| 指标 | 业务诉求 | 权重 | 优先级层级 | 量化方式（rubric 锚点） |
|---|---|---|---|---|
| 准确度 accuracy | 准确 | 0.25 | 🟥 底线(floor) | 5=完全针对问题且事实无误；3=方向正确但泛化；1=答非所问/事实错误 |
| 有用度 helpfulness | 有用 | 0.35 | 🟧 核心(core) | 5=主动帮用户解决；4=清晰可执行；3=通用说明需自行操作；2=大量推诿；1=毫无帮助 |
| 无幻觉 faithfulness | 不能瞎编 | 0.20 | 🟥 底线(floor) | 5=无编造+合理留白；3=未经核实的具体断言；1=虚构关键事实 |
| 语气态度 tone | 语气好 | 0.20 | 🟨 加分(enhancer) | 5=礼貌且共情到位；3=礼貌但模板化；1=冷漠/态度不当 |
综合分 = Σ(scoreᵢ × weightᵢ) / 5 × 100 → 0-100。
- "准确"=准确度：回复与问题相关且事实无误。量化锚点：是否答非所问、是否有事实错误。
- "有用"=有用度：是否真正解决问题、提供可执行方案，而非把责任推给用户。量化锚点：是否含 "我帮您"式主动服务 vs "联系客服/看详情页"式推诿。这是区分好坏回复最关键的维度 （人工标注也印证：20 条里 16 条的扣分点都是"被动推诿"）。
- "语气好"=语气：礼貌 + 同理心，尤其在用户不满时情绪安抚是否到位。
- "不瞎编"=无幻觉：是否编造订单号、具体政策、商品参数等不存在信息。
- 指标优先级：
- 底线层（不过线=严重事故）：准确度、无幻觉 —— 事实错误/虚构是不可接受的。
- 核心层（最能区分好坏）：有用度 —— 权重最高(0.35)。
- 加分层：语气 —— 锦上添花，权重最低(0.20)。
这是业界评估开放式回复质量的标准方法（参考 LLM-as-a-Judge, Zheng et al. 2023、MT-Bench）。 让 DeepSeek 扮演资深客服质量评审，按统一 rubric 对每条回复打分并给出理由。
关键设计（防数据泄露）：判官模型只看到 用户问题 + 自动回复 + 参考回复(human_reference)，
从来看不到 annotator_notes（人工标注的定性分析）。因此用 annotator_notes 做一致性校验是
合法的样本外检验，不存在"在测试集上调参"的作弊。
无 API Key 时自动降级到纯算法方案，基于 TF-IDF 余弦相似度与通用语言学特征：
- 用
auto_reply与human_reference的相似度估计有用度； - 用
auto_reply与user_question的相似度估计准确度； - 用通用对冲/礼貌词检测无幻觉与语气。
不依赖任何针对本题答案的硬编码关键词，阈值固定，仅作粗粒度降级。
把人工标注的定性判断映射成"好/中/差"三档，与 LLM 打分的三档对比：
- 方向一致率（差 ≤ 1 档）：90%（多次运行稳定在 85%-90%）—— 说明 LLM 判官与人工判断方向一致，方法可信。
- 少数分歧主要源于：自动回复作为"无状态自动应答"，人工标注有时会以"真人客服能做到"为标杆 要求主动服务，而 LLM 判官相对宽容（详见局限性）。
综合得分：73.4 / 100（合格 C）
样本数：20
各指标平均分(1-5)：
准确度 3.8 （底线达标）
有用度 3.0 ⚠️ 最大短板（分布偏左，存在较多"被动推诿"）
无幻觉 4.95 （接近满分，无虚构）
语气 3.4 （礼貌但偏模板化）
等级分布：优秀4 / 良好3 / 合格7 / 较差6 / 很差0
最差 3 条：case_13(面膜成分)、case_01(放错快递柜)、case_09(退货邮费)
最佳 3 条：case_07(异地登录)、case_18(扫地机故障)、case_08(手机壳材质)
完整报告见 results/evaluation_report.md，含分布图
metric_distribution.png、
grade_distribution.png。
LLM 判官对"事实正确但不够主动"的回复，有时给 3 分（中等）而非更低。人工标注认为这类应判更差。 改进：可在 rubric 中加入更强的"推诿惩罚"锚点，或引入"主动服务度"作为独立维度。
人工标注常以"真人客服能查订单/主动跟进"为标杆，但自动回复无法访问用户订单系统。 部分 case（如 case_02"这个充电宝能上飞机吗"）判官给了中等分，人工却判差——因为人工能查具体商品 参数。改进：应分"自动回复"与"人工回复"两套标准；或将"需要查订单的查询"路由到人工而非自动回复。
真实客服是多轮的。本评估只看单条回复，无法发现"追问后答不上""前后矛盾"等问题。 改进：扩展为多轮对话评估集。
reference-based judging 依赖人工参考回复质量。若参考回复本身不优，会拉偏判官尺度。 改进：每个 case 提供 2-3 条人工参考 + 标注一致性。
temperature=0 仍有轻微波动；调用 20 条需数十秒+少量 token 成本。 改进：关键 case 做多 judge 投票(ensemble)降低方差；大批量时用缓存。
- 模糊指代类（"那个""那款"）：判官不知指代何物，难以判"准不准"；
- 强情绪类：语气分易受判官自身倾向影响；
- 需要外部知识类（具体政策/物流时效）：无 grounding 数据时只能判"是否编造"，难判"是否最新准确"。
- Python 3.10+
- 依赖：
requests、matplotlib、scikit-learn（离线降级用）
pip install -r requirements.txt# 方式一：LLM-as-a-Judge（推荐，需配置 API Key）
# 支持 DeepSeek 或 智谱GLM（OpenAI 兼容接口）
set DEEPSEEK_API_KEY=sk-xxxx # Windows
python run.py --validate
# 方式二：离线算法模式（无需任何 Key）
python run.py --algo --validate运行后在 results/ 下生成：
evaluation_report.json— 结构化完整结果evaluation_report.md— 可读报告（含最差 3 条 case 分析）metric_distribution.png— 各指标平均分图grade_distribution.png— 综合分等级分布图
--validate 会额外输出与人工标注的一致性校验表。
auto-reply-eval/
├── task/ # 官方提供（输入数据，勿改）
│ ├── task3_auto_replies.json # 20 条待评自动回复
│ ├── task3_human_ref.json # 人工参考回复 + 标注分析
│ └── task3_eval_criteria.md # 业务方原始诉求
├── src/
│ ├── metrics.py # 指标定义 + 权重 + rubric（唯一事实来源）
│ ├── llm_client.py # LLM-as-a-Judge 引擎(DeepSeek/GLM，OpenAI 兼容)
│ ├── algo_scorer.py # 离线算法评分器(TF-IDF，降级用)
│ ├── pipeline.py # 评估流水线(读数据→打分→汇总)
│ ├── reporter.py # 报告生成(Markdown + 图表)
│ └── validate.py # 与人工标注盲测校验
├── results/ # 运行产物
├── run.py # CLI 入口
├── requirements.txt
└── README.md
本项目开发过程中使用了 AI 工具辅助：
- 编码助手（glm-5.2）：用于项目脚手架、prompt 构造、报告模板等工程代码生成与调试。
- 评估引擎（DeepSeek API）：作为 LLM-as-a-Judge 主引擎，对 20 条回复逐条打分。 这是"评估自动化"的核心——把需要人工判断的主观质量，用 AI 自动量化。
- 设计决策：指标拆解、rubric 锚点、防数据泄露设计、一致性校验方法均由人工主导， AI 辅助实现。关键设计（判官不接触 annotator_notes）保证了校验的有效性。
说明：开发中曾尝试过基于关键词的规则评分器，发现会导致"在标注数据上调参"的数据泄露问题， 已废弃并改用 LLM-as-a-Judge + 算法降级的方案，确保评估方法本身是自动化且可信的。