llm-evaluation（LLM评估）Skill 是什么？如何下载安装？

LLM评估Skill：用自动化指标 + 人工反馈 + LLM 裁判，把大模型应用的质量真正管起来

• 一句话定位：llm-evaluation 是一套面向大型语言模型（LLM）应用的「评估方法论 + 可复用代码」技能，覆盖自动化指标、人工评估、LLM 作为裁判、A/B 测试、回归检测与基准测试六大环节。
• 解决的核心痛点：LLM 输出具有随机性，传统「输入-断言-通过」的单元测试无法覆盖；很多团队只能靠肉眼看几条回答就上线，质量风险不可控。
• 最有价值的三个模块：EvaluationSuite（统一评估套件）、LLM 作为裁判（单点评分 / 成对比较 / 基于参考 / 无参考）、RegressionDetector（上线前自动发现指标回归）。
• 适合谁用：做 RAG 问答、AI 客服、内容生成、智能体的算法工程师、AI 应用开发者与测试/质量团队。
• 上手门槛：需要具备基础 Python 能力，并理解 BLEU、F1、NDCG 等常见指标的适用边界；技能已把实现骨架铺好，按需替换模型与数据集即可。

该技能叫什么？如何下载安装 AI 技能提升开发效率

基本信息

项目	内容
技能中文名	LLM评估Skill
技能英文名	llm-evaluation
技能ID	13220
技能定位	大型语言模型应用的全面评估策略与实现参考

它到底解决什么问题

大模型应用与传统软件最大的差异在于「没有唯一正确答案」。同一句提示词，模型两次输出可能完全不同；提示词改一个字，整体效果可能悄悄变差；换一个模型版本，昨天还好好的 RAG 问答今天开始一本正经地胡说。这类问题无法用普通断言测试发现，必须建立一套可量化、可复现、可持续追踪的评估体系。llm-evaluation 技能把这件事拆成三层：

1. 自动化指标层：用 BLEU、ROUGE、BERTScore、准确率、F1、MRR、NDCG 等计算型分数，实现快速、可重复、可扩展的批量评估；
2. 语义判断层：用更强的 LLM 充当裁判（LLM as Judge），对准确性、有帮助性、清晰度等难以公式化的维度打分或做 A/B 对比；
3. 人工与统计层：提供标注表结构、评估者间一致性（Cohen’s kappa）、T 检验与 Cohen’s d 效应量，保证结论在统计上站得住。

一键安装思路与步骤

AI 技能类产品通常采用「检索 → 安装 → 调用」的极简路径，关键在于装完之后确认它真的生效了：

1. 确认安装前提：准备好可运行 Python 的环境；技能示例中涉及 nltk、rouge_score、bert_score、transformers、scikit-learn、scipy 等常用评估依赖，具体依赖清单与版本要求以官方说明为准。
2. 找到技能入口：在所用 AI 技能平台/技能市场中，用技能英文名 llm-evaluation 或技能 ID 13220 检索并安装；具体安装命令、入口位置与是否收费以官方说明为准。
3. 验证是否生效：安装完成后，向助手提一个典型问题，例如「用 llm-evaluation 技能帮我搭一个包含 BLEU 和 BERTScore 的评估套件，并给出一条测试样例」，若能返回带中文注释的 EvaluationSuite 代码与用法说明，即说明技能已正常加载。
4. 接入自己的模型：把示例里的 your_model 替换成你自己的模型或链路（同步接口用 await 包一层即可），把 test_cases 换成你的真实业务样例。
5. 落到流程里：把评估脚本接入 CI/CD，形成「每次改提示词 / 换模型 → 自动跑评估 → 有回归就拦截」的闭环。

该技能的主要功能和特点

