3个开源LLM评估框架的对比

当今应用AI工程中最危险的短语是"它在演示中有效"。模型响应迅速，输出听起来合理，幻觉（如果有的话）足够微妙，可以通过粗略审查。然后系统投入生产，几周内，用户发现了你的演示没有涵盖的边缘情况：对抗性输入、模糊查询、微妙的提示注入、披着自信散文外衣的事实性虚构。

防止这种问题的学科是LLM评估——对语言模型行为进行系统性、可重复的自动化测试。它相当于单元测试、集成测试和安全扫描的测试等价物，应用于一类本质上概率性的软件。而在大多数工程组织中，它几乎完全缺席。

本文考察三个开源框架——DeepEval、Promptfoo和Giskard——它们代表了结构化LLM评估的当前领先方法，它们不同的架构理念，以及如何思考将它们分层到生产AI系统中。

没有一个评估工具能处理所有事情。2026年交付可靠AI系统的团队正在运行分层的评估管道——CI中的快速属性检查、发布前的质量指标、每次生产部署前的自动漏洞扫描。

1、为什么LLM评估在架构上不同

经典软件测试基于一个单一的基础假设：给定相同的输入，正确的系统产生相同的输出。你编写断言，运行测试，管道是绿色或红色。这个模型深深植根于工程文化中，以至于大多数团队在开始构建AI功能时会本能地采用它，然后发现它几乎立即失效。

让语言模型总结同一份文档十次。你得到十个不同的摘要——每个都可能准确，但没有一个是相同的。输出空间不是一个点；它是一个高维概率分布。测试输出相等性将这个分布折叠为单个预期字符串，完全错过了重点。

"当每次运行的输出都变化时，你测试的是输出属性——而不是输出内容。格式合规性、关键词存在、事实忠实性、长度边界、语义一致性。"

这种转变——从输出相等性到属性断言——是现代LLM评估的架构基础。它有几个下游影响。评估框架需要优雅地处理非确定性，通常通过运行多个样本并聚合分数。它们需要能量化忠实性、相关性和连贯性等模糊质量的指标。它们经常需要另一个LLM来评估第一个LLM的输出——这种递归安排带来了自身的可靠性挑战。

成熟的LLM评估架构在软件生命周期的三个不同阶段运行：

2、三层LLM评估架构

第一层：开发——单元评估

预提交和CI。在合并前捕获提示回归和质量下降。快速、自动化、与代码集成。

DeepEval · Promptfoo

第二层：暂存——安全和漏洞扫描

发布前门禁。自动对抗性探测幻觉、注入、偏见、数据泄露和行为不一致。

Giskard · Promptfoo

第三层：生产——可观察性和漂移检测

实时流量监控。捕获测试遗漏的故障和版本之间的模型漂移。

LangSmith · Langfuse · TruLens

让我们关注第一层和第二层，DeepEval、Promptfoo和Giskard各在这些层运行，对于今天构建生产AI系统的团队来说，架构选择最为关键。

3、DeepEval：代码优先的单元测试

开源LLM评估框架，设计为"LLM的Pytest"。Python优先，60+指标，集成到标准CI管道中。

DeepEval的设计论点是简单的：如果LLM评估要成为标准工程实践，它必须感觉像标准工程实践。对于Python开发者来说，这意味着Pytest。DeepEval镜像Pytest的测试用例结构、断言模型和CLI接口——所以一个以前写过Python测试的开发者可以在十分钟内写出第一个LLM评估。

中心抽象是LLMTestCase：一个结构化对象，包含模型的输入、模型的实际输出、可选的上下文文档（用于RAG评估）和可选的预期输出。测试用例针对一个或多个指标进行评估，每个指标返回一个分数和断言失败时的推理解释。

from deepeval import evaluate
from deepeval.metrics import (
    HallucinationMetric,
    AnswerRelevancyMetric,
    FaithfulnessMetric
)
from deepeval.test_case import LLMTestCase

# 定义带有检索上下文的测试用例
test_case = LLMTestCase(
    input="What is our refund window for digital products?",
    actual_output="Digital products are eligible for a 14-day refund.",
    context=[
        "All digital product purchases carry a 14-day money-back guarantee.",
        "Physical goods follow a separate 30-day return policy."
    ],
    expected_output="14 days"
)

# 堆叠多个指标——每个独立运行
hallucination = HallucinationMetric(threshold=0.5)
relevancy = AnswerRelevancyMetric(threshold=0.75)
faithfulness = FaithfulnessMetric(threshold=0.80)
evaluate([test_case], [hallucination, relevancy, faithfulness])

指标库是DeepEval的广度成为其主要差异化优势的地方。它支持60多个指标，涵盖幻觉检测、答案相关性、忠实性（答案是否保持在检索上下文内？）、上下文精确度和召回率、G-Eval（可推广的基于标准的评估器）、RAGAS兼容指标、多轮对话的连贯性、智能体系统的工具调用准确性，以及偏见和毒性评分。没有其他开源框架在单一连贯的包中覆盖这个表面区域。

