1. 从"搜不到"到"问得准"：RAG 和 Wiki 到底在解决什么

很多人第一次接触 RAG，是因为遇到了一个非常具体的困境：手头有一堆文档、笔记、产品手册、会议纪要，想让大模型帮忙回答问题，结果它要么胡编，要么说"我不知道"。你把文档粘贴进对话框，它倒是能答，但文档一长就超上下文，而且每次都要重新贴，效率极低。RAG 就是冲着这个场景来的——检索增强生成，先检索、再生成，让模型基于你给的资料回答，而不是靠它自己"回忆"。

但 RAG 单独用，很快会撞上另一堵墙。检索出来的东西是碎片化的，模型拿到几段文本，能回答"这个参数是多少"，却回答不了"这个模块在整个系统里处于什么位置""这个决策和三个月前那次调整有什么关系"。这时候 Wiki 的价值就出来了。Wiki 不是简单的文档堆叠，它是一张有结构、有链接、有层级的知识网络。RAG 负责"找答案"，Wiki 负责"长知识"——前者解决即时问答，后者解决长期积累。

我自己的理解是：RAG 是检索层，Wiki 是知识层，LLM 是推理层。三者叠在一起，才构成一个能持续运转的知识系统。单独看任何一个，都会觉得"好像能用，但总差点意思"。这篇内容就是围绕这个组合展开，把 RAG 的检索逻辑、Wiki 的结构化组织、以及两者怎么和 Agent 编排结合起来，拆开讲清楚。适合已经在用大模型、但觉得知识管理一团乱的人，也适合刚接触 RAG、想知道它和传统搜索区别在哪的人。

2. RAG 的检索链路：从"关键词匹配"到"语义召回"

2.1 为什么传统搜索在知识问答场景里不够用

传统搜索的核心是关键词匹配。你搜"部署流程"，它找包含"部署"和"流程"这两个词的文档。问题是，知识问答里用户不会这么规整地提问。他可能问"这东西怎么上线"，也可能问"发布步骤是什么"，甚至问"我改完代码之后要做什么才能让别人用上"。这些表达和文档里的"部署流程"在字面上完全不重叠，但语义上是一回事。

这就是 RAG 里向量检索要解决的问题。把文档切块、编码成向量、存进向量库，查询时把问题也编码成向量，算余弦相似度，召回语义最接近的片段。关键词匹配看的是"字面像不像"，向量检索看的是"意思近不近"。两者结合，就是常说的混合检索。

我实测下来，纯向量检索在专有名词、型号、代码标识符上容易翻车。比如你问"ESP32-CAM 的引脚定义"，向量检索可能召回一堆讲摄像头的通用内容，反而把真正包含引脚表的那段漏掉。所以生产环境里，混合检索基本是标配：一路 BM25 做关键词召回，一路向量做语义召回，最后用 RRF（倒数排名融合）合并结果。

2.2 文档切块：RAG 效果的第一道分水岭

很多人 RAG 效果差，根因不在模型，在切块。切块策略直接决定检索质量。切得太碎，一个完整概念被拆成好几段，召回时只拿到半截；切得太大，一个块里混了好几个主题，向量被"平均"掉，语义变得模糊。

常见的切块方式有这么几种：

我自己的经验是：Wiki 类内容天然适合按标题层级切。因为 Wiki 本身就是按主题组织的，每个小节就是一个相对独立的知识单元。切块时把父级标题拼进块内容里，比如"## 3. 部署流程 > ### 3.2 灰度发布"，这样检索出来的片段自带上下文，模型理解起来准确得多。

还有一个容易被忽略的点：重叠窗口。相邻两个块之间保留 10%-20% 的重叠内容，能有效避免"答案刚好被切在边界上"的情况。这个参数不用调得太精细，10% 起步，效果不明显再往上加。

2.3 检索命中率上不去，先查这三个地方

RAG 项目做出来，最常被问的就是"命中率怎么样"。命中率低，别急着换模型，先按顺序排查：

