Prompt 评估流水线：不要靠几次手工试问判断效果

Prompt 评估流水线：不要靠几次手工试问判断效果

一、Prompt 优化需要实验设计

Prompt 调整很容易让人产生错觉。手工试几个问题，回答看起来更流畅，就认为新版本更好；换几个样本，又觉得旧版本更稳。大模型输出具有随机性，样本分布也会影响判断。没有固定评测集和指标，Prompt 优化很容易变成主观体验比较。

工程化 Prompt 评估应像模型实验一样管理：固定测试集、固定模型版本、固定推理参数、记录 Prompt 版本、计算自动指标并进行人工抽检。尤其是在客服、知识问答、代码生成和内容审核场景中，Prompt 变化可能影响安全边界和拒答策略，不能只看回答是否“更像人”。

二、评估链路：Prompt 版本必须可追踪

flowchart TD A[Prompt 模板版本] --> B[固定评测集] B --> C[模型推理] C --> D[自动评分] C --> E[人工抽检] D --> F[对比报告] E --> F F --> G[灰度发布]

评测集应覆盖正常问题、边界问题、无答案问题、恶意输入和格式要求。只用常规样本评测，容易让 Prompt 在安全和拒答方面退化。对于 RAG 系统，还要包含证据不足场景，观察模型是否会明确说明无法回答。

Prompt 版本要像代码一样管理。模板内容、变量字段、系统指令、示例数量和输出格式都应记录。一次线上问题发生后，团队需要知道当时使用的是哪个 Prompt，而不是在文档里搜索一个可能已经被覆盖的文本。

三、评估脚本：固定参数减少随机性

下面示例展示一个简化的评估循环。真实项目中应加入重试、日志、成本统计和结果缓存。

def evaluate_prompt(client, prompt_template, dataset): results = [] for item in dataset: prompt = prompt_template.format(question=item["question"], context=item["context"]) answer = client.generate( prompt=prompt, temperature=0.0, max_tokens=512, ) results.append({"id": item["id"], "answer": answer, "gold": item["gold"]}) return results

评估时建议先使用temperature=0降低随机性。如果业务线上必须使用更高温度，也可以在稳定评估后增加多次采样，观察输出方差。Prompt 版本比较时，模型、参数和评测集必须保持一致，否则无法判断差异来源。

自动评分可以包括格式合法率、关键词覆盖、引用正确率、拒答准确率和事实一致性。生成任务不要只依赖一个综合分。不同指标反映不同风险，格式不合法会影响系统解析，事实错误会影响业务信任，拒答错误会影响安全。

四、发布策略：小步灰度而不是一次替换

Prompt 看似只是文本，但它实际改变了模型行为。新 Prompt 上线前应生成对比报告，列出提升样本、退化样本和不确定样本。退化样本比平均分更重要，因为它们往往揭示边界条件被破坏。

灰度发布时，可以按流量比例或租户分组启用新 Prompt，并记录线上成功率、用户反馈、人工转接率、平均输出长度和成本变化。若新 Prompt 让回答变长，token 成本可能上升；若拒答更严格，用户满意度可能下降。这些都需要数据判断。

最后，要建立回滚机制。Prompt 配置应支持版本切换，并保留旧版本。不要把 Prompt 写死在代码里，也不要只保存在个人文档中。Prompt 是生产系统的一部分，应进入配置、审计和发布流程。

五、总结

Prompt 评估不能依赖少量手工试问。固定评测集、版本管理、参数控制、自动指标、人工抽检和灰度发布，是 Prompt 工程化的基本要求。把 Prompt 当作可实验、可追踪、可回滚的资产，才能稳定改进模型表现。