前言

Github：https://github.com/HealerJean

博客：http://blog.healerjean.com

一、评估测试

1、核心概念

1）什么是 AI 评估测试

让另一个 AI 当 “裁判”，检查生成的回答好不好、对不对、有没有胡说八道。

目的：

• 防止 AI 幻觉（Hallucination）
• 保证回答和上下文相关
• 保证回答事实准确

2）Evaluator 评估器接口

@FunctionalInterface
public interface Evaluator {
    EvaluationResponse evaluate(EvaluationRequest evaluationRequest);
}

a、评估请求 (EvaluationRequest)

public class EvaluationRequest {

	private final String userText;

	private final List<Content> dataList;

	private final String responseContent;

	public EvaluationRequest(String userText, List<Content> dataList, String responseContent) {
		this.userText = userText;
		this.dataList = dataList;
		this.responseContent = responseContent;
	}

  ...
}

b、相关性评估器 (RelevancyEvaluator)

RelevancyEvaluator 是 Evaluator 接口的一个实现，旨在评估 AI 生成的响应与所提供上下文的相关性。此评估器通过确定 AI 模型的响应是否与用户输入以及检索到的上下文相关，来帮助评估 RAG 流的质量。

• 目的：判断 AI 的回答是否切题且符合上下文。
  • 只看：回答和问题、上下文是否相关
  • 不判断事实真假，只判断是否相关
  • 输出：YES / NO
• 原理：将“问题 + 上下文 + 回答”发给 LLM，让 LLM 回答 YES/NO。
• 适用场景：验证 RAG 流程是否正常工作，回答是否跑题
  • 问 “苹果手机”，AI 回答 “安卓很好用” → 不相关 → NO
  • 问 “苹果手机”，AI 回答 “iPhone15 搭载 A17” → 相关 → YES

• 默认提示模板：RelevancyEvaluator 使用的默认提示模板

  • Your task is to evaluate if the response for the query
    is in line with the context information provided.
        
    You have two options to answer. Either YES or NO.
        
    Answer YES, if the response for the query
    is in line with context information otherwise NO.
        
    Query:
    {query}
        
    Response:
    {response}
        
    Context:
    {context}
        
    Answer:
    

c、事实核查评估器 (FactCheckingEvaluator)：

• 目的：判断 AI 有没有 “胡说八道、造假、幻觉”

• 原理：将“文档 + 主张”发给专门的核查模型（如 Bespoke-Minicheck），检测幻觉。

  • 严格对比上下文，检查事实是否一致
  • 适合对抗幻觉
  • 推荐用小而专的模型：minicheck、专用核查模型

• 适用场景：金融、医疗等对准确性要求极高的场景。

  • 上下文：地球是第 3 颗行星
  • AI 回答：地球是第 4 颗行星
    • → 事实错误 → 不通过

• 默认提示词：其中 {document} 是上下文信息，{claim} 是待评估的 AI 模型响应。

  • Document: {document}
    Claim: {claim}
    

3）使用建议

• 生成模型：负责聊天、回答（可以大而全）
• 评估模型：负责判断对错（可以更小、更快、更专业）
• 比如：生成用 Qwen，评估用 minicheck
• 成本更低、结果更准

2、案例实战

1）案例1：相关性评估 (RelevancyEvaluator)

// ========================================================================
// 1. 相关性评估（RelevancyEvaluator）
// 功能：判断 AI 回答是否与问题 + 上下文相关
// URL: GET  http://localhost:8080/ai/eval/relevancy?question=地球有几颗天然卫星？&context=地球只有一颗天然卫星，叫月球。&aiResponse=地球有一颗天然卫星，是月球。
// ========================================================================
@GetMapping("/relevancy")
public EvaluationResponse relevancy(
        @RequestParam String question,
        @RequestParam String context,
        @RequestParam String aiResponse) {
    // 构建评估器
    RelevancyEvaluator evaluator = new RelevancyEvaluator(chatClientBuilder);

    // 构建评估材料
    EvaluationRequest request = new EvaluationRequest(question, List.of(new Document(context)), aiResponse);

    // 执行评估
    return evaluator.evaluate(request);
}



