✅派聪明RAG项目如何写到简历上？（附 20 道精选 AI 面试题）

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

Color1

• 如果有引发误会，我就只能保留前三个，其他都会删掉，望周知。
• 项目的写法有很多，往后面翻一翻。
• 教程和源码的获取方式：https://t.zsxq.com/XBc0a
• 派聪明的学习路线：https://paicoding.com/article/detail/2530200055836673

:::

xxxx数智有限公司｜研发部｜Java 后端 / AI 开发实习生 2026.05 - 2026.06

项目名称：政务热线工单平台｜RAG 智能政务问答助手

项目简介：面向政务热线与政策知识查询场景，参与建设支持多格式文档解析、混合检索、引用溯源及多租户权限控制的 RAG 问答系统，解决政策名称、事项编号等精确查询场景下纯向量检索效果不足的问题，支撑 13 个租户、8.32 万份知识文档的管理与检索。

技术栈：Java、RAG、Milvus、Elasticsearch、BM25、BGE Reranker、JWT、RBAC、MySQL

核心职责：

• 负责 RAG 检索策略优化，针对政策名称、业务事项及政策编号等专业词汇难以通过语义向量准确召回的问题，将原有单路向量检索升级为 BM25 + Dense Vector 双路召回，并通过 Reranker 精排候选片段；在 500 条固定测试集上，Recall@5 由 82.3% 提升至 91.6%，提高 9.3 个百分点。

• 设计混合检索与引用溯源机制，通过 Milvus 获取 Top-20 语义候选，结合 Elasticsearch BM25 关键词结果进行合并去重，再使用 bge-reranker-v2-m3 选取最终 Top-5；统一维护 Document、Chunk 及 Source Metadata，使模型回答能够引用对应政策文档及原始内容。

• 参与多租户知识库权限与会话管理开发，基于 JWT + RBAC + TenantContext 管理用户身份及租户权限，并在 Milvus、Elasticsearch 检索阶段注入 Tenant / ACL 过滤条件，避免其他租户的知识片段进入模型上下文；同时实现会话消息持久化、近期记忆与历史摘要管理，支持多轮政务咨询。

派聪明（企业级 RAG 知识库问答 Agent）

项目简介：基于 Elasticsearch 8 混合检索与 ReAct 工具调用的企业级知识库问答系统，支持大文件分片上传、异步流式解析、多级权限隔离检索、多轮复合意图问答与事后引用核验，检索与回答质量由 50 题离线评测集持续验证。

技术栈：Spring Boot 3 + Elasticsearch 8 + 阿里百炼 text-embedding-v4 / gte-rerank-v2 + DeepSeek + Kafka + Redis + MySQL + MinIO

【截图：派聪明简历核心技术栈与指标看板；风格：data-board；截图目标：展示派聪明简历包装中的关键架构组件与真实评测提升数据；关键词：Recall@5 76.1%、120 秒请求预算、三级阈值截断】

核心职责：

• 实现 ReAct 问答与工具调度机制，注册知识库检索、文档摘要、反馈记录、统计查询 4 类工具，通过第 1 轮强制挂载工具与 5 类跳过检索白名单解决模型盲目自信不查询知识库的问题，支持单轮多工具调用与最多 4 轮、8 次调用的分步推理，多次检索自动顺延引用编号并由 120 秒请求级截止时间保障超时可控
• 构建混合检索与三级防噪截断流程，BM25 与 2048 维向量 KNN 双路并行召回并经 RRF（k=60）融合，接入 gte-rerank-v2 对前 50 条候选精排，分别在精排（0.1）、RRF 兜底（0.028）和纯文本降级（0.3）设置分数阈值拦截低分噪声，分块级 Recall@5 达 76.1%、文档级召回率达 100%
• 设计父子分块扩展与多阶段防幻觉机制，检索命中 512 字符子块后自动拉取前后相邻分块合并为最多 1500 字符的父块补全上下文，生成侧采用 0.3 低温采样与局部拒答约束，生成后在独立线程池提取带引用编号的句子与父块原文逐句核验，自动标记可疑引用
• 搭建用户负向反馈修正与问题定位机制，提供反馈接口与对话工具将评价写入 Redis，后续对话自动注入该用户最新 5 条反馈实时修正回答偏好，同时将点踩记录关联原始提问、回答与分块引用映射定位检索或生成阶段问题，回流扩充离线评测集
• 落地 50 道题的 7 类场景离线评测与人工校准体系，统计分块级 Recall@5、MRR、NDCG@5 与评委打分，对检索未命中但评委判对的异常样本强制人工复核，模型评委与人工复核一致率达 80%（Cohen's kappa 0.61）

