eval-triage-and-improvement

评估分流与改进

帮助用户解读 Agent 评估结果，并找到可执行的后续改进步骤。遵循混合工作流：先收集评估结果，再生成结构化分流报告，其中包含 Step 7 的根因分类、负责人和建议的修复措施。

此技能以 skills/eval-guide/playbook.md 为依据，该文档是权威的 Agent 评估实用指南：10 步操作手册。它深入讲解 Step 7 — 迭代以诊断失败，并为生产环境反馈中的 Step 9 — 优化循环 奠定基础。MS Learn 页面和 Eval Guidance Kit 仍是 Copilot Studio 机制、生命周期节奏和检查清单材料的辅助来源。

何时使用此技能，何时使用 eval-result-interpreter

这两项技能采用相同的分流框架，但适用于不同的工作模式：

在以下情况下使用 eval-triage-and-improvement：	在以下情况下使用 eval-result-interpreter：
你需要交互式指导，逐步完成诊断	你有 CSV 文件或具体结果，需要一次性生成结构化报告
你正处于持续改进循环中——修复、重新运行并再次分流	这是你首次查看结果——你需要快速得出结论并确定首要行动
你需要针对特定评估集失败模式的详细修复指导（例如：“错误的工具触发了——现在怎么办？”）	你需要一份可交付给客户的材料（.docx 分流报告）
你遇到了大量失败（15+），需要帮助确定调查优先级	本次评估运行相对简单（失败数少于 20）
你需要操作手册中的示例和更深入的诊断演练	你需要在报告中直接获得活动映射／结果比较工具建议

**如果拿不准：**先使用 eval-result-interpreter 获取结构化报告；如果需要交互式帮助来落实修复措施，再切换到 eval-triage-and-improvement。

工作流

Step 1：收集评估结果

请用户分享：

1. 运行了哪些评估集及其通过率（例如：“忠实度：71%，提示词注入：95%”）
2. 方法清单元数据，取自配套的 .docx 报告或 stage-N-data.json：set_type、category／能力维度、method、gate（硬／软）、target、regression_class、人工审核标记，以及来源／真实值依据
3. 具体失败测试用例——测试用例 ID、样本输入、预期值、Agent 的实际响应，以及在 Copilot Studio 中指定的评估方法
4. 已运行的次数——这是首次基线运行（Step 6），还是修复后的重新运行？
5. 已尝试的操作——到目前为止是否尝试过任何评估、Agent、知识或工具方面的更改？

如果用户没有结构化结果，帮助他们整理现有信息。优先使用方法清单元数据，而不是根据文件名或问题文本进行推断。如果用户只有笼统的抱怨（“我的 Agent 运行效果不好”），请引导他们先使用场景库和 10 步操作手册的 Steps 1-6 运行基线评估。

Step 2：解读评分

根据方法清单中的 Step 4 目标和门槛，评估准备情况：

READINESS ASSESSMENT

Any failed hard gate            → BLOCK (trust & safety hard gates block regardless of aggregate pass rate)
Capability set below hard floor → ITERATE or BLOCK based on risk tier and capability criticality
Soft target missed only         → SHIP WITH KNOWN GAPS / ITERATE (tracked, not blocking)
All hard gates + targets pass   → SHIP

设置阈值——不要套用固定数值。优先使用方法清单中的目标；如果缺少目标，则根据 Agent 级别的风险等级推导一个临时目标，并标记需要更新方法清单。

因素	以下情况应提高阈值……
错误严重性	财务损失、安全风险、法律责任
影响范围	外部客户或大量内部用户
自主性／影响范围	Agent 可以采取行动或触发下游系统
监管风险	受监管的工作流、审计要求、合规义务
数据敏感性	PII、PHI、机密数据或租户敏感数据

第 3 步：预先检查基础设施

在诊断单项失败之前，先确认评估运行期间基础设施状态正常：

• 所有知识源都可访问且已完成索引？
• API 后端和连接器均未返回错误或超时？
• 身份验证令牌在整个运行期间都有效？
• 发布并评估的是正确的 Agent 版本？

如果任何依赖项状态异常，建议先修复基础设施，然后重新运行，再进行问题分类。

第 4 步：确定失败的优先级

如果用户遇到大量失败，建议按以下顺序进行问题分类：

