为什么Superflows响应这么快揭秘LLM响应缓存llmResponseCache实现原理【免费下载链接】superflowsOpen-source toolkit to build an AI copilot for SaaS products项目地址: https://gitcode.com/gh_mirrors/su/superflowsSuperflows 是一款开源的 SaaS 产品 AI 副驾AI Copilot工具包而让它秒回的核心秘密就藏在 LLM 响应缓存llmResponseCache里同一个问题第二次问系统直接复用历史回答跳过对 LLM 的重复调用——响应更快、Token 费用归零。当同样的问题被反复问AI 为什么还要再想一遍传统聊天式 AI 的痛点慢每次回答都要走一遍完整的 LLM 推理多轮工具调用时延迟叠加贵相同问题的 Token 费用反复支付不稳定同一个问题两次回答可能不一致。Superflows 的答案是在每次请求真正调用大模型之前先查一遍数据库里有没有一模一样的历史对话。有就直接把缓存里的结果流式推给用户没有才走正常流程。核心机制LlmResponseCache 类是怎么工作的整个缓存逻辑集中在一个类里LlmResponseCache分三步走。第一步initialize() —— 在历史会话中定位同款对话每次用户消息进来缓存类会先执行初始化查询llmResponseCache.ts#L25-L45拿当前用户消息内容 组织 ID 会话序号去chat_messages表里找历史上完全相同的用户消息最多取最近 4 条候选排除当前会话本身如果按原文找不到还会降级匹配用 AI 对长对话生成的摘要chat_summary来匹配即使用户换了一种说法只要语义摘要相同也能命中llmResponseCache.ts#L92-L136命中后把那条历史会话的完整消息序列取出记入内存备用isHit()返回true。 这里还有一个细节查询条件里带了fresh: true只有被标记为新鲜有效的消息才参与缓存匹配见下文开关部分。第二步逐条比对历史 —— 连 API 响应也要验证找到候选会话还不够必须确认上下文真的完全一致否则缓存答案可能是错的。_history_matches方法llmResponseCache.ts#L142-L174要求历史会话必须比当前对话更长后面还得藏着 AI 的回答每一条消息的role和content都要逐一对上对 API 返回的长 JSON 做了宽容处理因为入库时超长响应会被截断所以只要后续的数据分析结果一致就判定为同一个 API 响应实在拿不准时才用最慢的深度 JSON 比对兜底。第三步命中即返回完全跳过 LLMcheckChatCache是主聊天流程的总闸llmResponseCache.ts#L196-L208历史比对通过且下一条正是assistant消息时直接把缓存文本流式返回给用户。在 v1 引擎里这一步发生在真正调用 OpenAI 之前ai.ts#L274-L347——命中缓存意味着0 次 LLM 请求、0 Token 成本用户感知就是秒回。不止聊天气泡内置的 6 类缓存LLM 调用一个都不放过Superflows 的 AI 引擎一次回答背后其实是多次 LLM 调用路由判断、摘要、检索、数据分析、追问建议……。缓存类为每一环都提供了对应的拦截点缓存方法缓存了什么省下的 LLM 调用checkPreprocessingCache路由决策与选中的动作列表chosen_route / chosen_actions意图路由PreProcesscheckChatSummaryCache长对话的压缩摘要摘要生成checkDocsCacheRAG 文档检索结果 基于文档的回答文档问答checkAnalyticsCache数据分析的图表数据与结论文字数据解读checkBertieAnalyticsCacheBertiev2 引擎的分析输出数据解读checkFollowUpCacheAI 推荐的追问建议追问生成也就是说重复提问时整条链路路由 → 摘要 → 检索 → 分析 → 回答 → 追问都可以被缓存接管这就是响应飞快的完整来源而不只是回答快。在哪里生效三代引擎全部接入缓存类是各代 AI 引擎共用的基础设施关键调用点包括v1 引擎lib/edge-runtime/ai.ts#L275-L281初始化 主回答缓存v2 引擎lib/v2/edge-runtime/ai.ts#L173-L246摘要、路由、文档缓存依次检查数据分析缓存lib/v2/edge-runtime/dataAnalysis.ts、lib/v3/edge-runtime/matching.ts如何开启与失效缓存组织级开关organizations表中的caching_enabled字段控制该组织是否启用缓存迁移文件supabase/migrations/20231214175242_add-caching-feature-flag.sql新鲜度标记chat_messages等表都带fresh布尔字段配置变更后可批量把旧消息置为非新鲜让缓存自然失效避免用旧配置产出看似正确实则过期的答案。总结Superflows 响应快的原因可以浓缩为一句话把回答从一次性消费变成可复用的资产。LlmResponseCache通过原文匹配 摘要降级匹配 全历史严格比对三层校验在保证正确性的前提下让重复问题跳过路由、检索、分析、生成等全部 LLM 环节——快且免费。如果你正在为自己的 SaaS 产品搭建 AI 副驾这套多点位响应缓存的设计非常值得借鉴。【免费下载链接】superflowsOpen-source toolkit to build an AI copilot for SaaS products项目地址: https://gitcode.com/gh_mirrors/su/superflows创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考