GET http://localhost:8080/ai/eval/relevancy?question=地球有几颗天然卫星？&context=地球只有一颗天然卫星，叫月球。&aiResponse=地球有一颗天然卫星，是月球。
{
  "feedback": "",
  "metadata": {},
  "pass": true,
  "score": 1.0
}



GET http://localhost:8081/ai/eval/relevancy?question=地球有几颗天然卫星？&context=我是一个人&aiResponse=地球有一颗天然卫星，是月球。
{
  "feedback": "",
  "metadata": {},
  "pass": false,
  "score": 0.0
}

2）案例2：事实核查评估（FactCheckingEvaluator）

// ========================================================================
// 2. 事实核查评估（FactCheckingEvaluator）
// 功能：检查 AI 是否造假、幻觉
// URL: GET http://localhost:8080/ai/eval/fact-check?context=地球是太阳系第三颗行星。&aiResponse=地球是第四颗行星。
// ========================================================================
@GetMapping("/fact-check")
public EvaluationResponse factCheck(
        @RequestParam String context,
        @RequestParam String aiResponse
) {
    FactCheckingEvaluator evaluator =  FactCheckingEvaluator.builder(chatClientBuilder).build();

    EvaluationRequest request = new EvaluationRequest(context, List.of(new Document(context)), aiResponse);

    return evaluator.evaluate(request);
}


GET http://localhost:8080/ai/eval/fact-check?context=地球是太阳系第三颗行星。&aiResponse=地球是第四颗行星。
{
  "feedback": "",
  "metadata": {},
  "pass": false,
  "score": 0.0
}

3）案例3： RAG 完整流程 + 自动双重评估

// ========================================================================
// 3. RAG 完整流程 + 自动双重评估（检索→回答→相关性→事实核查）
// URL: GET http://localhost:8080/ai/eval/rag-evaluate
// ========================================================================
@GetMapping("/rag-evaluate")
public String ragEvaluate(@RequestParam String question) {
    // 1. 从向量库检索相关上下文
    List<Document> docs = vectorStore.similaritySearch(question);
    String context = docs.stream()
            .map(Document::getText)
            .reduce("", (a, b) -> a + "\n---\n" + b);

    // 2. AI 生成回答
    String aiAnswer = chatClient.prompt()
            .system("基于以下上下文回答，不要编造：\n" + context)
            .user(question)
            .call()
            .content();

    // 3. 构建评估请求
    EvaluationRequest request = new EvaluationRequest(question, List.of(new Document(context)), aiAnswer);

    // 4. 双重评估
    RelevancyEvaluator relEval = new RelevancyEvaluator(chatClientBuilder);
    FactCheckingEvaluator factEval = FactCheckingEvaluator.builder(chatClientBuilder).build();

    boolean relPass = relEval.evaluate(request).isPass();
    boolean factPass = factEval.evaluate(request).isPass();

    // 5. 返回结果
    return """
            【用户问题】
            %s

            【参考上下文摘要】
            %s

            【AI 回答】
            %s

            【评估结果】
            相关性：%s
            事实准确性：%s
            """.formatted(
            question,
            context.length() > 200 ? context.substring(0, 200) + "..." : context,
            aiAnswer,
            relPass ? "✅ 相关" : "❌ 不相关",
            factPass ? "✅ 事实正确" : "❌ 事实错误/幻觉"
    );
}




GET http://localhost:8081/ai/eval/rag-evaluate?question=地球有几颗天然卫星？

【用户问题】
地球有几颗天然卫星？

【参考上下文摘要】

---
Spring Boot 是快速开发Spring应用的框架，自动配置、内嵌服务器。
---
Spring AI 是Spring官方推出的AI开发框架，支持RAG、智能对话、函数调用。
---
Java 是跨平台编程语言，广泛用于企业级开发。

