派聪明(项目示例)
本文最后更新于10 天前,其中的信息可能已经过时,如有错误请发送邮件到2260856635@qq.com

✅派聪明RAG项目如何写到简历上?(附 20 道精选 AI 面试题)

重要提示,这部分内容有一些是我修改的球友简历,放上来是为了方便大家参考,请不要相互传播,引起误会,大家参考学习就好了,后期有遇到不错的内容我也会更新上来,互帮互助,才能更进一步。

Color1

  • 如果有引发误会,我就只能保留前三个,其他都会删掉,望周知。
  • 项目的写法有很多,往后面翻一翻。
  • 教程和源码的获取方式:https://t.zsxq.com/XBc0a

:::

写法1 派聪明 RAG 知识库 Java 后端开发 2025-06 ~ 2025-09

项目描述:派聪明是一个基于私有知识库的企业级智能对话平台,允许用户上传文档构建专属知识空间,并通过自然语言交互方式查询和获取知识。它结合了大语言模型和向量检索技术,能够让用户能够通过对话的形式与自己的知识库进行高效交互。

技术栈:SpringBoot、MySQL、Redis、Apache Tika、Ollama、Elasticsearch、MinIO、Kafka、Spring Security、WebSocket、Linux、Shell

核心职责:

  • 编写 shell 脚本,一键启动 Kafka 的 KRaft模式,自动处理 cluster ID 的冲突问题,包括清理日志、生成集群 ID、格式化存储目录、启动 Kafka 服务器等。
  • 基于 Kafka 解耦文件上传、处理与向量化流程,实现分片上传与断点续传;使用 Redis 的 Bitmap 存储分片状态,并通过 MinIO 按照 MD5 进行分片合并。
  • 能够在 Linux 服务器下通过 HTTPS 的方式启动 ElasticSearch,并设置 ES 的 JDK 加载版本为 17;可通过 CA 证书+ CURL 获取/更新 ElasticSearch 的键值对。
  • 使用 Redis 的 BitMap 来存储文件分片上传状态,能最大程度节省内存,即使一个文件有 1000 个分片,也只需要 125 字节的存储空间。
  • 支持 Docker 容器化部署,只需一个命令 docker-compose up -d 就可以在 1 分钟内一键启动整套系统。极大地简化了部署过程,并保证了开发、测试和生产环境的一致性。
  • 利用 Elasticsearch + IK 分词器对知识库文档进行索引和向量检索,支持 Word、PDF 和 TXT 等多种文本类型;并集成豆包 Embedding 模型进行文本到向量的转换,支持 2048 维;再结合 ES 的 KNN 向量召回、关键词过滤和 BM25 重排序实现「关键词+语义」 的双引擎搜索。
  • 基于 WebSocket 实现前端和后端之间的长连接通信通道,并结合 DeepSeek 大模型的 Stream API 实现流式响应返回,只要后端有新的内容到达,前端就即时将文本逐步拼接显示,用户看到的就是一个“打字机”式的逐字生成过程。
  • 使用 Redis 缓存文件元信息与上传分片,结合 MinIO 实现大文件分片上传与断点续传,优化后 1GB 文件上传耗时由 15s 降至 3s。 (本机是 macOS 顶配,128G 内存 Apple M3 Max 芯片)
  • 构建 RAG 检索流程:通过用户提问 + 检索片段拼接生成增强型 Prompt,结合上下文与语义召回提升问答准确度,构建企业私有知识问答体系。
  • 实现基于 Kafka 的文档处理异步流水线,解耦文件上传、解析和向量化过程,经测试,500M 文件上传仅需 200 毫秒。
  • 利用 Spring Security+JWT 实现基于组织标签的 RBAC 的多级权限系统,通过用户角色、组织归属和文件属性的权限过滤,实现精细化的文档访问控制,确保敏感数据安全。
  • 登录与鉴权模块采用 JWT 实现无状态认证,结合 ThreadLocal 管理用户上下文,配合拦截器实现 token 校验与自动续约,避免因 token 过期频繁导致的重新登录问题。
  • 采用 JWT+Redis 的双令牌机制,通过 Access token 处理业务请求,Refresh token 实现用户无感的令牌刷新。
  • 当用户搜索时,我们利用 Elasticsearch 的 KNN 算法计算查询向量和文档向量的余弦相似度,接着利用 ES 默认的 BM25 算法对关键词在文档中的出现频率、重要性进行打分,最后根据自定义公式综合计算出最后的置信分,方便用户判断检索结果的可靠性。
  • 引入滑动窗口机制,在相邻 chunk 之间保持一定的重叠区域,以保证跨 chunk 的信息完整性。
  • 采用基于 Redis 的对话历史管理机制,每个用户都有一个唯一的会话 ID,所有的对话内容都按照时间顺序存在 Redis 中,并设置了 7 天的过期时间,以便在多轮对话中保证上下文信息的完整性。
  • 在调用豆包向量 API 失败时,我们会自动回退到纯文本搜索,实现服务降级;并在调用豆包向量 API 时,采用 Reactor 的重试机制,支持固定延迟重试 3 次,并设置了 30 秒的超时保护。
  • 项目采用了 Mockito 注解驱动的测试模式,践行测试驱动开发(TDD)的理念,每个业务功能都有对应的测试用例,包括正常流程和异常流程。

智能 RAG 知识库管理系统(测试方向) 2025.06 – 至今

技术栈:Spring Boot、Spring Security、MySQL、Redis、Elasticsearch、Kafka、MinIO、Ollama

项目描述:构建智能化的知识库管理系统,支持文件存储、检索增强问答(RAG)、权限控制与智能文档处理。

主要工作:

  • 参与整体后端架构设计,基于 Spring Boot + Spring Security 构建模块化分层架构,确保系统 低耦合、高内聚。
  • 设计 MySQL + Redis + MinIO + Elasticsearch 的多级存储体系,实现文件元数据、对象存储与向量数据的分离,结合 用户标签权限模型,实现多租户知识库隔离。
  • 集成 RAG 检索增强架构,利用 Embedding API 生成文档向量,结合 Elasticsearch 语义检索,较关键词搜索准确率提升 40%+;通过 Kafka 异步结构文档的解析、向量化和存储,从而提升系统的整体 QPS。
  • 编写 JUnit + Mockito 单元测试,覆盖用户注册、认证、会话管理等功能与异常场景;对比验证 Redis 优化前后性能差异,为系统调优提供数据支撑。
  • 项目采用了 Mockito 注解驱动的测试模式,践行测试驱动开发(TDD)的理念,每个业务功能都有对应的测试用例,包括正常流程和异常流程。
  • 对文件分片上传、向量检索等关键环节进行压力测试和性能优化,检索响应时间从初始的 800ms 降低到 200ms,支持 TB 级文档存储和毫秒级检索。

