做智能客服系统积累了三年多从最开始关键词匹配、规则引擎到最后接入大模型这条路走得比想象中曲折。商品客服这个场景很适合分享因为它是电商业务里需求最明确、效果最容易量化、同时能拷问的技术点也最密集的一个方向——你既要处理自然语言又要管实时商品知识还得扛住线上流量光这三点就能把人的短板全部照出来。这次把Spring AI RAG Redis向量库这套组合完整拆开从架构选型、数据准备、检索调优到面试里最容易翻车的三轮技术深水区一次性讲透。这套方案能解决什么问题一句话说就是让客服系统基于最新的商品信息回答问题而不是靠模型死记硬背或者运营天天更新话术库。适合三类人看正在做电商后端想把大模型落到业务上的Java工程师准备面试想找真实项目经历的候选人以及已经接了模型API但发现回答胡编乱造、不知道怎么收敛的人。1. 场景拆解与技术选型为什么这套组合能扛住拷问1.1 商品客服最核心的三个痛点做客服系统做得久了会发现用户问的问题翻来覆去就那么几类但每一类都够传统系统喝一壶。第一类是语义理解问题。“这键盘适合打游戏吗”跟“这键盘打游戏行不行”在字面上完全不同关键词匹配基本抓瞎必须靠语义向量才能把这两句话拉到很近的位置。第二类是实时知识问题模型训练完那一刻就已经“死了”用户问“今天下单明天能到吗”、“这个型号现在还有黑色吗”这些信息只存在于数据库和物流系统里模型根本不知道。第三类是对话记忆问题用户问完“这个笔记本能装32G内存吗”之后紧跟着说“那散热呢”这里的“那”指的是什么没有上下文谁都答不了。传统做法里规则引擎维护成本极高一个几十万商品的大型店铺光配置新的FAQ就能把客服运营累到跑路。模板匹配永远落后于用户问法。所以RAG架构才会成为当前落地大模型的主流选择——把实时知识外置到向量库模型只负责“理解意图 组织语言”知识来源交给检索。这样一来知识的更新周期从“重新训练模型”变成“更新向量库里的文档”分钟级就能生效。1.2 为什么用Spring AI而不是裸写HTTP调用很多人一上来就想到用HttpClient直接调模型API代码也就二十几行看起来挺简单。但做业务系统不是写Demo多轮对话、工具调用、结构化输出、向量库适配这些能力如果全部自己撸一个月都不见得能磨完。Spring AI最大的价值是给Java生态提供了一套标准抽象。模型可以随时换业务代码不用动向量库可以自由切接口都是统一的VectorStore。这不是什么炫技而是工程上非常实在的降本。客服系统里常常需要同时接对话模型和嵌入模型Spring AI把这两种能力都统一成了ChatClient和EmbeddingModel写起来很顺手。另外Spring AI跟Spring Boot天然融合自动配置、参数管理、Actuator监控这些都用得上。作为Java服务端与其自己维护一套模型调用SDK不如用社区在推的框架。这也是面试时一个很好的切入点——你要能说清楚框架帮你解决了什么、留下了什么坑需要自己填而不是只会说“用了Spring AI所以就很牛”。1.3 Redis向量库与专业向量数据库的取舍这个点几乎是我每次给别人做技术评审时必问的。项目里已经有MySQL、Redis、ES了再引一个Milvus或者专门部署一套向量数据库实例很多时候是过度设计。当时的选择经历了三轮纠结。先考虑用ES的向量能力但现有ES集群版本偏低升级成本和数据迁移代价不小而且ES做向量检索的资源和性能消耗在线性搜索场景下不如预期。接着考虑独立部署一个轻量向量库运维团队明确反对——他们的人手不够再维护一套有状态服务监控、备份、扩缩容全得重新搭。最后看到Redis 8.0以后RediSearch模块已经非常成熟向量检索、混合过滤、聚合都在一个指令里完成而且项目里本来就有Redis集群故障转移、持久化都跑了两三年直接复用。选型逻辑很清晰在商品客服这个场景单品类商品数据量也就是几十万到几百万条向量单条文本按几百字符算内存开销完全可控。Redis单机可以扛再加上本身就自带高可用架构完全能满足业务需求。如果数据量真的到了千万级以上、业务对召回精度和性能提出了比近似检索更硬的要求再演进到专业向量库也不晚。2. 数据准备把商品知识加工成向量库能用的样子2.1 原始数据的问题不是所有表都能直接喂给模型这个环节经常被低估甚至不少团队直接把商品表的CREATE TABLE语句拼成文本塞进向量库结果检索出来的内容根本没法看。商品数据库表结构是为事务设计优化的字段叫spu_id、sub_title、product_attr_json模型不理解这些东西。你必须先把数据转换成“模型能读懂的自然语言段落”。当时整理的源头数据主要有四类商品表标题、类目、卖点、规格参数、价格库存、售后规则表退换货时效、运费承担、质保说明、活动表满减、优惠券、赠品规则、咨询高频问答人工客服沉淀的标准话术。四类数据格式完全不同第一步是把它们全部拉平统一转成一种便于向量化的文档模板。比如说一个商品最终会形成这样的知识单元【商品名】某品牌机械键盘 K870 【品类】外设/键盘/机械键盘 【SKU】KB-87-红轴-白光 【价格】399元 【库存状态】现货 【核心卖点】全键无冲适合电竞玩家支持Win/Mac双系统 【适用场景】办公打字、FPS游戏、MOBA游戏 【规格参数】87键、红轴、PBT键帽、键线分离 【售后政策】七天无理由退货十五天换货一年质保 【常见问题】问这款键盘有手托吗答标配磁吸手托不需要单独购买这类模板有几个隐性好处。第一模型能看到清晰的字段边界回答的时候知道哪些信息可以引用、哪句话对应哪个属性。第二检索时如果用户问“这键盘质保多久”能直接被“售后政策”这个段落命中。第三人工维护起来也很直观运营看到的是半结构化文本而不是一条条冰冷的数据库记录。2.2 文档切分按知识单元切而不是按固定字符硬切做过RAG的人都有体会切分粒度直接决定检索质量。切大了一段文本里混杂多个主题向量被“平均”成一个模糊的中间值啥都命不准切小了一个完整知识被劈成碎片上下文信息丢失模型回答时缺少背景。我采用的是双层切分策略。第一层按商品维度切每个商品形成独立的知识块这样同品类的商品天然在语义空间上聚在一起。第二层在每个商品的知识块内部预留一个premium字段把结构拆成更细的行比如把“规格参数”单独拆出来作为一个可检索片段。这样既能支撑“这个键盘重量多少”这类精确查询也能支撑“推荐一款适合FPS游戏的键盘”这类泛化查询。参数上主要文本块限定在300到500字之间重叠区间控制在50字左右。这个数值不是拍脑袋而是根据商品客服场景的平均话语长度观察出来的。用户问题通常是十几个词的短句知识片段如果超过500字重排和生成的时候噪声比例会明显上升。切分完成后还要保持知识块之间的物理隔离不能把两个商品的内容混在一个文档块里。这里有一个非常容易踩的坑很多初学RAG的人用通用分割器按固定字符数把整本商品手册切成无差别碎片检索时一个商品的卖点和售后规则散落在不同块中。结果用户问退换货模型却只能找到卖点信息然后顺着上下文瞎编——“本商品支持七天无理由退换货哦”而实际情况可能是定制款不支持七天无理由。这种问题一旦出现在客服场景就不是技术问题是客诉。2.3 嵌入模型选型与元数据设计嵌入模型这一步也折腾了不少时间。通用的英文嵌入模型在中文电商场景里表现飘忽同义词理解非常差。后来换了针对中文优化的开源嵌入模型使用768维向量在商品检索数据集上召回明显提升。如果团队有条件调用商用嵌入API普通项目里优先选1024维以上、中文效果好的模型即可。嵌入模型选型有两条硬标准。第一必须跟检索场景同域客服问题的嵌入模型和商品描述的嵌入模型必须要一致否则两个向量根本不在同一语义空间里。第二维度要跟后续存储和检索方案匹配Redis里创建向量索引前就要固定维度后期换模型就得重建索引。元数据这块需要重点设计。每个向量文档除了content还额外挂了SKU、品类、价格区间、库存状态、更新时间、知识类型等元数据。这些字段在生成索引时会被登记成可过滤属性检索时能用“品类 外设 AND 价格 500”这种方式把候选集先缩一圈然后再做语义检索。实测下来加了元数据过滤之后检索准确率至少提升十几个百分点这个手段比单纯堆向量维度性价比高得多。3. 向量索引与检索实战Redis的配置和坑3.1 Redis环境准备与内存规划先说环境。要把Redis当向量库用要求Redis 8.0及以上版本并加载RediSearch模块。很多老集群没开这个模块得先安排升级或者用官方提供的Redis Stack镜像重新部署。模块启用后通过命令验证FT.MODULE_LIST返回可用模块列表就说明环境OK。内存规划上向量数据比普通KV要占空间768维float32向量每条约3KB加上文档内容和索引开销一百万条向量大概需要4到5GB内存。这个数据对电商客服场景来说完全可以接受。另一个关键是索引类型。Redis里向量支持FLAT暴力全扫和HNSW近似最近邻两种索引线上场景我建议直接用HNSW。商品客服对延迟敏感用户等不了全扫描计算。HNSW自身参数里M值控制每个节点的连接数越大召回越准但内存越高efConstruction控制建索引时的动态列表大小影响建索引速度和精度。一般M设16、efConstruction设200在百万级数据下比较均衡。3.2 创建索引与写入数据Redis的向量索引结构是Hash上加一个向量字段用FT.CREATE声明FT.CREATE idx:goods ON HASH PREFIX 1 goods: SCHEMA title TEXT WEIGHT 5.0 category TAG price NUMERIC stock NUMERIC embedding VECTOR HNSW 6 TYPE FLOAT32 DIM 768 DISTANCE_METRIC COSINE这段命令有几个关键点。PREFIX 1 goods:表示所有以goods:开头的Hash都会自动纳入索引后续写入不用再手动关联。title字段加了权重5.0意思是关键词检索时标题比正文正文重要。embedding字段声明为HNSW、6表示HNSW参数用默认值、float32、768维、余弦距离。写入数据时每条商品数据存成一个Hash向量字段是二进制字节形式。在Java侧不需要手工拼命令直接用Spring Data Redis的封装把Document里的content和metadata映射到Hash字段再把嵌入结果写到embedding字段里。批量写入时用Pipeline把几千条一次性发送过去明显比逐条写入快很多。一个容易出问题的细节FT.CREATE里的DIM必须和EmbeddingModel输出维度完全一致不一致的话索引创建会直接报错。某些模型会带归一化选项Redis里COSINE距离对归一化后的向量算出来是1-内积输出会非常接近0或2这会影响阈值判断后面讲调参时再展开。3.3 检索参数调优相似度阈值与TopK的经验值检索不是简单调一下search方法就完事。Spring AI封装的RedisVectorStore核心参数是topK和similarityThreshold。topK控制召回条数客服场景我建议设为5到8太少容易漏相关答案太多会把不相关的内容塞给模型增加幻觉风险。similarityThreshold这个阈值才是真正磨人的地方。一开始按经验设0.75结果发现一堆真实咨询根本召不回来因为中文商品口语跟商品文档书面语本来就有语义距离普通描述相似度很难超过0.8。经过一批真实用户咨询样本的标注调参最后把阈值定在0.72左右既阻断了明显无关的检索结果又不会让相关回答大幅流失。阈值不是一次定死的需要分品类、分场景动态适配。比如“退换货”这类规则类问题和售后政策文档文本重合度高阈值可以拉到0.78而“推荐一款适合送女友的键盘”这类开放需求跟商品描述语义跨度大阈值得调到0.65附近。所以后来在代码里没有把阈值写死进配置而是随每类检索请求动态传入。下表是我在项目中的一份真实调参记录场景类型典型问题示例建议阈值建议TopK参数规格这个键盘支持蓝牙吗0.853售后政策耳机坏了怎么保修0.783商品推荐适合打游戏的外设有啥0.688物流时效今天拍明天能发货吗0.7553.4 多业务索引隔离与混合查询商品客服系统不只是卖货还有售后咨询、活动咨询、会员咨询。如果全部放在一个索引里检索时容易互相干扰。比如用户问“这个键盘有优惠券吗”如果索引里混入了大量活动页内容可能召回一堆不相关的满减规则。实践中我按业务域拆了三个索引idx:goods、idx:aftersale、idx:promotion。各索引有各自独立的prefix、字段schema、阈值参数。查询时先通过意图识别模块判断属于哪类请求再定向到对应索引。如果是复合意图比如“优惠后价格多少现在下单明天能到吗”就分别查promotion和goods索引最后把结果合并传给模型生成。4. Spring AI服务端链路搭建4.1 项目依赖与基础配置Spring Boot工程的构建文件里核心依赖主要有这几个spring-ai-starter-model相关依赖对接对话模型和嵌入模型、spring-ai-starter-vector-store-redisRedis向量库支持、spring-boot-starter-data-redisRedis连接。配置上模型网关地址、API Key等放在环境变量里不落代码仓库spring: ai: chat: base-url: ${LLM_GATEWAY_URL} api-key: ${LLM_API_KEY} options: model: commodity-consult-v1 temperature: 0.1 embedding: base-url: ${EMBEDDING_URL} api-key: ${EMBEDDING_API_KEY} options: model: commodity-embed-v1temperature设0.1甚至更低客服场景回答必须稳定输出要尽量贴着知识库内容不是要创意表达。很多模型默认的0.7会带来随机性会让客服回答同一问题时前后说法不一致这对客诉处理是最忌讳的。4.2 装配向量仓库与检索组件在Spring配置类里定义一个向量仓库BeanBean public VectorStore vectorStore(EmbeddingModel embeddingModel) { Jedis jedis new Jedis(redis-host, 6379); return RedisVectorStore.builder(jedis, idx:goods) .withPrefix(goods:) .withVectorDimensions(768) .withDistanceType(RedisVectorStore.DistanceType.COSINE) .build(); }这个Bean注入到客服Service里执行检索ListDocument docs vectorStore.similaritySearch( SearchRequest.builder() .query(userQuestion) .topK(5) .similarityThreshold(0.72) .build() );这里返回的Document里既有content也有metadataSKU、品类、价格等。这些信息后面的提示词拼接里都要用。4.3 RAG的两种接入方式选对才不会踩坑Spring AI提供了很便捷的QuestionAnswerAdvisor能帮你自动完成检索注入提示词配置极其简单。但实际业务里我建议两步走如果你只是做POC验证直接上QuestionAnswerAdvisor如果这个系统要上生产还是手动拼RAG链路原因是可控性。手动RAG链路的代码逻辑大概是这样String buildContext(ListDocument docs) { return docs.stream() .map(doc - doc.getMetadata().get(skus) \n doc.getContent()) .collect(Collectors.joining(\n---\n)); } String answer chatClient.prompt() .system(systemPrompt()) .user(用户问题 userQuestion \n\n相关资料\n buildContext(docs)) .call() .content();手动拼接的好处有三个。第一可以在System Prompt里明确指出“资料中没有提到的不要编造”比框架默认写的更符合商家诉求。第二能控制资料的展示顺序把跟问题相关性最高的文档排在最前面模型注意力会很明显偏向靠前内容。第三可以在上下文里附带元数据让模型回答“这款有现货吗”的时候能看到实时库存而不是纯文本缓存信息。4.4 多轮对话记忆与上下文管理客服必然是多轮对话。用户问“这款键盘多少价格”系统回答后用户接着问“那和普通版有什么区别”这里模型不知道“那”指什么。Spring AI里的MessageChatMemory专门解决这个问题。MessageChatMemory chatMemory MessageWindowChatMemory.builder() .maxMessages(20) .build(); ChatClient chatClient ChatClient.builder(chatModel) .defaultAdvisors(chatMemory) .build();maxMessages设20意味着大约10轮往来的对话会拼接进上下文。设太大对话历史里的旧信息会对当前问答产生干扰设太小多轮跟踪就断了。这个参数需要根据模型上下文窗口大小和业务问答长度来调。另一个细节多轮对话时检索问题要不要带历史重写这里有个很常见的误区。如果用户第二轮的“那”已经带了上下文直接拿新消息去做向量检索可能召不回正确的商品。应该把当前问题结合最新对话快照重写成一个完整问题再检索。实现时会用模型把“那散热呢”重写为“某型号笔记本散热效果怎么样”再进向量检索召回质量会明显提升。这一步虽然增加了一次模型调用但值得。5. 面试深水区三轮拷问实况与应对话术5.1 第一轮RAG和微调你究竟怎么选面试官大概率会从你的技术方案切入“你为什么不微调模型要用RAG”这个问题表面考方案选型实际考你对大模型技术边界的理解。面试官听的不是你背出两种方案的优劣列表而是你有没有真的踩过坑、想过取舍。我的回答思路分三段。第一段先讲RAG解决的问题知识时效性、知识私有性、事实一致性。商品价格和库存每小时都在变微调完数据又过期了而RAG的知识更新是分钟级。第二段再客观地讲RAG的短板长尾知识表达弱、多跳推理困难、检索噪声放大这些是RAG做不好的地方。第三段再讲什么情况下必须上微调如果客服需要固定话术风格、需要输出特定的结构化字段、模型本身能力不足那就要考虑用领域数据做轻量微调。最后落脚到生产场景往往是两者结合——RAG管事实、微调管风格回答如果还能带上这个认知基本就过关了。5.2 第二轮检索质量怎么量化评估“你怎么证明你的检索效果好”这是深水区里最核心的一道题。这里特别怕听到“我们做了很多测试感觉效果不错”这种主观汇报。面试官想看的是有没有建立一套可量化的评估体系。我们当时的做法是用测试集驱动。从线上客服会话日志里抽了500条真实用户问题人工标注了每个问题对应的预期商品和标准答案。跑检索引擎时按是否命中预期商品来计算召回率。同时让模型在测试集上生成答案人工评估回答是否基于知识库、是否存在编造、语气是否符合客服规范。一个重要的观测指标是“资料利用率”。模型回答里引用到的资料片段数量越多答案与现实对齐的概率越高。通过落盘日志里的Prompt快照能看到一次回答到底用上了几条知识。如果召回了5条但模型只用上了第1条那前面的检索策略很可能有问题。追问一般是“你怎么调阈值”。这里要把之前提到的case复盘讲出来整理一个典型误召case集观察距离分数分布在误召分数边界定阈值再用另一组测试集验证避免过拟合。这套方法论比直接报一个数字有说服力得多。5.3 第三轮线上稳定性和异常降级“如果Redis挂了你的客服还能回复吗如果模型网关超时了用户会等多久”生产环境拷问往往落在SLA上。纯依赖外部模型服务是不行的再稳定的供应商也有极端情况。客服这个场景是面向用户端的消费者不会因为你后端超时就不投诉。这套系统的降级设计分三层。第一层出问题时直接切换到规则模板命中FAQ就从MySQL里读预设答案返回没命中就返回兜底话术“暂时无法解答请稍后再试或联系人工”。这个兜底响应时间必须控制在50毫秒以内不能等模型超时再兜底。第二层模型网关超时控制统一强制在3秒检索超过500毫秒就跳过向量检索直接返回模型基于通用知识的回答给个友好提示避免无限等待。第三层对高频问题做了回答缓存键用语义指纹直接避免重复走完整链路。成本问题也常被连带拷问。“一个真实客服会话平均调用几次模型”这个问题要能随口答上来。当时统计是每次用户对话平均1.2次对话调用加1次嵌入调用再算算单价一个活跃商家一天几万次调用成本可控在上千元级别。同时用多级缓存把重复问题拦截掉很多实际费用远低于理论值。6. 常见问题排查与效果优化记录6.1 检索到了但回答没用上上下文注入顺序有问题最常碰到的现象是向量检索明明召回了正确答案生成结果却完全没用上。查日志发现最可能的原因有两个。第一是System Prompt太强势模型被约束成了“只依靠内部知识回答问题”或者Prompt本身跟用户的提问风格冲突。第二是上下文放在用户消息最后被模型的注意力窗口忽略掉。RAG链路里相关性最高的资料要放在尽可能靠前的位置我在手动拼Prompt时把所有检索结果插在用户问题之前用“请基于以下资料回答”做引导回答稳定性立刻有改善。6.2 中文切词与空格问题导致召回异常还有一次线上出现系统性召回下降排查后是数据源里混入了繁体字和半角全角符号导致同义表达分到不同向量空间。清洗流程里统一加了繁转简和标点归一化之后又在小样本上做了一轮测试确认。中文场景务必关注这个环节——很多开箱即用的嵌入模型是按简体和规范标点训练的喂进去繁体或者英文逗号都会影响效果。6.3 商品数据变更后向量没同步商品信息不是一成不变的。价格改版、下架停售、活动变更如果只更新了MySQL没重新生成向量客服回答的可能就是过期信息。这块的解法是个双写逻辑商品变更时发一条MQ消息消费端重新生成该商品的完整知识块覆盖写回向量库。删除商品时也要同步删向量Redis里HNSW索引的删除效率不高实际操作中采用软删除加定期重建索引来解决膨胀问题。6.4 冷启动阶段没有足够真实咨询怎么办新店铺没有历史会话日志没法建测试集。这个阶段的经验是先用FAQ和历史客服话术构造合成问句问句模板覆盖“参数确认”“价格优惠”“物流时间”“退款规则”四类高频意图。等系统上线跑了两周再切到真实会话数据上迭代阈值和切分策略。冷启动不能追求最优参数率先让链路闭环跑起来后续逐步优化才是关键。最后分享一个实际运维侧的体会向量检索的质量不只在算法层数据质量和元数据设计同样重要。之前把商品名称、卖点、规格文档塞进同一个向量里和后来按知识单元拆分、绑定元数据过滤效果差别极大。做这类客服系统的朋友建议先把这层做扎实再去翻模型选型和阈值调优的账。这套链路里值得做二次复用的东西很多搜索策略、提示词模板、评估脚本都可以沉淀成工具后续再接入新渠道、新品类时就是纯粹的复制粘贴加微调了。