WeKnora + Ollama本地部署实战:企业级AI推理的完整落地路径
【免费下载链接】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
某医疗公司想给医生做病历智能检索,但HIPAA合规要求数据必须留在院内,云端API被直接排除。出路是本地化部署:用Ollama做推理引擎,接入WeKnora知识库,模型推理、文档解析、检索问答全部跑在企业自有服务器上。数据不出内网,响应时间从云端的数百毫秒降到百毫秒内,长期成本变成一次性硬件采购而非按调用量计费。对医疗、金融这类强监管行业,这条路几乎是唯一选项。
五步跑通本地部署:从零到第一次推理
- 宿主机装好Ollama并拉取模型。执行
ollama pull llama3:8b,确认ollama list能列出模型。11434端口是WeKnora访问本地推理的唯一入口,这一步不通,后面全白搭。 - 准备环境文件。把
.env.example复制为.env,填上数据库密码、JWT_SECRET、SYSTEM_AES_KEY 等必填项。docker compose 遇到缺失的.env会直接解析失败,先补全可以少走弯路。 - 启动服务栈。克隆仓库(
git clone https://gitcode.com/GitHub_Trending/we/WeKnora && cd WeKnora)后执行docker compose up -d,等docker compose ps全部 healthy。后端监听8080,前端Nginx在80端口把/api/反向代理过去。 - 配置Ollama连接。在前端模型设置里填基地址
http://host.docker.internal:11434。WeKnora跑在容器里、Ollama在宿主机,必须经 host.docker.internal 才能到达,写 localhost 等于容器指回自身,永远连不上。 - 跑通第一轮。上传一份文档,等解析分块完成,在对话里提问,能看到带引用片段的回答即算成功。比如制造业的设备手册检索、研发团队的API文档问答,都是从这一步开始的。
关键验证点:宿主机上Ollama的11434端口必须连通,一条命令即可确认:
curl http://localhost:11434/api/tags能返回已拉取的模型列表JSON就可以进入WeKnora侧配置;随后后端http://localhost:8080/health应返回 healthy。更多细节见官方文档与Ollama集成源码。
WeKnora + Ollama部署配置与硬件选型
企业级安全加固:4个影响最大的参数
⚠️ 以下参数上线前值得逐项核对,默认值在开发环境够用,到生产就会出问题:
| 参数 | 推荐值 | 不改会怎样 |
|---|---|---|
| OLLAMA_OPTIONAL | false | 默认 true 时Ollama不可用仅告警不阻断,请求可能静默回退到云端API,数据就"出圈"了 |
| OLLAMA_BASE_URL | http://host.docker.internal:11434 | 地址写错,模型调用直接失败,知识库无模型可用 |
| 模型上下文长度 num_ctx | 4096 | 拉到8192以上单次请求内存占用明显增大,并发时容易OOM |
| NEO4J_ENABLE | 未部署Neo4j就保持关闭 | 开关开了没有对应服务,图谱相关调用报错 |
💡 配置文件在config/config.yaml,但容器化部署建议统一用.env覆盖,改镜像内文件会在升级时被覆盖。
混合检索召回率与推理机内存估算
WeKnora的混合检索是"BM25关键词 + 向量余弦相似度"双通道召回后融合。问题里出现专名、错误码、API名这类精确词时靠BM25命中;问语义、换说法时由向量补足。两路互补,召回率比单通道更稳——如果业务里精确标识符多(如型号、单号),调高BM25权重;若问法变化大、答案表述松散,则向向量侧倾斜。
硬件估算可以用一个公式:所需内存(GB) ≈ 模型大小(GB) × 1.5 + 8(系统预留)+ 并发数 × 0.2。以llama3:8b的实测数据为参考:
| 机型规格(内存) | 平均响应 | 可撑并发 | 适合 |
|---|---|---|---|
| 16GB | 约280ms | 5会话 | 小团队试用 |
| 32GB | 约150ms | 15会话 | 部门级使用 |
| 64GB | 约80ms | 40会话 | 多部门共享 |
如果并发会话超过40,加内存不如拆两台推理节点做负载均衡,单机的响应时间会先于内存成为瓶颈。
上线前验证:常见故障与排查清单
- 症状:容器反复重启,或前端提示模型不可用→ 查宿主机Ollama进程与端口占用(
systemctl status ollama、ss -tlnp),核对.env里的 OLLAMA_BASE_URL → 修复后curl http://localhost:11434/api/tags返回模型列表,WeKnora日志不再刷连接错误。 - 症状:模型拉取卡住或超时→ 检查出网带宽与磁盘余量,可用磁盘建议留到模型体积3倍以上,SSD优先 → 手动
ollama pull重试,下载完成后ollama list能看到该模型。 - 症状:首字延迟从100ms升到1秒以上→ 用 top 看内存是否打满,用
ollama ps看是否同时加载了多个模型,检查 num_ctx 是否过大 → 调低 num_ctx 或释放闲置模型后响应回落基线,连续100轮对话内存无增长。
上线前检查清单:
ollama list能看到要上线的模型- 宿主机与容器内访问11434端口均连通
- OLLAMA_OPTIONAL=false,OLLAMA_BASE_URL 正确
- JWT_SECRET、SYSTEM_AES_KEY 已改默认值
- 8080端口
/health返回 healthy - 真实文档走完上传、分块、问答全流程
上线建议走渐进路线:先挑一个非核心内部知识库试点,跑两到四周,盯住P95延迟(超过300ms告警)与错误率;验证过上述故障形态后,再扩展到客服、研发协同等高频场景。云端API可以保留为显式配置的备用通道,但绝不该静默生效——数据是否出网,应当始终是一个你主动控制的开关。
【免费下载链接】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),仅供参考