【AI 回答】
根据您提供的上下文信息，无法回答地球有多少颗天然卫星的问题。上下文内容仅涉及Spring Boot和Spring AI框架的相关信息，未包含天文学或地球卫星数据。

【评估结果】
相关性：✅ 相关
事实准确性：✅ 事实正确
  
  
  
GET http://localhost:8081/ai/eval/rag-evaluate?question=Spring Boot 是快速开发Spring应用的框架  对吗。
  
  【用户问题】
Spring Boot 是快速开发Spring应用的框架  对吗。

【参考上下文摘要】

---
Spring Boot 是快速开发Spring应用的框架，自动配置、内嵌服务器。
---
Spring AI 是Spring官方推出的AI开发框架，支持RAG、智能对话、函数调用。
---
Java 是跨平台编程语言，广泛用于企业级开发。

【AI 回答】
是的，根据提供的上下文信息，Spring Boot 被描述为“快速开发Spring应用的框架，自动配置、内嵌服务器”。因此该说法正确。

【评估结果】
相关性：✅ 相关
事实准确性：✅ 事实正确

二、模型评测

1、模型评测核心认知

1）什么是模型评测？

简单来说，就是给模型出一套测试题。

• 过程：准备测试数据 -> 模型作答 -> 自动或人工打分 -> 生成报告。
• 目的：客观、量化地评估大语言模型（LLM）的表现。

2）为什么要进行评测？（四大核心场景）

a、场景1：模型选型决策

问题：面对十几个大模型（千问、GPT、Claude、文心一言等），不知道哪个更适合我的业务。

解决方案：

1. 准备100条业务场景的测试数据
2. 用相同数据评测所有候选模型
3. 对比评测报告（得分、通过率、典型样本表现）
4. 选择最符合业务需求的模型

价值：

• 避免主观判断，用数据说话
• 节省人工逐个测试的时间
• 降低选型错误的风险

b、场景2：模型调优效果验证

问题：对千问进行了模型调优（提供了1000条训练数据），不确定调优是否真的有效。

解决方案：

1. 准备评测数据集（与训练集不重叠）
2. 分别评测调优前和调优后的模型
3. 对比两次评测结果：
   • 调优前得分：75分
   • 调优后得分：85分
   • 结论：调优有效，提升了10分

价值：

• 量化调优效果，验证投入是否值得
• 识别调优方向是否正确

c、场景3：模型能力量化评估

问题：需要向团队或管理层汇报模型在特定任务上的表现，但缺少客观数据。

解决方案：

1. 使用评测功能生成评测报告
2. 报告包含：
   • 综合得分：85/100
   • 通过率：90%（达到3分阈值的样本占比）
   • 分数分布：5分30条、4分40条、3分20条、2分10条
   • 典型案例：高分样本、低分样本
3. 用报告数据支撑决策和汇报

价值：

• 用数据替代主观描述（”还不错” → “得分85分，通过率90%”）
• 便于跨团队沟通和对齐认知
• 为后续优化提供基线参考

d、场景4：持续监控模型表现

问题：模型上线后，随着时间推移或业务变化，模型表现可能下降，但很难及时发现。

解决方案：

1. 建立定期评测机制（如每月一次）
2. 使用相同的评测数据集和评测维度
3. 追踪模型表现趋势：
   • 2024年1月：得分85
   • 2024年2月：得分87（提升）
   • 2024年3月：得分78（下降，需要排查）

价值：

• 及时发现模型表现下降
• 为模型迭代提供数据依据
• 建立模型能力档案

3）评测流程图

4）评测模式选择(自定义 vs 基线)

a、自定义评测：为你的业务“量体裁衣”

自定义评测的核心在于“业务贴合度”。通用的考试分数高，不代表模型能处理好你公司的具体业务（比如特定的客服话术或医疗问诊）。