• 三类核心评估范式的完整覆盖：自动化指标、人工评估、LLM 作为裁判，三者互为补充，避免「只盯一个指标」的常见误判。
• 指标按任务类型分类给出：文本生成（BLEU、ROUGE、METEOR、BERTScore、困惑度）、分类（准确率、精确率/召回率/F1、混淆矩阵、AUC-ROC）、检索增强生成（MRR、NDCG、Precision@K、Recall@K），选指标时不会「拿翻译指标评摘要」。
• 开箱即用的 EvaluationSuite：用 Metric 数据类 + EvaluationSuite 组合多个指标，异步遍历测试集，最终输出每个指标的均值与全部原始分数，便于二次分析。
• LLM 裁判四种模式：单点评分（llm_judge_quality）、成对比较（compare_responses）、基于参考的评估（evaluate_against_reference）、无参考判断，并用 Pydantic 模型约束返回结构（如 1-10 分区间、winner 只能取 A/B/tie），避免裁判输出难以解析。
• 自定义指标脚手架：给出 groundedness（基于 NLI 判断回答是否被上下文蕴含）、toxicity（毒性检测）、factuality（事实性核验）三个可复用实现，直接对应 RAG 场景最痛的「幻觉」问题。
• 人工评估框架：提供 AnnotationTask 结构化标注表（准确性/相关性/连贯性 1-5 分 + 事实错误、幻觉、跑题、不安全内容勾选项 + 文字反馈），并用 Cohen’s kappa 量化标注者一致性，附带「轻微 / 一般 / 中等 / 显著 / 几乎完美」的解释标准。
• 统计严谨的 A/B 测试：ABTest 类自动跑 T 检验，输出均值差、相对提升、p 值、是否统计显著，并计算 Cohen’s d 效应量与「可忽略 / 小 / 中等 / 大」的解释，避免把噪声当优化。
• 回归检测器：RegressionDetector 设定阈值（默认 5%），逐指标比较基线与新结果，返回是否回归、回归清单与摘要，可直接用于上线卡点。
• 基准测试运行器：BenchmarkRunner 输出每个指标的均值、标准差、最小值、最大值，让「平均分涨了但方差爆炸」这种问题无处藏身。
• 生态集成与最佳实践：包含 LangSmith 数据集与评估器集成示例（qa、context_qa、cot_qa），并附 8 条最佳实践与 7 个常见陷阱（单一指标痴迷、样本量小、数据污染、忽略方差、指标与业务目标不匹配、成对评估的位置偏差、提示过拟合）。

和普通做法比强在哪：普通做法是「写几个 if 判断 + 人工抽查几条」，本技能提供的是从指标选型、裁判提示词、统计检验到回归门禁的完整方法论骨架，拿来即可落地，不必从零设计评估体系。

如何使用该技能？

第 1 步：明确评估目标与任务类型

先回答三个问题：要评的是生成、分类还是检索？有没有标准答案（参考文本）？失败代价最大的是哪一类错误（事实错误？跑题？不安全？）。这决定了后续指标组合。

第 2 步：构建测试集（test_cases）

每条用例建议包含 input（问题）、expected（参考答案）、context（检索到的上下文），例如：

test_cases = [
    {
        "input": "法国的首都是哪里？",
        "expected": "巴黎",
        "context": "法国是欧洲的一个国家，巴黎是它的首都。"
    },
]

注意事项：测试集要贴近真实线上分布，样本量不能太小，且绝不能与训练数据重叠（详情中明确把「数据污染」列为常见陷阱）。

第 3 步：组合指标并运行评估套件

suite = EvaluationSuite([
    Metric.accuracy(),                                  # 准确性
    Metric.bleu(),                                      # N-gram 重叠
    Metric.bertscore(),                                 # 语义相似度
    Metric.custom("groundedness", check_groundedness)   # 是否基于上下文
])

results = await suite.evaluate(model=your_model, test_cases=test_cases)
# 返回 {"metrics": {指标名: 平均分}, "raw_scores": {指标名: [逐条分数]}}

第 4 步：用 LLM 作为裁判补充语义维度

自动化指标算不出「回答是否有帮助」，这时调用 llm_judge_quality(response, question, context)，返回结构类似：

{
  "accuracy": 9,
  "helpfulness": 8,
  "clarity": 10,
  "reasoning": "答案准确，但缺少对边界的说明"
}

若要比较两个版本，用 compare_responses(question, response_a, response_b)，返回 winner（A/B/tie）、reasoning 与 1-10 的 confidence。

第 5 步：做 A/B 统计检验，判断提升是真是假

把两个版本的逐条分数分别 add_result("A", score) 和 add_result("B", score)，再调用 analyze()，输出包含 p_value、statistically_significant、cohens_d、effect_size、winner 的字典。只有当 p 值小于 0.05 且效应量不为「可忽略」时，才值得宣布「新版本更好」。

第 6 步：设置回归门禁并持续跟踪

用一次稳定版本的评估结果作为 baseline_results，之后每次改动都调用 check_for_regression(new_results)，若返回 has_regression: True，说明至少有一个指标相对下降超过阈值，应当阻断发布并做错误分析。

第 7 步（可选）：接入 LangSmith 做实验管理

