企业官网建设流程全解析

最近好几个朋友跟我聊同一个话题，团队里不是没有知识库，也不是没有AI工具，但总感觉“用不起来”。Wiki建了一大堆，文档整整齐齐放着，真到要回答具体问题的时候，还是得人工翻半天；上了个AI问答机器人，结果回答得驴唇不对马嘴，反而更不敢用了。其实这俩问题本质上是一件事：知识沉淀和知识消费脱节了。

“RAG 找答案，Wiki 长知识”这句话，我觉得是给所有想搭知识库的团队指了一条特别务实的路。RAG负责把私有知识变成实时问答能力，Wiki负责把散落经验沉淀成结构化的长期资产。你读这句话时可以这样理解：Wiki是“藏书楼”，RAG是“图书管理员”，一个管积累，一个管调用。这篇内容就是围绕这套组合拳，讲清楚背后的原理、参数、落地步骤和我踩过的坑，适合正在做企业知识库、个人知识助理或者刚接触RAG的开发者参考。

1. 为什么是“RAG找答案，Wiki长知识”这套组合拳

先说个很直观的现状。很多团队的第一步不是从零开始，而是“已经有了一堆文档”，比如产品手册、技术方案、客户答疑记录，但散落在不同的网盘、GitLab Wiki、飞书文档里。这时候直接硬上一个知识库问答，效果往往很拉胯，因为语料本身没有结构。而Wiki恰恰是解决“语料结构化”的成熟工具，它有目录、有标签、有互相引用关系，相当于天然帮你把RAG的索引层做了前置整理。所以这两个东西不是二选一，而是上下游配合的关系。

1.1 两者的定位差异，决定了不能互相替代

Wiki的核心逻辑是“人写给人看”，RAG的核心逻辑是“机器读给人听”。两者的定位差异非常明显。Wiki讲究内容分层，比如一篇技术方案，通常会有背景、方案选型、实施细节、风险点几个章节，这种结构对人类检索很友好，但对模型来说，如果全篇丢给上下文窗口，反而容易抓到次要信息。RAG讲究的是“按需取用”，它会把文档切成一个个语义碎片，再根据用户问题去匹配相关片段，相当于把“读一篇二十页方案”的任务，变成“只读跟问题最相关的三段话”。

这里有个很容易踩的误区：有人觉得有了RAG，Wiki就该淘汰，反正AI都能“看懂”所有文档。实际体验下来完全不是这么回事，RAG的答案质量上限，取决于语料的组织质量。Wiki里的层级结构、关键词标签、页面彼此之间的链接，这些是绝佳的“语义路标”，能让RAG在召回阶段少走很多弯路。我试过一个对比实验：同一批内容，一份是杂乱无章的Markdown堆在一起，一份是放在Wiki里带目录带标签，两者的命中率和答案完整度差得不是一星半点。

1.2 这套组合到底解决了什么痛点

热词里有人提“解决了知识割裂 rag”，这确实是核心痛点之一。知识割裂说的是什么？就是每个部门都在攒自己的文档，技术部写接口文档，运营部写FAQ，销售部写客户话术，但这些内容可能描述的是同一件事，互相之间却没有链接。Wiki天然鼓励内容互相引用，能把这些孤岛连起来；RAG则让你不用记“哪份文档在哪”，有问题直接问就行。

第二个痛点是“问答入口太多”。很多公司不是没有工具，而是工具有点太多了，AskBot、飞书机器人、内部搜索引擎，每个都只覆盖一部分数据。你问AI技术问题，它答不上来，转头要去另一个工具查客户信息，体验断裂。基于RAG做的知识问答，可以把多个Wiki空间、多类文档统一接进来，做一个统一入口，算是在“信息架构”层面做了一次聚合。这也解释了为什么现在很多新项目喜欢把Wiki作为RAG的语料源，就是因为Wiki的元数据丰富，天然适合做权重的分配和权限的过滤。

2. RAG核心机制拆解：检索链路里那些决定成败的细节

