一、前言今天不是单独学一个知识点而是串起了一条完整链路今天继续分析 AI 项目中的 RAG 模块时我发现自己之前对“文件上传”“文件切片”“向量化”“召回”“大模型回答”这些概念虽然都单独听过但真正放到项目代码里看时还是容易混在一起。尤其是看到项目里有文件上传分片上传MinIO 存储Kafka 异步消费Tika 文档解析文本切片Elasticsearch 存储向量用户提问时向量召回最后交给大模型生成回答一开始会觉得特别绕用户不是上传了一个完整文件吗为什么代码里又有分片文件内容不是已经向量化了吗为什么数据库里还要存文件路径、文本内容、元数据ES 不是倒排索引吗怎么还能当向量数据库今天主要就是把这些问题拆开来看。二、用户上传完整文件为什么项目里还有“分片上传”一开始我有一个误解我以为所谓“文件分片”就是 RAG 里的文本切片。但实际看代码后才发现这两个“切片”完全不是一回事。1. 上传分片解决大文件上传问题用户在页面上看起来上传的是一个完整文件但前端可能会把这个大文件拆成很多小块一块一块传给后端。这叫文件上传分片它解决的是大文件传输问题。比如一个 200MB 的 PDF如果一次性上传网络中断就要全部重传请求时间可能过长后端接收压力比较大前端也不好显示上传进度。所以前端会把文件切成多个 chunk例如文件A.pdf ├── chunk-1 ├── chunk-2 ├── chunk-3 └── chunk-4后端收到这些 chunk 后先临时保存等所有分片都上传完成后再合并成完整文件。所以这里的分片是完整文件 → 上传小块 → 后端合并成完整文件它跟 RAG 的文本切片不是一个阶段。2. RAG 文本切片解决知识检索问题RAG 里的切片发生在文件上传完成之后。也就是说后端已经拿到了完整文件比如一个 PDF、Word、Markdown 或 txt 文件然后才会开始解析文件内容。流程大概是完整文件 ↓ Tika 解析出文本 ↓ 把文本切成多个 chunk ↓ 每个 chunk 向量化 ↓ 存入向量库 / ES这个切片解决的是知识检索问题。因为用户提问时不可能把整篇文档都塞给大模型。所以需要提前把文档切成一小段一小段等用户提问时只召回最相关的几段内容。三、MinIO 是什么它在这个项目里负责什么今天还分析到了 MinIO。以前我更熟悉的是本地文件存储或者阿里云 OSS 这种对象存储。MinIO 本质上也是对象存储可以理解为一个可以自己部署的 OSS。它适合存PDFWord图片视频日志文件上传的原始文档在这个项目里MinIO 主要负责保存用户上传的原始文件。也就是说用户上传的完整文件最终不会直接塞进 MySQL而是放到 MinIO 里。MySQL 或其他数据库里一般只保存文件ID 文件名 文件大小 文件类型 MinIO存储路径 上传用户 上传时间 处理状态真正的文件内容在 MinIO。这样做的好处是数据库不会被大文件撑爆文件存取更适合对象存储后续解析、下载、预览都可以通过文件路径去 MinIO 取方便做分布式部署。所以 MinIO 在这个项目中的定位是原始文件仓库。四、Kafka 为什么出现在文件处理流程里文件上传完成后项目并没有直接在接口里完成所有解析、切片、向量化操作而是通过 Kafka 发送了一个文件处理任务。一开始我也会想为什么不直接上传完就解析还要搞 Kafka后来理解是因为文件解析和向量化属于比较耗时的任务。比如一个用户上传了一个几十 MB 的 PDF后端如果在上传接口里直接完成上传文件 解析文件 切片 向量化 写入 ES 返回结果那这个接口可能会卡很久。更合理的做法是上传接口只负责上传和保存文件 ↓ 发送 Kafka 消息 ↓ 后台消费者异步处理文件这样用户上传完成后接口可以快速返回。真正耗时的文件解析和向量化交给后台慢慢处理。所以 Kafka 在这里的作用是解耦上传流程和文件处理流程让耗时任务异步执行。这也是很多后端项目常见的设计思想。五、Tika 是什么它解决了什么问题今天还接触到了一个以前不太熟的工具Tika。Tika 的作用可以简单理解为从各种文件中提取文本内容。比如用户上传的文件可能是PDFWordExcelPPTHTMLtxt这些文件格式不一样直接读取肯定不方便。Tika 就像一个统一的文本提取器它可以帮我们把不同格式的文件转换成文本内容。例如用户上传Java并发编程.pdf Tika 提取后 “线程池的核心参数包括 corePoolSize、maximumPoolSize、keepAliveTime……”RAG 关心的不是 PDF 文件本身而是 PDF 里的文字内容。所以 Tika 是 RAG 文件处理链路里非常关键的一步文件对象 → 文本内容只有拿到了文本后面才能做切片、向量化和召回。六、文本切片到底是按什么切的今天分析代码时我一直在纠结一个问题如果按照段落切万一一段很短怎么办如果按照固定长度切会不会把一句话切断为什么还要有 overlap后来我理解了RAG 文本切片不是为了“切得好看”而是为了让后续检索更稳定。常见切法有几种1. 按固定字符数切比如每 500 个字符切一段。优点是简单稳定。缺点是可能把一个完整语义切断。比如Spring AI 中的 ChatClient 负责构建对话请求 而 Advisor 可以在请求前后增强模型调用……如果刚好从中间切开就可能导致前后语义割裂。2. 按段落切按自然段切更符合人的阅读习惯。但问题是有些段落很短有些段落特别长不同文档格式不统一。如果一段只有几个字也单独作为一个 chunk就会浪费一次向量化和召回机会。3. 按固定长度 overlap 切这是很多项目更常见的方式。比如chunk size 500 overlap 100意思是每个切片大概 500 个字符但相邻切片之间保留 100 个字符重叠。例如chunk1: 0 - 500 chunk2: 400 - 900 chunk3: 800 - 1300中间重复的部分就是 overlap。这样做的目的是防止重要语义刚好被切断。如果一个关键答案刚好位于 chunk1 和 chunk2 的边界处没有 overlap 的话可能两个 chunk 都不完整。有 overlap 后至少有一个 chunk 能保留比较完整的上下文。所以 overlap 不是重复浪费而是为了提高召回质量。七、数据库里到底保存了什么今天我一开始也有疑问用户提问的时候不是把问题向量化然后去向量库召回吗那数据库里为什么还要保存文件信息、chunk 信息、路径这些东西后来理解了RAG 不只是“向量召回”这么简单它还需要管理知识库。通常数据库里会保存几类东西。1. 文件元数据比如fileId fileName fileType fileSize minioPath userId uploadTime status这些字段用于管理用户上传过哪些文件。2. 文本切片内容也就是文件被解析、切片之后的 chunk 文本。例如chunkId: 001 fileId: A1001 content: “Spring AI 的 ChatClient 是一个面向开发者的高级客户端……” chunkIndex: 03. 向量数据每个 chunk 会被 embedding 模型转换成向量。比如[0.012, -0.431, 0.875, ...]这个向量用于后续相似度搜索。4. 元数据 metadata例如source: Java并发编程.pdf page: 12 chunkIndex: 5 userId: 10001metadata 的作用是让系统知道这段内容来自哪个文件属于哪个用户是第几个切片以后回答时能不能标注来源删除文件时要删除哪些 chunk。所以数据库不是为了替代向量检索而是为了管理整个知识库生命周期。八、Elasticsearch 不是倒排索引吗为什么还能做向量数据库今天也重新理解了 ES。以前我对 ES 的印象主要是ES 擅长全文检索核心是倒排索引。倒排索引简单说就是关键词 → 出现在哪些文档中比如有三篇文档doc1: Java 支持多线程 doc2: Spring AI 支持 RAG doc3: Java 可以开发 AI 应用倒排索引可能是Java → doc1, doc3 AI → doc2, doc3 RAG → doc2 Spring → doc2所以用户搜索 “Java AI” 时ES 可以很快找到相关文档。但现在 ES 不只支持传统关键词检索也支持 dense vector 字段也就是向量检索。所以 ES 可以同时做两类检索关键词检索适合精确匹配 向量检索适合理解语义相似例如用户问如何让大模型基于企业知识回答问题虽然文档里可能没有完全一样的关键词但如果某些 chunk 的语义和这个问题接近向量检索就可以召回它。这也是为什么有些项目会直接用 ES 来做 RAG 存储。它不一定是最专业的向量数据库但对于很多项目来说ES 同时支持全文检索和向量检索已经足够实用。九、用户提问时RAG 到底怎么工作把今天的内容串起来用户提问阶段的流程大概是用户输入问题 ↓ 将用户问题向量化 ↓ 去 ES / 向量库中搜索相似 chunk ↓ 拿到相关文本片段 ↓ 把问题 召回内容一起交给大模型 ↓ 大模型基于上下文生成回答也就是说RAG 的核心不是“把文件上传给大模型”而是先把知识提前处理好用户提问时再按需召回相关内容。上传文件时做的是知识入库文件 → 文本 → chunk → embedding → 存储用户提问时做的是知识检索问题 → embedding → 相似度搜索 → 召回 chunk → LLM 回答这两个阶段一定要分清楚。十、从手写 RAG 到 Spring AI 框架 RAG是一个很好的学习路线今天还对比了两个项目里的 RAG 实现。一个项目更偏底层很多流程都是自己写的文件上传 MinIO存储 Kafka异步处理 Tika解析 手动切片 向量化 存入ES 检索召回 拼接Prompt 调用LLM另一个项目则更多使用 Spring AI 框架能力比如DocumentReader TokenTextSplitter EmbeddingModel VectorStore Advisor ChatClient这两个项目放在一起看其实是非常好的学习路线。1. 手写 RAG 的价值手写 RAG 虽然代码繁琐但可以真正理解底层流程。你会知道文件是怎么上传的原始文件存在哪里文本是怎么提取的chunk 是怎么生成的embedding 是什么时候调用的向量和原文为什么都要保存用户提问时为什么要先做召回prompt 是怎么拼接给大模型的。这些东西如果只用框架很容易变成“会用但不懂”。2. 框架 RAG 的价值Spring AI 这类框架的价值是把通用流程封装起来让开发者更专注业务。比如原来你可能要自己写很多代码切片 向量化 存储 检索 拼 prompt 调用模型框架可以帮你抽象成VectorStore EmbeddingModel QuestionAnswerAdvisor ChatClient开发体验会更好代码也更清晰。但是如果没有前面手写 RAG 的理解直接看框架代码反而容易不明白这些组件背后到底做了什么。所以我觉得比较好的学习路线是先手写理解原理 ↓ 再用框架提升效率 ↓ 最后结合业务设计出真正可落地的 Agent / RAG 系统十一、今天最大的收获RAG 不是一个点而是一条工程链路今天看下来我最大的感受是很多时候我们说 RAG脑子里只想到向量化 召回 大模型回答但真正落到项目里RAG 是一整条工程链路。它至少包含文件上传 对象存储 异步任务 文档解析 文本切片 向量生成 向量存储 元数据管理 问题向量化 相似度召回 Prompt增强 大模型生成每一个环节都有自己的工程意义。比如MinIO 解决原始文件存储Kafka 解决耗时任务异步化Tika 解决多格式文档解析chunk size 和 overlap 影响召回质量ES 既可以做全文检索也可以做向量检索metadata 让知识库具备可管理性LLM 最终负责基于召回内容组织自然语言回答。所以 RAG 不是简单调一个 API而是一个完整的后端 AI 工程系统。十二、总结今天通过分析项目代码我对 RAG 的理解从“概念层”进一步走到了“工程实现层”。以前我知道 RAG 是检索增强生成现在我更清楚它在项目中是怎么落地的上传文件 → 保存原文件 → 异步解析 → 提取文本 → 文本切片 → 向量化 → 存储 → 用户提问 → 召回相关内容 → 大模型回答同时也区分清楚了几个容易混淆的概念上传分片不是 RAG 文本切片MinIO 存的是原始文件Tika 负责从文件中提取文本Kafka 负责异步处理耗时任务数据库存的不只是向量还有文件、chunk、metadata 等管理信息ES 不只可以做倒排索引也可以支持向量检索框架 RAG 更简洁但手写 RAG 更能帮助理解底层原理。