企业官网建设流程全解析

最近刷 GitHub 的时候，看到微信开源了一个知识库项目，社区里一下就热闹起来了。做知识管理的人应该能理解，现在资料分散在本地文档、在线网页、群聊记录里，想找点东西全靠“文件夹整理”和“我记得当时在某个文件里”，效率是真的低。微信开源的这套知识库项目，解决的恰恰就是这件事：把各种格式的资料统一入库，用语义检索找到你想要的内容，再让大模型基于库内资料回答你的问题。对于个人做知识沉淀、小团队做共享知识库，甚至企业想私有化部署一套 RAG 问答系统，都是一个非常合适的起点。

我第一时间把它部署起来，前后跑了大概两周，把日常笔记、技术文档、PDF 报告都导了进去，又接上了本地模型做问答，期间踩了不少坑，也总结出一些实战经验。这篇文章不会只讲“如何一键安装”，而是会把项目的核心原理、部署步骤、参数调优，以及最容易翻车的地方，完整地记录下来。不管你之前有没有用过知识库工具，照着这篇去操作，基本可以少走一大半弯路。

1. 项目概览与解决的核心痛点

1.1 为什么“知识库”突然成了热点？

这几年的知识管理方式经历了两次明显转变。最早大家用文件夹 + 文件名管理资料，搜索依赖文件名和全文匹配；后来工具进化了，出现了 Notion、Obsidian 这类笔记软件，可以打标签、做双向链接，但本质上还是“人工整理 + 被动检索”。直到大模型火了，RAG（Retrieval-Augmented Generation）概念普及，知识库才真正变成一件“自动整理、对话式获取信息”的东西。

所谓 RAG，简单说就是先建立一个可检索的知识库，用户提问时，系统从库里检索相关片段，拼接到提示词里交给大模型回答。这样做的好处是不需要重新训练模型，也能让模型回答基于你私有资料的内容，还能给出引用来源，大大缓解了模型“瞎编”的问题。

现在很多团队和个人都在搭建自己的知识库，因为通用大模型记不住你个人电脑里的笔记、公司内部的 SOP、产品手册。微信开源的这个项目，就是把这条链路完整地打包成了一个可用的产品。

1.2 这个项目能解决什么具体问题

先说结论：它把“文档管理、内容解析、向量索引、语义检索、AI 问答”这几个环节串成一条流水线，同时还做了 Web 界面、API 接口和权限管理。

我实际体验到最舒服的一点，是导入资料后不需要做什么额外操作。PDF、Word、Markdown、TXT、HTML 这些格式都能自动解析。解析完以后，系统会自动把内容切片、向量化，然后你就能在搜索框里用自然语言搜东西了。比如我搜“Scrum 会议怎么开”，不用管哪个文档里写了什么，系统会直接从多份笔记里捞出来相关段落，然后由大模型整理成一段通顺、带引用的回答。

这一点比传统“全文检索”强很多。传统搜索只是把包含关键词的文档罗列出来，你得自己一个个点开看；而 RAG 知识库可以直接给你答案，还告诉你答案出自哪份文件的哪个位置。

1.3 它跟 Obsidian、Dify 这些工具有什么区别

市面上常见的知识管理工具不少，我第一次看到这个项目时也在想，微信是不是在做又一个“笔记软件”？用下来发现，它跟 Obsidian 这类工具定位完全不同。下面这张表可以比较直观地看出差异：

从我个人体验来看，WeKnow 这个项目最值得点赞的地方是“克制”。它没有想着做一个大而全的办公套件，而是围绕“知识库”这一件事，把解析、检索、问答、权限这些做得足够完整。你部署起来以后，它就是一个能立刻用的工具，而不是需要自己写一堆插件才能跑起来的半成品。

2. 核心架构与关键原理拆解

2.1 资料从上传到可检索，中间发生了什么？

要理解这个项目，就不能只看表面的上传按钮。一条数据从你拖拽一个 PDF 进去，到你提问时能找到它，其实经历了五个环节。

第一步是文档解析，针对不同格式调用不同的解析器：PDF 要处理版面、表格和文字块；Word 要提取正文；Markdown 要保留标题结构和代码块。第二步是清洗与切片，把提取出的长文本切成很多小段。为什么要切片？因为向量模型一般对输入长度有上限，而且把整个文档丢进去算相似度，粒度太粗，检索效果很差。项目默认提供了几种切片策略，包括按固定字符数切、按标题切、按语义切。

