1. 为什么一个AI助手需要先解决记得快的问题先交代一下背景这是个人AI助手系列的第7篇实践记录前面几个阶段已经把这台助手从能调API的大模型客户端逐步做到了有记忆、有工具调用能力的Agent。阶段1打通了模型接口阶段2给它加了搜索、网页抓取、日程提醒这类工具能力整体框架已经能跑通。但用到第3周的时候问题开始暴露了——每天高频使用的真实场景里这个助手有两大硬伤太慢、太贵。慢体现在哪里呢一次对话的耗时分布大概是网络往返几百毫秒模型首token响应一到三秒回答长问题加上流式输出又是几秒如果再触发工具调用一次完整回答动辄六七秒起步。贵就更直接了模型API按token计费同样是今天下午的会议改到几点帮我查一下明天的天气这类高度重复的问题每天能问上好几遍但每一遍都在按全价付费。顺着这两个痛点往深了想这其实不是一个模型选型或者提示词优化能解决的问题。模型再快也有物理时延提示词再精炼也改变不了重复请求的浪费。合适的做法是引入一层缓存系统让高频、高重复的请求在到达模型之前就命中离线的答案。这篇实践记录就围绕阶段3的缓存系统搭建展开包括整体架构设计、语义缓存的具体实现、实测效果以及我自己踩过的几个比较典型的坑。这个阶段的目标定义得很明确在不改变回答质量的前提下通过缓存把重复请求的响应时间压缩到五分之一以内同时把模型API的调用量降下来。文章适合正在做个人AI助手、本地知识库问答、或者任意一个带大模型调用的上层应用的开发者参考尤其是那种功能已经通了但性能和成本还没过关的阶段。2. 先明确缓存系统的边界哪些请求值得被缓存缓存不是万能药不是所有请求都适合塞进缓存系统里。设计阶段首先得划定边界确定这个缓存要吃什么数据、不吃什么数据否则后面做出来的系统要么命中率感人要么回答质量大幅下降。2.1 三种可缓存的数据类型我给自己的助手梳理了一遍对话场景把值得缓存的请求分成三类。第一类是事实查询类。比如帮我查一下XX接口的文档Python 3.12的typing有什么变更某软件的最新版本号是多少。这类问题的特点是答案客观、稳定、变化慢问10次正确回答都是同一个。传统做法是直接把整个问答对缓存住命中直接重放。第二类是工具结果类。比如天气查询的结果、某个网页抓取到的正文内容、论文摘要、RSS聚合结果。这类问题本身问法可能千变万化但背后的工具调用结果是稳定可复用的。如果不做缓存每问一次明天天气如何就真的再去调一次天气API不仅慢某些免费API还有每日请求配额限制。把工具返回结果单独缓存就是给工具调用本身加了一层数据源缓存。第三类是嵌入向量检索类。这是本地知识库问答场景特有的一类用户先提问系统把问题向量化到向量数据库里做相似度检索把命中片段塞进上下文再交给模型生成答案。这里的检索结果同样具备高复用性——同一个问题向量化后大概率命中的是同一批文档片段。2.2 不值得缓存的反面清单有几类请求我明确排除了。首先是创作生成类让助手写一段宣传语、改一篇文案、编一个故事这类任务没有唯一标准答案如果硬缓存同一个答案用户期望的是每次微调后的多样化输出缓存显然会帮倒忙。其次是个人状态类。问我的日程安排我的待办事项这种依赖用户私有上下文的问题同一句话不同时间问答案完全不同。缓存这种请求不仅没有用还可能因为缓存过期策略设计不严把过期数据当作最新数据返回造成严重的信息错误。再就是工具动作类。比如帮我订阅一下某网站的更新把某篇文章存到收藏夹这类请求做的是副作用的写入操作绝对不能走缓存。任何会改变外部系统状态的请求都应该默认绕过缓存系统。划定清楚边界之后实现的策略逻辑也就清晰了根据用户的提问内容做一个初步的请求分类事实查询类和工具结果类走缓存创作类和个人类直接放行到模型。分类本身不需要多聪明简单的关键词规则加上意图分类模型即可。3. 缓存架构的设计多层缓存与三种核心策略边界定好了接下来是架构层面的事情。我最后确定的方案是两层缓存内存缓存做热数据层向量语义缓存做冷数据层。为什么是两层而不是一个统一的缓存池这里面其实有很现实的取舍逻辑。3.1 内存缓存层L1第一层是进程内内存缓存本质就是一个带过期时间的字典。它的优势是访问速度极快纳秒级取数据完全不涉及跨进程通信。用Redis这类独立的缓存服务其实也很常见但对于个人助手这样的单机应用进程内存的延迟更低、部署更简单、不需要额外维护一个服务。内存层存的到底是什么不可能是所有的问答对内存空间有限。它只存那些高频访问的极热数据——比如用户最近半小时内反复查询的同一个问题。我设计了一个只要命中就自动刷新TTL的机制保证热数据一直被留在内存里。内存层的淘汰策略用最简单的LRU加一个最大条目限制。我的做法是设置最多缓存5000条问答超过之后按最近最少使用原则淘汰。这个数字是个人使用场景下比较合适的值如果读者是服务端团队使用可以根据内存配额和单条缓存平均大小重新估算。3.2 语义缓存层L2第二层是语义缓存这也是这个阶段最核心的工程难点。普通缓存的匹配逻辑是键值精确匹配用户两次提问必须一字不差才能命中。但自然语言不是这样,用户可能今天问明天的天气怎么样明天问明天会不会下雨两个句子字面不同但语义高度相近期望得到的答案几乎一致。语义缓存的实现思路是把用户提问嵌入成向量存入向量索引新请求进来时同样转成向量和已有缓存条目做相似度计算相似度超过设定的阈值就判定为语义命中。这相当于给缓存系统装了一个能看懂语义等价的翻译层。这样设计带来的直接好处是命中率大幅提升。传统精确缓存命中率可能只有20%到30%因为实际对话中很少有人一字不差地问同一个问题但换成语义缓存之后命中率能提升到50%以上用户的重复问题往往只是换了种说法。3.3 TTL策略不同数据要有不同寿命缓存能不能正常工作很大程度上取决于过期时间策略设得是否合理。我把TTL拆成了三个档位数据类型过期时间理由常识事实类问答7天到30天比如编程语法、工具用法内容变化慢时效类工具结果30分钟到6小时天气、新闻、股市这类信息必须保新鲜向量检索片段1天到7天文档内容相对稳定但保留更新空间这里有一个比较微妙的问题TTL设置不能一刀切。我踩过的坑就是最开始把所有缓存都设成24小时过期结果天气预报被缓存了整整一天用户早上问天气拿到的是昨天的答案这种数据性错误比慢几秒严重得多。后来改成按数据类型动态决定TTL才解决了这个问题。3.4 缓存键如何设计不管是精确缓存还是语义缓存缓存的键都要可控可追踪。我的做法是精确缓存用规范化后的用户提问文本做键做一步预处理——去掉多余空格、统一中英文标点、小写化语义缓存则用嵌入向量做索引同时把原文保留在元数据里便于调试时看到底是哪条语义命中了。规范化这一步在中文场景下特别重要。同一句话在手机上自动输入法可能带全角括号电脑上可能是半角不做规范化的话字面完全一致的句子都可能因为一个字符的差异而错过缓存命中。4. 核心代码实现一个能跑的语义缓存系统架构落定之后下一步是把它翻译成代码。这里给出我自己实现的最小可用版本整体偏Python风格便于读者直接改造成自己项目的一部分。需要注意这里展示的是核心骨架生产级细节比如并发锁、持久化、监控指标需要根据自己的场景补全。4.1 本体一个TTL缓存装饰器先看最简单的一层基于精确匹配的内存缓存。我把缓存逻辑封装成一个装饰器使用方只需要标记这个函数可以被缓存而不需要理解内部细节。import time import functools import threading from collections import OrderedDict class TTLCache: def __init__(self, capacity: int 5000, default_ttl: int 3600): self.capacity capacity self.default_ttl default_ttl self._store OrderedDict() self._lock threading.Lock() def get(self, key): with self._lock: if key not in self._store: return None value, expire_at self._store[key] if time.time() expire_at: del self._store[key] return None # 把命中的条目移到末尾维持LRU顺序 self._store.move_to_end(key) return value def set(self, key, value, ttlNone): ttl ttl or self.default_ttl with self._lock: if len(self._store) self.capacity: self._store.popitem(lastFalse) self._store[key] (value, time.time() ttl)装饰器的实现思路是先算缓存键然后查缓存命中直接返回没有命中就执行原函数手动把结果回填到缓存。def cached(ttl_cache: TTLCache, key_prefix: str , ttl: int None): def decorator(func): functools.wraps(func) def wrapper(*args, **kwargs): raw_key f{key_prefix}:{args}:{kwargs} cache_key normalize_key(raw_key) cached_value ttl_cache.get(cache_key) if cached_value is not None: return cached_value result func(*args, **kwargs) ttl_cache.set(cache_key, result, ttlttl) return result return wrapper return decorator真实项目里缓存的回填需要做异步写处理。如果每次缓存未命中都同步等待模型返回并写缓存那第一次请求的延迟并没有任何改善。实际做法是第一个请求正常执行模型调用后台线程把结果写入缓存同一时间窗口内到达的相同请求可以等待第一个请求的结果而不是各自重复调用模型。这个模式叫单飞singleflight实测下来在高并发下非常有用。4.2 语义缓存的判断逻辑语义缓存的核心函数是这个sentence_similarity 判断。我这里用的是嵌入模型加余弦相似度在两三万条缓存规模下足够用。import numpy as np from sentence_transformers import SentenceTransformer class SemanticCache: def __init__(self, threshold: float 0.92): self.model SentenceTransformer(your-embedding-model) self.threshold threshold self._items [] # 元素结构: {vector, question, answer, timestamp} def query(self, question: str): q_vec self.model.encode(question, normalize_embeddingsTrue) best_score 0.0 best_item None for item in self._items: score float(np.dot(q_vec, item[vector])) if score best_score: best_score score best_item item if best_score self.threshold: return best_item[answer] return None def add(self, question: str, answer: str): q_vec self.model.encode(question, normalize_embeddingsTrue) self._items.append({ vector: q_vec, question: question, answer: answer, timestamp: time.time(), })这个实现有几个性能问题线性扫描意味着缓存条目越多越慢同时向量全放内存也比较吃空间。个人助手场景下几千条缓存完全没问题但如果要做到几百万条就需要改成faiss这样的最近邻索引避免全量线性扫描。扩展方向我这里先提一下后文会具体讲。4.3 触发策略何时走语义缓存何时必须绕过有读者可能会问语义缓存需要额外调嵌入模型这不是一样增加耗时吗确实如果语义缓存引入的嵌入计算时间比直接调大模型还长那就本末倒置了。所以我把语义缓存的触发逻辑做了个分级先走L1内存精确缓存命中即为最优。如果L1未命中再走L2语义缓存此时嵌入模型的计算时间大约在几十毫秒量级相比大模型的一到三秒开销完全可以接受。如果L2最终也未命中这次请求就直接调用大模型并把结果异步写入两级缓存。绕过路径的设计同样重要如果用户显式要求重新回答换一种写法不要说刚才那套话那么这个请求必须强制绕过缓存直接交给大模型重新生成。不然就会出现用户想听一个不一样的版本系统却把旧答案原封不动端上来的尴尬场景。触发这种绕过的方式很简单在请求分类阶段检测到包含再来一次换一个重新说等关键词时在缓存键上强制加一个随机前缀让缓存必然失效。4.4 持久化问题缓存不能只存在进程里因为个人助手很可能每天都重启。每天重启后需要花很长时间重新预热头几轮请求全部缓存未命中用户体验会比较差。所以阶段3还做了一步持久化把内存缓存在每次写入时同步写一份到本地磁盘采用 JSON Lines 格式逐行追加启动时扫描加载。这里有一个经验性的细节别把整个缓存快照一次性写到磁盘。几万条数据按行追加的方式启动加载也就几百毫秒和一次快照序列化几乎没区别但按行追加的容错性好很多——即使上次崩溃导致最后几行损坏加载逻辑也能直接跳过坏行继续加载整个缓存不会因为尾部数据损坏而全部报废。5. 实测效果命中率、响应时延和成本账单系统跑了两周真实使用数据后我把效果指标整理了一下。这部分对评估缓存系统值不值得做非常关键。5.1 缓存命中率的真实分布指标精确缓存命中率语义缓存命中率总缓存命中率高频问答场景28%31%59%工具查询场景35%41%76%知识库检索场景15%43%58%整体26%33%59%从数据可以很清楚地看到精确缓存单独用的效果确实不够理想26%的命中率意味着四分之三的请求仍然要走模型但是加上语义缓存之后总命中率能到59%接近六成的请求不再消耗模型算力。5.2 响应时延的对比我特意统计了不同路径下的端到端响应时延L1内存缓存命中平均60毫秒基本就是函数调用加返回的开销。L2语义缓存命中平均180毫秒多出来的120毫秒主要花在嵌入模型推理和相似度计算上。缓存未命中直接走模型平均3800毫秒其中模型生成占了大头。这个对比非常直观缓存命中之后端到端延迟从接近4秒降到不到200毫秒体验完全是两个级别。日常使用中高频重复问题基本都是秒开这种流畅感对个人助手的使用意愿提升非常明显。5.3 token成本估算成本侧的收益也很好算。假设日均发生200次用户请求没有缓存时全部直接调用模型平均每次消耗2000 token按当前常见的中大型模型的计费标准估算一个月的token成本在高频使用下会比较可观。接入缓存后总命中率约59%等于只有41%的请求真正产生模型费用成本直接降到原来的四成出头。这里还没有计算嵌入模型的成本。语义缓存用的嵌入模型很小一次调用通常只有一两个token的花费量级和主模型的生成成本相比几乎可以忽略。如果是在预算紧张的环境里做这套系统这个成本结构是一种性价比很高的组合。6. 踩坑复盘这五个问题我排查了最久这一阶段最有价值的其实是踩坑过程。五个问题花了不少时间排查但每一个都让系统真正变得能打了而不是停留在demo层面。6.1 把嵌入模型加载放在了每次请求里第一版代码把嵌入模型的初始化写在了查询函数内部。看起来没什么问题语义缓存第一次被访问时才会加载模型但项目跑起来之后发现第一次请求要等待将近5秒。原因很简单嵌入模型首次加载需要把几千万个参数读进CPU和内存做权重初始化这个过程在没有预热的情况下被叠加到用户请求路径上。解决办法是在服务启动阶段主动加载嵌入模型并把加载放到后台线程同时提供一个健康检查接口确认模型就绪后才接收外部流量。如果你的应用不是常驻服务比如是命令行工具至少在初始化时打印明确的日志提示嵌入模型加载中首次查询可能稍慢避免用户误以为程序卡死了。6.2 语义判定的阈值问题0.95太严0.85太松阈值是语义缓存里最需要调参的参数。一开始我把阈值设成0.95结果命中率直线下降因为用户实际对话中的复述性问法相似度通常落在0.88到0.94之间0.95的阈值把这些全部拦死了。后来改到0.85命中率上来了但又出现新问题——明显语义不同的问法也被判断为相似。比较典型的翻车案例用户问帮我写一封邮件给客户和帮我写一封邮件给老板这两句话的向量相似度超过0.85系统判断为语义命中直接返回了写给客户的邮件模板。在正式场景里这就算事故了。最后的方法是把判断逻辑做成两级先用0.92的阈值做低门槛召回命中后不直接返回而是做一次关键实体比对比对待办事项、人物、时间、数值这类关键信息是否一致冲突则拒绝命中。这个思路比单靠一个阈值靠谱得多。6.3 缓存穿透恶意与无意的边缘请求有一类请求永远无法命中缓存比如带有随机数的问题帮我写一个带随机数字的测试数据第138条是什么。这些请求每次内容都不同缓存系统每次都未命中每次都直接打到模型上。攻击者可以靠这类请求绕过缓存把模型API打到限流或欠费。个人使用场景下这个问题没那么严重但如果你要把这套系统开放给多人使用就必须处理。常见的办法是加布隆过滤器拦截明显不可能命中的键以及给单位时间内的未命中请求计数超过阈值就自动开启限流。后来我给系统加了一层保护同类型问题短时间内重复未命中超过5次自动降级为纯本地模板回答既挡住了消耗又保证了响应速度。6.4 内存泄漏与缓存膨胀语义缓存有一个和精确缓存不一样的特性精确缓存有上限、有TTL、有淘汰语义缓存的条目是越积越多的因为向量索引天然倾向于堆数据。项目跑了两周后发现内存占用从最初的200MB涨到了接近900MB排查下来发现是语义缓存条目只增不减旧条目完全没有淘汰机制。解法是加一个定期清理任务每小时扫描一次缓存条目超过TTL的删除同时维护一个最近最少使用的访问计数清掉最久未访问的那批条目。这里有个细节要注意在做嵌入向量删除时不要把向量直接留在索引里然后标个已删除纯标记删除会导致索引里的无效向量越来越多相似度扫描的开销降不下来。正确做法是物理删除或者定期重建索引。6.5 缓存与流式输出不兼容最后这个坑属于设计层面的个人助手的答案原本是流式输出的用户能实时看到每个字的生成过程体验非常自然。但缓存系统返回的是完整答案无法直接流式重放。一开始我的做法是查缓存命中后直接一次性返回全文但用户明显觉得回答变快了但很生硬。后来改成了伪流式输出按每50毫秒一帧、每帧5到10个字的速度播放缓存答案。视觉上手感和真实的模型流式输出几乎没有区别但底层完全不需要等待模型生成。这一步对整体体验的一致性很重要个人助手类产品里不要忽略缓存场景下的交互形态变化。7. 下一步的扩展方向从缓存到整体的性能体系阶段3的缓存系统虽然解决了大部分问题但它只是个人AI助手性能体系的一部分。跑完这轮实践后我梳理了后续值得做的几个方向每个方向都建立在缓存基础之上。7.1 预热与预计算缓存只在用户发出请求之后才填充数据意味着第一次访问某个领域的知识时仍然要等待模型推理。如果能在用户token、配置文件、知识库加载阶段提前预计算一组高频问题把结果直接加热到语义缓存里那相当于所有常见问题从第一次问起就都是命中状态。以个人知识库助手为例文档导入阶段就对每篇文档自动生成5至10个候选问题逐个嵌入并预置到缓存中。用户导入一百篇文章缓存里就提前存了500到1000条高频问答。这套预热逻辑在缓存命中率上的提升幅度比继续调阈值和算法更明显。7.2 消息历史的增量缓存当前版本缓存的是单轮问答对。但实际对话是多轮连续的用户经常在上一轮结果的基础上追问。比如先问帮我把会议纪要整理成摘要再问把摘要翻译成英文这两个单轮请求之间是有依赖关系的。我规划的方向是把多轮对话的上下文摘要也纳入缓存对最近几轮消息做一个摘要编码连同本轮的问答一起存入语义缓存匹配时把上下文摘要加上当前问题作为整体向量判断。这样可以覆盖不少多轮追问场景下的重复计算。实现复杂度会高一些但对真实对话场景命中率的拉高非常明显。7.3 分层降级策略最后一个方向是分级响应策略的落地。不是所有问题都值得花同样的算力简单的事实性问题可以直接走语义缓存中等难度的可以走小模型配合检索增强最难的那批才走完整的大模型推理。这套分级策略的底层就是缓存数据因为缓存命中率本身就是判断问题是否已解决过最可靠的依据之一。跑完阶段3之后我最大的体会是给AI助手写缓存本质不是数据库技术而是行为建模技术。缓存背后记录的是用户曾经问过什么答案是否还有效哪些内容值得快速重放这套体系积累得越久助手就越像一个有经验的工作伙伴——你说上一句它已经知道下一句怎么接。如果你也正在做一个个人AI助手或者任何一个跑在大模型API之上的应用我建议从阶段3这件事开始做性能优化动作。它可能不像换一个大模型那样能立刻提升回答质量的天花板但它把每一分重复调用的成本都省了下来而省下来的预算和等待时间最终能用来换取更多真正需要模型智慧的时刻。