评测方案设计与实践
Q：Agent 的端到端成功率和工具误调用率怎么量化？怎么改进？
来源：腾讯 AI 应用开发二面
新手答：”看任务完成了没有，完成了就算成功。”
高手答：
“完成了没有”是最粗的指标，无法定位问题出在哪个环节。量化需要拆层，改进需要闭环。
端到端成功率的分层量化：
| 指标 | 定义 | 公式 |
|---|---|---|
| 端到端成功率 | 任务从输入到输出完全正确的比例 | 成功任务数 / 总任务数 |
| 规划成功率 | 模型生成的执行计划逻辑正确的比例 | 计划合理数 / 总规划数 |
| 工具选择准确率 | 选对了工具的比例 | 正确选择数 / 总选择数 |
| 工具调用成功率 | 工具调用返回有效结果的比例 | 有效返回数 / 总调用数 |
| 回复质量 | 最终回复满足用户意图的比例 | 满意回复数 / 总回复数（需人工/LLM 评估） |
工具误调用率的细分：
工具误调用不是一个单一指标，需要区分三种错误：
误选工具（选了不该选的）→ 看工具选择 Precision
漏选工具（该选的没选）→ 看工具选择 Recall
参数错误（选对了但参数传错）→ 看参数校验通过率量化工具链：
- 日志基建：每一步（意图识别 → 规划 → 工具选择 → 工具执行 → 结果生成）都记结构化日志，带 trace_id 串联
- 离线评估：用标注好的评测集定期跑回归，计算各层指标
- 线上监控：用 LangSmith / Langfuse / 自建 dashboard 实时追踪成功率、延迟、token 消耗
改进闭环：
常见优化手段：
- 工具选择准确率低 → 重写工具描述（加使用场景、输入输出示例）、减少工具数量（合并相似工具）
- 参数错误率高 → 参数 schema 加 enum 约束、在 System Prompt 中加参数填写示例
- 规划成功率低 → 拆分复杂任务（让模型先生成计划再执行）、加 Few-shot 示例
差距在哪：新手只看一个”成功率”数字，出了问题不知道该查哪。高手把端到端成功率拆成规划/工具选择/工具执行/回复质量四层，把工具误调用拆成误选/漏选/参数错误三类，且给出了从日志基建到改进闭环的完整量化方案。面试官考的是你有没有”可观测 + 可归因 + 可改进”的 Agent 评测方法论。
Q：通过什么方式去验证 Skill 的提升效果，指标是什么？
来源：美团/食杂后端一面 【电商库存一面追问：Skill 变更影响面回归】【字节火山引擎 Managed Agent 一面追问：脚本与模型评审对比两个 Skill】
新手答：“看用户反馈好不好，或者看任务成功率有没有提升。”
高手答：
验证 Skill 效果需要分层度量 + 对照实验：
1. 指标体系
| 层级 | 指标 | 含义 |
|---|---|---|
| 触发层 | 触发准确率 | 该触发时触发、不该触发时不触发 |
| 执行层 | 端到端成功率 | Skill 被调用后任务完成的比例 |
| 效率层 | 步数 / Token 消耗 | 有 Skill vs 无 Skill 的资源对比 |
| 质量层 | 输出一致性 | 同类任务多次执行结果的稳定程度 |
2. 评测方法
- A/B 对照：同一批 eval case，分别在有/无该 Skill 的条件下跑，对比成功率和步数
- 回归检测：新增 Skill 后原有能力是否退化（跑全量 eval set）
- 边界测试：故意给模糊/交叉意图，看 Skill 是否误触发
评价脚本和模型评审承担不同职责。格式、必填字段、工具调用、单测和业务不变量优先用确定性脚本；开放式质量使用固定 Rubric 的模型 Judge，隐藏候选名称并随机交换 A/B 顺序，重复多次检查位置偏差。Judge 分歧或高风险 Case 进入人工复核。对比两个 Skill 时固定模型、Prompt、工具快照和任务集，只改变 Skill 版本，同时报告成功率、路由准确率、Token、延迟、副作用和置信区间，不能用单次“看起来更好”决定发布。
回归集要分三圈：该 Skill 自己的正向、反向和边界 case；它与相邻 Skill 的路由混淆对（同一意图只改一个关键条件，看是否选错）；以及全局任务集。发布门槛同时约束本 Skill 的收益和另外两圈的最大退化，不能只证明“自己的题做得更好”，却让路由抢占其他 Skill 或损伤通用任务。
3. 实战经验
Skill 的效果不是线性的——简单任务提升不大，复杂重复任务提升显著。所以评测集要按任务复杂度分层，分别算各层提升比例，避免被简单任务的高基线稀释了真正的收益。
差距在哪：新手只看一个结果指标。高手分了触发/执行/效率/质量四层，且有对照实验设计和回归检测意识。面试官考的是你对”如何科学度量一个能力模块效果”的工程化思维。
Q：RAG 系统如何评测？有哪些评测维度和指标？评测数据集怎么构建？
来源：快手 AI Agent 开发一面
新手答：“看回答准不准。”
高手答：
RAG 评测不能只看最终回答——需要分阶段评估，才能定位问题出在哪个环节。
评测维度和指标：
| 评测阶段 | 维度 | 核心指标 | 说明 |
|---|---|---|---|
| 检索质量 | 召回率 | Recall@K | 正确文档是否进入了候选集 |
| 检索质量 | 精确率 | Precision@K | 候选集中相关文档的占比 |
| 检索质量 | 排序质量 | MRR / NDCG | 正确文档是否排在前面 |
| 生成质量 | 忠实度 | Faithfulness | 回答是否忠于检索到的文档（不编造） |
| 生成质量 | 相关性 | Answer Relevancy | 回答是否切题 |
| 生成质量 | 完整性 | Completeness | 回答是否覆盖了问题的所有方面 |
| 端到端 | 准确率 | Correctness | 最终回答和标准答案的一致性 |
| 端到端 | 拒答率 | Rejection Rate | 知识库无答案时，模型是否正确拒答而非编造 |
评测框架：
RAGAS：自动化评测框架，内置 Faithfulness、Answer Relevancy 等指标
TruLens：支持自定义评测函数，可追踪 RAG 管线每个环节
DeepEval：开源评测框架，支持 LLM-as-Judge 模式评测数据集的构建：
高质量评测数据的要求：
覆盖多种问题类型：
- 单跳事实题（答案在一个文档中）
- 多跳推理题（需要关联多个文档）
- 对比题（两个实体的异同）
- 超范围题（知识库中没有答案，测试拒答能力）
- 时效性题（信息可能过期）
标注内容：每条数据包含 query、标准答案、相关文档列表（ground truth）、难度标签
数据规模：通常 200-500 条覆盖主要场景即可，关键是多样性而非数量
持续更新：知识库更新后，评测集也要同步更新，否则评测结果不反映真实表现
差距在哪：新手只看”准不准”一个维度。高手把评测拆成检索和生成两个阶段，每个阶段有独立的指标体系，且说清了评测数据集的构建方法和质量要求。面试官考的是你有没有完整的 RAG 质量保障体系——不是”上线看看效果”，而是有离线评测、有基准数据、有分阶段归因。
追问：评测集 100 条够吗？分布怎么分析？baseline 用什么？
来源：字节 AI 一面（RAG 项目深挖）
100 条评测集的三个致命问题：
- 统计显著性不足：100 条样本下，Recall@5 从 0.81 波动到 0.75 可能只是随机误差，你无法区分”真的变差了”和”评测集太小导致的噪声”
- 分布偏差：如果 100 条中 80 条是简单的单跳事实题，Recall@5 = 0.81 不代表系统在多跳推理题上也能达到同样水平
- 无 baseline 对照：0.81 是好是坏？没有参照系就是一个孤立数字
评测集规模的工程标准：
| 场景规模 | 最低评测集 | 构建方式 |
|---|---|---|
| PoC / Demo | 50-100 条 | 手工构造即可 |
| 内部工具上线 | 200-500 条 | 自动生成 + 人工审核 |
| 面向用户产品 | 1000+ 条 | 真实日志挖掘 + 专家标注 + 对抗样本 |
分布分析必做的三件事：
- 按 query 类型分层：单跳事实 / 多跳推理 / 对比 / 超范围各占多少，分层计算指标
- 按难度分级：简单（答案在单段落内）/ 中等（需跨段落）/ 困难（需跨文档）
- 按文档来源分布：确保评测集覆盖知识库的各个领域，而非集中在少数文档
baseline 设计：
| Baseline | 作用 | 实现 |
|---|---|---|
| BM25 纯关键词检索 | 检验向量检索是否比传统检索好 | 同样的 query 走 BM25 |
| 纯 LLM 无检索 | 检验 RAG 是否真的有价值 | 直接问模型，不给文档 |
| 人类表现 | 性能上限参照 | 让领域专家回答同样的问题 |
有了 baseline，”Recall@5 = 0.81”才有意义——“比 BM25 的 0.62 高 30%，但离人类的 0.95 还有差距”。
Q：Ragas 评测框架是什么？Answer Relevance 偏低时，怎么区分是检索问题还是模型问题？
来源：蚂蚁 AI应用开发 二面
新手答：”Ragas 是评测 RAG 的工具，Answer Relevance 低就是检索不好。”
高手答：
Ragas 框架：一个专门评测 RAG 系统的开源框架，核心是把端到端的评测拆解成多个独立维度，每个维度单独打分，这样出了问题能精准定位到哪个环节。
核心指标：
| 指标 | 评测什么 | 不依赖 |
|---|---|---|
| Faithfulness（忠实度） | 回答是否基于检索到的上下文，而非编造 | 不依赖标注答案 |
| Answer Relevance（答案相关性） | 回答是否切题、是否回答了用户的问题 | 不依赖检索结果 |
| Context Precision（上下文精度） | 检索到的内容中，相关内容排在前面的比例 | 需要标注答案 |
| Context Recall（上下文召回） | 回答所需的信息是否都被检索到了 | 需要标注答案 |
Answer Relevance 偏低时的诊断方法：
Answer Relevance 低有两种可能：检索给了错误的上下文（模型”巧妇难为无米之炊”），或者检索正确但模型理解/表达能力不足。区分方法：
1. 交叉检验法：固定相同的检索结果，分别用当前模型和一个已知强模型（如 GPT-4）生成回答。如果强模型的 Answer Relevance 显著更高 → 当前模型能力不足。如果强模型也低 → 检索问题。
2. 指标联动分析：
- Context Recall 低 + Answer Relevance 低 → 检索没有找到相关文档，模型无法回答 → 检索问题
- Context Recall 高 + Faithfulness 高 + Answer Relevance 低 → 检索结果正确且模型忠实引用了，但回答方式不切题 → 模型理解/表达问题
- Context Precision 低 + Answer Relevance 低 → 检索结果中噪声太多，模型被无关信息干扰 → 检索排序问题
3. 人工抽样：随机抽取 20-30 个低分 case，人工判断检索结果和模型回答各自的质量。自动化指标是辅助，人工抽样是最终确认。
差距在哪：新手直接把 Answer Relevance 低归因于检索——这是最常见的误判。高手用交叉检验和指标联动两种方法精准区分了检索质量和模型能力的影响边界。面试官考的是你有没有系统性的 RAG 评测和问题诊断能力。
追问：Ragas 的 Context Precision 过低，怎么优化？
来源：阿里淘天 AI应用开发一面
Context Precision 衡量的是检索结果中相关文档的排位——即使召回了正确文档，如果排在第 4、5 位而噪声文档排在前面，Context Precision 也会很低。
优化的三个方向：
| 方向 | 具体方案 | 效果 |
|---|---|---|
| 检索排序 | 引入 Rerank 模型（Cross-Encoder）对召回结果重排序 | 直接提升相关文档排位 |
| 召回质量 | 优化 query 改写 + 混合检索（向量+BM25），减少噪声召回 | 从源头减少不相关文档 |
| 索引质量 | 改进分块策略（避免语义碎片化）+ 清洗知识库噪声文档 | 底层数据质量决定上限 |
诊断优先级：先看 Context Recall——如果 Recall 也低，说明正确文档根本没进候选集，优化召回策略优先；如果 Recall 高但 Precision 低，说明正确文档进了但排位差，加 Rerank 即可。
Q：怎么理解 Vibe Coding？你有哪些实践经验？
来源：蚂蚁 AI应用开发 二面
新手答：”就是用 AI 写代码，说需求然后让模型生成。”
高手答：
Vibe Coding 是 Andrej Karpathy 提出的概念——开发者用自然语言描述意图，AI 生成代码，开发者不逐行审查而是直接运行看效果，凭”感觉”（vibe）判断代码是否正确。核心特征：开发者从”写代码的人”变成”描述需求+验证结果的人”。
适用场景和边界：
| 场景 | 适合 Vibe Coding | 原因 |
|---|---|---|
| 原型验证 / 脚本 | 适合 | 快速试错，错了重来成本低 |
| UI / 前端样式 | 适合 | 视觉验证直观，改起来快 |
| 数据处理脚本 | 适合 | 输入输出明确，结果可验证 |
| 核心业务逻辑 | 不适合 | 错误难发现，后果严重 |
| 安全相关代码 | 不适合 | “看起来能跑”不等于安全 |
实践经验：
- 小步快跑：不要一次描述完整需求，而是分步骤——先搭框架 → 再填功能 → 最后优化。每步验证后再进入下一步
- 验证比生成更重要：AI 生成代码很快，但验证代码是否正确才是耗时的部分。好的 Vibe Coding 实践是花 20% 时间描述需求，80% 时间验证和调试
- 知道什么时候停：Vibe Coding 的效率在简单任务上极高，但在复杂逻辑上迅速下降。当你发现自己花更多时间解释 bug 而非描述需求时，就该切回手写代码
对 Agent 开发的启示：Vibe Coding 本质上就是人类使用了一个”代码生成 Agent”——用户用 NL 描述意图，Agent 调用代码生成工具执行。这个体验的好坏直接反映了 Agent 系统的核心能力：意图理解、工具调用、结果验证。
差距在哪：新手把 Vibe Coding 等同于”用 AI 写代码”。高手理解它的本质（角色转变：写代码→验证结果），知道适用边界（原型适合、核心逻辑不适合），且有具体的实践方法论。面试官考的是你对 AI 辅助开发的思考深度——不是”用没用过”，而是”怎么用、什么时候不用”。
Q：如何衡量 Agent 的 Planning 能力 vs Hallucination Rate？请列举具体的量化评估指标或自动化评估框架
来源：淘天 AI Agent 一面
新手答：”看任务成功率就行了。”
高手答：
Planning 能力和 Hallucination Rate 必须同时评估，因为它们之间存在本质张力——规划能力越强意味着模型越敢自主决策，但自主决策越多，幻觉风险越高。只看成功率会掩盖这个矛盾：一次”碰巧成功”的幻觉规划和一次”系统性正确”的规划，在成功率上没有区别。
Planning 能力的量化指标：
| 指标 | 定义 | 评估方法 |
|---|---|---|
| 计划完整度（Plan Completeness） | 生成的计划是否覆盖了任务所需的所有关键步骤 | 与标准步骤列表对比，计算覆盖率 |
| 步骤正确率（Step Correctness） | 每一步的动作和参数是否正确 | 逐步对比标准答案，人工或 LLM 评判 |
| 工具选择准确率（Tool Selection Accuracy） | 是否选择了最合适的工具 | 与标注的最优工具选择对比 |
| 计划效率（Plan Efficiency） | 实际步数 vs 最优步数 | 比值越接近 1 越好，>2 说明有冗余 |
| 计划适应性（Plan Adaptability） | 遇到工具失败或意外结果时能否调整计划 | 故意注入失败，观察恢复行为 |
| 子目标分解质量 | 复杂任务是否被合理拆解为可执行的子任务 | LLM-as-Judge 评分（1-5 分） |
Hallucination Rate 的量化指标：
| 指标 | 定义 | 评估方法 |
|---|---|---|
| 忠实度（Faithfulness） | 回答是否忠实于检索到的证据 | RAGAS Faithfulness 指标，或人工标注 |
| 事实基础率（Factual Grounding Rate） | 输出中有多少比例的陈述可以追溯到可靠来源 | 逐句标注来源，计算有来源覆盖的比例 |
| 无依据声明率（Unsupported Claim Ratio） | 输出中无法在上下文或知识库中找到支撑的声明占比 | 自动提取声明 → 逐条验证 → 计算比例 |
| 工具幻觉率（Tool Hallucination Rate） | 调用不存在的工具或使用不合法参数的比例 | 规则检查：工具名 属于 可用列表？参数符合 schema？ |
| 结果幻觉率 | 声称工具返回了某结果但实际返回不同 | 对比模型声称的工具结果与实际工具返回值 |
核心矛盾：Planning 越强，Hallucination 风险越高
Planning 自主性光谱：
低自主 ──────────────────────────── 高自主
固定流程 受限规划 自由规划 完全自主
幻觉风险低 幻觉风险高
能力上限低 能力上限高
→ 评估不能只看一端，要画出”能力-幻觉”的帕累托曲线所以评估框架必须同时覆盖两个维度，生成类似这样的联合报告：
Agent A：Planning 得分 82，Hallucination Rate 15% → 高能力、中风险
Agent B：Planning 得分 78，Hallucination Rate 5% → 中能力、低风险
Agent C：Planning 得分 90，Hallucination Rate 30% → 高能力、高风险（不可上线）自动化评估框架对比：
| 框架 | 核心能力 | Planning 评估 | Hallucination 评估 |
|---|---|---|---|
| RAGAS | RAG 管线自动评测 | 不直接支持 | Faithfulness、Answer Relevancy |
| AgentBench | Agent 多场景基准测试 | 任务完成率、步骤效率 | 间接（通过错误分析） |
| ToolBench | 工具调用能力评测 | 工具选择准确率、调用链正确性 | 工具幻觉率 |
| 自建评估管线 | 定制化全维度评估 | LLM-as-Judge + 规则打分 | 声明提取 + 来源验证 |
自建管线的推荐做法：
LLM-as-Judge 用于评估 Planning 质量（计划是否合理、步骤是否冗余），规则检查用于 Hallucination 检测（工具名是否存在、参数是否合法、引用的事实是否有来源）。两类评估互补：LLM 擅长语义判断，规则擅长精确校验。
差距在哪：新手只看”任务成功率”——这是一个结果指标，无法区分”系统性正确”和”碰巧成功”，更无法暴露潜在的幻觉风险。高手同时评估 Planning 能力和 Hallucination Rate，认识到两者之间的张力关系，并用多框架组合（LLM-as-Judge + 规则检查 + 注入测试）构建完整的评估管线。面试官考的是你有没有”评估即工程”的思维——不是跑一个 benchmark 就完了，而是要建一套持续运行的评估体系。
Q：设计一个电商客服 Agent 的评测方案——商品咨询、售后处理、投诉安抚三类任务如何分别评估？
来源：淘天 AI Agent 一面（场景题）
新手答：“看客服满意度评分。”
高手答：
电商客服 Agent 的三类任务——商品咨询、售后处理、投诉安抚——评测维度和指标必须分开设计，因为它们的成功标准完全不同。
分任务评测维度：
| 维度 | 商品咨询 | 售后处理 | 投诉安抚 |
|---|---|---|---|
| 核心目标 | 回答准确、促进转化 | 问题解决、流程合规 | 情绪缓解、用户留存 |
| 准确性指标 | 商品信息正确率（价格/规格/库存） | 政策引用正确率（退换货规则） | 情绪识别准确率 |
| 效率指标 | 平均响应时间、对话轮数 | 问题解决时长、一次解决率 | 情绪转正轮数 |
| 质量指标 | 推荐相关度、交叉销售率 | 解决方案合理性、用户确认率 | 共情表达质量、升级率（越低越好） |
| 安全指标 | 不承诺虚假信息 | 不违反退换货政策 | 不激化矛盾、不做超权限承诺 |
投诉安抚场景的特殊指标设计——用户满意度很难直接衡量，需要代理指标：
| 代理指标 | 如何采集 | 为什么能反映满意度 |
|---|---|---|
| 情绪转正率 | 对话开始和结束时的情绪分类（NLP 情感分析） | 从负面转为中性/正面说明安抚有效 |
| 情绪转正轮数 | 首次情绪转正时的对话轮次 | 轮数越少说明安抚效率越高 |
| 升级人工率 | 安抚后仍要求转人工的比例 | 越低说明 Agent 安抚能力越强 |
| 复访投诉率 | 同一用户 7 天内再次投诉的比例 | 低说明问题真正被解决，不是敷衍过去的 |
| 主动评分率 | 用户主动给好评的比例（非弹窗请求） | 主动好评比被动评分更真实 |
| 会话完成率 | 用户在对话中途离开的比例 | 高离开率说明用户对 Agent 回复不满 |
评测数据集构建：
判定 Agent 好坏的综合评分：
不能用一个分数定生死——三类任务加权，且有一票否决机制：
综合得分 = 0.4 × 商品咨询得分 + 0.3 × 售后处理得分 + 0.3 × 投诉安抚得分
一票否决项（触发任何一项直接判定不合格）：
- 承诺虚假商品信息（价格/功能/库存）
- 违反退换货政策做出超权限承诺
- 回复激化用户情绪（情绪恶化率 > 5%）
- 泄露其他用户信息差距在哪：新手只想到一个”满意度”数字。高手把三类任务的评测维度完全拆开——商品咨询看准确性和转化，售后看解决率和合规，投诉安抚用情绪转正率等代理指标替代难以直接衡量的满意度。面试官用这个场景题考的是你能不能把抽象的”Agent 评测”落地到具体业务场景中，且能设计出可量化、可采集的指标体系。