第三步是向量化，也就是用 Embedding 模型把每一段文字变成一串浮点数向量。两个文本的语义是否接近，就看这两个向量的“距离”有多近。第四步是向量存储，系统会把向量数据写入内置的向量数据库，同时把原始文本也存一份到关系型数据库里，方便后面拉取原文作为引用。第五步是建立索引，为关键词搜索建立倒排索引。这一步容易被忽略，但它恰恰是混合检索里很重要的一个分支。

说到这里，就不得不提一个参数：切片大小（chunk size）和切片重叠（chunk overlap）。这个项目默认的切片大小是 512 个字符，重叠是 50 个字符。我实际试下来，如果是中文技术资料，切片大小设置在 200-300 之间，问答准确率会更高。因为中文一句话承载的信息量比较大，512 字符的切片里很可能混进两个不同主题，检索的时候就容易被干扰。如果你做的是英文文档，512 或 768 都还行。建议先拿一小部分资料测试多组参数，不要一上来就全量导入。

2.2 混合检索：为什么不能只靠向量？

现在的知识库项目基本都会强调“混合检索”。这个项目走的也是这条路线，关键词和向量两端同时搜索，然后把结果合并。

向量检索擅长处理语义层面的相似，比如“人员流动率高”和“员工离职率偏高”这两句话没有什么共同关键词，但意思接近，向量模型能算出它们相似。关键词检索则擅长精确匹配，比如你搜索一个项目代号“JEV-7”，向量的效果很可能不如直接搜索字符串 BM25 的“JEV-7”。所以两种方式互补是很有必要的。

这个项目在检索阶段会把向量召回和关键词召回的结果做融合，常见算法是 RRF（Reciprocal Rank Fusion）。简单理解就是给每个来源的排名打分，综合后挑出 Top-N。之后还有一个重排序（Rerank）环节，用一个更精确的模型对候选片段重新打分，把最相关的内容排到前面。这一步对最终效果的影响非常大。我在实际使用中对比过，同样的知识库和数据，开重排和不开重排，回答质量差了一个档次。

如果你部署以后觉得回答不准确，优先检查两件事：一是有没有开重排模型；二是重排模型有没有正确配置成中文模型。默认配置如果是个英文模型，中文长文档的重排效果会比较弱。

2.3 为什么模型设计成“可以替换”而不是内置？

这个项目本身不包含大模型，它只负责“找到相关资料”和“组装上下文”，至于最后一步“看懂资料并回答”，交给外部的大模型来做。这个设计我觉得非常正确。

不内置模型意味着你可以按自己的场景灵活选择。任意有 OpenAI 兼容接口的模型都能接，也可以接本地部署的 Ollama、DeepSeek、通义千问等。如果你的资料非常敏感，完全可以在纯内网环境部署一个本地大模型，整个知识库问答链路不出本机。

从成本角度看，内置一个大模型既不符合开源社区的习惯，也会让项目体积变得臃肿。每个人对模型的需求不一样，有人追求准确率，有人追求低成本，有人只能离线运行。做成可替换接口，相当于把选择权还给使用者。在后台你只需要填一个 Base URL 和一个 API Key，然后把模型名称写好，测试连通即可。

2.4 多用户与权限管理是怎么处理的

知识库如果只是给自己用，权限无所谓。可一旦团队使用，权限就是刚需。这个项目里内置了用户系统和空间隔离机制。

你可以创建多个知识库，每个知识库可以单独设置“仅自己可见”和“指定成员可见”。管理员账号可以管理成员，成员可以新增、编辑或仅查看。对于中小企业来说，这个能力可以替代早期的 Confluence，虽然没有那么重，但胜在轻巧、完全可控。

有一点我要提醒：权限的核心在应用层，底层数据还是在一个数据库里。如果你特别注重数据隔离，比如不同部门之间不能看到彼此的资料目录结构，最好在物理部署层面做完全隔离，即开两套服务。项目本身的权限设计主要是满足团队协作的常规需求，而不是军工级别。

3. 本地部署与实操配置

3.1 部署前需要准备哪些环境

先列一下我完成部署时的环境，方便你对照：

