关注公众号
原创
✅派聪明 RAG 知识库项目上线了！AI 时代，你值得拥有！

大家好，我是二哥呀。

历经 4 个月，派聪明 RAG 知识库项目终于完工（包括源码和教程，全部交付给大家）！

不容易啊。

派聪明如何写到简历上：https://paicoding.com/column/10/2

这篇内容我先带大家了解一下什么是派聪明，我为什么要做派聪明这个企业级的 RAG 知识库？派聪明这个 AI 项目能让大家学到什么？以及如何解锁派聪明的源码仓库和教程？

派聪明的聊天助手：会依据知识库进行问答
派聪明的聊天助手：会依据知识库进行问答

一、派聪明的起源

了解技术派的球友应该知道，派聪明最初是技术派实战项目中一部分，主打的服务是和 AI 大模型进行聊天对话（没有检索增强生成）。

技术派这个项目也是非常经典，帮助 24、25 届，以及 26 届同学斩获了很多超出预期的 offer，我们这里就不多讲了，只贴一个喜报，一位球友靠技术派和面渣逆袭，投了两周拿下小红书的日常实习。

凭借技术派拿到小红书实习
凭借技术派拿到小红书实习

技术派这个项目如果你能认真学完，会收获非常非常多，基本上一个企业级的 Web 开发项目用到的技术栈，技术派都覆盖到了。

技术派的派聪明模块
技术派的派聪明模块

那为了延续正宗的皇家血脉，我把派聪明这三个字延续到了新的 RAG 项目，也就是大家目前看到的这个派聪明 AI 知识库项目（界面还是非常清爽的 😄）。

派聪明的聊天助手
派聪明的聊天助手

派聪明的知识库管理
派聪明的知识库管理

派聪明的组织标签
派聪明的组织标签

做 AI 知识库的起源，当然还是 DeepSeek 刚出来那会，我在本地用 Ollama+DeepSeek+Anythingllm 搭了一个本地的面渣逆袭知识库，当时觉得这玩意挺有意思的。刚好星球球友 Lan 来找我说，要不一起做点事吧，我就把我这个想法交给他去落实了。

当时我没有抱很大的期待，因为从一个 idea 萌芽到开花结果，真的很难，但 Lan 信守承诺，很快就把后端搭建好了。用了很多我觉得对大家求职很有帮助的技术栈，比如说 JDK17、ElasticSearch、MySQL、Redis、MinIO、Kafka 等等，并且涉及到了很多 AI 的知识，比如说目前很火的 RAG 技术。

派聪明的系统概述
派聪明的系统概述

4 月份的时候，机缘巧合，我和朋友【我糖呢】闲聊，就讲起这个项目，他已经悄咪咪的成为一名前端大佬，于是索性我就喊他来做前端，就这样，我们的派聪明团队就算是正式成立了。

下个版本，我打算把 MCP 和 Agent 也加进来。所以，这个项目在 AI 时代，绝对是一个明星级、现象级的实战项目。

二、派聪明的技术栈

先说后端的：

  • 框架/依赖管理 : Spring Boot 3.4.2 (Java 17)+Maven
  • 数据库 : MySQL 8.0 + Spring Data JPA
  • 缓存 : Redis
  • 搜索引擎 : Elasticsearch 8.10.0
  • 消息队列 : Apache Kafka
  • 文件存储/解析 : MinIO + Apache Tika
  • 安全认证 : Spring Security + JWT
  • AI 集成 : DeepSeek API/本地 Ollama+豆包 Embedding
  • 实时通信 : WebSocket
  • 响应式编程 : WebFlux

后端的整体项目结构：

src/main/java/com/yizhaoqi/smartpai/
├── SmartPaiApplication.java      # 主应用程序入口
├── client/                       # 外部API客户端
├── config/                       # 配置类
├── consumer/                     # Kafka消费者
├── controller/                   # REST API端点
├── entity/                       # 数据实体
├── exception/                    # 自定义异常
├── handler/                      # WebSocket处理器
├── model/                        # 领域模型
├── repository/                   # 数据访问层
├── service/                      # 业务逻辑
└── utils/                        # 工具类

前端其实用到的技术栈也非常新，包括：

  • 框架 : Vue 3 + TypeScript
  • 构建工具 : Vite
  • UI 组件 : Naive UI
  • 状态管理 : Pinia
  • 路由 : Vue Router
  • 样式 : UnoCSS + SCSS
  • 图标 : Iconify
  • 包管理 : pnpm

前端的整体项目结构：

frontend/
├── packages/           # 可重用模块
├── public/             # 静态资源
├── src/                # 主应用程序代码
│   ├── assets/         # SVG图标，图片
│   ├── components/     # Vue组件
│   ├── layouts/        # 页面布局
│   ├── router/         # 路由配置
│   ├── service/        # API集成
│   ├── store/          # 状态管理
│   ├── views/ ...

28人已点赞

杠精派
派聪明
0/512

热门评论