优先级	优先分类	理由
1	未通过的硬性门槛，尤其是信任与安全评估集	后果最严重；无论总分如何，都会阻止部署
2	高风险能力失败（准确性、忠实度、工具使用）	直接影响 Agent 的价值；幻觉属于忠实度／能力失败
3	得分最低的评估集中的失败	很可能是系统性问题——修复一种模式即可解决多个问题
4	基线评估／重新运行中反复出现的失败	最容易诊断，也最容易引发回归问题
5	未达到软性目标	很重要，但通常不会阻止部署，除非问题模式恶化

失败达到 15 项或以上？ 不要逐项分类。查看得分最低的评估集中 3 至 5 项失败。如果它们属于相同的根因类别／子类型模式，就修复该问题并重新运行。

第 5 步：分类根本原因

对于每项失败，按顺序回答诊断问题。每项失败最终都必须归入第 7 步中的一个且仅一个根因类别：eval-setup problem（响应可接受；修复评估）或 agent-quality problem（确实存在问题；修复 Agent／平台并记录该模式）。

TRIAGE DECISION TREE (for each failing test case)

1. Is the agent's response actually acceptable, even though it failed?
   → YES = Eval-setup problem (grader, expected value, rubric, or method is wrong)

2. Is the expected answer still current against the actual source/ground truth in the manifest?
   → NO = Eval-setup problem (expected answer outdated or source dependency drifted)

3. Does the test case represent a realistic user input for this eval set's `set_type` and category?
   → NO = Eval-setup problem (unrealistic or mis-scoped test case)

4. Could a valid alternative response also be correct, but the grader rejects it?
   → YES = Eval-setup problem (rubric/grader too rigid)

5. Is the eval method appropriate for what you're testing?
   → NO = Eval-setup problem (wrong method; update the manifest and Copilot Studio row assignment)

ALL PASS → The eval is valid. Classify as **agent-quality problem** and proceed to operational subtype diagnosis:

6. Does the issue come from prompt/topic/tool/retrieval configuration or stale knowledge?
   → YES = Agent Configuration / Knowledge Issue (agent-quality problem)

7. Does the behavior persist after reasonable config and knowledge fixes plus re-run?
   → YES = Platform Limitation (agent-quality problem; log evidence and workaround)

第 5b 步：对话（多轮）问题分类

对于对话评估失败，仍适用标准决策树，但你必须先找出关键轮次——Agent 最早出错的那一轮。错误轮次之后的所有内容都是连锁结果，而不是独立失败。

确定关键轮次：

1. 按轮次逐一检查对话
2. 找出 Agent 响应首次偏离预期行为的轮次
3. 使用上述决策树对该轮次进行分类
4. 将后续轮次标记为“连锁结果——受第 N 轮修复所阻碍”

对话特有的失败模式及修复措施：

模式	识别方法	根因领域	修复措施
上下文丢失——第 1 轮正常，第 3 轮及之后开始遗忘	Agent 再次询问先前轮次已提供的信息，或与先前轮次的内容矛盾	Agent 配置	检查主题管理；确保切换主题时保留对话上下文
状态循环——Agent 重复相同响应	Agent 连续多轮的响应完全相同或几乎相同	Agent 配置	检查主题路由是否存在循环引用；添加明确的退出条件
澄清处理失败——Agent 无法处理后续补充信息	用户在第 2 轮提供澄清或更正时，Agent 处理失败	Agent 配置	添加处理后续补充信息的指令；检查主题是否接受不完整输入或更正输入
最后一步失败——理解问题但无法解决	前几轮诊断正确，但最终解决问题的轮次失败	Agent 配置或平台	检查操作／连接器配置；确认解决问题的流程已正确连接
评估过于刻板——对话内容可接受，但评分器拒绝通过	阅读完整对话后，结果是合理的	评估设置	对话评分功能有限（仅支持 AI Generated 或 Approval Rating）；调整评分标准或预期值

与单响应问题分类的关键区别： 不要独立分类每一轮。对关键轮次进行分类并应用修复，然后重新运行，再查看哪些后续轮次会随之自动解决。修复关键轮次后，预计 40%–60% 的后续失败会消失。

两个根类别 + 操作子类型