• 一台 Linux 服务器或本地虚拟机，建议 4 核 CPU、8GB 内存起步；如果想跑本地大模型，建议再加 16GB 以上内存，或者单独的 GPU。
• Docker 和 Docker Compose。这是最省事的部署方式，两个命令就能启动整套服务。
• 一个可以访问外网的网络环境（用于拉取镜像、下载模型）。如果你是纯内网环境，需要提前把 Docker 镜像和模型文件下载好。
• 可选：大模型的 API Key，或者已经配置好 Ollama 服务。

我自己是在一台 8GB 内存的小服务器上部署的，因为只接 API，没有本地跑大模型，所以运行得很流畅。如果你想要一台机器同时跑知识库和本地大模型，那 8GB 不太够，推荐上 32GB 或带独显的设备。

3.2 Docker Compose 一键启动：实操记录

项目官方提供了一份 docker-compose.yml，我精简整理后类似下面这样。注意，不同版本的镜像名和端口可能有所变化，你需要参考官方仓库最新的配置，但整体结构是一样的。

version: "3.8" services: wk-server: image: weknow/weknow-server:latest container_name: weknow-server ports: - "8080:80" volumes: - ./data:/app/data environment: TZ: Asia/Shanghai APP_PORT: 80 DB_TYPE: postgresql DB_HOST: wk-db DB_PORT: 5432 DB_USER: weknow DB_PASSWORD: changeme DB_NAME: weknow VECTOR_STORE: chroma VECTOR_PATH: /app/data/vector depends_on: - wk-db restart: always wk-db: image: postgres:16 container_name: weknow-db environment: POSTGRES_USER: weknow POSTGRES_PASSWORD: changeme POSTGRES_DB: weknow volumes: - ./db:/var/lib/postgresql/data restart: always

把上面的内容保存为 docker-compose.yml，然后在终端里执行：

docker compose up -d

等待镜像拉取完成后，用浏览器访问http://你的服务器IP:8080，第一次进入会让你创建管理员账号。我实测整个流程大概需要 3-5 分钟，取决于镜像拉取速度。

这套部署方案里有两点值得说明：一是把数据目录和数据库目录都挂载到了宿主机，这样后续升级容器不会丢数据；二是向量库用的是内置的 Chroma，它适合单机小规模场景。如果你要支撑上万条文档的大并发检索，建议把向量库换成 Milvus 或 Qdrant，并在 Compose 里增加相应的容器。

3.3 大模型接入的三种方式

部署完以后，第一步不是建知识库，而是先配置大模型。进入后台控制台，找到模型设置项，一般有三种接法。

第一种是 OpenAI 兼容 API。目前市面上绝大多数模型服务都提供这种接口，包括 DeepSeek、Moonshot、智谱等。你只需要填入 Base URL、API Key 和模型名称。比如接入 DeepSeek，Base URL 填https://api.deepseek.com/v1，模型名填deepseek-chat。

第二种是本地 Ollama 模型。这种方式完全离线，适合隐私要求高的场景。首先你在服务器上装好 Ollama，然后拉一个中文能力不错的模型，比如qwen2.5:7b。启动后，模型的 Base URL 填http://host.docker.internal:11434（容器内访问宿主机用），模型名填对应的标签。注意，Ollama 默认只能本机访问，需要在 Ollama 的环境变量里加上OLLAMA_HOST=0.0.0.0，否则容器会连接不上。

第三种是自定义 HTTP 接口模型。如果你有自己的内部模型网关，也可以直接填一个完整 URL。这个用法依赖项目的通用模型适配层，具体规则可以看文档，但不建议普通用户使用。

我自己的建议是：先接 API 跑通流程，等确认知识库效果不错，再考虑换成本地模型。一上来就折腾 Ollama，遇到网络和跨域问题容易打击信心。

3.4 创建知识库并导入第一批文档

进入“知识库”页面，点击新建，填写名称和描述。关键配置项就两个：切片大小和切片重叠。以我的经验，导入中文文档时，切片大小调整为 256，重叠调整为 32 或者 64，效果会比默认值好不少。具体原理之前说过，中文信息密度高，切片大了容易混主题。

接着就可以上传文档了。支持拖拽上传，也可以选择文件目录批量导入。你还可以在文档列表里看到每个文件的状态：待解析、解析中、已入库、失败。第一次上传 PDF 时，如果文件是扫描件（图片型 PDF），你会看到解析成功但搜索不到内容，原因在于这种文件没有文字层，需要 OCR 支持。项目内置了基础 OCR 能力，但对复杂的扫描件，建议先用外部工具处理成文本格式再导入。

