continuous-eval

想象你是一名 AI 工程师，刚上线了一个 RAG（检索增强生成）聊天机器人。 用户问"2024年诺贝尔物理学奖颁给了谁"，系统却一本正经地回答"爱因斯坦"—— 这是典型的"幻觉"问题，LLM 在没有可靠检索结果支撑时胡编乱造。 这类问题靠人工抽查根本无法规模化发现，有什么工具能让评估变得系统化、自动化？

continuous-eval 就是答案——它是一个专为 LLM 应用设计的数据驱动评估框架， 由 Y Combinator 孵化的创业公司 Relari 开源，支持 RAG、代码生成、Agent 工具调用、 文本分类等多种场景的量化评估，让"AI 质量"不再是一句空话。

图1：Relari 公司 Logo — Y Combinator 孵化的 AI 基础设施创业公司

图2：Relari 产品体系 — continuous-eval 定位为 LLM 应用评估基础设施

图3：Relari 旗下 Nuvi 平台 — 自然语言驱动的 AI Agent 构建工具，与 continuous-eval 形成生态互补

背景：LLM 应用为什么需要评估框架

大语言模型（LLM）正快速渗透到搜索、客服、代码生成等核心场景。 然而，LLM 的输出天然具有不确定性——同样的问题，每次回答可能略有不同； 同样的检索系统，受限于向量数据库的质量，命中率也时好时坏。

在没有统一评估框架的时代，团队通常靠三种方式验证质量： 人工审核（慢）、用户投诉（滞后）、盲测（随机）。 这些方法效率低、一致性差、无法集成到 CI/CD 流水线中。

Relari 公司（官网 relari.ai）正是看到了这个痛点，推出 continuous-eval， 旨在让 LLM 应用的质量评估成为工程流水线的标准环节。 该公司还同时运营 Nuvi（自然语言驱动的 AI Agent 构建平台）和 Agent Contracts 项目， 在 Y Combinator 孵化的 AI 基础设施赛道中占据一席之地。

continuous-eval 的核心设计哲学是：模块化评估 + 多层次指标。 它不要求你把整个 RAG 管道当黑盒打分，而是将管道拆解为 Retriever、Reranker、Generator 等模块， 对每个模块单独配置适合的指标，实现精确诊断。

核心架构：模块化 Pipeline + 评估 Runner

项目的代码结构高度模块化，核心分为三大层：

1. 评估层（eval/）

• pipeline.py：定义 Pipeline 类，将 LLM 应用建模为 DAG（有向无环图）， 每个节点是一个 Module，支持 input（上游模块或数据集字段）和 output 类型注解。 提供了 SingleModulePipeline（单模块快捷封装）和 ModuleOutput（提取模块输出的选择器函数）。
• runner.py：EvaluationRunner 是评估执行器，核心方法是 evaluate()， 接收 Pipeline 对象和 PipelineResults，实现多指标并行计算与结果聚合。 test() 方法将评估结果与预设阈值对比，输出通过/失败状态。
• modules.py：定义 Module 类，是管道节点的数据类，包含 name、input、output、eval（指标列表）等字段。
• dataset.py：数据集封装，支持从本地文件或远程下载加载评估数据（JSONL 格式）。
• result_types.py：定义 MetricsResults、PipelineResults、TestResults 等结果数据结构。

2. 指标层（metrics/）

指标是 continuous-eval 的核心资产，覆盖五大类别：

类别	指标	说明
检索	PrecisionRecallF1、RankedRetrievalMetrics	基于集合重叠的精确率/召回率
生成-文本	AnswerCorrectness、Faithfulness、AnswerRelevance	LLM 裁判评分
生成-语义	BERTScore、ROUGLEScore	基于 embedding 的语义相似度
代码	SQLCorrectness、PythonCorrectness	SQL/Python 代码正确性
分类	F1、Precision、Recall	标准分类指标

每类指标都支持三种评估模式：

• 确定性指标（Deterministic）：精确匹配、F1 等，无需 LLM 调用，速度快。
• 语义指标（Semantic）：基于 sentence-transformers embedding，计算余弦相似度。
• LLM 裁判指标（LLM-based）：用 LLM API 打分，最灵活但成本最高。

3. LLM 抽象层（llms/）

提供了统一 LLMBase 抽象类，具体实现覆盖主流服务商： OpenAIModel、AnthropicModel、GoogleModel、CohereModel、 AzureOpenAIModel、BedrockModel（支持 AWS Bedrock）。 通过 tiktoken 实现 token 计数，支持多轮对话和流式输出。

4. 数据下载器（data_downloader.py）

提供了内置示例数据集下载器（example_data_downloader）， 支持 retrieval（检索）、graham_essays（小作文）等预置数据集，方便快速上手验证。

核心功能详解

快速单指标评估

最简单的用法是直接对一条数据运行单个指标：

from continuous_eval.metrics.retrieval import PrecisionRecallF1

datum = {
    'question': '法国的首都是哪里?',
    'retrieved_context': ['巴黎是法国的首都。', '里昂是法国城市。'],
    'ground_truth_context': ['巴黎是法国的首都。'],
    'answer': '巴黎',
    'ground_truths': ['巴黎'],
}
metric = PrecisionRecallF1()
print(metric(**datum))
# 输出: {'precision': 1.0, 'recall': 1.0, 'f1': 1.0}

