先说一个我自己的真实场景。团队准备搭内部知识库的时候，产品同事拿着一个 RAG 框架问：既然模型能“读”所有文档直接回答问题了，为什么还要逼大家去写 Wiki？我当时给的解释，也是后来我在项目里反复验证的一句话：RAG 负责找答案，Wiki 负责长知识。这两件事根本不是同一层的问题，RAG 帮你从文档里检索并组合出针对某个问题的回答，Wiki 帮你把散落的经验整理成可持续生长的知识结构。如果你把两者混为一谈，大概率会得到一个“什么都往里塞、什么问题都答不好”的尴尬系统。

这篇文章我想聊聊我在搭建这个体系时的完整思路：为什么 RAG 替代不了 Wiki，为什么成熟的 RAG 项目反而更依赖 Wiki 这种结构化知识底座，以及一个从零开始就能落地的“Wiki 知识库 + RAG 查询入口”最小方案。内容覆盖检索增强的实战心得、文本拆解工具的选择、知识更新的坑，以及 Agentic RAG、GraphRAG、本体建模这些能继续演化的方向。适合正在做知识库、RAG 应用、或者只是想把团队资料盘活的人参考。

1. 先理清一件事：RAG 和 Wiki 解决的问题根本不是一个维度

1.1 我在一个内部项目里翻过的车

去年年中我接手了一个团队知识沉淀项目，背景很简单：几十个技术文档散落在不同目录、聊天记录和本地文件里，新人入职半年还在到处问“这个配置在哪”“那个流程谁负责”。最初方案很粗暴，把所有文档扔进向量库，套一个 RAG 问答界面就算完事。当时觉得，既然 LLM 能读懂上下文，那“知识库=文档集合+RAG”就是全部答案了。

上线第一周就翻了车。同事问我：“上次线上故障的复盘结论是什么？”RAG 返回的是文档里一段对故障现象的描述，完全没有提到复盘结论和后续改进项，因为那部分写在会议纪要里，而会议纪要没进向量库。又有人问“当前生产环境的限流阈值是谁定的”，RAG 给了配置文档里的数值，但没回答“谁定的、为什么定、改的时候要找谁确认”。那一刻我才意识到：RAG 的检索能力再强，它也只是在“已有内容”里找答案，如果知识本身没有结构、没有归属、没有上下文，找到的答案就是残缺的。

1.2 两者的本质差异：一件事是一次性回答，一件事是长期资产

RAG 和 Wiki 的差异，可以用一句话概括：RAG 是“取”的技术，Wiki 是“存”的体系。RAG 关心的是给定一个问题，能否从语料里定位到最相关的片段，再让语言模型组织成连贯的回答。它的核心指标是检索命中率、答案准确率和引用溯源能力。而 Wiki 关心的是知识如何被组织、分类、关联和演进，它的产出不是单次回答，而是一套可持续更新、可追溯、可被多人协作维护的知识结构。

我把两者的差异整理成了下面这张表，方便你对照：

绝大多数项目真正需要的，不是二选一，而是让 RAG 站在 Wiki 的肩膀上。Wiki 负责把知识整理成有结构的语料，RAG 负责在这个语料上进行快速查询。这个认知转变，是我后续所有架构设计的基础。

2. 认清 RAG 的四个瓶颈，你才知道它“找答案”的上限在哪

2.1 检索质量：chunk 切错了谁都救不回

RAG 第一个隐藏瓶颈是文本分片（chunking）。很多人上来就按固定字符数切，比如每 500 个字符一刀，结果把完整的概念解释从中间劈开，把配置项和它的说明切到两个不同的块里。检索阶段，query 向量可能只命中了后半段，模型就看到了一截没有上下文的内容，答案自然又短又偏。我做过对比测试：同一个文档集，采用固定长度切分和采用“标题感知切分”（按 Markdown 标题层级、列表结构、代码块边界来切），Top-5 检索命中率从 61% 提升到 83%。这 22 个百分点的差距完全不是模型问题，而是语料准备问题。

