| # ScholarMind 高级缓存加速方案 |
|
|
| > 本文档补充原有 4 级缓存体系，新增 **7 层缓存机制**，覆盖从应用层语义缓存到 GPU KV Cache 硬件层的全栈加速。 |
|
|
| --- |
|
|
| ## 缓存全景图 |
|
|
| ``` |
| ┌──────────────────────────────────────────────────────────────────────────────────┐ |
| │ ScholarMind 7层缓存加速栈 │ |
| ├──────────────────────────────────────────────────────────────────────────────────┤ |
| │ │ |
| │ Layer 1 ─── 语义缓存 (GPTCache) │ |
| │ "What is SnapKV?" ≈ "Explain SnapKV" → 同一缓存命中 │ |
| │ 延迟: ~5ms (缓存命中) vs ~1500ms (LLM调用) │ |
| │ 节省: ~100× 延迟, ~100% API成本 │ |
| │ │ |
| │ Layer 2 ─── 检索结果缓存 (语义级) │ |
| │ 相似query复用检索结果, 跳过向量搜索+图谱遍历+重排 │ |
| │ 延迟: ~2ms vs ~300ms │ |
| │ 节省: 避免重复检索计算 │ |
| │ │ |
| │ Layer 3 ─── API Provider 提示缓存 │ |
| │ OpenAI: 自动, ≥1024 tokens → 90%输入token折扣 │ |
| │ Anthropic: cache_control 标记 → 90%折扣 │ |
| │ DeepSeek: 自动磁盘KV → 90%折扣 │ |
| │ 节省: 50-90% API成本, 最高80%延迟降低 │ |
| │ │ |
| │ Layer 4 ─── vLLM 前缀缓存 (APC) │ |
| │ 共享 system prompt + 文档chunk 的 KV Cache │ |
| │ 节省: 2-8× TTFT (首Token延迟) 降低 │ |
| │ │ |
| │ Layer 5 ─── RAG KV Cache 复用 (LMCache/CacheBlend) │ |
| │ 预计算每个文档chunk的KV状态, 组合时选择性重算5-15% │ |
| │ 节省: 2.2-3.3× TTFT, 2.8-5× 吞吐提升 │ |
| │ │ |
| │ Layer 6 ─── KV Cache 压缩 (SnapKV/Quest) │ |
| │ 长文档场景: 只保留注意力关键的20% KV位置 │ |
| │ 节省: 3.6× 解码加速, 8.2× 显存效率 │ |
| │ │ |
| │ Layer 7 ─── 多轮对话状态缓存 │ |
| │ 缓存Agent中间状态 + 检索上下文 + 部分答案 │ |
| │ 追问时跳过路由+检索+图谱查询 │ |
| │ 节省: 追问响应 ~60% 延迟降低 │ |
| │ │ |
| └──────────────────────────────────────────────────────────────────────────────────┘ |
| |
| 请求完整路径: |
| User Query |
| → [L1 语义缓存] 命中? → 直接返回 (~5ms) |
| → [L2 检索缓存] 命中? → 跳过检索, 直接生成 |
| → [L7 对话缓存] 追问? → 复用上下文 |
| → Retriever (向量+图谱+RAPTOR) |
| → Prompt组装 (static prefix + retrieved chunks + query) |
| → [L3 Provider缓存] 系统提示+文档chunk已缓存 → 90%折扣 |
| → [L4 vLLM APC] 共享前缀KV命中 → 跳过prefill |
| → [L5 CacheBlend] 非前缀chunk KV复用 → 部分重算 |
| → [L6 SnapKV] 长上下文KV压缩 → 加速decode |
| → Response → 写入 L1 + L2 |
| ``` |
|
|
| --- |
|
|
| ## Layer 1: 语义缓存 (GPTCache) |
|
|
| ### 原理 |
|
|
| 传统 Redis 缓存只能精确匹配 key。但学术问答中，同一个问题有多种表达方式： |
| - "SnapKV 是什么?" ≈ "解释一下 SnapKV 的原理" ≈ "What does SnapKV do?" |
|
|
| **语义缓存**将查询编码为向量，通过**相似度搜索**查找语义等价的历史查询，命中则直接返回缓存答案。 |
|
|
| ``` |
| 查询 → Embedding → 向量相似度搜索 → 相似度 > 阈值? |
| ├── 是: 返回缓存答案 (~5ms) |
| └── 否: 调用LLM → 存入缓存 |
| ``` |
|
|
| ### 实现 |
|
|
| ```python |
| # ===== 方案A: GPTCache (推荐, 7k⭐) ===== |
| # pip install gptcache |
| |
| from gptcache import cache |
| from gptcache.adapter import openai |
| from gptcache.embedding import Onnx |
| from gptcache.manager import CacheBase, VectorBase, get_data_manager |
| from gptcache.similarity_evaluation.distance import SearchDistanceEvaluation |
| from gptcache.processor.pre import get_prompt |
| |
| # 初始化: FAISS向量索引 + SQLite存储 (开发) |
| onnx = Onnx() |
| data_manager = get_data_manager( |
| CacheBase("sqlite"), |
| VectorBase("faiss", dimension=onnx.dimension) |
| ) |
| |
| cache.init( |
| pre_embedding_func=get_prompt, # 只用user query做缓存key (排除检索上下文) |
| embedding_func=onnx.to_embeddings, |
| data_manager=data_manager, |
| similarity_evaluation=SearchDistanceEvaluation(), |
| ) |
| |
| # 使用: 直接替换 openai 调用 |
| response = openai.ChatCompletion.create( |
| model="gpt-4o-mini", |
| messages=[ |
| {"role": "system", "content": "You are ScholarMind..."}, |
| {"role": "user", "content": "What is attention mechanism?"} |
| ] |
| ) |
| # 第二次语义相似查询 → 缓存命中, ~5ms返回 |
| ``` |
|
|
| ```python |
| # ===== 方案A (生产版): Milvus/Redis后端 ===== |
| from gptcache.embedding import OpenAI as OpenAIEmbedding |
| from gptcache.manager import CacheBase, VectorBase, get_data_manager |
| |
| # 使用 Qdrant 作为向量后端 (复用已有基础设施) |
| data_manager = get_data_manager( |
| CacheBase("postgresql", sql_url="postgresql://user:pass@localhost/gptcache"), |
| VectorBase("milvus", host="localhost", port=19530, dimension=1536) |
| # 也可用 VectorBase("qdrant", url="http://localhost:6333", collection_name="gptcache") |
| ) |
| |
| # 使用 OpenAI Embedding (与检索管道同模型, 一致性最高) |
| openai_emb = OpenAIEmbedding() |
| cache.init( |
| pre_embedding_func=get_prompt, |
| embedding_func=openai_emb.to_embeddings, |
| data_manager=data_manager, |
| similarity_evaluation=SearchDistanceEvaluation(), |
| ) |
| ``` |
|
|
| ```python |
| # ===== 方案B: LangChain SemanticCache (更简洁) ===== |
| from langchain_community.cache import RedisSemanticCache |
| from langchain_openai import OpenAIEmbeddings |
| import langchain |
| |
| langchain.llm_cache = RedisSemanticCache( |
| redis_url="redis://localhost:6379", |
| embedding=OpenAIEmbeddings(), |
| score_threshold=0.85, # 学术领域建议较严格 |
| ) |
| # 所有 LangChain LLM 调用自动走语义缓存 |
| ``` |
|
|
| ### 关键参数调优 |
|
|
| | 参数 | 推荐值 | 说明 | |
| |------|--------|------| |
| | 相似度阈值 | **0.85** (学术) | 太低→错误答案; 太高→命中率低; 通用场景可用0.75 | |
| | 嵌入模型 | text-embedding-3-small | 与检索管道一致, 避免语义偏差 | |
| | TTL | **24h** | 学术知识相对稳定 | |
| | 淘汰策略 | **LRU** | 最近最少使用 | |
| | 缓存key | **仅user query** | 排除检索context, 否则同一问题不同检索结果无法命中 | |
|
|
| ### 效果预估 |
|
|
| | 场景 | 命中率 | 延迟节省 | |
| |------|--------|---------| |
| | 同一用户追问变体 | ~70% | ~300× (5ms vs 1.5s) | |
| | 多用户热门问题 | ~30-40% | ~300× | |
| | 全新问题 | 0% | 无节省 (还多~10ms嵌入开销) | |
| | **加权平均** | **~35%** | **总QPS提升~50%** | |
|
|
| --- |
|
|
| ## Layer 2: 语义检索结果缓存 |
|
|
| ### 原理 |
|
|
| 混合检索 (向量+图谱+RAPTOR+重排) 耗时约 300ms。如果两个查询语义相似，它们的检索结果往往也相似。 |
|
|
| ```python |
| class SemanticRetrievalCache: |
| """语义级检索结果缓存 — 相似query复用检索结果""" |
| |
| def __init__(self, qdrant_client, collection="retrieval_cache", threshold=0.90): |
| self.client = qdrant_client |
| self.collection = collection |
| self.threshold = threshold |
| self.embed_model = load_embedding_model() |
| |
| # 创建缓存collection |
| self.client.create_collection( |
| collection_name=collection, |
| vectors_config=models.VectorParams(size=1536, distance=models.Distance.COSINE), |
| ) |
| |
| async def get_or_fetch(self, query: str, retriever) -> list: |
| """查缓存, 没有则检索并缓存""" |
| query_vec = self.embed_model.encode(query) |
| |
| # 1. 在缓存中搜索语义相似的历史查询 |
| hits = self.client.search( |
| collection_name=self.collection, |
| query_vector=query_vec, |
| limit=1, |
| score_threshold=self.threshold, |
| ) |
| |
| if hits and hits[0].score >= self.threshold: |
| # 缓存命中 — 直接返回历史检索结果 |
| cached = hits[0].payload["results"] |
| return cached |
| |
| # 2. 缓存未命中 — 执行完整检索 |
| results = await retriever.retrieve(query, mode="hybrid") |
| |
| # 3. 存入缓存 |
| self.client.upsert( |
| collection_name=self.collection, |
| points=[models.PointStruct( |
| id=hash(query) % (2**63), |
| vector=query_vec, |
| payload={ |
| "query": query, |
| "results": results, |
| "timestamp": time.time(), |
| } |
| )] |
| ) |
| |
| return results |
| ``` |
|
|
| ### 缓存失效 |
|
|
| ```python |
| async def invalidate_on_new_papers(self, paper_ids: list): |
| """新论文导入时, 清除可能受影响的缓存""" |
| # 策略1: 全量清除 (简单但激进) |
| self.client.delete_collection(self.collection) |
| |
| # 策略2: 精准失效 (复杂但精确) |
| # 检索包含这些paper_id的缓存条目并删除 |
| for paper_id in paper_ids: |
| self.client.delete( |
| collection_name=self.collection, |
| points_selector=models.FilterSelector( |
| filter=models.Filter( |
| must=[models.FieldCondition( |
| key="results[].metadata.paper_id", |
| match=models.MatchValue(value=paper_id), |
| )] |
| ) |
| ) |
| ) |
| ``` |
|
|
| --- |
|
|
| ## Layer 3: API Provider 提示缓存 |
|
|
| ### 核心原理 |
|
|
| ``` |
| Prompt 结构: |
| ┌─────────────────────────────────────────┐ |
| │ System Prompt (固定, ~500 tokens) │ ← 这部分每次都一样 |
| │ "You are ScholarMind, a research..." │ Provider 自动缓存 |
| ├─────────────────────────────────────────┤ |
| │ 检索到的论文片段 (半固定, ~2000 tokens) │ ← 热门论文反复被检索到 |
| │ Paper chunk A: "Attention is..." │ 高概率命中缓存 |
| │ Paper chunk B: "We propose BERT..." │ |
| ├─────────────────────────────────────────┤ |
| │ 用户问题 (动态, ~50 tokens) │ ← 每次不同 |
| │ "Compare BERT and GPT-2 on GLUE" │ 不被缓存 |
| └─────────────────────────────────────────┘ |
| |
| 关键: 固定内容放前面, 动态内容放最后! |
| ``` |
|
|
| ### OpenAI — 全自动 (零配置) |
|
|
| ```python |
| from openai import OpenAI |
| client = OpenAI() |
| |
| # 技巧: 构造≥1024 tokens的静态前缀, OpenAI自动缓存 |
| SYSTEM_PROMPT = """You are ScholarMind, an expert academic research assistant. |
| You have access to a knowledge base of 1000+ academic papers spanning NLP, |
| computer vision, and machine learning. When answering questions: |
| 1. Always cite specific papers with [Author, Year] format |
| 2. Include quantitative results where available |
| 3. Compare methods objectively |
| 4. Acknowledge limitations and open questions |
| ... (填充到≥1024 tokens) |
| """ |
| |
| response = client.chat.completions.create( |
| model="gpt-4o-mini", |
| messages=[ |
| {"role": "system", "content": SYSTEM_PROMPT}, # ~1200 tokens, 自动缓存 |
| {"role": "user", "content": f""" |
| Based on these papers: |
| {retrieved_chunks} |
| |
| Question: {user_question} |
| """} |
| ] |
| ) |
| |
| # 检查缓存效果 |
| usage = response.usage |
| cached = usage.prompt_tokens_details.cached_tokens |
| total = usage.prompt_tokens |
| print(f"Cache hit: {cached}/{total} tokens ({cached/total:.0%})") |
| # 首次: 0%, 后续相同前缀: ~70-90% |
| ``` |
|
|
| **成本节省**: |
| | 场景 | 正常价格 | 缓存命中价格 | 节省 | |
| |------|---------|-------------|------| |
| | GPT-4o input | $2.50/M | $1.25/M | 50% | |
| | GPT-4o-mini input | $0.15/M | $0.075/M | 50% | |
| | GPT-4o 长前缀 (>128K) | — | 高达 90% off | 90% | |
|
|
| ### Anthropic — 显式标记 (精细控制) |
|
|
| ```python |
| import anthropic |
| client = anthropic.Anthropic() |
| |
| response = client.messages.create( |
| model="claude-sonnet-4-20250514", |
| max_tokens=2048, |
| system=[ |
| { |
| "type": "text", |
| "text": SYSTEM_PROMPT, # 系统指令 |
| "cache_control": {"type": "ephemeral"} # ← 缓存断点1 |
| } |
| ], |
| messages=[{ |
| "role": "user", |
| "content": [ |
| { |
| "type": "text", |
| "text": retrieved_chunks, # 检索到的论文片段 |
| "cache_control": {"type": "ephemeral"} # ← 缓存断点2 |
| }, |
| { |
| "type": "text", |
| "text": user_question # 动态部分, 不缓存 |
| } |
| ] |
| }] |
| ) |
| |
| # 查看缓存统计 |
| print(f"Cache write: {response.usage.cache_creation_input_tokens} tokens") |
| print(f"Cache read: {response.usage.cache_read_input_tokens} tokens") |
| # 首次: 全部write; 5分钟内再次调用相同前缀: 全部read → 90%折扣 |
| ``` |
|
|
| **Anthropic 缓存定价**: |
| | 类型 | Sonnet 4 | Haiku 3.5 | |
| |------|----------|-----------| |
| | 正常输入 | $3/M | $0.80/M | |
| | 缓存写入 (首次) | $3.75/M (+25%) | $1.00/M (+25%) | |
| | 缓存读取 (命中) | $0.30/M (**-90%**) | $0.08/M (**-90%**) | |
| | TTL | 5分钟 (每次命中刷新) | 5分钟 | |
|
|
| ### DeepSeek — 自动磁盘缓存 |
|
|
| ```python |
| from openai import OpenAI |
| client = OpenAI(api_key="sk-xxx", base_url="https://api.deepseek.com") |
| |
| response = client.chat.completions.create( |
| model="deepseek-chat", |
| messages=[ |
| {"role": "system", "content": LONG_SYSTEM_PROMPT}, |
| {"role": "user", "content": user_question} |
| ] |
| ) |
| |
| # DeepSeek 自动缓存到磁盘, 无需配置 |
| usage = response.usage |
| print(f"Cache hit: {usage.prompt_cache_hit_tokens} tokens @ 10% price") |
| print(f"Cache miss: {usage.prompt_cache_miss_tokens} tokens @ 100% price") |
| # 磁盘缓存持续时间 > Anthropic的5分钟, 更适合低流量场景 |
| ``` |
|
|
| --- |
|
|
| ## Layer 4: vLLM 前缀缓存 (APC) |
|
|
| ### 原理 |
|
|
| vLLM 的 Automatic Prefix Caching 将 KV Cache 按 block (16-32 tokens) 分割，每个 block 通过 hash(tokens + position) 索引。新请求到来时，从头匹配已缓存的 blocks，跳过已有 blocks 的 prefill 计算。 |
|
|
| ``` |
| 请求1: [System 500 tokens] + [Chunk A 200 tokens] + [Query 1] |
| ↓ 全部计算 KV, 缓存所有blocks |
| |
| 请求2: [System 500 tokens] + [Chunk A 200 tokens] + [Query 2] |
| ↓ 前700 tokens 命中缓存! 只需计算 Query 2 的KV |
| → prefill 从 ~700 tokens 降到 ~50 tokens → 14× TTFT降低 |
| ``` |
|
|
| ### 配置 |
|
|
| ```bash |
| # vLLM serving — APC默认开启 (v1+) |
| vllm serve meta-llama/Llama-3.1-8B-Instruct \ |
| --enable-prefix-caching \ |
| --gpu-memory-utilization 0.95 \ |
| --max-model-len 32768 |
| |
| # 查看缓存统计 |
| curl http://localhost:8000/metrics | grep prefix_cache |
| # vllm_prefix_cache_hit_rate: 0.73 |
| # vllm_prefix_cache_queries_total: 10000 |
| ``` |
|
|
| ```python |
| # Python API |
| from vllm import LLM, SamplingParams |
| |
| llm = LLM( |
| model="meta-llama/Llama-3.1-8B-Instruct", |
| enable_prefix_caching=True, |
| gpu_memory_utilization=0.95, |
| ) |
| |
| # 关键: 所有请求共享相同的长前缀 |
| SHARED_PREFIX = f"""<|begin_of_text|><|start_header_id|>system<|end_header_id|> |
| |
| You are ScholarMind, an expert academic research assistant with access to |
| 1000+ research papers. Answer precisely with citations. |
| |
| <|eot_id|><|start_header_id|>user<|end_header_id|> |
| |
| Based on the following paper excerpts: |
| {FREQUENTLY_RETRIEVED_CHUNKS} |
| """ |
| |
| # 每次请求只改变 query 部分 — 前缀全部缓存命中 |
| responses = llm.generate([ |
| SHARED_PREFIX + "What is the main contribution of BERT?<|eot_id|>", |
| SHARED_PREFIX + "Compare BERT and GPT-2 on GLUE<|eot_id|>", |
| ]) |
| ``` |
|
|
| ### ⚡ 优化技巧: 文档chunk排序一致化 |
|
|
| ```python |
| def order_chunks_for_cache(chunks: list, query: str) -> list: |
| """ |
| 将检索到的chunk按确定性顺序排列, 最大化前缀缓存命中率 |
| |
| 策略: 按chunk_id排序 (而非按相关性排序) |
| → 不同查询检索到相同chunk集合时, 前缀完全一致 → 缓存命中 |
| """ |
| # 按paper_id + page_idx 确定性排序 |
| return sorted(chunks, key=lambda c: (c["metadata"]["paper_id"], c["metadata"]["page"])) |
| |
| # 注意: 这会牺牲一点"最相关chunk排前面"的优势 |
| # 折中方案: 前N个按相关性, 后面按ID排序 |
| ``` |
|
|
| --- |
|
|
| ## Layer 5: RAG KV Cache 复用 (LMCache / CacheBlend) |
|
|
| ### 问题 |
|
|
| 标准前缀缓存要求 chunks 以**完全相同的顺序**出现。但 RAG 检索结果的顺序经常变化： |
| - Query 1 → [Chunk A, B, C] |
| - Query 2 → [Chunk B, A, D] ← Chunk A, B 都出现了, 但前缀不同 |
|
|
| CacheBlend 解决这个问题: **预计算每个chunk的独立KV状态**, 组合时只选择性重算 5-15% 的 tokens。 |
|
|
| ### 实现 |
|
|
| ```bash |
| # 安装 LMCache (CacheBlend 的生产实现) |
| pip install lmcache lmcache-vllm |
| ``` |
|
|
| ```python |
| # LMCache 集成 vLLM 的示例 |
| import lmcache_vllm |
| from vllm import LLM, SamplingParams |
| |
| # LMCache 在 vLLM 之上透明地管理 KV 缓存 |
| # 支持 GPU VRAM → Host RAM → SSD 三级缓存层次 |
| llm = LLM( |
| model="meta-llama/Llama-3.1-8B-Instruct", |
| # LMCache 通过环境变量或配置文件集成 |
| ) |
| |
| # 预热: 将所有高频文档chunk的KV预计算并缓存 |
| for chunk in top_1000_chunks: |
| llm.encode(chunk["text"]) # 预计算KV → 缓存到GPU+RAM |
| |
| # 推理: 组合时自动复用已缓存的chunk KV, 只重算5-15% |
| response = llm.generate( |
| system_prompt + chunk_a + chunk_b + user_query |
| ) |
| # chunk_a 和 chunk_b 的 KV 从缓存加载, 仅选择性重算跨chunk注意力 |
| ``` |
|
|
| ### 效果 |
|
|
| | 指标 | 无缓存 | vLLM APC | CacheBlend | |
| |------|--------|----------|------------| |
| | TTFT (首token) | 基准 | 2-8× 降低 (仅限相同前缀) | **2.2-3.3× 降低** (任意chunk组合) | |
| | 吞吐 | 基准 | 1.5× 提升 | **2.8-5× 提升** | |
| | 适用场景 | — | 固定前缀 | **任意RAG检索结果** | |
|
|
| > **论文**: CacheBlend (arxiv:2405.16444), LMCache GitHub: `github.com/LMCache/LMCache` |
|
|
| --- |
|
|
| ## Layer 6: KV Cache 压缩 (长文档场景) |
|
|
| ### SnapKV — 关注度投票压缩 |
|
|
| 当输入很长（多篇论文全文）时，保留完整 KV Cache 会耗尽显存。SnapKV 只保留每个注意力头**真正关注的 20% 位置**。 |
|
|
| ``` |
| 完整KV: [tok1, tok2, tok3, ..., tok10000] → 160GB VRAM (70B模型) |
| SnapKV: [tok3, tok45, tok202, ..., tok9998] → 32GB VRAM (仅保留20%) |
| ~5× 显存节省, ~3.6× 解码加速 |
| ``` |
|
|
| ```python |
| # pip install snapkv |
| # 核心参数 |
| config = { |
| "compression_ratio": 0.2, # 保留20%的KV位置 |
| "observation_window": 32, # 用最后32个token投票决定保留哪些位置 |
| "kernel_size": 5, # 投票时的池化窗口 |
| } |
| |
| # SnapKV 集成方式: 修改 attention 层 |
| # 适用: 处理多篇完整论文时 (>16K tokens) |
| # 结果: 单A100可处理380K token上下文 (原本~32K) |
| ``` |
|
|
| ### Quest — 查询感知的稀疏注意力 |
|
|
| ``` |
| 每个KV页面维护元数据 (K向量的min/max值) |
| → 新query来了, 用Q和元数据估算每页的重要性 |
| → 只加载Top-K重要的页面 |
| → 7× self-attention加速 |
| ``` |
|
|
| > **论文**: SnapKV (arxiv:2404.14469, GitHub: `fasterdecoding/snapkv`) |
| > **论文**: Quest (arxiv:2406.10774, GitHub: `mit-han-lab/quest`) |
|
|
| --- |
|
|
| ## Layer 7: 多轮对话状态缓存 |
|
|
| ### 原理 |
|
|
| 学术问答常见多轮追问: |
| 1. "BERT在GLUE上表现如何?" → 检索+推理+生成 |
| 2. "和GPT-2相比呢?" → **不需要重新检索BERT的信息!** |
|
|
| ```python |
| from langgraph.checkpoint.memory import MemorySaver |
| |
| class ConversationCache: |
| """多轮对话缓存 — 避免追问时重复检索""" |
| |
| def __init__(self): |
| self.checkpointer = MemorySaver() # LangGraph 内置状态持久化 |
| self.context_cache = {} # session_id → {retrieved_docs, entities, graph_context} |
| |
| async def handle_query(self, session_id: str, query: str): |
| # 检查是否是追问 |
| if session_id in self.context_cache: |
| prev = self.context_cache[session_id] |
| |
| # 追问检测: 如果query引用了上一轮的实体, 复用上下文 |
| if self._is_followup(query, prev["entities"]): |
| # 直接复用之前的检索结果 + 图谱上下文 |
| return await self._generate_with_cached_context( |
| query=query, |
| retrieved_docs=prev["retrieved_docs"], |
| graph_context=prev["graph_context"], |
| history=prev["history"], |
| ) |
| |
| # 非追问: 完整检索流程 |
| result = await full_retrieval_and_generation(query) |
| |
| # 缓存上下文供追问使用 |
| self.context_cache[session_id] = { |
| "retrieved_docs": result["retrieved_docs"], |
| "graph_context": result["graph_context"], |
| "entities": result["entities"], |
| "history": result["messages"], |
| "timestamp": time.time(), |
| } |
| |
| return result |
| |
| def _is_followup(self, query: str, prev_entities: list) -> bool: |
| """检测是否是追问: 包含代词、比较词、或引用上一轮实体""" |
| followup_signals = ["compared to", "和...比", "那", "它", "this method", "上面提到的"] |
| has_pronoun = any(s in query.lower() for s in followup_signals) |
| references_entity = any(e["name"].lower() in query.lower() for e in prev_entities) |
| return has_pronoun or references_entity |
| ``` |
|
|
| ### LangGraph 内置检查点 |
|
|
| ```python |
| from langgraph.graph import StateGraph |
| from langgraph.checkpoint.postgres import PostgresSaver |
| |
| # 使用 PostgreSQL 持久化 Agent 状态 |
| checkpointer = PostgresSaver.from_conn_string("postgresql://...") |
| |
| # 编译时传入 checkpointer |
| agent = build_agent_graph().compile(checkpointer=checkpointer) |
| |
| # 每次调用使用 thread_id 标识会话 |
| config = {"configurable": {"thread_id": session_id}} |
| |
| # 第一次: 完整执行 |
| result1 = await agent.ainvoke({"query": "BERT在GLUE上表现如何?"}, config) |
| |
| # 追问: LangGraph 自动恢复之前的状态 |
| result2 = await agent.ainvoke({"query": "和GPT-2相比呢?"}, config) |
| # → Agent 已有上一轮的 retrieved_docs, 只需补充检索GPT-2信息 |
| ``` |
|
|
| --- |
|
|
| ## 集成架构: 完整缓存流水线 |
|
|
| ```python |
| class CachedQAEngine: |
| """集成7层缓存的问答引擎""" |
| |
| def __init__(self): |
| # L1: 语义缓存 |
| self.semantic_cache = GPTCacheWrapper(threshold=0.85, ttl_hours=24) |
| |
| # L2: 检索结果缓存 |
| self.retrieval_cache = SemanticRetrievalCache(qdrant, threshold=0.90) |
| |
| # L7: 对话状态缓存 |
| self.conversation_cache = ConversationCache() |
| |
| # L3-L6: 由 LiteLLM / vLLM / Provider 自动处理 |
| |
| async def query(self, session_id: str, query: str) -> dict: |
| |
| # === L1: 语义缓存检查 === |
| cached_answer = await self.semantic_cache.get(query) |
| if cached_answer: |
| return {"answer": cached_answer, "cache": "L1_semantic", "latency_ms": 5} |
| |
| # === L7: 追问检查 === |
| if self.conversation_cache.is_followup(session_id, query): |
| result = await self.conversation_cache.handle_followup(session_id, query) |
| if result: |
| return {**result, "cache": "L7_followup"} |
| |
| # === L2: 检索缓存检查 === |
| retrieved = await self.retrieval_cache.get_or_fetch(query, self.retriever) |
| |
| # === 组装 Prompt (L3/L4/L5友好的结构) === |
| prompt = self._build_prompt( |
| system=STATIC_SYSTEM_PROMPT, # → L3 Provider缓存 |
| chunks=order_chunks_for_cache(retrieved), # → L4 vLLM APC缓存 |
| query=query # → 动态部分 |
| ) |
| |
| # === LLM调用 (L3/L4/L5/L6 自动生效) === |
| answer = await self.llm.complete(prompt, task="generation") |
| |
| # === 写入缓存 === |
| await self.semantic_cache.set(query, answer) |
| self.conversation_cache.update(session_id, query, retrieved, answer) |
| |
| return {"answer": answer, "cache": "miss", "retrieved": retrieved} |
| |
| def _build_prompt(self, system: str, chunks: list, query: str) -> list: |
| """ |
| Prompt结构优化: |
| 1. 固定系统提示放最前 (Provider缓存 + vLLM前缀缓存) |
| 2. 检索chunks按确定性排序 (最大化vLLM前缀命中) |
| 3. 用户query放最后 (动态部分) |
| """ |
| return [ |
| {"role": "system", "content": system}, # ≥1024 tokens → OpenAI自动缓存 |
| {"role": "user", "content": |
| "Based on these paper excerpts:\n\n" + |
| "\n---\n".join([c["text"] for c in chunks]) + |
| f"\n\nQuestion: {query}" |
| } |
| ] |
| ``` |
|
|
| --- |
|
|
| ## 性能收益汇总 |
|
|
| ``` |
| ┌───────────────────────────────────────────────────────────────────┐ |
| │ 7层缓存预估收益 (1000篇论文, 日均500查询) │ |
| ├──────────┬──────────┬──────────────┬──────────────┬──────────────┤ |
| │ 缓存层 │ 命中率 │ 延迟节省 │ 成本节省 │ 实现复杂度 │ |
| ├──────────┼──────────┼──────────────┼──────────────┼──────────────┤ |
| │ L1 语义 │ ~35% │ 300×(5ms) │ ~100%(命中时) │ ⭐⭐ 中 │ |
| │ L2 检索 │ ~25% │ ~60×(5ms) │ 检索计算 │ ⭐⭐ 中 │ |
| │ L3 API │ ~70% │ 最高80% │ 50-90% │ ⭐ 低 │ |
| │ L4 APC │ ~60% │ 2-8× TTFT │ GPU算力 │ ⭐ 低 │ |
| │ L5 Cache │ ~40% │ 2-3× TTFT │ GPU算力 │ ⭐⭐⭐ 高 │ |
| │ Blend │ │ │ │ │ |
| │ L6 SnapKV│ N/A │ 3.6×解码 │ 5×显存 │ ⭐⭐ 中 │ |
| │ L7 对话 │ ~20% │ ~60%(追问) │ 检索+推理 │ ⭐⭐ 中 │ |
| ├──────────┼──────────┼──────────────┼──────────────┼──────────────┤ |
| │ 综合 │ — │ P50: 1.5s │ API成本 │ │ |
| │ 效果 │ │ → ~400ms │ 降低60%+ │ │ |
| │ │ │ P99: 4s │ │ │ |
| │ │ │ → ~1.5s │ │ │ |
| └──────────┴──────────┴──────────────┴──────────────┴──────────────┘ |
| ``` |
|
|
| --- |
|
|
| ## 实施优先级 |
|
|
| | 优先级 | 缓存层 | 理由 | 工作量 | |
| |--------|--------|------|--------| |
| | **P0 (立即)** | L3 Provider缓存 | 零代码改动, 只需调整prompt结构 | 2小时 | |
| | **P0 (立即)** | L4 vLLM APC | 默认已开启, 确认配置即可 | 1小时 | |
| | **P1 (本周)** | L1 语义缓存 | GPTCache几十行代码, 收益最高 | 1天 | |
| | **P1 (本周)** | L7 对话缓存 | LangGraph checkpointer, 追问体验质变 | 1天 | |
| | **P2 (下周)** | L2 检索缓存 | 复用Qdrant基础设施 | 2天 | |
| | **P3 (后续)** | L6 SnapKV | 仅长文档场景需要 | 3天 | |
| | **P3 (后续)** | L5 CacheBlend | 需要LMCache集成, 侵入性较大 | 1周 | |
|
|
| --- |
|
|
| ## 相关论文 |
|
|
| | 论文 | ArXiv ID | 核心贡献 | |
| |------|---------|---------| |
| | GPTCache | ACL 2023 NLPOSS | 语义缓存框架 | |
| | GPT Semantic Cache | 2411.05276 | 语义缓存基准评测 | |
| | PagedAttention (vLLM) | 2309.06180 | 分页KV Cache管理 | |
| | RAGCache | 2404.12457 | RAG专用多级KV缓存 | |
| | CacheBlend | 2405.16444 | 非前缀KV复用 | |
| | SnapKV | 2404.14469 | 注意力投票KV压缩 | |
| | Quest | 2406.10774 | 查询感知稀疏注意力 | |
| | StreamingLLM | 2309.17453 | 注意力sink+滚动窗口 | |
| | Prompt Cache | 2311.04934 | 模块化KV状态复用 | |
| | KV Cache Survey | 2412.19442 | KV Cache管理全面综述 | |
|
|
| --- |
|
|
| ## 开源项目 |
|
|
| | 项目 | GitHub | Stars | 用途 | |
| |------|--------|-------|------| |
| | GPTCache | zilliztech/GPTCache | 7k+ | 语义缓存 | |
| | LMCache | LMCache/LMCache | — | CacheBlend生产实现 | |
| | SnapKV | fasterdecoding/snapkv | 311 | KV压缩 | |
| | Quest | mit-han-lab/quest | 382 | 稀疏注意力 | |
| | vLLM | vllm-project/vllm | 45k+ | APC前缀缓存 | |
| | KV Cache Survey | TreeAI-Lab/Awesome-KV-Cache-Management | 314 | 综述索引 | |
|
|
