RAG-05在线治理-Caching-Cost-aware-RAG

本文属于 RAG 工程框架中的「5 在线运营与成本治理」环节，聚焦「Caching Cost aware RAG」方法。可先阅读 RAG-00.方法概述再进入本篇。

原理

对查询、检索结果、生成结果做分层缓存，并引入预算路由。

flowchart TD
  Q[请求] --> N[归一化]
  N --> C1{Query Cache 命中?}
  C1 -->|是| A1[直接返回]
  C1 -->|否| R[检索]
  R --> C2{Retrieval Cache 命中?}
  C2 -->|是| G[生成]
  C2 -->|否| IDX[索引检索]
  IDX --> G
  G --> C3[Answer Cache]
  C3 --> Out[返回]

优缺。

优点：大幅降。token 与检索开销；提升稳定性。
缺点：缓存失效策略复杂，可能返回过期答案。

性能/资源

高频场景 ROI 极高。
需权衡命中率与新鲜度。

应用场景

高并发客服、企业门户问答、API 化 RAG 服务。

统一合成数据示例

输入数据片段

{
  "query": "机票报销上限是多少？",
  "traffic_qps": 120,
  "budget_per_1k_requests": 18.0
}

中间结果（缓存与预算路由）

{
  "query_cache_hit": true,
  "retrieval_cache_hit": true,
  "generation_call_skipped": true,
  "estimated_cost_saved_usd": 4.2
}

最终生成示例（含引用）

{
  "answer": "机票报销上限为 2000 元。",
  "latency_ms": 42,
  "citations": [{"doc_id": "D01", "evidence_span": "机票报销上限 2000 元"}]
}

原始发表与工程实现

代表性原始发表：语义缓存工程实践。
核心解决问题：解决推理成本与时延。
成熟实现工具：Redis, GPTCache。

详细原理拆解

多级缓存优化 E[cost]=p_miss*infer_cost+cache_cost。
典型实现可拆为：输入预处理 -> 方法核心计算 -> 候选/证据构建 -> 生成与引用。
工程调优重点：质量（准确率/引用率）与成本（时延/token）的联合优化。

flowchart LR
  In[输入 Query 与知识] --> Core[方法核心计算]
  Core --> Rank[匹配/路由/排序]
  Rank --> Build[证据组装]
  Build --> Out[答案与引用]

工程落地扩展示例

伪代码

def cost_aware_answer(query, cache_embed, cache_gen, pipeline, ttl_s: int):
    key = cache_embed.key(query)
    if hit := cache_gen.get(key):
        return hit
    ans = pipeline(query)
    cache_gen.set(key, ans, ttl=ttl_s)
    return ans

参数示例

semantic_cache: true
retrieval_cache_ttl_s: 600
answer_cache_ttl_s: 300
invalidate_on_doc_version: true

常见失败案例

失败模式 1：制度已更新，缓存仍返回旧上限，合规风险。
失败模式 2：embedding 缓存键过粗，不同部门问法命中同一键。
失败模式 3：只缓存答案不缓存引用，审计链路断裂。

Demo 数据带入计算示例

1
2

infer_cost=0.012/req，hit=70%，cache_cost=0.001 → E[cost]=0.3*0.012+0.001=0.0046，降本约 61.7%。
若 doc_version 变更未 invalidate，**命中率仍高但答案错**——成本指标与正确率需联合监控。