Step 7 根类别	操作子类型	处理方	含义
评估设置问题	评估设置问题	评估编写者	响应可接受，或者评估元数据／评分标准／预期答案／方法有误。修正评估和清单。
Agent 质量问题	Agent 配置问题	Agent 构建者	Agent 确实生成了不良响应。修正提示词、主题、工具、检索、依据或知识。
Agent 质量问题	平台限制	平台团队 + Agent 所有者	评估发现了由平台行为导致的真实问题。记录证据，在可能时提供变通方案，并跟踪此类模式。

对于每个 Agent 质量问题，都要维护一份失败模式日志：测试用例、set_type/category、根类别、子类型、疑似模式、负责人、修复位置、验证评估集，以及是否应成为回归用例（Step 8）。

Step 6：映射到修复措施

如需查看按 Step 7 根类别、操作子类型和评估集失败模式划分的详细修复步骤，请阅读以下 playbook 文件：

• 完整分流决策树：阅读 triage-and-improvement-playbook/triage-decision-tree.md
• 修复映射：阅读 triage-and-improvement-playbook/remediation-mapping.md
• 模式分析：阅读 triage-and-improvement-playbook/pattern-analysis.md
• 示例演练：阅读 triage-and-improvement-playbook/worked-examples.md

快速修复参考

评估设置修复：

子类型	修复方法
预期答案已过时	更新预期值，使其与当前来源内容一致
评分标准过于死板	切换到 Compare Meaning，或扩大关键词集合
测试用例不切实际	使用真实用户的表达方式重写输入
评估方法错误	调整方法，使其符合评估集的用途和证据类型
评分器错误／偏见	检查评分标准，添加示例，并考虑使用确定性方法

Agent 质量修复 — Agent 配置／知识／工具：

失败模式	常见修复方法
事实准确性（来源错误）	检查知识来源配置，验证索引，检查词汇是否匹配
事实准确性（提取错误）	在系统提示词中添加提取指引
幻觉（忠实度能力失效）	优先改进检索／分块；添加指令：“仅根据知识来源回答。如果没有相关内容，请如实说明。”
触发了错误的工具	重写工具描述以区分工具；添加反例
未触发工具	检查触发条件；确认工具已启用且可访问
触发了错误的主题	检查触发短语是否重叠；调整优先级顺序
缺乏共情	在系统提示词中添加针对特定情境的语气指令
超出范围	添加明确的范围外指令
PII 泄露	添加 PII 保护指令；检查身份验证范围

Agent 质量修复 — 平台限制响应：

• 通过证据记录此限制
• 在可能时实施变通方案
• 调整评估阈值，以考虑已知的平台行为
• 向平台团队提交问题，并附上复现步骤

步骤 7：分流依据（讲清楚 WHY）

生成报告之前，补充分流依据，向客户讲清楚分流决策背后的推理过程，而不只是给出结论。针对以下各项，请使用本次分流的实际评估数据：

1. 为什么每个失败项归入相应的根因类别和子类型 — 对于步骤 7 中的每个根因类别，至少选一个示例，逐步说明决策过程。例如：“测试用例 KB-014 被归类为评估设置问题，因为根据当前知识来源，Agent 的回复在事实上是正确的，但预期值仍引用旧的 14 天政策。Agent 是对的；评估已过时。”

2. 为什么修复目标是配置、内容还是评估 — 说明其中的逻辑：“我们建议更新知识来源，而不是修改提示词，因为 Agent 的检索工作正常——它找到了正确的文档——但文档本身包含过时信息。修改提示词会掩盖真正的问题。”

3. 为什么优先级如此排序 — 联系影响范围和依赖链：“失败的硬性门槛优先处理，因为它们会阻止部署，并可能改变下游行为。先修复硬性门槛问题，再重新运行回归测试套件，然后对其余问题进行分流；否则，在修正阻塞性护栏后可能消失的失败项也会被误诊。”

4. 本次分流无法告诉你什么 — 明确说明局限：“本次分流分析了单次评估运行中的 [N] 个失败项。它无法检测你尚未编写测试用例的场景中的问题，也无法根据单个数据点区分不稳定的失败（非确定性）和真实失败。如果某个失败情况处于临界状态，请重新运行后再投入资源修复。”

