Day 70 · 大规模 LLM 评审:校准、一致性、成本
SupportPilot 每天三千张工单,想每天看一次回复质量,只能靠 LLM 评审。规模上来以后,Day 32 那套校准不够用了:校准集里差评样本太少、校正后的通过率自己也有误差、三个评审投票照样会一起犯错、评审模型一升级就悄悄变宽松。今天用模拟数据把这些问题一个个跑出来,写一个带区间的校正、投票分流和漂移报警模块,再算清楚评审的钱和人工各花多少。
Day 50 · 评测体系:100 条测试集、LLM-judge、轨迹评测,跑出第一份分数
把 Day 43 的验收指标变成能自动跑的评测:36 个场景、100 种客户说法,按场景拆 dev/test;规则检查管分类、工具轨迹、退款闸门、引用、事实和禁语,LLM 评审只判"有没有依据"和"有没有解决问题"两件事,再加成本和延迟。跑出第一份基线报告,并学会检查评审本身准不准。
Day 32 · LLM-as-judge:写评分 prompt、与人工对齐、偏差校准
代码断言查不了「回复有没有讲清楚政策」「有没有编造」。今天写一个只判一件事、只给 pass/fail 的 LLM 评分器,用你的人工标注去校准它:算 TPR、TNR 和 Cohen kappa,而不是只看准确率;再用这两个数修正评分器报出来的通过率,最后过一遍位置、冗长、自我偏好这些偏差。
Day 19 · RAG 怎么评估:召回率、MRR、忠实度,建第一份检索测试集
昨天的对比只有 6 个问题,结论全凭感觉。今天建一份 30 条的评估集,分检索和生成两层打分:检索看 hit@1、recall@k、MRR,生成用大模型当裁判看忠实、完整、该拒答时拒答。然后用它回答「切块多大、k 取几、rerank 值不值」。