Agent面试题汇总：LLM与Agent评测片

1. 为什么传统 NLP 评估指标（BLEU、ROUGE）对现代 LLM 局限性很大？

传统指标核心是比较生成文本与参考答案在 n-gram 上的表层重合度，存在以下问题：

• 语义缺失：只关心词汇匹配，不理解语义。如"今天天气很好"与"今天日光很灿烂"意思相近，但得分很低。
• 无法评估事实准确性：无法检测幻觉，流畅但包含错误事实的回答可能得高分。
• 忽略多样性与创造性：开放式任务没有唯一标准答案，基于固定答案的评估会惩罚优秀但不同的回答。
• 长文本评估能力差：无法评估长篇内容的连贯性、逻辑性和结构性。
• 无视推理过程：只能比较最终答案字符串，无法评估思维链步骤是否正确。

现代 LLM 评估需要深入到语义理解、事实性、逻辑推理、安全性、遵循指令等更高维度。

2. 介绍几个广泛使用的 LLM 综合性基准测试及其侧重点

• MMLU（Massive Multitask Language Understanding）

  • 侧重：知识广度与学科问题解决能力
  • 包含 57 个科目，涵盖数学、历史、计算机科学到法律、医学等
  • 形式：四选一单项选择题
  • 目的：检验模型是否具备渊博的跨学科知识储备

• Big-Bench（Beyond the Imitation Game Benchmark）

  • 侧重：探索 LLM 能力边界和未来潜力
  • 包含 200+ 个挑战性任务，测试常识推理、逻辑、物理直觉、创造性等
  • 形式：选择题、生成题、比较题等
  • 目的：衡量通用智能水平和前沿能力

• HumanEval

  • 侧重：代码生成与编程能力
  • 包含 164 个手写编程问题，提供函数签名、文档字符串和单元测试
  • 评估方法：pass@k 指标，生成 k 个样本中至少一个通过所有单元测试即算通过

• 其他重要基准

  • GSM8K：小学水平数学应用题推理能力
  • ARC：需要科学常识和推理的挑战性选择题
  • HellaSwag：常识推理，选择最合理的句子续写情景

3. 什么是"LLM-as-a-Judge"？其优点和潜在偏见是什么？

定义：利用一个强大的前沿 LLM（如 GPT-4o、Claude 3 Opus，称为"裁判模型"）来评估另一个 LLM 的输出质量。

工作流程：

• 向裁判模型提供评估提示，包含用户原始问题、被测试 LLM 的回答、参考答案（可选）、评估准则（如准确性、流畅性、有害性等 1-10 分评分标准）
• 裁判模型输出结构化评估结果（分数+解释）

优点：

• 可扩展性与效率：近乎实时、大规模评估，加速模型迭代
• 一致性：裁判模型和提示固定时，评估标准一致，避免人类标注者主观差异
• 可定制化：可设计不同准则和提示，从任意维度评估

潜在偏见：

• 位置偏见：A/B 对比时偏爱第一个呈现的答案
• 冗长偏见：偏爱更长、更详细的回答，即使包含冗余信息
• 自我偏好/风格偏见：偏爱与自己生成风格相似的回答
• 有限的知识与推理能力：裁判模型本身可能犯事实性错误或逻辑推理错误
• 过于"宽容"：对有害或不当内容的判断有时比人类更宽容

最佳实践：作为人类评估的有力补充和规模化工具，不能完全替代人类评估。

4. 如何设计评估方案衡量 LLM 的特定能力（事实性/幻觉、推理能力、安全性）？

遵循"定义能力 → 构建数据集 → 确定评估方法"的流程。

衡量事实性/幻觉水平：

• 数据集：基于知识库的 QA（答案可从 Wikipedia、内部文档等确定知识源找到）；对抗性问题（询问不存在的人物或事件）
• 评估方法：精确匹配/关键词匹配；LLM-as-a-Judge 判断与源知识是否相符；自动化框架（FaithScore、RAGAS 中的 Faithfulness 指标）

衡量推理能力：

• 数据集：GSM8K（数学应用题）、LogiQA（逻辑推理）、Big-Bench Hard 部分任务；自行设计需要特定推理路径的任务
• 评估方法：结果评估（只判断最终答案是否正确）；过程评估（评估思维链推理步骤是否合乎逻辑）

衡量安全性：

• 数据集：AdvBench、SafetyBench 等对抗性提示数据集；红队测试（Red Teaming）由人类专家构建攻击性提示
• 评估方法：安全分类器判断回答类别；核心指标包括拒绝率（成功拒绝有害问题的比例）和误伤率（错误拒绝正常问题的比例）；人工审核为最终黄金标准

5. 评估 Agent 为什么比评估基础 LLM 更困难复杂？评估维度有何不同？