用 Client 创建数据集与样例，配置 LangChainStringEvaluator("qa") 等评估器，执行 evaluate() 并用 experiment_prefix 标记版本（如 v1.0.0），即可在平台侧对比多轮实验。

同类型竞品对比分析

方案名称	定位	核心功能	安装/使用门槛	适用场景	优势与不足
llm-evaluation（本技能）	评估方法论 + 可复用代码骨架	三类评估范式、指标实现、LLM 裁判、人工标注、A/B 统计、回归检测、基准测试	需 Python 基础；依赖按需安装；入口以官方说明为准	想自建评估体系、需要掌控全部逻辑与数据	优势：体系完整、可裁剪、无平台绑定、附最佳实践与陷阱清单；不足：需要自己维护数据集与运行环境
LangSmith	商业化 LLM 应用可观测与评估平台	数据集管理、实验追踪、内置评估器（qa/context_qa/cot_qa）、可视化对比	需接入 SDK 与平台账号，费用以官方说明为准	团队协作、需要长期留存实验记录与看板	优势：开箱即用、可视化好、实验管理成熟；不足：依赖外部平台，深度定制受限于其接口
RAGAS	专注 RAG 场景的评估框架	面向检索增强生成的指标（忠实度、上下文相关性等）	安装 Python 库即可，学习曲线中等	纯 RAG 问答链路的专项评估	优势：RAG 指标专注、开箱即用；不足：覆盖范围偏窄，分类任务、A/B 统计、人工标注框架需另行补齐
DeepEval	单元测试风格的 LLM 评估库	以「测试用例 + 断言」方式写评估，易接入 CI	安装 Python 库，需理解其断言范式	想把评估写成测试用例、集成到流水线	优势：CI 友好、写法接近 pytest；不足：统计检验、标注一致性等分析能力需自建
自研脚本	完全自行实现	只做团队最关心的几个指标	零依赖新增，但设计与维护成本高	需求极简、临时验证	优势：完全可控、无额外依赖；不足：易陷入单一指标、缺少统计严谨性与回归门禁

选型建议：如果只是快速看一眼 RAG 效果，先用 RAGAS；如果团队需要长期实验管理与协作，用 LangSmith 打底；如果希望把评估逻辑握在自己手里、又不想从零设计方法论，llm-evaluation 的骨架最合适——它本身就是方法论参考，也天然可以与上述工具组合使用（详情中已给出与 LangSmith 的集成示例）。

该技能的典型应用场景与实际体验情况

场景一：RAG 知识库问答上线前的质量把关

• 角色与痛点：算法工程师做企业知识库问答，最怕模型「不看检索结果自己编」。传统做法只能人工抽 20 条看运气。
• 使用方式：测试集里带上 context，组合 accuracy + bertscore + 自定义 groundedness（基于 NLI 判断回答是否被上下文蕴含），一次性跑完数百条，输出每个指标的均值与原始分数，对 groundedness 低分的样本做错误分析。
• 实际体验：上手门槛主要在数据集构建，代码部分几乎可以照抄；效果好，尤其是 groundedness 这类自定义指标，能直接把「幻觉率」变成一个可追踪的数字。注意事项：NLI 模型对中文效果需要实测，lang 参数与模型选择要按实际语言调整。

场景二：提示词改版的 A/B 决策

• 角色与痛点：产品经理和算法同学争论「新版提示词到底有没有更好」，谁也说服不了谁。
• 使用方式：同一批测试用例分别跑 A/B 两个提示词，分数收集到 ABTest，调用 analyze() 得到相对提升、p 值与 Cohen’s d。
• 实际体验：这一步是很多团队的「认知升级点」——不少看起来涨了 3% 的改动，统计上并不显著，效应量为「可忽略」。注意事项：样本量必须足够，成对评估时要注意详情中提到的「位置偏差」，需随机化 A/B 顺序。

场景三：模型升级或依赖变更的回归拦截

• 角色与痛点：平台团队统一升级模型版本，多个业务线悄悄出现质量下降，往往靠用户投诉才发现。
• 使用方式：以稳定版本结果作为 baseline_results，用 RegressionDetector 对新结果做逐指标对比，5% 阈值触发告警，接入 CI 后形成发布门禁。
• 实际体验：这个模块的价值在长期——一次配置、持续受益。注意事项：基线要定期更新，否则会成为「永远拦不住」或「永远拦得住」的失效门禁。

场景四：内容安全与事实性人工抽检

