为什么结构化 Atom 优于固定分块 RAG
在 ENGRA-KB-v2（550 文档、400 查询）上，结构化 Atom Recall@10 达 75.3%，固定分块 RAG 为 54.8%——Library → Scope → Topic → Atom 如何改变检索。
分块大小的陷阱
多数 Agent 记忆栈仍把长期召回当作固定大小分块上的向量检索。512 token 会把表格切到边界外；2000 token 又会稀释相关性。团队最终在为每个语料调 chunk 大小，而不是定义记忆的存储单元。
分块流水线在更新时也很吃力：政策一改，就要重新嵌入重叠窗口并祈祷正确片段能浮上来。没有「三月定价决策」这类稳定标识——只有随措辞变化而漂移的 embedding。
Engra 以结构化 Atom 存储记忆——锚定在 Library → Scope → Topic → Atom 层级上的自洽事实与叙事。检索目标是 Atom，而非任意 token 窗口。
我们测了什么
ENGRA-KB-v2 是合成企业知识库：550 篇文档、400 条标注查询，所有方案共用同一 embedder（Xenova/all-MiniLM-L6-v2）。在同一语料上对比 BM25、固定 512 分块 RAG 与结构化 Atom 检索，便于本地复现。
结构化 Atom 达到 75.3% Recall@10，分块 RAG 为 54.8%，BM25 为 52.0%。MRR 排序一致——Atom 提升的是排序质量，不只是命中率。
Atom 为何胜出
Atom 贴合工程师对 Agent 记忆的思考方式：一项决策、一条客户偏好、一步 runbook——而不是「第 12 块的第 7 段」。每个 Atom 携带 Library、Scope、Topic 元数据（JSON 字段 libraryKey），向量打分前即可过滤。
Atom 之间的路径回链让唤醒与 L2 召回可解释，而非不透明的相似度分数。Agent 引用记忆时，可追踪注入了哪些 Atom ID 以及链接原因。
Engra 的 L0–L3 记忆栈（身份 → 叙事 → 主题召回 → 深度搜索）让 Agent 按任务加载合适深度，而不是塞满一个扁平上下文窗口。
分块何时仍会出现
入库时仍可能切分源文件以便嵌入，但检索单元始终是 Atom。附件与源文件预览单独计费——配额详见记忆库产品页。
若与自建分块流水线对比，请使用相同 embedder 与查询集。公平对比比绝对分数更重要。
接入你的技术栈
Cursor 类 Agent 用 Memory MCP + Agent Skills；编排服务用 REST API。两条路径同一 Atom 模型。
先在自有语料复现我们的数字，再与现有分块流水线对比。流程与政策类知识库通常收益最大。