生产级 Prompt 工程与评测体系
Prompt 模板化、版本管理、离线 eval 与 CI 门禁——让 AI 功能像发版一样可回归。
Token 计量、链路追踪、质量指标与模型降级——AI 功能上线后如何管得住。
前置阅读:Prompt 工程与评测 · 体系第 7 篇(完结)
AI 功能上线第三周,账单突然翻倍——排查发现某个 无 maxTokens 限制的 summarizer 被循环调用,单用户一天烧掉 120 万 token。之后我们给所有 AI 路径加了 计量、预算、降级、告警,月成本波动从 ±80% 压到 ±15%。
| 维度 | 指标 | 用途 |
|---|---|---|
| 延迟 | TTFT、E2E、tool P95 | 体验 / 检索瓶颈 |
| 成本 | prompt/completion tokens、$/feature | 预算 |
| 质量 | 👎 率、citation 率、eval 分 | Prompt/检索回归 |
| 可靠 | 5xx、tool 失败率、超时 | 稳定性 |
| 安全 | 注入拦截次数、PII 命中 | 合规 |
与通用 前端监控 不同:AI 必须 按 trace 串起 retrieve → tool → generate。
traceId: tr_abc
├─ span: retrieve 420ms topK=8
├─ span: tool:search_docs 180ms
├─ span: llm.stream TTFT=900ms tokens=1240/380
└─ span: post_filter 12ms
BFF 在每个 SSE 事件带 traceId;前端 error 上报带同一 id。
// middleware/log-ai-request.ts
export async function logAICompletion(meta: {
traceId: string;
userId: string;
feature: string;
model: string;
promptVersion: string;
usage: { promptTokens: number; completionTokens: number };
latencyMs: number;
thumbs?: 'up' | 'down';
}) {
await metrics.ingest('ai_completion', meta);
if (meta.usage.promptTokens + meta.usage.completionTokens > USER_DAILY_CAP) {
await rateLimiter.block(meta.userId);
}
}
| 层级 | 策略 |
|---|---|
| 用户 | 免费 50k tokens/日,超出降级 mini |
| 功能 | 内部助手 vs 对外客服不同 quota |
| 环境 | staging 禁止 GPT-4o |
gpt-4o → gpt-4o-mini → 仅检索摘要(不生成)→ 固定文案
触发条件:预算 90%、上游 429、P95 E2E > 8s。
我们缓存命中后 成本 -22%,要注意 invalidation 与版本号绑定。
Dashboard: AI Health
- 👎 率 by promptVersion(24h)
- Citation 率 by 检索模式
- Cost by feature(stacked bar)
- Tool 失败 Top 5
告警示例:
search_docs P95 > 3s → 索引工单Prompt 评测 是离线门禁;线上 👎 是在线信号。我们规则:
| 指标 | 治理前 | 治理后 |
|---|---|---|
| 月 LLM 成本波动 | ±80% | ±15% |
| 成本可 attribution 比例 | ~30% | 98% |
| P0 成本事故 | 2 次/季 | 0(8 个月) |
| 👎 → 定位到 trace | 难 | < 5min |
恭喜完成 AI 应用开发体系 01→07 全路径。可回到 专题首页 复习或按需重读。
AI 应用上线只是开始。不可观测的 AI = 不可控的成本和质量。这部分是 AI 应用开发岗位常见的工程化要求,值得系统整理。