3.1 架构考虑

DeepEval对LLM-as-judge的依赖——使用第二个语言模型来评分第一个模型的输出——既是它的优势也是它的成本中心。每次指标调用至少进行一次额外的API调用。在大规模下，这可能会给你的CI管道增加有意义的延迟和成本。对于超过50个案例的测试套件，使用DeepEval的批量评估模式并积极缓存。

DeepEval还包括一个合成测试数据集生成器——这是一个比第一眼看起来更实际重要的能力。大多数启动评估管道的团队面临一个先有鸡还是先有蛋的问题：他们需要测试用例来评估质量，但创建高质量的测试用例需要知道要探测哪些故障模式。DeepEval的合成器从现有文档或黄金示例生成对抗性、边缘案例和改写变体，显著加速冷启动问题。

3.2 何时使用DeepEval

DeepEval是构建RAG系统、多轮聊天机器人或智能体管道的Python团队的正确默认选择，他们需要与pytest和CI干净集成的结构化、研究支持的评估层。它是这里审查的三个框架中最多功能的，当你需要质量指标——而不仅仅是安全检查——作为一等CI门禁时的自然选择。

4、Promptfoo：YAML原生、安全优先、CI原生

用于提示A/B测试、回归检测和红队测试的轻量级CLI和库。无需云设置，无需SDK依赖。随处运行。

Promptfoo占据了一个不同的细分市场：它是为那些用提示而不是Python思考的团队提供的测试工具。它的配置是YAML优先的，它的接口是CLI优先的，它的心智模型更接近Jest或Vitest而不是pytest。开发者以声明方式定义测试用例，指定他们的提示变体和模型提供商，并运行npx promptfoo eval来获得每个组合执行情况的并排比较表。

这种轻量级方法对于处于评估旅程初期的团队来说是一个真正的优势。没有要管理的SDK依赖，没有要配置的Python环境，没有要注册的平台。开发者可以在一个下午将Promptfoo添加到CI管道中，并立即开始在每个拉取请求上捕获提示回归。

prompts:
  - "Summarise the following document in 3 bullet points:\n{{document}}"
  - "You are a concise analyst. Extract 3 key findings:\n{{document}}"
providers:
  - openai:gpt-4o
  - anthropic:claude-sonnet-4-6
tests:
  - vars:
      document: "Q3 revenue grew 12% YoY driven by enterprise expansion..."
    assert:
      - type: contains
        value: "revenue"
      - type: llm-rubric
        value: "Response must contain exactly 3 bullet points"
      - type: not-contains
        value: "I cannot summarise"
      - type: javascript
        value: "output.split('\n').filter(l => l.trim()).length <= 5"

Promptfoo在安全测试方面赢得最强差异化优势的地方。它的红队套件自动扫描提示注入、越狱漏洞、有毒内容生成、PII泄露和系统提示泄露——无需开发者手动制作对抗性输入。对于面向消费者的AI产品，这不是一个锦上添花的功能；它是负责任部署的先决条件。

4.1 架构考虑

Promptfoo支持确定性断言（字符串匹配、正则表达式、JSON模式验证）和模型辅助断言（LLM-as-judge标准）。对于CI管道，尽可能优先选择确定性断言——它们更快、更便宜，并且不会因为评判模型变化而产生误报。将LLM标准断言保留给无法表达为规则的主观质量属性。

随着评估需求的成熟，Promptfoo的局限性变得明显。它的指标库涵盖RAG和安全，但远不及DeepEval的60多个指标。YAML繁重的工作流虽然易于访问，但对于需要以编程方式表达复杂评估逻辑的团队来说会产生摩擦。而且缺乏用于管理测试数据集、跟踪版本分数或协作评估结果的原生平台意味着团队在AI系统扩展时会很快超越它。

4.2 何时使用Promptfoo

Promptfoo是处于评估旅程初期的团队的正确起点——特别是那些拥有非Python工程师或没有深厚编码背景的提示工程师的团队。它也是任何需要在发布前快速红队测试面向消费者的AI系统的团队的首选工具，无论评估堆栈中还有什么其他东西。

5、Giskard：数据集级别、合规级漏洞检测

用于自动LLM漏洞检测的Apache 2.0测试框架。自动生成对抗性测试用例。通过GDPR、HIPAA和SOC 2认证。

Giskard采取了三个框架中最具架构特色的方法。DeepEval和Promptfoo要求工程师指定要测试什么，而Giskard要求工程师指定要测试什么系统——然后自己生成对抗性探针。这种反转意义重大：这意味着Giskard可以 surfaced 开发者没有想到要测试的漏洞类别，而不仅仅是验证他们预期的故障模式。

