1. 从“找答案”到“长知识”RAG 与 Wiki 的定位差异1.1 为什么单靠 RAG 解决不了知识沉淀问题RAG 这个词在过去两年被聊烂了。检索增强生成说白了就是用户问一个问题系统先去知识库里捞相关片段再把片段塞进大模型的上下文让模型基于这些片段组织答案。这套流程解决的是“模型不知道你公司内部文档”的问题落地快、见效直接所以成了绝大多数知识问答项目的默认方案。但我在实际项目里反复遇到同一个尴尬RAG 的答案质量高度依赖检索命中的片段质量而片段质量又高度依赖原始文档的结构化程度。如果原始文档是一堆散落的 PDF、聊天记录、会议纪要检索出来的东西经常是断章取义模型拿着半截话硬编答案看着像那么回事细看全是坑。更麻烦的是RAG 每次问答都是一次性的用户问完就走了知识本身没有沉淀下次换个问法系统还得从头检索一遍之前踩过的坑、验证过的结论全都没留下来。这就是 RAG 的“找答案”定位——它是一个查询接口不是一个知识容器。你问它答你不问它就静止。对于高频、重复、需要长期积累的领域知识这种模式效率极低。1.2 Wiki 作为知识沉淀层的天然优势Wiki 不一样。Wiki 的核心不是“回答”而是“组织”。它把零散的信息按主题、层级、关联关系整理成页面每个页面可以被人反复编辑、补充、修正。一个成熟的 Wiki 页面往往凝聚了多人多次的贡献最终形成一个相对稳定、可追溯、可引用的知识节点。我拿游戏 Wiki 举例。像《英灵神殿》这种生存建造类游戏玩家需要查的东西极其琐碎某个材料在哪张地图刷、某个 Boss 的弱点是什么、某个建筑配方需要哪些前置。这些信息如果靠 RAG 去检索论坛帖子答案质量参差不齐因为论坛里大量是个人经验、版本过时内容、甚至错误攻略。但一个维护良好的 Wiki会把版本号、数据来源、验证时间都标清楚读者一眼就能判断可信度。所以 Wiki 的价值在于“长知识”——它不是一个问答机器而是一个持续生长的知识有机体。每一条新信息进来不是被塞进向量库就完事而是被归类、被关联、被验证最终成为整个知识网络的一部分。1.3 RAG 与 Wiki 结合的核心思路把 RAG 和 Wiki 放在一起看逻辑就清楚了RAG 负责“找”Wiki 负责“长”。RAG 从 Wiki 里检索内容来回答用户问题同时把用户的高频问题、新发现的缺口、验证过的结论反哺回 Wiki 页面。这样形成一个闭环用户提问 → RAG 检索 Wiki → 生成答案 → 答案中的新知识或修正点回流到 Wiki → Wiki 变得更完整 → 下次 RAG 检索质量更高。这个闭环的关键在于“回流”机制的设计。如果只是单向的 RAG 读 Wiki那 Wiki 就是个静态数据库迟早会过时。只有让 RAG 的使用过程反过来驱动 Wiki 的更新整个系统才有生命力。我在实际项目中试过几种回流方式后面会详细展开。2. LLM Wiki 与 Agent 的协作架构拆解2.1 LLM Wiki 到底是什么LLM Wiki 这个概念最近被 Karpathy 带火了一波但很多人理解偏了。它不是一个“用大模型自动写 Wiki”的工具而是一种“让大模型参与 Wiki 维护和消费”的范式。具体来说LLM Wiki 包含三层含义第一层Wiki 的内容结构对 LLM 友好。传统 Wiki 是给人看的页面里有大量导航、侧边栏、样式代码LLM 直接读会浪费大量 token 在无关内容上。LLM Wiki 要求页面内容本身是干净的、语义完整的、段落自包含的这样 RAG 检索出来的片段可以直接用不需要额外清洗。第二层LLM 参与 Wiki 的编辑和校验。比如自动检测页面之间的链接是否失效、内容是否矛盾、版本是否过时。我见过一个项目用 LLM 定期扫描 Wiki 里的所有页面发现同一个参数在不同页面写了不同数值自动生成冲突报告让人工确认。这种活人干起来极其枯燥LLM 干正合适。第三层Wiki 作为 Agent 的长期记忆载体。Agent 在执行任务过程中产生的中间结论、工具调用结果、用户反馈可以结构化地写回 Wiki形成可追溯的执行日志。这样下次遇到类似任务Agent 可以直接查 Wiki不用从头推理。2.2 Agent 在 RAGWiki 系统中的角色Agent 在这里不是简单的“调用 RAG 接口”而是承担了编排和决策的职责。一个典型的 Agentic RAG 流程是这样的用户提问 → Agent 判断问题类型 → 如果是事实型问题直接走 RAG 检索 Wiki → 如果是需要多步推理的问题Agent 拆解子问题分别检索 → 汇总结果后判断是否需要补充检索 → 生成答案 → 判断答案中是否有值得沉淀的新知识 → 如果有写入 Wiki 草稿区。这个流程里Agent 的核心能力是“判断”。判断问题类型、判断检索结果是否充分、判断是否需要二次检索、判断哪些内容值得沉淀。这些判断如果全靠规则写死维护成本极高交给 LLM 做又需要设计好 prompt 和约束条件。我试过用 AgentScope 2.0 搭这类流程它的优势在于把 Agent 的推理步骤和工具调用做了标准化封装RAG 检索、Wiki 读写、答案生成都可以作为独立工具注册进去Agent 根据任务需要自己决定调用顺序。这种“RAG as a Service”的思路比把 RAG 硬编码在业务逻辑里灵活得多。2.3 本体 RAG 与 GraphRAG 在 Wiki 场景下的取舍热词里出现了“ontology rag”和“rag graphrag llm wiki 本体rag”说明大家已经在思考如何让 RAG 更懂知识结构。传统 RAG 是扁平的向量检索把文本切成 chunk 后算相似度。这种方式在 Wiki 场景下有个明显问题Wiki 页面之间有大量的层级关系和交叉引用扁平检索会丢失这些结构信息。GraphRAG 的思路是把知识建成图节点是实体边是关系检索时沿着图遍历。比如用户问“某个 Boss 的弱点”GraphRAG 可以沿着“Boss → 属性 → 弱点”的路径找到答案而不是靠文本相似度碰运气。本体 RAG 更进一步预先定义好领域本体比如游戏里的“材料-配方-建筑”关系检索时按本体约束来。但我在实际项目里的体会是GraphRAG 和本体 RAG 的构建成本很高需要大量人工标注或高质量的自动抽取。对于 Wiki 这种本身已经有结构化层级的场景一个折中方案是“轻量级图增强”——不建全量知识图谱而是利用 Wiki 的页面链接和分类标签在检索时做一层图扩展。比如检索到某个页面后自动把该页面直接链接的子页面也纳入候选集这样既保留了结构信息又不用从头建图。3. 实操搭建 RAGWiki 知识系统的完整流程3.1 环境准备与工具选型先列一下我实际用过的技术栈供参考组件选型理由Wiki 引擎Wiki.js 或 Outline支持 Markdown 存储API 友好方便程序读写向量库Qdrant 或 Milvus支持元数据过滤适合按 Wiki 分类做检索约束Embedding 模型BGE-M3 或 text-embedding-3-large中文场景 BGE 系列性价比高多语言选后者Agent 框架AgentScope 2.0 或 LangChain4jAgentScope 对多 Agent 协作支持更好LangChain4j 适合 Java 栈LLM按需选择生成答案用强模型判断类任务可用小模型降本选 Wiki.js 的原因是它原生支持 Markdown 存储页面内容可以直接通过 API 拉取不需要解析 HTML。Outline 的 API 更现代但自部署稍麻烦。如果团队已经在用 Confluence也可以直接对接但 Confluence 的存储格式是富文本清洗成本高一些。向量库选 Qdrant 是因为它的 payload 过滤很灵活。Wiki 页面通常有分类标签比如“Boss”“材料”“建筑”检索时可以先用标签过滤再算相似度命中率明显提升。Milvus 在大规模场景下更强但小规模项目 Qdrant 部署更轻。3.2 Wiki 内容的结构化处理这一步是整个系统质量的地基。我踩过的最大坑就是直接把 Wiki 页面原文切 chunk 塞进向量库结果检索出来的片段经常缺上下文。比如一个页面写“该材料掉落自第三个 Boss”单独看这句话完全不知道“第三个 Boss”是谁。正确的做法是在切 chunk 之前先给每个页面做“自包含化”处理。具体操作提取页面标题和层级路径作为每个 chunk 的前缀。比如“英灵神殿 Wiki Boss 第三个 Boss 掉落物”这样即使 chunk 单独拿出来也知道自己在说什么。检测页面内的指代词把“该”“它”“这个”替换成具体实体名。这一步可以用 LLM 批量处理成本不高但效果显著。把页面内的表格和列表转成自然语言描述。表格直接切 chunk 会丢失行列关系转成“某材料的掉落概率是 30%掉落数量是 2-3 个”这种句子检索效果好得多。处理完的 chunk 存入向量库时payload 里带上页面 ID、分类标签、最后编辑时间。最后编辑时间很重要检索时可以给新内容更高权重避免过时信息干扰。3.3 RAG 检索链路的参数调优检索链路的核心参数就几个chunk 大小、top-k、相似度阈值、重排序策略。我逐个说下实际调优的经验。Chunk 大小Wiki 页面通常段落清晰我一般按语义段落切每段 200-400 字。太小会丢上下文太大检索精度下降。如果页面里有长表格单独处理成结构化数据不参与文本 chunk。Top-k初始检索建议取 10-20 个候选然后经过重排序取前 3-5 个塞进 LLM 上下文。直接取 top-3 容易漏取太多又浪费 token。重排序用 cross-encoder 模型比如 BGE-reranker对中文支持很好。相似度阈值这个参数最容易被忽略。我建议设一个最低阈值比如 0.6低于阈值的检索结果直接丢弃宁可让 Agent 判断“没找到”也不要硬塞给 LLM。硬塞的结果就是模型拿着不相关内容硬编答案质量极差。重排序策略除了 cross-encoder还可以加一层“时间衰减”——最后编辑时间越近的页面排序时加权越高。Wiki 场景下这个很实用因为很多领域知识更新快旧页面的信息可能已经过时。3.4 Agent 编排与工具注册Agent 这边我把能力拆成几个独立工具注册进去wiki_search(query, category_filter, top_k)检索 Wiki 内容wiki_read(page_id)读取指定页面全文wiki_write(page_id, content, section)写入或更新页面内容wiki_create(title, category, content)创建新页面answer_generate(question, context)基于上下文生成答案Agent 的 system prompt 里写清楚每个工具的用途和调用条件。比如“当检索结果相似度低于阈值时尝试用不同关键词重新检索”“当答案中包含 Wiki 中不存在的新信息时调用 wiki_create 创建草稿页”。这里有个关键设计wiki_write 和 wiki_create 默认写入“草稿区”不直接发布到正式 Wiki。草稿区的内容需要人工审核后才合并。这样做是为了防止 Agent 把错误信息写进正式知识库。我试过让 Agent 直接写正式区结果它把用户提问里的错误前提当成事实写了进去后来不得不加审核环节。3.5 知识回流机制的具体实现回流机制是整个闭环的核心。我的实现方式是每次 Agent 生成答案后额外跑一个“沉淀判断”步骤。用一个轻量 LLM 判断本次问答中是否产生了 Wiki 中不存在的新知识是否修正了 Wiki 中的错误是否发现了 Wiki 的覆盖缺口如果判断为“是”Agent 自动生成一个草稿页面或草稿段落附带来源标注来自哪次问答、哪个用户、什么时间。草稿进入审核队列人工确认后合并到正式 Wiki。这个机制跑起来后我发现两个有意思的现象一是高频问题会自然催生出高质量的 Wiki 页面因为同一个问题被问多次每次的答案片段会被 Agent 合并整理二是用户提问中的错误前提会被 Agent 标记出来反过来提醒 Wiki 维护者补充“常见误解”章节。4. 常见问题与排查技巧实录4.1 检索命中率低的排查思路RAG 项目最常被问的就是“为什么检索不到”。我一般按这个顺序排查先看 chunk 质量。把检索失败的 query 对应的 chunk 拉出来看是不是切得太碎、缺上下文、或者本身内容就不完整。我遇到过最离谱的情况是 Wiki 页面里有个表格切 chunk 时把表头切掉了剩下的数据行完全不知道在说什么。再看 embedding 模型是否匹配。中文场景用英文模型效果会差很多多语言场景要确认模型支持目标语言。BGE-M3 在多语言上表现不错但如果领域术语特别多可能需要微调。然后看相似度阈值是不是设太高。有些项目为了“精准”把阈值设到 0.8结果大量相关内容被过滤掉。我建议先用低阈值跑一批测试 query看召回情况再逐步调高。最后看 query 本身。用户提问往往很短、有错别字、有口语化表达。可以在检索前加一步 query 改写用 LLM 把用户问题改写成更适合检索的形式。比如用户问“那个掉材料的 boss 在哪”改写成“材料掉落 Boss 位置”检索命中率会高很多。4.2 Agent 执行中断的常见原因热词里有个“agent execution terminated due to error”这个我太熟了。Agent 跑着跑着挂了常见原因就几个工具调用参数格式错误。Agent 生成的 JSON 参数不符合工具定义的 schema直接报错。解决办法是在工具定义里写清楚参数类型和示例并在 Agent prompt 里强调“严格按照 schema 生成参数”。循环调用。Agent 反复调用同一个工具陷入死循环。需要设置最大调用次数限制超过就强制中断并返回当前结果。上下文超长。Agent 的对话历史太长超过模型上下文窗口。解决办法是定期做上下文压缩把早期对话总结成摘要。工具返回结果过大。比如 wiki_read 读了一个超长页面直接把上下文撑爆。工具实现里要加截断逻辑返回结果超过一定长度就只返回摘要和关键段落。4.3 Wiki 内容冲突的检测与处理Wiki 多人维护时内容冲突是必然的。我见过同一个参数在三个页面写了三个不同数值读者完全懵。用 LLM 做冲突检测的思路是定期扫描所有页面提取其中的事实性陈述数值、日期、名称等按实体分组。同一实体的不同数值如果出现在不同页面标记为潜在冲突。然后人工确认哪个是正确的或者标注“版本差异”。这个检测不用做得很复杂先用规则提取数值和实体再用 LLM 判断是否真的冲突。我试过一个简单实现把所有页面的“数值单位上下文”抽出来按上下文相似度聚类同一簇里数值不同的就是冲突。准确率大概八成剩下两成人工过一遍就行。4.4 性能与成本优化技巧RAGWiki 系统跑起来后成本和延迟是两个大头。我总结了几条实用技巧Embedding 缓存。Wiki 页面更新频率不高embedding 结果可以缓存页面没变就不用重新算。这一条能省掉大量重复计算。分级检索。先用轻量模型做粗筛再用强模型做精排。粗筛可以用 BM25 或小 embedding 模型精排用 cross-encoder。这样比全程用强模型快很多成本也低。答案缓存。高频问题的答案可以缓存设置合理的过期时间。Wiki 页面更新时关联的缓存自动失效。Agent 推理降本。判断类任务比如“是否需要二次检索”“是否值得沉淀”用便宜的小模型生成类任务用强模型。这样整体成本能降一半以上。5. 从项目实践看 RAG 与 Wiki 的长期演进5.1 知识库的“活”与“死”我越来越觉得一个知识库的价值不在于它存了多少内容而在于它是否“活”。死的知识库是静态的建好之后就慢慢过时最后没人用。活的知识库是动态的每次使用都在给它注入新信息每次问答都在帮它修正错误。RAGWiki 这个组合之所以有意思就是因为它给了知识库一个“活”的机制。RAG 是使用入口Wiki 是沉淀容器Agent 是连接两者的桥梁。用户每次提问不仅是在消费知识也是在贡献知识——前提是回流机制设计对了。5.2 从“检索增强”到“知识增强”传统 RAG 叫“检索增强生成”重点在“检索”。但我觉得下一步的重点会转向“知识增强”——不是简单地检索片段塞给模型而是让模型真正理解知识的结构、关系、版本、可信度。这需要几个能力知识的结构化表示本体、图谱、知识的可信度评估来源、验证时间、冲突检测、知识的动态更新回流、审核、版本管理。这些能力单靠向量库和 LLM 不够需要一套完整的知识工程体系。5.3 给不同阶段团队的建议如果你刚开始做 RAG 项目我的建议是先别碰 GraphRAG 和本体 RAG把基础 RAG 跑通把 Wiki 内容整理干净把检索命中率提上去。基础不牢上再复杂的架构都是空中楼阁。如果你已经有稳定的 RAG 系统下一步可以加回流机制让使用过程驱动知识沉淀。这一步的投入产出比很高而且能显著提升用户粘性——用户发现自己提的问题被整理进了 Wiki会有参与感。如果你在考虑 Agent 编排建议从单 Agent 开始把工具注册和调用流程跑顺再考虑多 Agent 协作。多 Agent 的复杂度不是线性增长的调试成本很高没有明确收益不要轻易上。最后分享一个我在实际项目里验证过的小技巧在 Wiki 页面底部加一个“本页被 RAG 引用次数”的统计。这个数字会激励维护者更新页面——被引用越多说明越重要越值得花时间完善。同时也能帮 RAG 系统识别哪些页面是核心节点检索时可以给更高权重。一个小改动同时解决了激励和排序两个问题。