知识不是靠相似度找回来的——FTS5、Palantir 本体,和一个 Agent 记忆系统的工程账
知识不是靠相似度找回来的——FTS5、Palantir 本体,和一个 Agent 记忆系统的工程账 > 本文是《当 Agent 记忆遇上情报机构:Palantir 教我们什么》的工程续篇。前作讲”为什么这么想”,这篇讲”怎么建、怎么用、为什么不用另一种”。 > > 起因很实在:一位做企业知识库(业务+数据中台+BI 那套)的朋友问了个问题——知识老要更新,每次对话还得带一大堆上下文,怎么办。我把给自己 Agent 跑了几个月的那套东西整理成了一份方案文档,顺手也发出来。它同时是给同行的参考,和我对自己系统的半年体检报告。 一、三个痛点,三个解法 做企业知识库时,几乎必然撞上三堵墙: 痛点 表象 真实根因 知识更新难 改一条知识要重新切块、重新嵌入、重建向量库,管道长且容易和源文档脱节 存储(向量库)和真相源(文档)是两套系统,双写必漂移 上下文爆炸 每轮对话都带几万 token,成本高、响应慢,回答质量反而下降 把”全量知识”当”上下文”,没有分层注入 检索不可解释 召回了 A 没召回 B,说不清为什么;业务方问”依据是什么”答不上来 向量相似度是黑盒打分,无法追溯命中原因 我的解法就三句话:文件即真相源,索引是派生品,上下文是按需视图。 三者任何一层坏了,都能从上一层重建。再用 Palantir 本体模式把这些部件组织成一个”活模型”而不是”资料仓库”。 ┌─ 写入层 ──────────────────────────────────────────┐…