笔者在实习期间担任产品运营的过程中发现运营时存在大量未接触或未处理过的产品问题而且多数产品的用户手册和技术文档内容非常庞大学习和排查问题成本很高。而笔者正在学习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流程上传 PDF/Markdown 等文档。文档解析并切分为 chunk。生成 embedding。写入 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.10Node.js 18Docker用于 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数字人实现赛博永生”地狱笑话的同时也与项目暗合因此想到本项目写了这篇博客如果其他学习者对此项目感兴趣或者存在疑问也欢迎联系笔者或者评论希望可以为想在此方向的学习者提供一些借鉴和思路。