杰润软件(苏州) | Java开发实习生 | 2025.04 – 2025.07

技术栈: Spring Boot、Spring Security、Spring Data JPA、MinIO、Elasticsearch、Kafka、JWT、WebSocket

项目描述:参与构建基于 RAG 的企业级智能知识库,聚焦公司教学资源与项目知识的统一存储、高效检索及智能问答,解决教学资源管理痛点。

主要职责:

  • 参与搭建模块化分层架构,整合 MySQL + Redis + MinIO + Elasticsearch 多级存储体系,分离元数据、对象与向量数据,并设计组织标签权限模型,实现精细化的访问控制。
  • 使用 Kafka 解耦文件上传、处理、向量化与检索环节;实现分片上传与断点续传,结合 Redis 缓存文件状态、MinIO 存储内容,保障大文件可靠上传。
  • 通过 ElasticSearch 优化向量检索逻辑,将接口响应时间由 800ms 降至 200ms;基于 Embedding API 生成文档向量并存储至 Elasticsearch,检索准确率较传统关键词搜索提升 40%+。
  • 设计基于角色过滤的多级权限模型(RBAC);整合检索结果元数据构建 Prompt,结合 WebSocket 实现流式对话闭环。

自然资源部第一海洋研究所(海洋物理与遥感实验室—校企合作实习生)

自然资源部第一海洋研究所(海洋物理与遥感实验室—校企合作实习生)

游知通 — 基于 RAG 的智能游戏助手系统 2025.3 — 2025.7

技术栈:Spring Boot、MySQL、Redis、Apache Tika、ElasticSearch、Kafka、Spring Security、WebSocket

项目描述:这是一款基于 RAG 的游戏智能问答系统,整合百科、论坛、攻略等数据源,通过语义检索和上下文对话,为玩家提供实时、精准的游戏解答与建议。

核心职责

  • 基于 LangChain4j 封装 Spring Boot Starter,集成通义千问大模型,并封装只能问答接口,以加载“游戏助手”角色 Prompt,接口响应时间稳定在 300ms 以内;
  • 使用 MongoDB 持久化用户会话历史,在 AIService 中实现用户多轮对话管理;
  • 采用 Pinecone 向量知识库接入游戏攻略与官方数据,配合 RAG 流程实现“先检索再生成”,提升模型回答的专业度;实现本地 Ollama DeepSeek 与 OpenAI 线上 API 双模型路由策略;
  • 检索层采用 ElasticSearch + IK 分词器融合关键词与语义检索,提升专业术语和长尾问题的召回效果;
  • 利用 Apache Tika 解析并抽取 1500+ 文档信息,通过 Kafka 异步分发更新任务,将接口响应时间优化至 20ms 内;
  • 接口层引入 Spring Security + JWT 做鉴权,确保 LLM 调用安全;前端通过 WebSocket 实现 AI 回答实时推送。

同恩工程技术 | 高级开发工程师助理 2025.07 – 至今

项目描述:主要参与 teamerp 管理系统的开发,深度参与基于 RAG 架构的智能知识库系统建设,涵盖文档管理、语义检索和智能问答等核心模块。

核心职责:

  • 参与文件处理流水线设计,基于 MinIO 实现大文件分片上传,并结合 Redis 缓存分片状态
  • 基于 Kafka 实现文档解析(Apache Tika)与向量化任务的异步解耦,提升文档处理效率
  • 负责基于 Elasticsearch 的混合检索功能开发,将关键词匹配与向量相似度结合,并设计多级权限过滤机制,保障检索结果的准确性与数据安全
  • 协助实现检索结果到 Prompt 的结构化转换,整合文档内容、来源和相关性分数,为大模型(LLM)回答生成提供高质量上下文输入;参与权限体系建设,确保用户仅能访问授权范围内的知识文档
  • 负责实现工作流运行时待办人动态修改功能,通过事件驱动同步多源数据,并开发 WebSocket + 短信双通道通知机制,提升消息触达率

IntelliDoc 企业智能知识管理系统|后端开发 2025.02 — 2025.07

技术栈:Redis、Apache Tika、Elasticsearch、MinIO、RabbitMQ、Spring Security、WebSocket

项目介绍:基于 RAG 架构的企业级智能知识管理平台,支持多格式文档上传、解析与向量化,构建私有知识库并通过自然语言进行知识检索与智能问答,提升企业知识管理效率。

核心职责:

  • 基于 Redis BitMap 管理文件分片状态(1000 个分片仅占 125 字节),结合 MinIO 实现大文件分片上传与断点续传,将 1GB 文件上传耗时由 15s 优化至 3s。
  • 集成 Elasticsearch + IK 分词器构建多格式文档索引,融合通义千问 Embedding 模型实现 2048 维向量转换,结合 KNN 向量召回与 BM25 重排序,支持关键词与语义双引擎检索。
  • 基于 WebSocket 建立长连接,集成 DeepSeek 大模型 Stream API 实现流式响应,为用户提供“打字机式”逐字生成的对话体验。
  • 构建 RabbitMQ 异步文档处理流水线,解耦上传、解析与向量化流程。
  • 设计检索增强生成(RAG)流程,通过用户提问与检索片段生成增强 Prompt,并结合上下文语义理解提升问答准确度。
  • 基于 Spring Security 实现 RBAC 权限模型,从用户角色、组织归属与文档属性多维度进行权限过滤,确保企业敏感数据的精细化访问控制。
  • 结合 Elasticsearch KNN 余弦相似度与 BM25 算法,通过自定义置信分计算提升检索结果的用户信任度。
  • 采用 JWT 双令牌架构(Access Token + Refresh Token),结合 ThreadLocal 管理用户上下文,实现无感刷新登录。
  • 基于 Redis 实现会话管理,支持 7 天对话历史存储,并在向量 API 调用失败时自动降级至文本搜索保障可用。

匹兹堡大学 HARI 实验室

派聪明如何写到简历上:匹兹堡大学 HARI 实验室

智能在线教育平台 2024.11-2025.4

技术栈:SpringBoot SpringCloud MySQL Redis XXL-JOB Kafka OpenFeign

项目描述:基于微服务架构的视频播放平台,为培训机构或个人提供教学视频发布平台,学生等群体可以对视频课程进行学习。主要功能模块:内容管理,媒资管理,认证授权,智能 RAG 知识库模块。

