面试题 · Prompt
搜索「RAG」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
在进行Prompt优化时，应采用哪些定量和定性指标来评估其在Agent推理链路中的实际性能提升？请说明实验设计和对照方法。
任务层指标
资源层指标
稳定性指标
学习内容与项目面试，在同一条路上。
对照组设置
关键控制
分层评估
常见陷阱
建议系统学习该知识点
场景切入
假设你在优化一个电商客服Agent的Prompt，想让它在处理退换货时更少出错、更省钱。你会用什么指标来评估新Prompt到底有没有变好？
层层追问
你平时怎么判断Prompt改得好不好？……那光看成功率够吗？……如果我想控制成本，你会加什么指标？……怎么设计对比实验才能服人？
直球架构
设计一套Prompt优化的评估方案，包括定量和定性指标，以及实验对照方法。要覆盖任务层、资源层和稳定性，怎么确保实验可信？
这道题其实是在问，怎么量化一个Prompt改动对[[Agent]]推理链路的真实影响，而不只是拍脑袋觉得好。我一般会从定量和定性两个维度去评估，而且真正上线的时候，两者要结合起来看。
先说定量指标。核心是任务层的成功率，比如在客服退款场景里，用户说‘我买的东西降价了，退差价’，Agent能不能正确走完查订单、算差价、发起退款这个流程。这是端到端的硬指标。但只看成功率不够，我会同时看步骤效率，平均用了多少次工具调用，如果新Prompt让Agent多绕了一圈才成功，那可能只是碰巧对了。另外，Token消耗和延迟也很关键，尤其是线上服务，Prompt变长导致成本翻倍或者用户等太久，那成功率再高也上不了线。稳定性指标我特别关注方差，同一个Prompt跑十次，结果波动太大，说明Prompt对模型状态敏感，这很危险。
定性维度呢，我更看重可解释性和鲁棒性。可解释性就是说，Agent的中间推理步骤能不能让人看懂，比如在退款场景里，它为什么先查订单状态而不是直接调退款接口？如果推理链跳步或者乱来，那即使这次成功了，下次遇到类似但不同的case也容易崩。鲁棒性就是测边界case，比如用户说‘我买的东西降价了，但订单号忘了’，Agent能不能处理？或者故意给个矛盾指令，它会不会死循环？这些在测试集里很难覆盖全，但上线前必须人工抽检一批。
实验设计上，我的做法是分层评估。先单步验证，比如单独测[[ReAct]]里的Thought生成是否合理，再端到端跑完整链路。对照组一定要控制单一变量，固定模型版本、温度、工具集。测试集我会分层抽样，简单、中等、困难case按比例分配，样本量至少每组100条以上，否则统计不显著。另外，我会特意构造对抗测试，比如多轮交互里用户中途改需求，看Agent能不能跟上，避免状态漂移累积错误。
这里有个坑：指标提升但实际体验下降。比如新Prompt让成功率从80%涨到85%，但多消耗了30%的Token，或者对某些常见case变得特别慢。所以上线前我会做A/B小流量，同时看用户满意度抽检，不能只看指标。还有就是避免在训练集上评测，那会过拟合，必须用独立的验证集。
其实还有一个更棘手的问题：当Prompt优化和模型微调同时进行时，怎么区分各自的贡献？比如用了[[SFT]]之后，同样的Prompt效果变了，那到底是Prompt好还是模型好？这个我一般会固定模型版本先做Prompt实验，再反过来固定Prompt做微调实验，但实际业务里两者经常迭代，很难完全隔离。
所以整体上，我更倾向把Prompt优化看成一种低成本、高频迭代的手段，但它的上限受限于模型能力。如果遇到效果瓶颈，我会考虑结合[[Self-RAG]]或者[[Chain-of-Verification]]这类框架，让Agent自己学会反思，而不是死磕Prompt。