@pauliusztin_: 我曾以为将1,000,000份文档摄入AI记忆系统主要是个计算问题。但我一直被证明是错的……
摘要
作者讨论了将AI记忆摄入从数千份扩展到数百万份文档的架构,强调编排和并行性而非原始计算能力,并使用Prefect进行工作流管理。
查看缓存全文
缓存时间: 2026/07/04 20:53
我之前以为将100万份文档注入AI记忆系统主要是个计算问题。但我错了……
这其实是个编排问题。
如果架构仍在顺序处理所有任务,往流水线上堆更多GPU也于事无补。
我设计的系统将摄取过程拆分为两个独立的工作池。
第一个将原始数据转化为文档。 第二个将这些文档转化为记忆。
以下是高层架构:
1/ 两个层级的并行
想象一下注入100万份文档。
一个 @PrefectIO 工作流将它们分片为1000份文档的作业。
每个工作节点再以100份文档为批次处理这些作业。
这样就实现了两个层级的并行:
- 流水线并行 → 将分片分配给不同工作节点。
- 任务并行 → 在每个工作节点内部对耗时操作进行批处理。
需要提升LLM或嵌入向量的吞吐量?
无需修改架构,直接接入Dask或Ray集群即可。
2/ 数据工作池
流水线从以下源开始:
网页URL RSS订阅源
一个 @PrefectIO 工作流将每个源展平为URL,分片为作业,推入队列。
工作节点在容量可用时持续拉取作业,只需增加工作节点即可轻松应对流量峰值。
每个工作节点:
展平URL 并发抓取100个URL 转换内容 批量将文档存入存储
此阶段主要是网络和数据库I/O。
批处理远比计算更重要。
3/ 记忆工作池
文档进入仓库后,第二个 @PrefectIO 工作流重复相同模式。
每个工作节点运行:
文本分块 批量LLM提取 实体标准化 批量嵌入向量 知识图谱生成
例如,1000份文档可能变成10000个文本块,以每批100个块进行处理。
每个阶段有不同的瓶颈。
LLM提取 → vLLM 实体标准化 → 数据库I/O 嵌入向量 → 通常依赖CPU
对它们一视同仁会浪费性能。
核心要点:
扩展AI记忆并不在于增加GPU。
而在于设计一种架构,让每个瓶颈都能独立扩展。
这就是我选择 @PrefectIO 的原因。
它通过分片、队列、重试、调度和持久化执行来编排两个流水线,使得从数千到数百万份文档的扩展变得切实可行。
P.S. 是什么阻碍了你今天的流水线摄入一百万份文档?
相似文章
@Oliviacoder1: MIT刚刚让每家AI公司的数十亿美元赌注看起来尴尬不已。他们解决了AI记忆问题。不是通过构建更大的……
MIT CSAIL研究人员提出了一种新颖的AI记忆方法,通过将文档存储在外部,并让AI自行导航和查询,从而避免了上下文腐烂,以更低成本实现了1000万令牌的有效上下文。
@tricalt: https://x.com/tricalt/status/2057173322924806651
一位创始人讨论了在生产环境中使用Markdown文件作为AI代理记忆的扩展挑战,突出了关于权限、多代理交互和时间查询的常见陷阱,并指出团队常常在不经意间修补这些问题的过程中,实际上是在重新构建一个更复杂的系统。
@pvergadia:每位开发者都必须知道的9层AI生产架构。→ 服务/ RAG管道、语义缓存、记忆、查询改…
这篇文章概述了一个全面的9层AI生产架构,强调了如RAG管道、安全守卫、可观测性和评估等组件,以区分健壮的生产系统与简单的演示。
@mvanhorn: https://x.com/mvanhorn/status/2070966613994795489
作者认为,AI代理的内存膨胀会降低性能,并建议将memory和CLAUDE.md文件控制在200行以内,使用按需检索而非将所有内容加载到上下文中。
上周我构建了一个AI Agent,这周我添加了记忆功能!
一位开发者分享了他们使用 Anthropic SDK 和 TypeScript 构建具有记忆功能的 AI 智能体的经验,解释了工作记忆、情景记忆、语义记忆和程序记忆之间的区别,以及为生产环境扩展记忆所面临的挑战。