请将这些分流依据纳入分流报告（参见下方报告模板中的“分流依据”部分）。

步骤 8：生成分流报告

输出结构化的分流报告：

# Triage Report: [Agent Name] — [Date]

## Score Summary
| Eval Set | Set Type / Category | Pass Rate | Target | Gate | Status |
|----------|---------------------|-----------|--------|------|--------|
| ... | capability / faithfulness | ... | ... | hard/soft | PASS/BLOCK/ITERATE |

## Readiness Assessment
[SHIP / SHIP WITH KNOWN GAPS / ITERATE / BLOCK]
[Rationale]

## Failure Analysis
### Failure 1: [Test Case ID]
- **Set Type / Category:** capability or trust_safety / ...
- **Eval-set focus:** ...
- **Sample Input:** ...
- **Expected:** ...
- **Actual:** ...
- **Root Bucket:** [Eval-setup problem / Agent-quality problem]
- **Operational Subtype:** [Eval Setup / Agent Config / Knowledge / Platform Limitation]
- **Diagnosis:** [specific diagnosis]
- **Owner:** [who needs to act]
- **Remediation:** [specific action]
- **Verification:** [how to verify the fix worked]

[Repeat for each triaged failure]

## Triage Rationale
### Why these root bucket classifications
[Walk through the decision tree for representative examples — show the reasoning, not just the label]

### Why these remediations
[Explain the logic connecting root bucket/subtype to fix — why this fix and not an alternative]

### Why this priority order
[Connect priority to blast radius and dependency chains]

### What this triage does NOT tell you
[Name the limits: coverage gaps, single-run non-determinism, untested scenarios]

## Failure-Pattern Log
[Summarize recurring Step 7 patterns, owner, fix location, and whether each pattern should be added to the Step 8 regression suite]

## Systemic Patterns
[If 80%+ of failures share a root bucket/subtype/category, call it out]

## Action Items
| # | Action | Owner | Priority | Verification |
|---|--------|-------|----------|-------------|
| 1 | ... | ... | ... | Re-run [eval set] |

## Post-Triage Checklist
- [ ] All failed hard gates addressed before deploy
- [ ] Root buckets verified by reading actual responses
- [ ] Eval-setup fixes applied to expected answers/rubrics/method assignments/manifest
- [ ] Agent-quality patterns logged with owners and fix location
- [ ] Full Step 8 regression suite re-run after fixes
- [ ] Platform limitations filed if applicable

## Human Review Required
[Include human review checkpoints table — see Human Review Checkpoints section below]

分流后验证

修复应用后：

• 分数在修复后持平？ → 根因类别或子类型判断错误，请重新分流
• 一个分数上升，另一个下降？ → 指令冲突——修复改善了一项行为，却降低了另一项行为
• 80% 以上的失败项属于同一根因类别或子类型？ → 系统性问题——修复该类别，而非单个测试用例

非确定性处理

基于 LLM 的 Agent 和评分器会产生不稳定的输出：

• 建立基线： 在将任何分数作为步骤 6 的基线之前，至少运行 3 次。使用平均值，并记录 Agent 版本和时间戳。
• 正常波动： 不同运行之间的波动在 +/-5% 以内属于预期范围。若超过 10%，请进行调查。
• 不稳定的测试用例（有时通过，有时失败）：Agent 可能会生成两种有效回复，但评估过于严格。请调查是否应放宽预期值。
• 小型评估集（<30 个测试用例）： 单个测试用例的结果反转就会使分数变化 3% 以上。不要过度解读。

第 9 步优化循环：生产信号

如果 Agent 已部署（即使是在预览环境中），也要将生产反馈视为第 9 步循环：收集信号 → 聚类 → 确定修复位置 → 发布 → 根据第 8 步回归测试套件重新评估。按以下顺序排列信号优先级：点踩（负面反馈中信号最强）、升级处理、手动覆盖、支持工单，然后是定性评论。

• **评估通过的主题收到大量点踩：**覆盖缺口。如果这些评估用例代表反复出现的生产风险，请添加或修订用例，并将其标记为回归测试。
• **配置变更后点踩聚集出现：**可能是回归问题。重新运行第 8 步回归测试套件；如果套件未能发现问题，则添加用例。
• **升级处理／手动覆盖：**在证据确凿之前，先视为 Agent 质量问题；按能力或信任与安全类别进行聚类，并选择修复位置：Agent 配置／检索／工具、评分标准／预期答案，或新增评估覆盖。
• **评估失败的主题持续收到点赞：**可能是评估设置问题。先检查实际回复，再考虑放宽门槛。

