正在打开每日关注
正在打开每日关注
解析 LLM Wiki 将原始资料编译为可维护页面，并区分语料知识与具时效、带身份的用户记忆。
这篇把「LLM Wiki」讲透了。 Karpathy 4 月那篇 gist 之后，四家完全独立的团队（Cognition DeepWiki、Factory AutoWiki、LangChain OpenWiki、Garry Tan GBrain）几乎同时收敛到同一套架构： ingest 时编译成可维护的 markdown 页面，而不是每次 query 再从 raw 重新推导。 核心 insight 是对的——人类 wiki 死于维护成本，而模型恰好不嫌烦、不漏更新。 但文章最后那个区分才是真正值钱的部分： Wiki 解决的是 corpus knowledge（这堆材料里有什么），不是 user memory（这个人上周改主意了、这个方案已经试过失败了）。 把 Gmail / 代码仓库编译成页面，只是告诉 agent「文档里写了什么」。它解决不了「这个决策已经作废」「上次这个路径踩过坑」这种带身份、带时间、带矛盾的记忆。
是什么 这是一条对 LLM Wiki 架构趋势的二次解读。推文观察到，Karpathy 的 gist 之后，Cognition、Factory、LangChain 与 Garry Tan 相关项目都采用相近路径：在 ingest 阶段把代码仓库、Gmail 等原始材料编译为可维护的 Markdown 页面，供后续 agent 使用。
核心设计 关键变化是把知识整理从 query-time 推理前移到写入阶段。页面成为稳定、可审阅、可增量更新的中间表示，能够降低每次从 raw corpus 重建上下文的成本，也让知识结构更容易被人和模型共同维护。
关键洞察 推文最有价值的判断是区分 corpus knowledge 与 user memory。前者回答材料中有什么，适合 Wiki；后者记录某个用户在何时作出的决策、改变的意图、已经失败的尝试及相互矛盾的事实，必须保留身份、时间与状态。两者混为一谈，会让 agent 把过时文档误当成当前意图。
边界与风险 LLM Wiki 不是完整记忆系统。落地时仍需设计事件来源、时间有效性、冲突消解、作废标记和权限隔离；Markdown 编译只解决可维护的知识呈现，不自动保证事实新鲜、因果关系或个体化判断。更稳妥的架构是让 Wiki 负责语料层，让独立的记忆层管理用户状态，并通过明确的引用和更新协议协作。