核心功能:

  • 认证鉴权采用 JWT 实现无状态认证,结合 ThreadLocal 管理用户上下文,配合拦截器实现token 校验与自动续约;
  • 实现课程视频的断点续传,结合 XXL-JOB,线程池和乐观锁实现视频的并发转码任务并保证任务的不重复执行;
  • 通过本地消息表+任务调度实现分布式任务,课程发布后再异步执行向 Redis,MinIO,Elasticsearch 写入信息;
  • 通过自定义注解+AOP 实现服务接口鉴权和内部认证,防止在使用 OpenFeign 时外部请求调用接口;
  • 设计基于组织标签的多级权限模型,结合用户角色、组织归属和文件属性的权限过滤,实现了精细化文档访问控制;
  • 设计实现了完整的文件处理流水线,包括分片上传、文件合并、内容解析和向量化环节。使用Redis 缓存分片状态,MinIO 存储文件,Apache Tika 解析文档,通过 Kafka 实现异步处理,解决大文件上传和处理效率挑战。
  • 利用 Elasticsearch + IK 分词器对知识库文档进行索引和向量检索,实现关键词+语义的双引擎搜索;
  • 基于 WebSocket 实现了流式对话响应,结合会话历史管理和上下文追踪,通过 DeepSeek API 提供智能回复;

助学宝 – 在线教育智能助教2025.02 – 2025.07

项目描述:基于 RAG(检索增强生成)架构的在线教育智能助教系统,支持教案、课件、习题库、学术论文等多类型文档的分片上传、向量化处理与关键词+语义混合检索,为师生提供实时、流式的对话式答疑与写作辅导。

技术栈:LangChain、Ollama、MongoDB、SSE、Function Calling、Java、Spring Boot

核心工作:

  • 基于 LangChain + Ollama 部署本地大模型,封装多用户、多轮会话管理的 AIService
  • 使用 MongoDB 持久化用户上下文与对话历史,支持断点恢复与快速加载,平均会话恢复耗时 < 200ms
  • 设计可配置的 Prompt 模板,限定回答风格与知识范围,减少幻觉输出比例至 2% 以下
  • 基于 LangChain Function Calling 解耦大模型与业务接口,串联“课程报名”“作业提交”“成绩查询”等流程,端到端调用耗时稳定在 500ms 内
  • 使用 SSE(Server-Sent Events)实现流式响应,将首响应时间从 2.3s 优化至 0.6s

国网黑龙江省电力有限公司大庆供电公司 – 智能问答系统开发2025.04 – 2025.06

项目描述:构建面向电厂设备操作指南的智能问答系统,支持多格式设备手册上传与解析,结合语义检索与大模型为运维人员提供技术咨询。系统实现多级权限管控,保障敏感设备信息安全,并通过流式对话与上下文记忆提升操作效率。

技术栈:Spring Boot、Redis、MinIO、Elasticsearch、WebFlux、WebSocket、MySQL

核心工作:

  • 设计基于组织标签的多级权限模型(RBAC),结合用户角色、组织归属和文件属性实现多维度权限过滤,覆盖 100% 敏感文档访问场景;
  • 采用分片上传与断点续传技术,结合 Redis 的 Bitmap 缓存文件状态、MinIO 存储文件内容,支持单文件最大 5GB 上传且失败重传率低于 0.3%;
  • 建立语义向量+关键词的混合检索引擎,基于 Elasticsearch 存储向量化数据,集成 rescore 重排优化结果并融合权限过滤,在 50 万条文档规模下检索延迟稳定在 300ms 内;
  • 实现多轮对话上下文记忆,结合 Redis 缓存与持久化机制支持会话断点恢复;
  • 基于 WebSocket + WebFlux 实现大模型流式响应推送,首 token 响应时间由 2.5s 降至 1.2s。

项目:医疗行业 AI 智能助手

技术栈:SpringBoot、MyBatis、MySQL、LangChain、RAG、MongoDB、Pinecone、Ollama

  • 基于 LangChain 构建医疗智能问答助手,结合 Ollama 本地大模型能力,面向挂号平台、在线问诊等场景,提供诊前咨询、科室推荐等功能。
  • 使用 MongoDB 持久化用户上下文信息,通过封装 AIService 管理每个用户的会话历史,实现了“多用户多轮对话”能力。
  • 利用 Prompt 模板规范大模型行为,塑造“AI 医助”身份,限定其知识边界及回答风格,减少幻觉输出。
  • 借助 LangChain 的 Function Calling 能力,将大模型与业务能力解耦,打通“预约挂号、查询记录、取消订单”等业务流程,实现结构化对接调用,用户平均操作耗时控制在 500ms 以内。
  • 使用 Pinecone 构建向量索引库,结合医疗文献、科室说明等非结构化文本,集成 RAG 框架实现知识增强问答,并优化模型对冷门问诊的应答能力。
  • 实现基于 SSE 的模型流式输出,用户提问后通过 Stream 持续接收模型生成内容,减少白屏等待时间,平均首响应时间从 2.3s 降至 0.6s。

AI 交友助手 2025.02 – 2025.06

**项目简介:**用 Spring Boot 3 + Spring AI 搭建 AI 交友助手,集成 Tool Calling 和 MCP,支持多轮对话与记忆持久化,结合 ReAct 框架实现意图解析、工具调用和结果整合闭环,支持自主完成搜索、下载、生成 PDF 等操作。

个人职责

  • 基于文件系统自研了对话记忆机制,结合 Kryo,解决服务重启后历史对话丢失的问题;
  • 借助 Spring AI 的扩展能力,结合上下文缓存和消息增强策略,实现多轮对话中的语境保持,让 AI 在长对话场景下保持上下文一致;
  • 接入 CallAroundAdvisor 记录 AI 调用请求与结果信息,方便追踪链路与问题定位;
  • Retrieval Augmentation 方案整合文档检索与查询转换逻辑,结合相似度阈值与元信息过滤优化召回策略,提升 AI 回答的准确性。

技术创新中心 — 工业软件发展中心

大模型后端开发 | 2024.10 – 2025.04

项目描述:参与虚竹大模型项目,针对工业软件领域同行间知识难以共享、复用率低的问题,和团队一起开发了一款通用的工业知识大模型,主要实现了知识库构建、知识助手、智能问答和仿真等功能模块。