困难根源：

• 交互性与状态空间：基础 LLM 是无状态的"输入→输出"模式；Agent 是有状态的，与环境多步交互，行为轨迹数量天文数字
• 环境动态性与不确定性：LLM 评估环境确定；Agent 环境（真实网页、API）动态变化、不可预测，结果难以复现
• 非确定性：LLM 采样随机性+环境动态性，相同初始任务两次执行结果可能完全不同
• 任务开放性：Agent 任务往往开放式，没有唯一正确答案（如"预订性价比最高的机票"），难以定义简单正确/错误指标

评估维度对比：

总结：LLM 评估像"产品质量检测"，Agent 评估像"路况复杂的真实驾驶测试"，不仅看是否到达终点，更看过程中的效率、安全性和应对突发状况的能力。

6. 专门用于评估 Agent 能力的基准测试有哪些？测试环境和任务如何构建？

知名 Agent 能力基准测试：

• WebArena

  • 专注领域：网页浏览与操作
  • 高度逼真的独立网页环境模拟器，复刻多个真实网站（电商、论坛、软件开发协作工具）
  • 任务举例：在电商网站找到满足特定要求的商品并加入购物车；在论坛预订会议室
  • 评估方式：基于最终网页状态的程序化判断（如购物车是否有正确商品）

• AgentBench

  • 专注领域：通用 Agent 能力的综合评估
  • 包含 8 个不同环境：操作系统（Linux 终端操作文件、执行命令）、数据库（根据自然语言问题查询 SQL）、知识图谱（多跳推理）、游戏（文字冒险游戏）

• GAIA（General AI Assistants）

  • 专注领域：模拟人类使用真实工具完成复杂任务
  • 问题通常需要多步推理并组合使用多种工具（网页浏览器、代码解释器、文件操作）
  • 任务举例："找出引用了论文 A 和论文 B 的所有论文中，被引用次数最高的那篇的第三位作者是谁？"

测试环境和任务构建方式：

• 环境构建 → 沙箱化与可复现性

  • 使用 Docker 容器封装包含浏览器、终端、文件系统的独立环境
  • 网页浏览：本地托管网站静态副本或使用 Web 后台模拟器
  • API 调用：重定向到模拟（mock）API 服务器

• 任务构建 → 目标导向

  • 以高层次目标（high-level goal）形式给出，而非具体步骤指令
  • 覆盖信息检索、工具使用、推理规划、记忆等多种能力
  • 附带明确的、可程序化验证的成功标准

• 评估构建 → 程序化验证

  • 评估脚本自动检查环境最终状态是否满足成功条件
  • 举例：检查磁盘是否创建了内容正确的文件；检查购物车最终状态；检查最终答案字符串是否与标准答案匹配

7. 评估 Agent 任务完成情况时，除最终结果正确性外，还有哪些值得关注的过程指标？

效率（Efficiency）：

• 成本：Token 消耗量、API 调用费用
• 延迟：总耗时（Wall-clock Time）、计算时间（CPU/GPU Time）
• 步骤数："思考-行动"循环总次数，更少步骤通常意味着更强规划能力

鲁棒性（Robustness）：

• 错误处理能力：工具返回错误、网页加载失败时，能否识别问题并采取纠正措施（尝试不同工具、修正参数、重新规划）
• 抗干扰能力：环境中加入噪声或误导性信息后，成功率下降程度

自主性与对齐（Autonomy & Alignment）：

• 需要人类干预的次数：更自主的 Agent 需要人类帮助的次数更少
• 行为可解释性："思考"过程是否清晰、合乎逻辑，能否让人类理解决策依据
• 计划遵循度：预先生成计划后，在多大程度上遵循自己的计划

8. 什么是红队测试？它在发现 LLM 和 Agent 安全漏洞与偏见方面扮演什么角色？

定义：红队测试（Red Teaming）源自网络安全渗透测试，指组织专门团队（红队）主动、创造性地像"攻击者"一样寻找和利用 LLM 或 Agent 的漏洞、缺陷和非预期行为，以评估和提升安全性与鲁棒性。

核心特点：与常规测试（使用固定已知测试用例）不同，红队测试的核心在于"探索未知"，发现开发者设计时未预料到的、可能导致严重后果的"边缘案例"和"攻击向量"。

发现安全漏洞：

• 绕过安全护栏：设计复杂提示（"越狱提示"）绕过安全审查机制，诱导生成有害内容（暴力、色情、仇恨言论、违法活动指导）
• 提示注入攻击（针对 Agent）：模拟恶意用户或被污染外部数据（如包含恶意指令的网页），劫持 Agent 控制流，导致泄露敏感信息、滥用工具（发送垃圾邮件、删除文件）、改变原始目标
• 资源滥用漏洞：让 Agent 陷入无限循环或执行高消耗操作，测试资源限制和熔断机制