很多人一说RAG就想到“向量检索”，好像把文档变成向量、算个相似度就完事了。但真正做落地项目的人都知道，一条可用的RAG链路由三层构成：索引层、检索层、生成层。每一层都有坑，而且大多数“回答得乱七八糟”的问题，根源都不在模型，而在前面的检索层。

2.1 三层架构，每一层都在干什么

索引层负责把原始文档切碎、清洗、向量化，存到一个向量数据库里。这一步看似简单，其实最影响结果。切多大合适？切小了语义不完整，切大了噪声太多。清洗要做到什么程度？模板里的页眉页脚、代码块里的乱字符，都会污染向量。检索层负责把用户问题做同样的向量化，然后去库里找TopK个最相似的片段，这个阶段通常还会混入关键词检索（BM25）做加权，也就是行业里常说的“混合检索”。生成层比较直接，把用户问题和检索到的片段一起塞给LLM，让它基于这些上下文生成答案。

我见过不少团队在这三层上用力不均：模型换成了70B大参数，但索引层还是丢一个PDF就直接入库，chunk_size用的是默认值，结果回答里经常出现把A页内容和B页内容拼在一起的情况，这就是典型的“上游污染，下游背锅”。如果你把RAG链路当成一个水管，模型只是出水口，前面几段管道堵了，出水口再大也没用。

2.2 核心参数选择，直接决定“能否找到”

讲几个关键参数，都是我实测下来对效果影响比较大的。

第一个是chunk_size（切块大小）。很多RAG框架默认是512或1024字符，但这不是万能值。语义相对独立的FAQ类内容，256左右反而更精准；长文档的连续章节，512到1024比较合适。关键是要配合overlap（重叠长度），一般设为10%-20%，比如chunk_size选512，overlap设64到128，这样可以避免一句话被从中间切断，导致检索时查不到完整语义。我见过有项目完全不设overlap，结果“动态规划算法”这个短语被拦腰切成两截，用户问“动态规划”就怎么都搜不到，加个overlap之后命中率直接翻倍。

第二个是embedding模型的选择。这个环节“小模型”和“大模型”的差距没有想象中大，但领域差异很重要。通用场景用bge-m3或text-embedding-v3这类中文效果好的模型就够了；如果是垂直领域，比如医学、法律、代码，可以考虑领域微调过的模型，或者至少用领域语料跑一遍“向量自评”，看看相似问题召回对不对。模型维度不用刻意追高，1024维和768维对效果的影响，远小于chunk策略和语料清洗的影响。

第三个是TopK（召回条数）和相似度阈值。我的一句建议是：TopK建议5到10，阈值不要轻易设得太高。很多刚上手的人把相似度阈值设成0.8，结果能召回的内容寥寥无几，系统“宁缺毋滥”，但实际问答场景里，宁可多召回几条让模型自己筛，也不要让答案空白。通常把阈值放在0.3到0.5之间，再配合一个TopK上限，效果比较稳。当然这也要看使用的embedding模型本身的分数分布，有些模型相似度普遍偏低，0.5就算很接近了，建议先在库里随机跑几个问题，观察分数分布再定阈值。

2.3 怎么评估一套RAG系统好不好用

热词里有“rag hit rate”，就是指命中率。评估一套RAG系统，不能只看“答得对不对”，要拆成三个指标：检索命中率（hit rate）、排序质量（MRR）、生成正确率（faithfulness）。坦白说，很多团队压根没建评估集，全靠人工“随便问几个问题”，这会导致你根本不知道改动一个参数到底是变好了还是变差了。我建议从Wiki里挑二三十个“既有标准答案”的问题，组成一个最小评估集，每次调参后跑一遍，统计命中率和正确答案覆盖数，再做决定。这比凭感觉调参数靠谱得多。

3. Wiki侧的内容治理，才是RAG效果的“隐藏杠杆”

如果你只想简简单单把Wiki塞给RAG，那这篇的第三节可以跳过；但如果你想真正把知识库做起来，这节可能是全文最值钱的部分。RAG的上限，很大程度上取决于Wiki的内容质量。