• 角色与痛点：运营与风控团队需要对生成内容做人工质检，但不同人打分标准差得离谱，结论无法复用。
• 使用方式：用 AnnotationTask 统一标注表（准确性/相关性/连贯性 1-5 分 + 幻觉、跑题、不安全内容勾选），多人标注后用 Cohen’s kappa 检查一致性，低于 0.4 就说明标注规范需要重新对齐。
• 实际体验：结构化的标注表显著降低了沟通成本；kappa 的解释分级（轻微/一般/中等/显著/几乎完美）让团队有了客观的对齐标准。注意事项：先小样本试点跑通规范，再放大标注量。

该技能能为用户带来的价值

• 把「感觉还行」变成「数字说话」：从单一的主观抽查，升级为多指标、带统计检验的量化结论，团队决策从争论转向看数据。
• 显著缩短评估体系建设周期：指标实现、裁判提示词、标注表、A/B 统计、回归检测这五套东西如果从零设计，通常需要数周；技能直接给出可用骨架，通常一天内就能跑通第一版。
• 降低专业门槛：BLEU 与 BERTScore 该用在哪、p 值和效应量怎么读、标注一致性怎么算，这些原本需要评估经验的知识，被写进代码与最佳实践中，初级工程师也能用对。
• 提前拦截质量事故：回归检测把「上线后才发现变差」变成「上线前就知道会变差」，避免的每一次线上事故都是直接的成本节省。
• 可量化的长期收益：有了稳定基线，每次提示词优化、模型切换、RAG 检索策略调整都能给出「提升百分比 + 是否显著 + 效应量大小」的完整证据链，让迭代方向不再靠猜。
• 生态友好，不锁定：技能本身是方法论与代码骨架，可与 LangSmith、RAGAS、DeepEval、Arize Phoenix 等工具组合使用，不绑定任何单一平台。

常见问题 FAQ

Q1：这个技能怎么安装？需要付费吗？

A：在所用 AI 技能平台中，通过英文名 llm-evaluation 或技能 ID 13220 检索并安装即可，安装完成后用「帮我搭一个包含 BLEU 和 BERTScore 的评估套件」这类问题验证是否生效。是否需要付费、有哪些依赖需要预装，以官方说明为准。技能内容本身包含完整的 Python 实现示例，可直接复制到本地工程中使用。

Q2：我不会写复杂代码，能用吗？

A：可以，但需要基础 Python 能力。技能的 EvaluationSuite、ABTest、RegressionDetector 等类都是「填参数即用」的结构，你主要需要准备三样东西：自己的模型调用方式、测试集（输入 + 期望输出 + 上下文）、以及选择哪几个指标。真正的门槛不在代码，而在测试集质量——用例是否贴近真实线上分布，直接决定评估结论是否可信。

Q3：自动化指标和 LLM 作为裁判，我该用哪个？

A：建议两者结合使用，这也是技能反复强调的「多种指标」原则。自动化指标（BLEU、ROUGE、BERTScore、F1、NDCG 等）胜在快速、便宜、可重复，适合大批量回归与流水线门禁；LLM 裁判胜在能评估「有帮助性、清晰度、是否真正回答了问题」这类公式化不了的维度，适合做小批量深度判断与版本对比。只用其中一种，很容易陷入详情中列出的「单一指标痴迷」陷阱。

Q4：和 LangSmith、RAGAS、DeepEval 相比，我该选哪个？

A：三者定位不同。RAGAS 专注 RAG 场景指标，适合快速验证检索增强链路；LangSmith 是平台型方案，强在实验管理、可视化与团队协作；DeepEval 是单元测试风格，适合想把评估写进 CI 的团队。本技能更偏「评估方法论 + 全流程代码骨架」，覆盖从指标选型到统计检验、回归门禁、人工标注的完整链条，且不绑定平台。实践中常见组合是：用本技能搭评估框架与统计逻辑，用 LangSmith 或 RAGAS 补充平台与专项指标能力。

Q5：评估跑出来的分数涨了，就一定说明新版本更好吗？

A：不一定。技能里专门提供了 ABTest 与 T 检验、Cohen’s d 效应量，就是为了防止把随机波动当成优化成果：p 值未低于 0.05 或效应量为「可忽略」时，谨慎下结论。另外还要注意详情列出的几个坑——样本量太小、测试集与训练数据重叠（数据污染）、只盯一个指标而牺牲其他维度、以及针对测试集反复调提示词造成的「提示过拟合」。