中心API调用是giskard.scan()。你将现有模型或管道包装在giskard.Model对象中，提供数据集，并调用scan。Giskard跨多个漏洞类别自动生成对抗性变体——幻觉、事实矛盾、提示注入、敏感数据泄露、不当内容生成——针对你的系统运行它们，并生成带有严重性排名的结构化漏洞报告。

import giskard
import pandas as pd
from langchain.chains import RetrievalQA

# 包装你现有的RAG或LLM管道——需要最小更改
def my_rag_pipeline(df: pd.DataFrame) -> list:
    return [qa_chain.run(q) for q in df["question"]]

giskard_model = giskard.Model(
    model=my_rag_pipeline,
    model_type="text_generation",
    name="Customer Support RAG",
    description="Answers user questions using internal knowledge base",
    feature_names=["question"]
)

# 包装你的黄金数据集
giskard_dataset = giskard.Dataset(
    df=pd.DataFrame({"question": ["What is the return policy?", "How do I cancel?"]}),
    name="Support QA Test Set",
    target=None
)

# 一次调用——Giskard自动生成并运行对抗性探针
scan_results = giskard.scan(giskard_model, giskard_dataset)
scan_results.to_html("vulnerability_report.html")  # 结构化报告

Giskard还引入了变形测试——一个从经典软件测试中借鉴并很少应用于LLM系统的概念。思想是语义等价的输入应该产生一致的输出。客户问"你们的退货政策是什么？"和"我可以退货吗？"应该收到一致的答案，无论措辞、标点、语言或是否存在拼写错误。Giskard自动生成这些句法和语义变体，并标记不一致——这是DeepEval和Promptfoo都没有系统解决的可靠性缺陷类别。

5.1 架构考虑

Giskard的数据集级评估模型——跨测试集产生聚合分数，而不是每案例通过/失败——更自然地映射到发布门禁而不是每提交CI。推荐的模式是在发布检查清单中将Giskard扫描作为强制步骤运行，而不是在预提交钩子中。对于受监管的部署（医疗、金融、法律），将Giskard漏洞报告视为与变更日志一起的必需发布产物。

对于在受监管行业运营的团队，Giskard的合规认证——GDPR、SOC 2 Type II和HIPAA——是最明确的差异化优势。当前格局中没有其他开源LLM评估框架持有这些认证，使Giskard成为任何处理患者数据、财务信息或法律敏感内容的AI系统的实际默认选择。

5.2 何时使用Giskard

Giskard是预发布安全验证、受监管行业部署，以及任何需要自动对抗性测试生成而不是手工编写测试用例的团队的正确选择。它在比DeepEval或Promptfoo更抽象的层次上运行——粒度更粗的每案例控制，但更全面的系统覆盖。将它作为生产前的最终门禁，而不是作为主要开发时评估工具。

6、并排比较：框架对比

7、推荐技术栈：分层，而不是选择

一个常见的错误是将这些框架视为替代品——进行 bake-off，选择一个赢家，并标准化使用它。这既误解了工具也误解了问题。没有一个评估工具能做好所有事情。交付可靠AI系统的团队正在运行分层管道，每个工具做它在架构上适合做的事情。

8、影响和展望

这里审查的框架代表了一个按历史标准来看极其年轻的学科当前领先边缘。该领域已经从追求零幻觉转向以可衡量、可预测的方式管理不确定性——这种成熟反映了安全测试的轨迹，后者同样从"消除所有漏洞"转向"了解你的攻击面并系统地管理它"。

随着评估格局的演变，有几个研究趋势值得跟踪。合成评估数据生成——使用LLM自动创建测试用例、对抗性变体和边缘案例——正在成为标准能力而不是差异化优势。自动和自适应指标选择，其中评估框架根据应用类型推荐适当的指标，是一个新兴领域。而LLM-as-judge校准——衡量LLM评判员对特定领域的人类判断相关性如何——随着团队发现未校准的评判员多么不可靠，正在受到越来越多的研究关注。

"评估不是测试工具。它们是一种强制功能——使团队在他们将系统交付给会发现'坏'意味着什么的用户之前，阐明'好'对他们的特定应用实际意味着什么。"

更广泛的影响是架构性的：LLM评估不是你添加到现有AI系统的层。它是一个约束，从一开始就塑造你如何设计系统。以评估为心构建的团队——有可衡量的质量契约、定义的故障模式和自动门禁——交付更可靠的系统并更快地检测回归。事后添加评估的团队发现他们构建的系统通常结构不良，无法进行系统测试。

这里审查的三个框架——DeepEval用于质量深度、Promptfoo用于速度和安全性、Giskard用于合规和自动对抗性覆盖——代表了当今大多数生产AI应用的足够工具包。行业中评估差距不是工具差距。它是优先级差距。工具存在。始终如一使用它们的团队是那些将赢得权利交付用户实际上可以依赖的AI系统的团队。

原文链接：LLM Evaluation Frameworks: DeepEval, Promptfoo, and Giskard

汇智网翻译整理，转载请标明出处