最近，我将以前做的一个知识库Bishon V2系统开源了。这是一款为内部场景开发的知识库问答系统，完成架构升级与能力补全后对外开源。它完整兼容 QAnything 风格的 API 接口，采用轻量化技术栈设计，无需复杂微服务与云服务依赖，即可在本地搭建完整的 RAG 知识库体系，兼顾数据隐私可控性与落地便捷性。
设计初衷
在实际工作中，个人与中小团队的知识库需求长期处于一个尴尬的区间：主流开源 RAG 方案普遍采用重型微服务架构，向量数据库、关系型数据库、全文检索引擎、推理服务一应俱全，部署运维门槛高，普通笔记本难以流畅运行；同时方案绑定性强，新增文档格式、替换组件引擎都需要跨服务改造，定制成本高。而大量内部文档、研究资料又有明确的本地化部署要求，无法直接使用云端SaaS产品。
基于这个现状，我设计了 Bishon：它不追求百万级文档的分布式扩展能力，也不做复杂的多租户体系，专注做好个人与中小团队的本地知识库场景。核心目标是低运维成本、高模块化、数据完全可控、迁移成本低，让使用者能把精力放在内容本身，而非搭建和维护一套复杂的技术栈。
核心技术特性
全格式文档解析，内置 OCR 能力
支持 PDF、Word(docx)、PPT、TXT、CSV、Excel、EML、Markdown、常见图片格式，以及任意网页 URL 直接抓取入库。内置 PaddleOCR 3.x，在服务进程内完成图片与扫描件的文字识别，省去独立 OCR 微服务的部署步骤与跨进程调用开销。所有加载器均采用插拔式设计，新增格式只需补充对应解析逻辑。
向量检索 + 重排序两级召回体系
采用 FAISS 实现向量检索，同时内置 Qwen3-Reranker 重排序模型，通过 transformers 本地加载运行，无需额外部署 Triton 等推理服务。两级召回组合在保障检索精度的同时，大幅压缩了部署依赖。重排序能力可通过环境变量一键启停，FAISS、OCR、重排序三个核心组件均支持独立配置 GPU 加速，适配不同硬件条件。
对齐 QAnything API，低成本平滑迁移
核心接口与 QAnything 保持一致的命名规范与请求结构，覆盖知识库创建、文件上传、文档问答、文件管理、状态查询等全量核心能力。原有基于 QAnything 开发的上层业务系统、客户端脚本、自动化工具，只需修改接口地址即可完成迁移，大幅降低切换成本。在此基础上，额外补充了 SSE 流式问答、网页链接摄入等扩展能力。
模型层完全解耦，兼容标准 OpenAI 协议
LLM 与 Embedding 层全部基于标准 OpenAI 兼容协议实现，不绑定任何特定厂商与模型。支持对接本地运行的 Ollama、vLLM，也可直接使用各类云端 API，仅需修改环境变量中的地址与模型名即可切换。知识库数据与模型服务完全解耦，模型升级、方案替换都不会影响已入库的文档与索引。
完整的文档溯源与可视化管理
自带 Web 管理界面，支持多知识库隔离、批量文件上传与管理、处理状态实时查看。每一条问答结果都会关联对应的来源文档与片段位置，点击即可直接在浏览器中打开原始文件，方便核对原文上下文，确保答案可追溯、可验证。
SSE 流式交互体验
问答接口支持 SSE 流式输出，token 逐字返回，有效降低长回答的等待感知，交互体验贴近主流对话产品。
架构设计与选型思考
整体采用高内聚、模块化的一体化服务架构，核心能力收敛在同一套 FastAPI 服务中，通过清晰的分层与接口抽象保证可扩展性，外部仅依赖独立的模型服务。
整体架构示意：
知识库服务 (FastAPI, 端口 8777)
├── FAISS ------ 向量检索引擎，文件持久化
├── SQLite + FTS5 ------ 元数据存储 + 全文检索能力
├── PaddleOCR 3.x ------ 内置图文识别能力
└── Qwen3-Reranker ------ 内置重排序能力
│
│ 标准 HTTP 协议（可配置）
▼
外部模型服务（独立部署，可复用）
├── LLM 服务（Ollama / vLLM / OpenAI 兼容）
└── Embedding 服务（Ollama / OpenAI 兼容）关键选型的技术考量：
- 存储层选择 FAISS + SQLite：对于单机万级到十万级文档的场景，FAISS 的检索性能完全够用，且只有文件依赖，零运维成本；SQLite 配合 WAL 模式可支撑不错的并发读取，自带 FTS5 扩展即可实现全文检索，单文件存储让备份、迁移都极其简便。这套组合用极低的运维成本，覆盖了绝大多数个人与中小团队的性能需求。
- 能力组件进程内集成 + 接口抽象：OCR 与重排序直接集成在服务进程内，消除了跨服务网络调用的开销，也让部署步骤大幅简化；同时所有组件均做了标准接口抽象，替换为云端 API 或其他开源引擎只需实现对应接口，上层业务逻辑无需改动。
- 模型层外置标准化：将 LLM 和 Embedding 作为外部依赖，既控制了项目本身的体积，也给了使用者最大的模型选择权。无论是纯本地私有化部署，还是混合云端 API 的方案，都可以灵活适配。
适用场景与配置参考
适用场景
- 个人研究者 / 开发者：本地管理技术文档、研究论文、笔记资料，数据全部保存在本地，一个界面完成检索与问答。
- 3--10 人小型团队：共享项目文档、会议纪要、内部 Wiki，可每人独立部署对接共享模型端点，也可单实例配合反向代理服务全团队。
- 10--50 人中型团队：作为部门级知识库部署在单台工作站上；如有更高并发需求，可基于预留的扩展点做定向改造。
该方案不面向多租户 SaaS、超高并发生产流量、百万级超大规模文档库等企业级场景，这类需求更适合 QAnything、RAGFlow、Dify 等重型企业级方案。Bishon 专注于轻量化、易定制、低运维的定位，在匹配的场景下具备更高的性价比。
参考配置规格
单工作站环境下，关闭重排序、CPU 模式 OCR 的参考指标：
| 规模定位 | 文档数量 | 文本分块数 | 建议内存 | 建议磁盘 | 说明 |
|---|---|---|---|---|---|
| 个人使用 | 100--1,000 | < 5 万 | 8 GB | 20 GB | 默认配置，普通笔记本即可流畅运行 |
| 小型团队 | 1,000--10,000 | 5 万--50 万 | 16 GB | 100 GB | 可开启重排序，CPU 版 FAISS 性能充足 |
| 中型团队 | 10,000--50,000 | 50 万--200 万 | 32 GB | 500 GB | 建议开启 FAISS-GPU 与重排序 GPU 加速 |
快速上手
环境要求
- Python 3.11+
- 提供 OpenAI 兼容接口的 LLM 服务（Ollama / vLLM / OpenAI 等）
- 提供 OpenAI 兼容接口的 Embedding 服务
- （可选）NVIDIA GPU + CUDA 用于组件加速
启动步骤
# 1. 创建 Python 环境
conda create -n bishon python=3.11 -y
conda activate bishon
# 2. 安装依赖
pip install -r requirements.txt
# 3. 复制并编辑配置文件
cp .env.example .env
# 在 .env 中配置 LLM 与 Embedding 的接口地址、模型名、密钥等
# 4. 构建前端（如仓库中无 dist 目录则执行）
cd front_end && npm ci && npm run build && cd ..
# 5. 启动服务
./start.sh # Linux / WSL
start.bat # Windows启动后访问 http://localhost:8777/bishon/ 使用 Web 界面，http://localhost:8777/api/docs 查看完整 API 文档。
模块化扩展能力
代码库采用分层模块化设计，预留了清晰的扩展点，可按需进行定向改造：
- 存储扩展：实现标准接口即可替换向量库（Milvus / Qdrant / pgvector）与元数据库（PostgreSQL / MySQL），上层逻辑无需改动。
- 能力扩展：新增文档加载器、新增 LLM 厂商、替换 OCR / 重排序引擎，均有明确的接入位置与接口规范。
- 部署扩展：支持增加反向代理、按用户分片索引配合负载均衡实现水平扩展。
- 功能扩展：可在 FastAPI 层快速接入 API 密钥、OIDC 等认证鉴权能力。
后续规划
- v2.1：提供可选的 Docker / docker-compose 部署方式，上线 MkDocs 官方文档站。
- v2.2：支持音视频转录等多模态内容摄入，提供官方可插拔存储后端。
最后
Bishon 诞生于实际的使用需求，也始终围绕"好用、好维护、好改造"的目标迭代。如果你需要一套轻量化、数据可控、兼容主流接口的本地知识库，或者希望基于简洁的代码底座做二次开发，欢迎尝试 Bishon。
项目地址：GitHub - dliting/Bishon · GitHub
欢迎 Star，也欢迎通过 Issue 和 PR 交流问题与想法。