xxx｜国家重点实验室｜Agent 开发实习生 2026.05 – 至今

项目名称：内网 RAG 知识检索与智能研判系统

项目简介：面向涉密内网技术资料检索与趋势研判场景，独立负责 RAG 核心模块开发，在公网隔离环境完成模型与检索组件私有化部署，支持长技术报告知识问答、复杂问题多轮检索及证据溯源。

技术栈：Python、MinerU、BGE-M3、Milvus、BM25、RRF、Reranker、Qwen、Celery、Redis

核心职责：

• 负责内网 RAG 系统开发，在公网隔离环境完成 MinerU、BGE-M3、Milvus、Reranker、Qwen 等组件本地化部署；针对长技术报告固定切片容易造成语义割裂与重复上下文的问题，采用 Parent-Child Chunk 分层索引，以细粒度子块完成召回并回溯父级内容生成回答。

• 针对缩写、设备型号及专业术语在纯向量检索中容易漏召回的问题，融合 BGE-M3 Dense 与 BM25 Sparse 双路检索，通过 RRF 合并候选结果并使用 BGE Reranker 精排，同时结合时间、技术领域等 Metadata Filter 缩小检索范围；在固定技术问答评测集上 Recall@10 由 0.72 提升至 0.87，MRR@10 由 0.64 提升至 0.79。

• 针对 PDF 解析、Chunking、Embedding 等耗时操作阻塞在线问答的问题，基于 Celery + Redis 将文档解析、向量化及索引写入改为异步任务，并缓存高频 Query 与 Retrieval / Rerank 结果，减少重复模型计算与向量检索。

• 针对复杂趋势问题单次检索难以覆盖完整证据的问题，实现 Query Rewrite 与多轮补充检索，根据已获取证据动态调整查询并结合时间、技术领域等条件限制检索范围；进一步结合主题演化、时间序列与变点检测生成趋势判断，并为 Document / Page / Chunk 建立 Evidence ID，使分析结论能够回溯至原始文档及具体页面。

派聪明 RAG 知识库 RustFS

项目简介：基于 Elasticsearch 混合搜索的 RAG 知识库系统，支持文档上传、分块解析、向量检索和智能问答。

技术栈：Spring Boot、RustFS、AWS SDK for Java v2、Elasticsearch、Kafka、PyIceberg、DuckDB

核心职责：

• 将对象存储从 MinIO 迁移到 RustFS，通过标准 S3 API 对接 AWS SDK for Java v2，业务代码零改动
• 设计分片上传合并方案，解决浏览器分片小于 S3 Multipart 5 MiB 限制的问题，支持断点续传和失败自动回滚
• 编写 Python 跨存储迁移工具，支持 SHA-256 校验、元数据保留和 dry-run 模式，迁移过程零数据丢失
• 集成 RustFS S3 Tables（Iceberg REST Catalog），实现 RAG 分块数据的结构化存储和 SQL 查询
• 配置 Docker Compose 编排 RustFS 服务，实现健康检查、CORS 跨域、内外网双地址预签名

YuForge Knowledge Engine｜研发知识库与 AI Agent 知识引擎

GitHub： gxySkywalker/YuForge-Knowledge-Engine⁠

项目简介：面向企业研发团队与 Coding Agent 的研发知识引擎，统一管理需求、架构、规范及版本文档，通过 RAG 为开发者与 Codex 等 Agent 提供带引用、可追溯、权限隔离的知识检索与智能问答，并支持 Web、REST、CLI、MCP 多种接入方式。

技术栈：Java、Spring Boot、MySQL、Redis、Kafka、MinIO、Elasticsearch、Apache Tika、WebFlux、Qwen Embedding / Reranker、DeepSeek、MCP

核心职责：

• 基于 Elasticsearch 实现 Hybrid Retrieval，融合 BM25 关键词检索与 2048 维 Dense Vector 语义召回，通过 RRF 合并候选结果并使用 Qwen3 Reranker 精排；增加 Confidence Gate 对低置信度结果拒答，兼顾代码标识、专业术语与自然语言查询的检索效果。

