LLM Evaluation Frameworks Compared: How to Actually Measure What Your Model Does

对比LLM评估框架：如何真正衡量你的模型表现 - MachineLearningMastery.com

对比LLM评估框架：如何真正衡量你的模型表现

By

Shittu Olumide

on

2026年7月14日

in

语言模型

0

分享

发布

在本文中，你将学习如何使用三个主流开源框架（RAGAS、DeepEval 和 Promptfoo）来评估 LLM 应用，以及为什么它们都依赖的“LLM 作为裁判”机制存在可衡量的偏见，你需要主动设计以规避这些偏见。

我们将涵盖的主题包括：

• RAGAS、DeepEval 和 Promptfoo 在目的上的差异，以及何时使用每个框架，包括有经验的团队通常选择的组合。

• 如何实现一个忠实度检查和一个带有 CI 门控的质量评估，并提供可立即运行的代码示例。

• 什么是位置偏见、自我偏好偏见和冗长偏见，如何通过审计工具检测它们，以及如何在生产环境中缓解它们。

内容很多，我们直接进入正题。

引言

你看到几个输出后就上线了一个 LLM 功能，并决定看起来不错。三周后，一个提示的微调悄无声息地破坏了某些未被测试的功能，直到用户投诉才被注意到。这是 LLM 应用程序的默认失败模式，与典型的软件错误不同。传统代码会因堆栈跟踪而失败，而 LLM 输出的失败方式是“自信且看似合理地错误”，这正是快速手动检查无法发现的失败类型。

2026 年，有三个开源工具主导了这个问题的实践方面：Promptfoo、DeepEval 和 RAGAS。每个工具都针对不同类型的任务构建，而不是争夺同一份工作。在它们之上的是生产监控平台，如 LangSmith 和 Braintrust，它们在离线评估之后接续工作。这些工具中没有一个能全面胜出；大多数成熟的 GenAI QA 程序会并行运行其中两个工具：一个轻量级框架用于阻止不良部署，以及一个平台用于持续监控和人工审查。

本文将比较真正重要的框架，逐步演示两个最常见的评估任务的经过测试的代码，并涵盖大多数比较文章完全跳过的部分：即“LLM 作为裁判”这一机制——几乎所有框架都依赖的机制——存在可衡量且已发布的偏见，你需要围绕这些偏见进行设计，而不仅仅是信任它们。

“评估 LLM”实际上意味着什么

在比较工具之前，先区分人们在说“LLM 评估”时混淆的三个事物是有帮助的。在这里选择错误的类别是团队最容易犯的错误。

• 模型基准测试：在标准化的学术任务（如 MMLU、GSM8K 和 HumanEval）上比较模型的原始能力。lm-evaluation-harness 是这里的标准，当需求是标准化的学术基准时，几乎没有真正的替代品。如果你在 GPT-5 和 Claude 之间为一个新项目做选择，这就是你想要的类别，但它几乎不会告诉你你的特定应用是否有效。

• 应用评估：提出一个更狭窄、更有用的问题：你的 RAG 管道、聊天机器人或代理是否在你的数据和提示下生成正确、有依据且安全的输出？这就是 RAGAS、DeepEval 和 Promptfoo 所处的领域，也是本文大部分时间讨论的内容。

• 生产监控在部署后跟踪实时流量，能够发现离线测试集从未预料到的回归和偏移。这是LangSmith、Braintrust和Arize Phoenix的领域。

大多数询问“应该使用哪个评估框架”的人实际上需要的是第二类工具，通常与第三类工具结合使用。本文其余部分将聚焦于这一领域。

框架背后的指标

在进行框架对比之前，了解实际被评估的内容很有必要，因为以下所有工具都实现了相同的一组核心指标。

• 忠实性（或可信度）检查答案是否仅包含被检索上下文支持的主张——这是检测RAG幻觉的核心机制。

• 上下文精确率和召回率检查检索是否获取了正确的文档，且仅获取了正确的文档，即使在生成之前。

• 答案相关性检查响应是否确实解决了所提出的问题，与答案是否基于事实无关。

• G-Eval由刘等人引入，通过结合思维链提示和表单填写引导大语言模型评委按照明确的评分标准进行评估，其与人类偏好的一致性优于简单的“1-10评分”提示。除此之外，大多数框架会添加针对毒性、偏见和PII泄露的任务特定检查。

