LLM 应用评估体系设计：指标、工具与自动化

引言：为什么需要专门的评估体系

1.1 LLM 应用与传统软件的根本差异

传统软件测试有一个基本假设：相同输入必然得到相同输出。但 LLM 应用打破了这个假设：

非确定性输出：即使输入完全相同，LLM 也可能给出不同回答。温度参数（temperature）控制随机性，但即使 temperature=0，不同模型、不同版本、甚至同一模型的不同调用，输出也可能有细微差异。

概率性错误：传统软件是”对/错”二元判断，LLM 是”好/更好/最好”的连续谱。一个回答可能”基本正确但有细节错误”，或者”方向正确但表述不清”。如何量化这种模糊性？

上下文依赖：LLM 的效果受历史对话、系统提示、few-shot 示例等多重因素影响。单独测试某个 Prompt 可能效果很好，但放到完整对话流程中就可能失效。

1.2 缺少验收标准的后果

我们团队在 AskBI 项目中踩过这些坑：

上线即翻车：测试环境用 50 个精心设计的问答对，准确率 95%。上线后真实用户提问，准确率掉到 70%。原因：测试数据没有覆盖真实场景的多样性。

无法量化改进：优化 Prompt 后，产品说”感觉更好了”，但无法证明。A/B 测试需要 2 周才能看到统计显著性，迭代太慢。

责任边界模糊：效果差时，模型团队说是数据问题，数据团队说是工程问题，工程团队说是模型问题。没有分层指标，无法定位问题层级。

1.3 评估体系的核心目标

可量化：每个层级都有明确指标，不是”感觉好”而是”准确率达到 92%”。

可复现：测试结果可以重复验证，不是”今天好明天差”。

可自动化：减少人工评估成本，支持持续集成和快速迭代。

---

评估体系设计原则

2.1 分层评估

LLM 应用通常有 3 个层级，每层关注点不同：

Prompt 层：单个交互的质量。关注回答的准确性、相关性、完整性。

RAG 层：检索与生成的协同。关注检索结果的召回率、生成内容的忠实度。

Agent 层：任务完成与工具调用。关注任务成功率、工具选择准确率、状态管理。

2.2 指标设计原则

可测量：必须有明确的计算方法，不能是主观判断。

有意义：与业务目标对齐，不是”为了测而测”。

可行动：指标异常时知道如何改进，不是”只能看不能改”。

2.3 测试数据设计

基准数据集：覆盖典型场景的固定测试集，用于版本对比。

边界案例：极端输入、模糊需求、对抗样本，用于压力测试。

真实数据：生产环境采样，持续更新，用于发现长尾问题。

---

Prompt 层级的评估指标

3.1 核心指标

准确率（Accuracy）：回答正确的比例。适合有明确答案的场景（如数学题、事实查询）。

相关性（Relevance）：回答与问题的相关程度，通常用 1-5 分人工评分。适合开放性问题。

完整性（Completeness）：是否覆盖问题的所有子问题。适合复杂问题（如”分析 A 并给出 B 建议”）。

一致性（Consistency）：多次调用的输出稳定性。相同问题调用 5 次，输出语义一致的比例。

3.2 测试方法

黄金测试集：准备 50-100 个标准问答对，覆盖典型场景。

人工评分：3 人独立评分，取平均值，减少个人偏差。

自动化评估：用另一个 LLM 作为评判模型（LLM-as-a-Judge），但需要定期人工抽检校准。

3.3 合格标准示例

准确率 ≥ 90%
相关性 ≥ 4.0/5.0
完整性 ≥ 85%
一致性 ≥ 80%（相同问题 5 次调用，输出语义一致的比例）

3.4 常见问题与调优方向

准确率低 → 优化系统提示、增加 Few-shot 示例、调整模型温度。

相关性低 → 调整温度参数、优化问题重写、增加上下文。

完整性低 → 在 Prompt 中明确要求”分点回答”、“覆盖所有子问题”。

一致性低 → 降低温度（如 0.1）、增加随机种子控制、简化输出格式。