• 设计 Evidence-grounded RAG 问答机制，针对跨需求、架构、规范等多主题问题拆分检索子任务，并按照显式版本、知识权威等级及相关性选择证据；生成结果要求逐项绑定稳定 Citation，并对引用有效性进行校验，在证据不足时支持部分回答或明确拒答，减少无依据内容进入研发决策。

• 设计 Asset → DocumentVersion → ContentNode → Chunk → Embedding 分层知识模型，通过 DocumentVersion 管理同一研发资产的历史版本，并以状态机控制解析、切片、Embedding、索引及失败恢复；基于 Kafka 将文件上传与知识加工异步执行，支持 100 MiB 文件、20 分片乱序上传、重复分片幂等及断点续传。

• 针对企业知识存在部门、项目及资产权限边界的问题，基于用户角色、组织标签、公开属性与资产归属生成 ACL Filter，并在 BM25 与向量检索阶段直接限制候选范围，避免无权限内容被召回后进入 LLM Context，实现检索阶段的数据权限隔离。

• 建立 Retrieval 与 Generation 双层评测机制，通过黄金数据集持续评估 Recall、MRR、nDCG 等检索指标，以及事实完整度、Citation 有效性与拒答准确率；结合自动化回归覆盖知识版本、权限、检索及问答场景，避免检索策略或模型调整造成效果退化。

项目名称：PaiSmart 2026年4月-2026年5月

项目介绍：基于 RAG 的企业级 AI 知识库，支持多租户文档智能检索与对话问答，提供从文档上传、切片向量化到语义检索、流式对话等。

技术栈：Spring Boot 3.4 / WebSocket / Elasticsearch 8 / Kafka / Redis / MinIO / MySQL / DeepSeek API / 阿里 Embedding

核心职责：

• 基于 WebSocket 实现全双工流式对话，后端通过 WebFlux 的 Stream 接入 DeepSeek 等 LLM 的 SSE 流，实现逐字输出；支持用户主动中断，后端同步取消 LLM 侧的流式连接，避免错误提示词下的 Token 消耗；整体首字响应延迟控制在 500ms 以内。
• 基于 LiteParse 命令行工具重构 PDF 解析流程，通过子进程调用实现本地 OCR，解决扫描件与图片型 PDF 在知识库中无法被检索的问题
• 设计可插拔 OCR 适配层，借助 LiteParse 的 ocr-server-url 机制将识别引擎在本地 Tesseract 与阿里云高精版 OCR 之间无缝切换
• 实现对话内容的持久化和断线续传，每个流式内容原子写入 Redis，并通过状态机维持状态；用户断线重连后自动恢复上一次输出进度，不丢失已生成文本，保障弱网环境下的用户体验。
• 利用 Elasticsearch + IK 分词器对知识库文档进行索引和向量检索，支持 Word、PDF 和 TXT 等多种文本类型；并集成阿里 Embedding 模型进行文本到向量的转换，支持 2048 维；再结合 ES 的 KNN 向量召回、关键词过滤和 BM25 重排序实现「关键词+语义」的双引擎搜索，同时内嵌多租户权限过滤，确保数据隔离。
• 基于 Spring WebSocket 实现全双工流式对话，后端通过 WebFlux 的 Reactive Stream 接入 DeepSeek 等 LLM 的 SSE 流，实现逐字输出；支持用户主动中断生成，后端同步取消 LLM 侧的流式连接，避免无效 Token 消耗；整体首字响应延迟控制在 500ms 以内。
• 前端使用 SparkMD5 计算文件指纹，然后开启 4 个 worker 并发上传分片；后端通过 Bitmap 追踪分片状态；合并阶段按 chunkIndex 升序组装后调用 MinIO 进行合并，保证分片不乱序。
• 利用 Kafka 进行异步文档处理，覆盖「文件解析 → 文本切片 → 向量化入库」全流程，并通过事务确保生产者侧消息不丢失不重复，消费端失败的消息经 4 次重试后自动路由至死信队列。
• 通过 Redis 维护 20 条消息的上下文窗口，供 LLM 调用时毫秒级加载；并将完整对话内容持久化到 MySQL。
• 实现可热插拔的多模型路由与 Token 配额管理，支持运行时切换 DeepSeek、通义千问等 LLM 和 Embedding 供应商，无需重启服务；并通过流式 usage 解析实现精确的 Token 消耗计量，结合每日请求数 + Token 余额双维度限流，控制调用成本。

西南技术工程研究所｜大模型应用开发 2025.07 – 2026.02

项目名称：Agentic RAG 企业知识库系统

