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 效果差根因不在模型在切块。切块策略直接决定检索质量。切得太碎一个完整概念被拆成好几段召回时只拿到半截切得太大一个块里混了好几个主题向量被平均掉语义变得模糊。常见的切块方式有这么几种切块策略适用场景典型块大小注意事项固定长度结构松散的纯文本300-500 字容易切断句子需加重叠按段落段落边界清晰的文档不定段落过长时仍需二次切分按标题层级有明确章节结构的 Wiki按小节保留标题作为上下文语义切块内容密度高的技术文档不定计算成本高但边界更准我自己的经验是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 的思路是让大模型参与知识的抽取、归纳和链接生成。你给它一堆原始材料——会议记录、聊天记录、代码注释、工单——它帮你提炼成结构化页面自动打标签、自动建链接。具体怎么做我的做法是分三步抽取把原始材料按主题切分每个主题生成一个草稿页面包含摘要、关键点、相关实体。归并把草稿页面和已有 Wiki 页面做相似度比对能合并的合并不能合并的新建页面。链接扫描所有页面找出实体共现关系自动生成双向链接。这三步里归并是最难的。模型很容易把两个相关但不同的概念合并成一个导致信息丢失。我的处理方式是归并前先让人确认或者设置一个相似度阈值超过阈值才自动合并介于中间的人工介入。宁可多建几个页面也不要错误合并。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 的编排流程大致是这样意图识别判断这是历史问题查询需要查 Wiki 里的故障记录。检索先在 Wiki 里搜接口超时拿到相关页面列表。链接扩展选中最相关的页面顺着链接拉出关联的解决方案页面和监控告警页面。生成把检索到的内容整合生成回答标注来源页面。回写如果这次问答产生了新的解决思路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, overlap0.15) vectors embed(chunks) index build_index(vectors) def ask(question): q_vec embed(question) hits index.search(q_vec, top_k5) context merge_with_links(hits) return llm.generate(question, context)这个版本跑通之后再逐步加东西加混合检索、加重排序、加链接扩展、加 Agent 编排。不要一上来就搭大系统先让最小闭环跑起来再迭代。5.2 Wiki 内容的导出与结构化处理Wiki 系统一般都能导出格式可能是 Markdown、HTML 或 XML。导出后要做几件事保留标题层级这是切块的依据也是上下文来源。提取链接关系把页面间的链接抽出来存成图结构供检索时扩展用。清理格式噪音导航栏、页脚、模板文字这些要去掉否则会污染向量。我处理过一个 Confluence 导出的 Wiki里面每个页面都带一堆宏标记和附件链接。直接切块的话向量里混了大量无关内容。后来写了个清洗脚本把宏标记去掉、把附件链接转成纯文本引用检索质量立刻上来了。清洗这一步不能省脏数据进向量库后面怎么调都救不回来。5.3 检索质量调优的实操清单系统跑起来之后调优是个持续过程。我整理了一份自查清单按优先级排优先级检查项判断标准调整手段高切块是否合理正确内容是否被完整召回调整块大小和重叠高embedding 是否匹配语义相近的内容是否召回换模型或微调中查询改写是否到位口语化问题能否召回加改写步骤中重排序是否有效最相关的是否排前面加 rerank 模型低链接扩展是否过度是否引入无关内容限制扩展层数调优时一定要建评测集。挑 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 项目里特别适用。
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 效果差根因不在模型在切块。切块策略直接决定检索质量。切得太碎一个完整概念被拆成好几段召回时只拿到半截切得太大一个块里混了好几个主题向量被平均掉语义变得模糊。常见的切块方式有这么几种切块策略适用场景典型块大小注意事项固定长度结构松散的纯文本300-500 字容易切断句子需加重叠按段落段落边界清晰的文档不定段落过长时仍需二次切分按标题层级有明确章节结构的 Wiki按小节保留标题作为上下文语义切块内容密度高的技术文档不定计算成本高但边界更准我自己的经验是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 的思路是让大模型参与知识的抽取、归纳和链接生成。你给它一堆原始材料——会议记录、聊天记录、代码注释、工单——它帮你提炼成结构化页面自动打标签、自动建链接。具体怎么做我的做法是分三步抽取把原始材料按主题切分每个主题生成一个草稿页面包含摘要、关键点、相关实体。归并把草稿页面和已有 Wiki 页面做相似度比对能合并的合并不能合并的新建页面。链接扫描所有页面找出实体共现关系自动生成双向链接。这三步里归并是最难的。模型很容易把两个相关但不同的概念合并成一个导致信息丢失。我的处理方式是归并前先让人确认或者设置一个相似度阈值超过阈值才自动合并介于中间的人工介入。宁可多建几个页面也不要错误合并。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 的编排流程大致是这样意图识别判断这是历史问题查询需要查 Wiki 里的故障记录。检索先在 Wiki 里搜接口超时拿到相关页面列表。链接扩展选中最相关的页面顺着链接拉出关联的解决方案页面和监控告警页面。生成把检索到的内容整合生成回答标注来源页面。回写如果这次问答产生了新的解决思路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, overlap0.15) vectors embed(chunks) index build_index(vectors) def ask(question): q_vec embed(question) hits index.search(q_vec, top_k5) context merge_with_links(hits) return llm.generate(question, context)这个版本跑通之后再逐步加东西加混合检索、加重排序、加链接扩展、加 Agent 编排。不要一上来就搭大系统先让最小闭环跑起来再迭代。5.2 Wiki 内容的导出与结构化处理Wiki 系统一般都能导出格式可能是 Markdown、HTML 或 XML。导出后要做几件事保留标题层级这是切块的依据也是上下文来源。提取链接关系把页面间的链接抽出来存成图结构供检索时扩展用。清理格式噪音导航栏、页脚、模板文字这些要去掉否则会污染向量。我处理过一个 Confluence 导出的 Wiki里面每个页面都带一堆宏标记和附件链接。直接切块的话向量里混了大量无关内容。后来写了个清洗脚本把宏标记去掉、把附件链接转成纯文本引用检索质量立刻上来了。清洗这一步不能省脏数据进向量库后面怎么调都救不回来。5.3 检索质量调优的实操清单系统跑起来之后调优是个持续过程。我整理了一份自查清单按优先级排优先级检查项判断标准调整手段高切块是否合理正确内容是否被完整召回调整块大小和重叠高embedding 是否匹配语义相近的内容是否召回换模型或微调中查询改写是否到位口语化问题能否召回加改写步骤中重排序是否有效最相关的是否排前面加 rerank 模型低链接扩展是否过度是否引入无关内容限制扩展层数调优时一定要建评测集。挑 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 项目里特别适用。
