直接回答：评测的前提是有一个标注好的评测集：真实业务场景的问题加标准答案（或评分标准），几十到几百条起步，持续补充线上踩坑样本。打分方式按输出形态选：封闭式任务（分类、抽取）用准确率等硬指标；开放式生成用 LLM-as-a-judge——让强模型按 rubric 对答案打分，RAG 场景常用 faithfulness（答案是否忠于资料）、answer relevance、context recall 这组维度；成对比较（A/B 两个版本谁更好）比绝对打分更稳定。
展开解析：落地节奏：开发期跑离线评测，每次改 prompt、换模型、调分块策略都回归，防止"修了一个 case 坏了十个"；LLM-as-a-judge 本身要先用人工标注校准一致率，并注意裁判模型的位置偏置和长度偏置（偏爱长答案）。上线后做线上监控：采样一定比例对话送异步评审，追踪 badcase 率、延迟、token 成本；用户侧埋点（点赞点踩、改写重问率、会话完成率）是最终的业务真相。把线上 badcase 回流进评测集，形成"评测集扩大→发现新问题→修复→回归"的飞轮，这比追求某个 benchmark 分数实在得多。
追问方向：LLM-as-a-judge 有哪些已知偏置？如何给多轮对话评测？RAGAS 这类框架的指标可信吗？
（约 440 字）