企业官网建设流程全解析

如果你也在做企业内部知识库，大概率会陷入同一种困境：资料攒了一大堆，OA里的文档、Wiki里的沉淀、群文件里的培训材料，全都在，但真要找答案时，搜索半天翻不到，问同事也问不到人。这就是典型的知识库“存而不用”。最近我把腾讯微信团队开源的 WeKnora 拉到本地跑了一遍，这个东西解决的就是“怎么把文档变成能对话的知识库”这件事——基于RAG路线，把检索、分块、向量化、问答串成一条流水线，最后变成一个可以私有化部署的问答系统。这篇就把我的搭建过程、踩坑点、调优思路和选型对比一次说完。

对想搞AI知识库的人来说，这篇适合两类读者：一类是刚接触RAG，想找一个开箱即用的开源项目当切入点；另一类是在 Dify、RagFlow、WeKnora 之间犹豫，不知道选哪个。我会尽量少讲概念堆砌，多讲实际操作，包括配置里哪些参数值得优先调、遇到检索不到内容时应该先查哪个环节。

1. 为什么微信团队要开源 WeKnora：AI知识库的底层逻辑

1.1 从“文档堆放”到“对话式知识库”

传统知识库最大的问题，是把“存储”当成了“目的”。文件上传、目录分类、全文检索，顶多再加个标签体系。用户要找东西，得先猜关键词，再翻一堆结果。这种模式在资料少的时候还凑合，一旦文档量上来，搜索结果的排序质量就直线下降。

WeKnora 走的是RAG路线，全称可以理解为“检索增强生成”。它做的事是：把文档切块、向量化、存进向量库，等用户提问时，先把问题也向量化，然后去库里召回最相关的内容片段，再把片段拼成上下文交给大模型生成答案。也就是说，知识库不再只是“给你一堆链接”，而是直接给你“基于资料整理出的回答”。

我在实际操作里最明显的感受是，WeKnora 把这条链路做成了产品化流程，而不是只给一堆代码让你自己拼。你上传 PDF、Word、Markdown，它自动解析、分块、建索引；你配置好大模型接口，它就能在同一个界面上完成对话。对团队来说，这比从 LangChain 手搓一个问答系统省事得多。

1.2 微信团队为什么要做这件事

微信团队做 WeKnora，我理解不只是做一个“AI搜索框”。从开源项目的命名和模块划分来看，它更想解决的是企业知识库的“最后一公里”：文档进来了，但怎么让知识被准确调用？怎么让不同角色看到不同的知识？怎么控制回答内容不越界？

这些需求在个人项目里不太明显，在企业环境里却是刚需。举个例子，一个售前团队的知识库，和售后团队的知识库，资料可能是同一套产品文档，但关注点完全不同。如果只有一个全局搜索，所有人拿到的是同样的结果，内部知识库用起来就会很别扭。WeKnora 这一类平台级知识库，在设计上会更多考虑权限、空间隔离、多种检索策略组合，而不是只做一个“大模型聊天框包了一层文档查询”。

另外，微信团队开源它，还有一个现实原因：微信生态内有大量公众号文章、聊天记录、客服话术，这些内容格式杂、质量参差、实时性强，非常适合用来验证知识库的解析和检索能力。所以你会发现它在文档解析上做得比较细，对多级标题、表格、图片混杂的文档，处理效果比很多“半拉子”开源方案要稳。

1.3 适合谁用，不适合谁用

先说适合的。如果你的团队已经有了一堆散落的文档，想快速搭一个内部问答机器人；或者你想把产品手册、技术规范、培训材料变成可检索的知识资产；再或者你正在做 AI Agent，需要给 Agent 配一个“长期记忆”和“事实来源”——WeKnora 这类RAG平台都很合适。

不适合的情况也有几种。第一，你的知识库只有十几个文件，那根本不用上平台，直接用现成的 AI 搜索引擎或者 Dify 的简易知识库就够了，没必要多部署一套系统。第二，你想要的是“让大模型自己胡编乱造搞创作”，不是“基于真实资料回答问题”，那知识库模式会限制你。第三，你的团队没人愿意持续维护和更新知识库，那无论用什么工具，最后都会变成一堆过时的索引。工具解决的是效率问题，不是管理问题。

2. 核心功能拆解：我能拿 WeKnora 做什么