第一，看切块。把召回失败的 query 拿出来，看它对应的正确文档块长什么样。如果正确内容被切散了，或者块里混了无关内容，那就是切块问题。

第二，看 embedding 模型。不同 embedding 模型对中文、对技术术语的表现差异很大。有些模型在通用语料上表现好，但遇到代码、型号、专有名词就拉胯。换一个在技术语料上训练过的模型，命中率可能直接上一个台阶。

第三，看查询改写。用户的问题往往口语化、省略多。在检索前加一步 query rewriting，把"这东西怎么上线"改写成"部署流程 发布步骤 上线操作"，召回效果会明显改善。这一步可以用小模型做，成本很低。

提示：命中率不是越高越好。召回太多无关内容，反而会干扰生成。一般 top-k 取 3-5 就够，配合重排序（rerank）把最相关的排前面。

3. Wiki 作为知识底座：让 RAG 有"根"可依

3.1 Wiki 和普通文档库的本质区别

普通文档库是"文件夹 + 文件"的结构，靠目录树组织。Wiki 不一样，它的核心是双向链接。每个页面不仅知道自己属于哪个目录，还知道自己被哪些页面引用、又引用了哪些页面。这种网状结构，恰好是 RAG 最需要的。

为什么？因为 RAG 检索出来的是一个一个孤立的块，模型看到的是碎片。但如果这些块背后有 Wiki 的链接关系，就能做上下文扩展：召回一个块之后，顺着链接把它的父页面、相关页面一起拉进来，给模型一个更完整的知识背景。这就是从"检索片段"升级到"检索知识单元"。

我见过一个很典型的场景：技术 Wiki 里有一个"故障排查"页面，链接到"日志规范"和"监控指标"两个页面。用户问"服务报错怎么查"，RAG 召回"故障排查"页面，如果只给这一段，模型只能答个大概。但如果顺着链接把日志规范和监控指标也带上，模型就能给出"先看哪个日志、再查哪个指标"的具体步骤。差别非常大。

3.2 LLM Wiki：让模型参与知识整理

传统 Wiki 靠人维护，问题是人懒、更新慢、格式不统一。LLM Wiki 的思路是：让大模型参与知识的抽取、归纳和链接生成。你给它一堆原始材料——会议记录、聊天记录、代码注释、工单——它帮你提炼成结构化页面，自动打标签、自动建链接。

具体怎么做？我的做法是分三步：

1. 抽取：把原始材料按主题切分，每个主题生成一个草稿页面，包含摘要、关键点、相关实体。
2. 归并：把草稿页面和已有 Wiki 页面做相似度比对，能合并的合并，不能合并的新建页面。
3. 链接：扫描所有页面，找出实体共现关系，自动生成双向链接。

这三步里，归并是最难的。模型很容易把两个相关但不同的概念合并成一个，导致信息丢失。我的处理方式是：归并前先让人确认，或者设置一个相似度阈值，超过阈值才自动合并，介于中间的人工介入。宁可多建几个页面，也不要错误合并。

3.3 本体 RAG：给知识加上"骨架"

热词里出现了"ontology rag""本体 rag"，这个概念值得说一下。本体（Ontology）在这里指的是领域内的概念体系：有哪些实体、实体之间有什么关系、关系有什么约束。把本体引入 RAG，等于给检索加了一层"语义导航"。

举个例子。在一个产品知识库里，本体可能定义：产品属于某个系列，系列属于某个品类，品类有对应的配置项。用户问"这个系列的配置项有哪些"，普通 RAG 靠向量召回，可能召回一堆零散内容。本体 RAG 则可以先定位到"系列"这个实体，再顺着"属于"关系找到品类，再顺着"有配置项"关系找到具体配置。检索路径是确定的，结果也更完整。

本体 RAG 的落地成本比普通 RAG 高，需要先建本体。但对于知识结构稳定、查询模式固定的场景——比如产品手册、法规文档、设备维护手册——投入是值得的。建本体不用一上来就搞得很复杂，先把核心实体和主要关系理出来，后面再逐步扩展。