3.1 把Wiki当成知识资产库来经营

Wiki的价值，不只是“有一个网页能看文档”，而是它天然支持版本管理、历史追溯、多人协作、内容互链。这些特性对于RAG来说都是加分项。版本管理意味着你可以在增量更新时回溯；内容互链意味着你可以把语义关系显式地表达出来。尤其是Obsidian一类本地化双链笔记工具，很多人已经习惯用它搭个人知识体系SOP，如果后续把这些笔记作为RAG语料，双链关系在切片后依然保留在元数据里，能给检索带来丰富上下文。

但用Wiki做语料源之前，一定要做一次内容体检。看看有没有过期文档、有没有只言片语的流水账、有没有图片截图当答案的页面。RAG对“高信息密度的文字”最友好，对“图里藏着答案”的内容基本无能为力。热词里有人问“rag知识库能存储图片嘛”，能存，但能不能检索出图片里的信息是另一回事。如果图片是流程图、架构图，建议在Wiki页面里给它配一段文字说明，这样RAG才能“看得到”它。这个习惯，比任何技术优化都重要。

3.2 一套可复制的Wiki知识结构SOP

内容结构化这件事，完全可以标准化。我建议任何一个团队在搭Wiki时按下述三层来组织：

第一层是空间划分，按“对象”区分而不是按“部门”区分。比如把“产品手册”、“技术方案”、“FAQ”、“内部流程”分成四个独立空间，后续做RAG接入时，可以按空间做过滤，权限管理也清晰。第二层是页面模板，每类文章固定几个板块，比如FAQ就写“问题标题、背景、解决方案、注意事项”，这相当于给RAG提供了稳定的语义骨架。第三层是标签与链接规范，每个页面至少打3个标签，关键术语要链接到概念页。这样在索引阶段，标签可以变成附加的检索信号，链接关系可以为后续升级到GraphRAG打基础。

别小看模板的作用。我用同一个模型、同一个检索链路测过，结构化模板的Wiki页面，比纯自由书写的页面，hit rate能提升15%以上。原因是模板让语义位置相对固定，模型在理解“这是背景还是结论”时更明确。日常维护时，也应约定“标题即问题、正文即答案”的写法，这种页面对于RAG来说简直是天然的一问一答语料，检索时相关性极高。

3.3 从Wiki到RAG：内容接入的关键动作

Wiki内容接入RAG，不是把页面URL扔给爬虫就完了。我建议的流程是四步：清洗、转换、增量、权限过滤。

清洗要把模板导航、页脚、广告位等非正文内容去掉，否则向量里会混进大量噪声；转换是把所有格式统一成Markdown，尤其是要处理从Word或网页粘贴来的内容，统一代码块的标记，统一列表符号；增量是指每次Wiki更新只需要处理增量部分，不用全量重建索引，能省大量耗时和API成本，这里可以借助Webhook或定时任务检测更新节点；权限过滤更关键，要知道哪些内容能进向量库、哪些不能，比如内部薪酬制度，即使在Wiki里也要加白名单控制，不然RAG的检索出口就变成了一个隐形泄露通道。

这些看上去都不难，但每一条我都见过反面教材。有人直接在原始HTML上做切块，结果向量里全是导航文字；有人全量重建索引，几千个页面跑一次要几个小时；有人权限没设好，问一句“公司平均薪资”直接答上来了，场面一度很尴尬。

4. 实操流程：一套可复制的本地RAG+Wiki知识库搭建

前面讲了这么多原理和策略，下面给一套能直接照做的方案。这里我以“本地部署、零基础可复制”为原则，不依赖商业API，适合个人或小团队内网使用。

4.1 环境准备与模型选型