• 核心逻辑：你需要自己充当“出题人”和“阅卷老师”。你需要准备一份包含“问题”和“标准答案（或期望回答）”的 Excel 数据集，然后定义一套评分规则（评测维度）。
• 如何运作：
  • 数据准备：你上传自己的测试集（例如 100 条真实的用户咨询日志）。
  • 裁判机制：通常使用一个更强的模型（如千问-Max）作为“裁判模型”，或者使用特定的算法（如语义相似度）来给待测模型的回答打分。
  • 评分标准：你可以设定具体的维度，比如“是否包含了免责声明”、“语气是否亲切”、“是否准确提到了产品A的价格”。
• 适用场景：
  • RAG（检索增强生成）应用：验证模型是否能准确利用知识库回答问题。
  • 垂直领域：如法律、医疗、金融，这些领域有特定的术语和合规要求，通用榜单无法覆盖。
  • 风格控制：要求模型扮演特定角色（如“傲娇的二次元助手”），通用评测无法评估这种主观风格。

b、基线评测：行业通用的“体检报告”

基线评测的核心在于“横向对比”。它使用的是学术界和工业界公认的标准数据集，用来衡量模型在通用能力上的“硬实力”。

• 核心逻辑：参加“标准化考试”。系统内置了如 C-Eval（中文综合评测）、MMLU（大规模多任务语言理解）等权威数据集。你不需要准备题目，只需要把模型放进去跑分。
• 如何运作：
  • 无需准备数据：直接选择系统预置的评测集（涵盖数学、推理、常识、代码等）。
  • 自动化打分：对于客观题（选择、判断），系统自动计算准确率；对于部分主观题，也有标准化的评分逻辑。
  • 结果对标：得分可以直接与榜单上的其他模型（如 Llama 3, GPT-4 等）进行对比，看你的模型处于什么水平。
• 适用场景：
  • 模型选型：在决定使用哪个基座模型前，先看它的基线分数。
  • 微调效果验证：当你微调模型后，需要确认模型是否发生了“灾难性遗忘”（即学会了新知识，但变笨了，连基本的数学题都不会了）。
  • 能力边界探索：了解模型在逻辑推理或代码生成上的天花板在哪里。

c、组合拳策略

在实际的模型开发和落地过程中，建议采取“先基线，后自定义”的组合策略：

1. 第一阶段（基线评测）：当你刚拿到一个开源模型或准备微调时，先跑一遍 基线评测。确保模型的基础智商（逻辑、语言理解）没有硬伤，并以此为基准线
2. 第二阶段（自定义评测）：在模型投入业务前，构建你的“业务金集” (Golden Dataset)。收集 50-100 个真实的业务 Bad Case，进行自定义评测。重点关注模型是否解决了具体的业务痛点（如：幻觉问题、格式遵循问题）。
3. 第三阶段（人工盲测）：对于两个模型分数咬得很死，或者涉及复杂主观体验（如文案的感染力）时，使用人工盲测（类似竞技场模式），让人类专家在不知道模型身份的情况下进行投票，这是最终的“仲裁”。

三、评测维度详解

评测维度就是评分标准，决定了如何给模型打分。自定义评测必须先创建评测维度。

1、5 种评测纬度

2、评测纬度介绍

1）大模型评估-数值型 (AI裁判打分 1-5分)

• 原理：利用一个“裁判模型”（作为阅卷老师，给被测模型打分（1-5分）。
• 适用场景：需要判断“好坏程度”而不仅仅是“对错”的场景，比如回答是否专业、是否有帮助。
• 配置关键：
  • 评分器 Prompt：告诉裁判模型怎么打分（如综合评测、语义相似度模板）。
  • 核心变量：${prompt} (用户问题), ${output} (模型回答), ${completion} (参考答案/标准答案)。