项目简介：面向环境工程领域的企业知识库系统，支持文档解析、知识图谱构建、结构化数据查询及智能问答，通过 Agentic RAG 完成复杂问题分析与知识检索，为科研场景提供智能检索能力。

技术栈：Spring Boot、MySQL、Redis、Kafka、Elasticsearch、MinIO、MinerU、Ollama

核心职责：

• 使用 Kafka 构建文档异步处理流程，将文件上传、解析、切片、向量化拆分为后台任务执行；结合 Redis Bitmap 管理分片上传状态，并使用 MinIO 实现大文件断点续传，提高文档处理吞吐能力。

• 设计 Agent 执行流程，根据用户问题复杂度动态选择 ReAct 或 Plan-Execute 两种执行模式；同时实现分层上下文管理，通过滑动窗口保留近期对话，对历史内容进行摘要压缩，降低长对话中的 Token 消耗。

• 实现意图驱动的混合检索模块，根据查询类型自动选择检索策略；普通问答采用 BM25、KNN 双路召回及 RRF 融合排序，复杂关系查询结合知识图谱完成多跳检索，并统一通过 Rerank 对文本与图谱结果进行排序，提高复杂问题检索准确率。

• 构建知识图谱增量更新机制，将文档实体、关系及文本片段建立关联索引，支持新增文档自动更新知识图谱，减少全量重建带来的计算开销。

• 建立 RAG 离线评测体系，基于 RAGAS 自动回放检索与生成流程，并结合人工校验持续评估证据相关性、信息覆盖率、回答忠实度及答案相关性等指标，核心指标稳定保持在 0.73～0.80。

写法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 服务器等。
• 利用 Elasticsearch 加 IK 分词器对知识库文档进行索引和向量检索，结合 KNN 向量召回与 BM25 关键词匹配，通过 RRF 融合排序实现语义加关键词的双引擎检索，经测试集评估检索命中率较纯关键词检索提升约25%。
• 引入 MCP 协议对本地文件操作、PDF 生成及数据库查询等能力进行 Server 端封装，实现了Agent 与工具生态的解耦。
• 参考 OpenManus 开源架构，设计了分层智能体体系（BaseAgent、ReActAgent、ToolCallAgent）。利用 SpringAI 的 FunctionCallback 机制实现本地方法的自主调用，以及 ReAct 推理，赋予 Agent“思考-规划-行动-观察”的自主决策能力，使其能够处理“检索/搜索-生成文本-生成总结PDF”等跨多步骤的复杂任务。
• 编写用户认证模块单元测试，结合 JUnit + Mockito 验证 Redis 引入前后的性能差异，为系统调优提供依据。
• 基于 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 芯片，你自己要做测试，没有实际测试过，你就写下一个）
• 基于 Redis Bitmap 将已上传分片状态查询由 N 次 Redis 往返优化为 1 次批量读取，并结合 MinIO 和数据库校验实现分片幂等和断点续传；前端采用 5MB 分片、单文件 4 并发上传。
• 构建 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）的理念，每个业务功能都有对应的测试用例，包括正常流程和异常流程。

项目名称：Agentic RAG 学术研究助手 时间：2026.02 – 2026.04

技术栈：Spring Boot、LangChain4j、Elasticsearch、Redis、MinIO、Kafka、Java 21

项目描述：基于 ReAct 实现的 Agentic RAG 系统，将检索能力封装为工具接入 Agent Loop，支持多格式文档上传、混合检索与多轮对话，并通过多租户隔离保障数据安全。

核心职责：

• 将 RAG 模块封装为 Agent Tool，构建“向量 + BM25”双路检索能力，并通过 RRF 融合与 Rerank 模型重排结果；结合多种文档切块策略，减少无关内容干扰

• 设计三级上下文管理机制，基于滑动窗口控制上下文长度，对历史对话进行异步压缩，在保证对话连贯性的同时减少长上下文带来的信息丢失与 Token 消耗

• 使用 Kafka 解耦文档解析流程，将上传、解析、向量化拆分为异步任务，并通过 Outbox 模式保证数据一致性

• 设计多租户隔离方案，使用 TransmittableThreadLocal 在虚拟线程中传递用户身份信息，在数据写入与查询阶段附加用户标识，实现文档级权限控制

• 对不同格式文档解析流程进行拆分，使用策略模式与工厂模式组织解析逻辑，使系统可以方便扩展新的文档类型

Tiny-RAG

GitSeek