2.1 多格式文档解析与图片处理

知识库项目最容易被低估的环节是文档解析。很多人以为把 PDF 塞进去就能用，实际上PDF里的扫描件、表格线、分栏排版，每一样都可能让检索效果断崖式下降。

WeKnora 在文档解析层面提供了比较完整的处理链：文本型 PDF 直接抽文本，扫描型 PDF 走 OCR，Word、Excel、PPT、Markdown 都有对应解析器。需要注意的是，图片类内容不只是“OCR成文字”这么简单。我试过把产品截图放进去，系统会识别图中的文字，但纯图片上的图表趋势、颜色含义，如果没有额外补充文字说明，知识库依然很难理解。所以“RAG知识库能存图片吗”这个问题的答案是：能存、也能搜到，但图片必须结合文字描述，检索效果才有保障。

实操建议是：上传文档前，给重要图片补一句上下文说明，比如“下图展示了2024年各季度营收趋势，柱状图显示Q4最高”。这样切块之后，文字和图片的语义才能关联起来。不要指望知识库具备人类的看图能力，现阶段多模态模型能理解视觉信息，但成本高、响应慢，文本描述依然是性价比最高的方案。

2.2 混合检索与重排：不是简单向量匹配

早期RAG项目喜欢搞“向量检索一统天下”，但用过的都知道，纯向量检索有两个毛病：一是对精确关键词不敏感，比如搜“售后电话”，向量找出来的可能是“客户服务热线”；二是对数字和产品型号很不友好，型号“WR-3000”和“WR-3000Pro”在向量空间里会被当成接近的内容，但实际是完全不同的产品。

WeKnora 的实现更接近工程上验证过的套路：向量检索 + 全文检索做召回，再用重排模型对结果精排。全文检索负责精确命中，向量检索负责语义扩展，重排负责把最相关的几条挤到前面。我在试跑时对比过，同一批测试问题，加了全文召回之后，带型号和数字的准确率提升非常明显。如果你的知识库里有大量产品编号、合同号、代码变量名，建议务必把全文检索和重排都打开，别省这一步。

这里面有个常见误区：以为召回数量越多越好。实际不是。把 Top-K 从5调到20，召回更多内容不假，但噪声也进来了，大模型的注意力会被无关段落带偏，回答反而更差。我建议先从 K=5 或 K=8 起步，看回答不满意再慢慢加大，而不是一上来就召回二十条。

2.3 在RAG流水线上做知识库编排

WeKnora 这类平台级项目，和 Dify 这类低代码平台的边界，很多人会搞混。Dify 更偏向“工作流编排”，你可以把知识库当作检索节点，塞进一个更大的 Agent 流程里，比如先判断用户意图，再决定走哪个知识库。WeKnora 的重点则更聚焦在“知识库本身”：文档怎么管理、切片怎么优化、检索怎么调优、权限怎么隔离。

所以在实际项目中，两者不是非此即彼。完全可以用 WeKnora 作为知识库底座，把检索接口提供给上层 Agent 平台调用。我调研下来的结论是，如果团队已经用了 Dify 做 Agent，只是缺一个能打的知识库，那可以考虑用 WeKnora 补齐检索这一层，而不是在 Dify 里硬堆知识库文件。反过来，如果你不需要复杂的知识库管理，只想要十个文件快速跑通问答，Dify 自带的简易知识库就够用。

3. 本地部署实操：零基础也能跑起来的完整流程

3.1 环境准备：Docker与模型选型

WeKnora 的部署方式对新手比较友好，最省事的路径是用 Docker Compose 拉起全套服务。你需要准备的机器，我建议最少 16GB 内存，原因不是 WeKnora 本身吃很多资源，而是你通常还要跑一个嵌入模型和一个大模型。如果机器只有 8GB，跑是能跑，但检索和回答都会明显变慢。

模型选型上，我建议拆成两步考虑。嵌入模型负责把文本转成向量，推荐用 bge-m3、text2vec 这类中文表现不错的开源模型；大模型负责生成答案，可以用 OpenAI 兼容接口，也可以本地跑 Qwen、Llama 系列。热搜里有人问“Llama 适合国内企业拿来搞知识库问答和私有化 Agent 部署吗”，我的看法是：通用能力上 Llama 系列没问题，但中文场景里 Qwen 的语义理解和输出稳定性通常更顺手。如果你没有强依赖 Llama 的理由，优先考虑 Qwen 系列做生成端，嵌入端用 bge-m3，成本低、效果好。