所以我把 chunking 当作 RAG 项目里最重要的预处理环节之一。按经验，正文段落通常按标题层级切片，单块控制在 300~800 字之间，代码块单独成块并保留所在章节的标题上下文；表格如果不大就整块保留，否则按行拆并生成一个行摘要。每一块还要带上来源页面 ID、标题路径、更新时间，方便后续引用溯源。

2.2 知识更新：文档改了，答案还是旧的

RAG 系统跑一段时间后会出现一个很隐蔽的问题：文档更新了，但向量索引没跟上。或者索引跟着更新了，但用户的问题描述比较模糊，检索模块命中了一段新文档里几个孤立的词，组合出的答案和整体事实对不上。知识库一旦开始频繁变化，“检索结果的时效性”就成了新的痛点。

最初我采用的是全量重建，每次文档更新都把整库重新向量化一遍。数据量小的时候没感觉，到了几万个 chunk 之后，一次全量重建跑十几分钟，而且新文档和旧文档混在一起，很难定位“刚才那批更新到底改了什么”。后面改成增量更新：文档入库时按路径和标题生成哈希，只有内容变动的文件才重新分块和向量化，再配合向量库里的 ID 删除旧记录。这样既省时间，又能保证索引和 Wiki 页面版本之间保持可追踪的关系。这里的关键思路是：RAG 的更新策略必须和 Wiki 的版本记录对齐，才能回答“你这条答案依据的是哪个版本的知识”。

2.3 多跳推理：一个简单问题把 RAG 逼到墙角

RAG 第二个大瓶颈是单轮检索搞不定需要多步推理的问题。比如有人问“我们调用支付服务时用的超时时间是多少？这个配置是否和网关层的设置一致？”这个问题至少需要先定位“支付服务配置文档”，找到超时参数；再跳到“网关层配置”文档，对比同一个参数；最后由模型判断“是否一致”。传统 RAG 的检索模块通常只做一次 Top-K 召回，根本不具备跨文档串联的能力。结果就是模型最终回复看起来言之凿凿，实际上只引用了“支付服务”一个来源。

这在行业里已经有明确解法，就是从普通 RAG 走向Agentic RAG。简单说，让 LLM 驱动检索过程：它自己决定第一步搜什么、读到结果后再决定第二步搜什么，必要时调用工具去查代码库或数据库，甚至搜索完多个来源再综合判断。我在一个故障排查场景里试过：普通 RAG 回答“某个服务为什么启动失败”只能返回日志相关段落，而 Agentic RAG 会先定位服务配置、再查依赖组件状态、最后给出原因链。代价是响应时间变长、Token 消耗变大，但复杂问题的回答质量有明显提升。

2.4 幻觉的变种：有据可查的“看似正确”

最后聊聊 RAG 里一种最误导人的失败模式：模型确实引用了检索到的片段，但把片段里的信息和长期记忆里的常识缝合在一起，给出一个看似很专业、实际经不起推敲的答案。因为答案里有引用来源，用户很容易信任它。比如知识库里写“服务 A 依赖 Redis”，模型就可能把它展开成“服务 A 依赖 Redis，Redis 支持持久化，所以重启后缓存数据不会丢失”——后半句是常识没错，但在这个具体系统里，Redis 重启后到底会不会丢数据，取决于持久化配置，而知识库根本没有这块内容。

RAG 并不天然消除幻觉，它只是把幻觉的素材从模型内部记忆转移到了外部文档。要缓解这个问题，一方面需要给每个 chunk 打更细粒度的元数据（比如来源、更新时间、可信等级），在生成时让模型严格依据引用片段作答，减少自由发挥空间；另一方面，Wiki 知识库的规范编辑流程反而能提供质量过滤，让 RAG 拿到的语料本身就是相对可信的。这也是我后面选择“Wiki 做语料源”的核心理由之一。

3. Wiki 知识库真正值钱的地方，在于帮你长出知识结构

3.1 从零散文档到知识体系，中间隔着“整理”这一步

RAG 可以把一堆零散文档变成“能回答问题”，但它不能让“知识体系”自动生长。什么是知识体系？就是你能从一个概念跳到相关概念，能从“某个配置项”找到“它的负责人”和“它的变更历史”，能区分“这篇文档已经过时”和“那篇文档是现行标准”。这个过程不是检索能替代的，它需要人在整理时主动建立联系。

