LLM-as-Judge
使用语言模型作为裁判对AI输出进行评分的范式,已被多项研究证实与人类评估具有较高相关性,但存在位置偏见(倾向于给排在前面的选项更高评分)和奉承偏见(倾向于认可权威来源输出)等问题。
核心事实
时间轴 (近 90 天)
在 FaithCoT-Bench 和 BonaFide 的四个数据集上,VERITAS 的平衡准确率比 LLM-as-Judge 高出 28.4%。
交叉验证的常见做法包括:多模型投票或对比、同一问题多次采样看结果稳定性、用规则或小模型做二次校验、以及人工抽检作为黄金标准
在 LangSmith 评估时,可将追踪数据加入数据集,配合自定义评估器或 LLM-as-Judge 打分。
将LLM-as-Judge视为推理合同意味着要求其输出完整推理链,明确可接受的事实来源、伪造证据的判定以及否决条件,否则评判者的失败模式会继承到基准分数。
若评判者仅阅读Agent的自我报告而非实际产物,完全做错事的运行也可能通过,因此评判者必须基于独立验证的事实推理并拥有否决权。
RAG评估中传统F1-score难以衡量自然语言回答,当前主流做法是LLM-as-Judge,让大模型从忠实度、相关性、完整性等维度打分,但会引入评委模型本身的偏差。
LLM-as-Judge适用于没有唯一正确答案的开放式评估,核心做法是将评估结果结构化为包含分数、理由、是否通过的Pydantic模型。
使用temperature=0和结构化输出可使LLM-as-Judge评审结果稳定可复现。
使用LLM-as-Judge时,裁判与生成Agent最好使用不同模型或不同system prompt,以避免共享偏见导致互相背书
底层schema测试运行只需毫秒级,顶层LLM-as-Judge评估每次不过几美分的API费用
还有 29 条时间轴事件
全部知识事实 (20)
智能体评估的主流方案包括LLM-as-Judge、轨迹匹配和结果验证
90%已验证LLM-as-Judge方法利用GPT-4等大语言模型作为裁判对Agent输出质量进行自动化评分
90%已验证LLM-as-a-Judge方法存在位置偏差、冗长偏差和自我偏好偏差等已知系统性偏差
80%已验证LLM-as-Judge方法与人类专家评分的一致性可达80%以上
80%已验证LLM-as-Judge方法论最早由UC Berkeley等机构在2023年系统提出
80%已验证LLM-as-a-Judge评估范式最早由LMSYS团队在MT-Bench和Chatbot Arena中大规模应用
65%已验证LLM-as-a-judge模式即用一个能力更强的模型来评判另一个模型的输出质量,降低评测成本但引入评判模型自身的偏见问题
65%已验证GPT-4级别的模型作为Judge时,其评判结果与人类专家的一致性超过80%
65%待验证基于规则的确定性评估框架相比LLM-as-Judge方法,在可重复性和可解释性方面具有优势,每条规则都是二元判断,不受评估模型本身偏差的影响
80%待验证一些团队引入LLM-as-Judge方式,用另一个模型评估Agent输出质量以形成自动化质量闭环
60%待验证LLM-as-a-Judge范式最初用于评估生成式AI输出质量,现被应用于简历-职位匹配等复杂推理判断场景
60%待验证LLM评估需同时考量事实准确性、指令遵循度、有害性、有用性和表达质量等多个维度,这些维度之间常存在张力
60%待验证LLM语义级断言的常见实现方式包括基于规则的检查器、嵌入向量余弦相似度阈值(如0.85)、LLM-as-judge评分,以及基于NLI模型验证事实一致性
60%待验证AI Agent评估领域正在经历从人工标注到LLM-as-Judge再到主动对抗性测试的三代技术演进
60%待验证MLflow的评估框架采用了LLM-as-Judge范式,用一个强模型来评判另一个模型的输出
60%待验证AI模型A/B测试业界通常采用基于规则的自动评估、LLM-as-Judge方法以及人工标注的黄金数据集对比三种评估框架
60%待验证在 FaithCoT-Bench 和 BonaFide 的四个数据集上,VERITAS 的平衡准确率比 LLM-as-Judge 高出 28.4%。
50%待验证交叉验证的常见做法包括:多模型投票或对比、同一问题多次采样看结果稳定性、用规则或小模型做二次校验、以及人工抽检作为黄金标准
50%待验证在 LangSmith 评估时,可将追踪数据加入数据集,配合自定义评估器或 LLM-as-Judge 打分。
50%待验证若评判者仅阅读Agent的自我报告而非实际产物,完全做错事的运行也可能通过,因此评判者必须基于独立验证的事实推理并拥有否决权。
50%