核心职责:

  • 负责大模型相关后端开发工作,使用 Django 和 FastAPI 设计并实现了多组 RESTful 接口,支持模型训练任务的调度和多轮问答服务;配合前端 Vue.js 完成知识助手模块开发。
  • 在知识库管理模块中,基于 PostgreSQL 实现知识数据存储与索引优化,支持海量文档的高效检索与管理。
  • 结合 LangChain 框架构建了面向工业领域的知识问答与辅助决策能力,支撑大模型根据专业领域知识给出智能建议与解答。
  • 使用 Docker 完成核心模块的容器化部署,结合数据库迁移技术,实现不同环境下的一键部署与快速上线。
  • 参与项目从技术选型到模块开发的完整过程,掌握了团队协作开发流程,熟练使用 Git 和需求管理工具。

AI Agent 智能体平台 – 企业级 AI 服务架构 时间:2025.03 – 2025.05

技术栈: Java、Spring Boot、OpenAI API、PostgreSQL、Docker、Redis、Nginx、MCP

核心职责:

  • 采用 DDD 架构设计企业级 AI 智能体平台,深度集成 OpenAI GPT 模型与 PostgreSQL 向量数据库,实现智能知识管理和自动化内容分发。
  • 使用 Redis 的 BitMap 来存储文件分片上传状态,最大程度节省内存,即使一个文件有 1000 个分片,也只需要 125 字节的存储空间。
  • 构建包含 4+ 个容器化服务的微服务架构,支持 SSE 实时通信与工具集成,满足 AI 工具链服务化需求。
  • 集成 Elasticsearch + FAISS,实现「关键词 + 语义」双引擎搜索,目前已通过 ES 的 bool should 查询实现关键词 + 语义的搜索方式。
  • 集成微信 API 与 CSDN API,实现消息与内容自动发布,结合 Playwright 实现网页自动化,日均处理 100+ 工作流。
  • 基于 pgvector 搭建向量化语义检索系统,支持 AI 知识库的上下文匹配与高性能问答,支持 100M 大文档向量处理。
  • 使用 Docker Compose 实现一键部署,通过 Nginx 负载均衡与 Redis 缓存提升系统吞吐量。
  • 深度应用 MCP 协议,构建标准化通信机制,支持 AI 工具与外部系统的数据流互通与插件解耦。

智慧医疗客服系统(2025/02 – 2025/03)后端开发

技术栈:SpringBoot + LangChain4j + Pinecone + MongoDB + MySQL

项目简介:该项目聚焦医疗垂类智能问答,通过集成 LangChain4j 和通义千问大模型,结合 RAG 技术,实现用户医疗咨询的自动回复与辅助服务。

核心职责

  • 基于 LangChain4j 的 Spring Boot Starter 快速集成通义千问大模型,封装智能问答统一接口,加载自定义 Prompt,使 LLM 拥有“医疗顾问”角色;
  • 实现 WebFlux 流式响应能力,支持 LLM 分段返回内容,提升问答交互体验与响应实时性
  • 构建用户级聊天记忆体系:利用 MongoDB 存储历史上下文信息,支持多会话隔离,实现“问诊上下文连续性”;
  • 设计 Tools 工具方法,通过 LangChain Function Call 驱动 LLM 自动调用后端接口,完成 挂号查询与预约挂号功能
  • 基于 Pinecone 搭建向量知识库,接入医疗文献/问答语料,配合 Retrieval-Augmented Generation(RAG)流程,实现“先检索再生成”的专业问答逻辑,模型回答准确率显著提升。

RAG 增强检索知识库系统 2024.05 – 2025.08

技术栈:Spring Boot、Spring AI、PostgreSQL、Redis、Ollama DeepSeek、OpenAI API、JGit、Apache Tika

**项目介绍:**构建智能化的知识库系统,支持文档解析与 Git 仓库分析,结合 RAG(检索增强生成)机制提升问答精准度。系统已应用于内部技术团队文档问答与项目代码辅助理解场景。

主要工作:

  • 封装 Ollama DeepSeek 与 OpenAI 接口,支持主备模型自动切换与请求优先级配置。
  • 使用 Apache Tika 实现 PDF、Markdown、Java 等多格式文档解析,兼容性覆盖 90% 以上业务资料。
  • 引入 TokenTextSplitter,优化大段文本切分逻辑,避免超 Token 限制。
  • 基于 JGit 实现 Git 仓库的增量拉取与解析,支持源码结构和注释自动提取,平均 1 个仓库处理时间小于 2.5 秒。
  • 使用 PostgreSQL 向量存储文本向量,配合语义检索实现知识片段精准命中,问答准确率较原始检索提升 60%。
  • 利用 Redis 管理知识库标签索引,支持多用户知识隔离与权限控制;实现流式问答接口,响应延迟控制在 300ms 内,打字机式输出优化交互体验。
  • 系统目前服务于 4 个内部研发团队,累计上传文档 2000+,问答日均调用量超 1500 次,显著降低重复沟通与知识查找成本。

DeepSeek RAG 增强检索知识库系统 2025.04 – 2025.05

核心技术:SpringBoot、Spring AI、Redis、Ollama、PostgreSQL、JGit

项目简介:本项目基于 Spring AI 框架集成 Ollama DeepSeek 与 OpenAI 双模型,构建了一个智能化知识库系统,支持文档解析与 Git 仓库分析能力。用户上传文档或代码后,系统将其转化为向量存储,构建专属知识库,并支持通过自然语言进行问答检索。

核心职责

  • 基于 Spring AI 构建 Ollama DeepSeek 与 OpenAI 双模型策略对接能力,实现智能知识库的建立与维护,支持上下文感知与语义理解能力;
  • 使用 PostgreSQL 存储文档向量信息,支持大规模文档转向定量表示结构,并配合语义分段优化检索性能,向量查询延迟控制在 100ms 以内;
  • 使用 JGit 完成 Git 仓库接入,通过抽取代码变更、注释与提交信息构建代码知识图谱,支持增量式同步与自动更新机制;
  • 基于 Flux 构建流式接口,支持客户端打字机式的流式问答体验;
  • 实现文章发布自动化流程,构建文章生成模块与 MCP 接口,将知识问答结果聚合为结构化文章,并同步发布至 CSDN、博客园、掘金社区等。

派聪明大模型(核心研发人员)20XX.XX – 至今

技术栈:Spring Boot、Spring Cloud、WebSocket、SSE、MyBatis、MySQL、Redis、Docker、LangChain

项目描述:该项目为面向专业知识场景打造的智能问答平台,支持接入军智 1.0、百川系列、通义千问、GLM、子牙等多个大模型,实现专业问答、知识搜索、文书写作等功能。

