企业官网建设流程全解析

做AI知识库问答，大多数人第一反应是Dify或FastGPT这类“全家桶”平台，界面漂亮、工作流可视化，对新手确实友好。但如果你手头有一批结构复杂的文档——扫描件、老式Excel表格、带公式的PPT，Dify那套“上传即解析”的流程往往会让人怀疑人生。这也是我花了两周时间，把WeKnora本地部署跑通、接上Ollama和DeepSeek，搭出一套完整的开源AI知识库问答系统之后，最想跟你聊清楚的第一件事。

WeKnora是腾讯微信团队开源的一套面向RAG场景的知识库系统，官方定位是“做知识库的解析与召回”。它跟Dify这类通用AI应用平台最大的区别在于：它不管“应用编排”那摊子事，而是专注把“文档进、检索出”这条RAG链条的最底两层做深。文本、PDF、PPT、Excel、图片扫描件，都能先解析成结构化内容，再进入召回阶段。适合谁？如果你手里有大量实际业务文档、想在本地安全地跑一套可私有化部署的问答系统，不希望数据出内网，那它是很合适的底座。我这次就是在一台32G内存的服务器上，完全离线的环境里，把它和本地大模型接起来，做了一套能回答员工入职、制度条文、数据报表类问题的内部知识库问答系统，目前稳定跑了两个月。

1. 为什么最终选了WeKnora：与Dify、FastGPT对比后的选择逻辑

1.1 你真正需要的是一条“能扛住脏文档”的RAG链路

先说一个很反直觉的结论：在RAG问答系统里，大模型往往是最不重要的一环。大部分团队搭知识库问答，最后效果稀烂，问题压根不在模型笨，而在前面的文档解析和检索环节——PDF扫描件进来乱码、Excel多级表头读不懂、PPT里的文字被当成图片忽略、文档被粗暴切成固定长度的小块导致语义断裂。这些问题不解决，你接最强的商用模型还是接DeepSeek，答案都是错的。

Dify和FastGPT这类平台，胜在“全能”：从对话应用、Agent工作流到知识库，一条龙都给你。但知识库只是它们的一个子模块，对复杂文档的处理能力相对有限。WeKnora是反过来的思路——它把整个项目押在“解析+召回”上，不是为了做一个通用AI平台，而是把知识库问答这件事本身做深。

WeKnora处理表格的能力确实值得单独说。它对图片型表格的处理，在这个开源阵营里几乎是独一档的。我在测试时放过一个带合并单元格、三级表头这种反人类结构的Excel，以及一张手机拍的报表照片，Dify和FastGPT基本没法直接给出正确答案，WeKnora可以。

1.2 三款主流开源知识库问答工具的对比

1.3 什么时候你不该选WeKnora

我这里必须泼盆冷水。如果你只是想做一个小Demo，或者你的文档全是干净的Markdown和TXT，Dify反而更省事——它自带一个用起来很顺的管理后台，连文档分块大小都有图形化配置，WeKnora需要你对RAG本身有概念，否则有些参数调不明白容易劝退。另外想做复杂Agent工作流、多轮工具调用的，也绕不开Dify这类平台，WeKnora不提供这些。

所以我的结论是：WeKnora适合对“检索效果”有要求的用户，而不是对“开发效率”有要求的用户。你自己属于哪边，先想清楚再动手。

2. 部署前的关键决策：硬件、模型接入与网络环境

2.1 先给硬件探个底：什么配置才能跑起来

我在部署前先给服务器做了个压力测试。WeKnora整个服务栈由多个容器组成：前端、后端、向量数据库、网关等。CPU内存上，官方推荐是8GB内存起步，但这只是跑起来，真要导入一批文档再做问答，8G会很吃力——几个容器同时吃内存，再叠加一个Ollama，内存溢出几乎是早晚的事。我实际用的32G内存服务器，跑起来后核心服务占用了不到2G左右，Ollama加载7B量化模型再吃掉4到5G，整体还能比较从容。

硬盘方面建议留出至少50G，文档解析过程中会产生大量中间缓存和向量索引，公版镜像本身也有几个GB。我一开始只给系统盘留了30G，导入第3批文档就报警告了，后来把Docker的数据目录迁到数据盘才解决。

2.2 大模型接入的三种方案

这一步必须在部署前想清楚，因为WeKnora本身不含任何生成模型，问答全靠外接。目前主流有三条路：

• 方案A：在线API。包括OpenAI官方、DeepSeek官方等。效果好、部署省事，但对内网部署来说，数据出网是个硬门槛，很多企业直接排除。
• 方案B：本地推理框架。需要处理较多编译和依赖，适合对推理性能有极致要求的场景。
• 方案C：Ollama + 本地量化模型，这是我现在用的。Ollama的优势是模型管理简单，一条命令就能拉模型、起服务，对WeKnora这类系统来说接入也不费劲。

