这篇笔记是我学习企业级 RAG 多索引架构的完整总结，从架构设计、多索引与多向量库区别、文档入库、路由调度、权限控制、Prompt 工程，到全流程执行逻辑，全部用最通俗、工程师能直接落地的方式讲清楚。 适合正在做 AI 知识库、企业内部问答、RAG 系统开发的同学参考。
一、整体架构概述 企业内部 RAG 知识库，90% 场景都用「单向量数据库 + 多索引」，轻量、稳定、易维护。
用户请求 ↓ 权限校验（后端代码硬控制） ↓ 意图识别 & 路由分类（LLM + Prompt） ↓ 查询对应业务索引（HR/财务/法务/产品/制度） ↓ 混合检索 + Rerank 重排序 ↓ LLM 依据资料生成最终回答
核心特点： • 一套 RAG 系统 • 一个向量数据库服务 • 内部按业务拆成多个 Collection / 索引 • 统一文档处理流程 • 权限安全 + 业务路由分离
二、多索引 vs 多向量数据库
- 多索引（企业首选） • 同一个向量库内，建多个 Collection • 逻辑隔离、轻量、简单 • 一套代码、一套服务 • 适合：按业务/部门/文档类型分类
向量库（Chroma/Milvus） ├─ index_hr 人力资源 ├─ index_finance 财务 ├─ index_legal 法务 ├─ index_product 产品文档 └─ index_policy 公司制度
- 多向量数据库（独立部署） • 多个独立向量库服务（不同端口/目录） • 物理隔离、安全性极高 • 部署重、维护成本高 • 适合：涉密、多租户、超大规模数据
一句话结论： 普通企业知识库 → 多索引 高安全/强隔离需求 → 多向量数据库
三、文档构建入库流程 目录结构按业务分好，一套代码统一处理： data/ ├─ hr/ ├─ finance/ └─ legal/
流程： 读取文档 → 内容清洗 → 文本切片 → 向量化 → 写入对应索引
关键点： • 不需要多进程、多套代码 • 依次构建不同 Collection 即可 • 入库逻辑完全复用
四、路由与调度层（核心灵魂） 权限控制（重中之重） • 必须由后端代码实现 • 用户角色/部门/权限白名单 • 硬拦截，绝对不能靠 Prompt • 决定：能查哪些库
意图识别 & 分类 • 靠 LLM + Prompt 实现 • Prompt 定规则 • LLM 做理解和判断 • 决定：该查哪个库
索引选择 根据分类结果自动匹配：hr → index_hr
五、企业级 3 套核心 Prompt 路由分类 Prompt 你是企业知识库智能路由助手。 任务：根据用户问题判断所属业务领域。
可选分类：hr, finance, legal, product, policy, contract
规则： 只输出分类单词 不回答问题、不解释 无法判断输出 unknown
回答生成 Prompt 你是企业官方问答助手，仅基于参考资料回答。
参考资料：{context} 用户问题：{question}
规则： 只依据资料，不编造、不扩展 无答案统一回复：未找到相关信息 语言简洁、正式、不带格式
内容安全辅助 Prompt（可选） 判断用户问题是否包含敏感内容： 薪资、合同、财务、涉密、个人信息
只输出 allow 或 deny
六、完整执行流程（背会就是架构师） 用户提出问题 后端权限校验（代码） 路由 LLM 做业务分类（Prompt） 去对应索引检索内容 召回相关片段 + 重排序 送入回答 LLM 生成结果 返回给用户
七、核心学习心得 权限是安全底线，必须代码控制，不能靠 Prompt 路由 = LLM 理解 + Prompt 规则，缺一不可 企业优先用多索引，轻量够用 Prompt 工程 = 写稳定、可解析、可上线的指令 Prompt 稳定后，长期不用更新
八、适合人群 • AI 开发 / LLM 应用开发者 • 想做企业内部 RAG 知识库的同学 • 正在学习向量库、检索、Prompt 工程的初学者 • 需要整理系统化技术笔记的人