核心职责

  • 参与大模型问答、知识搜索、文书写作等模块的需求评审、数据库建模、方案设计与联调测试,推动项目快速落地;
  • 设计数据源配置中心,支持灵活绑定默认引擎、向量搜索引擎、知识图谱与 LangChain 知识库,按需选择问答通路,实现定制化问答体验;
  • 使用策略模式封装不同大模型接入流程,已成功集成军智 1.0、百川 1.0/2.0、通义千问、GLM、子牙等多个模型;
  • 基于 WebSocket 实现用户与模型之间的长连接通信通道,结合大模型 Stream API 实现响应流式返回;为适配浏览器端展示效果,使用 SSE 实现单向实时推送流,将 AI 回复过程逐字逐句输出;
  • 使用 Redis 缓存热点数据与用户上下文信息,提升多轮问答的响应效率与上下文保持能力;使用 Docker 进行服务部署与模型运行环境隔离;
  • 使用 Redis 缓存文件元信息与上传分片,结合 MinIO 实现大文件分片上传与断点续传,优化后 1GB 文件上传耗时由 15s 降至 3s;集成 kkFileView 实现压缩包、PDF、Word 等文件的在线预览能力。

派聪明 Lab 多模型实验平台 2025.01 – 2025.05

技术栈:Spring Boot、MyBatis-Plus、MySQL、Redis、Sa-Token、LangChain4j、MinIO

项目描述:该平台是一个基于 Java 构建的多模型实验环境,集成多种主流大语言模型(如 OpenAI、Claude、DeepSeek 等),支持用户通过 Web 界面便捷构建个性化知识库与 AI 对话助手,可用于问答服务、文档摘要、知识搜索等场景。

个人职责

  1. 负责平台核心模块开发,搭建统一权限校验体系,基于 Sa-Token 实现对模型管理、知识库、聊天接口的精细化权限控制,防止接口越权调用和敏感数据泄露;
  2. 实现基于 Server-Sent Events(SSE)的流式响应机制,配合前端实现 AI 对话实时输出体验,用户响应时间缩短至平均 60ms 内;
  3. 构建融合文档向量检索与 Web Search 插件的 LangChain4j RAG 系统,提升 AI 回答的准确性与时效性,适配搜索增强问答场景;
  4. 实现动态配置中心,支持通过前端界面无感刷新大模型 API Key、系统角色参数、向量数据库连接配置,避免频繁重启服务;
  5. 设计并实现 Function Call 能力,通过可扩展 Tool 类体系封装本地方法,支持 AI 自动调用数据库检索、文件解析、第三方接口等操作;
  6. 完善知识库上传模块,集成 MinIO 存储上传文档,自动完成文档解析与向量化入库流程,支持批量上传、内容过滤与多知识库管理。

项目成果:平台成功支持多个校内/业务部门部署私有化模型测试环境,实现快速搭建 AI 助手场景,支持并发用户数达 500+。

派聪明 Lab – 实验平台 2025.01 – 2025.05

技术栈:Spring Boot、MyBatis-Plus、MySQL、Redis、Sa-Token、LangChain4j、MinIO

项目描述:平台基于 Java 技术栈构建,支持多种主流大模型接入(如 OpenAI、通义千问、文心一言等),用户可通过 Web 页面构建知识库并快速生成具备上下文记忆与插件能力的 AI 对话机器人,支持 SaaS 化部署与私有化落地。

核心职责

  • 接入 LangChain4j 构建 RAG 系统,融合文档向量检索与 Web Search 插件,提升 AI 回答准确率与覆盖面,召回正确率提升至 83%+;
  • 支持 Function Call,设计可扩展 Tool 接口体系,使模型具备本地函数与第三方 API 的调用能力,支持动态数据加载与逻辑处理;
  • 基于 SSE 实现流式输出,结合 Redis Pub/Sub 机制优化多模型响应处理链路,消息延迟由平均 1.2s 降至 300ms
  • 开发模型配置热更新功能,支持在不重启服务的前提下,通过 Web UI 动态调整模型参数、Token Key、向量存储策略等核心参数;
  • 设计知识库模块,支持 PDF、DOCX、TXT 格式内容上传与分片解析,结合 MinIO 存储文件并生成向量入库,实现数据私有化检索闭环。

人工智能医疗助手 2025.04 – 2025.05

技术栈:Spring Boot、LangChain4j、MongoDB、MySQL、MyBatis-Plus、Pinecone

项目描述:基于大语言模型构建智能医疗助手,结合 RAG 技术,面向患者提供智能化的问诊、预约挂号、取消挂号等服务。系统通过 LangChain4j 集成 Pinecone 向量检索与多模态能力,提升模型对专业医学知识的理解与响应准确性。

核心职责

  • 基于 MongoDB 构建长期对话记忆机制,增强多轮问答的上下文连贯性与语义理解;
  • 设计系统提示词模板与用户意图识别模块,使 LLM 问答准确率提升约 20%;
  • 开发预约挂号、取消挂号、查询号源等功能模块,通过 Function Calling 赋予模型业务逻辑调用能力,实现 LLM 执行业务任务的落地;
  • 基于 Pinecone 构建医疗知识向量库,实现毫秒级语义检索,覆盖超过 10 万条专业医学知识,显著提升回答的专业性与精准度。

派聪明伴侣 2025.05 – 2025.07

技术栈:Spring Boot 3、Spring AI、RAG、Tool Calling、MCP、Ollama、PGvector、SSE

项目描述:基于大语言模型打造的智能旅游规划应用,支持多轮上下文对话、知识检索(RAG)、自主任务规划与 PDF 行程报告生成,实现从用户提问到完整旅游方案交付的端到端智能体验,适配 SaaS 与私有化部署场景。

核心职责

  • 深度集成 Spring AI,接入通义千问、Ollama 等大模型能力,支持多模型热切换;
  • 实现 多轮对话持久化机制(MySQL + 文件系统 + Kryo 序列化),支持服务重启后的上下文恢复;开发 Re-Reading Advisor 模块,提升模型在复杂提问下的上下文理解能力;
  • 构建高性能 RAG 知识库,基于 PGvector 实现文档向量化存储与语义检索,平均检索耗时 < 200ms;
  • 基于 ReAct 架构 构建自主规划型 Agent,支持任务分解与工具链调用(网页搜索、PDF 生成等),五日行程规划任务平均生成时间 < 30 秒;
  • 接入 高德地图 MCP 获取位置上下文,结合用户历史行为推荐兴趣点;实现关键词图片检索并通过 SSE 实时返回;
  • 利用 SseEmitter + CompletableFuture 实现 AI 流式答复,首响应时间控制在 500ms 以内。

RAG 知识库检索系统 2025.01 – 2025.03

技术栈:Spring Boot、Spring AI、Ollama(DeepSeek)、OpenAI API、Redis、Docker、RAG、PgVector