4. Agent 编排：让 RAG 和 Wiki 动起来

4.1 为什么需要 Agent 来编排

RAG 和 Wiki 各自能干活，但组合起来需要"调度"。用户问一个问题，系统要先判断：这个问题该查 Wiki 还是查向量库？查完之后要不要顺着链接扩展？扩展几层？答案生成后要不要回写 Wiki？这些判断，靠固定流程写死很僵硬，靠 Agent 来做就灵活得多。

Agent 在这里的角色是编排者：它理解用户意图，决定调用哪些工具（检索、链接扩展、页面生成），按什么顺序调用，拿到结果后怎么整合。热词里的"agentic rag"说的就是这个方向——RAG 不再是单次检索，而是 Agent 驱动的一个多步过程。

4.2 一个可落地的 Agent 编排流程

我拿一个实际场景来拆：用户问"上次那个接口超时的问题怎么解决的"。

Agent 的编排流程大致是这样：

1. 意图识别：判断这是"历史问题查询"，需要查 Wiki 里的故障记录。
2. 检索：先在 Wiki 里搜"接口超时"，拿到相关页面列表。
3. 链接扩展：选中最相关的页面，顺着链接拉出关联的"解决方案"页面和"监控告警"页面。
4. 生成：把检索到的内容整合，生成回答，标注来源页面。
5. 回写：如果这次问答产生了新的解决思路，Agent 可以提议更新 Wiki 页面。

这个流程里，第 3 步和第 5 步是普通 RAG 没有的。第 3 步让答案更完整，第 5 步让知识库持续生长。这就是"RAG 找答案，Wiki 长知识"的完整闭环。

4.3 Agent 框架选型：别被"全家桶"绑架

现在 Agent 框架很多，LangChain、LangGraph、AgentScope、还有各种轻量方案。选型时容易陷入一个误区：觉得功能越多越好，结果引入一堆用不上的依赖，调试起来痛苦不堪。

我的建议是按需选型：

• 如果只是简单的"检索 + 生成"，不需要复杂编排，直接用最基础的调用链就行，不用上框架。
• 如果需要多步推理、条件分支、工具调用，再考虑 LangGraph 这类支持状态机的框架。
• 如果团队已经在用某个生态（比如 Spring AI、LangChain4j），优先复用现有技术栈，减少学习成本。

框架是手段不是目的。我见过用最朴素的 Python 脚本搭出来的 RAG 系统，效果比用重型框架搭的还好，因为逻辑清晰、调试方便。别为了"用框架"而用框架。

注意：Agent 编排里最容易出问题的是循环和超时。Agent 调用工具时如果陷入死循环，或者某个工具响应太慢，整个流程就卡住了。一定要设置最大步数和超时时间，并且有降级方案——比如检索失败时直接返回"未找到相关内容"，而不是无限重试。

5. 从零搭一套 RAG + Wiki 系统的实操路径

5.1 环境准备与最小可用版本

先说最小可用版本需要什么：一个向量库、一个 embedding 模型、一个 LLM、一份文档。向量库用 FAISS 或 Chroma 都行，本地跑不需要额外服务。embedding 模型选一个中文表现好的，LLM 用你手头能调用的就行。

最小流程：

# 伪代码示意，实际按你的技术栈调整 docs = load_documents("wiki_export/") chunks = split_by_heading(docs, overlap=0.15) vectors = embed(chunks) index = build_index(vectors) def ask(question): q_vec = embed(question) hits = index.search(q_vec, top_k=5) context = merge_with_links(hits) return llm.generate(question, context)

这个版本跑通之后，再逐步加东西：加混合检索、加重排序、加链接扩展、加 Agent 编排。不要一上来就搭大系统，先让最小闭环跑起来，再迭代。

5.2 Wiki 内容的导出与结构化处理

Wiki 系统一般都能导出，格式可能是 Markdown、HTML 或 XML。导出后要做几件事：

