项目介绍（面试口述稿）

30 秒版

我做的是一个基于 RAG 的企业级智能知识管理平台，可以理解成企业内部版的 ChatGPT：用户上传自己的 PDF、Word 等文档，系统自动解析、切片、向量化存入 Elasticsearch；提问时系统做向量加关键词的混合检索，找出最相关的片段，再由大模型生成带引用来源的回答。我负责从文件上传、解析向量化到检索和对话的完整链路，重点解决了大文件的分片断点上传和混合检索两个问题——检索命中率从纯关键词的 63% 提升到了 85%。

2 分钟版

背景与痛点：企业内部的知识查找效率很低——文档散落在邮件、网盘、共享文件夹里，关键词搜索经常因为"用词不一样"搜不到。所以我想做一个"把文档喂进去、用自然语言把答案取出来"的平台，回答必须带原文出处——这也是私有知识库和普通聊天机器人的本质区别：答案是可溯源、可验证的。

整体架构：后端 Spring Boot，存储四件套——MySQL 存业务与元数据，Redis 做进度缓存和会话上下文，MinIO 存文件对象，Elasticsearch 承担检索；文件处理走 Kafka 异步流水线，前端通过 WebSocket 拿流式回答。

亮点一，大文件的可靠上传：大文件直传遇到网络抖动就前功尽弃，所以做了分片上传——前端 SparkMD5 分块算文件指纹实现秒传和断点定位，5MB 切片、四个并发上传，Redis 位图记进度；后端用"Redis 位图 + MySQL 元数据 + MinIO 对象"三方校验做幂等去重，写入顺序是先存内容、再记元数据、最后标缓存——不依赖分布式事务，靠写入顺序加幂等保证最终一致，Redis 挂掉断点进度也不丢。

亮点二，混合检索：纯关键词召回不了同义改写，纯向量对专有名词不敏感，所以两层各干各擅长的事——向量 HNSW 召回（窗口放大 30 倍），一次 ES 请求里做 must 关键词匹配加权限 filter 过滤（越权文档不进候选集），最后 BM25 rescore 二阶段重排、关键词主导排序。效果是 recall@5 从 63% 提到 85%——控制变量测的：同一批真实查询、同样的权限条件，基线是纯 BM25 的检索路径。

亮点三，异步处理流水线：解析向量化比较重，合并完成后发 Kafka 消息异步处理；embedding 配额两阶段结算（调用前预估拦截、调用后按真实用量记账）；ES 文档 ID 用文件指纹加块序号的确定性 ID，消息重复消费也不产生重复数据。

收尾：最大的收获两点——不引入分布式事务，用写入顺序和幂等设计解决跨存储一致性；用评测数据驱动检索优化，而不是凭感觉调参数。

追问衔接

追问	去处
分片去重 / 断点恢复 / 合并挂了	文件上传模块
检索怎么混合 / 63%→85% 怎么测	知识库检索模块
流式输出 / 多轮上下文	聊天助手模块
表设计 / 存储选型	库表设计
整体架构 / 开发计划	整体设计方案

一、这个项目是什么？

这是一个基于 RAG 的企业级智能知识管理平台：允许用户上传文档构建专属知识空间，并通过自然语言交互方式查询和获取知识。它结合了大语言模型（如 DeepSeek、ChatGLM 等）和向量检索技术，让用户能够通过对话形式与自己的知识库进行高效交互。

它本质上是一个"知识增强型"AI 助手，它不仅仅依赖大模型固有知识，更重要的是能够基于用户提供的专属内容进行精准回答，确保信息的可靠性和私密性。

二、它有哪些应用场景？

• 企业知识管理：整合公司制度、流程文档、技术文档等内部知识，员工用自然语言提问即可获得带出处的答案
• 制度与 IT 自助服务台：报销流程、请假制度、环境配置这类高频重复问题，员工自助查询，不再反复打扰 HR 和运维
• 个人学习助手：把课程讲义、论文、技术文档上传为个人知识库，用对话方式复习、检索、追问
• 研发协作与交接：项目设计文档沉淀后，新人用自然语言了解系统细节，降低交接与上手成本
• 客服与售前支持：基于产品手册构建知识库，辅助客服快速给出一致、可溯源的口径

三、它解决了哪些痛点？

从技术角度来看，传统的企业知识管理存在很多痛点。最明显的就是信息孤岛问题，各个部门的文档散落在不同的系统里，有的在邮件附件，有的在共享文件夹，还有的在各种云盘里。员工想找个资料，得在好几个地方翻来翻去，效率极低。

平台通过统一的文件管理系统解决了这个问题。它不仅支持各种常见的文档格式，还用 Apache Tika 这个强大的文档解析库来提取文本内容。更重要的是，它引入了组织标签的概念，让不同部门的文档可以有序管理，同时保证权限隔离。

另一个让人抓狂的问题是大文件上传。传统的上传方式经常出现这种情况：网络稍微不稳定就上传失败，得重新来。平台用了分片上传的技术，把大文件切成小块，一块一块地上传。

这个实现很巧妙，用 Redis 的 BitMap 来记录哪些分片已经上传了。即使中间断网了，也能从断点继续，不用重头开始。而且用 MinIO 做对象存储，可以很好地处理海量文件。

第三个痛点是检索不精准。传统的关键词搜索经常出现这种情况：你明明知道有个文档讲过相关内容，但就是搜不出来，因为你用的词和文档里的不一样。平台采用了混合检索的方案，把 Elasticsearch 的全文检索和向量语义搜索结合起来。

这样即使你用的词不完全匹配，系统也能理解你的意图，找到相关的文档。比如你搜"报销流程"，即使文档里写的是"费用申请"，向量搜索也能找到相关内容。