框架之间真正的差异不在于指标的新颖性，它们大多实现相同的核心理念。关键差异在于工作流适配性：指标如何被触发、结果流向何处，以及是阻止部署还是仅生成报告。

RAGAS vs. DeepEval vs. Promptfoo，直接对比

RAGAS具有研究支持，其忠实性、上下文精确率和召回率等指标采用学术级方法论，但其范围仅限于检索和生成评分，没有内置生产监控或协作层。当你的架构以检索为主且需要具有论文支持的指标定义（而非仅依赖供应商的内部启发式方法）时选择它。

• DeepEval是原生Python且基于pytest的工具，包含14多个指标，涵盖幻觉、偏见、毒性及RAG特定检查——专门设计为CI/CD质量门禁，可阻止部署。当评估需要集成到现有测试套件而非作为需要人工运行的独立离线报告时选择它。

• Promptfoo以CLI优先且基于YAML配置，最擅长多模型提示比较和对抗性红队测试，其安全测试套件包含500多个内置攻击向量。当需要跨多个模型进行提示工程迭代，或实际需求是红队测试和安全测试时选择它。

最重要的定位是：DeepEval和RAGAS并非真正竞争对手。DeepEval覆盖广泛的LLM应用测试，RAGAS专门针对RAG，许多生产团队会同时运行两者——RAGAS负责评估检索相关维度，DeepEval处理其余所有内容，且两者共享同一CI流水线。

| 类别 | RAGAS | DeepEval | Promptfoo | |------|-------|----------|-----------| | 最适合 | RAG特定评分 | CI/CD质量门禁 | 多模型比较、红队测试 | | 集成方式 | Python库 | pytest原生 | YAML + CLI | | 最强指标集 | 忠实性、上下文精确率/召回率 | 14+指标（含偏见、毒性） | 安全/攻击向量（500+） | | 生产监控 | 否 | 与DeepEval搭配使用（更广覆盖） | 无 |

RAGAS（RAG专用深度）

用于提示侧测试

代码解析：通过可信度检查捕捉幻觉

以下是RAGAS可信度指标的实现机制演示：将答案分解为原子声明，然后逐一核对每个声明与检索到的上下文之间的关联性。如果某个声明在上下文中找不到支持依据，就属于幻觉——这种失败模式通常会被快速的人工阅读遗漏，因为缺乏支持的细节往往听起来完全合理。

faithfulness_check.py # 依赖条件：仅需Python标准库（re） # 运行方式：python faithfulness_check.py # # 注意：这演示了RAGAS真实可信度指标所采用的检查机制，该机制通过LLM判断实现。下面的关键词重叠检查是该LLM声明验证功能的简化版离线测试替代方案——实际生产环境应替换为RAGAS的真实指标 import re def decompose_claims(answer: str) -> list[str]: """将答案拆分为可独立验证的原子声明""" sentences = re.split(r'(?<=[.!?])\s+', answer.strip()) return [s.strip() for s in sentences if s.strip()] def claim_supported_by_context(claim: str, context: str) -> bool: """检查声明是否在检索到的上下文中存在词汇支持。RAGAS通过LLM判断实现此功能；以下重叠检查以确定性方式演示相同的支持/不支持判断""" claim_words = set(re.findall(r'\b[a-zA-Z]{4,}\b', claim.lower())) context_words = set(re.findall(r'\b[a-zA-Z]{4,}\b', context.lower())) if not claim_words: return True overlap = len(claim_words & context_words) / len(claim_words) return overlap >= 0.5 def compute_faithfulness(answer: str, context: str) -> dict: """可信度得分=答案中被上下文支持的声明占比。这与RAGAS真实指标定义一致：支持声明数/总声明数""" claims = decompose_claims(answer) supported = [c for c in claims if claim_supported_by_context(c, context)] unsupported = [c for c in claims if c not in supported] score = len(supported) / len(claims) if claims else 1.0 return { "score": round(score, 3), "total_claims": len(claims), "unsupported_claims": unsupported, } if __name__ == "__main__": context = "Abuja于1991年成为尼日利亚首都，取代拉各斯成为政府所在地。" # 案例1：完全基于上下文的答案——每个声明均可追溯至上下文 grounded_answer = "尼日利亚的首都是阿布贾。它于1991年成为首都。" result_1 = compute_faithfulness(grounded_answer, context) print("基于上下文的答案:") print(f" 可信度得分: {result_1['score']}") print(f" 未支持声明: {result_1['unsupported_claims']}\n") # 案例2：模型添加了上下文未提及但看似合理的细节 hallucinated_answer = ( "尼日利亚的首都是阿布贾。它于1991年成为首都。 " "该城市人口超过300万。" ) result_2 = compute_faithfulness(hallucinated_answer, context) print("包含幻觉细节的答案:") print(f" 可信度得分: {result_2['score']}") print(f" 未支持声明: {result_2['unsupported_claims']}")