这里有个很多人忽略的点：嵌入模型和大模型的硬件要求不一样。嵌入模型很小，CPU 就能跑；大模型才是吃显存的大头。所以预算有限的情况下，优先保证大模型显存，嵌入模型用 CPU 跑完全可行。我在测试时就是 7B 量级的 Qwen + CPU 嵌入模型，16GB 内存的笔记本照样能带起来。

3.2 配置文件里的四个关键参数

部署过程中最值得花时间研究的，不是怎么启动容器，而是配置里这几个参数。

第一个是文档切块大小。WeKnora 默认的切块策略通常按 token 数控制，比如 300 到 800。切块太大，检索会召回大段无关内容，浪费上下文；切块太小，语义完整性被切碎，检索召回率下降。我实测下来，中文技术文档建议从 400 token 起调，配合 50 到 100 的 overlap（重叠长度）。overlap 的作用是避免一个完整句子被硬生生切开，让两个相邻切块之间保留一点共同上下文。

第二个是相似度阈值。检索阶段如果阈值设得太高，比如 0.9，很多相关文档会被过滤掉；设成 0.7 又可能混进大量噪声。我的习惯是先跑一批测试问题，观察召回的分数分布，再决定阈值。多数知识库场景，相似度阈值设在 0.75～0.85 之间比较合理，具体要看你用的嵌入模型和文档类型。

第三个是 Top-K 召回数量。前面说过，不要贪多。从 5 起步，逐个问题测，回答不够详实再增加到 8 或 10。第四个是 prompt 模板。WeKnora 一般会内置默认模板，但默认模板通常偏通用，没有结合你的知识库上下文。我建议在模板里明确写一句“如果资料中没有明确信息，请直接说不知道，不要猜测”，这能明显减少大模型上下文幻觉。

3.3 从上传文档到回答问题：一份可直接照抄的步骤

我在本机试跑时，整个流程大概可以分成五步，每一步都会有反馈信息可查，排查起来还算顺手。

第一步，用 Docker Compose 启动依赖服务，包括向量数据库、中间件、API 服务。启动完成后先检查容器日志，看到“healthy”或者“running”状态再继续。我最开始忽略了这一步，直接去上传文档，结果接口报错，后来才发现是向量库没就绪。

第二步，在管理后台创建知识库，配置解析方式。针对文档里包含扫描图片的情况，把 OCR 开关打开；针对纯文本文档，OCR 可以关掉，能省不少时间。

第三步，配置嵌入模型并上传文档。上传之后系统会进入解析和切块流程，你可以在任务列表里看到每个文件的处理状态。这个阶段最容易出问题的是表格类文档，解析后经常丢失层级关系，所以上传前先抽样几页检查效果。

第四步，配置大模型接口。把 API 地址、模型名、密钥填进系统。本地模型用 Ollama 的话，如果 Ollama 和 WeKnora 不在同一台机器，注意不要写“localhost”，要写实际局域网 IP。

第五步，在问答测试界面里输入问题。可以先挑文档里明确存在的专业术语问一遍，确认召回是否命中；再问一个文档里没有的问题，确认回答不会乱编。这样一轮下来，知识库基本就能用了。

3.4 常用调优手段与性能观察

跑通还只是开始，真正费时间的是调优。我常用的调优顺序是：先看文档解析效果，再看检索召回内容，最后才调 prompt。很多人在回答不准确时上来就改 prompt，其实顺序反了。如果检索阶段就没召回正确答案，prompt 写得再好都是空中楼阁。

检索效果怎么看？在管理后台的检索测试功能里，输入问题，系统会列出召回的片段和分数。一条条翻，问自己：正确答案在里面吗？在的话，为什么排名不够靠前？不在的话，是切块切坏了，还是文档本身没有这个信息？这一步是调优的地基。

性能方面，如果要支持团队多人同时使用，建议至少 16GB 显存的消费级显卡起步，或者直接用 API 服务。本机部署更适合演示和个人试玩，真要生产，优先保证并发量和响应时间。

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

4.1 文档解析后全是乱码，怎么查