我最终选C，理由有三个：一是数据完全不出内网，满足敏感信息管控；二是Ollama对内存的占用控制比较平缓，量化模型跑在CPU上也能出结果，不必非得有高端显卡；三是升级模型方便，后面如果同事反馈答案质量不够，我去ollama pull拉新版本模型就行，不用动WeKnora本身的配置。

2.3 嵌入模型：别只盯着生成模型

我在最初犯过一个典型的想当然错误：以为只要接上“问答模型”，系统就能工作。实际RAG链路还需要一个嵌入模型，负责把文档和问题都转成向量。嵌入模型的效果直接决定召回的准不准。我在WeKnora里配了bge-m3这个开源中文嵌入模型，官方也支持Ollama方式接入。这一步不能省，否则后面会出现“文档能存进去但问不出来”的诡异现象——数据确实在库里，可检索就是捞不回来，那才是最让人抓狂的情况。

顺带提醒一句：嵌入模型和问答模型是两回事，别填反。我见过有同事把嵌入模型地址填到问答模型里，结果每次回答都返回一堆向量数字，排查半天才意识到是接口填错了。

3. Docker Compose拉起完整服务栈的详细步骤

3.1 拉取项目与准备配置文件

WeKnora官方仓库提供了完整的docker compose编排。我的操作过程大致是：

1. 在服务器上建一个部署目录，把项目源码包拉下来，进入部署目录。
2. 检查env文件，重点确认几个对外端口和本机数据存储路径。
3. 用docker compose up -d拉镜像并启动。

这里我遇到的第一个坑：默认配置里的端口是8080，如果跟你现有服务冲突，记得提前改掉，否则后面改端口还要连带改好几处配置，挺麻烦。没有Docker环境的先装好Docker和Compose插件，这一步不做完后面全是空谈。

3.2 容器启动后的健康检查

镜像数量多，启动时间从几分钟到十几分钟不等。我第一次部署时，前端容器一直显示重启中，进去看日志才明白是等待数据库初始化超时。后来我按官方文档说的，等所有容器进入健康状态再做日志检查。

docker compose up -d docker compose ps docker compose logs -f api

小白容易忽略的是，即使所有容器都变为Up，也不代表能立刻打开页面，后端的模型服务可能还在预热。我建议在浏览器里访问管理后台时，先确认后端接口能正常返回，再开始操作。另外，如果服务器开了防火墙，记得把8080端口和Ollama的11434端口都放通，否则外部浏览器访问不到。

3.3 初始化账号与创建第一个知识库

首次打开管理后台需要初始化管理员账号。初始化完成之后，你就可以看到知识库管理的界面了。创建第一个知识库时，最好先导入一份测试用的PDF或Markdown，把整个“上传—解析—问答”的链路先跑通。我最开始一上来就导入了上千页的资料，结果解析队列堆积，还以为是系统坏了，其实是自己操作顺序不对。

这个经历提醒我：任何新系统第一次使用，务必用最小样本验证全链路，再放大批量。这个习惯能帮你省下大量排查时间，尤其是面对自建系统的时候，因为你无法确定是哪一层出了问题——是解析、索引、检索还是模型生成。

4. 接入Ollama + DeepSeek的完整配置：把问答链路跑通

4.1 安装Ollama并拉取模型

服务器上装Ollama很简单，一条安装脚本就搞定。然后按需拉取模型。我拉的是DeepSeek-R1的蒸馏版7B量化模型，实际用下来对于制度问答和条文检索够用。命令大致是：

ollama pull deepseek-r1:7b ollama run deepseek-r1:7b ollama pull bge-m3

注意bge-m3是嵌入模型，千万别用来做问答。我见过同事把嵌入模型地址填到问答模型里，结果每次回答都返回一堆向量数字，排查半天才意识到接口填错了。

4.2 WeKnora中的模型配置

登录后台，在模型管理里配置两个东西：一个是对话模型，指向Ollama的DeepSeek；一个是嵌入模型，指向bge-m3。地址格式一般是http://<服务器IP>:11434。由于WeKnora和Ollama通常跑在同一台机器或同一内网，直接用内网IP就行，不要写localhost——否则容器里的请求访问的是容器自身，会连不上宿主机。这个细节是我在排查“模型一直连不上”时发现的，改成内网IP立即就好了。

4.3 第一次问答测试

