详情

首页手游攻略 把 LLM 测试从"手摸"变成工程化——我试了 Promptfoo

把 LLM 测试从"手摸"变成工程化——我试了 Promptfoo

佚名 2026-08-05 09:33:56

调提示词这件事,我以前基本靠手感。改一版 prompt,手动跑几条用例,看着输出觉得"好像好点了"就上线。但LLM 输出有随机性,几条样本根本说明不了问题,而且上线后经常发现某些 corner case 还是翻车。

最近开始用 Promptfoo。它是一个开源的 LLM 测试与评估框架,也支持红队安全测试。我用它做了一个项目的 prompt 回归测试,效果比手动测好很多。今天聊聊这个工具。

一、Promptfoo 解决什么问题

简单说,它把软件工程里的测试驱动开发思想搬到了 LLM 应用上。

传统调 prompt 的问题:

手动测几条,主观判断 换模型、换提示词版本后没有回归基线 安全漏洞(提示注入、越狱、数据泄露)靠人工想,覆盖不全 不同模型之间没有系统对比

Promptfoo 的做法是:用声明式配置定义测试矩阵,自动运行、自动断言、生成对比报告。

YAML 配置文件├── prompts(待测提示词)├── providers(模型提供商)├── tests(测试用例)└── assertions(断言规则)│▼promptfoo eval 自动运行│▼生成 Web UI 报告 / CI 门禁

二、核心配置长什么样

Promptfoo 用 YAML 配置,结构很清晰。一个最小示例如下:

prompts:- "将以下文本分类为正面或负面:{ {text}}"- "判断这段评论的情感倾向(正面/负面):{ {text}}"providers:- openai:gpt-4o- anthropic:claude-3-5-sonnettests:- vars:text: "这家餐厅太棒了"assert:- type: icontainsvalue: "正面"- vars:text: "服务态度很差"assert:- type: icontainsvalue: "负面"- vars:text: "一般吧,没什么特别的"assert:- type: answer-relevancethreshold: 0.7

这个配置会:

用两个提示词模板 跑两个模型 对三个测试用例分别断言 自动生成 2 × 3 = 6 组结果对比

三、断言机制是它的核心竞争力

Promptfoo 支持多种断言类型:

断言类型用途
equals / contains / icontains精确匹配、包含判断
answer-relevance答案相关性
context-recall / context-faithfulnessRAG 评估
json-schema校验输出 JSON 结构
javascript / python自定义脚本验证
llm-rubric用更强的模型当评委打分

最实用的是 llm-rubric。复杂业务场景下,规则很难写,可以让 GPT-4o 或 Claude 给输出打分,并说明理由。虽然成本高一点,但覆盖了大量人工难以枚举的情况。

四、多模型对比很实用

我同一个测试配置跑 GPT-4o、Claude 3.5 Sonnet 和本地 Ollama 模型,Promptfoo 会输出一张对比表:

模型通过率平均耗时Token 消耗成本
GPT-4o95%1.2s12k$0.18
Claude 3.592%1.5s14k$0.21
Ollama llama378%4.5s18k$0

这个表对选型很有帮助。有时候本地模型够便宜但质量差一点,有时候云端模型质量高但贵。用数据说话,比拍脑袋选型靠谱。

五、红队测试:不只是功能测试

Promptfoo 还有一个很强的能力:自动化红队测试。

它可以自动生成大量对抗性输入,测试你的应用是否存在:

提示词注入(Prompt Injection) 越狱攻击(Jailbreak) 敏感信息 / PII 泄露 有害内容生成 业务规则绕过 Agent 不安全工具调用

使用方式也很简单:

npx promptfoo@latest redteam setupnpx promptfoo redteam runnpx promptfoo redteam report
连接应用│▼生成上下文感知攻击│▼运行测试并识别漏洞│▼PR 中显示发现   修复建议│▼持续监控

这对要上线的 AI Agent 很重要——你自己想不到的攻击向量,Promptfoo 的社区威胁情报会帮你想到。

六、接进 CI/CD

Promptfoo 是 CLI 工具,接进 CI/CD 很自然。我把它配进 GitHub Actions:

name: LLM Evalon:pull_request:paths:- 'prompts/**'- 'promptfooconfig.yaml'jobs:eval:runs-on: ubuntu-lateststeps:- uses: actions/checkout@v4- run: npm install -g promptfoo- run: promptfoo eval --config promptfooconfig.yamlenv:OPENAI_API_KEY: ${ {secrets.OPENAI_API_KEY }}

这样每次改 prompt 都会自动跑测试,分数低于阈值就阻止合并。把提示词变更纳入代码质量门禁,这是真正的"测试即代码"。

七、Web UI 报告

跑完测试后,Promptfoo 会起一个本地网页:

promptfoo view

报告里能看到每个用例在每个模型上的输出、断言是否通过、token 消耗、耗时。失败用例可以点进去看完整输出和失败原因,排查很方便。

八、我的实际使用感受

适合的场景:

prompt 已经比较稳定,需要防止回归 多模型选型,需要量化对比 对安全性有要求,需要系统做红队测试 团队协作,需要把 prompt 测试纳入 CI 流程

不适合的场景:

还在快速迭代 prompt 的早期阶段,测试配置反而拖慢速度 完全不在乎成本和质量,只求快 没有可定义的期望输出,断言写不出来

最大的改变:

用了 Promptfoo 之后,我调 prompt 不再靠"感觉更好了",而是看通过率有没有提升、哪个断言失败了、成本变化多少。这种量化反馈让提示词工程更像工程,而不是炼丹。

结语

Promptfoo 代表了一个趋势:LLM 应用正在从"写 prompt"走向"测试 prompt"。

当提示词成为生产系统的一部分,它就需要有单元测试、回归测试、安全测试。Promptfoo 把这套基础设施提供出来了,而且开源、可本地运行、能接 CI/CD。

如果你维护的 LLM 应用已经上线或准备上线,值得把它加进工具链。

相关资讯
点击查看更多
游戏推荐
推荐专题
热门阅读
推荐下载