Node.js 用语义缓存减少大模型重复调用

同一个问题换个问法，就又付一次模型调用费，这是不少 AI 应用会遇到的浪费。作者给出的方案是在 Node.js 进程里加一层语义缓存：先判断新问题与历史问题是否足够接近，命中就复用答案，否则再调用 OpenAI。

这套方案用 local-semantic-cache 包装 SDK，把向量计算和文件持久化放在本地。接入看起来很轻，但能否用于生产，取决于两个更难的问题：语义接近是否允许复用答案，以及缓存会不会忽略影响答案的上下文。

问法不同，为什么还能共用缓存

普通键值缓存按字符串查找。「怎么重置密码」与「忘记密码怎么办」即使指向同一件事，也会形成不同的键。这里的限制来自精确匹配策略；Redis 只是原文拿来举例的存储工具。

语义缓存会先生成嵌入向量（embeddings），也就是把文本转换为可计算相似程度的数字表示，再用余弦相似度比较新问题和历史问题。超过门槛，就返回历史答案。

原文把典型云端 LLM 响应时间写为 800ms 到 4000ms，并宣称本地缓存命中可在 <1ms 返回。不过，文章没有交代测试硬件、缓存规模、向量模型，也没有说明这个时间是否包含新问题的向量生成。因此，这些数字只能视为作者的性能主张，不能直接当作项目预算。

流程里的判断条件是相似度 >= 0.85 时命中，< 0.85 时调用上游，再保存问题向量与答案。原文流程图混用了「距离」和「相似度」：这里应该按相似度理解，数值越大越接近。

语义相似只能筛出候选答案，不能证明两个请求可以安全地共用答案。

例如「允许删除」和「不允许删除」只差一个字，业务含义却相反。对程序员来说，减少重复请求只是收益的一半，错误复用的代价也必须进入评估。

本地接入很短，部署条件不能省略

作者选择 local-semantic-cache，是因为它把本地向量生成、矩阵相似度计算和自动文件序列化封装在一起，无需先搭外部向量数据库。

依赖安装命令是 npm install local-semantic-cache openai，开发依赖则是 npm install --save-dev typescript @types/node。文章没有给出包版本，后续核对行为时需要自行锁定版本。

下面这段代码解决进程重启后缓存丢失的问题，可放入 aiService.ts：

import { OpenAI } from 'openai';
import { wrapOpenAI } from 'local-semantic-cache';
import path from 'path';

const baseOpenAI = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });

export const persistentOpenAI = wrapOpenAI(baseOpenAI, {
  minSimilarity: 0.85,
  // 自动将变化写入磁盘
  filePath: path.join(__dirname, 'data', 'llm-cache.json'),

  onCacheHit: (q, time) => console.log(`Served from disk-backed cache in ${time}ms`),
  onCacheMiss: (q) => console.log(`Fetching new tokens from provider for: ${q}`),
});

重点看 filePath：它为缓存提供本地文件备份，但文件能否跨部署保留，还要看运行环境。容器被替换、临时文件系统被回收时，仅有这个配置并不够。多个 Node.js 实例如何共享缓存、并发写入如何处理，原文也没有说明。

minSimilarity 的配置范围是 0.0 到 1.0。作者推荐 0.85 捕捉同意图的小幅改写，但没有提供阈值对照实验。它适合作为试验起点，不适合作为通用默认答案。

onCacheHit 和 onCacheMiss 提供了观察入口。示例会打印完整问题，实际接入时应根据请求内容调整日志，尤其是内部问答可能包含用户资料或业务信息。

流式、多轮和类型提示，分别保证了什么

原文进一步宣称，包装器能保留 SDK 原生调用方式，并覆盖流式响应、多轮对话和 TypeScript 类型提示。这三项解决的是不同层面的问题。

下面的代码展示流式消费方式，调用处仍然使用 chat.completions.create：

import { persistentOpenAI } from './aiService';

async function handleStreamingAssistant(prompt: string) {
  const stream = await persistentOpenAI.chat.completions.create({
    model: 'gpt-4o',
    messages: [{ role: 'user', content: prompt }],
    stream: true, // 缓存拦截、保存并回放流
  });

  for await (const chunk of stream) {
    process.stdout.write(chunk.choices[0]?.delta?.content || '');
  }
}

需要看的是 stream: true。作者称，包装器会透传分片，同时在内存重建文本，等流正常结束后再缓存。这个设计能解释完整文本怎样保存，但示例只读取 delta.content，没有展示工具调用、异常中断、取消请求或其他响应字段如何处理。所谓不增加延迟，也没有附测试证据。

多轮对话部分，正文说会综合 system、user、assistant 消息，代码注释则说主要向量化最后一条用户消息，再把历史作为上下文修正。修正算法没有展开。对于「按刚才第二个方案继续」这样的请求，前文直接决定答案，不能仅凭描述认定隔离准确。

类型方面，作者称包装器通过 TypeScript 泛型保留自动补全、参数检查和返回结构。示例仍可传入 model: 'gpt-4o'、temperature: 0.2，并读取 completion.choices[0].message.content。这有助于降低迁移成本，但编译期类型正确，并不能验证缓存命中的业务正确性。

我的判断

我认可先用嵌入式方案验证需求的方向。对单实例、问题重复度高、答案相对稳定的 Node.js 服务，它能减少早期搭建向量基础设施的工作。

但原文更接近接入教程，没有提供足以支撑「生产就绪」的完整证据。延迟收益、阈值效果和上下文匹配准确率都缺少对照数据；节省多少费用也没有实际账单。这些应当作为待验证假设。

和精确匹配缓存相比，它能覆盖更多改写问题，也增加了错误复用的可能。和外部向量数据库相比，它减少了部署组件，却仍要面对容量、共享、持久化和失效管理。

「零基础设施」可以理解为少部署一个服务，不能理解为没有运维条件。

原文结尾还询问读者是否需要 TTL，却没有给出过期策略实现。模型、系统提示、知识内容更新后怎样失效，用户之间怎样隔离，也都需要补齐。

能拿来做什么

• 在 Node.js 问答服务里，先选答案稳定、重复率高的一类问题试接入，记录命中率、完整请求耗时和错误复用案例，再决定是否扩大范围。
• 用真实问题的改写样本测试 minSimilarity: 0.85，同时加入否定句、不同业务条件和多轮指代，检查它是否把不该合并的请求合并了。
• 给前端提供 SSE 接口时，分别验证首次请求、缓存回放和中途取消，确认浏览器消费到的内容及结束行为符合预期。
• 在部署前确认 filePath 所在磁盘能否保留，并明确用户隔离、配置变化和内容更新时的失效规则；原文没有替你完成这些工作。