1. 从“RAG 找答案Wiki 长知识”说起这套组合拳到底在解决什么问题第一次看到“RAG 找答案Wiki 长知识”这个说法我脑子里蹦出来的画面特别具体一个刚接手新项目的人打开对话框问“这个模块的鉴权逻辑在哪”系统三秒钟甩给他一段代码位置和解释等他闲下来想系统了解整个架构时又切到另一个页面像翻一本活的百科全书一样从入口一路读到边界条件。这两件事看起来都是“问问题”但底层诉求完全不同——前者要的是精准命中后者要的是体系化沉淀。RAG也就是检索增强生成核心动作是“找”。你给它一个问题它去知识库里捞最相关的片段塞进大模型的上下文让模型基于这些片段回答。它的强项是有据可查、答案可溯源适合处理“这个接口的参数是什么”“上次那个报错怎么解的”这类点状查询。但 RAG 有个天然短板它不负责“长知识”。你问十次它答十次每次都是碎片彼此之间不串联用户脑子里还是散的。Wiki 恰好补上这一环。Wiki 的本质是结构化、可链接、可演进的知识网络。一个页面可以链到另一个页面一个概念可以展开成子概念版本可以迭代讨论可以留痕。它解决的是“我想系统搞懂一件事”的需求。但传统 Wiki 的问题是写起来累维护更难时间一长就变成“文档坟场”没人愿意翻。所以“RAG 找答案Wiki 长知识”这句话的精髓不是二选一而是让两者互为输入输出。RAG 在回答问题的过程中把高频问题、优质答案、关联片段沉淀回 WikiWiki 作为高质量语料又反过来提升 RAG 的检索命中率和回答质量。这套思路在 LLM Wiki、Agentic RAG、Ontology RAG 这些近期热词里反复出现本质上都是在解决同一个问题知识怎么从“死文档”变成“活资产”。这篇文章适合谁看如果你正在搭 RAG 知识库、维护团队 Wiki、做 Agent 开发或者单纯被“文档没人看、问答答不准”折磨过那接下来的内容应该能帮你少走几个弯路。我会从整体设计、核心细节、实操落地、问题排查四个层面把这套组合拳拆开讲清楚尽量做到你看完就能照着搭。2. 整体设计与思路拆解为什么不是“RAG 替代 Wiki”而是“RAG 喂养 Wiki”2.1 先想清楚你的知识到底分几层很多人一上来就纠结“用哪个向量库”“切多大 chunk”但真正决定成败的是知识分层。我习惯把知识分成三层原子层单个事实、参数、报错码、API 签名。这层最适合 RAG检索粒度细答案短平快。关系层概念之间的依赖、调用链、因果、版本演进。这层需要 Wiki 的链接和结构化页面来承载。意图层用户到底想干什么是查、是学、还是决策。这层靠 Agent 来编排决定走 RAG 还是走 Wiki。“RAG 找答案Wiki 长知识”之所以成立就是因为原子层和关系层天然互补。你让 RAG 去维护关系它会丢你让 Wiki 去扛高频查询它会慢。分层之后各干各的再用 Agent 串起来整个系统就顺了。2.2 方案选型为什么我倾向“Wiki 为主干RAG 为入口”市面上常见的做法有两种一种是以 RAG 为中心Wiki 只是语料来源另一种是以 Wiki 为中心RAG 作为查询加速层。我实测下来更推荐后者原因有三第一可维护性。Wiki 页面是人可读、可编辑的出了问题能直接改。RAG 的向量库是黑盒你很难定位“为什么这条没检索到”。以 Wiki 为主干等于把真相源放在明处。第二可演进性。知识会变版本会迭代。Wiki 天然支持版本管理和讨论RAG 的索引重建成本高。让 Wiki 做主干RAG 定期从 Wiki 重建索引逻辑更干净。第三Agent 友好。Agent 需要的不只是“一段文本”而是“这个文本属于哪个页面、关联哪些概念、置信度多少”。Wiki 的页面结构和链接关系正好给 Agent 提供了这些元信息。Ontology RAG 之所以火就是因为它把本体结构引入了检索而 Wiki 本身就是最轻量的本体载体。2.3 数据流设计从“问答”到“沉淀”的闭环我画过很多版架构图最后稳定下来的数据流大概是这样用户提问Agent 先判断意图是点状查询还是体系学习。点状查询走 RAG检索 Wiki 索引返回带来源的答案。体系学习走 Wiki直接推荐相关页面路径支持逐层展开。无论走哪条路高价值问答对会被记录由人工或模型辅助整理成 Wiki 草稿。Wiki 更新后触发索引重建RAG 的语料同步刷新。这个闭环的关键在于第 4 步。很多团队做到第 3 步就停了结果 RAG 永远在答重复问题Wiki 永远没人写。把“问答沉淀”做成自动或半自动流程才是这套方案真正跑起来的分水岭。提示沉淀环节不要追求全自动。我试过让模型直接写 Wiki结果格式乱、事实错、链接断。后来改成“模型生成草稿 人工审核合并”质量稳定很多。2.4 和 Agentic RAG、LLM Wiki 的关系Agentic RAG 强调的是“检索不是一步而是多步推理中的一环”。LLM Wiki 强调的是“用模型辅助维护 Wiki”。这两者和“RAG 找答案Wiki 长知识”是一脉相承的Agentic RAG 负责“怎么找得更准”比如多轮检索、查询改写、结果重排。LLM Wiki 负责“怎么长得更快”比如自动摘要、自动链接、自动分类。两者交汇的地方就是知识从查询中沉淀从沉淀中反哺查询。理解了这一层后面的实操就不会跑偏。3. 核心细节解析与实操要点把“找”和“长”都做扎实3.1 RAG 侧检索命中率上不去的三个真实原因RAG 最容易被吐槽的就是“答非所问”。我排查过几十个案例发现根因基本集中在三处第一chunk 切得太碎或太整。切太碎语义不完整检索到半句话切太整噪声太多模型抓不住重点。我的经验是技术文档按“标题 段落”切每块 300 到 600 字对话记录按“问答对”切每对独立成块。别迷信固定字数结构优先。第二查询和语料不在一个语义空间。用户问“登录失败怎么办”语料里写的是“鉴权异常处理流程”。字面不匹配向量也未必近。解决办法是加一层查询改写用模型把口语问题转成文档里的术语再检索。这一步在 Agentic RAG 里几乎是标配。第三没有重排。向量检索召回 top 20直接取前 3 塞给模型很容易漏掉真正相关的那条。加一个轻量重排模型把 top 20 重新打分取 top 5命中率提升非常明显。实测下来重排带来的收益比换更大的嵌入模型还高。3.2 Wiki 侧让页面“活”起来的四个习惯Wiki 变坟场通常不是因为没人写而是因为写了没人用、用了不更新。我总结的四个习惯能显著延长 Wiki 的寿命一页一概念别把十个知识点塞进一个页面。页面越聚焦链接越清晰RAG 切块也越干净。首段即摘要每个页面开头用两三句话讲清“这是什么、解决什么问题、适合谁看”。这段会被 RAG 优先检索也会被用户优先阅读。强制互链新页面必须至少链到一个已有页面且被至少一个已有页面链接。孤岛页面等于不存在。标注时效每个页面顶部写清“最后更新日期”和“适用版本”。过时知识比没有知识更危险。注意Wiki 的命名规范要统一。我见过同一个概念有五种叫法RAG 检索时直接裂开。建议维护一个术语表所有页面标题和别名都从术语表取。3.3 连接层Agent 怎么决定“走 RAG 还是走 Wiki”这是整套方案里最容易被忽略、但最影响体验的一环。我的做法是给 Agent 一个简单的路由规则用户意图判断信号路由目标点状查询问句短、含具体名词、要“是什么/在哪/怎么改”RAG体系学习问句含“整体/架构/流程/入门”、要“讲讲/梳理”Wiki混合意图先问点再问面或问面时带具体例子先 RAG 后 Wiki不确定信号模糊先 RAG答案末尾附 Wiki 相关页面推荐这个规则不复杂但能覆盖八成场景。关键是答案末尾永远附上 Wiki 链接让用户有机会从“找答案”自然过渡到“长知识”。3.4 语料治理RAG 和 Wiki 共用的地基不管走哪条路语料质量都是地基。我踩过的坑包括PDF 解析丢表格、Markdown 标题层级混乱、代码块被当正文切碎、图片说明丢失。后来固定了一套预处理流程统一转成 Markdown保留标题层级。表格转成结构化文本别直接扔原始格式。代码块单独标记检索时可按需过滤。图片配文字说明说明文字进语料。每篇文档打上来源、版本、更新时间三个元数据。这套流程看起来笨但跑通之后RAG 的命中率和 Wiki 的可读性都会上一个台阶。4. 实操过程与核心环节实现从零搭一套“找答案 长知识”的系统4.1 环境与工具选型够用就好别过度设计我搭过三版第一版追求“全栈自研”结果三个月没上线第二版堆了一堆框架维护成本爆炸第三版回归简单反而最稳。推荐的工具组合如下Wiki 引擎选支持 Markdown、版本管理、API 访问的即可。团队小就用现成的协作平台团队大再考虑自建。向量库数据量在百万级以内本地文件型向量库完全够用别一上来就上集群。嵌入模型中文场景优先选中文语料训练充分的模型别盲目追大。重排模型轻量级即可重点是快别让重排成为瓶颈。Agent 框架选支持工具调用、多步推理、状态管理的。AgentScope 2.0 这类支持 RAG as Service 的思路值得参考但不必照搬。提示工具选型的核心原则是“每一层都能单独替换”。Wiki、向量库、模型、Agent 框架之间用标准接口隔开将来换任何一个都不影响其他层。4.2 第一步把 Wiki 整理成 RAG 友好的语料这一步决定了后面所有环节的上限。具体操作导出 Wiki 全量页面为 Markdown保留目录结构。按页面生成“页面摘要块”内容为首段 标题层级 出链列表。按段落生成“内容块”每块附带所属页面、上级标题、前后块 ID。所有块打上元数据页面路径、更新时间、版本、标签。存入向量库同时保留原始文本用于重排和展示。这里的关键是双层索引摘要块用于粗召回内容块用于精定位。实测下来比单层索引的命中率高出一截。4.3 第二步搭 RAG 查询链路查询链路的完整流程# 伪代码示意实际按所选框架调整 def rag_query(question): # 1. 查询改写 rewritten rewrite_query(question) # 2. 粗召回 candidates vector_search(rewritten, top_k20) # 3. 重排 ranked rerank(question, candidates, top_k5) # 4. 组装上下文 context build_context(ranked) # 5. 生成答案 answer llm_generate(question, context) # 6. 附来源 return attach_sources(answer, ranked)每一步都有讲究。查询改写要保留原意别改着改着跑偏粗召回可以多路并行比如向量 关键词各召一批再合并重排要看原始问题不是改写后的问题组装上下文要控制长度别把模型上下文塞爆附来源要精确到段落方便用户核对。4.4 第三步让 Agent 编排“找”和“长”Agent 的核心职责是判断意图、选择路径、记录沉淀。我用的编排逻辑接收用户输入先做意图分类。点状查询走 RAG返回答案 来源 相关 Wiki 页面。体系学习走 Wiki返回页面路径 摘要 推荐阅读顺序。混合意图先 RAG 给具体答案再 Wiki 给体系入口。无论哪种记录问答对标记是否高价值。高价值问答对进入沉淀队列等待整理成 Wiki 草稿。这里有个细节沉淀队列要有优先级。被反复问到的、被用户点赞的、涉及核心概念的优先沉淀。别什么都往 Wiki 塞否则 Wiki 会变成垃圾场。4.5 第四步沉淀闭环让 Wiki 真的“长”起来沉淀流程我建议做成半自动模型根据问答对生成 Wiki 草稿包含标题、摘要、正文、相关链接。草稿进入审核队列由熟悉该领域的人审核。审核通过后合并进 Wiki触发索引重建。重建完成后RAG 自动获得新语料。这个流程跑顺之后你会发现一个正向循环问得越多Wiki 越厚Wiki 越厚答得越准答得越准用户越愿意问。4.6 参数计算与选择几个关键数字的来由chunk 大小300 到 600 字。太小语义不全太大噪声多。技术文档偏小叙述性文档偏大。粗召回 top_k20 左右。太少容易漏太多重排压力大。重排 top_k5 左右。够模型生成又不至于超上下文。上下文长度控制在模型上限的 60% 到 70%留出余量给生成。索引重建频率Wiki 更新后触发或每天定时一次。别实时重建成本高且没必要。这些数字不是拍脑袋是多次实测后的经验值。你可以根据自己的语料特点微调但别偏离太远。5. 常见问题与排查技巧实录那些文档里不会写的坑5.1 检索命中率忽高忽低怎么排查先别急着换模型按这个顺序查看语料是不是有重复内容、过时内容、格式混乱内容。看切块随机抽几个块读一遍看语义是否完整。看查询把用户原始问题和改写后的问题都打出来对比。看召回把 top 20 打出来人工判断真正相关的排在第几。看重排对比重排前后的顺序看重排是否帮倒忙。八成问题出在前两步。语料和切块没做好后面怎么调都是白搭。5.2 Wiki 没人写、没人更新怎么办这是组织问题不是技术问题。我的经验是降低门槛提供模板提供一键从问答生成草稿的入口。给反馈谁写的页面被 RAG 引用了给个通知让人有成就感。定责任每个核心页面指定维护人过期未更新自动提醒。做减法定期归档过时页面别让 Wiki 无限膨胀。注意别用考核逼人写 Wiki写出来的全是废话。要让写 Wiki 变成“顺手的事”而不是“额外的活”。5.3 Agent 路由错了怎么调路由错误通常表现为该走 RAG 的走了 Wiki该走 Wiki 的走了 RAG。排查思路把意图分类的输入输出打出来看分类是否合理。检查分类规则是否覆盖了长尾表达。加一个“兜底策略”不确定时先走 RAG答案末尾附 Wiki 推荐。收集误判案例定期更新分类规则或微调分类模型。路由不需要百分百准但要有兜底别让用户卡死。5.4 常见问题速查表问题现象可能原因排查动作解决方向答案答非所问语料噪声大、切块不合理抽查语料和切块清洗语料、调整切块检索不到相关内容查询与语料语义不匹配对比原始查询和改写查询加查询改写、加关键词召回答案遗漏关键信息召回 top_k 太小、重排有偏打印召回列表人工判断增大 top_k、换重排模型Wiki 页面无人访问入口太深、没有推荐看访问日志在 RAG 答案末尾附链接沉淀内容质量差全自动生成未审核抽查草稿改半自动、加人工审核索引更新后效果变差新语料污染、重建参数变了对比更新前后回滚、检查新语料质量5.5 几个独家避坑技巧别在周五下午重建索引。出问题没人修周末过不安生。保留旧索引至少一周。新索引效果不对能快速回滚。给 RAG 答案加“置信度”提示。低置信度时明确告诉用户“可能不准建议核对来源”。Wiki 页面标题别用生僻缩写。RAG 检索时标题权重高生僻缩写等于自断命中率。定期做“盲测”。找不熟悉系统的人问十个问题看答得怎么样比你自己测准得多。6. 我在这套方案里踩过的三个大坑第一个坑是过度依赖向量检索。早期我所有查询都走向量结果遇到专有名词、错误码、版本号就歇菜。后来加了关键词召回和查询改写才稳住。向量擅长语义关键词擅长精确两者不是替代关系是互补关系。第二个坑是Wiki 和 RAG 各搞各的。有一段时间Wiki 是 WikiRAG 是 RAG语料不同步答案和页面经常打架。后来强制“Wiki 为真相源RAG 索引从 Wiki 重建”才解决一致性问题。这个原则看起来简单执行起来需要纪律。第三个坑是沉淀环节全自动。我试过让模型直接把问答对写成 Wiki 页面结果格式五花八门事实错误不少链接乱指。后来改成“模型生成草稿 人工审核”效率虽然低一点但质量可控。知识这东西宁可慢一点也别错。最后分享一个小技巧在 RAG 答案的末尾永远附上一句“想系统了解这块可以看这几个 Wiki 页面”。这句话看起来不起眼但它是从“找答案”到“长知识”的桥梁。用户点进去一次就可能从一次性查询变成长期学习者Wiki 的访问量和更新动力也会跟着上来。这套组合拳能不能跑通往往就藏在这些细节里。