运行：python faithfulness_check.py

#

注意：这演示了RAGAS实际Faithfulness指标所采用的忠实性检查MECHANISM，该机制通过LLM judge实现。下面的关键词重叠检查是用于替代LLM基于的主张验证的简化版，完全离线可测试。在生产环境中请使用RAGAS的实际指标。

import

re

def

decompose_claims

(

answer

:

str

)

->

list

[

]

""

"将答案拆分为可独立验证的原子声明。"

sentences

=

.

split

r

'(?<=[.!?])\s+'

,

strip

return

s

for

if

claim_supported_by_context

claim

context

bool

"

检查声明是否在检索到的上下文中具有词汇支持。

RAGAS通过LLM judge实现这一点；下面的重叠检查以确定性方式演示了相同的支持/不支持决策。

claim_words

set

findall

'\b[a-zA-Z]{4,}\b'

lower

context_words

not

True

overlap

len

&

/

=

0.5

compute_faithfulness

dict

Faithfulness分数 = 答案中受上下文支持的声明占比。

这与RAGAS的实际指标定义一致：支持的声明数 / 总声明数。

claims

supported

c

unsupported

score

else

1.0

{

"score"

round

"total_claims"

"unsupported_claims"

}

__name__

==

"__main__"

"1991年，阿布贾成为尼日利亚的首都，取代拉各斯成为政府所在地。"

案例1：完全基于上下文的答案——每个声明都可以追溯到上下文

grounded_answer

"尼日利亚的首都是阿布贾。它于1991年成为首都。"

result_1

print

"基于上下文的答案："

f

" 忠实性分数：{result_1['score']}"

" 未支持的声明：{result_1['unsupported_claims']}\n"

案例2：模型添加了一个上下文从未提及的看似合理的细节

hallucinated_answer

"尼日利亚的首都是阿布贾。它于1991年成为首都。 "

"该城市人口超过300万。"

result_2

"包含幻觉细节的答案："

" 忠实性分数：{result_2['score']}"

" 未支持的声明：{result_2['unsupported_claims']}"

如何运行（无需依赖项）：

python faithfulness_check.py

python

faithfulness_check

py

输出：

基于上下文的答案： 忠实性分数：1.0 未支持的声明：[] 包含幻觉细节的答案： 忠实性分数：0.667 未支持的声明：['该城市人口超过300万。']

基于上下文的

忠实性

包含幻觉细节

0.667

'该城市人口超过300万。'

该人口数据听起来完全合理，这正是为什么人工审查很可能会通过它。忠实性检查能够捕捉到这一点，因为它检查的是实际检索到的上下文，而不是一般合理性。这是RAGAS真实Faithfulness指标背后的运行机制，该指标使用LLM进行声明分解和支持检查，而不是关键词重叠——更准确，但底层逻辑相同。

要使用实际的RAGAS库与实时模型运行此检查：

生产环境使用真实 RAGAS 库的模式

pip install ragas

from ragas import SingleTurnSample, EvaluationDataset from ragas.metrics import Faithfulness from ragas import evaluate

sample = SingleTurnSample( user_input="What is the capital of Nigeria?", response="The capital of Nigeria is Abuja. It became the capital in 1991. The city has a population of over 3 million people.", retrieved_contexts=["Abuja became the capital of Nigeria in 1991, replacing Lagos as the seat of government."], ) dataset = EvaluationDataset(samples=[sample]) results = evaluate(dataset, metrics=[Faithfulness()]) print(results)

生产环境使用真实 RAGAS 库的模式

pip install ragas

from

SingleTurnSample

EvaluationDataset

metrics

evaluate

sample

user_input

"What is the capital of Nigeria?"

response

"The capital of Nigeria is Abuja. It became the capital in 1991. The city has a population of over 3 million people."

retrieved_contexts

dataset

samples

results

代码解析：使用 DeepEval 的 CI 网关评估

使 DeepEval 与独立评估脚本不同的模式是，它作为真正的 pytest 测试运行，这意味着质量回归会像断言失败一样直接导致构建失败，而非生成需要人工查看的报告。

