测评方法

引言 A/B测试是验证AI系统效果最可靠的方法。与其依赖基准分数，不如在真实用户中进行对照实验。2026年，A/B测试已经成为AI产品迭代的标配流程。本文将系统介绍AI系统A/B测试的实践方法。 A/B测试基础 什么是A/B测试 将用户随机分为两组：A组使用版本A（如GPT-5），B组使用版本B（如Claude 4），比较两组的关键指标。 AI系统A/B测试的独特性 输出不确定性：同一输入可能产生不同输出 延迟变化：不同模型的响应速度不同 成本差异：不同模型的API成本可能差10倍 多维评估：不仅看准确率，还要看用户满意度、延迟、成本 实验设计 步骤一：定义假设 假设：使用Claude 4替代GPT-5作为客服机器人后端， 用户满意度将提升5%以上，且API成本降低30%以上。 步骤二：选择指标 指标类型 具体指标 说明 主要指标 用户满意度评分 核心评估指标 次要指标 任务完成率、首次解决率 辅助评估 护栏指标 延迟、错误率、成本 确保不恶化 业务指标 留存率、转化率 最终业务价值 步骤三：计算样本量 from scipy import stats def calculate_sample_size(baseline_rate, mde, alpha=0.05, power=0.8): """ 计算所需样本量 baseline_rate: 基线指标值 mde: 最小可检测效应 alpha: 显著性水平 power: 统计功效 """ z_alpha = stats.norm.ppf(1 - alpha/2) z_beta = stats.norm.ppf(power) p1 = baseline_rate p2 = baseline_rate + mde p_avg = (p1 + p2) / 2 n = ((z_alpha * sqrt(2 * p_avg * (1 - p_avg)) + z_beta * sqrt(p1 * (1 - p1) + p2 * (1 - p2))) ** 2) / (p2 - p1) ** 2 return ceil(n) 步骤四：流量分配 方案一：50/50均分 - A组：50%流量 - B组：50%流量 - 优点：最快达到统计显著 - 缺点：风险较高（B可能更差） 方案二：90/10渐增 - A组：90%流量（对照组） - B组：10%流量（实验组） - 优点：风险可控 - 缺点：需要更长时间 推荐：先10%灰度，确认无问题后扩到50% 实验执行 流量路由 class ABTestRouter: def __init__(self, experiment_id, variants): self.experiment_id = experiment_id self.variants = variants # {"A": 0.5, "B": 0.5} def assign(self, user_id): """ 根据用户ID分配实验组 """ # 使用一致性哈希，确保同一用户始终在同一组 hash_value = hash(f"{self.experiment_id}:{user_id}") bucket = hash_value % 100 / 100 cumulative = 0 for variant, ratio in self.variants.items(): cumulative += ratio if bucket < cumulative: return variant return list(self.variants.keys())[-1] 实验配置 experiment_config = { "id": "exp_2026_07_gpt5_vs_claude4", "name": "GPT-5 vs Claude 4 客服对比", "start_date": "2026-07-01", "end_date": "2026-07-14", "variants": { "A": { "model": "gpt-5", "system_prompt": "v1.0", "temperature": 0.7 }, "B": { "model": "claude-4-opus", "system_prompt": "v1.0", "temperature": 0.7 } }, "allocation": {"A": 0.5, "B": 0.5}, "primary_metric": "user_satisfaction", "guardrail_metrics": ["latency_p95", "error_rate", "cost_per_session"], "sample_size": 10000 # 每组 } 数据收集 def log_experiment_event(user_id, variant, event_type, event_data): """ 记录实验事件 """ event = { "timestamp": datetime.now().isoformat(), "experiment_id": "exp_2026_07_gpt5_vs_claude4", "user_id": user_id, "variant": variant, "event_type": event_type, # "request", "response", "feedback" "event_data": event_data } # 写入数据仓库 data_warehouse.insert("ab_test_events", event) 结果分析 统计显著性检验 def analyze_experiment(results_a, results_b, metric="satisfaction"): """ 分析实验结果 """ # 描述性统计 stats_a = { "mean": mean(results_a[metric]), "std": std(results_a[metric]), "n": len(results_a) } stats_b = { "mean": mean(results_b[metric]), "std": std(results_b[metric]), "n": len(results_b) } # t检验 t_stat, p_value = stats.ttest_ind(results_a[metric], results_b[metric]) # 效应量 pooled_std = sqrt((stats_a["std"]**2 + stats_b["std"]**2) / 2) cohens_d = (stats_b["mean"] - stats_a["mean"]) / pooled_std # 置信区间 diff = stats_b["mean"] - stats_a["mean"] se = sqrt(stats_a["std"]**2/stats_a["n"] + stats_b["std"]**2/stats_b["n"]) ci_lower = diff - 1.96 * se ci_upper = diff + 1.96 * se return { "stats_a": stats_a, "stats_b": stats_b, "difference": diff, "p_value": p_value, "significant": p_value < 0.05, "effect_size": cohens_d, "confidence_interval": (ci_lower, ci_upper) } 护栏指标检查 def check_guardrails(results_a, results_b, thresholds): """ 检查护栏指标 """ alerts = [] # 延迟检查 if results_b["latency_p95"] > thresholds["latency_p95"]: alerts.append(f"延迟超标：B组P95={results_b['latency_p95']}ms") # 错误率检查 if results_b["error_rate"] > thresholds["error_rate"]: alerts.append(f"错误率超标：B组={results_b['error_rate']}") # 成本检查 if results_b["cost_per_session"] > thresholds["cost_per_session"]: alerts.append(f"成本超标：B组={results_b['cost_per_session']}") return alerts 常见陷阱 陷阱一：提前停止 实验还没达到所需样本量就因为"B看起来更好"而停止。 ...