项目名：基于 RAG 的问答助手 2025.08-2025.11 后端开发

项目简介：面向企业内部文档检索与知识问答场景，搭建一套基于 RAG 的问答助手。系统支持大文件上传与异步解析向量化、混合检索召回与多轮对话。

技术栈：Spring Boot、MySQL、MyBatis、Redis、Kafka、Elasticsearch（向量检索）、MinIO、Ollama

核心职责：

• 基于 MinIO 搭建对象存储承载大文件上传，使用 Kafka 构建文档异步处理，把上传、解析、切块、向量化彻底解耦，同时将向量和关键词存入 Elasticsearch 供混合检索。
• 使用 Redis 持久化多轮对话历史，针对超长对话引入摘要记忆策略，触发大模型对早期上下文进行压缩总结，减少上下文长度带来的推理成本。
• 设计文档分块与索引方案，用文档层级树组织章/段/句结构，以句子作为最小向量单元，并实现动态粒度检索，减少语义链被硬切导致的召回断裂，使检索 F1 提升约 10%。
• 本地部署向量模型完成文本块向量化，落地关键词检索加向量检索的混合检索，采用 RRF 倒数排名融合策略计算 TopK。
• 构建 RAG 效果评测与模型对比机制，设计多层次文档匹配算法评估检索质量，针对 bge、qwen 等向量模型输出 Precision、Recall、F1、MRR 等指标，为优化提供量化依据。

智能 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 级文档存储和毫秒级检索。

运维方向

项目名称：RAG 智能报价系统 2025.03 - 至今 运维工程师

技术栈：Spring Boot、Redis、MinIO、Elasticsearch、vLLM、Kubernetes、Prometheus、Grafana、Fluent Bit、NetworkPolicy、Helm

项目简介：为某传感器制造企业构建的智能报价系统，集成 RAG 架构与中文大模型，服务于内部销售人员与官网用户，系统日均处理超 5000 次请求，基于 Kubernetes 私有平台部署，保障数据不出内网。

个人职责：

• 部署并维护 Spring Boot、Redis、MinIO、Elasticsearch 等核心服务，基于 Deployment + Service + Ingress 实现高可用访问。90% 的线上故障可在 10 分钟内定位并修复，平均故障恢复时间 < 15 分钟。
• 集成 vLLM 推理框架，引入 NVIDIA GPU Operator，完成 Qwen-7B 等模型的本地化部署与调优。
• 为无状态服务和大模型推理服务配置 HPA 弹性伸缩策略，结合 8 张 RTX 5090 显卡实现动态调度，应对销售高峰期 200-300 QPS 的突增流量，保障 P95 延迟 ≤600ms。
• 搭建 Prometheus + Grafana 的全链路监控体系，采集 JVM 状态、Pod 资源占用、HTTP 错误率、GPU 利用率等指标，并配置自动告警。
• 使用 Fluent Bit 收集容器日志同步至 Elasticsearch，结合 Kibana 支持基于 TraceID 的链路级检索。
• 通过 NetworkPolicy 实现前后端服务间的访问控制，防止敏感组件（如数据库）被直接暴露。
• 沉淀 Helm Chart 与监控告警模板，形成可复用的基础设施交付能力，缩短后续项目上线周期。

工作党1

龙软智能矿山 AI 知识库平台 Java 开发工程师 2025.06 - 至今

项目简介：围绕矿山企业知识碎片化、AI 能力弱等问题，构建覆盖地质、生产、安全等多领域的企业级智能知识平台。

技术栈：Spring Boot、Redis、MySQL、Elasticsearch、OpenSearch、FastDFS、MQ、百炼向量模型、IK Analyzer、LangChain、ChatGLM、Vue

核心职责：

• 设计基于 MQ 解耦的文件处理流程，支持大文件分片上传与断点续传；引入 Redis 构建全链路文件状态缓存，支撑上传→解析→入库→向量化→检索等流程。
• 通过接入公司 AI 中台与数据中台，整合多源异构知识，结合 RAG 检索增强技术，实现矿体测算、瓦斯分析等复杂任务智能处理，支持文字对话、数字人问答等多模态交互。
• 实现基于 Redis 的对话上下文管理机制，以用户会话 ID 为索引，按时间戳顺序存储多轮历史消息，支持合理过期策略，提升智能对话的连贯性与上下文感知能力。
• 自研 VectorStore 接口，支持将百炼模型生成的语义向量写入 Elasticsearch；结合 IK 分词器构建混合检索引擎，融合向量 KNN 召回 + BM25 重排策略，实现语义与关键词双通道查询，关键词命中率提升约 40%。
• 引入 Prompt 重写机制与上下文增强策略，提高查询语义精度与检索相关性；结合定制 Prompt 模板限制回答边界，降低生成幻觉；编写时间、文件操作、简单计算等可调用工具类，强化对话端真实业务能力。

