笔者在实习期间担任产品运营的过程中发现，运营时存在大量未接触或未处理过的产品问题，而且多数产品的用户手册和技术文档内容非常庞大，学习和排查问题成本很高。
       而笔者正在学习RAG系统，受此启发做了一个本地可部署的企业知识库 AI 系统，目标是打破传统To C的聊天机器人，而是帮助企业内部员工完成“问题受理-分诊-排查-升级-结案-沉淀”完整闭环的问题处理平台。

       收到笔者爱人的建议，对文章做出部分修改。考虑到系统本身涉及企业数据的私密性，因此并未做内网穿透，所以将部分网页内容以截图形式展示，具体如下：

登录页面：

工作台：

问题处理：

文档中心：

质量测评：

       之前已经将项目上传到 GitHub，但考虑到部分学习者可能无法稳定访问 GitHub，因此在 CSDN 补充一篇完整技术说明，希望所有看到此文的初学者能否对AI产品有更深的理解。

       笔者能力和文笔有限，文章浅薄，本文仅供参考，真正的学习还是应该在实践中不断探索。

本项目 GitHub 地址：Koala-la-la/Enterprise-KB-AI: This is an AI system based on RAG. You can upload PDF files and build your own independent knowledge base for reference onlyhttps://github.com/Koala-la-la/Enterprise-KB-AI

一、项目背景与动机

1.1 实际业务痛点

       在实习期间做产品运营时，笔者遇到一个非常典型的问题：
       企业内部存在大量历史问题和复杂文档（用户手册、技术文档、SOP、FAQ、接口规范），新人或跨岗位学习者在处理问题时，往往要花大量时间“找文档、读文档、拼答案”。

常见现象：

• 文档很多，但很难快速定位可执行结论。
• 同一个问题，不同人给出不同处理口径。
• 处理完成后缺乏沉淀，下次还会重复问。

1.2 项目目标

        因此笔者做了这个本地可部署的企业知识库 AI 系统。目标不是做 ToC 聊天机器人，而是面向企业内部员工，支撑完整链路的问题处理平台：

• 问题受理
• 分诊
• 排查
• 升级
• 结案
• 沉淀

         这个目标决定了系统必须同时具备“AI 能力 + 流程能力 + 管理能力”，在笔者看来这也是一种产品思维，从问题的痛点提炼出产品的需求，然后推导到产品的问题解决。

二、项目定位：为什么不是“文档聊天”，而是“问题处理平台”

2.1 文档聊天的上限

       很多人会对项目目标产生疑问，为什么你说要做的是问题处理平台，而不是文档聊天机器人，其实现有的知识库聊天机器人很多，比如GPT，豆包一众AI助手都可以上传文档，构建自己的知识库，用于回答和解决问题。

       但是对于刚接触工作内容，或者是企业产品实际场景来说，这是远远不够的，纯“文档问答”模式更像工具能力，适合快速检索，但很难覆盖企业真实协作流程。
       企业内部不只关心“答得出”，更关心：

• 能否按流程推进问题。
• 能否追踪谁在什么时候做了什么。
• 能否在时限（SLA）内完成处理。
• 能否把一次处理沉淀成组织知识。

2.2 平台化思路

       从工具到平台，这是一个重大的思路转变，工具满足的是 “信息检索需求”，平台满足的是 “业务处理需求”。本项目将 AI 作为“处理引擎”，不是“产品本体”。产品本体是“问题单工作流”，AI 负责：

• 给分诊建议
• 给排查步骤
• 给依据引用
• 给升级前补充信息建议

      一句话总结：
      从“会回答”升级为“会处理”。

三、总体架构设计
3.1 技术栈

• 后端：FastAPI
• 前端：React + Vite
• 向量库：Milvus
• 模型侧：HuggingFace Embedding + LLM
• 缓存：Redis
• 数据存储：本地 JSON（会话/问题单/审计）

3.2 架构分层

• 接入层：登录、上传、问答、评测 API
• 处理层：问题分诊、检索、重写、重排、生成
• 数据层：文档注册表、向量索引、问题单存储、审计日志
• 产品层：工作台、问题单流程控制、SLA、评测报告

3.3 核心数据对象

• 用户（username / team / role）
• 文档（source / type / access_level / owner_team / tags）
• 问题单（status / priority / system / environment / error / resolution）
• 审计事件（event_type / actor / timestamp / details）

       在此提醒，现有的AI代码辅助工具层出不穷，该项目的部分具体代码笔者也是通过Open Code实现，很多初学者会疑惑我到底要不要学习代码，要不要学习机器学习，在笔者看来，只有具备基本的知识和代码能力，才能通过辅助工具来构建项目，Open Code、Claude Code、Cursor只能帮你提升代码的撰写效率和问题的解决速率，并不能弥补你对知识和逻辑的空白。

四、RAG 核心链路与关键实现

4.1 文档入库（Ingestion）

流程：

1. 上传 PDF/Markdown 等文档。
2. 文档解析并切分为 chunk。
3. 生成 embedding。
4. 写入 Milvus，并保留文档元数据（类型、权限、团队、标签等）。

这样做的价值是：检索不仅看语义相似度，还能按权限和业务标签过滤。

