先说一个挺有意思的观察RAG这两年被讨论得很多但大多数人对它的理解还停留在“给大模型加个外挂知识库”这句话上。真到自己动手从向量是什么、文档怎么切、检索为什么不准到最后的评测指标怎么设计每一步都可能卡壳。我最近用Spring AI把一个本地知识库问答完整跑通顺手把整个链路画成了13张图从最基础的“向量是什么”一直画到最终的评测体系。这篇博文就跟着这13张图的思路把RAG从原理到落地的完整链路拆一遍核心关键词是RAG、Spring AI、向量、评测体系适合正在用Spring Boot做AI集成的后端开发者也适合刚接触RAG、想搞懂每个环节“为什么这么做”的入门读者。1. 从一张流程图看懂RAG的完整链路1.1 RAG到底在解决什么问题——先回答一个最基本的“为什么”如果你用过纯大模型问答大概率遇到过这么两种情况问“公司上个月的销售数据”模型说不知道因为它的训练数据截止到你买服务器那天问一个只有内部文档里有的操作规范模型一本正经地胡编了一个流程看起来还挺像那么回事。这就是大模型的两大硬伤——知识截止和幻觉。RAGRetrieval-Augmented Generation检索增强生成的思路本质上就是开卷考试不让模型凭记忆闭卷答题而是先把相关文档片段找出来摆在它面前再让它基于这些材料组织答案。整个过程分三步索引Indexing、检索Retrieval、生成Generation。索引阶段把知识文档解析、切分、转成向量存进数据库检索阶段根据用户问题找出最相关的几个片段生成阶段把这些片段拼进提示词交给大模型产出最终答案。这就像一个“知识外挂”或者“动态记忆卡”区别在于它不修改模型本身的参数只是每次问答时临时注入相关上下文。这种方式对工程落地特别友好——不需要训练、不需要微调知识更新只需要重跑一次索引改动成本比换模型低好几个数量级。1.2 第1张图把RAG全流程画成一条流水线我画的第一张图是一条横向流水线从左到右正好串起RAG的全部环节文档解析 → 文本切分 → Embedding向量化 → 写入向量库 用户提问 → 问题Embedding → 向量相似度检索 → TopK候选片段 候选片段 用户问题 → 拼接Prompt → LLM生成 → 引用来源输出这张图的价值在于把抽象概念落到具体名词上。你会发现RAG其实没有多少“AI魔法”前半段就是传统的数据处理管线后半段是检索系统只有生成那一步调用了大模型。我在用Spring AI落地时也是按这条流水线逐个找对应组件文档解析和切分用TextSplitter向量化用EmbeddingModel存储和检索用VectorStore生成用ChatClient。每个环节都会有文章专门讲这里先建立整体地图后面不管踩坑还是调参心里都有谱。和LangChain这类框架相比Spring AI在这条链路上最大的特点是“无状态且可替换”。检索和生成的每个环节都是独立接口你在开发时可以先用本地模型跑通流程上线前再替换成生产级向量库或云端模型这也是我后面实战部分反复强调的思路。2. 地基篇从“向量是什么”到向量数据库选型2.1 向量到底是个什么东西——用坐标和买菜来理解很多后端开发者一听到“向量”就头皮发麻其实完全不用。在RAG语境下向量就是一组数字通常写成[0.12, -0.55, 0.89, ...]这种浮点数列表。比如一段关于“红烧肉做法”的文本经过Embedding模型转换后变成768个数字组成的列表这串数字就是这段文本的“语义坐标”。为什么可以用数字表示语义因为Embedding模型在训练时学会了把“意思相近的文本放到高维空间里靠近的位置”。“红烧肉怎么做”和“猪肉如何炖煮”这两句话的向量距离很近而“红烧肉怎么做”和“数据库索引优化”的距离很远。这就是把文本匹配变成了数学计算——本质上是把非结构化数据变成了结构化特征。顺带把两个常见概念说清楚张量是向量的广义形式标量是0阶张量向量是1阶张量矩阵是2阶张量多维数组就是高阶张量。另一个是“向量叉积”——叉积在RAG里基本用不上检索中用的是点积和余弦相似度叉积的结果是向量而相似度需要标量所以别被网上的公式汇总带偏。维度数量是另一个值得关注的参数。常见Embedding模型输出512维、768维、1024维甚至1536维。维度越高表达语义的粒度越细但存储和计算开销也越大。实测下来中文知识库场景768维的模型如bge-m3的中文版本已经能覆盖绝大多数业务需求不必盲目追逐高维度。2.2 向量相似度怎么算——点积、余弦相似度与“为什么不提叉积”向量化只是把文本变成了数字真正“检索”的核心是计算相似度。最常用的相似度指标是余弦相似度公式长这样cos(θ) (A · B) / (||A|| × ||B||)其中A · B是点积||A||是向量的模也就是向量范数。生活化理解就是把两个向量都从原点出发看它们方向的接近程度。方向越一致余弦值越接近1方向完全相反接近-1垂直则接近0。Euclidean距离欧氏距离虽然也常见但在高维空间中容易受向量长度影响语义检索时往往不如余弦相似度稳定。点积本身也能当相似度用但它同时考虑了方向和长度如果Embedding模型的向量长度不稳定结果会被“长向量”带偏。所以Spring AI内置的向量库多数默认用余弦相似度或内积不需要你自己算。不过理解公式仍然有意义——当你调节similarityThreshold阈值时实际就是在设定这个余弦值的底线太低会带进噪声太高会漏掉相关内容。2.3 Embedding模型选型与本地部署Ollama怎么玩Embedding模型的选择直接决定检索质量的上限这地方别省钱也别省事。常见开源选项包括bge-m3、nomic-embed-text、mxbai-embed-large商业API有OpenAI的text-embedding-3-small和text-embedding-3-large国内厂商普遍提供中文本地化模型。在探索阶段我强烈建议先用Ollama跑本地Embedding模型零成本试错。安装Ollama之后拉取模型只需要一条命令ollama pull nomic-embed-text ollama pull bge-m3查看安装好的模型清单用ollama list启动服务是ollama serve默认监听11434端口。Spring AI里接入本地Embedding只需要配置一个地址spring: ai: ollama: base-url: http://localhost:11434 embedding: options: model: nomic-embed-text本地部署的意义不只是省API费用更重要的是数据不出内网。做餐饮SaaS这类toB项目时客户的菜单、配方、操作手册往往属于敏感业务数据走本地Embedding模型可以避免传输到外部API。生产环境如果没有GPU用CPU推理Embedding其实完全够用——向量化是小模型一次推理毫秒级和生成模型完全不是一个量级。2.4 向量数据库怎么选Chroma、Milvus、PgVector还是SimpleVectorStore向量库负责存储向量并提供近似检索能力选型决策可以从数据规模和运维成本两个维度来看。Spring AI早期版本内置了SimpleVectorStore纯内存实现非常适合本地跑通流程和写测试用例数据量超过几万条后性能和持久化都会成为问题不适合生产。我整理了一张横向对比表供参考这是第6张图的核心内容方案适合规模持久化部署成本Spring AI支持典型场景SimpleVectorStore万条以内无零成本内置默认原型验证、单元测试Chroma十万级有低单机适配器支持中小型知识库Qdrant百万级有中可单机可集群适配器支持生产级检索服务Milvus亿级有高依赖集群适配器支持大规模多租户场景PgVector百万级依托PostgreSQL低复用现有PG适配器支持已有PG基建的团队我的建议用一句话概括原型用SimpleVectorStore中小型项目直接上PgVector优点是不用额外引入新中间件在Spring Boot工程里加一个依赖就能把表结构建好。如果后续数据量暴涨、检索性能出现瓶颈再迁移到Milvus这类专用向量库。别一上来就搭Milvus集群运维成本会让你怀疑人生。3. Spring AI实战从配置到跑通第一个RAG问答3.1 为什么我用Spring AI而不是LangChain4j后端圈选RAG框架时绕不开两个名字Spring AI和LangChain4j。我在实际项目中两个都试过最终长期保留的是Spring AI。原因是它的设计风格和Spring生态高度统一——VectorStore是接口ChatClient是门面你熟悉的Configuration、Service、依赖注入全部照常工作学习成本低单元测试也方便。LangChain4j的优势在于起步早、功能覆盖面广尤其在Agent编排上更丰富。但Spring AI 1.0 GA之后迭代速度快官方对齐了OpenAI、Ollama、Qdrant、PgVector等主流厂商还推出了Spring AI Alibaba分支做国内云厂商适配。我的观点是如果你所在团队已经深度使用Spring BootRAG场景没必要引入两套技术栈。纯看文档和生态热度这俩半年内几乎不相上下但Spring AI在“无状态Web服务”场景下更顺手。这不算结论算是个人实战偏好。3.2 搭一个最小可运行的RAG工程我用Spring Boot 3.3 Spring AI 1.0.0 GA版本搭的工程Maven依赖就三个核心starterdependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-ollama-spring-boot-starter/artifactId /dependency dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-pgvector-store-spring-boot-starter/artifactId /dependency dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-tika-document-reader/artifactId /dependency配置文件application.ymlspring: datasource: url: jdbc:postgresql://localhost:5432/rag_demo username: postgres password: postgres ai: ollama: base-url: http://localhost:11434 chat: options: model: qwen2.5:7b embedding: options: model: nomic-embed-text vectorstore: pgvector: initialize-schema: true dimensions: 768这里有两个关键参数需要解释。initialize-schema: true表示Spring AI启动时自动创建向量表否则你要手写CREATE TABLE和索引DDL。dimensions必须和Embedding模型输出维度一致——nomic-embed-text输出768维那就填768如果换成bge-m3维度要改成1024不一致会导致写入时报错或查询返回全空。3.3 文档切分与写入向量库RAG里最容易被低估的步骤是文档切分Chunking它直接决定检索命中率。切得太小单个片段信息量不足大模型没有完整上下文切得太大片段里噪声太多相似度检索会被不相关内容稀释还会浪费模型输入窗口。Spring AI里提供了TokenTextSplitter按token数切分并带重叠率控制Configuration public class RAGConfig { Bean TextSplitter textSplitter() { return new TokenTextSplitter(800, 200, 5); } Bean ApplicationRunner ingestRunner( TikaDocumentReader reader, TextSplitter splitter, VectorStore vectorStore ) { return args - { var docs reader.get(); var chunks splitter.apply(docs); vectorStore.add(chunks); }; } }TokenTextSplitter(800, 200, 5)的含义是每个片段最多800个token相邻片段重叠200个token最少保留5个token。为什么需要重叠因为一句话可能在边界处被腰斩重叠区域能保证语义连贯性。实测下来中文文档用800到1000 token的切片大小回答质量最稳定如果知识库是FAQ问答对这种短文本结构根本不用切直接一条一向量。上传文档时我用的是TikaDocumentReader它对PDF、Word、Markdown、HTML都能解析内部用的是Apache Tika的格式识别能力。如果公司文档以企业内网Confluence和飞书为主建议额外写一层抓取或导出适配解析后统一转成Spring AI的Document对象再做切分。3.4 检索问答把“查资料”和“写答案”接起来写入向量库之后问答环节剩两步检索和生成。Spring AI最新版的ChatClient把这两步封装得很顺手Service public class RAGService { private final ChatClient chatClient; public RAGService(ChatClient.Builder builder, VectorStore vectorStore) { this.chatClient builder .defaultSystem( 你是一个企业知识库助手只能根据提供的参考资料回答。 如果资料中没有答案直接说“该内容不在知识库中”不要编造。 回答时引用资料编号例如[1][2]。 ) .defaultAdvisors(QuestionAnswerAdvisor.builder() .vectorStore(vectorStore) .topK(4) .similarityThreshold(0.45) .build()) .build(); } public String ask(String question) { return chatClient.prompt() .user(question) .call() .content(); } }QuestionAnswerAdvisor是Spring AI做RAG的标准入口它的内部逻辑就是“问题向量化 → 向量库检索 → 把命中的片段拼接进prompt → 交给ChatClient生成”。这里有两个参数值得反复调topK是返回候选片段数量similarityThreshold是相似度阈值。我的经验是topK从3到5之间开始试超过5之后大模型会“选择困难”答案反而分散。阈值则要结合你的向量模型来看——nomic-embed-text在中文场景下0.4到0.55是比较靠谱的区间低于0.4噪声明显高于0.6则经常查不到东西。注意阈值和topK是“且”的关系两个条件都满足的片段才会进入prompt所以阈值太高会导致实际可用片段远少于topK。4. 从Hit Rate开始搭建你的RAG评测体系4.1 为什么要有评测体系光“跑通了”不算数很多人做RAG最兴奋的时刻是第一个Demo跑通——问一句答案出来了看起来还挺像样。但实际放到业务里问题很快就来了“为什么有些问题答得好有些完全胡扯”“我改了一下切分参数到底改好了还是改坏了”“下周要上线了能保证准确率有多少”这些问题如果不量化只能靠“体感”判断。我的建议是从第一天就给RAG配上评测体系不需要复杂的平台一个带标注的QA集合加一个脚本就够。没有评测的RAG相当于没有CT和血常规全靠医生摸脉搏偶尔能蒙对长期必然出事故。4.2 核心指标拆解Hit Rate、MRR、NDCG、幻觉率对RAG评测的指标我挑四个实用度最高的展开。下面是第9张图的核心表格指标全称与含义计算方式适用判断Hit Rate命中率检索结果里是否有相关片段命中的query数 / 总query数检索有没有漏MRR倒数排名第一个正确答案排在第几位平均(1 / rank)答案排得够不够靠前NDCG归一化折损累计增益考虑多个结果的相关程度按位置加权折算结果排序质量幻觉率生成答案中无依据内容的比例需人工或LLM判卷最终回答靠谱程度Hit Rate是最基础的指标也是很多人评测的起点。它只问一个问题检索出的TopK片段里有没有包含能回答用户问题的关键段落公式就是命中问题数 / 总问题数。假设测试集有80个问题其中65个问题的TopK结果里出现了正确答案片段Hit Rate就是81.25%。MRR更严格它惩罚“答案确实在TopK里但排在很后面”的情况。比如某个问题的正确答案排在第3位这条query的MRR贡献就是1/3。如果三组对话正确答案的排序分别是1、2、4MRR (1 0.5 0.25) / 3 ≈ 0.583。MRR越高说明第一屏就给模型喂到了正确上下文。NDCG考虑到“多个片段可能都有用但相关性有强弱”适合评估整体排序质量但计算复杂度高小项目可以先不考虑。幻觉率则需要人工抽查或用一个更强的裁判模型来打分它衡量的是RAG“最后一道防线”的质量和检索指标配合才会完整。4.3 评测集怎么构建从知识库自动生成QA对评测集的质量决定了评测结果的可信度。我的建议是准备50到100条问题太少统计波动大太多标注成本高。评测问题可以有两种来源一是业务真实高频问题从客服记录、系统日志里挖出来二是用LLM从知识库反向生成。反向生成比较简单高效取一段文档原文让模型基于内容出题再保存“问题 期望片段ID 期望答案要点”。我写过一个批量生成脚本核心prompt长这样以下是一段知识库文本 [文本内容] 请基于该文本设计3个不同的中文问题要求 1. 每个问题都能从文本中找到明确答案 2. 覆盖不同难度直接查询、归纳总结、条件筛选 3. 输出JSON格式[{question: ..., answer_points: ..., source_chunk_id: ...}]生成后一定要人工抽检至少过一遍有没有问得含糊、答非所问的脏数据。评测集建好后放在Git里每次改检索参数、换Embedding模型、调整切分策略都跑一遍用指标说话。4.4 用Spring AI写一个自动化评测脚本代码层面把评测逻辑做成一个可重复执行的JUnit测试或者命令行Runner都行。核心思路是循环遍历测试集调用检索接口记录命中情况最后计算指标Component public class RAGEvaluator { private final VectorStore vectorStore; private final ObjectMapper mapper; public ListEvaluationResult evaluate(ListTestItem testItems) { ListEvaluationResult results new ArrayList(); for (TestItem item : testItems) { var searchResponse vectorStore.similaritySearch( SearchRequest.query(item.question()).withTopK(5) ); boolean hit searchResponse.stream() .anyMatch(doc - doc.getId().equals(item.sourceChunkId())); int firstHitRank searchResponse.stream() .map(Document::getId) .toList() .indexOf(item.sourceChunkId()) 1; results.add(new EvaluationResult(item, hit, firstHitRank)); } return results; } public double hitRate(ListEvaluationResult results) { long hits results.stream().filter(EvaluationResult::hit).count(); return hits / (double) results.size(); } public double mrr(ListEvaluationResult results) { return results.stream() .mapToDouble(r - r.firstHitRank() 0 ? 1.0 / r.firstHitRank() : 0.0) .average() .orElse(0.0); } }跑一次评测把Hit Rate和MRR打到日志或者输出成JSON然后对比改动前后的指标变化。这里要引入“评测驱动调参”的习惯每次只改一个变量比如只改切分块大小或者只换Embedding模型一次只动一个因素才能定位效果提升的真凶。5. 进阶GraphRAG、Agentic RAG与RAG as Service5.1 三种RAG形态的对比RAG不是只有一条路。传统RAG面向单轮问答每次从向量库检索一批片段拼进提示词生成答案简单直接适合大多数内部知识库。GraphRAG在此基础上引入知识图谱——先把文档里的实体人名、地名、产品名和关系抽出来构成图结构再结合图查询和向量检索混合召回适合回答“A和B什么关系”这类需要跨越多个文档的关联性问题。Agentic RAG则更进一步把RAG当成智能体的工具——模型自主决策“要不要检索、检索什么、要不要换一个检索词再试一次”适合复杂多跳推理。热词里还有一个Ontology RAG它比GraphRAG更强调领域本体Ontology适合术语体系严格的专业领域比如医疗、法律。但这类方案落地成本高需要业务专家参与建模小团队慎入。RAG as Service例如AgentScope 2.0的“RAG as Service”思路则是把检索能力封装成独立服务供多个业务方调用本质上是架构层面的演进。5.2 别急着上GraphRAG很多人在RAG刚跑通时就想上GraphRAG我的建议是“先量化再决定”。先用传统RAG搭好基线测出Hit Rate和幻觉率。如果问题集中在“跨文档关联回答不了”才值得引入GraphRAG。因为GraphRAG需要额外抽取实体关系、存储图数据、设计图查询调试成本比向量检索高出不止一个数量级。Spring AI目前的官方生态并没有完整内置GraphRAG你可以用Spring AI做向量召回再外挂Neo4j子图查询但这是工作量不小的项目别在Demo阶段冲动下单。5.3 Spring AI Alibaba与NL2SQLRAG的延伸方向如果知识库不是纯文本而是关系型数据库里的结构化数据RAG的检索环节就不适合走向量。热词里“Spring AI Alibaba NL2SQL”属于这个方向模型把自然语言问题翻译成SQL查询数据库拿到结果再组织成答案。Spring AI Alibaba分支提供了NL2SQL相关的路由和工具链支持本质上是用LLM做Schema理解和SQL生成。还有一种常见的混合策略先向量召回文档片段再从片段里用结构化抽取拿精确数值最后让模型综合两者回答。比如餐饮SaaS里问“上周三的翻台率是多少”资料PDF里有定义和规则具体数值在数据库里只靠向量库是绝对答不出来的。这种场景就需要你把RAG和多轮工具调用结合起来Spring AI的ChatClient通过Function Calling也能实现但那是另一篇长文的量了。6. 实战中踩过的坑与调参心得6.1 最容易踩的五个坑我整理了这半年做RAG项目时遇到的典型问题按出现频率排序现象根因解决方案检索结果一片空白Embedding维度与向量库配置不一致核对模型输出维度修改dimensions配置并重建集合答案答非所问但检索正常切分太碎单片段缺上下文调大chunk size加overlap或改用语义段落切分相似度阈值调高后经常无结果topK与阈值双条件过严候选被过滤光先不设阈值看topK召回再逐步调低阈值观察中文效果差直接用英文Embedding模型处理中文换bge-m3等中文本地化模型或做分词预处理答案刚上线没问题隔几天变差知识库更新后未重建向量建立增量索引流程文档变更时联动更新向量库维度不一致那个坑尤其隐蔽。nomic-embed-text输出768维bge-m3输出1024维如果先在Ollama换了模型但没改Spring配置查询时向量维度对不上向量库不会报“数据不匹配”这类明显错误而是安静地返回空结果。我当时查了两小时才定位到这个配置项。6.2 我最近验证有效的一组参数以中文知识库、qwen2.5:7b生成模型、nomic-embed-text向量模型为例我目前稳定使用以下参数切分块大小800到1000 token重叠200 tokentopK 4similarityThreshold 0.45生成温度设置为0.2。温度是很关键却容易被忽略的参数——RAG问答本质是“基于给定资料作答”温度太高会引入模型自由发挥的幻觉低于0.3更稳妥。如果是代码生成类的RAG温度甚至可以调到0.1。关于引用溯源我从一开始就给系统提示词强调“必须在答案后追加资料编号[1][2]”。做餐饮SaaS这类行业应用时客户对答案的可解释性要求极高他们需要知道这个结论出自哪份文档。没有引用来源的RAG回答在业务侧基本没有说服力。最后说一个我自己养成的验证习惯每次改完任何参数除了看评测指标一定人工挑10个典型问题挨个审答案。指标提升不代表每个关键场景都变好尤其要关注那些检索时召回正确、但生成阶段“自作主张”的情况。RAG的本质是“检索到的知识 模型的语言能力”评测检查的不仅是检索更是整个链路的协同质量。