杰润软件（苏州） | 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、微信公众号等平台自动发布与通知追踪流程。

项目名称：智能医疗客服系统 2025.01 - 2025.03 Java 后端开发

项目简介：本项目基于 Java 与大语言模型（LLM）技术构建的智能医疗助手系统，通过集成 ChatGPT、DeepSeek 等模型，为医疗机构提供智能客服、AI 分导诊、挂号管理等功能，优化医疗服务流程。

技术栈：Spring Boot、LangChain4j、MySQL、MongoDB、Pinecone、RAG、ChatGPT、DeepSeek

核心职责：

• 使用 LangChain4j 封装智能问答服务，集成 DeepSeek、通义千问等模型，实现多模型统一调用，加载自定义 Prompt，让 LLM 扮演医疗顾问角色。
• 构建 RAG 智能问答系统，结合 Elasticsearch + IK 分词实现关键词索引，调用豆包 Embedding API 实现语义向量转换，融合关键词与语义双引擎检索。
• 使用 Kafka 解耦文件上传、向量化与检索流程，配合 Redis 管理文件状态，MinIO 存储内容，支持大文件分片上传与断点续传。
• 利用 MongoDB 记录对话历史，封装 AIService 实现多用户会话隔离，结合 RAG 增强问答准确率。
• 构建医疗对话智能体，设计 Tool 方法，借助 LangChain4j Function Calling 能力驱动大模型自动调用挂号相关后端接口。

模板20

实习经历

模板21

实习经历

22项目名称：Tiny-RAG 企业级知识库与智能对话平台 2025.11 – 2026.03

技术栈：Spring Boot、Redis、Ollama、Elasticsearch、MinIO、Kafka、Spring Security、WebSocket

项目描述：构建企业级 RAG 知识库平台，支持文档上传、解析、向量化、检索与对话能力。通过混合检索与上下文优化，提升知识问答在专有名词与长文本场景下的准确性。

核心职责：

• 实现 BM25 + 向量检索的混合检索引擎，基于 Elasticsearch + IK 分词构建关键词索引，同时使用 2048 维 Embedding 进行语义检索，并通过 KNN 召回 + Cross-Encoder 重排提升结果相关性。

• 设计 Parent-Child Indexing 方案，将文档切分为子块用于检索，再回溯父级段落恢复上下文，解决长文档检索中语义割裂问题。

• 使用 Kafka 解耦文档上传、解析与向量化流程，结合 Redis Bitmap 跟踪分片状态，配合 MinIO 与分片 MD5 校验实现断点续传。

• 实现 Dynamic Top-K 策略，根据召回分数动态控制传入 LLM 的上下文片段数量，在保证召回效果的同时降低 Token 消耗。

• 开发基于 LLM 的 Query Rewrite 模块，对用户问题进行指代消解与语义扩展，提高首轮检索命中率。

• 在检索阶段接入 Spring Security + RBAC 权限控制，实现租户隔离与文档级访问控制。

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问题 ：整个处理流程是流式的，内存占用被控制在恒定的低水平。

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

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

第二个回答

在派聪明项目中，我们有一个核心功能是大文件上传与合并 。我们发现当用户上传大文件并触发合并操作时，后端处理时间过长。如果同步处理，不仅会长时间占用主线程，导致前端请求超时，还容易因为网络波动导致任务失败。

我的目标是将耗时的‘文件合并与后续处理’从主流程中剥离出来，实现异步化，同时必须保证任务不丢失 ，即使处理失败也能有重试机制。

于是我引入了 Kafka 作为消息队列。

前端上传完成后，Controller 层只负责快速响应‘接收成功’，然后在一个 事务 中向 Kafka 发送一条 FileProcessingTask 消息。

FileProcessingTask task = new FileProcessingTask(
                    request.fileMd5(),
                    objectUrl,
                    request.fileName(),
                    fileUpload.getUserId(),
                    fileUpload.getOrgTag(),
                    fileUpload.isPublic()
            );