4.2 检索增强生成（RAG Pipeline）

当前链路包含以下关键节点：

• Query Rewrite（查询重写）
  把用户提问改写成更适合检索的表达，减少口语化噪声。

• Hybrid Retrieval（混合检索）
  结合关键词匹配与向量检索，兼顾精确术语与语义召回。

• Reranker（重排）
  对召回结果再排序，把真正有用的证据排到前面。

• Grounded Answer（基于证据作答）
  回答必须绑定命中文档证据，降低“看起来合理但无依据”的幻觉。

       相关的概念已经趋近成熟，笔者不再详细赘述。

       在此，任需补充说明：在 RAG 学习过程中，许多初学者易陷入 “过度聚焦模型本身” 的认知误区。事实上，随着 AI 技术的不断迭代，当前主流大模型的能力已趋于稳定，达到了可满足多数场景需求的阈值。

       从投入产出比来看，单纯在模型选型、参数调优上投入过多精力，边际效益已明显递减；真正需要深耕的，并非模型本身，而是模型的落地应用方式 —— 也正是前文所阐述的检索增强生成（RAG Pipeline）以及下文提到的分诊路由（Case Routing），当然这也只是方式之一。

       唯有搭建高效、完善的 RAG 链路，才能让大模型的能力充分落地，真正解决实际场景中的问题，这也是 RAG 技术的核心价值所在。

4.3 分诊路由（Case Routing）

       系统会结合“问题单上下文 + 当前提问”进行问题类型路由（如支付异常、鉴权问题、发布稳定性、升级协作），再限制检索范围。
目的：避免跨问题串题，提高回答稳定性与可控性。

五、问题单工作流引擎（产品核心）

5.1 状态机设计

问题单不是“会话标签”，而是流程对象。
当前采用可流转状态机：

• new（待受理）
• triaged（已分诊）
• investigating（排查中）
• pending_escalation（待升级）
• escalated（已升级）
• resolved（已解决）
• archived（已归档）

系统会做“合法流转校验”，禁止任意跳转，保证流程一致性。

5.2 SLA 机制

按优先级自动计算：

• 首次响应截止时间
• 解决截止时间

并标记：

• 是否响应超时
• 是否解决超时

这一步把系统从“问答工具”推进到“可运营产品”。

5.3 审计日志（Audit Trail）

每次关键动作都记录审计事件：

• 创建问题单
• 字段更新
• 状态流转
• 消息写入
• 删除问题单

每条事件记录：谁（actor）在何时（timestamp）做了什么（event_type）。
用于复盘、追责、流程优化与团队协作透明化。

六、权限模型与企业可用性

6.1 用户权限

• 角色：member / admin
• 团队：如 platform、payment 等

6.2 文档可见性

• private：仅本人可见
• team：团队内可见
• org：全公司可见

问答与评测都走同一权限过滤逻辑，保证“可见即可检索，不可见不参与回答”。

七、评测体系（Evaluation）设计

7.1 为什么要做评测

       没有评测的 RAG 优化，容易陷入“主观感觉变好”的黑盒状态。评测的意义是把优化变成可量化迭代。

7.2 当前评测能力

• Benchmark 用例运行
• 多文档评测套件生成
• 结果报表（JSON/Markdown）
• 关键指标：pass rate、平均分、失败用例等

7.3 评测在产品里的作用

• 验证改动是否真实提升
• 发现知识缺口与高失败场景
• 形成“数据驱动迭代”闭环

八、前端产品化设计

8.1 页面结构

• 登录/注册页
• 工作台 Dashboard
• 文档中心
• 问题处理台（核心）
• 评测页

8.2 问题处理台的核心交互

• 左侧：问题单列表
• 中部：问题详情 + 流程动作 + 聊天处理过程
• 右侧：引用依据（命中文档片段与元数据）

8.3 可解释性设计

回答不仅给结论，还展示：

• 路由类型
• 检索范围
• 证据来源

避免“黑盒 AI 输出”，提升内部信任度。

九、部署与运行方式（本地）

9.1 基础依赖

• Python 3.10+
• Node.js 18+
• Docker（用于 Milvus/Redis 等依赖）

9.2 启动流程（示例）

# 后端
python -m uvicorn app.main:app --reload

# 前端
cd web/react-ui
npm run dev

若 Milvus 未启动，上传/检索会报连接错误（127.0.0.1:19530）。需先启动对应容器。

十、项目价值与适用场景

10.1 适用场景

• 企业内部客服/售后支持
• 技术支持与实施团队
• 运维故障排查协作
• 研发知识库与 SOP 管理

10.2 产出价值

• 降低新人处理门槛
• 提升问题定位速度
• 统一处理口径
• 沉淀组织知识资产
• 为团队管理提供可量化数据

结语

       现有的成熟的知识库AI项目或者是RAG项目在网络上数不胜数，笔者做的项目也只能算是抛砖引玉。笔者最近看到一则新闻，“前同事离职后成为AI数字人实现赛博永生”，地狱笑话的同时，也与项目暗合，因此想到本项目，写了这篇博客，如果其他学习者对此项目感兴趣或者存在疑问，也欢迎联系笔者，或者评论，希望可以为想在此方向的学习者提供一些借鉴和思路。