项目描述:融合 RAG(检索增强生成)与 AI 代码分析能力,构建企业级代码知识库与自动化评审体系。集成 GitHub Actions 与微信公众号,实现从代码提交、语义级评审建议生成,到实时通知开发者的闭环处理链路。

核心职责

  • 基于 Spring AI 搭建多格式文档解析与向量化模块,支持 Markdown、PDF、Word 等文档自动解析与嵌入存储;采用 PgVector + Redis 提升语义检索性能;
  • 构建 RAG 检索流程,将用户提问与检索片段拼接生成增强型 Prompt,结合上下文与语义召回提升企业私有问答准确率;
  • 集成 Ollama(DeepSeek)与 OpenAI API,提供统一 API 接口,支持多大模型适配与流式响应;
  • 设计 代码自动评审组件:接入 GitHub Webhook 与 Git Diff 数据,利用大模型自动识别代码风格、潜在缺陷与规范违规行为;
  • 基于 GitHub Actions 实现评审流程自动触发,将语义级别代码审查能力嵌入 CI/CD 流程;
  • 接入 微信公众号模板消息 API,将评审结果实时推送至开发者端,形成从提交到反馈的闭环;
  • 完成知识库与问答接口部署,RAG 推理平均响应时间控制在 800ms 内;自动评审组件已开源至 GitHub: 开源地址 🔗

DeepSeek RAG 增强检索知识库系统|后端开发 2025.04 – 2025.05

技术栈:Spring Boot、Spring AI、Redis、Ollama、PostgreSQL、JGit、Flux、MCP

项目描述:基于 Spring AI 框架集成 Ollama DeepSeek 与 OpenAI 模型,构建智能化知识库系统,支持文档解析与 Git 仓库分析。用户上传文档或代码后,系统自动向量化并入库,支持自然语言语义检索与多轮上下文对话。

核心职责

  • 封装 Spring AI + Ollama DeepSeek + OpenAI 统一接口,支持大模型热切换与上下文共享;
  • 基于 PostgreSQL 构建文档向量索引,结合语义分段与稀疏索引加速检索,平均查询耗时 < 100ms
  • 接入 JGit 抽取代码仓历史变更、注释与提交记录,生成代码知识图谱,支持增量更新;
  • 使用 Flux 实现 AI 流式对话,结合 ChatMemory + Advisor 机制保持多轮复杂问答的上下文连贯性;
  • 基于 MCP 协议 构建自主规划型 Agent,实现“发布模板生成 → 发帖 → 渠道调用”全流程自动化,平均耗时 < 3 秒
  • 通过 Cookie 模拟登录 + 模板填充策略,打通 CSDN、微信公众号等平台自动发布与通知追踪流程。

(样例)项目名称:派聪明 – 智能 RAG 知识库系统

写法 1:

项目介绍:派聪明是基于 RAG(检索增强生成)架构开发的企业级知识库系统,支持大文件分片上传、文档向量化处理和语义检索,实现了从文档管理到智能问答的完整流程,解决企业知识沉淀与高效利用的难题。

个人职责:

  • 负责系统整体架构设计:主要运用了 Spring Boot、Spring Security、Spring Data JPA、MySQL、Redis、MinIO、Elasticsearch、Kafka 和 JWT 等技术栈,构建了模块化的分层架构,实现功能模块间的低耦合高内聚。
  • 负责存储设计:通过运用 MySQL+Redis+MinIO+Elasticsearch 的多级存储结构,实现了文件元数据、对象存储、向量数据分离,设计了基于组织标签的权限模型,有效解决了数据访问控制与检索性能问题。
  • 负责落地实现:通过引入模块化+异步化设计思路,让文件上传、处理、向量化和检索各环节解耦清晰,模块职责明确。有效提升了系统的可扩展性和可维护性。
  • 进行性能调优:对文件分片上传、向量检索等关键环节进行压力测试和性能优化,检索响应时间从初始的 800ms 降低到 200ms,支持 TB 级文档存储和毫秒级检索。

难点/亮点:

  • 多级权限控制:通过设计基于组织标签的多级权限模型,结合用户角色、组织归属和文件属性的权限过滤,实现了精细化的文档访问控制,确保敏感数据安全。
  • 高性能文件处理:采用分片上传、断点续传技术,结合 Redis 缓存文件状态,MinIO 存储文件内容,实现了大文件的可靠上传,同时通过 Kafka 解耦实现文件异步处理。
  • RAG 核心架构:实现了基于检索增强的 RAG 核心架构,通过 Embedding API 生成文档向量,使用 Elasticsearch 存储和检索向量数据,与传统关键词搜索相比提升检索准确率 40%以上。
  • 检索增强生成:实现了基于检索结果的 Prompt 构建机制,整合文档内容与元数据(相关度、权限信息),提升大模型回复的准确性和可溯源性。
  • 流式对话体验:基于 WebSocket 实现了流式对话响应,结合会话历史管理和上下文追踪,通过 DeepSeek API 提供的智能回复,形成完整 RAG 对话闭环。

写法 2:

项目介绍:实习或工作期间参与开发的基于 RAG(检索增强生成)架构的智能知识库系统,支持文档管理、语义检索和智能问答,解决部门内部知识共享与利用的难题。

个人职责:

  • 参与系统架构设计:使用 Spring Boot、Spring Security、Spring Data JPA、MySQL、Redis、MinIO、Elasticsearch、Kafka 等技术栈,参与构建模块化的分层架构,实现系统各功能模块间的低耦合高内聚。
  • 独立负责文件处理模块:设计实现了完整的文件处理流水线,包括分片上传、文件合并、内容解析和向量化环节。使用 Redis 缓存分片状态,MinIO 存储文件,Apache Tika 解析文档,通过 Kafka 实现异步处理,解决大文件上传和处理效率挑战。
  • 主导 RAG 检索引擎开发:负责基于 Elasticsearch 实现混合检索引擎,结合向量相似度搜索和关键词匹配,设计多级权限过滤机制确保数据安全,将检索响应时间从 800ms 优化至 200ms,为智能问答提供核心支持。
  • 参与性能优化:对文件处理和向量检索等关键环节进行性能调优,协助将系统整体处理效率提升 3 倍,满足企业级使用需求,支持 TB 级文档存储和毫秒级检索。

