WeKnora 配 Ollama 本地大模型部署一篇跑通 RAG 知识库的完整实战【免费下载链接】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/WeKnoraWeKnora 是一款开源 RAG 知识库与智能体平台把文档加工成可问答的检索引擎、推理 Agent 和自维护 Wiki。搭配 Ollama 做本地大模型部署后文档、检索、推理全部留在自己的机器上。快速上手从零到能对话这一节的目标只有一个让服务跑起来并确认本地模型链路真的通了。按顺序做每步都有可验证的结果。装好两个前置Docker含 Compose和 Ollama。Ollama 装完先起服务ollama serve /dev/null 21 然后拉一个对话模型如llama3:8b和一个向量模型如bge-m3用ollama list能列出两者就算第一步完成。克隆代码库git clone https://gitcode.com/GitHub_Trending/we/WeKnora进入目录把.env.example复制为.env。编辑.env填上 Ollama 的模型名、向量维度bge-m3 是 1024。如果暂时不配 Rerank 可以先留空它不是必需的。这一步最容易漏——文档上传后一直报错多半就是这两个模型没配对。docker compose pull拉镜像docker compose up -d启动。之后按需加 profile知识图谱用--profile neo4j对象存储用--profile minio链路追踪用--profile langfuse。浏览器打开http://localhost后端 API 在http://localhost:8080。首部署检查清单ollama list能看到对话模型和向量模型11434 端口在宿主机可访问Ollama 默认监听此端口.env中 LLM 与 Embedding 的模型名、向量维度与本地实际一致磁盘剩余空间大于模型文件总和的 3 倍Web 登录页能打开且第一次提问时答案正常返回而不是模型连接报错部署决策本地化到底值不值得先说结论本地部署省的是按量付费的钱换来的是硬件先掏钱、维护自己扛。适不适合看三件事。场景匹配。三类情况适合上本地文档本身敏感合同、病历、内部规范不愿发给第三方 API网络环境受限内网隔离、断网办公调用量大到 API 账单开始肉疼。反过来如果只是低频试用、或者团队根本没有能跑模型的机器先用云 API 把流程跑通更划算。有制造企业的做法是核心模型放本地、边缘场景用小模型各管一段——这个思路对预算有限的团队同样适用。硬件选型。没有 GPU 也能跑但只适合体验。下面是我们整理的一套经验值参考 llama3:8b 级别的对话模型硬件档位内存基线适合的规模备注体验机16GB单人 / 小团队试用无 GPU 可行响应偏慢部门级32GB十几人日常使用16 核 CPU 起步企业级64GB多团队高并发建议配 GPU并发可到 40 路左右粗算公式所需内存 ≈ 模型大小 × 1.5 8GB 系统预留 并发路数 × 0.2GB。客服这类高频场景16GB 内存加 8B 模型的组合就能扛住日常并发。成本回本点。本地部署没有按次费用所以回本逻辑很简单把硬件投入摊到三年看云端 API 的调用费什么时候超过这个摊销值——调用量大的团队一年出头就能打平。真正要额外算的是有人负责运维的人力成本。原理拆解数据在机器里走了哪些路用大白话说WeKnora 就是三件事把文档变成可检索的碎片、把问题变成可匹配的向量、再让模型基于检索结果作答。拆开看有三个模块。模型服务层。WeKnora 把模型抽象成五类对话、向量、重排、图像理解、语音转写每类可以独立选来源——本地 Ollama 或远程 API两者还能混着用比如向量模型放本地、回答用云端大模型。本地模型的生命周期由OllamaService见 internal/models/utils/ollama托管界面里可以检查模型是否已下载、一键拉取、看下载进度你不用记ollama pull这些命令。文档处理流水线。上传的 PDF、Word、Excel 等十余种格式交给 docreader 服务解析再切块、向量化可选地抽取实体建知识图谱。整个流水线支持按批次覆盖配置——比如某一批文档只想开图谱抽取不影响知识库的全局设置。每篇文档的解析进度还有可视化的分阶段时间线哪个阶段卡住了直接能看到。混合检索。检索不是只靠向量相似度BM25 关键词召回和向量稠密召回并行做命中后再用 Rerank 模型精排开了图谱的话还能走 GraphRAG 补一层关联召回。为什么这么设计因为用户提问时有的词必须精确命中型号、报错码有的要靠语义模糊匹配单一路径哪边都会漏。组件全部可替换向量库从 pgvector 到 OpenSearch、Milvus、Qdrant 都支持存储后端也支持每空间多实例绑定。模块化是它私有化部署时最好用的特性——哪个组件不合你环境换掉即可。生产调优参数、安全与故障排查上线前花一天调这三块能避开 80% 的后续工单。性能参数。上下文窗口num_ctx按你的文档长度和对话轮数给够大就行给到 8192 以上会显著推高内存占用本地机器容易 OOM。Embedding 模型一旦定了就别换它决定索引里向量的含义和维度换模型等于老数据全部失效必须重建索引所以选型时就把长期不换当成前提。后台任务并发受模型级max_concurrency约束多机部署时闸门走 Redis 分布式信号量单模型被打爆的排队和等待数都能在运行时队列面板里看到。安全加固。三条底线服务放在内网或私有网络别直接暴露公网开启登录鉴权多人环境配好 RBAC 角色只读的给 Viewer维护知识库的给 ContributorAPI Key 走权限范围模型按能力和知识库范围授权别发全权 Key。另外 SSRF 白名单SSRF_WHITELIST只加确认可信的目标生产环境别图省事放宽。监控告警。建议接上 LangfuseAgent 的推理循环、每次模型调用的 token 消耗、工具调用轨迹都能追到本地 Ollama 模型的调用同样在列。告警阈值给两个经验值响应时间持续超过 300ms、错误率高于 1%就该有人看日志了。常见故障排查。文档传不上去 / 提问报模型错误九成是.env里 LLM 或 Embedding 模型没配对先查这里再看 app 容器日志里的 ERROR。文档卡在处理中打开解析时间线看停在哪个阶段解析 / 切分 / 向量化确认挂死就点中止解析。PaddleOCR 起不来换OCR_BACKENDvlm走外部视觉模型或先关掉 OCR 保主流程。升级后权限不足0.6.0 起启用空间 RBAC先看当前工作区的角色徽章再对照 RBAC 说明。常见问题QOllama 装在别的机器上WeKnora 能连吗可以。只要容器网络和宿主机/Ollama 所在机器能互通模型配置里指向对应的服务地址即可。部署时先确认连通性再保存别等提问时报错再排查。Q本地和云端的模型能混着配吗能。五类模型各自独立选来源典型组合是向量模型放本地数据敏感对话模型用云端效果好。代价是要维护两套连通性记得每类都点一次测试连接。Q想给文档里的图片也做理解要额外装什么需要配一个 VLM视觉语言模型并在知识库设置里开启多模态。存储走 MinIO 的话记得用--profile minio把 MinIO 拉起来否则图片会显示为无效链接。Q换了 Embedding 模型老知识库还能搜吗搜不到。向量维度与含义都变了必须重建索引。所以选型阶段就要把 Embedding 模型定死这也是我们反复强调选定后别换的原因。Q怎么知道是哪次解析、哪次调用出了慢开 Langfuse 后每类模型调用和 Agent 运行都有瀑布图后台任务看系统设置的运行时队列面板失败任务可以手动重试。落地建议建议按试点 → 扩展的节奏走先拿一个非敏感的知识库内部规范、产品手册跑通建库、上传、问答、Agent 四个环节验证模型效果和数据隔离都符合预期再逐步接入 IM 渠道、嵌入组件这类对外能力最后才把核心业务文档放进去。硬件按部门级 32GB起步调用量上来再升配。遇到配置问题先查 常见问题排查完整功能、API 与环境变量见 官方文档约 150 个环境变量都能在里面查到默认值和说明。【免费下载链接】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），仅供参考