• 举例说明：
  • 场景：电商客服回复质量。
    • 题目：用户问：“我的订单为什么还没发货？”
    • 标准答案：“非常抱歉让您久等了，我们查询到您的订单因仓库缺货正在补货中，预计明天发出。”
    • 模型回答A：“还没好呢，等等吧。” -> 裁判模型打分：1分（态度恶劣，信息缺失）。
    • 模型回答B：“由于库存原因，您的订单正在处理中。” -> 裁判模型打分：3分（信息有，但不够完整）。
    • 模型回答C：“抱歉久等，查询到因仓库缺货正在补货，预计明天发出。” -> 裁判模型打分：5分（完美匹配）。

2）大模型评估-分类型 (AI裁判分类 Pass/Fail)

• 原理：裁判模型判断结果是“通过/不通过”或“是/否”。同样是利用“裁判模型”作为老师，但老师不需要打分，只需要判断模型的回答是否符合某个特定条件，输出“通过”或“不通过”（或者“是/否”、“安全/不安全”）。
• 适用场景：内容安全审核、答案正确性判断（Pass/Fail）。

• 配置关键：在 Prompt 中详细说明每个标签（如“安全/不安全”）的判定条件。

• 举例说明：
  • 场景：内容安全审核。
    • 任务：判断模型回答是否包含暴力内容。
    • 模型回答：“我觉得有时候解决问题需要一点强硬的手段……”（未提及暴力）。
    • 裁判模型判断：Pass（安全）。
    • 模型回答：“直接打爆他的头就好了。”
    • 裁判模型判断：Fail（包含暴力，不通过）。

3）规则评估-文本相似度 (算法计算相似度)

• 原理：使用算法计算模型输出与标准答案的相似度，不依赖裁判模型，不看模型用的词是否和标准答案一模一样，只看“语义意思”是否接近。系统通过算法（如 BLEU、ROUGE）计算两个句子的相似度。

• 适用场景：答案表达方式可以多种多样，但核心意思要对。如翻译、摘要、改写。

• 举例说明：
  • 场景：新闻摘要生成。
    • 原文：“昨日晚高峰，北京国贸桥发生严重拥堵，持续了2个小时。”
    • 标准答案：“北京国贸桥晚高峰大堵车。”
    • 模型回答：“北京国贸桥在昨天的高峰期出现了长时间的交通瘫痪。”
    • 分析：虽然字不一样，但意思完全一样。
    • 结果：算法计算出相似度为 0.9（满分1），判定为优秀。

4）规则评估-字符串匹配 (精确字符串匹配)

• 原理：精确匹配字符串。“死记硬背题”。这是最机械的评判方式。系统会检查模型的输出中是否包含特定的字符、单词或代码。
• 适用场景：代码生成、函数调用（Function Calling）、数据库查询（NL2SQL），这些领域必须精确无误。
• 匹配规则：
  • 相等：完全一致（如城市名称）。
  • 包含：输出中包含特定关键词（如必须包含 query_weather）。
  • 开头/结尾包含：校验格式前缀或后缀。
• 举例说明：
  • 场景：智能助手调用天气函数。
    • 用户问：“今天北京天气怎么样？”
    • 正确动作：模型必须输出代码指令 {"name": "get_weather", "arguments": {"city": "北京"}}。
    • 评判：系统设置“字符串包含”规则
      • 只要模型输出里有 get_weather 这个词，就判定为 通过。
      • 如果模型只说了“北京今天晴天”，但没有调用函数，判定为 失败。

5）人工评估-分类型 (人工打标签)

• 原理：由人工打标签，“专家评审团”。当机器算法和裁判模型都无法判断好坏时（比如涉及审美、创意、极其专业的领域），就需要真人介入打分。
• 适用场景：创意性评估、专业质量审核（当算法无法判断时）。

• 配置关键：编写《评测指南》，培训标注员，建议多名评分员交叉标注以降低主观误差。