最后一个痛点是"找到了还要自己读"。平台集成了 RAG 技术：先根据你的问题找到相关文档，然后基于这些文档内容生成精准的答案。

这样你不用自己去翻文档，AI 直接给你答案，还会告诉你答案来源于哪些文档。而且用 WebSocket 建立长连接，支持流式响应，AI 生成内容的时候可以一边生成一边显示，就像 ChatGPT 那样，用户不用干等着。

四、它包含哪些业务模块？

各模块的数据模型与存储选型见 库表设计。

1. 用户管理模块

私有 AI 知识库的核心必须包含"私有"二字。每个用户需要有自己的账号和权限边界，才能确保知识安全。

想象一下，如果所有人都能看到所有文档，那还叫"私有"吗？用户管理模块解决的就是"谁能看什么"的问题，这是整个系统安全性的基础。对于企业用户来说，部门间的文档隔离更是刚需，没有这个模块，产品寸步难行。

2. 文档上传与解析模块

文档上传与解析模块是连接用户知识和 AI 理解的关键环节。首先，我们需要一个简单直观的方式让用户上传各类文档，这是知识的来源；其次，上传的原始文档还需要经过专业处理，转化为 AI 可理解的格式。

如果只有上传功能而没有处理能力，系统就像是一个无法阅读的文件仓库；反之，如果有处理能力却没有好的上传体验，用户就无法输入自己的知识。文件上传功能是整个流程的起点，文档处理则是将这些上传的文件转化为"智能"的关键步骤，决定了系统能否真正理解文档内容。

→ 技术深挖：文件上传模块

3. 知识检索模块

用户提问后，系统需要从海量的知识中找到相关内容，这是检索模块的核心价值之一。如果把文档比作图书馆的藏书，检索模块就是图书管理员，决定了能否找到合适的"参考资料"。

没有精准的检索，AI 模型再强大也无法给出准确回答，因为它找不到相关信息。检索模块解决的是如何从信息海洋中快速定位所需知识的问题，这直接影响回答的准确性和相关性。

→ 技术深挖：知识库检索模块

4. 聊天助手模块

再强大的后台技术，如果交互不自然，用户也会觉得产品难用。想象一下，如果每次都要用特定格式提问或等待很久才有回应，用户很快就会失去耐心。

聊天助手模块解决的是"如何让人机交流自然流畅"的问题，它让复杂技术变得简单易用，就像用户在和一个了解所有文档的助手对话，而不是在操作冰冷的机器。

→ 技术深挖：聊天助手模块

5. 聊天记录模块

用户通过对话获取的知识也是宝贵财富，如果每次关闭页面就全部丢失，那价值就大打折扣了。聊天记录模块就像用户的"第二大脑"，它记录了探索知识的全过程。

对于复杂问题，用户可能需要多次查阅之前的回答；对于重要发现，用户希望能随时回顾。没有会话历史，用户就需要重复提问，浪费时间也影响体验。该模块解决的是"如何保存和利用对话成果"的问题。

6. 文档管理与组织模块

随着企业知识库规模扩大，需要更完善的文档组织功能，如分类目录、标签系统、权限管理等，帮助企业系统化管理大量文档资产。

五、介绍一下你正在做的项目

背景与痛点：这个项目的出发点是企业内部的知识查找效率很低——文档散落在邮件、网盘、共享文件夹里，关键词搜索又经常因为"用词不一样"搜不到。所以我想做一个"把文档喂进去、用自然语言把答案取出来"的平台，回答必须带原文出处，这也是私有知识库和普通聊天机器人的本质区别：答案是可溯源、可验证的。

整体架构：后端是 Spring Boot，存储用了四件套——MySQL 存业务与元数据，Redis 做进度缓存和会话上下文，MinIO 存文件对象，Elasticsearch 承担检索；文件处理走 Kafka 异步流水线，前端通过 WebSocket 拿流式回答。

亮点一，大文件的可靠上传。大文件直传遇到网络抖动就前功尽弃，所以做了分片上传：前端用 SparkMD5 分块算文件指纹实现秒传和断点定位，按 5MB 切片、四个并发上传，Redis 位图记进度。后端用"Redis 位图 + MySQL 元数据 + MinIO 对象"三方校验做幂等去重，写入顺序是先存内容、再记元数据、最后标缓存——整个链路不依赖分布式事务，靠写入顺序加幂等保证最终一致，Redis 挂掉断点进度也不丢。

亮点二，混合检索。纯关键词召回不了同义改写，纯向量对专有名词不敏感，所以两层各干各擅长的事：向量用 HNSW 召回，召回窗口放大到返回量的 30 倍；再在一次 ES 请求里做关键词过滤加权限过滤，权限条件放在 filter 子句，越权文档根本不进候选集；最后用 BM25 rescore 做二阶段重排，关键词主导排序。效果是 recall@5 从纯关键词的 63% 提到 85%——这是控制变量测出来的：同一批真实查询、同样的权限条件，只对比基线是纯 BM25 的检索路径。

亮点三，异步处理流水线。解析和向量化比较重，合并完成后发 Kafka 消息异步处理；给用户的 embedding 配额做了两阶段结算——调用前预估拦截、调用后按真实用量记账；ES 文档 ID 用文件指纹加块序号的确定性 ID，消息重复消费也不会产生重复数据。

收尾：这个项目带给我最大的收获有两点：一是在不引入分布式事务的前提下，用写入顺序和幂等设计解决跨存储的一致性；二是学会用评测数据驱动检索优化，而不是凭感觉调参数。