init: RAG 知识库服务初始提交

- 后端 API（Flask + Gunicorn）
- RAG 引擎（混合检索 + 云端 Reranker + 引用溯源）
- 文档解析（MinerU + 多格式支持）
- Docker 生产部署配置
- 排除前端项目、敏感配置、模型文件

docs/多向量库实现权限划分.md

@@ -0,0 +1,48 @@
+# 多向量库实现权限划分详细说明
+
+## 1. 架构目标与背景
+本项目早期采用单一Chroma向量库体系，所有文档数据混合存储，并在检索层采用软性过滤。为满足企业级数据权限隔离、部门级知识库自治管理的要求，本项目统筹规划重构为「多向量库体系」，将`public_kb`（公共知识库）与`dept_{department}`（部门私有知识库）在 Chroma 中进行物理分隔，实现在数据存储基座维度的鉴权与隔离。
+
+## 2. 权限控制策略与角色模型
+系统主要通过 `auth/gateway.py` 与网关注入的 Header 信息配合，进行请求身份的判定与映射。
+
+### 2.1 网关注入的用户信息
+API 服务会在接受请求前，解析来自网关传递的 HTTP Header：
+- `X-User-ID`：用户唯一标识符
+- `X-User-Role`：用户角色（admin / manager / user）
+- `X-User-Department`：用户所属部门标识（如：finance, hr, tech 等）
+
+### 2.2 角色与集合访问权限规则
+根据系统预设的 `COLLECTION_PERMISSIONS` 规则表，不同类别的用户具有不同层级的读写能力：
+- **Admin（超级管理员）**
+  - **Read（跨库查询）**: `*`（所有向量库均可访问检索）
+  - **Write / Delete / Sync**: `*` （可进行全局库维护操作）
+- **Manager（部门管理员）**
+  - **Read**: `public_kb`, `dept_{自己所在部门}`
+  - **Write / Delete / Sync**: 仅限 `dept_{自己所在部门}`
+- **User（普通员工）**
+  - **Read**: `public_kb`, `dept_{自己所在部门}`
+  - **Write / Delete / Sync**: 无任何写入/修改/删除权限。
+
+## 3. 多库混合检索与结果合并
+
+将文档隔离为多个不同的库集合后，依然通过以下机制保障检索质量与执行效率：
+
+### 3.1 独立BM25缓存与协程并发查询
+- **完全解耦索引**：每个子向量库均配备对应的独立 `BM25.pkl` 关键词索引结构（如 `bm25_index_public.pkl`，`bm25_index_finance.pkl`）。
+- **协程并行加载**：在使用大维度混合查询（比如跨多部门或公共+个人部门）时，知识库引擎通过 `asyncio.gather` 并行向相应的分离集合及BM25文件发起并发读取，整体耗时比单一库顺序扫描具备极大优势（多线程下总耗时稳定在 50~70ms 内）。
+
+### 3.2 智能库路由 (`knowledge/router.py`)
+Agentic RAG在正式下发检索前，加入了一层轻量级意图预判节点（Router）：
+- **意图降噪**：大模型/关键词正则检测若发现用户的查询（如："财务部报销规范"）具有极强的部门属性，则缩小检索范围仅查匹配的库。
+- **动态寻址**：过滤掉权限不匹配库的同时，避免去不相干的知识库进行检索从而拉低相似度分值，极大提高了用户问答查询效率。
+
+### 3.3 RRF (Reciprocal Rank Fusion) 多库融合重排
+当请求在数个子向量库查得片段后，返回的多路向量由于采用了“同源 Embedding 模型”（例如BGE），其余弦相似度在不同子库的数据集之间是完全等价和客观可比较的。
+最终数据层依靠融合模块汇聚所有库的 Top-K 记录，经过全局倒排算法（RRF）以及多维分数权重融合重排，保证了隔离存储不影响任何语义搜寻与内容关联。
+
+## 4. 相关代码路径总结
+- **`auth/gateway.py`**：主要负责网关鉴权与鉴权路由逻辑。
+- **`knowledge/router.py`**：LLM智能知识库请求目标路由。
+- **`knowledge/manager.py`**：支持多库并发检索引擎与RRF打分融合模块。
+- **`rebuild_multi_kb.py`**：从单库直接转换为多库分治物理结构的离线迁移脚本。