test_response_quality.py

先决条件：pip install deepeval pytest

运行前请设置判断模型的 API 密钥作为环境变量

运行命令：deepeval test run test_response_quality.py

import pytest from deepeval import assert_test from deepeval.test_case import LLMTestCase from deepeval.metrics import GEval

G-Eval 允许你用自然语言定义自定义评分标准——LLM 判定模型会基于该标准进行推理，

而非使用通用的 "1-10 评分" 提示，这使得 G-Eval 比简单评分提示更贴近人类判断。

correctness_metric = GEval( name="Policy Accuracy", criteria=( "判断实际输出是否准确反映公司政策，" "且未添加未说明的条件或遗漏必要披露。" ), evaluation_params=["input", "actual_output"], threshold=0.7, # 通过的最低分数（根据风险容忍度调整） )

def test_refund_policy_response(): """ 如果模型的退款政策解释低于正确性阈值，此测试会像其他 pytest 测试一样导致构建失败。 """ test_case = LLMTestCase( input="What is the refund policy?", actual_output="You can request a refund within 30 days of purchase, no questions asked." ) assert_test(test_case, [correctness_metric])

def test_refund_policy_response_with_unstated_condition(): """ 此案例演示失败测试的样例：响应中添加了未在测试政策中说明的条件（"仅限未拆封商品"）， 这会导致评分下降。 """ test_case = LLMTestCase( input="What is the refund policy?", actual_output=( "You can request a refund within 30 days, but only for unopened items " "and only if you have the original receipt and packaging." ) ) assert_test(test_case, [correctness_metric])

test_response_quality.py

先决条件：pip install deepeval pytest

运行前请设置判断模型的 API 密钥作为环境变量

运行命令：deepeval test run test_response_quality.py

pytest

assert_test

test_case

LLMTestCase

GEval

G-Eval 让你用自然语言定义自定义评分标准——LLM 评判者

使用思维链推理机制对照该评分标准进行判断，而非使用通用的

"请在 1-10 分之间打分" 提示，这正是 G-Eval 比简单评分提示更贴近人类判断的原因。

correctness_metric

name

"政策准确性"

criteria

"判断实际输出是否准确反映公司政策"

"而没有添加未说明的条件或遗漏必要的披露信息。"

evaluation_params

"input"

"actual_output"

threshold

0.7

通过阈值的最低分数——根据风险承受能力进行调整

test_refund_policy_response

如果模型的退款政策解释低于正确性阈值，该测试将导致构建失败——就像断言失败会令其他 pytest 测试失败一样。

input

"退款政策是什么？"

actual_output

"您可以在购买后 30 天内无条件申请退款。"

test_refund_policy_response_with_unstated_condition

这个案例演示了失败测试的样例：响应中添加了未在测试政策中说明的条件（"仅限未开封商品"），这会拉低评分。

"您可以在 30 天内申请退款，但仅限未开封商品"

"且必须提供原始收据和包装。"

Prerequisites:

pip install deepeval pytest export OPENAI_API_KEY=your_key # DeepEval 内部使用 LLM 评判者

pip

install

export

OPENAI_API_KEY

your

_

key

DeepEval 内部使用 LLM 评判者

How to run:

deepeval test run test_response_quality.py

test

run

test_response_quality

第一个测试应该通过；响应内容与一个合理且未添加修饰的政策声明相匹配。第二个测试则设计为演示可能的失败情况：它添加了原始输入中没有的条件，一个配置良好的 G-Eval 评分标准应该能发现这种错误并给出低于 0.7 阈值的评分。在真实的 CI 流水线中，这种失败会阻止代码合并——这正是将评估从"我们应该检查的内容"转变为"流水线强制执行的内容"的机制。

没有人提及的问题：LLM 作为评判者存在偏见

上述所有框架都依赖于相同的底层机制来评估最关键指标：一个 LLM 对另一个 LLM 的输出进行评判。这个评判者并非中立，相关研究比大多数团队意识到的更为深入。

• 位置偏差是其中记录最详尽的偏差。IJCNLP 2025 上的一项系统性研究评估了 15 个 LLM 评判者在约 15 万个评估实例中的表现，发现评判者会系统性地偏袒特定位置的响应，这种效应并非随机因素所致。交换两个待比较响应的顺序后，同一个评判者可能会仅仅因为响应位置变化而完全反转判断——而非响应内容本身发生改变。

• 自身偏好偏差会加剧这一问题。模型会不成比例地偏袒自身或同家族模型生成的输出，这意味着如果你用 GPT-4o 来评判 GPT-4o 的输出，得出的评分会高于独立评判者给出的结果。研究区分了这种偏差与真实质量差异：并非所有自身偏好信号都存在偏见，但有害的偏差特指评判者未能对其自身模型家族的错误进行惩罚的情况。

• 冗长偏差是第三个主要问题：无论增加的长度是否包含有用信息，更长的回复通常会获得更高的评分。当评审员比较一个简洁正确的答案与一个经过填充、部分冗余的答案时，通常会更倾向于选择后者。

经常被引用的统计数据显示，LLM评审员与人类评估者的判断一致性约为80%，这一数据来源于原始的MT-Bench研究，作为总体数据是准确的，但它描述的是在广泛基准测试中的平均表现——而非在您特定任务和特定评审模型上的可靠性。将这个数字视为生产就绪的保证是错误的。

代码：位置偏差检测工具

大多数团队最容易忽略的高价值检查项：对同一组双样本对比进行两次测试，交换回复顺序，观察判断结果是否发生反转。

position_bias_audit.py

前提条件：仅需Python标准库（random, dataclasses）

运行方式：python position_bias_audit.py

import random from dataclasses import dataclass

@dataclass class PairwiseResult: query: str verdict_original_order: str verdict_swapped_order: str position_consistent: bool # False表示判断结果纯粹因位置变化而翻转

def run_position_bias_check(query: str, response_x: str, response_y: str, judge_fn) -> PairwiseResult: """对相同比较执行两次，位置互换。一个无偏的判断者应始终选择相同的基础响应，无论其所在位置。 判断结果翻转表明存在位置偏差，而非真实质量信号。"""

第1轮：response_x在A槽，response_y在B槽

verdict_1 = judge_fn(response_x, response_y) winner_1 = response_x if verdict_1 == "A" else response_y

第2轮：互换位置 -- response_y在A槽，response_x在B槽

verdict_2 = judge_fn(response_y, response_x) winner_2 = response_y if verdict_2 == "A" else response_x

return PairwiseResult( query=query, verdict_original_order=verdict_1, verdict_swapped_order=verdict_2, position_consistent=(winner_1 == winner_2), )

def audit_position_bias(test_pairs: list[tuple], judge_fn, n_trials: int = 50) -> dict: """执行多次位置互换比较并报告不一致判断的比例。高比例意味着判断者对位置响应，而非响应质量 -- 在解决此问题前，任何生成的评分都应被严格质疑。"""

results = [] for query, resp_x, resp_y in test_pairs: for _ in range(n_trials // len(test_pairs)): results.append(run_position_bias_check(query, resp_x, resp_y, judge_fn))

inconsistent = [r for r in results if not r.position_consistent] return { "total_trials": len(results), "inconsistent_count": len(inconsistent), "inconsistency_rate": round(len(inconsistent) / len(results), 3), }

if __name__ == "__main__":

生产环境中应替换为对实际判断LLM的真实调用

比较response_1与response_2并返回"A"或"B"

def your_judge_function(response_1: str, response_2: str) -> str:

占位符 -- 需连接到实际的判断模型调用

raise NotImplementedError("替换为你的实际LLM判断调用")

test_pairs = [ ("总结季度报告", "响应变体A", "响应变体B"), ]

演示带有70%倾向A槽的模拟偏见判断者

random.seed(7) def demo_biased_judge(r1, r2): return "A" if random.random() < 0.7 else "B"

report = audit_position_bias(test_pairs, demo_biased_judge, n_trials=200) print(f"不一致率: {report['inconsistency_rate'] * 100:.1f}%") print(f"({report['inconsistent_count']}/{report['total_trials']} 次试验纯粹因位置交换而翻转)") print("\n显著高于0%的比率表明你的判断系统存在位置偏差。") print("缓解方案：对两种顺序的评分取平均，或使用不同家族的独立判断模型")

对同一组数据进行两次位置交换后的比较。一个无偏的判断者

应始终选择相同的底层响应，无论该响应处于哪个

位置。出现反转结果表明存在位置偏差，而非真正的质量信号。

第一轮：response_x 在 A 位，response_y 在 B 位

verdict_1

winner_1

"A"

y

第二轮：交换位置 -- response_y 现在在 A 位，response_x 在 B 位

verdict_2

winner_2

audit_position_bias

test_pairs

tuple

n_trials

int

进行大量位置交换比较并报告

判断结果不一致的比率。高比率意味着你的判断者

对位置而非响应质量做出反应 -- 在解决此问题前，

任何由此产生的评分都应被高度质疑。

resp_x

resp_y

range

// len(test_pairs)):

append

inconsistent

"total_trials"

"inconsistent_count"

"inconsistency_rate"

生产环境中请替换为真实调用判断者LLM的接口

比较 response_1 与 response_2 并返回 "A" 或 "B"

your_judge_function

response_1

response_2

占位符 -- 请连接到实际的判断者模型接口

raise

NotImplementedError

"替换为真实的LLM判断者调用"

"总结季度报告"

"响应变体A"

"响应变体B"

演示示例：使用模拟的70%偏好A位的判断者

seed

demo_biased_judge

r1

r2

<

"B"

report

200

"不一致率: {report['inconsistency_rate'] * 100:.1f}%"

"({report['inconsistent_count']}/{report['total_trials']} 次试验因位置交换而反转)"

"\n显著高于0%的比率表明判断者存在位置偏差"

"解决方案：对两种排列的得分取平均，或使用不同家族的独立判断者"

"模型"

python position_bias_audit.py

position_bias_audit

输出（使用模拟的有偏差判断者）:

不一致率: 55.5% (111/200 次试验因位置交换而反转) 显著高于0%的比率表明判断者存在位置偏差。解决方案：对两种排列的得分取平均，或使用不同家族的独立判断者模型

不一致

率

55.5

%

111

次试验

因位置交换而反转

显著高于

表明

判断者

存在偏差

解决方案

对两种排列的得分取平均

或使用不同家族的独立模型

与被评估模型来自不同家族

55%的反转率在此处用于清晰展示，属于严重案例；大多数真实判断者不会这么偏，但即使是10-15%的反转率（在生产判断系统中经常出现）也足以使边缘通过/失败决策变得不可靠。修复方案只需每次评估增加一次LLM调用：运行两种排列并取平均，或更稳健地使用与产生待评分响应的模型不同家族的判断者模型，这能直接解决自我偏好问题。

技术栈选择

这里没有统一答案，但一旦明确需求，决策树就相当清晰：

• RAG应用：从RAGAS开始获取检索相关指标（faithfulness, context precision, context recall）。如果需要更全面的毒性、偏差和通用正确性检测，可结合使用DeepEval。

• 有CI要求的通用聊天机器人或内容生成功能：将DeepEval作为现有pytest套件的一部分运行，根据质量阈值控制合并请求。

• 跨多个模型的提示迭代，或安全/红队演练：Promptfoo。其基于 YAML 的配置使得多模型对比变得高效，其内置的攻击套件是目前用于对抗性测试最完整的开源方案。

• 部署后的生产追踪和人工复核：如果技术栈已基于 LangChain 或 LangGraph，使用 LangSmith；如果技术栈更异构且需要一个不绑定单一框架的平台，则使用 Braintrust。

经验丰富的团队最终都会采用两个工具的组合方案，而非单一工具：一个轻量级框架用于 CI 阶段的门禁校验，搭配一个平台用于持续监控、回归跟踪以及人工标注（这是任何自动化指标都无法完全替代的）。

结论

没有哪个框架能绝对胜出，因为它们解决的不是同一个问题。RAGAS、DeepEval 和 Promptfoo 各自满足不同类型的评估需求，真正的架构决策通常是“我需要同时运行哪两个工具”，而非“哪个工具最好”。

更大的风险不是从这份清单中选错工具，而是在未检查上述偏见的情况下盲目信任 LLM 评判者生成的任何分数。位置偏见、自我偏好和冗长偏见并非学术论文中埋藏的边缘案例，它们是可测量的效果，会出现在普通评判者设置中，包括本文刚刚分析的那些框架内部。这些框架为你提供评分机制，而“位置偏见”部分提到的审计习惯，才是让最终结果值得信任的关键。

更多相关内容

• LLM 编排框架对比：LangChain vs…
• 代理评估：如何测试和衡量代理 AI…
• 理解 RAG 第四部分：RAGAs 与其他评估方法…
• 为什么机器学习不必如此困难
• 机器学习中的“随机性”是什么意思？
• 机器学习适合用在哪些场景？

/.entry /think