我的推荐组合是：ollama跑本地LLM + BGE-M3做embedding + Chroma做向量库 + LangChain或LlamaIndex做编排。这套组合的好处是全部开源、可离线运行、成本极低。LLM建议从qwen2.5系列或glm系列开始，显存不够就先选量化版本，比如qwen2.5-7b-instruct-q4，单张16G显卡就能跑得动；显存特别紧张的，可以用3b或1.5b小模型先跑通流程，再根据效果升级。

这里强调一下，LLM参数量的重要性，远低于“检索质量”的重要性。很多团队用了超大模型但检索一塌糊涂，答案照样胡说。所以新手起步，我特别建议用最小的成本把链路跑通，再逐步升级模型，而不是一上来就上72B。

4.2 数据准备：把Wiki内容变成可检索的向量

假设你的Wiki内容已经导出成Markdown格式，下面是一个最小可跑的切块和向量化流程。我用Python写了个精简示例，你可以根据自己用的框架调整：

from langchain.text_splitter import MarkdownTextSplitter from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import Chroma # 1. 读取Wiki导出的Markdown文件 with open("wiki_export/faq_ai_product.md", encoding="utf-8") as f: content = f.read() # 2. MarkdownTextSplitter：按标题切分，保留页面层级意识 splitter = MarkdownTextSplitter(chunk_size=512, chunk_overlap=64) chunks = splitter.split_text(content) # 3. 本地embedding模型，不用调外部API embeddings = HuggingFaceEmbeddings(model_name="BAAI/bge-m3") # 4. 写入Chroma向量库 vectorstore = Chroma.from_texts( texts=chunks, embedding=embeddings, persist_directory="./chroma_db", metadatas=[{"source": "faq_ai_product.md"} for _ in chunks] ) print(f"共写入 {len(chunks)} 个文档分块")

这段代码里，选了MarkdownTextSplitter而不是普通TextSplitter，是因为它能感知Markdown的标题层级，按章节边界切分，避免把一个二级章节截成两半。chunk_overlap设成了64，确保章节边界处的上下文不断裂。如果你用的是Obsidian这类本地笔记工具，导出Markdown后这套流程同样适用。

4.3 问答测试：从检索到生成的完整链路

向量库建好之后，就可以写问答接口了。核心逻辑是先检索最相关的分块，再把它和用户问题拼成一个Prompt，送给LLM生成答案。这里我给的Prompt模板是实践下来比较稳的版本：

from langchain_community.llms import Ollama from langchain.chains import RetrievalQA # 加载本地大模型 llm = Ollama(model="qwen2.5:7b", temperature=0.2) # 构建检索问答链 qa = RetrievalQA.from_chain_type( llm=llm, retriever=vectorstore.as_retriever(search_kwargs={"k": 5}), chain_type="stuff", verbose=True ) # 自定义Prompt，强调“只用Wiki内容作答” from langchain.prompts import PromptTemplate template = """你是一个企业内部知识助手。请只根据以下提供的内容回答用户问题。 如果提供的内容中没有相关信息，请直接回答“未找到相关资料”，不要编造。 【参考内容】 {context} 【用户问题】 {question} """ prompt = PromptTemplate(template=template, input_variables=["context", "question"]) qa.combine_documents_chain.llm_chain.prompt = prompt # 测试 result = qa.invoke("RAG和Wiki有什么区别？") print(result['result'])

注意这里的三个细节：temperature设成了0.2，尽量让输出保守稳定；k设5，召回够用又不会把上下文撑爆；“未找到相关资料”这个兜底逻辑很关键，能让系统在知识覆盖不到的时候“认怂”而不是“胡说”。这套链路跑通之后，你可以用Flask或FastAPI包一层HTTP接口，接到飞书机器人或企业微信里，整个团队就能直接用了。

4.4 进阶方向：Agentic RAG与GraphRAG的引入时机

当你发现“简单问答”已经满足不了需求，比如用户会问“对比一下方案A和方案B的优缺点”“按风险评估归类这几个客户”，这时候可以考虑引入Agentic RAG或GraphRAG。Agentic RAG是让LLM自己规划要检索哪些内容、分几步检索，相当于给问答加了一个“拆解问题”的过程；GraphRAG则把知识图谱引入检索，适合处理关系密集型的知识，比如“哪个模块调用了哪个API接口”。这些方向能解决很多朴素的相似度检索搞不定的问题，但不要一上来就上，先把基础的RAG链路和Wiki语料质量打磨好，再逐步演进，是最稳妥的路子。