• 保留标题层级：这是切块的依据，也是上下文来源。
• 提取链接关系：把页面间的链接抽出来，存成图结构，供检索时扩展用。
• 清理格式噪音：导航栏、页脚、模板文字这些要去掉，否则会污染向量。

我处理过一个 Confluence 导出的 Wiki，里面每个页面都带一堆宏标记和附件链接。直接切块的话，向量里混了大量无关内容。后来写了个清洗脚本，把宏标记去掉、把附件链接转成纯文本引用，检索质量立刻上来了。清洗这一步不能省，脏数据进向量库，后面怎么调都救不回来。

5.3 检索质量调优的实操清单

系统跑起来之后，调优是个持续过程。我整理了一份自查清单，按优先级排：

调优时一定要建评测集。挑 20-50 个典型问题，人工标注正确答案，每次调整后跑一遍，看命中率和准确率的变化。没有评测集，调优就是盲调，今天觉得好了，明天换个问题又不行。

6. 踩过的坑和几条实在的经验

6.1 检索命中率虚高：别被"看起来对"骗了

有段时间我的 RAG 系统命中率显示很高，但用户反馈答非所问。排查后发现，评测集里的问题太"标准"了，都是照着文档标题问的，向量检索当然准。真实用户的问题五花八门，口语化、省略、指代多，命中率其实低得多。

后来我改了评测集的构建方式：从真实问答记录里抽问题，包括那些答得不好的。这样评测结果才反映真实水平。这个坑很隐蔽，因为指标好看的时候，人容易放松警惕。

6.2 Wiki 链接扩展：层数不是越多越好

链接扩展能补充上下文，但扩展层数太多，会引入大量无关内容，反而稀释了核心信息。我试过扩展到三层，结果召回的内容里一半是边缘相关，模型被带偏了。

现在的做法是：默认扩展一层，且只扩展高相关链接。高相关怎么判断？看链接两端的页面在向量空间里的距离，距离近的才扩展。这样既补充了上下文，又不会引入噪音。

6.3 Agent 回写 Wiki：谨慎自动化

Agent 自动回写 Wiki 听起来很美，但实操中风险不小。模型生成的内容可能有错、可能重复、可能和现有页面冲突。我现在的策略是：Agent 只生成草稿，人工确认后才入库。草稿里标注来源和置信度，人审核起来快很多。

完全自动化的回写，我只在低风险场景用，比如日志类的追加记录。涉及知识性内容的，一律人工过一道。知识库的价值在于准确，不在于数量。

6.4 一个容易被忽略的细节：时间维度

知识是有时效的。三年前的部署流程和现在的可能完全不同。RAG 检索时如果不考虑时间，可能召回过期内容。我的处理方式是：给每个块打时间戳，检索时按时间加权。近期内容权重高，远期内容权重低，但不清零——因为有些知识是长期有效的。

这个加权系数需要根据你的场景调。技术文档更新快，时间权重可以高一些；法规类内容更新慢，时间权重就低一些。没有通用值，得自己试。

7. 关于这套组合的一些个人体会

我搭这套系统最大的感受是：RAG 和 Wiki 不是替代关系，是互补关系。RAG 解决"我现在要一个答案"，Wiki 解决"这些知识怎么沉淀下来"。只做 RAG，知识是散的，每次问答都是重新检索，没有积累；只做 Wiki，知识是死的，查起来费劲，用起来不灵活。两者结合，才形成一个能自我生长的知识系统。

Agent 的加入让这个系统从"被动查询"变成"主动服务"。但 Agent 不是必须的，如果你的场景就是简单的文档问答，不用硬上 Agent。工具是为场景服务的，不是反过来。

最后说一个我踩过的认知坑：一开始我总想着把系统做"全"，什么功能都想加，结果每个都做得半吊子。后来想明白了，先把一个场景做透——比如就做技术文档问答——把这个场景的检索、切块、扩展、评测都打磨好，再往其他场景扩展。贪多嚼不烂，这话在 RAG 项目里特别适用。