---

RAG 层级的评估指标

4.1 检索质量指标

召回率（Recall@K）：正确答案是否在前 K 个检索结果中。K 通常取 5 或 10。

精确率（Precision@K）：前 K 个结果中有多少是相关的。

MRR（Mean Reciprocal Rank）：正确答案的排名倒数平均值。排名越靠前，分数越高。

NDCG（Normalized DCG）：考虑排名位置的加权评分，排名越靠前权重越大。

4.2 生成质量指标

忠实度（Faithfulness）：生成内容是否基于检索到的上下文，不编造信息。

答案相关性（Answer Relevance）：最终答案与问题的相关程度。

上下文利用率（Context Utilization）：检索内容被引用的比例，避免检索了大量但只用了一部分。

4.3 端到端指标

答案准确率：最终答案是否正确，综合检索和生成的效果。

拒绝率：无法回答时的拒绝比例。应控制在合理范围（如 5-10%），太高说明检索能力不足，太低可能产生幻觉。

幻觉率：生成内容中事实错误的比例，应尽可能低（< 5%）。

4.4 测试方法

检索测试：固定问题集，评估检索结果质量，不关心生成。

生成测试：固定检索结果，评估生成质量，不关心检索。

端到端测试：完整流程，评估最终答案，反映真实效果。

4.5 合格标准示例

Recall@5 ≥ 95%
Precision@3 ≥ 80%
MRR ≥ 0.85
忠实度 ≥ 90%
幻觉率 ≤ 5%

4.6 常见问题与调优方向

召回率低 → 优化分块策略（chunk size）、增加嵌入维度、调整相似度阈值。

精确率低 → 优化重排序（Re-ranking）、增加元数据过滤、调整 Top-K。

忠实度低 → 在 Prompt 中强调”仅基于上下文回答”、“不知道就说不知道”。

• 幻觉率高 → 增加引用要求（“请标注信息来源”）、设置置信度阈值、过滤低分结果。

---

Agent 层级的评估指标

5.1 任务完成指标

任务成功率（Task Success Rate）：任务最终完成的比例。Agent 的核心指标。

步骤准确率（Step Accuracy）：每一步工具调用的正确率。定位哪一步容易出错。

平均步骤数（Average Steps）：完成任务所需的平均工具调用次数。越少越好，但不应以牺牲成功率为代价。

超时率（Timeout Rate）：超过最大步骤数仍未完成的比例。反映任务复杂度或 Agent 规划能力。

5.2 工具调用指标

工具选择准确率：选择正确工具的比例。Agent 需要理解”用什么工具做什么事”。

参数准确率：工具参数的正确率。选对工具但参数错误，任务仍会失败。

工具执行成功率：工具调用成功（无异常）的比例。反映工具稳定性和参数格式。

冗余调用率：不必要的工具调用比例。如重复查询、无效尝试。

5.3 状态管理指标

状态一致性：多轮对话中状态维护的正确性。如”记住用户之前选的选项”。

错误恢复率：遇到错误后成功恢复的比例。反映容错能力。

人工介入率：需要人类协助的比例。越低越好，但关键任务需要人工确认。

5.4 测试方法

场景测试：设计典型任务场景（如”创建环境并部署”），覆盖完整流程。

压力测试：复杂任务、多步骤、边界条件，测试极限能力。

对抗测试：故意提供错误信息、模糊需求，测试鲁棒性。

5.5 合格标准示例

任务成功率 ≥ 85%
步骤准确率 ≥ 90%
平均步骤数 ≤ 预期步骤数 × 1.5
超时率 ≤ 10%
工具选择准确率 ≥ 95%
人工介入率 ≤ 15%

5.6 常见问题与调优方向

任务成功率低 → 优化技能设计（更清晰的工具描述）、增加错误处理、降低任务复杂度。

步骤准确率低 → 改进工具描述（更详细的参数说明）、增加 Few-shot 示例、优化系统提示。

