我们之前给客户做过一个背调系统方案。用 RAG 查企业材料自动生成背调报告。听起来很成熟检索加生成标准管线。报告出来了版式漂亮引用齐全语气笃定。不过财务数字是错的。营业收入、净利润整段数字对不上材料。有的是编的有的是把别处的数挪了过来。看起来比真的还真。关键数字不对报告就没法用。材料里明明写着数模型为什么不抄材料。后来我想明白了这不是 RAG 做错了什么。恰恰相反它很好地完成了自己的任务找到相关材料。问题在于我们让一个检索系统承担了知识管理系统的职责。RAG 是知识消费层不是知识生产层。财务数字这种东西不能靠模型「理解大意」必须钉死在结构里带单位带期间带口径带出处。搜得再好也只是把原料端上桌。怎么变成可以下锅的知识是另一件事。我后来把这个过程叫做「知识编译」。编译不是总结。写代码的人对这个类比不陌生源代码 ↓编译器 ↓机器码知识这边对应的是原始资料 ↓知识编译 ↓实体、关系、规则、约束、证据总结是给人看的一段话编译是给系统用的结构。机器码可以在机器上反复执行编译好的知识可以在 Agent 里反复调用每次不用重新理解一遍源代码。这两年大家默认堆 RAG。文档入库切块Embedding进向量库。提问时召回几个分块模型现场组答案。管线很漂亮。问题是它不保留结果。第 10 次提问和第 1 次一样从原始分块重新推导。前面九次的理解一点没剩下。Karpathy 关于 Agent 上下文管理的一系列讨论把问法换了一下。别在查询时重新发现知识把知识编译一次持续更新让它成为 Agent 可以长期访问的环境。社区后来把这类做法叫成 LLM-Wiki。我觉得多数人还是把它当成「又一种知识库产品」。这样看会看丢真正的变化。它不是产品是一种知识编译范式。一先看生命周期RAG 是单向的。原始资料切块Embedding检索回答结束。LLM-Wiki 是个环。原始资料进来理解、提取变成实体、关系、规则、适用条件、证据与冲突。编译成 Wiki 页面。持续增量维护。Agent 与人消费。消费时冒出新证据、新经验。再编译。回到维护那一步。区别就在这里RAG 优化的是这次怎么找到答案。LLM-Wiki 优化的是这次找到的东西能不能成为下一次的知识。知识复利只在闭环里成立。单向管线跑一万次也不会长出利息。对照着拆解知识能力其实分三层。Knowledge Retrieval我去哪里找。RAG、搜索、向量库都停在这。Knowledge Compilation找到的东西怎么变成结构化、可复用的知识。这才是 LLM-Wiki 的核心。Knowledge Evolution新信息进来后原知识怎么变。这是复利能不能转起来的关键。RAG 等于 Retrieval。LLM-Wiki 等于 Compilation 加 Evolution。二Compilation 到底在编什么它不是简单地写摘要完事。而是对着源资料编译至少要落下这几类东西实体。谁是谁。同一项目在不同文档里的别名要并成一条。关系。谁依赖谁谁适用谁。客户到产品到规则那条链以前散在四个目录里。规则。生效的口径是什么版本号是多少。条件。什么情况下适用。地区、时段、服务类型、例外。证据。每句话来自哪份材料第几节。冲突。两份材料不一致时双方观点都钉住标明待裁决。我们库自己就挂着这种冲突。同一晚的 Agent 发邮件事件团队第一次复盘把 Code Sandbox 加 smtplib 直连夸成 Plan B 优秀实践。过阵子写修订版把同一方案降成临时工答案换成 Agently Mail。两份都是正式材料但是观点和评价互相冲突了。这种事没法靠检索消掉。只能在编译时承认冲突存在双页标注留下解决方向等人或等新证据来裁。人类 Wiki 腐化多半就腐在这一步。修链接、对齐摘要、逐份比对、统一实体无尽头无即时回报团队一忙就扔扔了就没人再用。模型正适合干这个。它不会烦不会跳过某条交叉引用一次能改十几个文件。所以定义可以收准一点。LLM-Wiki是用模型承担人类无法持续完成的知识编译与维护工作。编译是前半程维护是后半程。很多人只抄了「用 Markdown 记笔记」没抄这两程那还是检索套壳。三Evolution 怎么转编译一次不够。材料会更新结论会过期新的经验会盖掉旧的判断。没有 EvolutionWiki 会变成一屋子过期档案。这里有个很容易被略过的判断。Evolution 不等于「自动改文档」。变更至少要有三样东西合并策略出处可追溯。合并策略回答的是新旧冲突时怎么办。是增量追加还是整体替换基石事实能不能被覆盖过期记忆要不要删掉。没有策略的自动改写等于让实习生拿橡皮擦直接改档案。出处回答的是这句话从哪来。可追溯回答的是上周改了什么能不能 diff。所以认真的知识库都会把版本控制写进交付方式用 git 分发让每一次知识变更都留下痕迹。知识库不是聊天记录得有 diff。一个工程实现给出的合并语义大致是这几种操作合并策略用途增量合并保留旧文追加或局部修改事实补充整体替换新结论覆盖旧结论判断更新只创建不覆盖保护基石事实口径、定义删除清过期记忆失效信息关联记忆之间双向挂钩建立图闭环长这样。对话完成任务提取变更按策略写入重建导航下次查询直接用上。每个动作都在给知识库进货。四规模上去了怎么喂给 Agent编译出几百个页面之后新问题来了Agent 怎么读得进去。靠一份总目录加链接导航大约撑到一百份源文档、数百个页面。再大光索引就能把上下文撑爆。但是撞墙的是导航方式不是「编译成 Wiki」这件事本身。工程上的答案是分层供给。不是把整库塞进上下文而是让 Agent 像翻文件系统一样从粗到细一层层看。层作用L0说清这是什么判断方向L1核心信息与结构导航理解脉络L2原文细节确认需要才碰Agent 的路径变成先扫 L0 判断哪些目录相关再读 L1 看结构确认需要才下到 L2。Token 从全量读降到按需读。检索也跟着变成结构化导航。先在粗粒度上定位相关目录再钻进目录里精查。比在一堆扁平分块里捞 top-k更不容易把无关目录的零散句子端上来。最近被频繁碰过的知识理应优先出列——上周的经验不该埋在三年前的文档底下。这里真正值得记住的不是某家的算法而是一个原则知识规模变大后供给方式要比检索算法先升级。先解决「Agent 一次该看多少、按什么顺序看」再谈召回率。五形状怎么统一知识编译完了长什么样各家原来各说各话。AGENTS.md、CLAUDE.md、Obsidian 加 Agent、各种 index.md 加 log.md 文件夹互不兼容。谷歌云 2026 年 6 月发的 OKFOpen Knowledge Format想定的就是这个形状。极度克制。一个 Bundle 就是个普通文件夹一个概念一份 Markdown上面 YAML frontmatter下面正文。强制字段只有一个 type。title、description、resource、tags、timestamp 都可选。路径即概念 IDtables/orders.md 的 ID 就是 tables/orders。文件之间用标准链接互引文件夹自己长成图。保留名两个。index.md 管渐进探索log.md 管变更历史。合规只要三件事。frontmatter 可解析type 非空index 和 log 若存在则结构正确。消费者必须容忍未知 type、缺字段、断链。一个文件不合格不影响整包。这套设计我觉得狠的地方在于它不定义内容模型只定义互操作最小公约数。type 取值完全由生产者定。要扩展加自定义键消费者该保留不该丢。在更大的栈里OKF 是内容层。llms.txt 是入口路标EntityMap 是实体声明OKF 是图书馆本体。MCP 管实时工具和活数据在旁边另一条道。一个是知识沉淀层一个是工具访问层互补不抢地盘。我们自己的 wiki 结构几乎是 OKF 的超集。分层 INDEX、log、frontmatter、双链都有。还多两样 OKF v0.1 没有的。hot.md 当近期上下文缓存。矛盾用 callout 钉在冲突双方页面上。OKF 悬而未决的「冲突没有合并语义」我们用最小机制先扛住了。六分清四层就不会把产品摆成对打到这里可以收一张图。层次解决什么代表Paradigm为什么要把资料编译成 WikiLLM-WikiFormat知识怎么表示、怎么流通OKFInfrastructure大规模知识怎么被 Agent 高效使用OpenVikingOwnership知识如何长期属于一个人或组织MolioLLM-Wiki 是范式。OKF 是表示与流通规范。OpenViking 是企业规模的基础设施实现。Molio 管的是知识归属。不在一个维度上竞争。这里我原先写的是「个人可拥有」后来觉得不够。真正的差异不是个人是 Knowledge ownership。OKF 管形状可交换。OpenViking 管规模可供给——当知识量超出扁平索引的边界它用分层摘要和结构化导航让 Agent 像操作文件系统一样渐进读取。Molio 管知识归属Agent、Wiki、Skill、Memory 四层交在用户手里本地 vault入库人在环页面可读可改。「属于」比「个人」更大。企业私有知识库同样适用。否则别人会觉得这只是 Obsidian 加了个 AI。实际上的定位是拥有自己的 AI 知识资产。底下共同仰赖的就是 Compilation 加 Evolution。对做个人或小团队知识系统的人我的建议其实很朴素。表示层尽量靠 OKF将来好交换。供给层别急着上向量全家桶先看有没有过那条百页边界。维护层宁可人在环也别留下没人认领的自动改写。作答纪律要写死依据不足口径冲突就明说不要补猜。知识系统最危险的时刻从来不是搜不到是搜到一条错的穿着正确信息的外衣被复述十遍。七 总结回到开头那份背调报告。下次再生成财务段落我不希望它「理解」材料。我希望它从编译好的实体页往上拼。这家公司这个期间营收多少单位是什么口径是什么出处在第几页。材料更新了页面跟着改。模型只负责组织不负责发明数字。有实证的直接引用写入。要确认的知道找谁。确认结果写回同一套知识。RAG 答完就忘每个答案都是一次性的现场发挥。编译好的 Wiki 会随时间长利息数字长在结构上下一次不用再赌模型会不会编。再往下说一层。过去的信息系统解决的是「记录发生过什么」。搜索系统解决的是「找到在哪里发生」。LLM-Wiki 想解决的是让 Agent 继承过去发生过一切。从检索走到编译这是AI系统接下来的方向核心竞争力不是检索更多资料而是把资料编译成可以持续进化的知识。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
RAG 找答案，Wiki 长知识
我们之前给客户做过一个背调系统方案。用 RAG 查企业材料自动生成背调报告。听起来很成熟检索加生成标准管线。报告出来了版式漂亮引用齐全语气笃定。不过财务数字是错的。营业收入、净利润整段数字对不上材料。有的是编的有的是把别处的数挪了过来。看起来比真的还真。关键数字不对报告就没法用。材料里明明写着数模型为什么不抄材料。后来我想明白了这不是 RAG 做错了什么。恰恰相反它很好地完成了自己的任务找到相关材料。问题在于我们让一个检索系统承担了知识管理系统的职责。RAG 是知识消费层不是知识生产层。财务数字这种东西不能靠模型「理解大意」必须钉死在结构里带单位带期间带口径带出处。搜得再好也只是把原料端上桌。怎么变成可以下锅的知识是另一件事。我后来把这个过程叫做「知识编译」。编译不是总结。写代码的人对这个类比不陌生源代码 ↓编译器 ↓机器码知识这边对应的是原始资料 ↓知识编译 ↓实体、关系、规则、约束、证据总结是给人看的一段话编译是给系统用的结构。机器码可以在机器上反复执行编译好的知识可以在 Agent 里反复调用每次不用重新理解一遍源代码。这两年大家默认堆 RAG。文档入库切块Embedding进向量库。提问时召回几个分块模型现场组答案。管线很漂亮。问题是它不保留结果。第 10 次提问和第 1 次一样从原始分块重新推导。前面九次的理解一点没剩下。Karpathy 关于 Agent 上下文管理的一系列讨论把问法换了一下。别在查询时重新发现知识把知识编译一次持续更新让它成为 Agent 可以长期访问的环境。社区后来把这类做法叫成 LLM-Wiki。我觉得多数人还是把它当成「又一种知识库产品」。这样看会看丢真正的变化。它不是产品是一种知识编译范式。一先看生命周期RAG 是单向的。原始资料切块Embedding检索回答结束。LLM-Wiki 是个环。原始资料进来理解、提取变成实体、关系、规则、适用条件、证据与冲突。编译成 Wiki 页面。持续增量维护。Agent 与人消费。消费时冒出新证据、新经验。再编译。回到维护那一步。区别就在这里RAG 优化的是这次怎么找到答案。LLM-Wiki 优化的是这次找到的东西能不能成为下一次的知识。知识复利只在闭环里成立。单向管线跑一万次也不会长出利息。对照着拆解知识能力其实分三层。Knowledge Retrieval我去哪里找。RAG、搜索、向量库都停在这。Knowledge Compilation找到的东西怎么变成结构化、可复用的知识。这才是 LLM-Wiki 的核心。Knowledge Evolution新信息进来后原知识怎么变。这是复利能不能转起来的关键。RAG 等于 Retrieval。LLM-Wiki 等于 Compilation 加 Evolution。二Compilation 到底在编什么它不是简单地写摘要完事。而是对着源资料编译至少要落下这几类东西实体。谁是谁。同一项目在不同文档里的别名要并成一条。关系。谁依赖谁谁适用谁。客户到产品到规则那条链以前散在四个目录里。规则。生效的口径是什么版本号是多少。条件。什么情况下适用。地区、时段、服务类型、例外。证据。每句话来自哪份材料第几节。冲突。两份材料不一致时双方观点都钉住标明待裁决。我们库自己就挂着这种冲突。同一晚的 Agent 发邮件事件团队第一次复盘把 Code Sandbox 加 smtplib 直连夸成 Plan B 优秀实践。过阵子写修订版把同一方案降成临时工答案换成 Agently Mail。两份都是正式材料但是观点和评价互相冲突了。这种事没法靠检索消掉。只能在编译时承认冲突存在双页标注留下解决方向等人或等新证据来裁。人类 Wiki 腐化多半就腐在这一步。修链接、对齐摘要、逐份比对、统一实体无尽头无即时回报团队一忙就扔扔了就没人再用。模型正适合干这个。它不会烦不会跳过某条交叉引用一次能改十几个文件。所以定义可以收准一点。LLM-Wiki是用模型承担人类无法持续完成的知识编译与维护工作。编译是前半程维护是后半程。很多人只抄了「用 Markdown 记笔记」没抄这两程那还是检索套壳。三Evolution 怎么转编译一次不够。材料会更新结论会过期新的经验会盖掉旧的判断。没有 EvolutionWiki 会变成一屋子过期档案。这里有个很容易被略过的判断。Evolution 不等于「自动改文档」。变更至少要有三样东西合并策略出处可追溯。合并策略回答的是新旧冲突时怎么办。是增量追加还是整体替换基石事实能不能被覆盖过期记忆要不要删掉。没有策略的自动改写等于让实习生拿橡皮擦直接改档案。出处回答的是这句话从哪来。可追溯回答的是上周改了什么能不能 diff。所以认真的知识库都会把版本控制写进交付方式用 git 分发让每一次知识变更都留下痕迹。知识库不是聊天记录得有 diff。一个工程实现给出的合并语义大致是这几种操作合并策略用途增量合并保留旧文追加或局部修改事实补充整体替换新结论覆盖旧结论判断更新只创建不覆盖保护基石事实口径、定义删除清过期记忆失效信息关联记忆之间双向挂钩建立图闭环长这样。对话完成任务提取变更按策略写入重建导航下次查询直接用上。每个动作都在给知识库进货。四规模上去了怎么喂给 Agent编译出几百个页面之后新问题来了Agent 怎么读得进去。靠一份总目录加链接导航大约撑到一百份源文档、数百个页面。再大光索引就能把上下文撑爆。但是撞墙的是导航方式不是「编译成 Wiki」这件事本身。工程上的答案是分层供给。不是把整库塞进上下文而是让 Agent 像翻文件系统一样从粗到细一层层看。层作用L0说清这是什么判断方向L1核心信息与结构导航理解脉络L2原文细节确认需要才碰Agent 的路径变成先扫 L0 判断哪些目录相关再读 L1 看结构确认需要才下到 L2。Token 从全量读降到按需读。检索也跟着变成结构化导航。先在粗粒度上定位相关目录再钻进目录里精查。比在一堆扁平分块里捞 top-k更不容易把无关目录的零散句子端上来。最近被频繁碰过的知识理应优先出列——上周的经验不该埋在三年前的文档底下。这里真正值得记住的不是某家的算法而是一个原则知识规模变大后供给方式要比检索算法先升级。先解决「Agent 一次该看多少、按什么顺序看」再谈召回率。五形状怎么统一知识编译完了长什么样各家原来各说各话。AGENTS.md、CLAUDE.md、Obsidian 加 Agent、各种 index.md 加 log.md 文件夹互不兼容。谷歌云 2026 年 6 月发的 OKFOpen Knowledge Format想定的就是这个形状。极度克制。一个 Bundle 就是个普通文件夹一个概念一份 Markdown上面 YAML frontmatter下面正文。强制字段只有一个 type。title、description、resource、tags、timestamp 都可选。路径即概念 IDtables/orders.md 的 ID 就是 tables/orders。文件之间用标准链接互引文件夹自己长成图。保留名两个。index.md 管渐进探索log.md 管变更历史。合规只要三件事。frontmatter 可解析type 非空index 和 log 若存在则结构正确。消费者必须容忍未知 type、缺字段、断链。一个文件不合格不影响整包。这套设计我觉得狠的地方在于它不定义内容模型只定义互操作最小公约数。type 取值完全由生产者定。要扩展加自定义键消费者该保留不该丢。在更大的栈里OKF 是内容层。llms.txt 是入口路标EntityMap 是实体声明OKF 是图书馆本体。MCP 管实时工具和活数据在旁边另一条道。一个是知识沉淀层一个是工具访问层互补不抢地盘。我们自己的 wiki 结构几乎是 OKF 的超集。分层 INDEX、log、frontmatter、双链都有。还多两样 OKF v0.1 没有的。hot.md 当近期上下文缓存。矛盾用 callout 钉在冲突双方页面上。OKF 悬而未决的「冲突没有合并语义」我们用最小机制先扛住了。六分清四层就不会把产品摆成对打到这里可以收一张图。层次解决什么代表Paradigm为什么要把资料编译成 WikiLLM-WikiFormat知识怎么表示、怎么流通OKFInfrastructure大规模知识怎么被 Agent 高效使用OpenVikingOwnership知识如何长期属于一个人或组织MolioLLM-Wiki 是范式。OKF 是表示与流通规范。OpenViking 是企业规模的基础设施实现。Molio 管的是知识归属。不在一个维度上竞争。这里我原先写的是「个人可拥有」后来觉得不够。真正的差异不是个人是 Knowledge ownership。OKF 管形状可交换。OpenViking 管规模可供给——当知识量超出扁平索引的边界它用分层摘要和结构化导航让 Agent 像操作文件系统一样渐进读取。Molio 管知识归属Agent、Wiki、Skill、Memory 四层交在用户手里本地 vault入库人在环页面可读可改。「属于」比「个人」更大。企业私有知识库同样适用。否则别人会觉得这只是 Obsidian 加了个 AI。实际上的定位是拥有自己的 AI 知识资产。底下共同仰赖的就是 Compilation 加 Evolution。对做个人或小团队知识系统的人我的建议其实很朴素。表示层尽量靠 OKF将来好交换。供给层别急着上向量全家桶先看有没有过那条百页边界。维护层宁可人在环也别留下没人认领的自动改写。作答纪律要写死依据不足口径冲突就明说不要补猜。知识系统最危险的时刻从来不是搜不到是搜到一条错的穿着正确信息的外衣被复述十遍。七 总结回到开头那份背调报告。下次再生成财务段落我不希望它「理解」材料。我希望它从编译好的实体页往上拼。这家公司这个期间营收多少单位是什么口径是什么出处在第几页。材料更新了页面跟着改。模型只负责组织不负责发明数字。有实证的直接引用写入。要确认的知道找谁。确认结果写回同一套知识。RAG 答完就忘每个答案都是一次性的现场发挥。编译好的 Wiki 会随时间长利息数字长在结构上下一次不用再赌模型会不会编。再往下说一层。过去的信息系统解决的是「记录发生过什么」。搜索系统解决的是「找到在哪里发生」。LLM-Wiki 想解决的是让 Agent 继承过去发生过一切。从检索走到编译这是AI系统接下来的方向核心竞争力不是检索更多资料而是把资料编译成可以持续进化的知识。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