数据集级评估（EvaluationRunner）

在真实使用场景中，你需要对整个数据集运行评估： EvaluationRunner 接收 Pipeline 和 Dataset，批量执行指标，并支持并行化：

runner = EvaluationRunner(pipeline)
eval_results = runner.evaluate()
print(eval_results.aggregate())
# 自动聚合所有模块的指标结果

模块化管道评估（Pipeline）

continuous-eval 最强大的功能是对多模块管道进行精细化评估： 以一个 3 步 RAG 管道为例：Retriever → Reranker → LLM Generator 每个模块独立配置指标：

• Retriever：用 PrecisionRecallF1 评估检索精确率和召回率。
• Reranker：用 RankedRetrievalMetrics（NDCG、MRR 等）评估排序质量。
• LLM Generator：用 AnswerCorrectness（LLM 裁判）评估答案正确性。

这种设计让开发者能精确定位管道中的性能瓶颈—— 是检索质量差（召回率低），还是生成器产生幻觉（正确性低）？ 一目了然，不再靠猜。

自定义指标（LLM-as-a-Judge）

对于没有内置指标的场景，CustomMetric 允许你用自然语言定义评判标准：

criteria = '检查回答是否包含 PII 或敏感信息'
rubric = 'Yes: 包含敏感信息 / No: 不包含'
custom = CustomMetric(criteria=criteria, rubric=rubric)

支持概率评分模式（probabilistic=True），输出置信区间而非点估计，适合生产环境。

部署与上手

安装方式：

pip install continuous-eval        # 基础版
pip install 'continuous-eval[semantic]'  # 含 sentence-transformers
pip install 'continuous-eval[anthropic]'  # Anthropic Claude 支持
pip install 'continuous-eval[all]'       # 全量依赖

依赖要求：Python 3.10-3.12，内存 1GB+，无需 GPU。 LLM 指标需要配置 API Key（.env 文件）：

OPENAI_API_KEY=sk-...
ANTHROPIC_API_KEY=sk-ant-...

评估执行注意：必须将代码包裹在 if __name__ == '__main__': 中， 因为评估过程使用了 multiprocessing 并行计算，缺少此入口会导致进程管理问题。

无 Web UI：这是一个纯 Python CLI 包，没有图形界面， 结果以结构化字典/Pydantic 模型形式返回，适合集成到自有监控系统。

无容器化：没有提供 Dockerfile 或 docker-compose.yaml， 生产环境部署需要手动配置 Python 虚拟环境或 conda 环境。

局限与争议

1. 依赖 LLM API 成本：LLM-as-a-Judge 指标（如 AnswerCorrectness、CustomMetric） 每次评估都调用 LLM API，对于大型数据集（如 10 万条），成本可能快速累积。 框架提供了确定性指标（PrecisionRecallF1）作为替代，但语义质量评估仍需 LLM。

2. 数据集质量瓶颈：评估结果的可靠性直接取决于 Ground Truth 数据集的质量。 构建高质量标注数据集（Golden Dataset）是公认的难题，continuous-eval 自身不提供数据集构建工具。

3. 评估的固有局限：LLM 裁判本身的偏见（position bias、length bias）是学术界广泛讨论的问题。 框架没有内置裁判偏见检测功能，需要用户自行设计实验（如 swap-order 测试）验证评分稳定性。

4. 不支持流式/实时评估：当前版本面向离线批处理，不支持实时流式数据的边跑边评。 对于需要在线监控生产管道的团队，需要自行封装监控层。

行业意义与趋势

continuous-eval 站在 LLM 应用工程化的关键节点上。 随着 RAG、Agent 架构成为主流，业界对"AI 质量可观测性"的需求正在爆发。

从技术趋势看，该项目代表三个方向的交汇：

1. MLOps for LLMOps：传统 ML 的评估体系（精确率/召回率/F1）正在被扩展到 LLM 场景， continuous-eval 是这一趋势的开源代表。

2. 自动化评估流水线：手动审核正在被自动化评估取代，CI/CD 中集成 AI 质量门禁（Quality Gate） 成为工程团队的标准需求。

3. 多模态评估萌芽：当前版本以文本为主，但代码指标（SQL、Python）的加入显示 多模态评估正在成为下一个发展方向。

GitHub 数据显示，该项目自 2024 年中发布以来稳定增长， 517 颗星、38 个 Fork、Apache-2.0 许可证，由 Relari 商业公司维护， 与 Y Combinator 生态深度绑定，后续商业化路径清晰。

总结

continuous-eval 是一款专为 AI 工程师设计的 LLM 应用评估框架， 核心优势在于模块化的评估管道设计 + 丰富的内置指标库 + 多 LLM 提供商支持。 它将"AI 质量"从玄学变为可量化、可复现、可集成的工程实践。

对于 RAG 开发者、Agent 构建者和 AI 质量保障团队，这是一款值得纳入工具箱的评估利器。 上手门槛低（pip 安装即用），但深度足够（支持自定义 LLM 裁判和模块化管道评估）。 主要局限是无容器化部署、无 Web UI、依赖高质量数据集和 LLM API 成本。

适合场景：RAG 质量评测、CI/CD 质量门禁、LLM 应用迭代对比实验。 不太适合：实时流式评估、无 LLM API 预算的低成本团队。