物化结果要按版本失效并增量刷新
三个错误答案
- 每次保存都算:笔记每 800ms 自动保存,写一句就分析一次 —— 又贵又抖,还会在用户没写完时过早下结论。
- 每次打开页面都实时算:用户要等模型和向量计算,页面打开变慢。
- 首次生成后永远不变:库越大,旧结论越不准。
正确形态:SWR 式物化
写入侧:停止编辑约 2 分钟 → 标记待处理 → Cron 生成 → 落库(带版本)
读取侧:打开页面 → 立即展示已存结果 → 若已 stale,后台刷新替换
手动侧:高优先级任务,走同一套队列,而不是同步请求
每条结果记录版本与失效依据,例如:noteId / noteVersion / kind / relatedSetHash / corpusRevision / promptVersion / model / generatedAt / supersededAt。触发失效的条件:正文变了、Top-K 相关内容明显变了、新内容与它建立高相似关系、prompt 或模型版本变了、用户手动要求重算。
关键约束:不能「每加一篇就重算全部」
正确做法是反向的:新内容先算向量 → 找出真正受影响的少数对象 → 更新关联 → 只把这几条标记 stale。作废要精确到「受影响的那几个」,刷新要留给下一次 Cron。
相关
- 工作流按内容类型分开而不是抽象成一条通用流水线 —— 这些结果由哪条流水线产出
- 更新时序要由本地最新状态决定 —— 版本比对才决定谁作废谁
- 存量不会自动跟上新逻辑 —— 规则改了,已有物化结果不会自己更新
- 服务端缓存与浏览器缓存的边界 —— 「旧结果先展示、后台替换」的缓存同族
- 后台任务队列选型 —— 刷新任务排在哪
- 活的能力取决于增量机制而不是生成质量 —— 本条是该 synthesis 的一处证据:判据从「生成一次」换成「带版本 + 作废 + 增量刷新」