我搭建 Wiki 时有个原则：不追求一次把所有文档搬进去，而是按主题优先级迁移。一个主题的页面要有明确的“概述、核心概念、操作步骤、相关链接”结构，每个页面底部列清楚“维护人、最近更新时间、认可状态”。这个整理过程看起来很慢，但等到 RAG 上线之后，它的价值就体现出来了——检索出来的每个 chunk 都带着结构上下文，模型判断“哪段话和问题真正相关”的准确率会高一个量级。

3.2 双向链接和命名规范：让知识自己长出来

Wiki 比普通文档库强的地方，主要体现在关联能力上。双向链接意味着你可以在“支付服务”页面里链接到“网关配置”页面，同时“网关配置”页面会自动显示“被支付服务页面引用”。这种结构非常接近人类理解问题时的关联方式：遇到一个概念，不是孤立地看它，而是看它处于哪张概念网中。

命名规范同样重要。我见过不少团队 Wiki 用“新建文档”“未命名 1”“最终版最终版”这样的标题，三个月之后根本没法维护。在我们项目里，所有页面标题都遵循“主题-对象-场景”格式，比如“配置-支付超时时间-生产环境”，这样既方便人工阅读，也方便 RAG 索引时理解 chunk 主题。

3.3 版本记录和讨论页：团队知识最容易忽略的地基

知识库维护最大的敌人是“过期”和“失实”。Wiki 的版本记录功能可以显示谁在什么时候改了什么，有没有人对这个修改提出过异议；讨论页则能保留决策背后的理由。我通常在关键页面上设置“技术负责人审核”标记，只有审核通过的版本才进入正式索引。

这些机制看起来和“AI 找答案”没有直接关系，但它们决定了 RAG 拿到的语料质量。如果一个 Wiki 页面已经三个月没更新，而某个流程实际上两周前就改了，RAG 引用旧版本文档给出答案，用户会觉得整个系统可信度崩塌。所以我在系统设计上做了一个硬性要求：RAG 检索结果必须显示“信息来源版本时间”，让用户能立刻判断这条答案依据的材料新旧。这个信任问题，仅仅靠优化 embedding 模型是解决不了的，必须靠知识库的管理机制来兜底。

4. 让 RAG 和 Wiki 真正协作，我采用的落地架构与背后逻辑

4.1 四层结构：原始资料 → Wiki → 索引 → 查询入口

我目前的落地架构分四层。

第一层是原始资料区，包括各种临时文档、会议记录、聊天里沉淀的片段和外部参考资料。这个区域不追求结构化，重点是“能追溯原始出处”。

第二层是 Wiki 知识库，核心工作是把原始资料整理成有结构的长期知识。每条知识都经过整理者加工，明确适用场景、限制条件和相关链接。这一层是团队的“记忆中枢”，也是 RAG 的主要语料来源。

第三层是 RAG 索引层，针对 Wiki 导出的规范化文档做分块、向量化和索引，同时保留页面元数据，例如标题路径、标签、维护人、版本时间。这一层直接用 Wiki 的导出接口批量更新，避免人工把文档再拷一遍。

第四层是查询入口，也就是用户看到的问答界面。这里可以是大语言模型驱动的对话应用，也可以是接入了 Agentic 流程的自动排查工具。查询入口的职责很纯：接收问题、调用检索、组织回答、附上引用。

这套结构的好处是：每一层只干一件事，修改某一层不会影响其他层。原始资料再乱也不影响最终回答质量，因为 Wiki 层做了质量把关；RAG 参数怎么调都不会破坏知识结构，因为 Wiki 层仍然稳定地沉淀知识。

4.2 为什么我坚持用 Wiki 做 RAG 的语料源，而不是直接扔原始文档

直接拿原始文档做 RAG 最快，但有两个绕不开的问题：第一是信息密度不均衡，文档里可能大段讲背景、讲历史，真正回答操作问题的那句话藏得很深，chunk 召回时容易被背景信息干扰；第二是矛盾内容没法自动裁决，比如旧文档说“超时时间是 3 秒”，新文档说“已改为 5 秒”，RAG 会随机命中其中一个，给出“不稳定”的答案。

