DeepEval:AI代理评估框架
AI系统是概率性的,意味着相同的输入可能产生略有不同的输出。
AI编程/Vibe Coding 遇到问题需要帮助的,联系微信 ezpoda,免费咨询。
如果有人想用DeepEval尝试RAG和Agent评估示例,请访问仓库并按照README中的设置步骤操作。
1、AI信任问题
想象一下,你已经为你的公司构建了一个AI助手。它回答客户问题,从你的文档中检索信息,甚至帮助计算运费。在演示期间一切似乎都很正常。但后来,一个客户询问你的退款政策,AI自信地回应了完全编造的信息。
这个场景不是假设的——这是团队在部署AI系统时面临的最常见问题之一。大型语言模型(LLM)非常强大,但它们有一个有据可查的倾向,即"幻觉"——生成听起来合理但不正确的信息。
问题不是你的AI是否会犯错。而是你会在用户发现之前抓住它们。
2、为什么评估比以往任何时候都重要
传统软件是可预测的。如果你编写一个函数来加两个数字,它总是会对相同的输入返回相同的结果。你可以编写单元测试,如果它们通过,你就对你的代码有很高的信心。
AI系统是不同的。它们是概率性的,意味着相同的输入可能产生略有不同的输出。它们可能受到措辞细微变化的影响。最重要的是,它们可能以看起来完全合理的方式失败。
考虑这两种在现代应用中迅速变得必不可少的AI系统类型:
AI代理是可以使用工具来完成任务的系统。它们可能搜索网页、查询数据库、执行计算或与API交互。挑战?你需要确保代理:
- 为每个任务选择正确的工具
- 向用户提供相关的答案
- 不编造它没有的信息
RAG系统在生成响应之前从你的文档中检索相关信息。这有助于将AI的答案锚定在你的实际数据中。但你需要验证:
- 检索找到正确的文档
- AI使用检索到的信息(而不是它的训练数据)
- 最终答案是准确和相关的
没有适当的评估,你本质上是在蒙着眼睛部署AI系统,希望它们能正常工作。
3、评估领域:为什么选择DeepEval?
存在几个用于评估LLM应用的框架:
DeepEval的突出之处
1. 开发者友好的设计: DeepEval对软件工程师来说感觉很熟悉。如果你写过pytest测试,你已经知道如何使用它。这大大降低了学习曲线。
2. 开箱即用的全面指标: 从答案相关性到幻觉检测到工具正确性——DeepEval提供了经过实战测试的指标,你自己构建这些指标需要几个月的时间。
3. 适用于任何LLM技术栈: 无论你使用的是LangChain、LlamaIndex还是自定义实现,DeepEval都能无缝集成。
4. CI/CD集成: 你可以将LLM评估添加到你的持续集成管道中,在回归到达生产环境之前捕获它们。
5. 活跃的开发: 随着定期更新和活跃的社区,DeepEval随着快速变化的AI领域不断进化。
4、实践:构建和评估AI系统
让我们通过一个实际示例。我创建了一个完整的仓库,演示如何评估AI代理和RAG系统:
仓库:https://github.com/DhunganaKB/DeepEval_Examples
项目结构很简单:
第一部分:评估AI代理
我们的代理使用LangGraph构建,可以访问三个工具:
@tool
def get_weather(city: str) -> str:
"""获取城市的当前天气信息。"""
# 返回主要城市的天气数据
@tool
def calculate(expression: str) -> str:
"""评估数学表达式。"""
# 安全地评估数学表达式
@tool
def search_knowledge_base(query: str) -> str:
"""搜索公司政策和产品信息。"""
# 返回退款政策、运费信息等
当用户问"旧金山天气如何?"时,代理应该:
- 认识到这需要
get_weather工具 - 用正确的参数调用它
- 返回有用的响应
测试数据集
我们用预期行为定义测试场景:
TEST_SCENARIOS = [
{
"input": "旧金山天气如何?",
"expected_output": "旧金山:62°F,晴朗。",
"expected_tools": [ToolCall(name="get_weather")],
},
{
"input": "计算85美元账单的15%小费。",
"expected_output": "85美元的15%小费是12.75美元。",
"expected_tools": [ToolCall(name="calculate")],
},
{
"input": "你们的退款政策是什么?",
"expected_output": "我们的退款政策允许在30天内退货...",
"expected_tools": [ToolCall(name="search_knowledge_base")],
},
]
评估指标
我们评估三个关键方面:
1. 工具正确性
代理是否调用了正确的工具?如果用户询问天气,代理应该使用get_weather,而不是calculate。
ToolCorrectnessMetric(threshold=0.5, include_reason=True)
2. 答案相关性
响应实际上与所问的问题相关吗?代理可能调用了正确的工具,但随后提供了不相关的摘要。
AnswerRelevancyMetric(threshold=0.5, include_reason=True)
3. 输出正确性
答案在事实上是否正确?使用GEval,我们可以创建自定义评估标准:
GEval(
name="Correctness",
criteria="根据预期输出确定实际输出在事实上是否正确。",
evaluation_params=[
LLMTestCaseParams.ACTUAL_OUTPUT,
LLMTestCaseParams.EXPECTED_OUTPUT,
],
threshold=0.5,
)
运行评估
cd Agent
python test_agent.py
DeepEval通过所有指标运行每个测试用例并提供详细反馈:
======================================================================
AGENT EVALUATION
======================================================================
Evaluating 4 test cases...
[1] 旧金山天气如何?
Output: 旧金山天气是62°F,晴朗。
Tools: ['get_weather']
✓ Tool Correctness: PASSED (1.0)
✓ Answer Relevancy: PASSED (0.95)
✓ Correctness: PASSED (0.92)
第二部分:评估RAG管道
RAG系统更复杂,因为它们涉及两个阶段:检索和生成。两者都可能独立失败。
RAG管道
我们的管道使用:
- LangChain 用于编排
- FAISS 用于向量存储
- OpenAI嵌入 用于文档编码
- GPT-4o-mini 用于生成
class RAGPipeline:
def __init__(
self,
model_name: str = "gpt-4o-mini",
embedding_model: str = "text-embedding-3-small",
chunk_size: int = 500,
chunk_overlap: int = 50,
top_k: int = 4,
):
管道从data/文件夹加载文档,其中包含:
- 公司手册(PTO、远程工作政策)
- 产品常见问题解答(功能、故障排除)
- 支持工单(历史问题和解决方案)
- API文档(端点、速率限制)
- 培训材料(支持程序)
评估数据集
我们创建了20个直接从源文档派生的问答对:
EVAL_DATASET = [
{
"input": "全职员工每月累积多少天PTO?",
"expected_output": "全职员工每月累积1.5天PTO。",
"expected_context": "全职员工每月累积1.5天PTO。",
"source_file": "company_handbook.txt",
},
{
"input": "认证用户的API速率限制是多少?",
"expected_output": "速率限制是每个用户令牌每分钟60个请求。",
"expected_context": "每个用户令牌每分钟60个请求",
"source_file": "api_refrence.txt",
},
# ... 还有18个测试用例
]
每个测试用例包括:
- Input:要问的问题
- Expected Output:理想的答案
- Expected Context:应该被检索的文本
- Source File:哪个文档包含答案
五个RAG指标
RAG评估比代理评估更细致。我们使用五个互补的指标:
1. 答案相关性
生成的答案是否与问题相关?
AnswerRelevancyMetric(threshold=0.5, include_reason=True)
2. 忠实性(幻觉检测)
这很关键。答案是否锚定在检索到的上下文中,还是模型编造了东西?
FaithfulnessMetric(threshold=0.5, include_reason=True)
高忠实性分数意味着AI正在使用你的文档,而不是发明信息。
3. 上下文召回
检索系统是否找到了包含答案的文档?
ContextualRecallMetric(threshold=0.5, include_reason=True)
4. 上下文精确性
检索到的文档实际上是否相关,还是我们检索到了噪音?
ContextualPrecisionMetric(threshold=0.4, include_reason=True)
5. 正确性
最终答案在事实上是否准确?
GEval(
name="Correctness",
criteria="确定实际输出在事实上是否正确...",
threshold=0.5,
)
理解结果
当你运行评估时:
cd RAG
python test_rag.py -quick
你可能会看到如下结果:
Contextual Precision (score: 0.5, threshold: 0.4)
Reason: 直接回答问题的相关节点
('全职员工每月累积1.5天PTO')排名第二,
而第一个节点讨论费用政策...
这告诉你一些重要的事情:你的检索正在找到正确的信息,但没有将其排在第一位。这是可操作的反馈——你可能需要改进你的分块策略或添加重新排序步骤。
5、LLM评估的最佳实践
通过构建这个项目,出现了几个最佳实践:
1. 从黄金数据集开始
创建一个规模小但高质量的测试用例集,其中包含已知的正确答案。这些成为你评估的ground truth。
2. 测试失败模式
不要只测试快乐路径。包括以下问题:
- 需要你的文档中没有的信息
- 可以由多个文档回答
- 措辞模糊
3. 迭代阈值
从较低的阈值(0.5)开始,随着系统改进而增加。过早设置过于严格的阈值可能会令人沮丧。
4. 使用缓存
LLM调用缓慢且昂贵。缓存你的测试用例结果,以避免在开发期间重新运行相同的查询:
_test_case_cache: dict[str, LLMTestCase] = {}
def build_test_case(scenario: dict) -> LLMTestCase:
cache_key = scenario["input"]
if cache_key not in _test_case_cache:
# 运行实际测试...
return _test_case_cache[cache_key]
5. 集成到CI/CD
一旦你的评估套件稳定,将其添加到你的部署管道:
# .github/workflows/test.yml
- name: Run LLM Evaluation
run: |
deepeval test run test_agent.py
deepeval test run test_rag.py
6、更大的图景:构建可信赖的AI
评估不仅仅是捕捉错误——它是关于建立信任。
当你能够证明你的AI系统:
- 为正确的任务调用正确的工具
- 检索相关信息
- 锚定在你的数据中
- 提供准确的答案
……你不仅仅是发布一个功能。你是在发布信心。
你的用户相信,当他们问一个问题时,他们会得到一个可靠的答案。你的团队相信,更改不会破坏关键功能。你的利益相关者相信,AI正在做它应该做的事情。
这种信任是通过严格的评估赢得的。
探索和适应:
- 修改测试场景以匹配你的用例
- 根据你的质量要求调整阈值
- 根据需要添加新指标
7、结束语
AI应用的"发布并希望它有效"的时代已经结束。随着LLM越来越多地集成到关键业务流程中,系统评估其行为的能力变得至关重要。
DeepEval为这一挑战提供了一种实用、开发者友好的方法。通过将LLM评估视为软件测试——具有明确的指标、可重现的测试用例和CI/CD集成——我们可以构建不仅强大而且可靠的AI系统。
本文中的代码示例可在github.com/DhunganaKB/DeepEval_Examples获取。使用它们作为评估你自己的AI代理和RAG系统的起点。
原文链接: Getting Started with DeepEval: Testing AI Agents and RAG Pipelines Made Simple
汇智网翻译整理,转载请标明出处