• 举例说明：
  • 场景：生成品牌Slogan。
    • 任务：为一款新潮运动鞋生成广告语。
    • 模型回答：“这是一双红色的运动鞋，穿着很舒服。”
      • 人工评判：标签“较差”（太直白，没有创意）。
    • 模型回答：“点燃街头，一步入魂。”
      • 人工评判：标签“优秀”（有感染力，符合品牌调性）。

3、评测纬度选型

1. 想看模型“回答得好不好”（通用）？ -> 选 大模型评估-数值型（最常用）。
2. 想看模型“意思对不对”（翻译/摘要）？ -> 选 规则评估-文本相似度。
3. 想看模型“有没有违规/犯错”？ -> 选 大模型评估-分类型。
4. 想看模型“代码/关键词准不准”？ -> 选 规则评估-字符串匹配。
5. 机器搞不定，必须人眼定乾坤？ -> 选 人工评估-分类型。

4、评测维度设计最佳实践

1）单一职责：

• 每个评测维度只关注一个评测目标
• 避免混合多个标准
• 例如：不要在”准确性”维度中同时考核”流畅性”

2）量化标准：

• 尽量使用客观、可量化的标准
• 减少主观性
• 为每个分数档提供明确的判定条件

3）迭代优化：

• 根据评测结果反馈，持续优化 Prompt
• 定期人工抽查，验证评测准确性
• 对比人工评分和 AI 评分，调整评测标准

四、数据准备与流程

1、 数据来源

1）数据来源类型

a、评测数据集 (Prompt + Completion)：

• 说明：包含问题（prompt）和参考答案（completion）

  • 类比：“现场考试”：老师（系统）把试卷（Prompt）发给学生（模型），学生现场做完（生成 Output），老师再拿着标准答案（Completion）去批改。

• 数据格式：

  Prompt (题目)	Completion (标准答案)
  中国的首都是哪里？	北京
  2+2等于多少？	4

• 工作流程：系统调用模型实时推理 → 生成output → 评分器打分
  • 系统读取：读取到“中国的首都是哪里？”。
  • 实时调用：系统呼叫模型 ·A：“请问中国的首都是哪里？”
  • 模型作答：模型 A 思考后回答：“北京”。
  • 评分：系统让裁判模型对比“北京”和标准答案“北京”，打分 5 分。
  • 重复：再呼叫模型B，问同样的问题，看模型B表现如何。

• 场景：

  • 模型选型：你想知道 GPT-4 和 千问-Max 谁更强，必须让它们都现场做这套题，然后对比分数。

  • 效果验证：你刚给模型写了新的 Prompt（提示词），想看它现在回答得好不好。

b、推理结果集 (Prompt + Completion + Output)：

• 说明：已包含模型输出，系统直接读取结果评分（用于降低重复推理成本）。

  • 类比“存档复查”：老师（系统）手里不仅有试卷和标准答案，还有一份去年某个学生（比如千问-Turbo）做好的试卷（Output）。老师这次不想让这个学生重考了，直接拿他去年的答案去打分。

• 数据格式：

  Prompt (题目)	Completion (标准答案)	Output (模型之前的回答)
  中国的首都是哪里？	北京	中国的首都是北京，是一座历史悠久的城市…
  2+2等于多少？	4	2+2的结果是4。

• 工作流程：系统直接读取 output → 评分器打分（不推理）

  • 系统读取：读取到“中国的首都是哪里？”以及“模型之前的回答”。
  • 跳过推理：系统不呼叫模型，直接跳过“做题”环节。
  • 直接评分：系统让裁判模型直接对比“模型之前的回答”和“标准答案”，打分 4 分。
  • 用途：这个分数代表了“这个模型以前的表现”。你可以把它作为一个基准（Baseline）。

• 适用场景：

  • 基准对比：你想证明“我新调优的模型比旧模型强”。你可以把旧模型的历史回答（推理结果集）作为“基准线”，然后看新模型的分数是否超过了这条线。
  • 成本控制：你有一个包含 10,000 条数据的庞大测试集。如果每次评测都让模型重做一遍，费用极高且耗时。你可以只做一次（生成推理结果集），以后只用这个结果集来跑评分，节省大量金钱。

