如果有人想用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.pyDeepEval通过所有指标运行每个测试用例并提供详细反馈：
====================================================================== 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.py6、更大的图景：构建可信赖的AI
评估不仅仅是捕捉错误——它是关于建立信任。
当你能够证明你的AI系统：
- 为正确的任务调用正确的工具
- 检索相关信息
- 锚定在你的数据中
- 提供准确的答案
……你不仅仅是发布一个功能。你是在发布信心。
你的用户相信，当他们问一个问题时，他们会得到一个可靠的答案。你的团队相信，更改不会破坏关键功能。你的利益相关者相信，AI正在做它应该做的事情。
这种信任是通过严格的评估赢得的。
探索和适应：
- 修改测试场景以匹配你的用例
- 根据你的质量要求调整阈值
- 根据需要添加新指标
7、结束语
AI应用的"发布并希望它有效"的时代已经结束。随着LLM越来越多地集成到关键业务流程中，系统评估其行为的能力变得至关重要。
DeepEval为这一挑战提供了一种实用、开发者友好的方法。通过将LLM评估视为软件测试——具有明确的指标、可重现的测试用例和CI/CD集成——我们可以构建不仅强大而且可靠的AI系统。
本文中的代码示例可在github.com/DhunganaKB/DeepEval_Examples获取。使用它们作为评估你自己的AI代理和RAG系统的起点。
原文链接：DeepEval：AI代理评估框架 - 汇智网