发现偏见：

• 暴露刻板印象：设计涉及特定人群（种族、性别、国籍、职业）的引导性问题，暴露模型是否生成带有刻板印象或歧视性的回答
• 测试政治与社会偏见：询问有争议的社会或政治话题，评估模型立场是否中立、是否存在偏向性
• 揭示代表性不足问题：探索模型在处理非主流文化或群体相关问题时，是否表现出知识缺乏或不准确描述

总结：红队测试扮演"AI 系统免疫系统压力测试员"的角色，通过模拟最坏情况和最狡猾的对手，帮助开发者在部署前系统性发现并修复标准测试中难以暴露的深层次安全和对齐问题。

9. 人工评估时，如何设计合理的评估准则和流程，保证结果的客观性和一致性？

设计合理的评估准则（Rubric）：

• 明确且原子化的评估维度

  • 不使用模糊词语如"好"或"坏"，将"质量"分解为多个相互独立、具体的维度：
    • 准确性（Accuracy）：答案是否包含事实错误？
    • 完整性（Completeness）：是否全面回应问题所有方面？
    • 简洁性（Conciseness）：是否有冗余信息？
    • 安全性（Harmlessness）：是否包含有害内容？

• 量化的评分标准

  • 使用李克特量表（1-5 分）或二元判断（是/否）
  • 每个分数等级提供清晰定义，如准确性：5 分=完全准确；4 分=基本准确但有细微瑕疵；3 分=包含明显但非核心错误...；1 分=完全错误

• 提供丰富的示例

  • 为每个维度每个分数等级提供典型正面和负面示例（Golden examples and counter-examples），帮助标注者校准判断标准

设计合理的评估流程：

• 标注者培训与校准

  • 评估前对所有标注者进行系统性培训，确保完全理解评估准则和定义
  • 进行校准会，让所有标注者对同一批样本打分，公开讨论和对齐打分差异，直到理解趋于一致

• 盲评（Blind Evaluation）

  • 标注者不应知道正在评估的回答来自哪个模型（A 模型、B 模型还是人类），消除品牌偏见或先入为主的观念

• 多次独立评估与一致性检验

  • 每个样本至少由 2-3 名标注者独立评估
  • 使用统计指标衡量标注者间信度（Inter-Annotator Agreement, IAA），如 Cohen's Kappa 或 Fleiss' Kappa
  • IAA 过低说明评估准则存在歧义，需要返回修改

• 采用成对比较（Pairwise Comparison）而非绝对评分

  • 对比两个模型（A vs. B）时，让人类判断"哪个更好"（A 更好/B 更好/平局）通常比分别打绝对分数更容易、更可靠，有效减少个体打分尺度差异

• 建立仲裁机制

  • 标注者分歧较大的"疑难案例"，由更高阶专家或委员会进行最终仲裁，确保结果权威性

10. 如何持续监控和评估已部署上线的 LLM 应用或 Agent 服务，应对性能衰退或行为漂移？

采集与日志（Collection and Logging）：

• 全面日志：记录每次请求的完整交互数据，包括用户输入、模型生成的中间步骤（如 Agent 思考链）、最终输出、调用的工具、延迟、Token 消耗等
• 用户反馈：在产品界面嵌入明确反馈机制，如"顶/踩"按钮、打分、一键报告问题，这是最直接的性能信号

自动化监控（Automated Monitoring）：

• 监控代理指标（Proxy Metrics）

  • 输入指标：问题长度、主题分布、提问语言等
  • 输出指标：回答长度、代码块比例、JSON 格式错误率、拒绝回答率等
  • 过程指标（针对 Agent）：平均执行步数、工具调用频率、工具调用失败率

• 自动化质量评估

  • 定期抽样：从生产流量中随机抽取样本
  • LLM-as-a-Judge：使用强大"裁判 LLM"根据固定评估准则对抽样样本自动打分
  • 对比黄金集：将抽样样本与内部维护的高质量"黄金评估集"对比，看关键问题表现是否稳定

人工审核与分析（Human Review and Analysis）：

• 定期人工审计：组织运营或评估团队，对随机样本、用户反馈坏案例、自动化监控发现的异常案例进行深入分析
• 根本原因分析：分析问题根源——LLM 本身能力退化？Agent 规划逻辑有误？某个工具 API 发生变更？

反馈闭环与模型迭代（Feedback Loop and Model Iteration）：

• 持续的数据管理：将生产环境发现的有价值案例（特别是失败案例和用户不喜欢的案例）清洗、标注后，持续加入评估集和微调数据集
• 定期再训练/微调：根据积累的新数据，定期对模型进行微调（Fine-tuning）或重新训练