5. 实操中的高频问题与排查思路

真正落地时遇到最多的问题，基本集中在“答非所问”“答案太陈旧”和“性能太差”这几个方向上。每个问题都可能有多重原因，下面按我摸排的经验给一个排查顺序，不一定对号入座，但大概率能帮你定位。

5.1 检索召回质量差，命中率上不去

排查顺序是：先看切块，再看embedding模型，最后看混合检索的比例。第一个要检查的是chunk_size和overlap，很多命中率低和内容被拦腰切断有关，尤其表格和代码块，建议在切块规则里把表格、代码块设为“不拆分单元”。第二个看embedding模型是否适合中文，先换成bge-m3这类中文效果经过验证的模型试试。第三个如果只用了向量检索，建议加上BM25做混合召回，两者加权合并，通常能同时覆盖语义检索和关键词检索两个场景。热词里很多人提到“rag hit rate”低，大概率是这三步里面漏了后面两步。

5.2 回答幻觉严重，答案和材料对不上

幻觉问题的核心在生成层，但根子往往在检索层。如果召回的内容本身和问题关联度很低，模型为了回答，只能编造。我的排查顺序是先看召回的前几条内容是否真的相关——可以把调试模式打开，把召回片段打印出来看一眼。如果召回不相关，回到5.1；如果召回相关但答案仍错，再检查Prompt约束是否够强，是否明确写了“只根据以下内容回答”。此外，把temperature适当降低，也会减少模型的自由发挥空间。对准确率要求高的场景，还可以让模型在回答末尾标注引用了哪个Wiki页面，方便人工核验。

5.3 知识库更新不生效，回答还是旧内容

这个问题特别常见，而且特别隐蔽。通常原因有两个：一是向量库没有做增量更新，还在用旧索引；二是缓存层把旧结果返回了。建议给Wiki页面加上更新时间戳元数据，检索时对超过一定天数的内容降权；同时在RAG接口外面做一层时效性判断，比如用户问到“最新版本是什么”，可以额外触发一次最新文档检索。这里我建议团队把“内容更新频率”纳入Wiki维护SOP，哪些页面是月度更新的，哪些是季度更新的，要让RAG系统感知到这些节奏，而不是被动接受内容。

5.4 成本与性能平衡的几条经验

最后聊点硬件和成本的心得。本地部署这套方案，7B量化模型加BGE-M3，16G内存的机器勉强跑得动，但并发一高就会卡。真要多用户使用，建议把embedding检索和LLM生成拆到两个服务里部署，前者很轻，后者吃显存，拆开之后可以独立扩容。向量库的选择也要看规模，几千个分块用Chroma足够，到了几十万分块，可以考虑Milvus或者Qdrant，检索性能差距会拉开。批量入库的时候，尽量用批量接口而不是逐条写入，实测能快一个量级。我个人踩过的坑是，一开始贪便宜用很小的embedding模型，中文检索效果惨不忍睹，后来换回bge-m3才稳定下来，所以这一块真不值得省。

做这套东西大半年，我最大的体会是“Wiki长知识”比“RAG找答案”更难，也更值得花时间。很多项目把工夫都花在调模型、调参数上，但真正拉开体验差距的，是Wiki侧的语料结构、内容质量和更新节奏。RAG解决的是“怎么把知识用起来”，前提是得有真正值得用的知识。所以我的建议是，先花几周时间把团队Wiki整理成一个清爽的知识空间，再把RAG接上去，你会看到1+1大于2的效果。最后再补一个小贴士：如果团队还没统一知识库工具，不妨先选了支持Markdown导出、双链、权限管理的Wiki工具再说，这三个能力，决定了你后面接RAG时顺不顺手。