引言 LLM应用的测试与传统软件测试截然不同：输入空间无限大、输出不确定、质量主观。2026年，LLM自动化测试已经形成了一套完整的方法论和工具链。本文将系统介绍如何构建LLM自动化测试体系。 LLM测试的挑战 挑战一：输入空间无限 传统软件的输入是结构化的（如表单字段），而LLM的输入是自由文本，可能的组合无限多。 挑战二：输出不确定 同一个输入，LLM可能给出不同的输出（即使temperature=0，不同版本也可能不同）。 挑战三：质量主观 “好的回答"的定义因任务、用户、上下文而异。 挑战四：成本高 每次测试都需要调用LLM API，大规模测试成本可观。 测试分层架构 ┌─────────────────────────────────┐ │ 端到端测试 (E2E) │ ← 模拟真实用户场景 ├─────────────────────────────────┤ │ 集成测试 │ ← 测试模块间协作 ├─────────────────────────────────┤ │ 提示测试 │ ← 测试提示效果 ├─────────────────────────────────┤ │ 单元测试 │ ← 测试单个功能 └─────────────────────────────────┘ 第一层：单元测试 测试LLM的基本功能： class TestLLMUnit: def test_json_output(self): """测试JSON输出格式""" response = llm.generate("输出JSON格式：{\"name\": \"test\"}") assert is_valid_json(response) def test_language_detection(self): """测试语言识别""" response = llm.generate("用中文回复：Hello") assert is_chinese(response) def test_length_constraint(self): """测试长度约束""" response = llm.generate("用50字以内回答：什么是AI？") assert len(response) <= 100 # 中文字符数 第二层：提示测试 测试提示在不同输入上的表现： class TestPrompt: def test_sentiment_analysis(self): """测试情感分析提示""" test_cases = [ {"input": "太棒了！", "expected": "positive"}, {"input": "太差了！", "expected": "negative"}, {"input": "还行吧。", "expected": "neutral"}, ] for case in test_cases: response = llm.generate(prompt.format(input=case["input"])) assert case["expected"] in response.lower() def test_robustness(self): """测试提示鲁棒性""" # 测试不同表述方式 inputs = [ "这部电影怎么样？", "你觉得这部电影如何？", "评价一下这部电影", ] responses = [llm.generate(prompt.format(input=i)) for i in inputs] # 检查输出是否一致（语义相似度） for i in range(len(responses)-1): similarity = compute_similarity(responses[i], responses[i+1]) assert similarity > 0.7 第三层：集成测试 测试多个模块协作： ...

引言 尽管自动评估和LLM-as-Judge在2026年已经非常成熟，但人工评估仍然是LLM评估的"黄金标准"。特别是对于创意写作、对话质量、文化敏感性等主观维度，人工评估不可替代。本文将系统介绍LLM人工评估的方法论。 为什么需要人工评估 自动评估的局限 创意任务：BLEU等指标无法衡量创意质量 文化敏感：自动指标无法检测文化不当内容 用户体验：用户满意度需要人类主观感受 安全边界：某些安全问题的判断需要人类常识 新颖性：自动指标倾向于奖励"常见"回答 人工评估的优势 可以评估主观维度 可以发现细微错误 可以判断文化适宜性 可以评估用户体验 可以提供改进建议 人工评估流程 步骤一：明确评估目标 评估目标: 评估对象: GLM-5 vs GPT-5 评估维度: - 回答准确性 - 表达流畅性 - 用户体验 - 安全性 评估任务: - 问答对话 (100条) - 创意写作 (50条) - 代码生成 (50条) - 多轮对话 (30组) 步骤二：设计评估规范 评分标准 ### 回答准确性（1-5分） 5分：完全正确，信息准确 4分：基本正确，有小瑕疵 3分：部分正确，有遗漏 2分：大部分错误 1分：完全错误 ### 表达流畅性（1-5分） 5分：表达自然流畅，无语法错误 4分：表达流畅，偶有小问题 3分：表达尚可，有一些不自然 2分：表达困难，语法错误多 1分：无法理解 ### 用户体验（1-5分） 5分：回答贴心、有帮助、超出预期 4分：回答有用、友好 3分：回答可以接受 2分：回答不太有用 1分：回答完全没用或令人不快 标注指南 ### 标注指南 1. 独立评估 - 请独立完成评估，不要参考其他评估者的评分 2. 不确定处理 - 如果不确定，请选择较低的分数 - 在"comment"字段说明不确定的原因 3. 安全性问题 - 如果回答包含以下内容，请标记为"unsafe"： - 歧视性言论 - 暴力内容 - 违法建议 - 隐私泄露 4. 文化敏感性 - 如果回答可能冒犯特定文化群体，请标记为"culturally_insensitive" 5. 对比评估 - 在对比两个模型时，请评估哪个"更好"，而不是分别打分 - "更好"的判断应该综合考虑所有维度 步骤三：选择评估者 评估者类型 类型 适用任务 成本 质量 领域专家 专业领域评估 高 最高 通用标注员 通用任务评估 中 中等 众包工人 简单分类任务 低 较低 用户群体 用户体验评估 中 高 评估者数量 每个样本建议3-5个评估者 计算评估者间一致性（Inter-Annotator Agreement） 如果一致性低（Krippendorff’s α < 0.6），需要修订标注规范 步骤四：执行评估 class HumanEvaluation: def __init__(self, config): self.config = config self.evaluators = self.recruit_evaluators(config) def create_evaluation_task(self, model_outputs): """ 创建评估任务 """ tasks = [] for output in model_outputs: task = { "id": output["id"], "input": output["input"], "output_a": output["model_a_output"], # 模型A输出 "output_b": output["model_b_output"], # 模型B输出 "dimensions": self.config["dimensions"], "guidelines": self.config["guidelines"] } tasks.append(task) return tasks def collect_results(self, tasks): """ 收集评估结果 """ results = [] for task in tasks: # 分发给多个评估者 evaluations = [] for evaluator in self.evaluators: eval_result = evaluator.evaluate(task) evaluations.append(eval_result) # 计算一致性 agreement = self.calculate_agreement(evaluations) # 如果一致性低，重新评估 if agreement < 0.6: evaluations = self.re_evaluate(task) results.append({ "task": task, "evaluations": evaluations, "agreement": agreement, "final_score": self.aggregate_scores(evaluations) }) return results 步骤五：分析结果 def analyze_evaluation_results(results): """ 分析人工评估结果 """ analysis = {} # 总体对比 model_a_wins = sum(1 for r in results if r["final_score"]["a"] > r["final_score"]["b"]) model_b_wins = sum(1 for r in results if r["final_score"]["b"] > r["final_score"]["a"]) ties = len(results) - model_a_wins - model_b_wins analysis["overall"] = { "model_a_win_rate": model_a_wins / len(results), "model_b_win_rate": model_b_wins / len(results), "tie_rate": ties / len(results) } # 按维度分析 for dim in ["accuracy", "fluency", "user_experience", "safety"]: dim_scores_a = [r["final_score"]["a"][dim] for r in results] dim_scores_b = [r["final_score"]["b"][dim] for r in results] analysis[dim] = { "model_a_avg": mean(dim_scores_a), "model_b_avg": mean(dim_scores_b), "p_value": t_test(dim_scores_a, dim_scores_b) } # 评估者一致性 analysis["agreement"] = { "avg_krippendorff_alpha": mean([r["agreement"] for r in results]), "low_agreement_cases": [r for r in results if r["agreement"] < 0.6] } return analysis 评估方法 方法一：绝对评分 让评估者对每个输出独立打分： ...

引言 Agent（智能体）的评估比传统LLM评估复杂得多。Agent不仅需要理解语言，还需要规划任务、调用工具、处理异常、与环境交互。传统的"输入-输出"评估模式无法捕捉Agent的多步骤、动态特性。本文将系统介绍2026年Agent评估基准的设计方法。 Agent能力维度 维度一：任务理解与规划 任务分解：将复杂任务分解为子任务 计划制定：为子任务制定执行顺序 动态调整：根据执行结果调整计划 维度二：工具调用 工具选择：选择正确的工具 参数生成：生成正确的工具参数 结果处理：正确处理工具返回结果 错误恢复：工具调用失败时的恢复策略 维度三：环境交互 网页操作：浏览网页、点击、输入 文件操作：创建、读取、修改文件 API调用：调用外部API 代码执行：编写并执行代码 维度四：记忆与上下文 短期记忆：当前任务的上下文 长期记忆：跨任务的知识积累 记忆检索：从记忆中检索相关信息 维度五：协作能力 多Agent协作：与其他Agent分工合作 人机协作：与人类用户交互 角色适应：根据角色调整行为 主流Agent基准 AgentBench AgentBench是最全面的Agent评估基准，覆盖8个场景： 场景 说明 评估指标 网页购物 模拟电商购物 任务完成率 网页浏览 浏览网页获取信息 信息准确率 数据库操作 SQL查询和数据操作 查询正确率 卡牌游戏 策略游戏 胜率 知识问答 多跳推理问答 准确率 房间设计 3D空间布局 满意度 操作系统 Linux命令操作 任务完成率 数据库管理 数据库维护 操作正确率 WebArena WebArena测试Agent在真实网页环境中的操作能力： 任务示例： 1. "在亚马逊上找到评分4星以上的无线耳机，加入购物车" 2. "在GitLab上创建一个新仓库，命名为'test-project'" 评估指标： - 任务完成率（Success Rate） - 步骤效率（Step Efficiency） - 路径准确率（Path Accuracy） ToolBench ToolBench评估工具调用能力： ...

引言 “我的模型到底好不好？“这是每个AI应用开发者都会面临的问题。基准测试分数高不等于实际效果好，通用基准可能不反映你的特定任务。2026年，LLM评估已经从简单的"看分数"进化到系统化的评估框架。本文将全面解析2026年的LLM评估方法。 评估的核心问题 问题一：评估什么 LLM的能力是多维度的，不能只用一个分数衡量： 知识理解：世界知识、专业知识 推理能力：逻辑推理、数学推理、因果推理 语言生成：流畅性、连贯性、创造性 指令跟随：格式遵守、约束遵循 安全性：拒绝有害请求、避免偏见 效率：推理速度、成本 问题二：怎么评估 静态基准：固定测试集（MMLU、GSM8K等） 动态评估：实时变化测试集（防数据污染） 人工评估：人类专家评估 模型评估：用强模型评估弱模型 实际应用评估：A/B测试、用户反馈 问题三：评估谁 通用能力：模型的基础能力 领域特定能力：在特定领域（医疗、法律等）的表现 任务特定能力：在特定任务上的效果 主流评估基准 知识与理解 基准 说明 评测维度 2026最高分 MMLU-Pro 57学科多任务理解 知识广度 91.3% (GPT-5) CMMLU 中文多任务理解 中文知识 89.7% (GLM-5) C-Eval 2026 中文综合评估 中文综合 92.1% (GLM-5) BBH BigBench Hard 复杂理解 88.5% (GPT-5) 推理能力 基准 说明 评测维度 2026最高分 GPQA Diamond 研究生科学推理 深度推理 82.3% (o3) GSM8K 小学数学推理 数学推理 96.8% (o3) MATH-500 高级数学竞赛 数学推理 96.8% (o3) ARC 科学推理 科学推理 96.2% (GPT-5) 代码能力 基准 说明 评测维度 2026最高分 HumanEval Python代码生成 代码生成 94.2% (GPT-5) SWE-Bench Verified 软件工程 工程能力 71.2% (GPT-5) MultiPL-E 多语言编程 多语言 89.3% (GPT-5) LiveCodeBench 实时编程竞赛 竞赛编程 72.5% (Claude 4) 安全性与对齐 基准 说明 评测维度 TruthfulQA 事实准确性 幻觉率 ToxiGen 毒性检测 安全性 BBQ 偏见检测 公平性 HarmBench 有害内容 安全拒绝率 Agent能力 基准 说明 评测维度 AgentBench Agent综合能力 工具调用、规划 WebArena 网页操作 实际任务 ToolBench 工具调用 API调用准确性 GAIA 通用AI助手 多步骤任务 评估框架设计 框架一：多维评估矩阵 class LLMEvaluationFramework: def __init__(self): self.dimensions = { "knowledge": ["MMLU-Pro", "CMMLU", "C-Eval"], "reasoning": ["GPQA", "GSM8K", "MATH"], "code": ["HumanEval", "SWE-Bench", "MultiPL-E"], "safety": ["TruthfulQA", "ToxiGen", "BBQ"], "agent": ["AgentBench", "WebArena"], "chinese": ["C-Eval", "CMMLU"] } def evaluate(self, model, dimensions=None): dimensions = dimensions or self.dimensions.keys() results = {} for dim in dimensions: benchmarks = self.dimensions[dim] results[dim] = {} for benchmark in benchmarks: score = run_benchmark(model, benchmark) results[dim][benchmark] = score return results def visualize(self, results): """ 生成雷达图，展示各维度能力 """ # ... 可视化代码 框架二：分层评估 第1层：通用能力评估 ├── 知识理解（MMLU-Pro） ├── 推理能力（GPQA, GSM8K） ├── 代码能力（HumanEval） └── 安全性（TruthfulQA） 第2层：领域能力评估 ├── 法律（LegalBench） ├── 医疗（MedQA） ├── 金融（FinBench） └── 教育（EduBench） 第3层：任务能力评估 ├── RAG效果评估 ├── 对话质量评估 ├── 摘要质量评估 └── 翻译质量评估 第4层：实际应用评估 ├── 用户满意度 ├── 任务完成率 ├── 响应延迟 └── 成本效率 框架三：对比评估 def comparative_evaluation(models, benchmarks): """ 对比评估多个模型 """ results = {} for model in models: results[model] = {} for benchmark in benchmarks: results[model][benchmark] = run_benchmark(model, benchmark) # 生成对比报告 report = generate_comparison_report(results) return report 评估中的常见陷阱 陷阱一：数据污染 训练数据中包含了测试集，导致分数虚高： ...

引言 2026年，AI编程工具已经从"代码补全"进化为"编程协作者"。本文对Cursor、GitHub Copilot、Claude Code、Codeium四款主流工具进行深度横评，从代码生成、调试、重构、测试等多个维度对比其能力。 评测方法论 评测维度 维度 权重 说明 代码生成质量 25% 生成的代码准确性、可读性 上下文理解 20% 对多文件项目的理解能力 调试能力 15% Bug定位和修复的准确性 重构能力 15% 代码重构的安全性和有效性 交互体验 15% 响应速度、UI/UX 集成生态 10% IDE支持、插件生态 测试数据集 开源项目：React、FastAPI、LangChain等 自定义任务：CRUD API、数据可视化、算法实现 真实项目：公司内部的微服务项目 各工具深度评测 Cursor 定位： AI-first IDE，专为AI编程设计 优势： 多模型支持（Claude、GPT-4、Gemini） 深度代码库索引，上下文理解能力强 Composer模式支持多文件协同编辑 内置Git集成，AI辅助提交 实测表现： 代码生成：⭐⭐⭐⭐⭐ 多模型切换灵活 上下文理解：⭐⭐⭐⭐⭐ 代码库索引全面 调试：⭐⭐⭐⭐ 错误定位准确 重构：⭐⭐⭐⭐⭐ 安全重构能力强 劣势： 仅支持VSCode内核 付费价格较高（$20/月起） 离线能力有限 GitHub Copilot 定位： 最成熟的AI编程助手 优势： 与GitHub生态深度集成 支持所有主流IDE Copilot Chat功能完善 企业级安全合规 实测表现： 代码生成：⭐⭐⭐⭐ 稳定但创新不足 上下文理解：⭐⭐⭐ 单文件为主 调试：⭐⭐⭐ 辅助定位 重构：⭐⭐⭐ 基础重构 劣势： ...

引言 评测是衡量Agent能力的唯一客观标准。2026年，Agent评测基准从单一任务型向综合型演进，覆盖了代码生成、网页操作、多轮对话、工具调用等多个维度。本文深度解析主流评测基准的设计理念和适用场景。 主流评测基准对比 GAIA（General Assistant Benchmark） 定位： 通用AI助手能力评测 设计特点： 真实场景任务：文件处理、邮件回复、数据分析 多模态输入：文本、表格、PDF 开放域：不限定特定领域 评测维度： 工具使用能力 信息整合能力 复杂任务分解 局限性： 评分标准主观性强 任务难度分布不均 SWE-bench（Software Engineering Benchmark） 定位： 代码问题修复能力评测 设计特点： 真实GitHub Issue 需要理解代码库并生成修复 自动验证（测试通过即成功） 评测维度： 代码理解 Bug定位 修复生成 测试验证 优势： 客观可验证 贴近真实开发场景 局限性： 仅覆盖代码场景 对大型代码库支持有限 AgentBench 定位： Agent工具使用能力评测 设计特点： 模拟操作系统环境 提供API和命令行工具 多步任务完成度 评测维度： 工具选择 参数生成 错误恢复 任务规划 WebArena 定位： 网页操作能力评测 设计特点： 模拟真实网站（电商、地图、邮件等） 需要GUI理解和操作 多步骤网页任务 评测维度： 网页理解 元素定位 操作序列规划 状态跟踪 评测方法论 评分体系 Agent能力 = f(任务完成度, 效率, 资源消耗, 安全性) 权重分配： ...

引言 2026年，大模型评估已经成为一门独立的学科。随着模型能力的提升，传统的评估方法越来越难以区分模型间的细微差异。如何科学、全面、客观地评估一个大模型，是开发者和企业选型的关键前提。本文将系统介绍大模型评估的方法论，从基准选择到实际测试，提供一套可操作的评估框架。 评估框架 四层评估体系 层级 评估内容 方法 适用阶段 L1: 标准基准 通用能力 公开基准测试 初步筛选 L2: 领域基准 专业能力 领域特定测试 深入评估 L3: 真实任务 实用能力 模拟真实场景 最终验证 L4: 人工评估 主观质量 专家盲评 质量把关 评估原则 多维度覆盖：不依赖单一基准 防数据污染：使用最新/私有测试集 控制变量：统一prompt、温度、采样参数 统计显著性：多次运行取平均 人机对齐：基准分数与人类判断对齐 L1: 标准基准 核心基准选择 基准 测试能力 难度 区分度 推荐 MMLU-Pro 专业知识 中 中 ✅ 必测 GPQA Diamond 推理 高 高 ✅ 必测 BBH 综合推理 中 中 ✅ 推荐 HumanEval+ 代码生成 中 低 ⚠️ 参考用 SWE-Bench Pro 工程能力 极高 高 ✅ 必测 IFEval 指令遵循 中 高 ✅ 必测 TruthfulQA 事实性 中 中 ✅ 推荐 MATH-500 数学 高 中 ⚠️ 参考用 基准选择的常见误区 误区1：只看MMLU ...

引言 中文大模型的能力评估远不止MMLU和C-Eval等标准化测试。真正的中文能力体现在对专业领域的深度理解、对中国文化语境的准确把握、以及对中文表达习惯的自然运用。本文设计了20个专业领域的深度测试，对2026年主流大模型进行全面的中文能力评估。 测试设计 20个专业领域 序号 领域 测试项数 评测维度 1 中国法律 50 法条引用准确性、案例分析合理性 2 中医中药 40 经典方剂、药理理解、诊疗逻辑 3 中国历史 50 史实准确性、因果分析、史料引用 4 古典文学 40 古文翻译、诗词鉴赏、文学理论 5 现代文学 30 作品分析、文学批评、创作模仿 6 财务会计 50 准则应用、分录编制、报表分析 7 税务筹划 40 税法理解、筹划方案、风险提示 8 医学诊断 50 症状分析、检查建议、治疗方案 9 药学知识 40 药物交互、剂量计算、不良反应 10 建筑工程 35 规范引用、结构计算、施工方案 11 电力系统 30 电网分析、故障诊断、调度方案 12 化学工程 35 反应机理、工艺设计、安全评估 13 农业技术 30 作物栽培、病虫害防治、土壤分析 14 教育学 40 教学设计、教育心理、评价方法 15 心理学 35 理论应用、案例分析、干预方案 16 新闻传播 30 选题策划、文案撰写、舆情分析 17 国际贸易 40 贸易规则、合同条款、风险控制 18 知识产权 35 专利分析、侵权判断、保护策略 19 中国方言 30 方言识别、翻译解释、文化背景 20 网络文化 25 流行语理解、梗文化、网络礼仪 评测模型 模型 定位 API来源 Qwen3.5 Max 阿里旗舰 阿里云 DeepSeek V4 推理旗舰 DeepSeek GLM-5-Plus 智谱旗舰 智谱AI GPT-5.5 OpenAI旗舰 OpenAI Claude Opus 4.1 Anthropic旗舰 Anthropic Gemini 3.5 Pro Google旗舰 Google Cloud Llama 4 405B Meta开源旗舰 Together AI 评测方法 每个领域的测试由3位领域专家独立评分： ...

RAG评估的困境 大多数RAG系统在上线时面临一个尴尬的问题：你知道它在工作，但你不知道它工作得有多好。 没有系统化的评估框架，调参就像蒙眼开车——你不知道改chunk_size从512到1024到底是好了还是坏了。 RAGAS（Retrieval Augmented Generation Assessment）是目前最流行的RAG评估框架，它提供了一套无需人工标注的自动化评估指标。 RAGAS核心指标体系 指标全景图 RAGAS 指标体系 │ ┌──────────────┼──────────────┐ ▼ ▼ ▼ 检索指标 生成指标 端到端指标 │ │ │ ┌─────┼─────┐ ┌────┼────┐ ┌────┼────┐ ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼ 上下文 上下文 ─ 忠实 答 答 语义 答案 精确率 召回率 度 案 案 相似 相关 相 完 关 整 性 性 四大核心指标详解 指标 评估什么 范围 理想值 Faithfulness（忠实度） 答案是否忠于检索到的上下文 0-1 >0.95 Answer Relevancy（答案相关性） 答案是否回答了用户问题 0-1 >0.85 Context Precision（上下文精确率） 检索到的上下文有多少是相关的 0-1 >0.80 Context Recall（上下文召回率） 回答问题所需的信息是否都检索到了 0-1 >0.85 指标计算原理 Faithfulness（忠实度） 衡量答案中的每个claim是否能从检索上下文中找到支撑。 ...