Wiki 层作为语料源时，这两类问题被前置处理了：整理者会主动删掉无关背景、标注废弃内容、统一矛盾描述。并且维护者可以在 Wiki 页面里用折叠块或注释明确标出“这条规则只适用于 xx 环境”“这段内容已由 xx 文档替代”。RAG 拿到的语料是清理过的，检索命中率和答案稳定度都会提升。

4.3 从本体论到 GraphRAG：知识关联的进阶玩法

热词里有个“ontology rag”，这个方向值得单独说一下。普通 RAG 做的是向量相似度检索，本质上还是在比“字面/语义相近”。但很多问题需要的不是相近，而是概念关系。比如“这个告警应该由哪个团队处理”，需要从“告警规则”关联到“所属服务”，再关联到“值班组”，这是典型的图谱关系检索。

Ontology（本体）和 GraphRAG 解决的就是这个问题：先定义概念类型和关系（比如：服务-依赖→中间件，告警-属于→服务），再把文档里的信息抽取成实体和关系，存入图数据库。查询时先向量召回相关概念，再沿图关系跳转获得更完整的上下文。我试过在故障排查场景里引入这种方案，面对“数据库连接池打满，关联服务有哪些”这类问题，效果比纯向量 RAG 好很多，因为图结构天然支持“从连接池沿依赖方向扩散”这种推理。

不过要注意，本体建模和实体抽取的工作量不低，适合知识图谱相对稳定、关系多跳查询频繁的团队。如果你的场景只是简单问答，普通 RAG 加 Wiki 就够用了，不必一上来就上图谱。

4.4 多模态的方向：图片和表格到底该怎么进 RAG

热搜词里还有一条“rag知识库能存储图片嘛”，这个问题我实际处理过。图片能不能进 RAG，取决于你要它做什么。如果只是想“找到某张架构图”，那很简单，在向量库里存图片的描述文本和路径，用文本检索就能命中。如果你希望模型能根据图片内容回答“这张图里流量走向是什么”，那需要多模态模型参与，对图片做识别、生成结构化描述，再把描述文本作为可检索的内容。

表格也是类似逻辑。直接把 Excel 或 Markdown 表格原样塞给 RAG，很容易因为切分导致行列错位。我的做法是：对表格进行“单行描述化”，即把每一行数据转成一句自然语言摘要，例如“环境=生产，服务=支付，超时=5秒”，再参与向量化。这样检索时命中的文本是完整语义句，而不是截断后的表格碎片。多模态 RAG 目前还没有“一键搞定”的方案，更多是围绕文本描述来做工程化处理，关键是先想清楚你想让模型从图片/表格中“读到”什么信息。

5. 零基础也能抄作业的最小可运行方案

5.1 工具选型：本地跑还是用云端服务

如果你只是个人学习或小团队验证，我的建议是无脑选“本地小模型 + 轻量级向量库”先行，不必一开始就上大厂服务。热词里有一条“ollama + 简易本地 rag 知识库”，这个路线我在小项目里亲测可行：用 Ollama 跑量化过的开源模型（比如 Qwen、Llama 系的 7B~14B 量化版），向量模型用本地化的 embedding 模型，向量存储用一个支持本地的库即可。整条链路不需要申请云端 Key，数据不出去，成本也低。

等数据量上来、团队对回答质量有了更高要求，再迁移到云端或企业级方案。我的经验是：先跑通一个最小闭环，再根据瓶颈做扩展。RAG 项目的复杂度增长点通常不在模型，而在文档处理、索引更新和结果评估，这些环节和用不用云端服务关系不大。

5.2 文本拆解：用什么工具，按什么规则切

热词里有人问“有没有本地的 rag 文本拆解工具”，这类工具现在还挺多的。如果你是 Markdown Wiki 体系，可以直接写一个按标题和段落结构切块的脚本，注意处理代码块和表格；如果你有 PDF、Word 等格式，可以尝试一些文档解析工具，比如支持版面分析的库，先转成带结构的文本再切块。关键不是工具多强大，而是切出来的块要有三个属性：语义独立、上下文完整、元数据清晰。

