如何在没有外网的内网服务器上跑通 WeKnora从环境检查到第一份文档问答的完整实操【免费下载链接】WeKnoraOpen-source LLM knowledge platform: turn raw documents into a queryable RAG, an autonomous reasoning agent, and a self-maintaining Wiki.项目地址: https://gitcode.com/GitHub_Trending/we/WeKnora假设你的场景是这样的一台公司内网的服务器连不上公网但老板要求把几十年的 PDF 合同、Word 制度文档做成一个可以问一嘴就出答案的知识库。云端大模型 API 在这里完全不适用——网络不通数据也不能外流。这篇文章带你把 WeKnora 完整部署在这台机器上。它本身就是一个开源的 LLM 知识平台把上传的文档解析、分块、向量化再结合本地大模型做检索增强问答。走完本文你手上会有一个可以离线运行的文档问答系统解析 PDF、Word 等十几种格式问答全程不碰外网。跑通之后向量检索响应一般在 300 毫秒内8 核 CPU 下解析吞吐大约 50 页/分钟16GB 内存跑 7B 模型的单轮回答延迟通常压在 2 秒以内。先看懂再动手一份文档上传后会经过哪几步在敲命令之前花三分钟把系统摸透后面排查问题会顺很多。你上传一份 PDF 之后它的路径大致是先进入文档解析服务docreader这个服务内置了多套解析引擎会根据文件类型自动路由——扫描件会渲染成图片再走 OCR纯文本 PDF 直接抽取文本层解析结果被切成一个个带语义边界的块接着向量化服务把每个块送进本地嵌入模型变成一串向量存进向量库原始文件则落到本地存储目录留底。提问时走的是反向链路你的问题先被理解和改写然后系统用全文关键词 向量相似度混合的方式从库里捞出最相关的若干块可选地再做一次重排序最后把这些块拼进提示词交给本地大模型生成回答。所以它答得准不准一半取决于解析切块的质量一半取决于检索捞回来的片段对不对。存储这一层有三个角色PostgreSQL 存所有元数据知识库、会话、用户向量库存嵌入向量MinIO或直接用本地目录存原始文件。你可能会问为什么模型要用 Ollama 而不是云 API原因很简单粗暴——你的机器没有外网而 Ollama 可以把对话模型和嵌入模型都放在本机推理数据一步都不出机房。为什么用 Docker Compose 而不是 K8s因为这套系统总共十来个容器一个 compose 文件就能编排内网运维的人不用再多学一套工具。为什么解析器要本地化云端文档解析 API 意味着敏感文档要发到别人的服务器上这在内网合规面前是过不去的。跟着做一遍把整套服务拉起来⚠️ 离线场景下最大的坑是镜像服务器拉不到 Docker Hub。务必先在一台有网的机器上把镜像导出docker save拷贝到内网机器后docker load后面启动时才敢加--no-pull。先确认硬件够不够用系统对硬件没有硬性门槛但体验差别很大建议按下表自查项目能跑起来的底线用起来舒服分配建议CPU8 核16 核把约一半核心留给模型推理内存32GB64GBOllama 跑 7B 模型是大头别卡死内存上限磁盘200GB SSD500GB NVMe文件与向量目录最好单独分区装好 Docker≥20.10和 Compose v2 后用docker --version、docker compose version各验证一次。拉代码把离线参数配好在有网的跳板机上克隆代码再整体拷贝进内网或者内网机器有缓存也可以直接执行git clone https://gitcode.com/GitHub_Trending/we/WeKnora cd WeKnora所有可调参数都收在一个环境变量文件里从模板复制一份出来改cp .env.example .env重点确认这几处完整说明见 .env.example 里的注释STORAGE_TYPElocal——文件直接存本地目录离线环境的正确姿势OLLAMA_BASE_URL——指向 Ollama 所在地址。若 Ollama 和容器在同一台宿主机保持默认http://host.docker.internal:11434即可OLLAMA_OPTIONALtrue——Ollama 没就绪时系统只告警不崩首次部署建议保留。改完顺手留个底cp .env .env.bak。一键启动全部服务先跑一遍环境自检它会检查配置文件是否齐全并诊断常见问题./scripts/check-env.sh确认没问题后分两步把东西拉起来。Ollama 负责模型推理单独启动./scripts/start_all.sh --ollama再把模型拉进 Ollama——嵌入模型和对话模型各一个离线机器上同样需要提前准备ollama pull bge-m3 ollama pull deepseek-r1:7b最后启动主服务集群--no-pull表示不再去仓库拉镜像前提是你已经docker load好了./scripts/start_all.sh --no-pull跑完用docker compose ps看一眼frontend、app、docreader、postgres、redis 等容器都应该是 Up 状态其中 app 有健康检查显示 healthy 才算真正就绪。上传第一份文档并提问浏览器打开http://localhost首次使用直接注册账号登录。接下来按界面引导走新建一个知识库 → 上传一份本地 PDF → 等解析进度跑完你会看到文档被切成的块列表然后打开会话窗口直接问这份文档的主要内容是什么。如果回答里带着原文的引用说明从解析、向量化到本地模型推理的整条链路都通了。跑起来之后调优、排障和安全收口性能往哪里拧慢的地方通常就三处解析、向量化、检索。解析慢多半是大扫描件 PDF把 .env.example 里的DOCREADER_PDF_RENDER_PARALLELISM从默认值调大比如 4前提是容器分到了足够的 CPU渲染是并行最明显的环节向量化排队可以设BATCH_EMBED_SIZE控制批量大小在内存紧张时调小更稳问答太慢优先减少检索返回的块数、或关闭重排序用一点准确度换速度。改完环境变量重启对应容器即可生效。平时盯这几个信号CPU 常态 30%~70%、连续 5 分钟超 85% 就该看看是谁在空转内存 40%~60% 健康超 80% 注意是不是模型吃光了向量检索响应正常在 200ms 内稳定超过 500ms 要检查向量库负载问答端到端超过 5 秒先怀疑模型没跑在预期设备上。高频问题及解法问题app 容器起不来或反复重启原因内存不足、端口被占、或配置文件语法错误。 解决free -m和df -h先看资源docker compose logs app看最后几条报错netstat -tulpn查 80/8080 是否已被占用。问题某份文档解析失败其他文件正常原因文件本身损坏、加密或超过大小上限默认MAX_FILE_SIZE_MB50。 解决file 文件名确认它是不是真的 PDF核对大小限制再看docker compose logs docreader里的具体报错。问题系统能打开、文档也传上去了但一问就提示模型不可用原因OLLAMA_OPTIONALtrue的设计就是 Ollama 没好也不拦你所以表面一切正常实际模型缺席。 解决确认OLLAMA_BASE_URL可达ollama list检查模型是否真的拉下来了Ollama 侧有报错就看它的日志。上线前顺手做几件事端口收口默认只对宿主机暴露前端 80 和后端 8080其他服务的端口能不映射就不映射账号收口人员都建好后把DISABLE_REGISTRATION设为true关掉注册入口数据库密码换成强密码.env文件权限收严且永远不要提交进版本库数据收口文件目录放在卷里宿主机目录权限设成 700多用户使用时靠租户空间划分数据边界天然隔离备份收口每天定时导出数据库并归档文件目录脚本可以很短——docker compose exec -T postgres pg_dump -U 用户名 库名 backup_$(date %Y%m%d).sql tar -czf files_$(date %Y%m%d).tar.gz /path/to/data-files用户名和库名以.env里的实际值为准。最后接下来还能做什么到这里一台无外网的服务器上已经跑起了完整的文档问答系统解析、检索、推理全部本地完成数据不出机房。如果之后想再进一步方向有三个给模型推理加 GPU 加速把延迟再压一半、把大模型量化成更小规格以适配低内存机器、以及把多实例拆开做分布式扩展。更多细节可以查 config/config.yaml 的完整配置、config/builtin_models.yaml.example 的内置模型声明模板以及 docs/QA.md 的常见问题文档。【免费下载链接】WeKnoraOpen-source LLM knowledge platform: turn raw documents into a queryable RAG, an autonomous reasoning agent, and a self-maintaining Wiki.项目地址: https://gitcode.com/GitHub_Trending/we/WeKnora创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/6 15:09:23 · 阅读 1.2k 如何在没有外网的内网服务器上跑通 WeKnora：从环境检查到第一份文档问答的完整实操
如何在没有外网的内网服务器上跑通 WeKnora从环境检查到第一份文档问答的完整实操【免费下载链接】WeKnoraOpen-source LLM knowledge platform: turn raw documents into a queryable RAG, an autonomous reasoning agent, and a self-maintaining Wiki.项目地址: https://gitcode.com/GitHub_Trending/we/WeKnora假设你的场景是这样的一台公司内网的服务器连不上公网但老板要求把几十年的 PDF 合同、Word 制度文档做成一个可以问一嘴就出答案的知识库。云端大模型 API 在这里完全不适用——网络不通数据也不能外流。这篇文章带你把 WeKnora 完整部署在这台机器上。它本身就是一个开源的 LLM 知识平台把上传的文档解析、分块、向量化再结合本地大模型做检索增强问答。走完本文你手上会有一个可以离线运行的文档问答系统解析 PDF、Word 等十几种格式问答全程不碰外网。跑通之后向量检索响应一般在 300 毫秒内8 核 CPU 下解析吞吐大约 50 页/分钟16GB 内存跑 7B 模型的单轮回答延迟通常压在 2 秒以内。先看懂再动手一份文档上传后会经过哪几步在敲命令之前花三分钟把系统摸透后面排查问题会顺很多。你上传一份 PDF 之后它的路径大致是先进入文档解析服务docreader这个服务内置了多套解析引擎会根据文件类型自动路由——扫描件会渲染成图片再走 OCR纯文本 PDF 直接抽取文本层解析结果被切成一个个带语义边界的块接着向量化服务把每个块送进本地嵌入模型变成一串向量存进向量库原始文件则落到本地存储目录留底。提问时走的是反向链路你的问题先被理解和改写然后系统用全文关键词 向量相似度混合的方式从库里捞出最相关的若干块可选地再做一次重排序最后把这些块拼进提示词交给本地大模型生成回答。所以它答得准不准一半取决于解析切块的质量一半取决于检索捞回来的片段对不对。存储这一层有三个角色PostgreSQL 存所有元数据知识库、会话、用户向量库存嵌入向量MinIO或直接用本地目录存原始文件。你可能会问为什么模型要用 Ollama 而不是云 API原因很简单粗暴——你的机器没有外网而 Ollama 可以把对话模型和嵌入模型都放在本机推理数据一步都不出机房。为什么用 Docker Compose 而不是 K8s因为这套系统总共十来个容器一个 compose 文件就能编排内网运维的人不用再多学一套工具。为什么解析器要本地化云端文档解析 API 意味着敏感文档要发到别人的服务器上这在内网合规面前是过不去的。跟着做一遍把整套服务拉起来⚠️ 离线场景下最大的坑是镜像服务器拉不到 Docker Hub。务必先在一台有网的机器上把镜像导出docker save拷贝到内网机器后docker load后面启动时才敢加--no-pull。先确认硬件够不够用系统对硬件没有硬性门槛但体验差别很大建议按下表自查项目能跑起来的底线用起来舒服分配建议CPU8 核16 核把约一半核心留给模型推理内存32GB64GBOllama 跑 7B 模型是大头别卡死内存上限磁盘200GB SSD500GB NVMe文件与向量目录最好单独分区装好 Docker≥20.10和 Compose v2 后用docker --version、docker compose version各验证一次。拉代码把离线参数配好在有网的跳板机上克隆代码再整体拷贝进内网或者内网机器有缓存也可以直接执行git clone https://gitcode.com/GitHub_Trending/we/WeKnora cd WeKnora所有可调参数都收在一个环境变量文件里从模板复制一份出来改cp .env.example .env重点确认这几处完整说明见 .env.example 里的注释STORAGE_TYPElocal——文件直接存本地目录离线环境的正确姿势OLLAMA_BASE_URL——指向 Ollama 所在地址。若 Ollama 和容器在同一台宿主机保持默认http://host.docker.internal:11434即可OLLAMA_OPTIONALtrue——Ollama 没就绪时系统只告警不崩首次部署建议保留。改完顺手留个底cp .env .env.bak。一键启动全部服务先跑一遍环境自检它会检查配置文件是否齐全并诊断常见问题./scripts/check-env.sh确认没问题后分两步把东西拉起来。Ollama 负责模型推理单独启动./scripts/start_all.sh --ollama再把模型拉进 Ollama——嵌入模型和对话模型各一个离线机器上同样需要提前准备ollama pull bge-m3 ollama pull deepseek-r1:7b最后启动主服务集群--no-pull表示不再去仓库拉镜像前提是你已经docker load好了./scripts/start_all.sh --no-pull跑完用docker compose ps看一眼frontend、app、docreader、postgres、redis 等容器都应该是 Up 状态其中 app 有健康检查显示 healthy 才算真正就绪。上传第一份文档并提问浏览器打开http://localhost首次使用直接注册账号登录。接下来按界面引导走新建一个知识库 → 上传一份本地 PDF → 等解析进度跑完你会看到文档被切成的块列表然后打开会话窗口直接问这份文档的主要内容是什么。如果回答里带着原文的引用说明从解析、向量化到本地模型推理的整条链路都通了。跑起来之后调优、排障和安全收口性能往哪里拧慢的地方通常就三处解析、向量化、检索。解析慢多半是大扫描件 PDF把 .env.example 里的DOCREADER_PDF_RENDER_PARALLELISM从默认值调大比如 4前提是容器分到了足够的 CPU渲染是并行最明显的环节向量化排队可以设BATCH_EMBED_SIZE控制批量大小在内存紧张时调小更稳问答太慢优先减少检索返回的块数、或关闭重排序用一点准确度换速度。改完环境变量重启对应容器即可生效。平时盯这几个信号CPU 常态 30%~70%、连续 5 分钟超 85% 就该看看是谁在空转内存 40%~60% 健康超 80% 注意是不是模型吃光了向量检索响应正常在 200ms 内稳定超过 500ms 要检查向量库负载问答端到端超过 5 秒先怀疑模型没跑在预期设备上。高频问题及解法问题app 容器起不来或反复重启原因内存不足、端口被占、或配置文件语法错误。 解决free -m和df -h先看资源docker compose logs app看最后几条报错netstat -tulpn查 80/8080 是否已被占用。问题某份文档解析失败其他文件正常原因文件本身损坏、加密或超过大小上限默认MAX_FILE_SIZE_MB50。 解决file 文件名确认它是不是真的 PDF核对大小限制再看docker compose logs docreader里的具体报错。问题系统能打开、文档也传上去了但一问就提示模型不可用原因OLLAMA_OPTIONALtrue的设计就是 Ollama 没好也不拦你所以表面一切正常实际模型缺席。 解决确认OLLAMA_BASE_URL可达ollama list检查模型是否真的拉下来了Ollama 侧有报错就看它的日志。上线前顺手做几件事端口收口默认只对宿主机暴露前端 80 和后端 8080其他服务的端口能不映射就不映射账号收口人员都建好后把DISABLE_REGISTRATION设为true关掉注册入口数据库密码换成强密码.env文件权限收严且永远不要提交进版本库数据收口文件目录放在卷里宿主机目录权限设成 700多用户使用时靠租户空间划分数据边界天然隔离备份收口每天定时导出数据库并归档文件目录脚本可以很短——docker compose exec -T postgres pg_dump -U 用户名 库名 backup_$(date %Y%m%d).sql tar -czf files_$(date %Y%m%d).tar.gz /path/to/data-files用户名和库名以.env里的实际值为准。最后接下来还能做什么到这里一台无外网的服务器上已经跑起了完整的文档问答系统解析、检索、推理全部本地完成数据不出机房。如果之后想再进一步方向有三个给模型推理加 GPU 加速把延迟再压一半、把大模型量化成更小规格以适配低内存机器、以及把多实例拆开做分布式扩展。更多细节可以查 config/config.yaml 的完整配置、config/builtin_models.yaml.example 的内置模型声明模板以及 docs/QA.md 的常见问题文档。【免费下载链接】WeKnoraOpen-source LLM knowledge platform: turn raw documents into a queryable RAG, an autonomous reasoning agent, and a self-maintaining Wiki.项目地址: https://gitcode.com/GitHub_Trending/we/WeKnora创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考