乱码问题十有八九出在扫描版 PDF 或特殊编码的 Word 文档上。排查思路很简单：先看系统日志里解析器是否报错，再看解析后的纯文本内容。如果纯文本是乱码，但原 PDF 是文字版，尝试换一个解析引擎；如果是扫描版，确认 OCR 是否启用。还有一种情况是文档包含大量图片，解析慢到像卡住，其实是在排队 OCR，不是死机。

我踩过最典型的一个坑是 Excel 文件：多个 sheet 的表格，解析后只保留了第一个 sheet。后来发现系统默认只解析当前工作表，需要提前把其他 sheet 导出成独立文件再上传。这个细节在文档里写得不明显，但对实际使用影响很大。

4.2 答案“答非所问”，先检查这三个环节

回答不准，通常不是大模型能力不够，而是知识库链路里某一段出了问题。第一个环节是切块，如果答案对应的内容被切碎在多个块里，检索时可能只召回一半；第二个环节是召回阈值，阈值设置过高，正确答案被过滤了；第三个环节是忠实度，如果你没在 prompt 里要求模型只能基于资料回答，模型就可能自由发挥。

我的排查法则是：同一个问题，先用检索测试看召回结果。召回结果没问题，问题在生成端；召回结果不对，问题在解析、切块或检索配置。定位到具体环节再动参数，比盲调 prompt 高效得多。

4.3 部署机器内存不够，有哪些降级方案

内存不够的大头通常在于大模型推理。降级方案按效果排序：优先换更小参数量的大模型，比如从 14B 降到 7B；其次考虑把大模型部署到远端服务器，本机只跑 WeKnora 和向量库；最后才是减少向量库内存占用，比如换更轻量的向量索引类型。嵌入模型对内存的占用远小于生成模型，CPU 跑嵌入完全没问题。

如果只是个人试用，还有一个更极限的方案：用商用大模型 API 当生成端，嵌入模型依然本地跑。这样既保证回答质量，又能把文档数据留在本地，只是调用 API 会有一点网络请求。数据敏感度高的场景，别这么干。

4.4 问题速查表

5. 与 Dify、RagFlow 等开源知识库的选型对比

5.1 三款主流开源RAG平台横评

现在市面上一线开源知识库方案，绕不开 Dify、RagFlow 和 WeKnora 这三个。Dify 的优势是工作流编排能力强，不只做知识库，还能做 Agent 应用；RagFlow 主打文档深度解析，尤其是 PDF 排版的还原度；WeKnora 更偏向企业级知识库的检索和权限设计。

从部署复杂度看，Dify 的界面和功能最全，但初学者容易迷失在大量配置里；RagFlow 安装相对简单，文档解析能力突出；WeKnora 的架构更贴近企业内部系统，权限隔离和检索调优做得很细。从我实测的感受来说，如果你要的是“大而全的应用平台”，Dify 更合适；如果要处理大量版面复杂的 PDF，RagFlow 值得优先试；如果目标是“建一个长期维护的企业知识库”，WeKnora 的定位更精准。

5.2 按场景选型：个人玩、小团队、企业级

个人试玩或学习，我反而推荐 Dify，因为它的可视化界面能帮你快速理解知识库、Agent、模型之间的关系，学习曲线最平滑。小团队内部用，建议看两个维度：文档类型是否复杂、是否有权限隔离需求。如果文档普遍是 PDF 和扫描件，RagFlow 更能救；如果团队已经有明确的文档管理和权限体系，WeKnora 的贴合度更高。

企业级部署，我建议不要只看单个软件功能，还要评估运维成本。WeKnora 这类项目模块多，Docker Compose 起来简单，但真正生产化之后，模型更新、索引重建、日志监控都要有人打理。开源平台只是底座，最终效果取决于你是否配置了合理的人员来维护知识质量。

我用下来最深的体会是：知识库能不能用好，七分在内容治理，三分在工具。WeKnora 解决的是“检索准确、回答可溯源”这一层的问题，但前提是文档你得定期整理、过期资料要及时下架、回答中信源要能点击查看原始段落。否则再强的 RAG 平台，也会被你自己的文档状态拖垮。

最后分享一个小技巧：每次批量更新文档之后，不要直接相信“索引已更新”的提示。拿三个高频问题重新测一遍检索，确认新文档被正确召回、旧版本不再返回，再对业务用户开放。这个习惯帮我提前拦下了好几次“知识库答错但没人发现”的事故。