knowRAG知识库系统

一、立项背景与目标
企业普遍存在内部文档分散在各系统/个人电脑、员工查找困难、知识无法沉淀复用的问题；对外客服重复咨询量大、人工成本高。本项目构建一套企业级AI知识库管理平台，把散落的制度、产品手册、FAQ等文档统一沉淀为可智能检索的知识库，对内供员工快速查资料，对外驱动AI客服自动应答，降低人工成本、避免知识流失。我负责后端架构与核心AI管线开发。

二、核心功能模块
1、文档沉淀与知识库管理：支持PDF/Word/Markdown/Excel/图片等多格式一键导入，自动解析切分建库；QA问答格式自动识别保留完整语义；多知识库按部门/业务隔离；支持飞书、Notion等外部文档源定时同步，保证知识库常新。
2、智能检索与问答：语义检索+关键词检索加权融合，经精排后由大模型流式输出答案，答案附带原文出处可追溯，避免AI胡编。
3、AI客服与多轮对话：结合对话历史做指代补全与纠错，解决多轮对话"一聊就忘"；拒答策略可按需切换（仅按知识库答/混合/自由闲聊），控制客服回答边界。
4、角色化应答：内置多套角色Prompt（如售后客服、销售顾问、内部IT支持），配置化切换，新增角色无需改代码。

三、业务流程与功能路径
1、知识入库：上传或定时同步文档→格式解析→智能切分→向量化与关键词索引写入→进入可检索知识库。
2、智能问答：用户提问→结合历史改写问题→按权限圈定知识库范围→混合检索→精排→拒答判定→流式生成→返回带引用来源的答案。
3、AI客服：选择客服角色→加载对应话术配置→结合知识库检索结果生成符合角色口吻的回答。

一、整体架构与技术栈
采用 Ingestion（入库）+ Query（检索）双管道解耦架构：入库管道负责文档解析、切分、向量化异步落库；检索管道负责查询改写、混合检索、精排、流式生成，两管道独立扩展互不阻塞。
技术栈：Spring Boot 3.x + Spring AI + MyBatis-Plus 做后端主干；
PostgreSQL + pgvector 同时承担关系存储与向量检索（用 pgvector 而非独立向量库，减少一套中间件运维成本）；zhparser 做中文关键词检索；Redis 缓存热点知识与会话；Tika 做多格式文档解析；前端 React 18 + TypeScript。混合检索用单条 SQL 完成余弦相似度(0.7) + BM25关键词(0.3) 加权融合，权重按业务场景可配置，集中由 RagProperties 配置中心管理各子模块参数。

二、我负责的模块与结果
独立负责后端整体架构与核心AI管线，前端主流程联调。
1、高并发入库：用 Java 21 虚拟线程覆盖入库、Embedding调用、SSE流式三个I/O密集环节，批量上传多文件并发解析不阻塞主线程；Semaphore 对 Embedding 接口限流并做 429 退避重试，避免打爆第三方额度。
2、检索质量：父子分块（父块保上下文、子块供检索、设重叠防句子截断）平衡召回与精度；多轮 Query 改写结合近几轮历史做指代补全（"它"→具体产品名）与语音输入纠错；引入 Reranker 对粗检索结果精排，人工抽检问答命中率明显提升。
3、配置化与多角色：知识库参数、拒答策略、角色 Prompt 全部外部化配置，新增客服角色或调整检索权重无需改代码重启。
4、多模态与特殊格式：图片走"视觉描述+OCR+用户标题"三层文本合并后向量化；QA 格式自动识别并做合理性校验防误判。

三、难点、坑与解决
1、虚拟线程拿不到登录用户：虚拟线程无法继承 ThreadLocal 里的 SecurityContext，导致异步入库丢失操作人。解决：在请求入口显式捕获 userId 沿调用链透传，不依赖 ThreadLocal。
2、中文检索召回差：纯向量检索对"产品型号、专有名词"这类精确词不敏感。解决：叠加 zhparser 关键词检索加权融合，专有名词语义+精确双路命中。
3、答案胡编/越界：模型偶尔脱离知识库自由发挥。解决：答案强制附带原文出处引用供核验，并按场景切换拒答策略（仅按库答/混合/闲聊）控制边界。
4、文档格式杂乱：客户文档含大量扫描件、表格、图文混排。解决：Tika 统一解析 + 图片多模态索引 + QA 格式校验兜底，保证入库语义完整。