LogUtils.logBusiness("MERGE_FILE", userId, "发送文件处理任务到Kafka(事务): topic=%s, fileMd5=%s, fileName=%s", 
        kafkaConfig.getFileProcessingTopic(), request.fileMd5(), request.fileName());
kafkaTemplate.executeInTransaction(kt -> {
    kt.send(kafkaConfig.getFileProcessingTopic(), task);
    return true;
});

我在消费者端配置了死信队列策略 DeadLetterPublishingRecoverer。如果文件处理连续失败（比如重试 3 次后），消息会自动进入死信队列，而不是无限重试阻塞消费者。

在发送端，我使用了 executeInTransaction 方法，确保创建文件处理任务时，任务信息会可靠地发送到 fileProcessingTopic 主题，供消费者异步处理。如果发送失败，整个操作会回滚，避免出现"任务已创建但消息未发送"的不一致状态。

上线后经测试，500M 的大文件上传能稳定在 200毫秒内。

第三个回答

派聪明是一个支持多团队协作的系统（SaaS 模式）。最开始设计时，我们面临一个棘手问题：新注册用户的知识库怎么存，怎么隔离，怎么共享？我们需要一种机制，既能让用户拥有私有空间，又能支持未来的团队协作，且必须保证数据的绝对隔离。

于是我设计了一套基于组织标签 (OrgTag) 的自动装配机制，确保用户注册即拥有独立的、隔离的数据空间，且过程必须是原子性的。

我重构了 UserService 的注册流程，当用户注册时，系统不仅会插入一条用户记录，还会同步生成一个以 PRIVATE_ 开头的专属组织标签，并将其强制绑定为用户的“主组织”。

// src/main/java/com/yizhaoqi/smartpai/service/UserService.java
@Transactional // 确保用户创建和空间分配是原子操作
public void registerUser(String username, String password) {
    // 1. 基础校验与用户创建
    if (userRepository.findByUsername(username).isPresent()) {
        throw new CustomException("Username already exists", HttpStatus.BAD_REQUEST);
    }

    User user = new User();
    user.setUsername(username);
    user.setPassword(PasswordUtil.encode(password));

    // 2. 核心逻辑：自动生成私有组织标签
    // 格式如：PRIVATE_zhangsan，确保天然隔离
    String privateTagId = PRIVATE_TAG_PREFIX + username;

    // 3. 级联保存：先创建标签，再绑定用户
    createPrivateOrgTag(privateTagId, username, user);

    user.setOrgTags(privateTagId);       // 赋予权限
    user.setPrimaryOrg(privateTagId);    // 设置默认上下文

    userRepository.save(user);

    // 4. 更新缓存，保证后续请求能立即读到权限
    orgTagCacheService.cacheUserOrgTags(username, List.of(privateTagId));
}

这个设计确保了“用户A无法看到用户B的私有文件”，但却能共享组织下公开的共有文件。

09、knn 和关键词搜索为什么取交集，RRF 是不是更优解？

星球原贴：https://t.zsxq.com/D8EmY

相信大家看完后会更有底气，会对 RAG 和混合检索有更深的理解，拥抱 AI 不能只停留在工具上啊，还要从真实的项目经验着手。

1、先 KNN 再关键词取交集，是否会漏掉文档？

会的。用户搜"如何提升代码质量"，向量检索召回了一篇讲"重构最佳实践"的文档，语义高度相关。但 BM25 那边因为没有"代码质量"这几个字，召回不了。取交集就把这篇相关文档丢了。

用户搜索一个特定的错误码 AX-123 ，这个错误码可能出现在一篇非常长的、主题是“系统维护”的文档中。这篇文档的整体语义和“错误码”可能相去甚远，导致它在 KNN 召回中排名很低，甚至根本没被召回。那么，取交集自然也就找不到它了。

2、BM25 和 KNN 得分量纲不一致，加权计算是否不合适？

BM25 的得分是一个相对值，它没有固定上限，可以从零到几十甚至上百。得分高度依赖于词频（TF）、逆文档频率（IDF）等统计特征。

KNN（余弦相似度）的得分通常在 [0, 1] 或 [-1, 1] 的区间内。

简单的加权求和在量纲不一致的情况下确实有待改进。

3、通过 RRF 算法计算得分并排序是否好一些？

RRF (Reciprocal Rank Fusion, 倒数排名融合) 的核心思想是：“一个文档越是在多个不同的排名列表里都排在靠前的位置，它的最终得分就越高。”

