评测
评测
生成指标、基准、裁判模型和安全测试。
069 · 中 · 为什么传统的 NLP 评估指标(如 BLEU, ROUGE)对于评估现代 LLM 的生成质量来说,存在很大的局限性?
来源:Hello-Agents Extra01
传统的NLP评估指标,如BLEU(常用于机器翻译)和ROUGE(常用于文本摘要),其核心思想是比较模型生成的文本与一个或多个“参考答案”在表层词汇(n-gram)上的重合度。这种方法对于评估现代LLM的生成质量存在巨大局限性,原因如下:
- 语义理解的缺失(Lack of Semantic Understanding):
- 这些指标只关心词汇的表面匹配,完全不理解其背后的语义。例如,“今天天气很好”和“今天日光很灿烂”,在人类看来意思相近,但它们的BLEU/ROUGE得分会很低,因为词汇重合度小。反之,一个与参考答案词汇高度重合但语法不通或逻辑混乱的句子,也可能得到高分。
- 无法评估事实准确性(Cannot Evaluate Factual Accuracy):
- LLM的核心挑战之一是幻觉。一个生成的答案可能在语言上非常流畅,甚至与参考答案的风格相似,但包含完全错误的事实。BLEU/ROUGE无法检测出这种事实性错误。
- 忽略了多样性与创造性(Ignores Diversity and Creativity):
- 对于开放式生成任务(如对话、写作、头脑风暴),根本不存在唯一的“标准答案”。一个好的LLM应该能生成多样化、有创意且合理的回答。而基于固定参考答案的评估方法会“惩罚”任何与参考答案不同但同样优秀的回答,扼杀了创造性。
- 对长文本的评估能力差(Poor for Long-form Content):
- 这些指标在评估长篇文本(如文章、报告)的连贯性(Coherence)、逻辑性和结构性方面几乎是无能为力的。它们只能进行局部、零碎的词汇匹配。
- 对推理过程的无视(Ignores Reasoning Process):
- 对于需要推理的问题(如数学题、逻辑题),LLM的价值不仅在于最终答案,更在于其“思维链”。BLEU/ROUGE只能比较最终答案的字符串,完全无法评估推理步骤是否正确。
总之,现代LLM的评估需要超越表层词汇,深入到语义理解、事实性、逻辑推理、安全性、遵循指令等更高维度的能力层面,而这正是BLEU和ROUGE等传统指标的盲区。
070 · 中 · 请介绍几个目前行业内广泛使用的 LLM 综合性基准测试,并说明它们各自的侧重点。(例如:MMLU, Big-Bench, HumanEval)
来源:Hello-Agents Extra01
为了更全面地评估LLM的能力,学术界和工业界开发了许多综合性基准测试。其中,MMLU、Big-Bench和HumanEval是最具代表性的几个,它们各自有不同的侧重点:
- MMLU (Massive Multitask Language Understanding)
- 侧重点: 知识的广度与学科问题解决能力。
- 简介: MMLU是一个大规模的多任务测试集,旨在衡量模型在各种学科领域的知识水平。它包含57个不同的科目,涵盖了从初等数学、美国历史、计算机科学到专业级别的法律、市场营销和医学等。
- 形式: 所有问题都是四选一的单项选择题。
- 评估目的: 检验模型是否具备渊博的、跨学科的知识储备和应用这些知识解决问题的能力。一个在MMLU上得分高的模型,通常被认为是一个“知识渊博”的模型。
- Big-Bench (Beyond the Imitation Game Benchmark)
- 侧重点: 探索LLM的能力边界和未来潜力。
- 简介: Big-Bench是一个由社区协作创建的、极其多样化的基准,包含了超过200个任务。这些任务被设计得非常有挑战性,旨在测试当前LLM难以解决的能力,如常识推理、逻辑、物理直觉、创造性任务等。
- 形式: 任务形式非常多样,包括选择题、生成题、比较题等。
- 评估目的: Big-Bench的目标是“预测未来”。它试图找到那些一旦模型规模或技术发展到某个临界点就可能“涌现”出的新能力。它衡量的是模型的通用智能水平和前沿能力。
- HumanEval (Human-Labeled Evaluation)
- 侧重点: 代码生成与编程能力。
- 简介: HumanEval是一个由OpenAI创建的、专门用于评估代码生成能力的基准。它包含164个手写的编程问题,每个问题都提供了函数签名、文档字符串(docstring)、以及几个单元测试(unit tests)。
- 形式: 模型需要根据函数签名和文档字符串,生成完整的Python函数体。
- 评估方法: 采用 pass@k 指标。即模型生成k个代码样本,只要其中至少有一个能够通过所有的单元测试,就算通过。这衡量了模型编写正确、可用代码的能力。
其他重要基准:
- GSM8K: 专注于评估小学水平的数学应用题的推理能力,需要模型进行多步的思维链推理。
- ARC (AI2 Reasoning Challenge): 专注于评估需要科学常识和推理的、有挑战性的选择题。
- HellaSwag: 专注于评估常识推理,任务是选择一个最合理的句子来续写一个给定的情景。
071 · 中 · 什么是“LLM-as-a-Judge”?使用 LLM 来评估另一个 LLM 的输出,有哪些优点和潜在的偏见?
来源:Hello-Agents Extra01
“LLM-as-a-Judge” 是一种新兴的、自动化的模型评估范式。它的核心思想是利用一个功能强大的、前沿的LLM(通常是像GPT-4o或Claude 3 Opus这样的闭源模型,被称为“裁判模型”)来评估另一个被测试LLM的输出质量。
工作流程:
- 提供一个 评估提示(Evaluation Prompt) 给裁判模型。
- 这个提示通常包含:
- 用户的原始问题(user query)。
- 被测试LLM生成的回答(response)。
- (可选)一个参考答案(reference answer)。
- 一套清晰的评估准则(rubric),例如“请从准确性、流畅性、有害性三个维度,为下面的回答打一个1-10分的分数,并给出你的理由。”
- 裁判模型会输出一个结构化的评估结果,包括分数和详细的解释。
优点:
- 可扩展性与效率(Scalability & Efficiency): 这是最大的优点。相比于昂贵且缓慢的人工评估,LLM裁判可以近乎实时地、大规模地对海量模型输出进行评估,极大地加速了模型迭代的反馈循环。
- 一致性(Consistency): 只要裁判模型和评估提示固定,其评估标准就是一致的,避免了不同人类标注者之间主观差异带来的不一致性问题。
- 可定制化(Customizability): 可以通过设计不同的评估准则和提示,轻松地让裁判模型从任意维度(如简洁性、创造性、安全性、共情能力等)来评估输出,非常灵活。
潜在的偏见:
- 位置偏见(Position Bias): 在进行A/B模型对比评估时,裁判模型倾向于偏爱第一个呈现给它的答案。
- 冗长偏见(Verbosity Bias): 裁判模型倾向于给更长、更详细的回答打更高的分数,即使这些回答可能包含冗余或无用的信息。
- 自我偏好/风格偏见(Self-Preference / Style Bias): 裁判模型可能更偏爱那些与它自己生成风格相似的回答,这会惩罚那些风格不同但同样优秀的模型。
- 有限的知识与推理能力(Limited Knowledge and Reasoning): 裁判模型本身也可能犯事实性错误或进行错误的逻辑推理。它可能无法识别出被测试模型回答中非常细微的、专业领域的错误,从而给出错误的评估。
- 过于“宽容”: 研究发现,裁判模型有时对于一些有害或不当内容的判断会比人类更宽容。
因此,LLM-as-a-Judge是一个强大高效的评估工具,但不能完全替代人类评估,尤其是在需要深度专业知识和对齐验证的场景。最佳实践是将其作为人类评估的有力补充和规模化工具。
072 · 中 · 在进行人工评估时,如何设计合理的评估准则和流程,以保证评估结果的客观性和一致性?
来源:Hello-Agents Extra01
在人工评估中,保证结果的 客观性(Objectivity) 和 一致性(Consistency) 是最大的挑战,因为人类的判断天生是主观的。设计合理的评估准则(Rubric)和流程是克服这一挑战的关键。
一、 设计合理的评估准则(Rubric):
- 明确且原子化的评估维度(Clear and Atomic Dimensions):
- 不要使用模糊的词语如“好”或“坏”。将“质量”分解为多个相互独立的、具体的维度。例如:
- 准确性(Accuracy): 答案是否包含事实错误?
- 完整性(Completeness): 答案是否全面地回应了问题的所有方面?
- 简洁性(Conciseness): 是否有冗余信息?
- 安全性(Harmlessness): 是否包含有害内容?
- 量化的评分标准(Quantitative Rating Scale):
- 使用量化的尺度,如 李克特量表(1-5分) 或 二元判断(是/否)。
- 为每一个分数等级提供清晰、明确的定义。例如,对于准确性维度:5分=完全准确;4分=基本准确但有细微瑕疵;3分=包含明显但非核心的错误...;1分=完全错误。
- 提供丰富的示例(Abundant Examples):
- 为每个维度的每个分数等级,提供典型的正面和负面示例(Golden examples and counter-examples)。这能极大地帮助标注者校准他们的判断标准。
二、 设计合理的评估流程:
- 标注者培训与校准(Rater Training and Calibration):
- 在评估开始前,对所有标注者进行系统性培训,确保他们完全理解评估准则和所有定义。
- 进行校准会,让所有标注者对同一批样本进行打分,然后公开讨论和对齐打分差异,直到大家的理解趋于一致。
- 盲评(Blind Evaluation):
- 标注者不应该知道他们正在评估的回答来自哪个模型(A模型、B模型还是人类)。这可以消除品牌偏见或先入为主的观念。
- 多次独立评估与一致性检验(Multiple Independent Ratings & Consistency Check):
- 每个样本至少由 2-3名 标注者独立进行评估。
- 使用统计指标来衡量标注者间信度(Inter-Annotator Agreement, IAA),如 Cohen's Kappa 或 Fleiss' Kappa。
- 如果IAA过低,说明评估准则存在歧义,需要返回第一步进行修改。
- 采用成对比较(Pairwise Comparison)而非绝对评分:
- 对于对比两个模型(A vs. B)的场景,让人类判断“哪个更好”(A更好/B更好/平局)通常比让他们分别为A和B打绝对分数更容易、也更可靠。这种方法可以有效地减少个体打分尺度的差异。
- 建立仲裁机制(Adjudication Mechanism):
- 对于标注者之间分歧较大的“疑难案例”,需要有一个更高阶的专家或委员会进行最终的仲裁,以确保最终结果的权威性。
073 · 中 · 大模型能力评测指标有哪些?
来源:小林 coding
换模型、改 Prompt、决定要不要微调,都要把「感觉还行」变成可比较的数字。生成没有唯一正确答案,所以指标要分学术榜、业务集和线上行为。
学术榜只说明能力区间:
| 名字 | 在测什么 |
|---|---|
| MMLU / MMLU-Pro | 几十个学科的选择题,后者更难,更吃推理 |
| HumanEval、MBPP | 按隐藏测试看函数能不能过;Pass@k 是 k 个候选里至少一个通过 |
| SWE-bench Verified | 修真实 GitHub issue |
| GSM8K、MATH、GPQA | 小学应用题、竞赛数学、研究生级别的科学问答 |
| MT-Bench、Arena、τ-bench | 多轮对话、人类偏好、工具调用和业务流程 |
| HELM、LiveBench、Humanity's Last Exam | 多维度,或用持续更新、更难的题减轻背题 |
数据污染是这些榜的系统性缺陷。题目在公开互联网上,预训练可能见过答案,排名高不代表业务里更聪明。应对是不用公开榜当训练集,看会换题的榜,以及用自己的请求做评测。
业务集从真实请求里抽 50–200 条,人工写出期望。分类、抽取、代码用程序判;摘要和开放问答用更强的模型按标准打分,再抽 10%–20% 人工校准这个裁判。每次改 Prompt 或换模型都重跑,一次只改一处。
线上再看满意度、任务完成率和中途放弃。离线集用来快速迭代,线上指标用来确认用户是否真的更好。两条线缺一条,都会把排行榜或主观感觉当成上线依据。
074 · 中 · 对比使用过哪些主流大模型?你们项目中最终选用了哪个模型?为什么?
来源:小林 coding
选型不是看榜首。四件事同时约束:合规、成本、延迟、能力是否打在这个节点上。版本迭代很快,面试里模型名是例子,判断框架才是答案。
国内企业链路里,生产候选通常先看 DeepSeek、Qwen、豆包这一类。DeepSeek 的推理和单价适合高频分析、代码和长链中间步骤。Qwen 的中文、工具调用、结构化输出和长上下文适合做调度、文档和 RAG 汇总。豆包一类更偏并发和产品化,适合客服、批量分类和内容生成。
海外模型,例如 GPT 的强推理系列、Claude 的 Sonnet / Opus,适合当能力上限的参照,做离线评测,或放在不碰敏感数据的兜底上。国内 ToB 要过数据分级、客户合同、出境审批和访问稳定性。这几关不过,再强也不能进核心链路。榜单高也不保证财报格式、内部黑话和工具参数稳定。Agent 内部循环如果每步都叫最贵的模型,预算会先被打穿。
落地用路由,不押一个模型。调度节点和要严格 JSON、函数参数的节点,选指令遵循和结构化输出稳的。高频清洗、比对、摘要,选够用且便宜的。少数真正难的问题再送到更贵的模型。敏感商业数据留在合规可控的一侧。
讲这道开放题时,先说业务链路,再说哪个节点怕错格式、哪个节点怕单价、哪段数据不能出境,最后才落到具体模型。顺序反了,就只是在背排行榜。
075 · 难 · 什么是红队测试?它在发现 LLM 和 Agent 的安全漏洞与偏见方面扮演着什么角色?
来源:Hello-Agents Extra01
红队测试(Red Teaming)是一种对抗性测试方法,源自于网络安全领域的渗透测试。在AI领域,它指的是组织一个专门的团队(红队),主动地、创造性地、像一个“攻击者”一样,去寻找和利用LLM或Agent的漏洞、缺陷和非预期行为,以评估和提升其安全性和鲁棒性。
与常规测试(使用固定的、已知的测试用例)不同,红队测试的核心在于“探索未知”,发现那些开发者在设计时没有预料到的、可能导致严重后果的“边缘案例”和“攻击向量”。
红队测试在发现安全漏洞与偏见方面的核心角色:
1. 发现安全漏洞 (Security Vulnerabilities):
- 绕过安全护栏: 红队会设计各种复杂的、精心构造的提示(即“越狱提示”),试图绕过模型的安全审查机制,诱导其生成有害内容,如暴力、色情、仇恨言论或违法活动的指导。
- 提示注入(Prompt Injection)攻击(针对Agent): 这是对Agent最核心的威胁之一。红队会模拟恶意用户或被污染的外部数据(如一个包含恶意指令的网页),尝试劫持Agent的控制流,让Agent执行非预期的、危险的操作,例如:
- 泄露其上下文中的敏感信息。
- 滥用其工具,如发送垃圾邮件、删除文件。
- 改变其原始目标。
- 发现资源滥用漏洞: 红队会尝试让Agent陷入无限循环或执行高消耗的操作,测试其资源限制和熔断机制。
2. 发现偏见 (Biases):
- 暴露刻板印象: 红队会设计一些涉及特定人群(如种族、性别、国籍、职业)的、看似中立但具有引导性的问题,来暴露模型是否会生成带有刻板印象或歧视性的回答。
- 测试政治与社会偏见: 通过询问有争议的社会或政治话题,评估模型的立场是否中立,是否存在偏向性。
- 揭示代表性不足问题: 探索模型在处理非主流文化或群体的相关问题时,是否会表现出知识的缺乏或产生不准确的描述。
总结:
红队测试扮演着“AI系统的免疫系统压力测试员”的角色。它通过模拟最坏情况和最狡猾的对手,帮助开发者在模型部署前,系统性地发现并修复那些在标准测试中难以暴露的深层次安全和对齐问题,是确保AI系统安全、可靠、公平的重要保障。
076 · 中 · 如何设计一个评估方案来衡量 LLM 的特定能力,比如“事实性/幻觉水平”、“推理能力”或“安全性”?
来源:Hello-Agents Extra01
为衡量LLM的特定能力设计评估方案,需要遵循“定义能力 -> 构建数据集 -> 确定评估方法”的流程。
1. 衡量“事实性/幻觉水平”:
- 能力定义: 模型生成的回答是否基于可验证的事实,而不是捏造信息。
- 数据集构建:
- 基于知识库的QA: 构建一个问题集,其中每个问题的答案都可以从一个确定的知识源(如Wikipedia、公司内部文档、数据库)中找到。
- 对抗性问题: 设计一些诱导模型产生幻觉的问题,比如询问关于不存在的人物或事件的信息。
- 评估方法:
- 精确匹配/关键词匹配: 对于事实简单的问题(如“谁是新加坡现任总统?”),可以直接将生成答案中的实体与标准答案进行比较。
- LLM-as-a-Judge: 使用一个更强大的LLM,让它判断生成的答案是否与提供的源知识(ground-truth knowledge)相符或矛盾。
- 自动化框架: 使用如 FaithScore 或 RAGAS 中的 Faithfulness 指标,它们通过自动化的方式将生成答案的每个声明与上下文进行比对验证。
2. 衡量“推理能力”:
- 能力定义: 模型能否在没有直接知识的情况下,通过逻辑、数学或常识进行多步推导,得出正确结论。
- 数据集构建:
- 使用专门的推理基准,如 GSM8K(数学应用题)、LogiQA(逻辑推理)、Big-Bench Hard 中的部分任务。
- 自行设计需要特定推理路径的任务,例如,给出一系列前提,要求模型推断结论。
- 评估方法:
- 结果评估(Outcome-based): 只判断最终答案是否正确。这是最直接的方法。
- 过程评估(Process-based): 对于使用了思维链(CoT)的模型,不仅评估最终答案,还由人类或另一个LLM来评估其推理步骤是否合乎逻辑、是否正确。这能更深入地了解模型的推理过程。
3. 衡量“安全性”:
- 能力定义: 模型能否拒绝回答有害、不道德、危险或非法的用户请求。
- 数据集构建:
- 使用公开的对抗性提示数据集,如 AdvBench (Adversarial Benchmarks) 或 SafetyBench,它们包含了大量经过设计的、试图绕过安全护栏的“危险问题”。
- 通过红队测试(Red Teaming),由人类专家主动地、创造性地构建新的攻击性提示。
- 评估方法:
- 分类器评估: 将模型的回答输入到一个预训练好的安全分类器(通常是另一个LLM或专用分类模型)中,判断其是否属于“有害”、“拒绝回答”或其他类别。
- 核心指标:
- 拒绝率(Refusal Rate): 模型成功拒绝回答有害问题的比例。
- 误伤率(False Refusal Rate): 模型错误地拒绝回答一个正常、安全问题的比例。
- 人工评估: 对于模糊或新型的案例,人工审核是最终的黄金标准。