我在实际项目中是把“切块规则”定义成配置化的，同一个文本可以按“章节再按段落”切成大块，也可以按“句子滑动窗口”切成小块。何时用大块？当问题是“这个模块的总体设计是什么”时，需要大块保留全局上下文。何时用小块？当问题是“这个函数的参数是什么”时，小块更能精准命中。想用一个切法满足所有场景是不现实的，更稳妥的做法是维护两套索引，一套粗粒度上下文索引、一套细粒度精检索索引，查询时按问题类型选择。

5.3 一套最小可运行的工作流

如果你现在就想搭起来，我推荐按下面这个顺序操作，每一步都不依赖复杂基础设施：

1. 准备一批规范文档：先把内容整理成 Markdown 格式，每个页面有标题、有章节结构、有维护人信息和更新时间。
2. 编写分块脚本：按标题层级切分，每块保留标题路径作为前缀，例如“支付服务-配置-超时时间”。
3. 生成向量索引：用本地 embedding 模型将每个块向量化，存入向量库，并保存对应的元数据字段。
4. 搭建问答接口：写一个简单的检索函数，接收问题、向量化、Top-K 召回、把召回片段拼进 prompt、调用本地 LLM 生成回答。
5. 输出引用信息：回答末尾拼接“依据文档：xxx，更新于 xxxx”来源列表，让用户能回溯验证。
6. 接一个 Wiki 同步脚本：检测 Wiki 页面变更，自动重新切分与索引受影响的部分。

这套工作流我在笔记本上跑通过，整个过程大约一个周末就能完成基础版。重点不在代码有多花哨，而在于每个环节你都清楚数据是怎么流动的。

5.4 起步阶段最容易踩的三个坑

第一个坑是把全部资料无差别灌进去。知识库不是垃圾桶，塞得越多，RAG 回答的噪声越大。我见过有人把十年前的项目计划书也索引进去，结果问“当前版本怎么部署”，模型答出过时路径。起步阶段只索引团队当前最常用的、最有维护价值的文档。

第二个坑是不评估检索质量就急着调 prompt。很多人搭完立刻开始改提示词，想让回答更“聪明”，但问题的根源可能在检索阶段就命中了错误片段。所以我每次都先单独检查检索命中列表：把 query 输进去，看看 Top-5 召回的是什么内容。这一步都不做，后面全是在错误数据上做文章。

第三个坑是索引和 Wiki 更新脱节。如果 Wiki 编辑者不知道有同步任务的存在，改完页面不触发索引更新，RAG 就是一本“旧书”。我在每个 Wiki 页面的关键位置放了一个“上次索引时间”占位字段，由同步脚本自动填充，这样用户一看就知道当前索引是否过期。

6. 用到现在，我对这套体系最真实的感受

项目跑到现在，最明显的变化不是“问答页面更好用了”，而是团队写文档的意愿变强了。以前大家觉得写 Wiki 是“给别人看的负担”，现在每个人都知道 Wiki 页面会被 RAG 用来回答问题，写清楚对自己也有直接好处：以后别人问相关问题时，AI 给出的答案来自自己写的文档，而且能附上出处。这个正向循环，比任何 KPI 都好使。

还有一件事值得一提。我把 Wiki 的页面结构和 RAG 的检索逻辑做了映射，比如页面里的“概述”部分会参与宽松检索，“操作步骤”部分会参与精确检索，“常见问题”部分独立建索引。这样做之后，用户问“怎么配置”时优先看操作步骤，问“这个模块是干嘛的”时优先看概述。这个映射规则很简单，但效果比统一切块再检索好不少，算是一个低成本高收益的优化点。

回到标题那句话：RAG 找答案，Wiki 长知识。RAG 是那把在书架里快速翻到正确页的手电筒，Wiki 是书架本身，是它决定了一本书该有什么章节、章节之间怎么关联、哪本是有价值的那本。如果你正在搭知识库，我的建议是先花两周整理出几十个高质量 Wiki 页面，再花一个周末接上 RAG。顺序反了，你只会收获一个看起来很智能、其实经常答非所问的玩具系统。