第一批文档建议控制在十几份以内，导入完成后先在问答页面测试几个典型问题，看看召回效果。我当初第一轮测试就问“这个项目支持哪些文件格式”，系统直接引用项目文档给出了准确回答，那一刻还是挺有成就感的。

4. 实际使用场景与案例分享

4.1 把个人 Obsidian 笔记库迁进来：从“记过但找不到”到“问一下就知道”

我一直用 Obsidian 写个人笔记，用了两年积累了上千条 Markdown 文件。Obsidian 的双链和图谱很漂亮，但真要找一条具体内容时，全文搜索的体验还是比较粗糙——尤其当关键词记不准的时候。

把 Obsidian 的笔记目录整体拷出来，批量导入到 WeKnow，这一步操作起来并不复杂。导入完成后，我试着搜一个半年前记录的“Async/await 错误处理模式”，结果系统直接把当时记的一段代码片段和相关文章捞了出来，还结合大模型整理成一段带示例的说明。

这就是个人知识库的典型价值。你不需要再记得“我把这条信息放在哪个文件夹”，只需要带着一个模糊的记忆或问题，知识库就能帮你找到并组织答案。同时它把 Obsidian 的定位保留了下来：Obsidian 继续做日常编辑和灵感整理，而 WeKnow 承担了“二次沉淀和查询”的角色。

4.2 帮一个设计工作室搭团队知识库

正好有个朋友的工作室，七八个人，平时资料散落在微信群文件、百度网盘和各自电脑上。找一份设计规范要对半天聊天记录。我给他们部署了一套 WeKnow，做了这么几步：

第一步，建立了几个顶层分类知识库：品牌规范、项目经验、客户资料、会议记录。第二步，把所有历史文件按分类导入。第三步，给每个人创建账号，按角色分配权限：成员可以查看所有知识库，但只有管理员能修改公共资料。第四步，把问答页面发给团队成员，让大家开始用自然语言提问。

效果超出预期。比如新同事入职后想问“之前项目的色彩体系是什么”，直接在统一后台搜，几秒钟就能得到答案和原始文件出处，不需要再去打扰老员工。虽然团队成员都不懂技术，但他们只需要通过浏览器访问一个网址，习惯几天后就能自然使用。

4.3 通过 API 把知识库接进微信小程序

微信开源的项目，天然让人联想到微信生态。如果你有自己的小程序，想做一个“智能客服”或者“资料查询助手”，完全可以让小程序调用 WeKnow 的 API。

WeKnow 提供了 RESTful API，你可以用 Python 的 FastAPI 或 Flask 写一个薄薄的代理层，把小程序请求转发给知识库接口，再把返回结果传给小程序。下面是一个用 FastAPI 写的简化示例：

import requests from fastapi import FastAPI from pydantic import BaseModel app = FastAPI() KB_API_URL = "http://localhost:8080/api/query" KB_API_KEY = "你的API密钥" class QueryRequest(BaseModel): message: str session_id: str = "" @app.post("/kb_query") def kb_query(req: QueryRequest): headers = {"Authorization": f"Bearer {KB_API_KEY}"} payload = {"question": req.message, "top_k": 5} resp = requests.post(KB_API_URL, json=payload, headers=headers, timeout=30) data = resp.json() return { "answer": data.get("answer", ""), "references": data.get("references", []) }

在这个示例中，小程序请求你的后端服务/kb_query，后端再调用 WeKnow 接口。千万不要把小程序的请求直接打到知识库上，一是会暴露 API Key，二是小程序域名白名单会更难配置。中间加一个代理层，既安全又能统一控制流量。

4.4 内网离线方案：在没有外网的环境里也能跑

有时候客户环境是完全内网，不能访问外部的模型 API。需要把整套链路全部放到内网。第一，把 Docker 镜像提前打包，用docker save导出 tar 文件，拿到内网再docker load。第二，在内网机器上部署 Ollama，拉取一个中量级的模型，比如qwen2.5:7b-instruct。这个模型对配置的要求不算太高，32GB 内存的纯 CPU 机器也能跑，就是速度略慢。第三，把知识库的大模型配置指向本机 Ollama 地址。

整个流程跑通后，所有数据解析、向量化、检索、问答全部在内网完成，满足了一些企业数据不出内网的需求。这是开源私有部署最大的魅力所在——数据完全在自己手里。

5. 常见问题与排查技巧实录

