“RAG 找答案Wiki 长知识”这句话是我折腾了一年多知识库项目之后总结出来的最朴素心得。很多人一上来就堆RAG组件向量库、Embedding模型、重排器全上跑出来的效果却总差口气。问题往往不在检索而在于知识本身是乱的。RAG负责的是“从已有的知识里把答案找出来”可如果知识是碎片化的、割裂的、没有体系的找答案就是无源之水。Wiki的价值恰恰在前面那一层——把知识沉淀成结构让RAG有据可查。这篇文章我会围绕“RAG与Wiki如何配合”讲透思路、选型、实操和避坑尤其适合正在搭本地知识库、做LLM应用开发、或者被RAG命中率折磨的读者。1. 为什么“RAG找答案Wiki长知识”是一个完整闭环1.1 RAG的本质以及它解决不了的问题RAG检索增强生成Retrieval-Augmented Generation原理其实特别朴素先把文档切成文本块用Embedding模型转成向量存进向量库用户提问时把问题也转成向量在库里做相似度检索找出最相关的几个片段最后把这些片段和问题一起塞给大模型让它基于这些资料作答。你可以把RAG理解成开卷考试。不是让模型凭空想而是让它看着资料回答问题。这样能解决大模型“知识截止日期”的问题也能让它针对私有文档、本地资料回答不用重新训练模型。听起来很完美但它的前提是资料里确实有正确答案而且资料得能被检索到。我踩过最深的一个坑就是知识库本身一团糟——同一件事在不同文档里说法不一过时内容没清理长文档被切得支离破碎结果模型检索到的片段既不全也不准答得倒是很流利但内容张冠李戴。这不是RAG不行而是知识管理没做好。RAG是个“捞答案”的引擎它不是“整理书架”的管家。书架乱了捞出来的自然全是乱书。1.2 Wiki补的正是知识结构化那一层Wiki这个词很多人第一反应是“维基百科”或者游戏攻略站比如人气很高的英灵神殿Wiki、后室中文维基。但Wiki的本质不是网页而是一种协作式知识组织方式页面、分类、标签、双向链接、版本历史、讨论页。这些功能全都是为了让知识具备“单一事实源”和“可追溯性”。放到个人或团队知识库里Wiki解决的是三个问题一是知识放哪里——有明确的页面归属二是知识怎么组织——通过层级和标签建立脉络三是知识和知识怎么连接——用双向链接把相关内容串成网络。这三件事做好之后RAG检索到的不再是孤零零的一个片段而是带着上下文语境的信息。举个例子。我之前在项目Wiki里记录“为什么用消息队列而不是直接调用”这个架构决策如果只是把Markdown文件一股脑塞进RAG模型很可能只看到一句“这里用了RabbitMQ”完全get不到背景。但在Wiki结构下这篇文档挂在“架构决策”分类下链接着“系统边界”和“削峰填谷”两个页面还带了一张时序图。RAG检索时如果能把这些关联信息一并带出来回答就有了依据。所以我的结论是RAG决定答案的下限Wiki决定答案的上限。2. 整体设计与方案选型本地优先自己掌控一切2.1 我的选型思路在动手搭这个RAGWiki系统之前我先定了三条原则。第一本地优先。知识库里的内容是我个人的笔记、整理的资料、部分项目文档上传到第三方云总觉得别扭很多想法也放不开写。本地部署虽然初期麻烦一点但隐私和掌控感完全在自己手里。第二零成本起步能跑通再升级。很多人一上来就上云向量库、托管Embedding服务还没摸清流程就花了一堆钱。我最初的目标是本地一台电脑能完整跑通“让大模型基于本地文档回答”之后再考虑更高配的方案。第三组件要可替换。RAG整个链路里的每一环从文本拆解、Embedding、向量存储到LLM最好都能单独换。这样哪一环出了问题能快速定位不用推倒重来。基于这三点我最终选定的技术栈是Ollama负责跑LLM和Embedding模型向量库从Chroma迁到了LanceDBWiki层用本地Markdown体系配合双向链接工具管理后面还会加一个轻量级Wiki引擎做发布。2.2 组件选择对比做选型的时候我把每个环节的候选方案都列出来对比过。下面这张表基本还原了当时选型的考量环节候选方案最终选择理由LLM推理Ollama、LocalAI、llama.cppOllama一条命令拉模型零配置启动社区模型多EmbeddingOllama内嵌模型、sentence-transformersOllama的nomic-embed-text复用本地资源不需要另起Python服务向量库Chroma、LanceDB、Qdrant、MilvusLanceDB嵌入式部署无服务进程适合单人知识库文本拆解LangChain文本拆分器、自研工具按结构拆分的自研工具能识别Wiki的标题层级保留上下文Wiki组织Obsidian、BookStack、MediaWiki、自建MarkdownObsidian配合Git本地可编辑、纯文本可控、方便接入RAG重排序BGE-Reranker本地部署、APIBGE-Reranker本地跑成本低对命中率提升明显这个组合最大的好处是除了下载模型时需要联网平时系统完全离线可用而且每个环节都是可替换的。如果你想用Java生态热词里提到的LangChain4j也是不错的选择它把RAG流程封装得很好在企业应用里更顺手。我自己因为是日常脚本为主所以直接用Python和LangChain拼装灵活度更高。3. 核心细节解析与实操要点3.1 RAG全流程拆解索引、检索、生成一条完整的RAG链路拆开看就是三个环节索引、检索、生成。索引阶段是把原始文档变成可检索的向量。这里面有四个操作清理、拆块、嵌入、入库。清理指的是去掉无关的页眉页脚、广告、重复内容拆块是把长文本切成适合嵌入和检索的片段嵌入是用Embedding模型把每个片段变成一个向量入库是把向量和原文片段存进向量库方便后续检索。检索阶段是用户提问后把问题向量化然后在向量库里做近似搜索找到最相似的若干个片段。注意最相似的片段不一定是对的回答所以通常要取Top-K比如K5或10把候选片段交给后续环节去筛选。生成阶段是把检索到的片段和问题一起拼成Prompt交给LLM做答案生成。这个阶段有两个关键一是Prompt里要明确告诉模型“只能基于提供的资料回答”二是如果资料不足或相关度低模型应该说实话“不知道”而不是瞎编。这需要在Prompt设计上下功夫。三个环节里最容易被忽视的是索引阶段。我见过太多人把精力全放在调LLM上却不肯在文档清理和拆分上花时间。实际上检索质量的上限在索引阶段就定死了后面的重排只能小修小补。3.2 Wiki的结构化设计页面规范、元数据、双向链接既然Wiki要为RAG提供高质量的知识Wiki本身的组织结构就必须有规矩。我给自己定了几条规则后来团队也用上了。第一每篇文档必须有明确的主题一个页面只讲一个知识点或一项决策。主题含糊的文档检索时既会命中一堆无关Q又容易漏掉正确答案。第二每篇文档的开头必须写元数据标签、所属分类、创建日期、来源。不要小看这些字段它是检索阶段过滤的重要依据。比如你只想在“架构决策”下检索元数据里的分类就能帮你把范围缩得很小。第三善用双向链接。没做过Wiki的人可能不理解双向链接的威力——它让知识从“一棵树”变成“一张网”。当你维护“消息队列选型”页面时顺手链接到“系统边界”“可靠性设计”这些相关页面这些链接关系本身就是一种知识。RAG检索时我们能靠这些链接把关联片段一起取出来效果跟开卷考试高亮重点一样。第四版本管理。Wiki内容必须纳入版本控制我用的是Git仓库管理Markdown文件。好处明显内容改坏了可以回滚也能追溯某个答案最初是依据哪一版文档生成的。我记得很深刻的一件事是把零散笔记整理成有分类、有标签、有链接的Wiki结构之后RAG的检索命中率直接涨了一截。因为相关文档被链接串起来了单纯的语义检索再辅以图关系检索信息密度完全不同。这也是后来GraphRAG能火的原因——它的底层就是把知识建模成图再按图去检索。3.3 文本拆解工具与参数调优热词里有人问“有没有本地的RAG文本拆解工具”这确实是个高频问题。默认的固定字数拆分chunk非常粗暴经常把一句话、一个表格、一段代码从中间切断导致语义丢失。我用下来最靠谱的思路是“结构感知拆分”。具体做法是先解析Markdown的结构识别标题层级H1/H2/H3、列表、表格、代码块然后以标题为单位切分小段落合并到邻近章节大章节再按字数二次切分。这样做出来的chunk每个片段都有完整的上下文意图。参数上几个核心值我推荐这么设chunk size每块字数根据文档类型在300到800之间调太长语义容易混太短检索容易丢上下文overlap重叠字数设置在50到100保证切分边界不会把关键信息切掉。有过一个实际测试案例同一个文档集合固定512字切分的命中率只有42%换成按标题结构切分后命中率到了71%。这个差距直接决定了你的RAG能不能用。如果你用LangChain自带的MarkdownHeaderTextSplitter就能干这事。不过我后来还是写了自己的拆解器因为团队Wiki有自定义的元数据语法只有自己处理才能把元数据解析出来作为检索的过滤条件。4. 实操过程与核心环节实现从零跑通本地RAGWiki4.1 用Ollama跑起全套本地模型首先装Ollama。官网下载对应系统的安装包装完命令行敲一下能看到服务已经在跑了。然后拉取两个关键模型一个是Embedding模型一个是生成用的对话模型。我在用的组合是ollama pull nomic-embed-text ollama pull qwen2.5:7bnomic-embed-text是本地Embedding模型768维处理中文效果中规中矩胜在体积小、速度快。qwen2.5用7B这个量级是因为它在质量和显存占用之间比较平衡普通消费级显卡能跑纯CPU也能凑合就是慢一些。拉完之后验证一下是否能正常推理ollama list能看到两个模型在列表里就行了。这一步跑通后面所有模型能力都由Ollama提供不用再折腾Python端的环境。4.2 把Wiki内容接入RAG导入、清洗、分块、嵌入、入库这是整个流程的核心我一步步说。第一步从Wiki库里导出Markdown。如果你用的也是Obsidian仓库本身就是文件夹加Markdown相当于天然可导入。如果你用的是Kirby、BookStack这类需要把页面导出成Markdown或HTML再转成Markdown。第二步清洗。把导出的文档滤掉多余空行、修正断行、去掉前后置导出的相关信息。这一步容易忽略但对Embedding影响很大。乱糟糟的文本嵌入出来的向量跟干净文本嵌入出来的向量检索效果差得很明显。第三步分块。用我上面说的结构感知拆解器处理。代码实现不复杂大致是这样import re def split_markdown_by_headers(text, max_chunk_size800): lines text.splitlines() chunks [] current_chunk [] current_header_level 0 for line in lines: header_match re.match(r^(#{1,6})\s(.*), line) if header_match: if current_chunk: chunks.append(\n.join(current_chunk)) current_chunk [] current_header_level len(header_match.group(1)) current_chunk.append(line) if current_chunk: chunks.append(\n.join(current_chunk)) # 对超长chunk按段落再切 final_chunks [] for chunk in chunks: if len(chunk) max_chunk_size: # 按段落粗切保留相邻段落语义 paragraphs chunk.split(\n) temp for para in paragraphs: if len(temp) len(para) max_chunk_size: final_chunks.append(temp) temp para else: temp \n para if temp: final_chunks.append(temp) else: final_chunks.append(chunk) return final_chunks这个函数把文档按Markdown标题切成块同时处理超长块。每块还记录一下它来自哪个标题下后面检索完能追溯出处。第四步嵌入和入库。用Ollama的Embedding接口把每块文本转成向量存进LanceDB。LanceDB是嵌入式向量库直接往文件夹里写数据没有独立的服务进程适合本地。代码如下import lancedb import ollama db lancedb.connect(./wiki_vectors) def embed_text(text): resp ollama.embed(modelnomic-embed-text, inputtext) return resp[embeddings][0] table db.create_table(wiki_docs, data[ {id: i, text: chunk, vector: embed_text(chunk), source: doc_name} for i, chunk in enumerate(chunks_list) ], modeoverwrite)至此Wiki里的知识已经变成可供检索的向量库了。整个过程里最耗时的其实是Embedding那一步上千个块可能要跑一段时间。别急索引是一次性的跑完以后增量更新只处理新内容就好。4.3 检索问答与命中率提升实战向量库建好之后检索问答就顺理成章了。用户输入问题先把问题转成向量然后在LanceDB里搜索前K个最相近的块再拼Prompt丢给LLM。我第一次跑通的时候兴冲冲地拿Wiki里的“消息队列选型”提问结果返回的内容没抓住重点。后来复盘发现问题出在检索阶段——没有设置元数据过滤也没有重排。加了两样东西之后效果立刻变了。第一加元数据过滤。用分类和标签做前置筛选把检索范围限制到“架构决策”分类。这一步相当于人工缩小了搜索范围召回准确率一下子上去不少。第二加重排Rerank。向量检索得到的Top-K只是向量空间里的“相似”不一定是语义上的“最相关”。我用一个本地重排模型BGE-Reranker对Top-K结果重新打分把最相关的提升到前面来。from FlagEmbedding import FlagReranker reranker FlagReranker(BAAI/bge-reranker-base, use_fp16True) def rerank(query, candidates): pairs [[query, cand] for cand in candidates] scores reranker.compute_score(pairs) return [c for _, c in sorted(zip(scores, candidates), reverseTrue)]做完这两步我的回答质量提升非常明显。这也验证了一个经验RAG系统好不好用hit rate检索命中率比模型本身更能决定体验。hit rate的意思是正确答案是否出现在被检索到的片段里。如果命中率低后面怎么调Prompt都是白搭。4.4 增量更新与维护知识库是活的Wiki会持续新增内容和修改旧内容RAG索引也要跟上。我的做法是用Git监听Wiki仓库的变化检测到有文件新增或改动时只对变化的部分重新分块、嵌入、更新向量库。删除的内容也要同步从向量库移除否则模型会一直拿旧资料回答问题。这个增量更新机制看起来不起眼但它是知识库能长期用的关键。一个不更新的索引三个月之后基本就是一堆过期垃圾。5. 常见问题与排查技巧实录5.1 检索效果差问题出在哪一环这是被问得最多的一个问题。我列了一个排查表格照着一步步查基本能定位80%的问题。现象可能的根源排查方法解决方向命中率低正确答案没被召回分块太粗暴把关键内容切断了检查被检索到的块看看是否断句、断表格换结构感知拆解调大overlap检索结果相关但不完整Top-K太小上下文不足打印检出的Top-K块看覆盖范围调大K值比如从5调到10检索结果里有无关旧内容索引许久没更新知识库里有过期数据对比原文和索引里的内容做增量更新清理过期向量回答部分正确但啰嗦Prompt没有约束“只根据资料回答”查看生成时的Prompt强化Prompt要求引用资料原文回答准确率不稳定没有重排向量检索的噪声太高查看Top-K排序是否合理加重排模型精排候选结果有时候问题不在单一环节而在整个链路。比如两个文档里同一个概念说法不一致模型会优先采用检索得分更高的那一个但那个可能是过时的。这时候需要回到Wiki层去做内容整合把矛盾信息消除掉。记住RAG只是搜索引擎不是保洁员。5.2 图片和表格内容处理热词里专门有人问过“RAG知识库能存储图片嘛”。纯粹靠向量检索图片本身是不能直接嵌入的——Embedding模型吃的是文本不是像素。表格则看情况转成文本后效果不稳定。我的处理方案分三步图片场景用本地视觉模型把图片转成文字描述比如流程图、截图里的关键信息写成一句话或一段摘要把这个摘要连同图片路径一起入库。表格场景不要直接转成“单元格A1是xx”这种扁平文本而是把表格的语义转成自然语言比如“消息队列选型的对比结果是RabbitMQ适合业务解耦Kafka适合高吞吐日志”。这样模型才能理解表格说的是什么。实测下来这种方式比丢原始图片给模型靠谱得多。视觉模型会偶发幻觉但摘要本身就是参考信息真正回答时还有大模型把一道关整体可控。5.3 从普通RAG到GraphRAG、本体RAG、Agentic RAG聊到最后必须说说演进方向因为热词里这几个词热度都很高而且它们解决的都是RAG的深层问题。GraphRAG的核心是把知识抽成实体和关系构建成图按图遍历去检索。普通RAG只能在文本语义层面找相似GraphRAG能跨文本把凌乱信息串成结构。我自己的Wiki双向链接已经具备一部分图的性质所以做GraphRAG很顺——直接从链接关系建图再迭代检索。本体RAGOntology RAG的思路更新它先建一层本体Ontology把业务概念、属性和关系定义清楚再让文档“挂靠”到本体上。这样检索不只是语义匹配还能做逻辑推断。举个例子如果Wiki标定了“模块A属于系统B”且“系统B的负责人是张三”那么问“张三负责哪些模块”时普通RAG要从文本里找才能知道本体RAG通过推理直接就能答。这个方向适合知识边界清晰、对准确率要求极高的场景。Agentic RAG是说检索不再是一锤子买卖而是Agent反复迭代的过程——先检索一轮发现信息不够再改写问题、再检索甚至调用工具、翻阅Wiki里的关联页面。试过一轮MedRAG增强后命中率提升了这条路未来的空间很大。但也要清醒Agentic RAG的复杂度和故障率都比单体RAG高建议先把基础RAG做好再往Agent方向演进。最后再分享一个小技巧。搭这套系统时最容易被忽略的其实是“问题路由”。别把什么都丢给RAG去捞简单问题直接问模型复杂问题才进知识库。我在本地跑了一个小分类器判断问题类型决定走快车道还是走知识库。这个思路极大节省了资源也减少了幻觉出现的概率。RAG和Wiki的分工也一样——一个负责找一个负责存各司其职知识库才会越来越聪明。