AI应用成本与质量量化治理#
一句话答案#
AI 应用治理的核心是「质量-成本-延迟」不可能三角的量化平衡：用质量指标（Faithfulness/Recall）设下限、成本指标（$/query）设上限、延迟指标（P99）设 SLO，三者联动调优而非单维优化。
核心要点
一、不可能三角
质量（Quality）
/ \
/ 在这个三角 \
/ 内找平衡点 \
/________________________\
成本（Cost） 延迟（Latency）
提升质量 → 用更大模型/更多检索/多轮反思 → 成本↑ 延迟↑
降低成本 → 用更小模型/减少调用次数 → 质量↓
降低延迟 → 跳过反思/减少检索轮次 → 质量↓量化治理的核心：为三个维度各设可接受的阈值，在约束下寻找最优解
二、成本量化模型
单次查询成本拆解：
Cost/Query = Σ(LLM调用) + Σ(Embedding调用) + Σ(Rerank调用) + 基础设施分摊
LLM调用 = input_tokens × input_price + output_tokens × output_price
Embedding = chunks × embedding_price
Rerank = candidates × rerank_price
拆解示例（只列 token 量，单价按所用模型的官方价目表代入）：
意图分类: ~1K input + ~50 output（小模型）
检索 embedding: 1 次 query embedding
Rerank: N 个候选
LLM 生成: ~3K input + ~500 output（主模型）
反思/校验: 触发率 r × 一次额外调用
──────────────────────────────────────
总计 = 各项 token × 单价 之和；按触发率加权的环节要乘概率
注意：output 单价通常是 input 的数倍（主流厂商多为 4-8 倍），长输出的环节往往是大头；
命中厂商 prompt cache 的输入 token 按折扣价计（如 Anthropic 缓存读取为 input 价的 0.1 倍或更低）。成本优化四字诀「缓级压批」：
| 策略 | 原理 | 效果 |
|---|---|---|
| 缓(Cache) | 语义缓存相似查询结果；厂商 prompt cache 复用稳定前缀 | 语义缓存命中的请求省掉整次 LLM 调用；prompt cache 让重复前缀按折扣价计费 |
| 级(Cascade) | 简单问题用小模型，复杂问题用大模型 | 小模型占比越高、大小模型单价差越大，省得越多 |
| 压(Compress) | 压缩 prompt/上下文 | 减少 input token，要验证不伤质量 |
| 批(Batch) | 非实时任务走异步批量接口 | OpenAI、Anthropic 的 Batch API 均为五折（以官方价格页为准） |
三、质量量化指标体系
| 维度 | 指标 | 可接受下限 | 优秀水平 |
|---|---|---|---|
| 检索准确性 | Recall@5 | ≥0.70 | ≥0.85 |
| 排序质量 | MRR | ≥0.50 | ≥0.70 |
| 回答忠实度 | Faithfulness | ≥0.80 | ≥0.90 |
| 回答相关性 | Relevance | ≥0.80 | ≥0.90 |
| 安全性 | Adversarial Rejection | =1.00 | =1.00 |
| 任务完成度 | Task Completion | ≥0.70 | ≥0.85 |
质量-成本联动决策表：
| 质量达标? | 成本达标? | 决策 |
|---|---|---|
| ✅ | ✅ | 维持当前配置 |
| ✅ | ❌ | 降级模型/增加缓存/压缩context |
| ❌ | ✅ | 升级模型/增加检索轮次/开启反思 |
| ❌ | ❌ | 重新审视架构（可能需要根本性优化） |
四、延迟量化与优化
延迟拆解（示意，数值随模型、部署和输出长度差异很大）：
Total Latency = 意图分类 + 检索 + Rerank + LLM生成 + [反思/校验 × 触发率]
其中 LLM 生成 ≈ 首 token 时间(TTFT) + 输出 token 数 × 每 token 生成时间通常 LLM 生成占大头，其次是 Rerank 和按条件触发的二次调用；优化前先按环节埋点拿到各段 P50/P99。
延迟优化手段：
| 手段 | 效果 | 代价 |
|---|---|---|
| 流式输出(SSE) | 总耗时不变，但用户感知延迟降到首 token 时间 | 流式下已发出的内容无法再改写 |
| 多路检索并行（向量 / BM25 同时跑） | 检索段耗时取最慢一路而不是相加 | 架构复杂度↑ |
| 小模型路由(简单query) | 小模型生成更快 | 质量略降，需评测把关 |
| 缓存命中 | 跳过检索和生成，直接返回 | 新鲜度风险 |
| 跳过反思(高置信) | 省掉一次额外 LLM 调用 | 少数 query 质量降 |
五、预算告警与治理
| 级别 | 触发条件 | 动作 |
|---|---|---|
| 绿色 | 日消耗 < 日预算 60% | 正常运行 |
| 黄色 | 日消耗 > 日预算 80% | 通知管理员 |
| 橙色 | 月消耗 > 月预算 90% | 自动降级到小模型 |
| 红色 | 月消耗 > 月预算 100% | 拒绝非核心请求/人工决策 |
成本异常检测：
- 单次查询 Token 超过 P99 的 3 倍 → 可能是 prompt injection 或异常输入
- 某用户/租户短时间成本飙升 → 可能是滥用或循环调用
- 日成本突增 50%+ → 自动告警 + 临时限流
六、Dashboard 核心看板
┌─────────────────────────────────────────┐
│ AI 应用治理看板 │
├─────────┬───────────┬───────────────────┤
│ 质量 │ 成本 │ 延迟 │
│ Faith: │ ¥/query: │ P50: P99: │
│ x.xx │ x.xxx │ x.xs x.xs │
│ Recall: │ 日消耗: │ │
│ x.xx │ 已用/预算 │ 缓存命中率: xx% │
├─────────┴───────────┴───────────────────┤
│ 趋势图: 过去7天 质量/成本/延迟 曲线 │
│ 异常: 无告警 │
└─────────────────────────────────────────┘面试回答（2分钟版）
AI 应用治理的核心挑战是质量、成本和延迟的不可能三角。我的治理方式是给三个维度各设量化指标和阈值：质量用 Faithfulness 不低于 0.80 和 Recall 不低于 0.70 设下限，成本用每 query 成本设上限，延迟用 P99 设 SLO。成本拆解到每个环节：LLM 调用、Embedding、Rerank 各多少钱，这样优化有的放矢。降本常用「缓级压批」四个手段：语义缓存和厂商 prompt cache 减少重复计算，大小模型级联让简单请求走小模型，反思这类二次调用只在低置信时触发，Prompt 压缩减少 Token，非实时任务走 Batch API 拿五折。结合项目时可以讲：每个手段各省了多少、怎么证明质量没掉。预算治理分四级：绿色正常、黄色通知、橙色自动降级到小模型、红色拒绝非核心请求。成本异常检测会捕捉单次 Token 超 P99 三倍的异常请求，防止 injection 或滥用导致成本失控。整个治理的核心思路是把三个维度联动起来看：质量达标但成本超标就降级模型，成本达标但质量不够就升级模型或增加检索轮次。
追问与易错
追问方向：
- “怎么选择降级到哪个模型？”→ 建立模型-质量-成本基准表，对每个任务类型跑评测拿到质量分数，选满足质量下限的最便宜模型；如摘要这类简单任务，同一厂商的小模型单价常常只有旗舰模型的几分之一到几十分之一
- “缓存怎么保证答案新鲜度？”→ KB 版本校验（知识库更新时 version+1）+ 缓存设 TTL（如 1 小时）+ 知识库更新时主动清除相关语义缓存条目
- “怎么向业务方解释成本？”→ 按功能维度拆分账单，展示每个功能的 cost/query 和质量指标（准确率/满意度），让业务方看到成本与价值的对应关系
- “多租户怎么做成本分摊？”→ 每次 LLM 调用记录 tenant_id + input/output token 数 + 模型类型，月度按租户汇总出账单；配合配额预算机制防止单租户超支
易错点：
- ❌ “成本优化就是换小模型”——要先量化质量影响，不能盲目降级
- ❌ “延迟不重要，用户能等”——交互场景里首 token 等待越长，放弃率越高；首 token 和总耗时都要设 SLO（具体阈值按业务定）
- ❌ “成本只看 LLM 调用费用”——还有 Embedding/Rerank/存储/基础设施的分摊
- ✅ 核心思路：量化→联动→自动化（手动调参不可持续）