计算公式为：RRF_Score(doc) = Σ (1 / (k + rank_i)) rank_i 是文档 doc 在第 i 个排名列表中的排名（比如在 BM25 结果中排第 3，在 KNN 结果中排第 10）。

k 是一个常数（通常设为 60），用于防止排名靠后的文档对总分影响过大。 RRF 能够解决量纲不一致的问题。无论 BM25 分数是 100 还是 1000，只要它排第一，贡献的都是 1 / (k + 1) 。

面试中，如果能自信地说出 BM25 和 KNN 分数量纲不一致的问题，并提出使用 RRF 作为解决方案，会是一个巨大的加分项。

4、面试时说“手动计算了 RRF 得分”，是否存在漏洞？

向 Elasticsearch 发送一个只包含 BM25 的查询，拿到一个排名列表。再发送一个只包含 KNN 的查询，拿到第二个排名列表。然后再写一个循环，遍历两个列表，根据 RRF 公式手动计算每个文档的最终得分，重新排序。

Elasticsearch 8.x 之后的版本，已经原生支持在一次查询中同时定义 knn 和 query （BM25），并直接指定使用 rrf 作为融合方法。这意味着可以只发送一次请求 ，ES 会在内部帮你完成所有事情，然后直接返回最终的、融合排序后的结果。

综合回答。 “在我项目的早期版本中，由于考虑的不充分，我确实分别执行了 KNN 和 BM25 查询，在下个版本中，我的优化方向是将 RRF 的计算下推到搜索引擎层，在一次请求中完成混合搜索和结果融合。”

10、为什么向量检索的时候不做权限过滤？混合检索的时候为什么不同时进行？

星球原贴：https://t.zsxq.com/P0GBc

答：

面试官你好：这里有这样的考量，如果向量检索的时候就考虑权限，那么需要在向量化的时候就充分考虑权限的问题，会增加向量的难度。

比如说 a 文档，对用户 1 有权限，或者对组织桃花岛有权限，那在存储向量的时候，就要考虑的非常复杂。

我们现在的做法，就相对明确很多，向量只向量文档，然后再去校验权限。彼此是解耦的，分离的，权限的变更不会影响到向量的结果。

这是一种设计选择，目的是为了区分“找不到”和“没权限”，从而提供更智能的用户体验。

就像你去找一个初级图书管理员，他只能进入“公共阅览区”。你问他：“有《凤凰项目技术架构》这本书吗？”。这本书其实在“内部资料室”里，但他进不去，所以他只能在公共区找一圈，然后告诉你：“对不起，我们图书馆没有这本书。”

你得到的反馈是“没有”，你以为是图书馆没收藏，然后就放弃了。

后置过滤的好处是，你去找图书馆的馆长（拥有特权的服务），他能进入所有区域。你问他同样的问题。

馆长先在所有书架 （包括公共区和内部资料室）上寻找，很快，他在内部资料室找到了这本书。

然后，他再看你的借书证，发现你的权限不够，不能进入内部资料室。

最后，他会告诉你：“这本书我们有 ，但它在内部资料室，需要特殊权限。你可以去某某部门申请。”

你得到了明确的反馈，你知道书是存在的，只是你权限不够，并且你还得到了下一步的行动指引。

所以， 在检索阶段不过滤权限，是为了获取一个“全集”的候选列表。然后，在应用层对这个全集进行权限校验，我们才能准确地知道哪些是“有权限看到的”，哪些是“没权限看到的”。

混合检索也可以分为两种路径，看你怎么选择了。

两阶段式（先向量召回，后关键词精排/过滤）。

第一阶段（召回）：对用户的查询进行向量化，然后在整个索引中进行向量相似度搜索，召回 recall_k 个（比如 100 个）最相似的文档。

第二阶段（精排/过滤）： 只在这 100 个结果的范围内 ，再进行关键词匹配，或者使用更复杂的模型（如 Cross-Encoder）进行重新排序。

第二种方式，并行式一体化混合搜索。

用户的查询被发送到搜索引擎（如 Elasticsearch 8.x+ 或其他现代向量数据库）。搜索引擎同时在内部执行两个并行的任务：任务A 在整个索引上进行向量相似度搜索。任务B在整个索引上进行 BM25 关键词搜索。

搜索引擎拿到两路召回的结果后，使用 RRF (Reciprocal Rank Fusion, 倒数排名融合) 的算法，将两个排名列表智能地合并成一个最终的、唯一的排名列表。