难点/亮点:

  • 高性能文件处理设计:针对企业级大文件需求,设计完整的分片上传与断点续传方案,通过 Redis BitSet 存储分片状态,实现文件上传的可靠性和高效性,支持企业级文档管理需求。
  • 异步处理流水线:构建基于 Kafka 的文档处理异步流水线,解耦文件上传、解析和向量化过程,实现系统高可用性和扩展性,文档处理效率提升 3 倍。
  • 混合检索实现:实现基于 Elasticsearch 的混合检索功能,结合文本匹配和向量相似度查询,应用权限过滤设计,提升搜索结果的相关性和安全性,为用户提供更准确的检索体验。
  • Prompt 构建设计:设计检索结果到 Prompt 的转换逻辑,将文档内容与元数据(如文档来源、相关度得分)整合为结构化上下文,使大模型能够基于可靠的企业知识生成准确回答。
  • 数据安全与权限设计:基于组织标签实现多级权限控制,在检索引擎层面进行权限过滤,确保用户只能访问有权限的文档,保障企业敏感信息安全。
  • 实际业务贡献:负责的核心模块上线后显著提升了企业知识管理效率,用户文档检索时间缩短 60%,降低了员工培训成本,获得了使用部门的积极反馈。

AI 应用开发的一系列面试题

当然了,派聪明只是一个载体而已,我们更在乎的是,大家能够利用 AI 这波浪潮,在面试中展示出自己对 AI 的全面掌握,包括但不限于下面这些面试题(面试篇里还有很多,这里只是开胃菜):

①、你怎么看待 agent 开发的未来趋势的?

答:关于 agent 开发的未来趋势,我觉得这确实是一个很热门的领域。从目前的发展来看,AI agent 正在从简单的任务自动化向更复杂的决策和推理能力发展。

我觉得有几个趋势比较明显。首先是多模态能力的增强,agent 不仅能处理文本,还能理解图像、语音等多种输入。然后是更好的工具调用能力,就像我们现在看到的一些 agent 能够调用各种 API、操作不同的软件工具。

还有就是记忆和学习能力的提升,让 agent 能够从历史交互中学习,变得更加个性化和智能。

从开发角度来说,我觉得未来会有更多标准化的框架和工具出现,比如说 MCP,让开发者更容易构建和部署 agent。

②、对大模型有什么看法?

从一个 Java 后端开发的角度来说,我觉得大模型确实是个很有意思的技术方向。最近我们团队也在讨论怎么把 AI 能力集成到现有的业务系统中,比如用大模型来做智能客服、代码审查辅助、或者业务数据的智能分析。

技术上来说,大模型的 API 调用其实跟我们平时调用其他第三方服务差不多,主要是 HTTP 接口的对接。

✅ 技术派集成 DeepSeek 到派聪明 AI 助手

不过在实际集成的时候需要考虑一些问题,比如响应时间比较长、成本控制、数据安全性等等。我们最近在调研一些开源的大模型,比如说 DeepSeek 的轻量级版本,看看能不能部署在自己的服务器上。

从业务角度来看,我觉得大模型可能会改变很多传统的开发模式,比如以前需要大量规则引擎和复杂逻辑的地方,现在可能用大模型就能解决。不过具体怎么落地还需要更多的实践。

③、RAG 了解吗?

RAG 就是 Retrieval-Augmented Generation,检索增强生成。简单来说就是在大模型生成回答之前,先从知识库中检索相关的信息,然后把这些信息作为上下文提供给大模型,让它基于这些真实的数据来生成更准确的回答。

我们这个派聪明项目主要是为了解决企业内部的知识管理问题。以前大家遇到技术问题或者业务问题,都要去翻文档或者问同事,效率比较低。所以我们就想做一个智能知识库,能够快速回答各种问题。

技术实现上,我们用的是比较经典的 RAG 架构。首先把公司的各种文档、wiki、代码注释这些都收集起来,然后用 Apache Tika 技术提取出纯文本信息,然后将长文档智能切分成多个语义完整的文本块。

用户提问的时候,我们先把问题也转换成向量,然后在 ES 中做混合检索,包括关键字精确查询和语义检索,找出最相关的几个文档片段。接着把这些片段和用户的问题一起作为 prompt 发送给大模型,比如 DeepSeek,让它基于这些上下文来生成回答。

后端我们用的是 Spring Boot 3.4.2,主要负责接口的处理、向量搜索、大模型调用这些逻辑。前端用的 Vue,整体用户体验还是非常不错的。

不过在实际开发过程中也遇到了不少挑战,比如文本分割的粒度怎么控制、检索的准确率怎么提升、成本怎么控制等等。现在这个系统已经在公司内部使用了,效果还可以(社招党可以这样讲)。

④、怎么理解 AI 和传统业务结合?

我觉得 AI 和传统业务结合,关键是要找到真正的痛点,而不是为了 AI 而 AI。我们团队在探索的时候,首先会梳理现有的业务流程,看看哪些环节效率低、人力成本高,或者容易出错,这些地方往往是 AI 能发挥价值的地方。

比如客服系统,以前用户咨询都要人工回复,客服小姐姐压力很大,响应也不够及时。就可以接入大模型,先让 AI 回答一些常见问题,解决不了的再转人工。这样既提高了效率,又降低了成本。

还有就是代码审查流程。以前都是靠人工 review,有时候会漏掉一些潜在问题。现在就可以用 AI 来做初步的代码扫描,检查一些常见的代码规范问题、潜在的 bug 等等,然后人工再做深度审查。这样既保证了质量,又提高了效率。

包括我们做派聪明 AI 知识库的 RAG 检索,其实也是为了解决传统关键词匹配效率的问题。

我觉得成功的 AI 业务结合,一定要让用户感觉不到 AI 的存在,但是明显感觉到效率在提升。AI 应该是润物细无声地融入到业务流程中,而不是生硬地替换原有的功能。

⑤、AI Agent 是什么?

AI Agent 是比传统 AI 应用更智能的系统,简单来说就是能够自主执行任务、做决策的 AI 助手。

传统的 AI 应用更像是”问答机器”,你问什么它答什么。但是 Agent 不一样,它能理解你的目标,然后自己制定计划,调用各种工具来完成任务,就像一个真正的助手一样。

举个例子,如果我们跟普通的 AI 说”帮我查一下技术派这个月的 PV 走势”,它可能只会给一些通用的分析方法。但是 Agent 会主动去连接数据库,搜查项目源码找出 PV 关联的表名、字段名,然后再查询相关数据,然后用合适的工具进行分析,最后生成报告出来。~~用 Trae IDE 开发的时候,就有这种感觉。(Cursor 也行)~~

从技术架构上来说,Agent 通常包含几个核心组件:首先是规划模块,负责理解任务并制定执行计划;然后是工具调用模块,能够调用各种 API、数据库、文件系统等外部资源;还有记忆模块,能够记住之前的对话和操作历史;最后是反思模块,能够评估执行结果并调整策略。