配置完成后，我在测试知识库上传了一份员工手册，然后在问答界面里提问，很快得到了回答。这里说一个很大的感受：WeKnora的问答界面会展示检索到的原文片段，这对我做内部知识库非常重要——答案不是凭空生成的，员工可以点击查证原文位置，减少大模型幻觉风险。这也是我坚持用RAG类系统而不是让模型裸答的核心原因。

4.4 OIDC单点登录的设置（可选）

如果你的内网环境有企业自己的账号体系，比如统一认证平台，WeKnora也支持OIDC方式接入单点登录，这样员工不用单独注册一套账号，直接拿着公司账号就能用。配置时主要是填服务端地址、客户端ID、客户端密钥和回调地址。

这里给一个建议：无论最终要不要切单点登录，都先在本地留一个管理员本地账号，免得回调地址配错之后彻底进不去后台，那时候真是叫天天不应。这个坑我实打实踩过一次，当时搞了半小时才通过命令行改配置把后台救回来。

5. 文档解析与检索调优的实测心得

5.1 解析能力：扫描件不再需要人工转文字

WeKnora内置OCR和版面分析能力，这一点在真实业务场景里太重要了。我测试了一份扫描版合同和一张带印章的照片，它能识别出表格结构，并把印章上的文字也提取出来。对历史扫描档案数字化问答来说，这就省掉了人工转文字的环节，直接把原始扫描件丢进去，系统自己完成“看得见”到“看得懂”的转换。

5.2 分块与召回：影响问答效果的两个隐藏旋钮

RAG链路里，文档分块是一个影响极大的环节。块太大，检索不精准，大模型收到太宽的上下文反而找不到答案；块太小，语义容易断，连接词被切断，召回率下降。我实测下来，对制度条文的文档，每块在300到500字左右比较合适，对代码或数据类内容可以更细。

WeKnora的重排功能是用一个重排模型对召回结果再排序，把最相关的片段排到前面。这个功能建议开启，它能明显提升答案引用的准确性。刚开始我没开，问一些表述不那么直接的业务问题时，回答经常引到相似但不完全正确的段落；开启重排之后，引用准确率提升了一个档次。

5.3 把Excel当问答对象：结构化数据问答的亮点

WeKnora一个亮点是支持把数据表作为问答对象。我在测试时导入了一张业务报表，直接问“上月华南区销售额是多少”，它能定位到具体的表头和数据行。这里有个前提：表格的分组表头、合并单元格、结构越规整，回答越准。如果你手里的表充满各种中文合并单元格，我建议先把表头整理成一行结构再导入，否则解析器再强也架不住数据本身的反人类设计。

6. 本地部署避坑指南：我踩过的典型问题和排查思路

6.1 容器内存耗尽：问题往往出在“隐性内存消耗”

第一次批量导入文档时，我的容器直接崩了。排查之后发现，不是文档太多，而是我在导入的同时，还在后台做了全文问答测试，两项任务叠加，内存瞬间打满。解决方案是给Docker设置内存限制，并且把批量解析和问答错开时段。具体来说，大文件批量导入放在晚上跑，白天只做问答查询，内存压力能明显降下来。

6.2 模型输出中文乱码或不完整

这个问题通常出在Ollama服务或者请求参数上。检查模型温度参数是否调得太高、上下文长度是否太小。DeepSeek系列模型对system prompt比较敏感，如果system prompt里要求提得太长，模型会把上下文窗口撑爆，结果反而截断回答。把上下文长度调到4096以上通常能缓解，温度我建议保持在0.3到0.6之间，太低会显得机械，太高则容易跑偏。

6.3 常规排查顺序

遇到系统不工作，我的排查顺序一般是：

1. 先看容器状态：docker compose ps
2. 再看后端日志：docker compose logs api | tail -100
3. 用curl直接访问后端接口，确认服务是否响应
4. 检查模型服务是否可达：curl http://localhost:11434/api/tags

这个顺序能快速区分是“系统本身的问题”还是“模型服务的问题”。很多人一上来就翻前端代码，纯属浪费时间——大部分时候问题出在后端没有正确连上模型服务，或者向量数据库索引没同步。

6.4 常见问题速查表

本来还想把多知识库隔离和权限管理的部分展开写一写，但篇幅已经不少了，这一篇就先到这里。最后说一点个人体会：本地部署一套开源AI知识库，最难的不是敲命令，而是你在心里对RAG各家系统有一个清晰预期——知道哪一层该由什么工具负责，遇到问题时知道先查哪里。WeKnora在我这边稳定跑了两个月，中间除了换过一次大模型版本，其他几乎没有动过。如果你也正好在选型阶段，建议先把我的测试流程走一遍：拿一批典型的“脏文档”，在Dify和WeKnora里各跑一遍，让数据说话，比自己脑补对比实在得多。