你做Prompt优化时，是如何判断优化后的Prompt在Agent推理链路中性能提升的？用什么指标来衡量
1️⃣ 考察意图
面试官想看你是否具备系统化评估 Prompt 优化效果的能力，而非仅凭感觉调 Prompt。这是“工程取舍 + 系统设计”型问题，刁钻点在于：Agent 推理链路中 Prompt 优化不仅影响单步输出，还影响工具调用、多步推理和错误恢复。答好了能展示你懂指标设计、实验控制、统计验证，并能将评估集成到 CI/CD 中，体现工程化思维。
2️⃣ 标准答
评估 Prompt 优化在 Agent 推理链路中的性能提升，我采用分层指标 + 对比实验 + 统计验证的框架，确保结果可复现、可量化。
指标选择：三层覆盖
- 任务完成率（Task Success Rate）：核心指标，定义任务是否最终达成目标（如用户意图是否完全满足）。例如，在客服 Agent 中，用户请求“帮我订机票并改签酒店”，成功标准是机票预订成功且酒店改签完成，缺一不可。这避免了只关注单步正确性而忽略链路完整性。
- 工具调用准确率（Tool Call Accuracy）：评估 Agent 调用工具的参数和顺序是否正确。例如，调用“search_flights”时，参数“date”和“destination”必须符合用户输入。使用精确匹配（Exact Match）或 F1 分数衡量，但注意：工具调用正确但顺序错误（如先改签后订票）仍算失败，需结合链路上下文。
- 用户意图保持率（Intent Retention）：衡量 Agent 在多步推理中是否偏离原始意图。例如，用户说“推荐北京适合带孩子的餐厅”，Agent 若在第二步开始推荐景点，则意图偏离。用人工标注或LLM-as-Judge（如 GPT-4 评分）评估，但需控制评分偏差（如使用双盲标注）。
- 响应质量（Response Quality）：对最终输出用 BLEU/Rouge-L 或人工评分（如 1-5 分制）。注意：Agent 输出常包含结构化内容（如 JSON），直接套用 BLEU 可能失效，改用语义相似度（如 Sentence-BERT 余弦相似度）更合理。
评估方法：控制变量 + 场景覆盖
- 构建测试集：覆盖 5 种场景（完整请求、模糊请求、多步推理、错误恢复、边缘 case），每种至少 10 个用例，共 50 个。例如，模糊请求：“帮我查点东西”（需 Agent 主动追问），多步推理：“先查天气，再订酒店，最后发邮件”。
- 对比实验：优化前后 Prompt 在相同测试集上运行，记录指标。注意：Agent 推理有随机性（如 LLM 采样温度），需固定 seed 或重复运行 3 次取均值，减少方差。
- 消融实验：逐步移除 Prompt 组件（如示例、约束、角色设定），观察指标变化。例如，移除“工具调用格式示例”后，Tool Call Accuracy 从 85% 降至 60%，说明该组件是关键。
统计验证：拒绝玄学
- 使用配对 t 检验或Bootstrap 方法（推荐，因不假设正态分布）判断提升是否显著。例如，优化后 Task Success Rate 从 70% 升至 80%，Bootstrap 1000 次后 p < 0.05，说明提升非偶然。
- 注意：样本量小时（如 50 个用例），p 值可能不显著，此时改用效应量（Cohen's d） 衡量实际影响，d > 0.5 视为中等提升。
实际落地的坑 + 解法
- 坑：测试集过小导致指标波动大。例如，10 个用例中优化后成功率从 60% 到 80%，但 p 值 > 0.1，无法判断是否有效。
- 解法：用蒙特卡洛模拟生成合成数据（如基于真实日志的变体），或使用交叉验证（5-fold）减少方差。
- 坑：LLM-as-Judge 评分有偏见（如偏好长回答）。
- 解法：使用双盲标注（隐藏 Prompt 版本），并引入一致性检查（Kappa 系数 > 0.7 才采用）。
自动化：集成 CI/CD
- 每次 Prompt 变更，自动运行评估流水线（如 GitHub Actions + 测试集），生成报告（含指标变化、p 值、消融结果）。例如，使用DSPy自动优化 Prompt，并对比基线，报告“Task Success Rate +12%，p=0.03”。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从指标设计、实验方法、统计验证三个层面回答。指标上，我用任务完成率、工具调用准确率、意图保持率和响应质量，覆盖链路完整性和单步正确性。实验上，构建 50 个测试用例覆盖 5 种场景，做对比和消融实验，固定 seed 减少方差。统计上，用 Bootstrap 或配对 t 检验判断显著性，p < 0.05 才算有效。总结一句：评估 Prompt 优化效果，核心是分层指标 + 控制实验 + 统计验证，拒绝玄学。”
4️⃣ 高频追问 & 应对
追问 1：如果测试集只有 20 个用例，你怎么保证评估结果可靠？
小样本下，我会用 Bootstrap 重采样（1000 次）估计指标置信区间，而非依赖 p 值。例如，Task Success Rate 从 70% 升至 80%，Bootstrap 95% CI 为 [65%, 85%] 和 [75%, 90%]，若区间不重叠则视为有效。同时，用 效应量（Cohen's d） 衡量实际影响，d > 0.5 可接受。另外，可引入 合成数据（如基于真实日志的 LLM 生成变体）扩充测试集，但需人工校验质量。
追问 2：你提到 LLM-as-Judge，但 GPT-4 评分有偏见，怎么处理？
我会用 双盲标注：隐藏 Prompt 版本，让 Judge 只看到输出。同时，引入 一致性检查：两个 Judge（如 GPT-4 和 Claude）评分，计算 Kappa 系数，> 0.7 才采用。若不一致，人工仲裁。另外，可改用 结构化评分：让 Judge 按维度打分（如准确性、完整性、流畅性），而非单一分数，减少主观性。最后，定期用 黄金标准（人工标注 10 个用例）校准 Judge 偏差。
追问 3：你的指标中，任务完成率和工具调用准确率冲突怎么办？比如工具调用准确但任务失败。
这种情况说明 链路逻辑有误，而非单步问题。我会优先看任务完成率，因为它反映最终用户价值。然后分析失败原因：工具调用顺序错误？参数传递遗漏？意图偏离？例如，Agent 正确调用“search_flights”但忘记“book_flights”，导致任务失败。此时，优化 Prompt 需强调 步骤完整性（如“必须完成所有子任务”），并引入 中间检查点（如每步后让 Agent 确认进度）。指标上，可增加 步骤完成率（Step Completion Rate）作为辅助指标。
5️⃣ 避坑 · 常见错误答法
- ❌ 只提 BLEU/Rouge 作为唯一指标，忽略 Agent 链路特殊性。 → ✅ 必须包含任务完成率和工具调用准确率，覆盖链路完整性和单步正确性，因为 Agent 输出常是结构化或动作序列，而非纯文本。
- ❌ 直接说“优化后效果更好”，没有统计验证。 → ✅ 必须用 Bootstrap 或配对 t 检验计算 p 值，p < 0.05 才算显著，否则可能是随机波动。
- ❌ 测试集只有 5 个用例，就下结论。 → ✅ 至少 50 个用例覆盖 5 种场景，小样本时用 Bootstrap 置信区间和效应量，避免过度自信。
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“RAG 中 Prompt 优化影响检索和生成”切入，展示你如何用任务完成率（如问答准确率）和工具调用准确率（如检索 API 参数）评估，并对比 BM25 和 DPR 的 Prompt 差异。
- 如果你只做过传统 NLP：用“文本分类中 Prompt 优化”类比，说明你如何用 F1 分数和消融实验评估，并迁移到 Agent 场景，强调需要增加链路指标（如步骤完成率）。
- 如果你是校招无项目：聚焦“DSPy 自动优化 Prompt”的论文复现 demo，展示你如何用 50 个测试用例和 Bootstrap 验证提升，并提到你读过《DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines》。
- 《DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines》
- 《Evaluating Large Language Model Agents: A Survey》
- 《Prompt Engineering Guide: Evaluation Metrics for LLM Applications》
- 《Bootstrap Methods: Another Look at the Jackknife》
- 《LLM-as-Judge: A Systematic Evaluation of LLM-based Evaluation》