我最近也在尝试做一些 Agent 相关的项目。比如我在考虑做一个运维 Agent,它能够监控系统状态,发现异常的时候自动分析日志,甚至执行一些简单的修复操作。

从开发的角度来说,Agent 其实就是把大模型、工具调用、流程控制这些技术整合在一起。后端可以用 SpringAI 来搭建,主要是处理 Agent 的调度逻辑、工具集成、状态管理这些。

不过 Agent 也有一些挑战,比如如何保证执行的可靠性、如何控制成本、如何处理复杂的异常情况等等。现在很多开源框架像 LangChain、AutoGPT 这些都在尝试解决这些问题。

包括之前很火的 Manus,包括 AI Coding 中各个智能体。

我觉得 Agent 可能是未来 AI 应用的一个重要方向,特别是在企业级应用中,能够真正提高工作效率。

⑥、未来的 AI 和 AI agent 会是什么样?

我觉得未来的 AI 会变得更加”无感化”,就像现在的互联网一样,我们不会觉得自己在用互联网,但它已经渗透到生活的方方面面。AI 也会是这样,不再是一个独立的产品,而是融入到各种业务系统中。

从技术架构的角度来说,我觉得未来的 AI 系统会更加模块化和标准化。就像现在我们用的 Spring AI 框架,能让我们开发者很容易地把 AI 能力集成到自己的应用中。可能几行代码就能给系统加上智能推荐、自动分析、智能客服这些功能。AI Agent 我觉得会变得更加专业化和垂直化。

现在的 Agent 还比较通用,但是未来可能会有专门的代码审查 Agent、专门的运维 Agent、专门的测试 Agent 等等。每个 Agent 在自己的领域内会变得非常专业,甚至超过普通的工程师。现在各大厂的 AI Coding 也都在主力推这些工具。

另外我觉得多 Agent 协作会成为趋势。就像现在的微服务架构一样,不同的 Agent 负责不同的职能,然后通过某种协议来协作完成复杂的任务。比如一个需求进来,产品 Agent 负责理解需求,架构 Agent 负责系统设计,开发 Agent 负责写代码,测试 Agent 负责测试,运维 Agent 负责部署。

从我们后端开发的工作来说,我觉得 AI 不会完全替代我们,但是会改变我们的工作方式。可能以后我们更多的是在设计系统架构、定义业务规则、优化性能这些高层次的工作上,而一些重复性的编码工作会被 AI 处理。

不过说实话,技术变化这么快,具体会发展成什么样很难预测。但有一点我比较确定,就是会越来越智能,越来越好用。

⑦、MCP 了解吗?

从我的理解来看,MCP 解决了一个很实际的问题。现在我们在做 AI 应用的时候,经常需要让大模型连接各种外部数据源,比如数据库、API、文件系统等等,但是每个应用都要自己实现这些连接逻辑,没有统一的标准,开发起来比较麻烦,维护成本也高。

MCP 就像是给 AI 应用定义了一套”数据接口标准”,有点像我们后端开发中的 REST API 规范一样。通过这个标准,不同的数据源和工具都可以用统一的方式暴露给大模型,大模型也能用统一的方式来访问这些资源。

这对我们开发者来说是个好消息,因为可以大大简化 AI 应用的开发复杂度。比如我们要做一个企业内部的 AI 助手,需要连接 HR 系统、财务系统、项目管理系统等等,如果都有 MCP 的支持,我们就不用为每个系统单独写连接器了。

而且这种标准化还有利于生态的发展,可能会有更多第三方提供符合 MCP 标准的连接器和工具,让我们有更多的选择。

从技术实现上来说,MCP 定义了一套通信协议和数据格式,让大模型能够以标准化的方式请求外部资源,并处理返回的数据。这样既保证了安全性,又提高了互操作性。

⑧、派聪明项目中你遇到过哪些难点?

在‘派聪明’项目的文档处理流程中,我遇到了一个技术挑战: 如何在处理超大文档时,避免因一次性加载文件而导致的内存溢出(OOM)风险,同时保证切分后的文本块(Chunks)在语义上的完整性。

具体来说,简单的流式分块处理(比如每 1MB 切一块)虽然能解决 OOM 问题,但这种‘硬切分’会破坏句子、段落甚至代码块的完整结构,导致上下文丢失。如果用户查询的内容恰好落在一个被切开的知识点上,检索系统就很难召回完整的上下文,从而影响最终生成答案的质量。

为了解决这个‘OOM风险’与‘检索质量下降’之间的矛盾,我没有采用简单的流式切块,而是设计并实现了一套‘父文档-子切片’的二级索引策略。这个策略的核心思想是: 用小的、精确的‘子切片’来做检索,用大的、上下文完整的‘父文档’来做推理。

我的具体实现步骤是这样的:

第一步:利用 Apache Tika 的流式解析能力,通过自定义 ContentHandler ,将文档内容以数据流的形式读入。我设置了一个内存缓冲区和一个阈值(比如 2000 个字符)。当缓冲区中的内容达到这个阈值时,我就认为获得了一个完整的‘父文档’块。从根本上避免将整个GB级的大文件加载到内存中。

第二步:获得一个‘父文档’块后,我并不会直接将其入库。而是调用之前实现的、基于 HanLP 的语义分割算法,将这个‘父文档’块进一步切分为更小的、带有重叠(Overlap)的‘子切片’(比如 200 个字符)。

第三步:我将处理好的数据存入两个地方:

  • 向量数据库 :只存储和索引那些小的‘子切片’。
  • 文档数据库 :存储未经再次切分的‘父文档’块,并为每个父文档生成一个唯一的ID。在‘子切片’存入向量库时,我会将它所属的‘父文档’ID 作为元数据(Metadata)一同存储。

第四步:当用户提问时,检索流程分为两步:

①、在向量数据库中,将用户的问题匹配那些小的‘子切片’。因为子切片粒度小,所以匹配精度非常高。

②、找到最相关的几个‘子切片’后,通过它们元数据中的‘父文档’ID,去文档数据库中取回它们所属的、完整的‘父文档’块。

③、将这些包含丰富上下文的‘父文档’块作为背景知识,连同用户问题一起提供给大模型,由模型进行理解和回答。

通过这套‘父文档-子切片’的策略,完美地解决最初的挑战:

解决OOM问题 :整个处理流程是流式的,内存占用被控制在恒定的低水平。

保证检索精度 :检索是在小粒度的‘子切片’上进行的,匹配更精确。

最终交给大模型的是完整的‘父文档’,避免了语义割裂,确保高质量的回答生成。

文末附加内容
暂无评论

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
下一篇