冗余调用高 → 优化系统提示（“避免重复调用”）、增加状态记忆、合并相似工具。

人工介入率高 → 明确任务边界（“哪些能做哪些不能”）、增加确认环节（关键操作前让用户确认）。

---

自动化测试框架设计

6.1 框架架构

测试数据层（JSON/CSV）
    ↓
测试执行层（并发调用、结果收集）
    ↓
评估层（指标计算、阈值判断）
    ↓
报告层（可视化、趋势分析）

6.2 核心组件

测试数据管理：版本化（Git）、分类（Prompt/RAG/Agent）、标签（场景/难度）。

测试执行器：支持并发（提高速度）、限流（避免超限）、重试（处理临时失败）。

评估引擎：指标计算（准确率/召回率等）、阈值判断（是否合格）、异常告警。

报告生成器：HTML/PDF 报告、图表可视化（趋势图/分布图）、邮件通知。

6.3 实现示例（Python）

from dataclasses import dataclass
from typing import List, Dict
import json

@dataclass
class TestCase:
    id: str
    input: str
    expected: str  # 期望输出或评估标准
    layer: str  # prompt/rag/agent
    tags: List[str]

class LLMTestSuite:
    def __init__(self, test_data_path: str, model_config: Dict):
        self.test_cases = self.load_test_cases(test_data_path)
        self.model = LLMClient(model_config)
        
    def load_test_cases(self, path: str) -> List[TestCase]:
        with open(path) as f:
            data = json.load(f)
        return [TestCase(**case) for case in data]
    
    def run_prompt_tests(self) -> Dict:
        results = []
        for case in self.filter_by_layer('prompt'):
            output = self.model.generate(case.input)
            score = self.evaluate_prompt_output(output, case.expected)
            results.append({
                'case_id': case.id,
                'score': score,
                'output': output
            })
        return self.calculate_metrics(results)
    
    def evaluate_prompt_output(self, output: str, expected: str) -> float:
        # 可以用另一个 LLM 作为评判模型
        judge_prompt = f"""
        问题：{expected['question']}
        期望答案：{expected['answer']}
        实际输出：{output}
        
        请评分（0-1 分）：
        """
        judge_output = self.judge_model.generate(judge_prompt)
        return self.extract_score(judge_output)
    
    def calculate_metrics(self, results: List[Dict]) -> Dict:
        scores = [r['score'] for r in results]
        return {
            'accuracy': sum(scores) / len(scores),
            'pass_rate': sum(1 for s in scores if s >= 0.8) / len(scores),
            'total_cases': len(results)
        }

6.4 持续集成

Git Hook：提交前运行快速测试（如 10 个核心用例），防止明显回归。

CI Pipeline：每次 PR 运行完整测试（如 50-100 个用例），生成报告附在 PR 中。

定时任务：每日/每周运行全量测试（如 200+ 用例），跟踪长期趋势，发现退化。

---

工具链与资源

7.1 开源工具

RAGAS：RAG 评估框架，提供忠实度、相关性、召回率等指标。支持自动化评估。

TruLens：LLM 应用评估平台，支持多指标、可视化、A/B 测试。

LangSmith：LangChain 官方评估工具，集成度高，支持追踪和调试。

DeepEval：通用 LLM 评估库，支持多种指标和自定义评估函数。

7.2 自建工具

基准数据集管理：版本化（Git）、标注工具（Label Studio）、去重和平衡。

自动化评分器：LLM-as-a-Judge 实现，定期人工校准，避免评判模型偏差。

可视化看板：指标趋势（时间序列）、分布图（分数分布）、异常告警（邮件/钉钉）。

7.3 推荐配置

# test_config.yaml
test_config:
  prompt:
    temperature: 0.1  # 低温度，提高一致性
    max_tokens: 512
    top_p: 0.9
    
  rag:
    top_k: 5
    similarity_threshold: 0.7
    rerank: true
    
  agent:
    max_steps: 128
    timeout_seconds: 300
    retry_count: 3
    
  evaluation:
    judge_model: "gpt-4-turbo"  # 评判模型
    human_sample_rate: 0.1  # 10% 人工抽检
    alert_threshold:
      accuracy_drop: 0.05  # 准确率下降 5% 告警
      timeout_rate: 0.15  # 超时率超过 15% 告警