5.1 中文语义检索效果差，搜不到想要的内容

这是反馈最多的问题。我自己的排查思路是这样：

先看 Embedding 模型是否适合中文。项目默认带的模型对英文效果好，对中文一般。建议换成bge-large-zh或m3e-large这类中文向量模型。在后台配置模型后，需要重建知识库索引，老索引不会自动更新。

再看切片大小。中文场景下 256 字符是基准线，如果你的文档里包含较多代码或数据，可以适当降低到 128，保证每个切片主题单一。最后检查查询词本身。如果你搜的是“投诉率如何降低”，而库里的文档写的是“客诉处理流程”，语义检索应该能匹配到，但前提是 Embedding 模型必须真正理解这些同义表达。实测下来，换中文 Embedding 模型后，这类问题基本能解决。

一个补充技巧：在提问时可以加上上下文，比如“结合流程文档，回答投诉处理的步骤”，效果往往比一句干巴巴的关键词要好。因为大模型在理解问题时，上下文越具体，最终生成的 query 越精准。

5.2 导入几十份文档后，系统变慢、内存暴涨

知识库变慢的原因，绝大多数出在向量库和索引层。我导入大约 5000 个文档切片后，服务器内存从 1.8GB 涨到了 4.2GB，查询响应时间也明显上升。

解决办法有几条。一是控制导入数量，不要盲目导入重复的文档。二是在后台开启向量库的索引优化。Chroma 默认的索引结构在数据量大时性能衰减，可以设置显式参数切换成 HNSW，并把M和ef_construction参数调高一点，检索速度会有明显改善。三是定期清理历史版本，这个项目支持文档更新，但会保留历史版本，时间久了文件占用很大。在管理后台把历史版本保留数改成 1 即可。

如果你的知识库确实有几十万甚至上百万条切片，建议直接把向量库换成专用的 Milvus 或 Elasticsearch，单机内存方案撑不住这么大的规模。

5.3 大模型回答出现幻觉，直接编造不存在的内容

RAG 最怕的不是答错，而是答得一本正经，但内容是凭空捏造的。发生这种情况，先检查你的提示词策略。

在后台设置中有一个提示词模板，如果模板里只写了“你是助手”，模型就很容易自由发挥。建议把模板改成类似这样的话：“仅根据给定的参考资料作答，如果资料中不包含相关信息，请明确回答‘未找到相关资料’，不要自行补充。”同时把生成参数里的temperature调低到 0.1-0.2，让模型更忠实于给定内容。

另一个有效手段是打开“引用标注”功能。要求模型在回答的每句话后面标注来源，比如标注出自哪个文件名。这样做能让用户判断答案是否真的有文档支撑。我目前使用过程中，凡是模型无法引用来源的答案，基本都可以判定为不可信，需要回来补资料。

5.4 部署中的其他常见坑速查表

这些坑几乎都会遇到，尤其是首次部署时，先对照表格排查，能省下不少时间。

6. 我的实操心得与更多玩法

先把话放在前面：无论用哪个知识库项目，决定效果的永远不是部署脚本，而是你导入的数据质量。我见过有人随便扔进去几百个文件，然后抱怨搜索不准，其实文件里一堆无关广告和乱码，再强的检索模型也无能为力。所以导入前做好清洗，把重复、无效、过期内容先处理掉，效果一定翻倍。

关于切片参数，我强烈建议每次只改一个变量，然后跑一组测试集对比。我自己会准备 20 个有明确出处的测试问题，每次调整完就挨个问一遍，看命中率和引用正确率。这个方法听起来笨，但它最可靠，比人眼“感觉”准多了。

这个项目后续还想做得更多，我打算把它的 API 接入到日常的 CI 流程里。比如每次文档更新后，自动触发知识库增量导入，让线上内容始终保持最新。对于想搭建企业级智能客服的人来说，这套知识库完全可以作为中台底座，前端接一个聊天界面，后端接企业内部的工单系统。开源项目的意义就在于你可以按自己的需求去改造它，而不是被某个 SaaS 平台锁死。

最后分享一条经验：部署完成后，先不要急着填各种复杂参数，先用默认配置导入一份你最常查的文档，跑通整个闭环，再逐步调优。知识库这种东西，只有真正查起来好用，你才会坚持用；而坚持用下去，它才会越来越成为你的第二大脑。我们踩过的坑，希望你在部署时能绕过去。