轻量化知识库Bishon V2.2 发布：部署工程化升级

项目地址：github.com/dliting/Bishon

上个月发布的 Bishon V2.0，用单进程架构替代了传统 RAG 方案的多容器微服务栈，验证了“一条命令跑起完整知识库”的轻量化路线。但“能运行”和“可部署、好运维”之间，始终存在工程化的鸿沟。

今天发布的 Bishon V2.2，核心目标就是填平这条鸿沟——在保留单进程、低依赖本色的前提下，围绕部署、升级、运维三大场景做了完整的能力补全。

全场景部署流水线，开箱即用

V2.0 仅支持裸机源码运行，对开发者友好，但离标准化部署有距离。V2.2 搭建了完整的 Docker 在线/离线 + 裸机三套部署体系：

• 一条 bash deploy.sh 即可走完全流程，交互式向导引导选择部署模式，配置自动持久化，同时支持非交互模式适配 CI 与批量部署。
• 发布包按组件拆分：源码包仅约 2 MB，Python 环境、模型、镜像独立打包。后续代码更新只需传输源码包执行升级，无需每次重传十几 GB 的完整依赖。
• 脚本体系全面重构，按公共工具、Docker 专用、裸机专用分层整理，根目录提供统一入口脚本，操作意图一目了然。

网络与 GPU：解决本地部署的典型痛点

本地部署最容易踩坑的两个环节——容器网络互通与 GPU 生效，在 V2.2 中得到彻底解决。

网络层面，新增 --network host 主机网络模式，容器共享宿主机网络栈。配置同机部署的 Ollama / vLLM 时，.env 中直接填写 localhost 即可连通，无需手动查询 Docker 网桥 IP，网络配置持久化保存，重启自动生效。

GPU 层面，修复了 WSL2 环境下 Docker 容器 GPU 静默失效的经典问题——因驱动文件缺失，容器内 CUDA 初始化失败却无明显报错，所有 GPU 能力悄悄回退到 CPU。V2.2 的启动脚本会在 WSL 环境下自动挂载驱动目录，一行配置解决长期困扰社区的问题。同时健康检查接口新增 GPU 运行时探针，实时检测 CUDA 可用性，避免硬件资源被浪费。

增量升级：数据与配置零触碰

V2.0 没有标准化升级路径，更新代码往往意味着重新配置。V2.2 采用 overlay 增量升级方案：

• 升级仅覆盖代码文件，知识库数据、配置文件、运行日志全程保留，永不被升级脚本触碰。
• 支持纯代码升级与带 Python 依赖升级两种模式，升级前自动备份，升级后输出变更明细，操作过程可追溯。

全链路可观测性与细节打磨

V2.2 的健康检查接口全面升级，覆盖 LLM、Embedding、重排序、OCR、向量索引、数据库、GPU 所有核心组件，每项能力的运行状态都可实时查询。

除此之外，版本还做了大量细节优化：修复环境变量加载时序问题、探针补全鉴权头以兼容更多云端 API、OCR 自动检测 GPU 可用性并降级、构建的发布包自带 SHA256 完整性校验、模型下载默认走国内镜像、支持一键推送镜像到多个容器仓库。

升级说明

从 V2.0 升级到 V2.2 只需三步：一次性重打 Docker 镜像、使用新发布包执行安装、按需切换主机网络模式。原有知识库数据与配置文件会完整保留，无需重新入库。