# LangChain OpenEvals Introduction

> 原文链接：https://blog.langchain.dev/evaluating-llms-with-openevals/
> 作者/来源：LangChain
> 阅读日期：2026-05-06

## 一句话总结
LangChain 发布 OpenEvals 的官方博文，阐述了 LLM 应用评测的核心挑战以及 OpenEvals 如何通过模块化评估器和 LLM-as-Judge 最佳实践来解决这些问题。

## 核心论点
1. LLM 应用的评测不同于传统 ML——输出是开放式的、主观的，传统 metric 不够用
2. LLM-as-Judge 是目前最实用的评测方式，但需要精心设计 prompt 和校准
3. 评测应该嵌入开发流程而非事后补充（shift-left evaluation）
4. 不同应用场景（RAG、chatbot、agent）需要不同的评测维度

## 关键概念
- **Evaluator as Function**：将评估逻辑封装为可组合的纯函数
- **Judge Prompt Engineering**：设计有效 judge prompt 的最佳实践（明确评分标准、提供参考答案、要求结构化输出）
- **Online vs Offline Evaluation**：生产环境持续评测 vs 开发阶段批量评测
- **Custom Evaluator**：在预置模板基础上定制领域专用评估器

## 实践建议
- 从简单的 heuristic 评估开始（格式检查、长度检查），逐步引入 LLM judge
- 为每个评测维度创建独立评估器而非一个"全能"评估器
- 使用人类标注的 golden set 校准 judge prompt 的准确性
- 将评测结果可视化为时间序列以跟踪模型/prompt 变更的影响
- 结合 LangSmith 的 tracing 功能将评测结果与具体 trace 关联

## 独到观点
- "最好的评测不是最复杂的，而是最能帮你做决策的"
- 建议从 5-10 个 golden examples 开始迭代评估器，而非追求大规模 benchmark
- 评测结果的 actionability 比 accuracy 更重要

## 与其他文章的关联
- 对应仓库为 langchain-ai/openevals
- 与 DeepEval 的评测方法论形成对比（OpenEvals 更轻量灵活，DeepEval 更全面但重）
- 继承了 OpenAI Evals 的 Model-Graded 理念
- 与 LLM Comparator 的 human-driven 方法互补