面试题 · Prompt
搜索「RAG 检索增强生成」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
在对Prompt进行优化时，应采用哪些评估指标和实验方法来判断其在Agent推理链路中的实际性能提升？
1. 任务完成指标（端到端）
2. 推理质量指标
3. 效率与成本指标
对照实验设计
学习内容与项目面试，在同一条路上。
评估方式组合
关键原则
建议系统学习该知识点
场景切入
假设你正在做一个电商客服Agent，用户问“我的订单什么时候到”，你设计了一条Prompt让Agent调用物流查询API。现在你觉得Prompt效果不好，想优化一下。从实际业务角度看，你会用什么指标来判断新Prompt真的比旧的好？
层层追问
你优化Prompt的时候，一般怎么衡量它变好了？……比如只看回答通顺够吗？……那如果Agent调用工具出错了呢？……所以你具体会从哪些维度去评估，实验怎么做才能保证结论靠谱？
直球架构
请直接设计一套针对Agent推理链路中Prompt优化的评估方案。包括：你选哪些指标（至少覆盖任务完成、推理质量和成本效率），以及实验方法怎么设计（对照、自动评估、人工抽检等）。
这道题表面问的是Prompt怎么评估，但本质是问：在[[Agent]]推理链路里，你如何判断一个Prompt改动是真的带来了提升，还是只是运气好？因为Agent的Prompt和普通LLM问答不一样，它涉及工具调用、多步推理，一个小改动可能让成功率从70%跳到90%，也可能让[[幻觉]]率翻倍。所以我的核心思路是：评估指标必须围绕端到端的任务完成，而不是只看单步的文本相似度。
先说评估指标。我会分三个维度来看。先看任务完成指标，这是最硬的。比如客服退款场景，Agent需要调用订单查询、退款策略、审批等多个工具。我会看任务成功率，也就是最终退款成功比例；再看步骤正确率，比如调用退款接口时参数传对了没有；还有结果一致性，同一个用户问同一个问题，输出不能今天行明天不行。接着说推理质量指标，重点关注工具调用准确率，比如[[Function Calling]]的参数格式、字段值对不对，还有Hallucination比例，Agent自己编了个退款原因就很麻烦。再补充效率和成本，包括Token消耗和延迟，如果为了提升成功率把Prompt写得特别长，导致每次调用多花50%的Token，那业务上不一定划算。
具体说一下实验方法。一个靠谱的做法是：先固定模型版本、温度参数、工具集这些变量，然后按任务类型分层抽样建测试集，比如客服场景里区分简单退款、争议退款、跨店退款。设置基线Prompt和新Prompt做A/B对比。评估方式我习惯自动加人工组合，自动用规则或者模型判断输出格式和结果对不对，人工重点抽边界case，比如退款金额刚好超限、订单状态异常这些。这里有个坑，就是别只看平均指标，要关注长尾case。很多时候一个Prompt优化只解决了某类失败，比如让Agent在满减政策冲突时能正确选择，但可能引入新的退化，比如把简单退款步骤变多了。所以我会建一个回归测试集，每次改完跑一遍，确保之前修好的case没坏。
落地时有个重要前提：模型版本必须锁定。我见过有人优化Prompt时模型偷偷升级了，结果指标提升其实是模型变强了，不是Prompt的功劳。另外，如果业务场景是实时性要求高的，比如在线客服，那延迟和Token消耗的权重就要提高，甚至可能为了快牺牲一点点成功率。反过来，如果是离线批量处理，成功率就是第一位的。
不过这里有一个更微妙的问题：当Agent的推理链路特别长的时候，比如需要连续调用五六个工具，这时候Prompt优化可能遇到瓶颈，你修好了第一个节点的错误，但下一个节点又坏了，这就是所谓的局部优化和全局效果的矛盾。我自己的经验是，这时候可能要考虑用[[Self-RAG]]或者[[Reflexion]]让Agent自己反思纠错，而不是死磕Prompt。
所以整体上，我的取舍是：优先用端到端任务成功率作为北极星指标，把Token消耗和延迟作为约束条件。如果成功率已经很高了，比如95%以上，我会更关注稳定性和长尾case；如果还在80%以下，那先集中修最大的失败模式，比如工具调用格式错误，而不是去抠Prompt的措辞。