2）数据格式

• Prompt：用户的问题或指令。
• Completion：参考答案（标准答案）。
• Output：模型生成的回答（仅推理结果集需要）。

3）数据量建议：

4）如何选择

1. 如果你是第一次评测，手里只有问题和标准答案：
   • 选：评测数据集。必须让模型先做题。
2. 如果你想对比“模型A”和“模型B”：
   • 选：评测数据集。让系统用同一套题目，分别考模型A和模型B。
3. 如果你已经评测过“模型A”，并且想保留它的成绩作为标准：
   • 操作：在第一次评测（评测数据集）完成后，系统通常会自动生成一份包含 Output 的报告。
   • 选：把这份报告下载下来，作为推理结果集保存。
   • 用途：下次评测新模型时，你可以把这份“

2、评测流程

1. 创建评测维度：定义评分标准（如“常识问答准确性”）。
2. 准备测试数据：整理Excel文件。
3. 创建评测任务：选择模型、数据和维度。
4. 查看报告：分析得分、通过率和典型样本。

3、结果分析与对比

1）排行榜

a、什么是排行榜：

• 用于对比多个模型在同一评测维度上的表现
• 可视化展示模型优劣排序
• 支持多个评测任务的横向对比

b、何时需要排行榜：

• 需要对比多个模型的表现（如 GPT-4 vs Claude vs 千问）
• 想要可视化展示模型在业务场景中的优劣
• 需要在团队内部分享模型对比结果

c、使用建议：

• 对比同一系列不同规格的模型（如 qwen-max、qwen-plus、qwen-turbo）
• 对比不同供应商的模型（如千问 vs DeepSeek）
• 对比同一模型的不同版本或配置

2）结果分析方法

a、关注分数分布：

• 查看各分数档的样本数量
• 识别分数集中的问题（如全部集中在3分）
• 调整评分标准或阈值

b、分析典型样本：

• 查看高分样本：了解模型优势
• 查看低分样本：识别模型不足
• 查看边界样本：优化评测标准

c、对比不同模型：

• 不要只看总分，要看不同场景下的表现
• 识别各模型的强项和弱项
• 根据业务优先级选择合适的模型

d、追踪模型迭代：

• 建立定期评测机制
• 记录每次调优后的评测结果
• 分析调优方向是否正确

3）常见问题排查

a、评测结果不符合预期：

1. 检查测试数据是否代表业务场景
2. 审查评测维度的 Prompt 是否清晰
3. 尝试调整评分范围和阈值
4. 考虑更换裁判模型或评分器模板

b、评分过于集中：

1. 评分标准过于宽泛 → 细化每个分数档的描述
2. 测试数据缺乏多样性 → 增加边界和异常样本
3. 裁判模型倾向保守 → 更换推理能力更强的模型

c、不同评测维度结果冲突：

1. 这很正常，说明模型在不同维度有不同表现
2. 根据业务优先级，赋予不同维度不同权重
3. 不要只看单一维度，要综合决策

五、成本优化与计费

模型评测会产生费用，主要由两部分组成（目前裁判模型评分限时免费）：

1、计费构成

• 被评测模型推理费用：调用模型生成答案产生的 Token 费用。
• 裁判模型评分费用：调用裁判模型打分产生的费用

2、降本技巧

1）合理选择评测方式：

• 格式化验证用规则评估（成本极低）。
• 语义理解用大模型评估（成本中等）。
• 创意类用人工评估（成本高，慎用）。

2）使用推理结果集：

• 对于需要频繁评测的基准模型，将其输出保存为推理结果集
• 避免重复调用模型，降低推理成本

3）分阶段评测：

• 先用小规模数据集（50-100条）验证配置
• 确认配置正确后，再扩大到200-500条

4）批量评测：

• 一次评测多个模型，提高效率
• 在同一个评测任务中选择多个模型