---

实战案例：AskBI 智能问答评估

8.1 项目背景

AskBI 是企业级 BI 智能问答系统，用户可以用自然语言查询业务指标（如”上个月销售额是多少”）。

技术架构：RAG + Agent

• RAG：检索指标文档、SQL 模板
• Agent：生成 SQL、执行查询、解释结果

挑战：需要支持 100+ 个业务指标，指标定义复杂（如”活跃用户”有多种定义），SQL 生成容易出错。

8.2 评估体系设计

Prompt 层：

• SQL 生成准确率：生成的 SQL 是否正确
• 自然语言理解准确率：是否正确理解用户意图

RAG 层：

• 指标文档召回率：是否能找到相关指标定义
• SQL 模板匹配率：是否能找到合适的 SQL 模板

Agent 层：

• 多步查询成功率：复杂查询（如”对比上个月和今年”）的成功率
• 工具调用准确率：选择正确工具（查询/计算/可视化）

8.3 测试结果（第 4 版）

Prompt 层：
  - SQL 生成准确率：92%
  - 自然语言理解准确率：88%
  
RAG 层：
  - 指标文档召回率@5：96%
  - SQL 模板匹配率：85%
  
Agent 层：
  - 多步查询成功率：82%
  - 工具调用准确率：94%
  - 平均步骤数：3.2（预期 2-4 步）

8.4 优化迭代

第 1 版 → 第 2 版：准确率从 77% 提升到 92%（+15%）

• 优化 Prompt：增加 Few-shot 示例、明确 SQL 格式要求
• 增加指标文档：补充 20 个常见指标的详细说明

第 2 版 → 第 3 版：召回率从 86% 提升到 96%（+10%）

• 优化分块策略：从固定 500 字符改为按语义分块
• 增加重排序：用 Cross-Encoder 对检索结果重排序

第 3 版 → 第 4 版：任务成功率从 74% 提升到 82%（+8%）

• 增加错误处理：SQL 执行失败时尝试修复或换方案
• 优化状态管理：记住用户之前的筛选条件

---

总结与最佳实践

9.1 核心要点回顾

分层评估：Prompt/RAG/Agent 各有侧重，不能混为一谈。

指标设计：可测量、有意义、可行动，不是”为了测而测”。

自动化：减少人工成本，支持持续集成和快速迭代。

9.2 最佳实践清单

• 建立基准数据集（至少 50 个测试用例，覆盖典型场景）
• 定义合格标准（每个层级都有明确阈值，如准确率≥90%）
• 自动化测试流程（CI/CD 集成，每次提交自动运行）
• 定期人工抽检（防止自动化偏差，如 10% 抽样）
• 持续跟踪趋势（发现退化及时告警，如准确率下降 5%）

9.3 常见陷阱

过度依赖自动化：LLM-as-a-Judge 也有偏差，需定期人工校准。

测试数据偏差：基准数据集不能覆盖所有场景，需持续补充真实数据。

指标游戏：优化指标不等于优化体验，需关注真实用户反馈（如满意度调查）。

9.4 下一步行动

1. 评估当前项目：测试覆盖度如何？哪些层级缺少评估？
2. 选择一个层级开始：从 Prompt 层开始最简单，逐步扩展到 RAG 和 Agent。
3. 建立基准数据集：收集 50-100 个典型用例，版本化管理。
4. 自动化测试流程：集成到 CI/CD，每次提交自动运行。
5. 持续迭代优化：根据测试结果调整 Prompt、检索策略、技能设计。

---

相关文章：

• [[LangGraph 复杂状态机设计模式]]
• [[LLM 在垂直领域的微调策略]]
• [[轻量级 Agent 开发方案：基于 Skill 插件的工具调用循环]]