主题
高频面试题
如何系统地评估和优化提示词的效果？
面试官问这题，不是想听“多试几个版本”，而是想看你能不能搭出数据集、指标、回放、上线监控的完整闭环。
面试官角度分析，想考什么
- 你怎么判断一个 Prompt 真的变好了？
考察是否能用评估集和指标说话，而不是凭几次对话的体感判断。 - Prompt 评估指标怎么设计？
考察能否把正确性、格式、稳定性、成本、延迟和安全拆开看。 - LLM-as-judge 能不能直接当最终标准？
考察对自动评估偏差、人工抽检和标注一致性的理解。 - 线上效果变差时怎么定位？
考察是否能从输入分布、模型版本、检索结果、工具调用和 Prompt 版本逐层排查。
可直接抄走的 30 秒参考答案
text
我会把 Prompt 评估做成一个闭环：先定义任务成功标准，再构建覆盖正常、边界、历史失败和安全攻击的评估集；指标上拆成正确性、格式遵循、稳定性、幻觉率、成本和延迟；评估时规则校验、程序验证、LLM judge 和人工抽检结合。每次优化都做离线回归和小流量灰度，把新失败样本沉淀回评估集，这样 Prompt 才能持续变好，而不是靠手感调参。面试回答详解，知其所以然
这道题的核心不是“会不会写更漂亮的提示词”，而是能不能把 Prompt 当成可测试、可回滚、可持续优化的工程资产。
1. 先定义任务边界和成功标准
Prompt 评估要从任务定义开始。不同任务的“好”完全不同：
- 信息抽取：字段准确、字段完整、JSON 可解析、缺失值处理合理。
- 客服问答：事实正确、语气符合规范、不越权承诺、能识别需要转人工的场景。
- 代码生成：能运行、测试通过、满足框架约束、没有引入明显安全问题。
- 总结改写：保留关键事实、结构清楚、不添加原文没有的信息。
一个可评估的 Prompt 通常要把目标写成这样：
text
输入样本 -> Prompt 版本 -> 模型输出 -> 自动检查 / LLM 评审 / 人工抽检 -> 指标报告2. 建立分层评估集
评估集不要只放“正常样本”。成熟的 Prompt 评估至少包含四类：
- 黄金路径样本：最常见、最重要的主流程输入。
- 边界样本：缺字段、歧义、多语言、长文本、噪声文本。
- 失败回归样本：线上出过错的 case，修复后必须长期保留。
- 安全样本：注入、越权请求、敏感信息、恶意格式破坏。
评估集要版本化，样本要有输入、期望行为、评分标准和来源说明。否则 Prompt 改动后很难判断是 Prompt 变好，还是测试样本变了。
3. 指标要拆开，不要只看一个总分
Prompt 效果通常由多维指标组成：
- 任务正确性：答案是否解决问题，抽取字段是否正确。
- 格式遵循率：JSON、Markdown、表格、枚举值是否符合约束。
- 稳定性：同一输入多次调用是否输出一致。
- 拒答准确率：该拒绝时拒绝，不该拒绝时不误杀。
- 幻觉率：是否编造来源、数字、接口或业务规则。
- 成本和延迟：Token 数、首 token 延迟、总耗时。
- 可维护性：Prompt 是否可读、可参数化、可复用。
面试里要强调：Prompt 优化很容易“提升一个指标，伤害另一个指标”。例如加很多规则能提高安全性，但会增加 token、降低自然度，还可能让简单问题变得啰嗦。
4. 自动评估和人工评审要结合
常见评估方式可以分三层：
- 规则检查：JSON schema、正则、枚举值、长度、必填字段，便宜且稳定。
- 程序化验证：代码能否运行、SQL 能否解析、引用链接是否存在。
- LLM-as-judge：评估语义正确性、语气、覆盖度和复杂主观标准。
LLM-as-judge 不能裸用。它会受提示词、顺序、长度、模型偏好影响，所以要固定 judge prompt，抽样做人审校准，关键场景最好用双评审或仲裁机制。
5. 优化过程要可回滚
一个稳妥的优化流程是：
text
收集失败样本
-> 分类根因
-> 修改 Prompt 或上下游链路
-> 离线评估对比
-> 小流量灰度
-> 线上监控
-> 沉淀新失败样本Prompt 版本要和模型版本、参数、检索配置、工具配置一起记录。否则线上变差时，你不知道是 Prompt 改坏了，还是模型升级、RAG 召回变化或 temperature 改动导致的。
面试官追问3个问题
追问一：LLM-as-judge 的主要风险是什么？
- 考察点：是否知道自动语义评估不是绝对真理。
- 回答方向：说明 judge 会有顺序偏差、长度偏好、模型偏好和被注入风险，生产中要固定评审标准、抽样人工复核，并用规则校验覆盖硬约束。
追问二：评估集应该多大？
- 考察点：是否理解规模和覆盖度的取舍。
- 回答方向：小团队可以先从几十到几百条高价值样本做起，关键是覆盖高频、边界和历史失败；随着线上流量增长，再按业务分布和失败类型扩充。
追问三：离线评估很好，线上仍然差，怎么办？
- 考察点：是否能诊断分布偏移。
- 回答方向：检查线上输入分布、模型版本、RAG 召回、工具返回、Prompt 参数和用户交互路径，把线上失败样本回放到离线环境，定位差异来源。
扩展知识
Prompt 失败根因不要只归咎于提示词
很多“Prompt 效果差”其实来自上下游：
- 检索召回错了，Prompt 再好也只能基于错误材料回答。
- 工具返回字段不稳定，模型只能猜。
- 输出 schema 设计过复杂，格式错误率自然升高。
- 评估集和线上分布不一致，离线分数会虚高。
常见优化手段
- 收紧任务边界：明确能做什么、不能做什么。
- 结构化输入：用分隔符、字段名、XML/JSON 片段降低歧义。
- 增加反例：告诉模型哪些输出不允许出现。
- 拆分任务：把复杂 Prompt 拆成分类、检索、生成、校验多个步骤。
- 降低随机性：关键生产任务用较低 temperature，并固定模型版本做评估。