有一次面试对面Java技术专家翻到我简历上的智能客服项目从“知识库怎么建的”一路追到“大促时大模型限流怎么办”。三轮连问从RAG链路设计到Redis向量索引参数再到评估体系和成本账单基本把Spring AI RAG Redis向量库这套方案挖了个底朝天。我当场都接住了但回家用三天复盘才发现平时很多“能用就行”的细节其实经不起推敲。这个项目是我们团队在某电商平台做的智能商品客服系统。背景很直接每天几万条咨询里六成以上是“什么时候发货”“这个尺码怎么选”“材料怎么洗”这类重复问题人工客服忙不过来高峰期排队一小时起步。于是我们决定引入AIGC能力做自动回复技术栈最终落到了Spring AI RAG Redis向量库。圈里朋友叫我谢飞机下面把这三轮面试的完整复盘写出来包含选型过程、底层原理、上线后踩过的坑以及面试后补课补齐的短板希望给做Java后端、想接真实AI落地项目的同学一个参考。1. 业务痛点与技术选型从“全文塞进Prompt”到RAG1.1 客服机器人每天要回答什么先看业务改版前的样子。我们用自然语言处理工具统计了一周会话问题分布很稳定商品参数相关约58%物流时效约15%售后规则约12%剩下的是优惠活动、库存、人工投诉等。这些问题的共同点是答案不在系统里而是散落在商品详情页、历史售后工单、平台售后政策等一堆文档里而且经常变化。比如“现在买有优惠吗”促销期间和平时的答案完全不同同一款手机在不同活动周期的赠品也不一样。静态FAQ根本覆盖不过来所以最开始我们试的是“纯Prompt方案”——把高频问答拼成一大段文字塞进系统提示词让大模型直接回答。这个方案上线试了几天就放弃了。一是内容一多提示词很快触及上下文窗口上限二是每次请求都携带全量知识内容模型账单膨胀得厉害三是商家改一次商品介绍就得重新拼一遍提示词运营完全没法自助维护。后来转向RAG检索增强生成核心思路换成“先查知识库再生成回答”用户问题进来先从知识库中检索最相关的几个片段再把片段和问题一起交给大模型。这样每次请求只携带少量相关内容知识更新也只需改动知识库文档不用改代码和提示词。1.2 为什么最终选了Spring AI而不是直接调用模型SDK我们团队是纯Java后端出身没有独立的AI服务团队。如果走“Python脚本服务HTTP调用”的老路就得同时维护两个技术栈还得自己处理鉴权、重试、连接池和监控指标。直接在每个业务模块里引用模型厂商SDK更不可取未来一旦换模型供应商改动面会非常大。Spring AI的价值体现在两个层面抽象层统一ChatClient、EmbeddingModel、VectorStore等接口把模型调用、向量化、向量检索全部抽象掉。业务代码里只要面向这些接口写逻辑模型厂商演进、替换时基本不用改业务代码。生态整合自动配置天然融入Spring Boot体系配置中心、分布式链路追踪、监控指标可以直接复用。这对基础设置不太完善的小团队来说能省掉大量基础设施工作。坦白说Spring AI当时还不算特别成熟接口迭代确实快。但从团队综合成本来看它依然是我们能选的更优解。1.3 Redis向量库怎么就成了最合适的选择向量存储方案我们对比过很多专用的开源向量数据库、云厂商的向量检索服务、Elasticsearch向量插件以及Redis的向量索引能力。我当时的判断标准是客服知识库到底多大数据量大概几十万条文本片段单机Redis完全扛得住。专用向量数据库虽然更强但要新增一套基础设施引入新的运维职责、数据同步链路和监控体系对一个小团队来说投入产出不划算。Redis的优势在于“一库多用”同一个Redis实例既能承担业务缓存又能做向量召回还能配合哈希结构同时保存文档原文、业务属性和向量本身。用Redis Stack或升级到支持向量索引的Redis 7.x版本一条命令就能建索引本地实测Top5检索P99在10毫秒内完全满足在线客服场景。我当时整理过一张对比表后来面试复盘时也大致画给面试官看过方案开发成本运维成本数据规模适配备注纯Prompt方案低低极有限上下文窗口和成本扛不住Python服务专用向量库高高大规模需要增加新团队技能栈Spring AI Redis向量库中低几十万片段绰绰有余与我们团队背景最匹配直接调模型SDK拼业务代码中高中无弹性供应商锁定风险高选型没有绝对的对错关键是数据量级和团队现状。我们这件事的核心矛盾是“重复问题的自动回答”不是“千亿级向量检索”所以Redis是性价比更高的选择。1.4 整体数据链路长什么样项目稳定运行后的请求链路大致是这样的用户消息 - 意图识别 - 向量化 - Redis向量检索 - 父片段补充 - Prompt组装 - 大模型生成 - 输出校验意图识别和请求前置的规则比较轻后面几轮面试中面试官追问的都是中间这段向量检索到底怎么召回的、相关度怎么保证的、数据更新怎么做到的。2. 第一轮拷问RAG链路的知识库建设与检索效果面试官第一个问题非常直接“你的知识库是怎么建起来的”我当时给的回答比较偏重流程后来复盘才发现真正的难点其实在文本切分和相关性保障上。2.1 知识库是“切”出来的文本切分不能只按字符数我们把商品知识文档分成三类商品参数表、商品详情文本、售后政策条款。来源包括商家后台填写的结构化字段、商品详情页HTML、历史客服工单整理出的标准问答。一开始我图省事所有文本都按固定500字切块结果很快发现两个问题一个段落被拦腰切断语义不完整售后政策一类结构化文本切断后每块都缺失了关键条件模型经常给出错误结论。后来改成“结构优先、长度兜底”的原则先把文档按章节、表格行、条款编号拆成结构块再对超长块做滑动窗口切分。窗口大小设为300到500字相邻窗口保留50到80字的重叠避免关键信息落在边界被切断。还有一个容易被忽视的坑按“字”切和按“token”切不一样。中文一字通常对应一到两个token英文单词还要考虑子词切分所以代码里要按token计算窗口而不是按字符。我们在开源组件基础上做了个切分器把所有块都记录下doc_id和chunk_index方便追踪来源。切分太碎也会出问题。比如“发货时间48小时内”单独作为一个块检索命中后给大模型的信息量太少。我们的处理手段是把父级章节标题和上级摘要拼进命中的子块中让模型能理解上下文。这步在工程上叫“父文档补充”对电商场景的提升很明显但也只针对命中块做补充不能无脑把所有父级内容都塞进Prompt。2.2 召回了但相关度不够问题出在哪面试官第二个问题问到了痛点“用户问‘羽绒服保暖吗’你的检索能召回正确内容吗”我当时的回答是“能”但真实情况是初期经常不能。通用Embedding模型对电商话术的理解不够深“保暖”和“充绒量”这类词在语义空间中的关联度比我们想象的低尤其商品文案充满营销词模型不一定能把“蓄热锁温”和“保暖”对应起来。排查相关度问题不能靠肉眼感觉要建badcase集合。我们收集了500条历史高频问题人工标注出每条问题应该命中的知识片段然后离线跑检索统计Top5命中率。这一跑才发现召回率只有六成左右。解决手段主要做了三件事同义词注入在建立文档时人工维护一份电商同义词表把“保暖/蓄热/锁温/保温”这类词在文本中做归一化或追加生成让向量索引能命中更多同义表达。查询改写通过轻量规则把口语query改写成检索query。比如“什么时候到货”改写成“发货时间预计送达时间”改写后再向量化效果比直接丢原文好。检索路径扩展向量召回之外同时对商品名称做精确匹配和关键词倒排召回最后合并去重。这个阶段还有一个认知要纠正向量检索的“相关”是语义层面的近似不是电商业务口径的“正确答案”。排查不相关时先判断是切分问题还是Embedding泛化问题再判断是不是TopK和阈值设置不当不要一上来就换模型。2.3 TopK、阈值与重排在召回率和纯噪声之间找平衡面试官追问“你TopK取多少相似度阈值怎么设”我当时的参数是TopK5相似度阈值0.6左右。这个值不是定死的不同类目差异很大售后政策类文本句式规范分数普遍偏高商品种草文案口语化分数整体偏低。用统一阈值会导致售后类经常召回过窄、种草类经常召回一堆噪声。调参建议先做一次“分数分布摸底”拿线上真实query跑一部分检索画出命中率和分数的散点分布找到分界位置再定阈值。电商场景通常需要高召回宁可让TopK多一些再做后置规则过滤也不要把阈值调高导致无结果。另外用“先粗召回再精排”的两段式结构非常推荐。先向量召回50条候选再通过一个更轻量的排序模型或者基于更多规则特征重排取Top5。这个策略让答案准确率明显提升代价是增加了一次轻量排序计算Redis性能完全跟得上。3. 第二轮拷问Redis向量库的索引原理与数据一致性面试官顺着“用Redis存向量”继续深挖“底层用的什么索引算法参数怎么设置的”这一轮明显进入技术深水区纯靠调用经验根本答不上来。3.1 向量索引参数背后到底是什么Redis向量索引支持FLAT和HNSW两种算法。FLAT就是暴力全量计算准确但慢只适合几千条以下的小数据集。我们几十万条片段必须用HNSW。HNSW的核心思想是构建一张分层导航图每个节点只和少量邻居连接搜索时从顶层快速下探到底层在召回质量和检索速度之间取得平衡。面试官关心的是你有没有真正调过这些参数M每个节点的最大连接数越大图连接越密、召回越好但内存和构建时间都会上升一般取16到32。efConstruction建索引时控制候选集的动态大小越大索引质量越高构建越慢。efRuntime查询时的候选集大小越大召回越高但延迟也增加。我们当时的配置大致是M32、efConstruction200、efRuntime80。一次全量构建几十万条向量耗时在分钟级检索P99在10毫秒内。创建索引的Redis命令大致如下示意FT.CREATE idx_product ON HASH PREFIX 1 doc: SCHEMA content TEXT category TAG spu_id TAG doc_type TAG embedding VECTOR HNSW 6 TYPE FLOAT32 DIM 1024 DISTANCE_METRIC COSINE字段设计上要特别注意向量字段用VECTOR HNSW声明类型、维度、距离度量都要和Embedding模型输出的维度严格一致。如果模型换了输出维度没改这里索引直接就建失败。3.2 商品上下架引发的向量数据一致性面试官最狠的问题是“商品每天上架下架、价格秒变你向量库里的数据怎么保持一致”这个问题我们吃过亏。商品详情变了知识库文档没重建用户问“现在多少钱”模型还回答旧价格这是客服事故级别的问题。我们的完整方案分三层第一层是事件驱动更新。商品主数据变更时发出消息消费者收到消息后重新拉取商品详情切分、向量化、写入Redis同时删除旧文档。这里的关键是“删除旧向量”否则索引里同一个SPU会有多个版本检索时新老数据混在一起。第二层是全量对账补偿。消息丢失、服务宕机会导致漏更新所以每天凌晨跑一次定时任务把业务库中当天修改过的商品全部重新生成向量再做一次索引数据对比。这个任务不算复杂但对数据准确性保障最关键。第三层是版本控制。每条文档记录加一个version字段发布时版本递增检索时过滤指定版本范围。这样我们可以先写新版本、验证无误后再切换查询版本实现业务层面的平滑升级。向量数据的更新还有一个隐藏坑换Embedding模型后旧向量和新向量不在同一个语义空间必须全量重建索引不能增量混着用。我们有一次升级Embedding模型后忘了这件事检索结果明显变差排查了很久才发现是向量空间不一致。3.3 从“搜得到”到“搜得准”混合检索才是电商客服的正解面试官问“用户的问题里有品牌、有型号也有模糊描述你怎么保证不召回其他商品”向量检索擅长语义匹配但对“品牌型号”这种强约束并不敏感可能把相近描述的其他商品也召回进来。比如“XX手机屏幕多大”如果只做向量召回容易混入类似型号的屏幕参数。电商客服场景的正确答案是“混合检索”先用规则或轻量模型提取用户问题中的实体约束例如SPU ID、SKU ID、品类、型号、价格区间再用这些字段在Redis索引上做属性过滤最后结合向量相关性打分。实践中还会遇到一个问题同时用文本过滤和向量距离打分时Redis会先按过滤条件缩小范围再算距离如果过滤条件太严格可能一个结果都不剩。我们的做法是两路召回后合并一路走纯向量召回一路走“属性过滤关键词倒排召回”然后在业务层做一个简单的加权合并和去重。这对“从搜得到变成搜得准”是关键的工程优化面试官的点头程度说明他更在意的是你有没有真正面对过现实业务里的脏数据和混淆问题。4. 第三轮拷问大促流量下的稳定性、成本与评估体系前两轮偏重架构和原理第三轮直接转向线上工程化“大促流量进来大模型限流了怎么办回答错了怎么发现”这才是Java岗位和资深架构师最看重的部分。4.1 降级预案与结果兜底大促期间客服咨询量是平时的数倍每个环节都可能成为瓶颈。我们的设计是给整条链路分层降级意图识别模型超时直接放行到检索流程不阻塞主链路。Redis检索超时或不可用走静态FAQ兜底匹配命中率低但至少有响应。大模型API超时或限流返回“正在为您转接人工”并把这个会话路由给在线客服工作台不能给用户一个空白响应。这里有一个最容易忽略的地方降级不是简单返回固定话术要考虑“用户是不是在等待中发第二条”。我们给降级会话打标客服接手时能直接看到用户原问题和系统尝试过的回复提升转人工处理效率。缓存策略也很重要。客服场景很多问题重复度极高“这个手机支持5G吗”同一商品在活动期内几乎每天被问上百遍。我们在Redis里对“问题商品SPU活动期”这个维度缓存大模型答案设置5到10分钟TTL命中缓存就直接返回完全不调用大模型。大促期间缓存命中率能到三成以上API压力小了一大截。4.2 Token成本是算出来的不是拍脑袋省的面试官问“你一次回答大概花多少钱”这个问题逼得我把账单重新算了一遍。客服场景平均一次回复消耗600到1200 token其中一半以上是Prompt携带的知识片段和系统提示词。优化空间就在这系统提示词尽量精简去掉没用的角色描述控制在几百字以内。命中片段不要整块塞进Prompt做抽取压缩只保留与query相关的关键句。不经常变化的固定知识库内容做成“预置上下文”不必每次重新拼一遍。大模型API按token计费Prompt越长费用越高而且延迟也越明显。我们对Embedding模型和大模型API分别做成本监控按天、按商品类目统计。这里有个经验真正省成本的不是换更便宜的模型而是减少无效调用。对客户问题先做意图分类部分问题比如“你们客服电话多少”直接查配置表返回根本不走大模型。4.3 没有评估体系一切优化都是玄学面试官最认真问的一个问题是“你怎么量化你的回答变好了还是变坏了”这个我承认之前做得不好。最初的评估方式是“人工点开几条看”完全不可靠。后来补了一整套评估体系建评测集收集1000条真实高频问题人工标注标准答案和对应知识片段覆盖不同类目和难度。离线指标每次修改切分策略、调Embedding模型、改Prompt模板时在评测集上算Top5召回率和答案命中率。在线监控线上回答被用户点“踩”、转人工、重复追问的次数做监控作为bad case来源。评测集是整个RAG项目的“压舱石”。没有它参数调整的好坏根本没有标尺面试被深挖时也很难拿出有理有据的结论。5. 面试后的复盘值得补的三块短板三轮拷问结束之后我自己做了深入复盘整理了三个无论面试还是真实项目都值得补的短板。5.1 Embedding模型不能停留在“默认能用”通用Embedding模型在电商领域不是不能用而是天花板明显。营销文案、商品参数表、客服口语这三种风格差别巨大同一个模型很难同时做好。如果再做一次我会收集一批“问题-标准答案片段”数据在领域语料上做微调或fine-tune。这是下一步能显著提升召回准确率的方向。5.2 核心链路要用内部接口隔离框架依赖Spring AI早期到现在的接口变化让我吃了不少苦头。0.8.x升1.0.x时不少核心接口都变了。如果我们直接在业务代码里到处依赖Spring AI的类型改动面会非常可怕。正确做法是包一层内部客服接口比如AnswerEngine.query(query)把Spring AI调用放在实现里。这样框架升级时只改一个类上层业务逻辑完全不动。5.3 版本升级前必须做的回归测试框架升级、Embedding模型升级、Redis索引参数更新每一步都可能让线上结果变差。尤其是Embedding模型升级旧向量必须全量重建这个问题我们已经踩过一次。受训经验就是每次升级前先跑一遍离线评测集至少保证旧指标不下降再灰度放量上线。灰度比例从1%开始观察转人工率和用户反馈指标确认没有问题再放量。面试后我最大的体会是一个项目从“demo能跑”到“生产稳定”之间隔着的全是这些不起眼的工程细节。切分策略、数据一致性、降级兜底、成本核算、评估体系任何一种细节缺失都会在真正上线或面试深挖时露馅。把RAG和向量库搭起来只是起点真正的价值在于把它打磨成一个在复杂业务中稳定运转的系统。这些补课经验也一并分享给正在做类似智能化改造的同学。