生产信号本身并非定论。它们用于形成假设、新增评估用例并记录故障模式；回归测试套件负责验证修复效果。

人工审核检查点

根据分流报告采取行动前，请先检查以下要点。分流决策会直接影响 Agent 的变更——诊断错误会浪费整个迭代周期。

#	检查点	重要性
1	亲自核实第 7 步的根因分类——对于每个被归类为评估设置问题的失败，请阅读 Agent 的实际回复。它真的可以接受吗？还是分流过程过于宽容地看待 Agent？	将 Agent 质量问题误判为评估设置问题，会导致真正的问题被忽略。两类问题的区分需要判断，不能只靠分数自动化处理。
2	应用系统性修复前，确认系统性模式诊断——如果报告指出 80% 以上的失败都属于同一根因分类／子类型，请通过阅读实际回复来核实。相似的症状可能有不同的原因。	系统性诊断错误意味着你以为一项修复能解决许多失败，实际却只能解决部分问题，甚至一个也解决不了。
3	验证修复方案的可行性和优先顺序——你的团队能实际完成建议的变更吗？优先顺序是否符合你的时间安排和限制？	分流按影响确定优先级，但只有你的团队了解工作量和依赖关系。修复知识来源可能需要 2 周；调整提示词或许能让你现在就继续推进。
4	确认建议的修复不会导致已通过的场景回归——变更前，请考虑哪些当前已通过的测试用例可能受影响。尤其是提示词变更，往往会产生连带影响。	修复 3 个失败却引入 5 个新失败，得不偿失。每次更改 Agent 配置后，都应计划重新运行完整测试套件。
5	升级问题前，验证平台限制的分类——如果某个失败被归类为平台限制，请确认在多种提示词和配置变体下，该行为仍然存在，然后再提交给平台团队。	将配置问题作为平台缺陷升级，会浪费平台团队的时间，并延误实际修复。
6	根据实际风险等级检查清单目标和门槛——SHIP／ITERATE／BLOCK 是否遵循硬性门槛、软性目标和五项风险因素？	只有你的团队了解真正能接受的风险程度。内部助手未达到软性目标或许可以接受，但未通过信任与安全硬性门槛则会阻止部署。

将此表纳入分流报告输出。添加以下内容：这份分流报告有助于加快诊断，但不能取代人工判断。在采取任何修复措施前，请先检查第 1 和第 2 项；评估设置问题与 Agent 质量问题的区别，需要阅读实际回复。

数据保留警告

Copilot Studio 会在 89 天后删除测试运行结果。这意味着，在下次季度审查之前，初次评估的基线结果可能已经不复存在。每次完成问题排查后：

1. 立即导出结果 CSV（测试集 → 导出结果）
2. 与问题排查报告一起存储在 SharePoint、代码仓库或团队存放版本化制品的位置
3. 标注 Agent 版本和日期，以便日后进行比较

如果问题排查发现需要修复并重新运行评估，请在应用更改之前导出修复前的结果。你需要进行前后对比，而 Copilot Studio 不会永久保留修复前的结果。

交叉参考

此技能以 skills/eval-guide/playbook.md 为方法论主线。它也可与 AI Agent Evaluation Scenario Library（github.com/microsoft/ai-agent-eval-scenario-library）配合使用，该库定义了配套的场景模式和质量维度；还可与 Triage & Improvement Playbook（github.com/microsoft/triage-and-improvement-playbook）配合使用，后者为第 7 步提供配套的诊断框架。

相关评估技能

问题排查后，如果你需要……	使用此技能
根据问题排查期间发现的新场景，构建或扩展评估计划	/eval-suite-planner
为扩展或修订后的场景生成新的测试用例	/eval-generator
根据新的 CSV 快速生成结构化报告（无需交互式问题排查）	/eval-result-interpreter
解答问题排查期间遇到的方法论问题	/eval-faq
引导客户端到端完成完整的评估流程	/eval-guide