这一版设计文档工程代号“动态向量数据库核心 AGI 架构”标题里“二版第四轮”这几个字每一个字都是实打实走过来的。这一轮最终没有打补丁而是把前几轮积累的结论全部摆上桌重新梳理出了一套新架构。简单说这版方案解决的是一个问题AGI 场景下记忆系统的写入、检索、遗忘和演进到底该怎么设计才能既撑得住动态变化又不牺牲查询质量和工程可控性。适合正在做智能体记忆、RAG 长期上下文、或者想深入理解向量数据库内部设计的后端同学参考我会把从第一轮原型到第四轮重构的完整推导过程、关键模块的落地细节以及几次印象深刻的翻车现场都拆开讲清楚。1. 整体设计思路为什么 AGI 记忆不能套传统向量检索先明确一件事动态向量数据库核心服务的对象不是普通推荐系统或者离线相似度匹配而是 AGI 的记忆系统。传统向量数据库做的是“读多写少、批次导入、离线建索引”但 AGI 场景完全是反过来的——它要求数据持续写入、按需修改、按生命周期遗忘并且检索不只看相似度还要看时间、看上下文、看信息强度。这等于把整个架构的设计前提给换了。1.1 “动态”到底是哪几个动态我拆解“动态向量数据库”时把动态分成了三个层面这三层缺一不可也是前几轮失败的根源所在。第一层是数据动态。向量数据会不断插入、更新、删除传统方案里常见的“全量建索引然后服务查询”在这个场景下根本走不通。每来一条新对话记录、新反思片段都要能立刻进入索引并参与检索同时老数据还要按策略被淡化和清理。第二层是结构动态。向量维度有可能变化元数据模式也有可能随业务调整。比如上游换了一个更大规模的嵌入模型向量的长度从 384 变成了 768数据库不能因此就强制推倒重建。再有原本记录记忆只存“文本、向量、时间”后来要加“重要度、来源模块、关联事件”这属于模式演化底层存储必须能平滑承接。第三层是查询动态。AGI 调用记忆不是固定式的“查 Top-K”而是会有时间衰减加权、事件路径追溯、条件过滤组合有时候还要支持“先模糊定位一组候选、再在这组候选里做推理排序”这种多级检索。传统向量库那种单索引、单路召回、暴力精确排序的做法在这样的查询模式下会很吃力。1.2 第四轮之前经历过什么第一轮单一大索引整库跑相似度检索。演示效果很好但一旦数据量上来删除和更新几乎无法低成本完成一条旧消息的修改可能要触发大范围索引重建。第二轮在向量索引之外加上了元数据过滤查询可以按会话、时间和类型先圈定范围。这一轮把检索精度拉上来了但发现高频动态写入会持续拆动索引结构导致线上延迟像心电图一样一跳一跳往上爬。第三轮引入了生命周期管理给每条记忆加了 TTL 和重要性衰减。遗忘能力有了但生命周期任务与在线查询在资源上互相撕扯CPU 峰值高得离谱查询尾部延迟反而恶化了。这三轮下来最大的认知变化是不能把动态性当作附加功能挂在静态索引外面而是要从存储引擎的层面把“新数据的写入缓冲、旧数据的冻结固化、后台的异步合并”当成一条一流的主链路来设计。这就是第四轮“综合梳理出新架构”的真正出发点。2. 新架构核心拆解读写分离的引擎分层这一版架构没有沿用“一个大索引挂所有”的思路而是借鉴了很多成熟存储引擎的玩法把路径拆成写入链路、查询链路和后台维护链路。整体上分成接入层、元数据目录层、向量文件层、调度维护层每一层各管一摊互不锁死。2.1 接入层与统一操作语义接入层对外提供统一的异步读写接口内部不再区分“这是插入”“这是更新”还是“这是删除”全部抽象成带版本号的记录操作。每条数据进入系统时都会被分配一个全局单调递增的 SeqID同时携带主键 ID、时间戳、向量、标量属性、来源指针这些元信息。为什么要统一操作语义因为 AGI 记忆系统里一条知识的更新很可能不是简单替换而是“旧的缩减权重、新的合并进来”。如果存储层只提供 put/get应用层就得自己处理并发和版本冲突最后容易把逻辑写死。把操作统一成“按主键、按版本进行解释写入”等于是把并发控制的复杂度收拢到数据库内部。接入层还做了两件事一是消息按语义主题做初步路由比如短期记忆和长期知识走不同的桶二是批量攒缓冲把高吞吐的写入先落到带 WAL 的追加日志里防止进程崩溃丢数据。2.2 写入路径内存原生索引与冻结段新架构最核心的存储抽象是分桶的 Segment。其设计逻辑与 LSM-Tree 有些相似新写入的向量先进入内存里的原生向量索引结构而不是直接去打扰磁盘上的大索引。内存索引持续接收数据达到一定规模后整个内存索引块被冻结成不可变的段文件写入磁盘后台再按期把多个小段合并成更大的段。这样的好处很直接查询只面对不可变段不会出现“正在查的这个索引结构被并发写入搞到分裂”的问题。删除操作也不立即物理删除而是先写入删除标记等到合并压缩时统一清理避免高频小删除对索引产生震荡。这正好回应了第一轮和第二轮的死穴。在具体参数上我给的推荐配置是每个内存分桶的冻结阈值设在 256MB 左右或者按 1 万条写入记录触发一次冻结。太小会导致段文件过多、合并压力大太大会让内存索引单次占用过高GC 或内存碎片失控。2.3 查询链路路由、召回、合并、精排查询时请求先进语义路由层。语义路由会读取本次查询附带的属性条件比如“只查最近 7 天”“只要某个事件流里的记忆”“丢弃强度低于阈值的记忆”然后决定需要访问哪些段、哪些分区。召回到具体段内时每个段本身维护一个独立向量索引比如 HNSW 或 IVF快速取回候选 Top-N。多段结果会先按分数与时间权重的综合分做一次粗排合并再对合并后的结果进行向量精排。结尾还有一个可选的重排环节通过重排模型或规则调整优先级。这一套流程下来查询不会因为动态写入被阻塞段合并也可以独立并发执行。实测下来第四轮的 p99 延迟比第三轮稳定了大概 35%而写入与查询的相互争抢导致的尖峰基本消失。3. 实操落地索引选型与关键参数架构画得好是一回事落到工程参数是另一回事。我在这轮落地里碰到的细节很多都是文档里不会写但实践中一定会踩的东西挑几个有代表性的展开。3.1 内存索引与磁盘段的索引选择内存中的新数据我推荐用 HNSW 变体。原因是内存阶段的数据量相对小却要求即时插入和即时可查HNSW 的增量插入能力强不像 IVF 那样需要周期性重算中心点。磁盘段则要区分大小小段的冷数据可以用暴力扫描或倒排文件 IVF大段用 HNSW。同一套架构内索引类型允许混合查询路由层只要拿到“段级元数据”就知道该走哪条索引路径。HNSW 参数上我的经验值是 M 取 16 到 24。M 太小图连通性差召回率会掉M 太大构建和检索的耗时会快速增长。efConstruction 一般设在 200 到 400 之间这个值主要影响建索引质量。线上查询时的 efSearch 则要按延迟预算动态调64 到 128 是常用起点如果召回率不够可以往后加。这里必须提醒一点不要全局只用一个 efSearch。不同分段会按时间或重要度区分热度和冷度热度高的段可以用更大的 efSearch 换取召回冷数据段用小参数省开销。把查询流程做成“先按分段元数据规划预算、再分头执行”的形式整体性价比会好很多。3.2 Upsert 的版本冲突处理动态数据里最常遇到的一个问题是同一条记忆被反复修改旧版本还在索引里新版本又写进来了。如果直接按主键覆盖后续的物理删除和查询去重都很难处理。我在实现里单独维护了一张“活动记录表”只存当前版本的指针。新写入进来时如果主键已存在旧版本会在逻辑上被置为失效但向量文件里的旧数据不会立刻删除而是等待索引合并时统一清理。查询阶段对主键做聚合去重保证同一个逻辑知识点只返回最新版本。这个做法牺牲了一点查询期去重开销但换来了写入路径的高吞吐和低碎片。注意活动记录表本身要持久化并加副本否则丢了它全库的逻辑视图就乱掉了。3.3 遗忘机制与打分策略AGI 记忆必须会忘记这版架构里的遗忘不是定时任务暴力删除而是基于记忆强度分数和时间衰减共同作用的动态策略。每条记录都会维护一个综合分计算公式可以简化为当前强度 基础强度 × 时间衰减系数 访问增益。时间衰减系数按指数走越久没被访问的记忆成本越高每一次被检索命中强度会小幅回升模拟“复习”的效果。只有分数低于某个阈值且超过最短保留期限的记录才会在下一轮段合并时被删除。用工程方式说遗忘本质上被转成了“低价值数据的标记与淘汰”这个流程和普通存储系统的垃圾回收很类似因此可以被调度器安排在低峰期做完不干扰查询。区别在于“什么数据是垃圾”不是靠 TTL 一个常量决定而是靠记忆系统自己的状态推断这就回扣了动态 AGI 场景的需求。3.4 分段合并的策略与限速段合并是把多个小段变成大段、清理删除标记的唯一时机。合并本身很吃 IO如果不停地在在线服务忙碌时跑会和正常查询抢磁盘表现就是延迟飙升。给调度器的合并任务配置了带宽令牌桶合并线程每秒只允许消耗设定额度的 IO超过就等待下一轮。同时合并任务的优先级可以被压到低于查询线程确保高负载时段查询优先。这个细节看起来不起眼但直接决定了系统在长时间运行后的稳定性在第三轮里我们就是忽略了它才导致 CPU 峰值把集群拖垮过。4. 常见问题与排查技巧实录工程里没有一次跑通的神话特别是这种数据系统问题往往都出在数据规模上来之后的第二周。记录几个我亲测碰到的典型问题帮助大家以后少走弯路。4.1 写入链路正常查询延迟却周期飙高现象是写入量平稳查询延迟曲线每隔一段时间就出现一个尖峰。一开始怀疑是 GC 问题后来逐步排查发现是内存索引达到冻结阈值后冻结动作与查询共用同一批 CPU 线程冻结时对原索引做了一个接近全量的遍历拷贝直接把延迟抬上去了。修复思路是给内存索引建一个双缓冲区结构新写入只进当前活跃区冻结时直接交换活跃区指针把老活跃区交给后台线程异步处理。这样前台查询几乎感觉不到切换尖峰随之消失。4.2 更新量上来以后段内 HNSW 上下层失配高频更新大量旧数据之后发现即使查询参数不变召回率仍然缓慢下降。后来定位到现象是访问频率高的热数据不断被更新并追加到新段而合并动作没跟上导致同一份逻辑数据被拆散到多个段里。各段单独召回本地 Top-K 时其实都拿不到全局真正最需要的几条。解决办法分了两步第一是让活动记录表里记录“数据所在段”的映射更新时优先写入最新活跃段第二是调高热数据段的合并优先级让相关段更快合并成一段减少跨段碎片化。4.3 向量维度升级时的兼容上游换嵌入模型后向量的维度变了。旧段是 384 维新数据是 768 维。如果两支数据并存于同一套查询链路内部检索距离根本无法比较。我这边的做法是设计一个固定最大维度、不足部分补零的策略让所有段在接口层表现为同一维度。真正计算相似度时查询向量也只和实际有效维度做点积。代价是有一点点无效计算但换来的是维度的平滑迁移。等旧分段数据逐步淘汰干净后再把全局最大维度正式切换上去。注意新空维度补的零不要参与归一化否则相似度会被稀释。这里顺便附一个参数速查表适合第一版落地时作为起点配置项推荐值说明HNSW M16 到 24影响图连通度与内存efConstruction200 到 400构建质量离线调参efSearch64 到 128在线召回质量与延迟权衡内存分桶阈值256MB 或 1 万条冻结触发时机合并 IO 令牌速率预留 20% 磁盘带宽避免合并抢占查询最大向量维度按上游模型上限预置维度迁移平滑方案4.4 生命周期淘汰误伤重要记忆第三轮里出现过用户反馈某些很久没被访问但极其重要的核心知识被系统遗忘了。原因就是纯靠时间衰减淘汰没有把“重要度”这个维度挂钩。第四轮把它修掉了打分公式里加入“基础强度”字段该字段由写入来源和业务策略共同决定。核心规则类知识的基础强度设定远高于闲聊信息即使长期不访问也有保护线。实际落地时还要注意不要每个小时都重新算一遍分否则资源开销很大一天两次批量重算就足够。5. 如果再让我从零梳理我会先定哪三个原则做到这个版本最大的收获不是某个索引参数而是几个可以直接迁移到其他系统的设计原则值得单独说出来。第一把写路径和读路径从物理上分开。所有动态更新先进内存缓冲查询只碰不可变段这是整个系统稳定性的基石。别图省事用一个可读写的大索引增删改查都往上面招呼那等于把所有复杂度都压在了索引结构上。第二淘汰机制要放进存储引擎而不是做成外部定时任务。记忆的遗忘是 AGI 系统的核心诉求不是附加功能。只有引擎级淘汰才能做到“合并时清理、查询时忽略、分数变化时调整”也才能把遗忘和系统生命周期结合在一起。第三参数必须可调且要区分冷热。在 AGI 架构里不同数据的时效性和价值差异极大一套固定的索引和淘汰参数根本撑不起全部业务场景。用语义路由把查询分发到不同策略的段上让冷热分层发挥作用才是动态系统的正确解法。这版架构梳理到目前的状态我已经把原来设计文档里“先解决检索精度、再解决写入稳定、再解决生命周期”的串行思路彻底改成了一套并行互不阻塞的整体。接下来要做的后续扩展大概率是把语义路由这层的策略做成可编程的让上层 AGI 能通过注册函数自定义记忆召回规则而不是把规则写死在数据库细节里。