丰富的凉面 2025年09月19日 20:01
**
1
回复3 取消回复
丰富的凉面 2025年09月19日 20:02
1e
3
回复 取消回复
丰富的凉面 2025年09月19日 20:02
weqe
1e
1
回复 取消回复
lwh 2025年11月13日 16:34
2
weqe
点赞
回复 取消回复

10 条评论

vert 2026年03月07日 16:47
速速来审核啦
点赞
回复 取消回复
fxq 2026年03月05日 18:39
@派聪明 二哥，刚才面了字节，他问我es中有多少数据，就是类似有几个document，我不太会[捂脸]，这种怎么答，大概有多少数据啊，我只是把项目启动起来了，但没有实际走一遍项目的流程
点赞
回复1 取消回复
派聪明 2026年03月05日 18:40
在面试中回答 Elasticsearch 数据量问题时，建议结合项目实际架构和业务场景合理估算，并强调数据规模的设计逻辑。以下是分层次回答建议： --- ### **回答思路** 1. **明确数据来源** > “项目中 Elasticsearch 存储的是**文档分块后的向量数据**。例如：用户上传的 Word/PDF 文档会被 Apache Tika 解析，然后按语义切分为 200-500 字的文本块，每个文本块通过豆包 Embedding 转换为 2048 维向量存储到 ES。” 2. **给出合理估算范围** > “根据项目设计，一个 10MB 的文档约生成 100-200 个文本块。假设系统支持 **1000 个用户**，每人平均上传 **10 个文档（每份 5MB）**，则总文档块数约为： > `1000 用户 × 10 文档 × 150 块/文档 ≈ 150 万个文档块` > **实际数据量**：每个向量块约 10KB（含原始文本+元数据），总存储量约 **15GB**。” 3. **强调可扩展性** > “数据量可通过 **ES 分片策略**动态扩展： > - 每分片建议 50GB 数据，按 15GB 总量仅需 1 个分片 > - 若数据增长至 1TB，可扩展至 20 个分片（5TB 总容量）” 4. **补充关键细节** > “实际检索时采用 **混合检索模式**： > - **语义搜索**：通过 ANN 算法匹配向量相似度 > - **关键词搜索**：利用 ES 的倒排索引精排 > 这种设计确保在百万级数据下响应时间仍保持在 500ms 内。” --- ### **面试官追问如何应对** - **问：“如何验证数据量？”** → 可通过 `GET /_cat/indices?v` 查看索引大小，或用 `GET /knowledge_base/_stats` 获取文档数。 - **问：“数据量增长后如何优化？”** → “会采用 **冷热分离架构**： > - 热数据：SSD 存储 + 高频分片 > - 冷数据：HDD 存储 + 压缩分片 > 同时通过 **TTL 自动清理过期数据**（如 90 天前的文档块）。” --- ### **注意事项** - **避免虚假数据**：若未实际运行项目，可强调 **“按典型业务场景估算”**，并说明估算依据（文档大小、分块粒度等）。 - **突出技术亮点**：提及 ES 的 **倒排索引+向量索引双引擎** 是支撑高并发检索的核心。 > 📌 **参考项目截图**： > ![ES数据监控](https://************************/paicoding/************************************) > 实际可通过 Kibana 监控索引状态（如文档数、存储大小）。 通过以上回答，既能体现对项目架构的理解，又能展现对大数据场景的工程化思考。
点赞
回复 取消回复
JOY 2026年03月04日 21:39
引用原文：路由 : Vue Router
这个的作用是什么
点赞
回复 取消回复
cx_chen 2026年03月02日 14:55
麻烦审核一下
点赞
回复 取消回复
湛以星 2026年01月28日 21:43
引用原文：派聪明通过集成 Apache Tika 文档解析、豆包 Embedding 向量模型、Elasticsearch 混合检索技术和 DeepSeek API，构建了一套完整的智能知识处理流水线。
@派聪明 我了解到RAG知识库会用到重排模型精确回复，嵌入模型只能粗略查询。这里没有用重排模型有什么考虑？
点赞
回复1 取消回复
派聪明 2026年01月28日 21:44
根据提供的参考资料，派聪明RAG知识库未明确提及使用重排模型（如Cross-Encoder或Reranker），主要基于以下考虑： ### 1. **技术架构的简化与效率优先** - **混合检索已满足需求**：系统通过Elasticsearch的`bool should`查询，同时集成**语义向量检索**（豆包Embedding）和**关键词匹配**（Apache Tika解析文本），实现了“粗查询+精排”的双重效果。这种设计在保证检索精度的同时，避免了额外部署重排模型的复杂性。 - **实时性要求**：重排模型需对Top-K结果进行二次排序，增加推理延迟。而派聪明强调**流式输出**（WebSocket实时推送），轻量化架构能更快响应用户问题。 ### 2. **成本与资源优化** - **降低推理开销**：重排模型通常需独立调用API或本地部署，增加计算成本（如GPU资源）。派聪明直接调用DeepSeek API生成最终答案，将检索结果与问题融合，减少中间步骤。 - **依赖现有组件**：系统已通过Elasticsearch的评分机制（如`score`权重）对检索结果排序，替代了传统重排模型的功能，无需额外模型维护。 ### 3. **场景适配性** - **企业级知识库的平衡需求**：项目定位是解决企业“知识孤岛”问题，而非追求学术级检索精度。混合检索已能覆盖大多数场景（如文档解析、语义理解、权限过滤），重排模型带来的边际收益有限。 - **避免模型幻觉**：RAG的核心优势是**基于真实知识生成答案**，重排模型若与检索结果冲突，可能引入新的不确定性。直接用DeepSeek整合上下文，可保持答案可*性。 ### 4. **迭代规划** - 未来计划集成**MCP（Model Context Protocol）和Agent**，可能将重排能力纳入扩展方向（如多轮对话的上下文重排序），但当前版本以核心功能落地为主。 ### 总结 派聪明通过**Elasticsearch混合检索 + DeepSeek生成**的组合，在精度、效率、成本间取得平衡，未使用重排模型是工程化取舍的结果。若需更高精度，可在现有架构上叠加轻量级重排模型（如BGE-Reranker），但需权衡延迟与资源开销。
1
回复 取消回复
湛以星 2026年01月28日 21:38
引用原文：Elasticsearch 8.10.0
@派聪明 这里用es出于什么考虑，为什么不用milvus呢
点赞
回复1 取消回复
派聪明 2026年01月28日 21:39
在派聪明项目中选择使用Elasticsearch 8.10.0而非Milvus，主要基于以下考虑： 1. **混合检索需求**：项目需要同时支持关键词搜索和语义搜索，Elasticsearch擅长处理基于文本的查询，而Milvus专精于向量相似度匹配。派聪明通过Elasticsearch实现了"关键词+语义"的双引擎搜索（bool should查询方式）。 2. **技术栈延续性**：项目基于Spring Boot生态，Elasticsearch作为成熟的全文搜索引擎，与Java生态集成更紧密，团队也更为熟悉。 3. **功能完整性**：Elasticsearch不仅支持向量搜索，还提供强大的全文检索、分析和复杂查询能力（如match、range、bool查询），满足企业级文档管理的多样化需求。 4. **性能满足需求**：对于派聪明的应用场景，Elasticsearch 8.10.0的向量搜索性能已足够，无需引入额外的Milvus组件增加系统复杂度。 5. **运维简便性**：单一数据库组件降低了部署和维护成本，而Milvus需要专门的配置和管理。 虽然Milvus在纯向量相似性搜索上性能更优（可达其他数据库2-5倍），但派聪明的RAG系统更看重混合检索能力和整体技术栈的一致性，因此选择了Elasticsearch。
点赞
回复 取消回复
zhiwenfan 2026年01月21日 22:20
引用原文：派聪明
@派聪明 派聪明用到了什么AI框架吗？langChain4j ,SpringAI？
1
回复2 取消回复
Alleon 2026年01月22日 20:53
同问同问
点赞
回复 取消回复
是你啊 2026年03月02日 16:04
@派聪明
点赞
回复 取消回复
东cic 2026年01月16日 18:16
求求审核给过
点赞
回复 取消回复
东cic 2026年01月16日 18:16
求求审核给过
点赞
回复 取消回复
zhiwenfan 2026年01月14日 16:07
引用原文：派聪明 RAG 知识库项目
@派聪明 1. 评估混合检索的指标是召回率和精确率，那么是用的什么方法进行的评估和计算，最终你优化的是哪个指标，最后的召回率和精确率大概是多少？（我说是人工标注＋用户反馈）如果是人工的话怎样优化测试的效率？怎么调整？ 2. 已知 ES 检索是目前性能的主要限制，你是怎么进行优化的？测试的时候是单用户还是并发，并发的话并发量是多少？（把我问懵了，直接说的单用户）接着面试官又追问是用多大的文件进行测试，最后实现的反应延时是多少？ 3. 每轮对话中送入大模型的 Prompt 大概有多少个 token？ 4. 把 RAG 系统做成一个 Agent 项目中的一部分，这个项目具体划分为哪些模块？ 5. 系统中会不会出现幻觉问题，怎么解决？
点赞
回复1 取消回复
派聪明 2026年01月14日 16:07
1. 混合检索评估采用人工标注QA数据集(约406个QA对)计算召回率和精确率，加入ES精确检索后召回率提升约22%。优化测试效率可通过自动化标注工具和采样策略，调整alpha参数(0-1)平衡关键词与向量检索权重。 2. ES检索优化采用查询优化和缓存策略，测试先单用户后多用户并发。文件测试大小从KB到GB不等，反应延时通常在200-500ms，取决于文档复杂度和索引大小。 3. 每轮对话Prompt约1000-2000 tokens，包含上下文、问题及系统指令，具体取决于检索到的文档数量和长度。 4. RAG作为Agent项目部分，可分为感知模块(用户输入处理)、决策模块(RAG检索与推理)、执行模块(响应生成)和反馈模块(结果评估与学习)。 5. 系统可能出现幻觉，解决方案包括：(1)提高检索准确性(混合检索+重排序)；(2)忠实性检测验证答案与上下文一致性；(3)优化Prompt设计增强约束；(4)使用大模型内置幻觉检测功能。
点赞
回复 取消回复

目录