最近看 AI 应用开发RAG 这个词出现频率很高。刚开始我看到它的时候说实话有点距离感。又是 Retrieval又是 Augmented又是 Generation看起来像是偏算法或者论文里的概念。对于一个长期做 Java Web 后端的人来说第一反应可能是这东西是不是很复杂是不是要懂很多模型原理后来我换了个角度理解发现 RAG 没有想象中那么玄。如果用后端开发的思路来讲RAG 可以先简单理解成一句话先查资料再让大模型根据资料回答。这句话虽然不够学术但对应用开发来说已经够用了。为什么需要 RAG大模型本身知道很多通用知识但它有几个很明显的问题。第一它不一定知道你的私有数据。比如公司内部制度、项目接口文档、产品使用手册、客服知识库、历史工单这些内容一般不会在模型原始训练数据里。你直接问模型它可能只能给一个通用回答。第二它可能会一本正经地说错。这个问题大家应该都遇到过。模型生成的内容看起来很自然但里面有些细节可能是猜的。如果用在普通聊天里还好如果放到业务系统里就比较麻烦。第三业务知识经常变化。今天产品规则改了明天报销流程变了后天接口字段调整了。你不可能每次业务文档更新都去重新训练一个模型。所以 RAG 要解决的问题就是让模型回答问题时先参考我们提供的最新资料。比如用户问公司的差旅报销标准是什么没有 RAG 时模型可能会给一套通用报销规则。有 RAG 后系统会先从公司制度文档里找出相关内容再把这些内容交给模型让它基于资料回答。这样回答就更接近真实业务。RAG 的流程像一次增强版查询站在后端角度RAG 其实可以拆成一条请求链路。普通 CRUD 查询可能是用户请求 - Controller 接收参数 - Service 查 MySQL - 组装返回结果 - 返回前端RAG 问答大概是用户提问 - Controller 接收问题 - Service 检索相关知识片段 - 组装 Prompt - 调用大模型 - 返回答案区别在于传统接口查的是结构化数据比如订单表、用户表、商品表。RAG 查的是知识片段比如文档段落、FAQ 内容、制度说明、接口文档片段。查到以后后端不是直接把原始片段返回给用户而是把片段和用户问题一起交给模型让模型组织成更容易理解的回答。所以我更愿意把 RAG 理解成在大模型回答前后端先帮它查一遍资料。检索这一步是关键RAG 里的 R就是 Retrieval也就是检索。这一步非常重要。因为如果检索出来的内容不相关后面模型再强也很难回答准确。比如用户问Redis 缓存穿透怎么解决如果系统检索出来的是“Redis 持久化配置”那模型就算回答得很顺也可能偏题。这和我们平时写后端查询很像。SQL 条件写错了后面 Service 和 VO 组装再漂亮也没用。知识库检索一般会涉及两类方式。一种是关键词检索类似传统搜索。用户问什么就找包含相关关键词的文档。另一种是向量检索也就是语义检索。它不是只看字面词而是看语义相似度。比如用户问“缓存里没有数据库压力被打爆了怎么办”虽然没有直接出现“缓存穿透”但语义上可能和缓存穿透有关。实际项目里很多时候会把两种方式结合起来。先不要纠结哪种最好关键是要理解RAG 的第一步不是调用模型而是把相关资料找准。文档不是直接丢给模型很多人刚开始做知识库可能会想我把整份文档传给模型不就行了吗小文档可以这样试但真实场景通常不行。原因很简单文档太长模型上下文放不下每次传整篇文档成本太高资料太多时模型容易抓不住重点不同用户权限不同不能随便全传所以一般会先把文档拆成很多小片段。比如一份系统说明文档可以按标题、段落、模块切分成多个 chunk。每个 chunk 保存原始内容同时记录它来自哪个文档、哪个章节、哪个用户或租户。后面用户提问时只检索最相关的几个片段交给模型回答。从后端角度看这一步很像数据预处理。不是所有原始数据都适合直接使用需要清洗、切分、存储、建立索引。Prompt 负责把资料和问题组织起来检索到知识片段以后下一步就是组装 Prompt。一个简单的 RAG Prompt 可能长这样你是一个知识库问答助手。 请只根据下面提供的资料回答用户问题。 如果资料中没有答案请说明暂时无法确认不要编造。 资料 {context} 用户问题 {question}这里的{context}就是检索出来的知识片段{question}是用户问题。这一步看起来只是拼字符串但其实很重要。Prompt 写得太松模型可能会发挥过头Prompt 写得太死回答又可能不自然。尤其是知识库问答场景一定要约束模型尽量基于资料回答。我的理解是RAG 里 Prompt 的作用就是告诉模型别只靠你自己的记忆先看我给你的资料。MySQL 和向量数据库各管一部分做 RAG 时经常会听到向量数据库。刚接触时我也容易把它想成 MySQL 的替代品。后来发现不是。MySQL 仍然很重要。它适合保存结构化业务数据比如文档基本信息用户信息知识库信息权限关系问答记录调用日志文档分片元数据向量数据库更适合保存文本片段对应的向量并提供相似度检索能力。也就是说MySQL 管业务关系和元数据向量数据库管语义检索。这两个不是互相替代而是配合使用。比如用户提问时后端可以先根据用户 ID 查出他有权限访问的知识库范围再去向量库里检索这些范围内的相关片段。这样既能保证检索效果也能保证数据权限。RAG 不是万能的RAG 很有用但它不是万能方案。如果文档本身写得乱检索效果就会受影响。如果切分方式不合理相关内容可能被拆散。如果检索结果不准确模型回答也会跟着偏。如果 Prompt 没有限制好模型可能会在资料之外补充内容。所以做 RAG 时不能只盯着模型。文档质量、切分策略、检索效果、权限过滤、Prompt 设计、日志追踪都很重要。这也是我觉得后端开发者适合切入 RAG 的原因。因为很多问题本质上还是工程问题不是简单调一个模型接口就结束了。怎么实践如果让我用 Spring Boot 做一个最小版 RAG我会先这样做。第一步先支持上传 Markdown 或 TXT 文档避免一开始处理复杂 PDF。第二步解析文档内容把文本按段落或标题切成多个片段。第三步把文档信息和片段信息存到 MySQL。第四步调用 Embedding 接口把每个文本片段转成向量存入向量数据库。第五步用户提问时也把问题转成向量然后检索相似片段。第六步把检索到的片段和用户问题组装成 Prompt调用大模型生成回答。第七步把问题、命中的片段、模型回答、耗时、用户信息记录下来方便后面排查。第一版只要能跑通这个流程就够了。不要一上来就追求复杂后台、精细权限、多格式文档解析、自动评估。先把主链路跑通再慢慢补。最后RAG 听起来是一个 AI 概念但从后端开发角度看它其实是一条比较清晰的业务链路。用户提问系统检索资料组装上下文调用模型返回答案。它真正解决的问题是让大模型在回答时能参考我们自己的业务资料而不是只依赖模型原本的通用知识。对 Java 后端来说理解 RAG 不一定要先陷进复杂术语里。可以先把它当成一次“带知识检索的增强查询”。等流程跑通后再逐步深入向量检索、Embedding、召回效果、重排、评估这些内容。下一篇我准备继续往实战方向想一想思考 AI 应用架构